June release notes

Advance notice

For all customers using our messaging functionality, we will be deploying an updated patient-facing message viewing app to resolve ongoing reports of the current version not loading for a significant number of patients. This is expected to be a seamless transition requiring no downtime within the first two weeks of July. This is a platform change and will be switched over for all customers simultaneously; There are no other major functional differences and no action is necessary by customers or users.

Integration

Introduces a concept of primary identifiers for feed based integrations.

• Integrated customers can specify one of multiple possible identifiers (usually a hospital (MR) number) to be used as the primary identifier.
• This identifier is then treated as the most reliable source of truth for patients where multiple identifiers are present, and is required for all patients.
• All customers currently using feeds have already been contacted about specifying a primary identifier.

Adds support for ADT_A40 feed messages to handle patient merging.

• Integrated customers can now use this functionality to notify us when patients are merged in their PAS to allow our records to be updated accordingly.
• This is also the only method we accept for changing a patient’s primary identifier.
• Implementation work to send these messages is required on the customer side of the integration to use this functionality; please contact your account manager. The required message structure can be found in our HL7 specs here

Fixes an issue with patient matching that could result in the algorithm falling back to PROMs matching when the patient identifier on one of the two sides; the incoming message vs. our record, contains whitespace.

• This discrepancy could occur either as a result of manual input before integration was enabled, or via a previously incorrectly formatted identifier being passed via integration that was later corrected on the PAS prior to the use of A40 messages
• There was no risk of the wrong patient being found; affected messages would usually still find the patient via PROMs matching, and where there were multiple possible matches, the messages sat in the queue and alerted us, requiring manual resolution.
• This change reduces the frequency of the events requiring manual resolution and requires no action from customers