[RETIRED] - Use-cases for GP Connect Send Document

Note: This has been superceded by the Send Document v2.0.0 specification

Use-case: Consultation summary

When a patient is seen by another organisation it is necessary for information from that consultation to be sent back to the patient’s registered GP practice. This is so the information can be recorded in the patient’s clinical record and is available during future consultations.

The use cases listed below are indicative of how the GP Connect Send Document capability could be used in this use case, but are not exhaustive.

A Consultation Summary is the clinical notes from the patient encounter with the clinician sent as a PDF

Example usage

GP Practice

Appointments

This use case completes the set of capabilities required to fulfil the following workflow:

The GP Connect Appointment Management FHIR® API enables booking of a consultation at an alternative organisation.
The GP Connect Access Record HTML FHIR® API enables an amenable consultation to take place at the alternative organisation through access to the patient record stored at the patient’s registered practice.
After the consultation, GP Connect Send Document enables the details of this consultation to be written back to the registered practice so that the registered practice patient record continues to provide an up-to-date view of care which the patient receives in a GP practice setting.

Note: The first two steps above use synchronous GP Connect FHIR® API capabilities and an asynchronous messaging approach is taken to facilitate the update made at the registered practice by the final step. GP Connect Appointment Management and GP Connect Access Record HTML are not prerequisites for GP Connect Send Document.

Out of hours

A patient visits an out-of-hours service (not provided by their registered GP practice). After the consultation, GP Connect Send Document enables the details of this consultation to be written back to the registered practice so that the registered practice patient record continues to provide an up-to-date view of care which the patient receives in a GP practice setting.

Targeted / specialist services

District nursing

A patient under the direct care of a district nurse. Clinically relevant encounters, for example, the start/end of care being provided, should be sent back to the patient’s registered practice using Send Document so that the registered practice patient record continues to provide an up-to-date view of care which the patient receives in a GP practice setting.

Other potential usage:

Specialist cardiac rehabilitation nursing
Specialist diabetes nursing
Specialist respiratory practitioners
Specialist heart failure nurse

Universal public health functions

School Nursing

A patient receives medical attention while at school. If the encounter contains clinically relevant information, Send Document should be used to send this information back to the patient’s registered practice so that the registered practice patient record continues to provide an up-to-date view of care which the patient receives in a GP practice setting.

PDF layout

Example wireframe

Field descriptions

Field name	Description	Confidential
`Version [x]`	The version of the consultation report sent.
`Number of related documents`	The number of documents attached to the message - for example, pain-point diagram, ECG, photo. These will be all documents recorded on the GP system that are linked to the consultation.
`Page [x] of [y]`	The page number and total pages of the PDF.
`Patient Name`	The surname, forename(s) and title of the patient. Format all names in the document as follows: `SURNAME <uppercase>, Forename(s), (Title)` This may wrap over multiple lines depending on the length of the name.
`DOB`	The date of birth of the patient in the format: `dd-MMM-yyyy`
`NHS No`	The NHS Number of the patient in the format `### ### ####`
`Tel No`	The patient’s contact telephone number. Format all telephone numbers in the document as follows: `Area Code <space> Local Number [‘x’ Extension Number]` For local numbers with more than six digits include a space before the final four digits.
`Mobile No`	The patient’s contact mobile telephone number.
`Current Tel No`	If the patient is currently staying at a temporary location, the number(s) for contacting the patient at that location. If the patient is not at a temporary location this will be blank and the ‘Current Tel No.’ label will not be shown.
`Home/Registered Address`	The registered address of the patient, presented line by line, including postcode. This may wrap over multiple lines depending on the length of the address.
`Current Address`	If the patient is currently staying at a temporary location, the address of that location. If the patient is not at a temporary location this will be blank and the ‘Current Address’ label will not be shown.
`Clinician`	The full name and role of the treating clinician for the consultation. Where the consultation has been set to confidential the data from the consultation is not displayed.
`Tel No`	The main telephone number of the organisation. Where the consultation has been set to confidential the data from the consultation is not displayed.
`Email`	The main email address of the organisation. Where the consultation has been set to confidential the data from the consultation is not displayed.
`Branch Location`	The name of the branch location, if applicable. Where the consultation has been set to confidential the data from the consultation is not displayed. If Branch Location is not applicable then the label will not be shown.
`Organisation`	The name of the organisation and the town specified in its full address. Where the consultation has been set to confidential the data from the consultation is not displayed.
`Consultation Date`	The date and time of the patient’s appointment at the sending organisation in the format: `dd-MMM-yyyy hh:mm`
`Receiving GP Practice`	The name of the GP practice receiving the consultation report.
`Summary Reason`	A brief description of why the consultation report has been sent to the receiving GP practice entered into the [Summary Reason] section of the PDF document. The text MUST be: `A patient recently consulted with a clinician at an organisation different to the GP practice that they are registered with. The notes contained in this document are a summary of the consultation.`
`Clinical note section title`	The title of the clinical section being displayed.
`[notes]`	All data entered by the clinician at the sending organisation into the `[notes]` section of the PDF document. This includes all free text, clinical/SNOMED CT codes, dm+d codes and any other data entered relating to the consultation. This data must be displayed in a format that matches how the consultation is displayed on screen or when printed. Each section must have a title in bold text. There must be a carriage return after each section to make the document more easy to read. Where the entire consultation has been set to confidential the data from the consultation is not displayed. It is replaced by the text `The details of this consultation have been set as confidential`. Where individual items in the consultation have been set to confidential those items are not displayed and replaced by the text `Confidential item`.
`Follow-up Actions`	A duplicate of any follow-up actions identified during the encounter entered into the `[actions]` section of the PDF document.

Process map

Steps in the process explained

Step 1: Write consultation

Clinician inputs the details of the consultation 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 apatient 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 the 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 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 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 patient activity is not completed when initially saved:

the clinician may not have time to finish the consultation notes 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 consultation notes 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 consultation notes

Step 7: Generate a PDF and metadata

A FHIR message is generated which contains a PDF which contains all the information recorded in the consultation (including free text, clinical coding and other data entered relating to the consultation).

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 consultation

When the PDF is generated, the provider system checks for previous versions of the PDF linked to this consultation.

A previous version will exist if the clinician updates the consultation 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: Consultation Report 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 10001 to 20013)

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 30001 to 30003)

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.

User stories

User story	Description	Acceptance criteria
Send report for correct patient	As a clinician at a practice, I want to send a document containing a patient's consultation notes when the patient is registered at another practice, so that the patient's medical record is kept up to date with a full treatment history.	Sending system the sender system must send a consultation report when the patient in question is registered at another GP practice the sender system must follow the method stated in the specification to determine whether a patient is registered at another GP practice. where the sender system supports an alternative method for communicating the consultation information back to the patient's registered GP practice, this method may be used in the place of GP Connect Messaging (based on local agreement) where an alternative method is used, the GP Connect Messaging requirements do not apply Receiving system Not applicable
Routing the report to the correct practice	As a clinician at a practice, I want the consultation report to be routed to the patient's registered practice, so that the patient's medical record is kept up to date with a full history.	Sending system all consultation reports will use MESH automated message routing in order to ensure that the message is routed correctly to the registered practice of the patient. It is not necessary for the sender system to specify a destination MESH mailbox ID the sender system must specify the patient's NHS Number, Surname and Date of Birth in the message header and use these to populate the Mex-To HTTP header in the MESH endpoint lookup service the sender system must use the allocated MESH Workflow ID associated solely with the GP Connect Send Document capability Receiving system where the message received is for a patient who is not registered at the GP practice, the receiver system must send a response back to the sending GP practice the receiver system must use the allocated MESH Workflow ID associated solely with the GP Connect Send Document capability
Generate PDF and associated metadata	As a clinician at a practice, I want a full and complete record of the consultation to be sent and the data entered into the local record to exactly match what is received at the patient's registered GP practice, so that the patient's medical record is kept up to date with a full history.	Sending system the sender system must include all data entered by the clinician at the originating practice into the 'Clinical notes `[notes]`' section of the PDF document; this includes all free text, clinical / SNOMED CT codes, dm+d codes and any other data entered relating to the consultation the sender system must include in the message all attachments relating to the consultation where the system does not have a concept of a consultation in its architecture, then the sender system will consider all data asserted about the patient for a specified date as part of the same consultation (this follows the same model as GP2GP) the layout and content of the PDF must conform to the template and logical field model contained within this requirements catalogue the version number must be displayed in the PDF in the relevant field and within the Subject of the MESH `.CTL` version 1 is the original report with each subsequent report that relates to the same consultation incrementing by 1 Receiving system Not applicable
Receiving the consultation report	As member of staff at a practice, I want a full and complete report of our patient's consultation when they are receiving care at another practice, so that the patient's medical record is kept up to date with a full history.	Sending system Not applicable Receiving system the receiver system must route consultation reports into the practice workflow and display it as a task the sender system must include in the message all attachments relating to the consultation when displaying the consultation report in the practice workflow/task list, the receiver system must display the Subject from the MESH .CTL file: `Consultation report for [patient-name], NHS Number: [nhs-number], seen at [practice-name], [ods-code], Version: [version-number]` the receiver system must display all data in the same form as supplied by the sender system the receiver system must make any attachments included with the consultation report available to the end user
Alert staff of errors	As a member of the admin staff at the originating practice, I want to be informed when a consultation report is not sent successfully, so that I can take appropriate measures to get the data to the patient's registered practice.	Sending system where a consultation report is not successfully received/managed by the receiver system, the sender system must inform an appropriate person where either the infrastructure or business acknowledgements, or both, are not received for a consultation report, the sender system must inform an appropriate person Receiving system the receiver system must return an error code when the processing of the message is unsuccessful
Report version number	As a clinician at the receiving GP practice, I want to know what version / iteration of the PDF document has been received, so that I am informed of updates to previous consultation reports and to understand that there are earlier versions that can be discarded / updated.	Sending system the sender system must identify if there are multiple consultation report documents sent for a specific consultation and patient. The version number must be displayed within the relevant section of the PDF document and in the subject of the MESH .CTL file in the format: `Consultation report for [patient-name], NHS Number: [nhs-number], seen at [practice-code], [ods-code], Version: [version-number]` version 1 is the original report with each subsequent report that relates to the same consultation incrementing by 1 Receiving system when displaying the consultation report in the practice workflow / task list, the receiving system must display the Subject of the MESH .CTL file in the format: `Consultation report for [patient-name], NHS Number: [nhs-number], seen at [practice-code], [ods-ode], Version: [version-number]`
Send consultation report	As the authoring clinician, I want the system to automate the process of generating and sending the consultation report to the registered practice, so that the consultation report document is sent for 100% of consultations.	Sending system the sender system must send the consultation report a configurable time period after the consultation was created or last updated where a consultation is updated within the configurable time period of the last update, the time delay to sending the consultation report will be from the later update where a consultation is updated after the configurable time period (and therefore the consultation report has already been sent) a new consultation report will be sent (after the configurable time period) each GP practice must be able to set its own a configurable time period where a GP practice has not set its own configurable time period the value will default to three hours Receiving system Not applicable
Patient confidentiality	As a patient, I want to be able to request that the details of the consultation are kept private, so that the data is not shared with someone I do not want to see it.	Note: This is the equivalent of a clinician setting a consultation as confidential and restricting the members of the GP practice who can view the details Sending system the clinician must be able to set a consultation as confidential (or the clinical system's equivalent) the consultation record held at the GP practice is recorded as confidential (or equivalent) and its access restricted to the clinician who made the record where a consultation has been marked as confidential, the message is still sent to the patient's GP practice stating the consultation took place; it will contain no information on what took place in the consultation information on the patient and when the consultation took place are still included information on the clinician and where the consultation took place are not included the clinical notes are replaced by the text 'The details of this consultation have been set as confidential' confidentially is applied on a per consultation basis. A request for confidentiality for one consultation will have no impact on the messages sent for any other consultation Receiving system Not applicable
Local record retention	As a clinician, I want the original record of the consultation recorded on the local system, so that it is available to support ongoing care of the patient and to review if there are any legal or clinical challenges about the care given.	Sending system the sender system must retain a copy of every consultation report that is sent for every consultation where a consultation report is produced, the sender system must retain a copy of the consultation in the format is was originally recorded Receiving system Not applicable
Data-sharing	As a clinician (and the data controller) sending a point-to-point targeted communication, I want sending and receiving the consultation report to not be restricted by any data sharing controls, so that the consultation report document is sent and received for 100% of consultations.	Sending system data sharing controls must not prevent the consultation message being sent Receiving system data sharing controls must not prevent the consultation message being received and made available to the GP practice
Deleted consultation	As a clinician at the originating practice, I want the patient's registered GP practice to be informed if I delete a consultation, so that the patient's medical record is kept up-to-date.	Sending system when a user deletes a consultation where a consultation report has been sent, the sending system must give a warning message to the user the warning message must include the patient name and NHS number, the consultation date and the GP practice the consultation report has been sent to(the patient's registered GP practice) where a consultation is deleted it is the responsibility of the GP practice that recorded the consultation to inform the registered GP practice there is no requirement for the sending system to send an automated message to inform the registered GP practice about the deletion the sending system should assist the GP practice in managing and tracking the process of informing other organisations Receiving system Not applicable