Issues With Development

PKB HL7 Feed

This section describes issues and solutions adopted during the testing of the HL7 feed.

Data Content Issues

This sections is to specifically describe issues with the way the data is held in the UKRDC and how that affects the ability to send/build the HL7 messages to send it to PKB.

Multiple Tests per LabOrder

• Currently PV files are turned into a laborder based on a single date. This means a single laborder on the ukrdc can have two results for the same test typically these are pre and post dialysis tests (not all sites supply the pre and post designator). PKB doesn't support more than one example of each result in a laborder. This means the laborders for PV files cannot be sent as is to PKB as they need to be split up. Not all laborders with duplicates have pre and post designators.

Field Sizes

• The data held in the UKRDC may exceed PKB field sizes. The way these checks are implemented in the PV extract is that prior to assigning a value the PyXB PV Schema Representation field is checked to find the element size and then the string truncated before assignment if required. For PKB we could do with knowing any limits they have so we could implement something similar but different.

Document Dates

Can PKB clarify the difference between the Activity/Origination/Transcription/Edit timestamps and how they're used in the UI.

10 Dec 2020  PKB asked

12 Dec 2020 PKB Response:

The four timestamps in the HL7 spec compete to be used as the basis for setting our document.timestamp value. We only capture the one timestamp in our data model. There is an order of precedence used to set document.timestamp. This is the order: TXA-8.1 (edit timestamp), TXA-7.1 (transcription timestamp), TXA-6.1 (origination timestamp), TXA-4.1 (activity timestamp).

Whichever ends up as the document.timestamp will be displayed in the UI. E.g. here is a discharge summary letter I just sent with TXA-8.1 set to 20201210093918.

In regards to documents in general. I notice for user 3205796616 you have loaded some clinic letters to the record - great! It looks like you haven’t got the file type set correctly. From a UX perspective it’s best to send through as .pdf. Then the letter will load seamlessly into the UI when you click the link (as my screenshot above). As you have it now the link prompts me to download and open in an external application which is not great for the user.

In regards to documents in general. I notice for user 3205796616 you have loaded some clinic letters to the record - great! It looks like you haven’t got the file type set correctly. From a UX perspective it’s best to send through as .pdf. Then the letter will load seamlessly into the UI when you click the link (as my screenshot above). As you have it now the link prompts me to download and open in an external application which is not great for the user.

Observations - SNOMED Codes

A PV to SNOMED Mapping Table needs to be populated and only applied to the Observations.

Multiple Measurement Message

• http://dev.patientsknowbest.com/home/hl7-api/messages/oru-r01/laboratory suggests that BPs need to be sent as a single message.

Question for PKB - If they were sent separately with the same observation time would the site recombine them?

10 Dec 2020  PKB Asked

12 Dec 2020 

I assume you are referring to the systolic and diastolic values? If that is the case then yes you do need to send them in on the same message and the OBXs providing the values need to be sequential. If you were to send them in separate messages you would get a rejection.

Sending Results

The results messages seem to be sending results with newest results sent first. This appears to be back to front and we should be sending the oldest data first then iterate through to the newest.

12 Dec 2020 PKB Response

I (David Lawson) think it would be better to send moving forward in time. That would be more representative of 'real life' data flow. It might help the notifications panel a bit too.

Diagnosis

Diagnosis seems to display sent date if no diagnosis date is sent. We have no diagnosis date for PV files but may for RDA sourced data this could be misleading.

EDTA coded diagnosis are displaying correctly which could be the sending of the data. It is also showing as two diagnosis (code+ blank text and the text)

PKB User Interface Issues

This section is to describe issues found with the way data is displayed in PKB or the way data sent is being rendered or grouped in the display. It should include any solutions to the issues agreed. Whether that is a change required of PKB or a change in the way the data is sent/formatted.

• Associate Icons on the main page in PKB are incorrectly scaled resulting in them being cut off.
• The Renal Association Icon is the old version of the Icon
• The icons are not clickable links and don't therefore take you to the associate website 

PKB should be able to correct this issue.

09/12/2020 This issues has been flagged to PKB Darryl is picking this up (12/12/2020)

• If a patient doesn't have a NHS Number (only HSC/CHI) then it isn't visible in the patient list but is on the patient record.

This seems to be a design feature in PKB. This needs querying with PKB. Each site on PKB is assigned a country of Origin England/Wales, Scotland, NI This defines which column is shown ie NHS Number, CHI, HSC) PKB will create some test sites that have an origin set to NI and Scotland to demonstrate this.

There will be some infrequent issues where a patient registered in one country has been referred for treatment in another and is registered on the renal system with their "home" NHS Number. This happens most commonly with NI patients.

• Notifications seem to be dated by update date so in his example the notification said 7 December (test patient
  3233986661) yet the latest value is in January:
  
  
  12 Dec 2020 PKB Response:
  We will need to confirm with our product team exactly how this works. Darryl would you mind picking that up please? I believe the notification for a test does show the date/time of message receipt into PKB as your screenshot suggests. So yes, that is something to consider with regard to the historical data load.

Graphs

The graphs default to the whole date range this looks odd when some results only have a few results in one date range and may be confusing to patients.

Add a result button

Prefills time but not date