Enabling a New Site

Owned by George Swinnerton
Last updated: Feb 03, 2022
5 min read

This assumes that a) when Send All Demographics was carried out that this unit was part of that send and b) that the New Patients Mirth Channel has been running to keep this up to date.

Darryl Nicholas darryl@patientsknowbest.com from PKB should be kept informed of the progress of each site. When started, When completed, how many patients sent, and if there are errors any impact that may have/delay. Darryl needs to know who each of the sites are in advanced so he can make his team aware and they can contact the sites and let them know. The Migration record/schedule should be updated as part of this

Preparation

Check whether the site to be sent belongs to a Trust which has already had a site enabled.

If this is the case a mapping needs to be created and loaded into the database - for example:

PKB_SITE,RQ601,PKB_MAIN,RQ617 PKB_SITE,RDEE4,PKB_MAIN,RGQ02 PKB_SITE,99RCSLB,PKB_MAIN,RCSLB PKB_SITE,RW3RM,PKB_MAIN,RM574 PKB_SITE,99RQR13,PKB_MAIN,RQR13 PKB_SITE,SGC02,PKB_MAIN,SGC04

Typically the “Main” site will be the Adult renal unit and the secondary ones will be the Paediatric site.

The send process then needs to be carried out for all the units individually as normal.

To check that this is working correctly (by doing a dry-run)

When doing the send for the secondary sites the MSH row in all files should have the code of the main site

MSH|^~\&|Renal Association|RQ617{RQ617}|

In the A28 messages the ZTM row should contain the code of the secondary site as a team name.

ZTM|prt~rq601

 

Initial Send

Log on to live-app.ukrdc.nhs.uk as ukrdc.

Activate the ukrdc-webapi venv.

source ukrdc-webapi/venv/bin/activate

Import the ukrdc-webapi environment variables. This is probably not required for Live but there is no harm in doing it.

source ukrdc-webapi/bin/env_settings.sh

Go to the pkbdump directory and check that the .env file contains the settings which correspond to Live.

Check there are no existing .dryrun or .responses folders. If you leave them there and run the script it will save its output in the existing folder and things will get confusing. There are instructions about what to do about the folders below.

 

If this is the first time doing a send for this type of system - or this is your first time of trying to do a send you may want to do a ‘dryrun' first. You can CTRL-C to quit it after a little while and just check a proportion of the files.

Run -

python services/scripts/pkb/dump.py send --dryrun --facility ABC123 --no-anon

(note the --dryrun parameter) This will create files in a .dryrun folder. Open one in a text editor and they should all contain a line similar to -

When doing a Live send it should NOT have a postcode of BS10 5NB as this means the anomyisation is still on.

Any errors will be in .dryrun/exceptions , .dryrun/empty , .dryrun/malformed or .dryrun/failed. When doing a dry run you should not have any files in these folders.

If there are any errors log tickets for them under the PKB project. Retain the .dryrun folder while you investigate.

If there are no errors or all errors have been resolved the .dryrun folder can be deleted.

 

When you’re ready to do the actual send -

Run -

It will output a lot of messages about insecure HTTPS Connections. This is an issue with the version of OpenSSL on the App servers and can be ignored.

 

Check in .responses/failed to see if there are any messages in there. A small number - say under 200 - files in there shouldn’t be a cause for concern provided the error messages are ‘known’ ones. The files will have the format 0000000000_MSG_TYPE_00 where the first numbers are the PID and the last are a counter for the number of messages of that type. It is of more concern if the rejected messages are spread across a lot of PIDs rather than a few PIDs having had all their messages rejected.

Known Errors:

Error

Cause

Fix

Error

Cause

Fix

Response NULL

 

Resend

Unexpected error while processing: javax.persistence.PersistenceException: org.hibernate.exception.JDBCConnectionException: could not prepare statement

Database issue at their end, possibly because two records are being processed for the same patient at once.

Resend

Unexpected error while processing: EJBCLIENT000079: Unable to discover destination for request for EJB StatelessEJBLocator for "phr/tolvenEJB/InstituteBean",
view is interface com.pkb.institute.InstituteRemote, affinity is None

This is another issue at the PKB end. It does seem like it might be triggered by a patient having a large number of OBS records.

Resend

HTTP request execution failed for URI [http://phr-wf:80/hl7Upload.action] in the [bean \'httpOutboundForSoapInboundGateway\' for component \'soapInboundFlow.org.springframework.integration.config.ConsumerEndpointFactoryBean#5\'; defined in: \'class path resource [com/pkb/integration/config/SoapInboundGatewayConfig.class]\'; from source: \'org.springframework.core.type.classreading.SimpleMethodMetadata@4cf777e8\']; nested exception is org.springframework.web.client.HttpServerErrorException$ServiceUnavailable: 503 Service Unavailable

 

Resend

 

 

 

 

 

Unexpected error while processing: Lookup single patient found more than one match by nationalId matches: [7554, 7676]

This is an issue at the PKB end, possibly related to a patient with both CHI and NHS numbers.

A minimal amount of the PID lines should be e-mailed to PKB ( help@patientsknowbest.com ) saying we have had these errors and asking them to investigate.

For example -

PID|||1111111111^^^NHS Scotland^NH~42222222222^^^NHS^NH

PID|||22222222222^^^NHS^NH~111111111111^^^NHS Scotland^NH

Do not send the rest of the demographics.

The files should not be resent until the PKB helpdesk have confirmed they’ve fixed the records at their end.

Parsing or validation error: Ambiguous patient IDs provided

This is an issue at the PKB end, possibly related to a patient with both CHI and NHS numbers.

Same as “Lookup single patient found more than one match”.

To resend the messages

  • Make a note of the PIDs the messages belong to.

  • Remove the PID from the .responses/resume directory if they exist.

  • Move the error responses to a subfolder of the failed folder

  • Run python services/scripts/pkb/dump.py send --facility ABC123 --no-anon --resume

  • Check to see that no more failure messages

 

When this has been done delete the contents of .responses/success

Rename the .responses folder to .responses_ABC123

Move the .responses_ABC123 folder to /data/PKB/

 

If these have resent correctly contact PKB to let them know it has completed, and advising them of what errors, if any, were found.

The people to be included on this e-mail are

 

In the Live UKRDC Database update the Facility table to set pkb_out = True.

This will then enable updates to be sent via the “PKB Identify Changes” view.