Full details of changes can be found in the release notes in version 2.0.1-public-beta.
Design overview
The Send Document capability provides a simple and standardised means of sending a document, such as a PDF, an image, or HTML file to a GP practice system. Each message sent using the Send Document 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.
GP Connect aims to support better clinical care by opening up information and data held within GP principal clinical systems for use across health and social care. The GP Connect vision will be achieved by standardising integration and simplifying the operating model. Find out more on the NHS Digital GP Connect homepage.
GP Connect has initially focused on delivering HTTP FHIR® APIs. The current GP Connect FHIR API specification is found at https://digital.nhs.uk/services/gp-connect/. An additional set of capabilities, under the badge GP Connect Messaging, is described in this specification. These new capabilities are focused on enabling updates to GP practice systems.
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, v2.10.0 standard
Who will be interested in this capability?
Two main audiences will be interested in this specification:
- message senders: NHS organisations 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 | Send document 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 send document 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 send document 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 for send document payload. Refer to Send Trigger for guidance on available options. |
| 2 | Create the ITK3 payload: Construct a PDF description of the encounter. |
| 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. |
Typical process map
Steps in the process explained
Step 1: Author patient activity
Clinician inputs the details of the activity into the GP provider system. Data inputted could be free text or clinical codes which may be entered manually or through the use of clinical templates. It could include adding attachments/documents (for example, pain-point diagram, ECG, photo). This is no different from the normal method of writing a activity for a patient registered at the GP practice.
Step 2: Save activity
The clinician manually saves the patient activity and commits them to the patient record.
Step 3: Save activity into patient record
The provider system saves the patient activity into the patient’s electronic record at the GP practice.
Step 4: Is the patient registered at this GP Practice?
The provider system need not send a patient activity if the patient they have seen is registered at their practice.
Step 5: Wait for a configuration amount of time
The provider system waits for a configuration amount of time (recommended three hours) before the process moves on. This gives time for the clinician to make any necessary updates to the patient activity to reduce the chance of the report being sent multiple times.
The period of time that the clinical system waits before sending a message can be configured by each GP practice to meet their local needs.
Step 6: Further updates to the activity required?
If the user makes changes to the patient activity in the patient record within the allotted time (step 5), the process moves back to step 1.
Otherwise, the process moves on to step 7.
There may be many reasons why the activity is not completed when initially saved:
- the clinician may not have time to finish the patient activity and must continue with treating other patients
- the clinician may wish to ask a colleague for advice
- the clinician may be off-site and will finish writing the patient activity when they have returned to the GP practice
- the results of a test may be required before the clinician can complete their notes
- the clinician may have forgotten to add some important information when originally writing the patient activity
Step 7: Generate a PDF and metadata
A FHIR message is generated which contains a PDF which contains all the information recorded in the activity (including free text, clinical coding and other data entered relating to the activity).
The ITK3 FHIR Message is generated, which must include:
- FHIR MessageHeader
- FHIR STU3 composition
- PDF file, its contents and metadata
- all attachments/documents recorded with the activity
When the PDF is generated, the provider system checks for previous versions of the PDF linked to this activity.
A previous version will exist if the clinician updates the activity more than three hours after it was initially saved and committed.
- if there are no previous versions, the PDF is designated as
[version 1] - if there are previous versions, the PDF is designated
[version 2 / 3 / 4 / ...n] - the version number is displayed in the title of the PDF:
[document title] Version [x]and the version field within the document itself
Step 8: Send message via MESH
The provider (sending) system passes the message to the MESH client.
Step 9: MESH file transfer
The MESH client transfers the message to the MESH inbox of the patient’s registered GP practice.
Step 10: Retrieve message from MESH
The consumer (receiving) system of the registered practice retrieves the message from their MESH inbox.
Step 11: Send infrastructure acknowledgement
The consumer system sends an ITK3 FHIR Message to the provider system containing:
- FHIR MessageHeader
- FHIR OperationOutcome (ITK3 response with response code
10001to20013)
Step 12: Receive infrastructure acknowledgement
The provider system records the infrastructure acknowledgement. If no acknowledgement is received within a reasonable timeframe (to be defined by system supplier), the provider system notifies an appropriate end user.
Step 13: Add message into workflow
The consumer system matches the message to a registered GP patient and presents the message to an appropriate user in a designated workflow.
Step 14: Send business acknowledgement
The consumer system sends an ITK3 FHIR Message to the provider system containing:
- FHIR MessageHeader
- FHIR OperationOutcome (ITK3 response with response code
30001to30003)
Step 15: Receive business acknowledgement
The provider system records the business acknowledgement. If no acknowledgement is received within a reasonable timeframe (configurable), the provider system notifies an appropriate end user.