GP Connect - Update Record (ITK3)

Business process integration

GP system suppliers have implemented rich workflow solutions to enable management of incoming healthcare events. Frequently, these incoming events result in the creation of tasks with associated workflows, which are assigned in a flexible and configurable way by each practice to suit their requirements. These solutions provide options for practices to define how this information is treated according to message type and content - enabling the definition of rules to automate the application of updates where this is deemed appropriate.

Senders of healthcare events frequently follow business processes which include a requirement that the target organisation not only acknowledges receipt of the message, but also includes expectation of notification of workflow events which cannot immediately be generated upon message receipt.

Therefore, the approach taken to facilitate updates to GP principal clinical systems originating outside the practice has sought to align closely with these existing practice workflow capabilities and requirements.

Communication paradigm: asynchronous messaging

With the choice of an asynchronous communication paradigm, the natural choice for transport was MESH, which is the strategic platform already in place to support the asynchronous messaging needs of the NHS.

MESH (and its predecessor DTS) is a proven platform which has successfully supported NHS messaging requirements for several years. One of the main benefits MESH brings is excellent reach.

MESH connectivity has already been implemented widely across the NHS and, importantly, is already built into support message flows incoming to GP practices in all GP core clinical system implementations.

Asynchronous messaging paradigms

Messages flowing into GP practices on MESH will arise mainly from the following two patterns of event notification:

1. Point-to-point event notification

Where the message sender knows which party or parties the message is intended for, a point-to-point event notification is often used. Here the sender directs the message to a known recipient or set of recipients.

For example, this specification uses this pattern. The sending practice knows that the payload is intended only for a single known recipient organisation - the registered practice of the patient. Therefore, this pattern is used for this use case and the MESH Endpoint Lookup Service is used as a broker to facilitate this message delivery pattern.

2. Publish/Subscribe event notification

This pattern would be more applicable where a healthcare event has taken place, but the message sender does not know all the parties who are interested in that event.

In this model, organisations will subscribe through an event hub to those events in which they have a legitimate interest. The sender publishes an event to this event hub, and all the subscribers to the event will receive the event details.

Messaging format: FHIR STU3 messages

The HL7 FHIR Message framework was chosen as the messaging format.

HL7 has defined FHIR STU3 as a standard to enable interoperable on-the-wire communication of healthcare data. Within the FHIR STU3 standard, a framework is defined for the exchange of healthcare information in an asynchronous messaging scenario - the HL7 FHIR Message Framework. This, therefore, was a natural choice for the message format, and aligns with the approach taken by the ITK3 Message Distribution Standard.

Re-usability: payload re-use

In designing a payload to meet a particular use case, care has been taken to design the payload in such a way that it may be re-used to fulfil other identified use cases through configuration change only.

For example, the Send Consultation Report use case makes use of the more general payload type. Should a future use case arise where a document needs to be sent, the same payload can be re-used.