An issue was identified with the FHIR package supplied with this version of the specification, which has been rectified.
Please click here to view the patched v1.1.1-public-beta specification with the updated FHIR package.
Design overview
The GP Connect Update Record (ITK3) capability provides a simple and standardised means of sending a structured payload between community pharmacy, and GP practice. Each message sent using this capability makes use of the GP Connect Messaging components, MESH, and ITK3 to deliver the message.
All messages sent using this capability will be FHIR® Messages, defined as a FHIR composition, constructed to meet the ITK3 standard and have a specific payload structure.
Initially, this capability will support the Pharmacy First Initiative for the following use cases:
- CPCS Minor Illnesses (including Common Conditions)
- Blood Pressure Check Service
- Contraception
Representation of the data
ITK3 is being used as the vehicle to transport the data between care settings, as it is well-established across GP and pharmacy system suppliers.
The representation, however, makes use of the GP Connect data model (FHIR STU3 representation) - which is the same model that is used by GP Connect - Access Record: Structured, and GP Connect - Patient Facing Services.
The intention is that the vehicle can be changed (for example, from ITK3 to a REST API) - but the FHIR profiles (outside of those required for ITK3) can still be ingested - rather than having to build new mappers to ingest data from the FHIR representation to the receiving system internal data model.
The initial use cases for this capability are pharmacy-based, and care has been taken to ensure that the fields within the PRSB Pharmacy Standard (V3.01) can be represented, without bespoke requirements on the FHIR representation that deviate from the existing profiles.
Each use case will be indicated via the appropriate SNOMED CT code using the Profile: CareConnect-Composition-1, within the type element.
ITK3 - How it all fits together
Using messaging to perform updates
In contrast to the synchronous FHIR® API approach, which has been taken to enable read-only access to patient information, updates to patient data will be fulfilled through a messaging approach.
Update messages will:
- be sent using MESH
- use the HL7 FHIR® STU3 interoperability standard to define their structure
- include FHIR® messaging information as defined by the ITK3 Message Distribution standard, v2.10.0 standard
Who will be interested in this capability?
Two main audiences will be interested in this specification:
- message senders: Community pharmacies seeking to send messages
- message receivers: GP practices seeking to receive and process messages
Typical message flow
The following diagram illustrates how messages flow between the sending (originating) organisation and the registered practice via MESH to fulfil this use case:
The diagram above depicts a successful message flow where registered practice message processing validates and matches the initial message successfully to a patient. This involves the following steps:
| Step | Event | Description |
|---|---|---|
| 1 | ITK3 payload | |
| 1a | After the patient activity is complete, a trigger at the sending organisation results in a FHIR Message being constructed which includes a PDF describing the patient activity. | |
| 1b | The MESH client at the sending organisation sends the message to the MESH server where it awaits collection by the registered practice. | |
| 1c | The MESH client at the registered practice collects the message from the MESH server and makes it available to other registered practice system components for onward processing. | |
| 1d | The message is processed at the registered practice. | |
| 2 | Infrastructure acknowledgement ITK Response | |
| 2a | When the payload is passed from the MESH client for processing at the registered practice, the message is first validated to ensure that its structure is correct. An ITK3 Response message is generated which indicates the success of message processing at a technical level - this is known as an infrastructure acknowledgement. |
|
| 2b | The MESH client at the registered practice sends the message to the MESH server where it awaits collection by the originating organisation. | |
| 2c | The MESH client at the originating organisation collects the message from the MESH server. The ITK Response is then available to other originating system components for onward processing. | |
| 2d | The acknowledgement message is processed as appropriate by the originating organisation. | |
| 3 | Business acknowledgement ITK Response | |
| 3a | When the payload is passed from the MESH client for processing at the registered practice, after successful message validation, the subject of the message contents - the patient - is looked up to ensure that patient is known and registered at the practice. An ITK3 Response message is generated which indicates the success of patient matching - this is known as a business acknowledgement. |
|
| 3b | The MESH client at the registered practice sends the message to the MESH server where it awaits collection by the originating organisation. | |
| 3c | The MESH client at the originating organisation collects the message from the MESH server and makes it available to other originating organisation system components for onward processing. | |
| 3d | The acknowledgement message is processed as appropriate by the originating organisation. |
The following processing steps must take place at the originating organisation system (the sender) to create the message - as described in step 1a above.
| Step | Description |
|---|---|
| 1 | Initiate process to create a payload. Refer to Send Trigger for guidance on available options. |
| 2 | Create the ITK3 payload. |
| 3 | Wrap the payload as an ITK3 message, requesting infrastructure and business acknowledgements. |
| 4 | Create the MESH message. Specify NHS Number, DOB and Surname in MESH metadata to enable MESH to route to registered practice. |