Purpose
The purpose of this page is to document the user stories that apply across all of GP Connect Send Document capability. To avoid duplication links to the requirements within the specification have be provided where applicable.
User stories
Send report for correct patient
ID: GPC-SD01 |
Source: Process 4.1 |
Description
As a clinician at the federated practice...
I want to send a document containing a patient's consultation notes when the patient is registered at another practice within my GP federation...
so that the patient's medical record is kept up to date with a full treatment history.
Acceptance criteria - sender
- the sender system must send a federated consultation report when the patient in question is registered at another GP practice within the federation (or group of GP practices working together to deliver a service)
- the sender system must follow the method stated in the specification to determine whether a patient is registered at another GP practice within the same federation. Details can be found here
- if the sender system determines the registered practice is outside the GP federation (or group of GP practices), no federated consultation report is sent and usual business processes should be followed
- 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
Acceptance criteria - receiver
N/ALinked requirements
Supporting technical requirements
GPCM-SD-001 GPCM-SD-002 GPCM-SD-003 GPCM-SD-004 GPCM-SD-005 GPCM-SD-006 GPCM-SD-007 GPCM-SD-008 GPCM-SD-009 GPCM-SD-010 GPCM-SD-011 GPCM-SD-012 GPCM-SD-013 GPCM-SD-014 GPCM-SD-015 GPCM-SD-016 GPCM-SD-017 GPCM-SD-018 GPCM-SD-019 GPCM-SD-020 GPCM-SD-021 GPCM-SD-022 GPCM-SD-023 GPCM-SD-024 GPCM-SD-025 GPCM-SD-026 GPCM-SD-027 GPCM-SD-028 GPCM-SD-029 GPCM-SD-030 GPCM-SD-031 GPCM-SD-032 GPCM-SD-033 GPCM-SD-034 GPCM-SD-035 GPCM-SD-036 GPCM-SD-037 GPCM-SD-038 GPCM-SD-078 GPCM-SD-079 GPCM-SD-080 GPCM-SD-081 GPCM-SD-082 GPCM-SD-092 GPCM-SD-093
Routing the report to the correct practice
ID: GPC-SD02 |
Source: Process 4.1 |
Description
As a clinician...
I want the federated 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.
Acceptance criteria - sender
- all federated 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
Acceptance criteria - receiver
- 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
Linked requirements
GPCM-SD-018 GPCM-SD-056 GPCM-SD-057 GPCM-SD-058 GPCM-C-01 GPCM-C-02
Supporting technical requirements
GPCM-SD-039 GPCM-SD-040 GPCM-SD-041 GPCM-SD-042 GPCM-SD-043 GPCM-SD-044 GPCM-SD-045 GPCM-SD-046 GPCM-SD-047 GPCM-SD-048 GPCM-SD-049 GPCM-SD-050 GPCM-SD-051 GPCM-SD-052 GPCM-SD-053 GPCM-SD-054 GPCM-SD-055 GPCM-SD-059 GPCM-SD-060 GPCM-SD-061 GPCM-SD-062 GPCM-SD-063 GPCM-SD-064
Generate PDF and associated metadata
ID: GPC-SD03 |
Source: Process 4.1 |
Description
As a clinician...
I want a full and complete record of the consultation to be sent and the data entered in to 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.
Acceptance criteria - sender
- the sender system must include all data entered by the clinician at the federated 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 file
- version 1 is the original report with each subsequent report that relates to the same consultation incrementing by 1
Acceptance criteria - receiver
N/ALinked requirements
GPCM-SD-086 GPCM-SD-087 GPCM-SD-088 GPCM-SD-089 GPCM-SD-090 GPCM-SD-091
Supporting technical requirements
GPCM-SD-024 GPCM-SD-025 GPCM-SD-026 GPCM-SD-027 GPCM-SD-078 GPCM-SD-080 GPCM-SD-081 GPCM-SD-082
Receiving the federated consultation report
ID: GPC-SD04 |
Source: Process 4.1 |
Description
As a member of staff at the registered practice...
I want a full and complete report of our patient's consultation when they are receiving care at another practice in our GP federation...
so that the patient's medical record is kept up to date with a full history.
Acceptance criteria - sender
N/AAcceptance criteria - receiver
- the receiver system must route federated consultation reports into the practice workflow and display it as a task
- when displaying the federated consultation report in the practice workflow/task list, the receiver system must display the Subject from the MESH .CTL file: "Federated 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 federated consultation report available to the end user
Linked requirements
Supporting technical requirements
Alert staff of errors
ID: GPC-SD05 |
Source: Process 4.1 |
Description
As a member of the admin staff at the federated practice...
I want to be informed when a federated consultation report is not sent successfully...
so that I can take appropriate measures to get the data to the patient's registered practice.
Acceptance criteria - sender
- where a federated 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 federated consultation report, the sender system must inform an appropriate person
Acceptance criteria - receiver
- the receiver system must return an error code when the processing of the message is unsuccessful
Linked requirements
Supporting technical requirements
GPCM-SD-065 GPCM-SD-066 GPCM-SD-067 GPCM-SD-068 GPCM-SD-069 GPCM-SD-070 GPCM-SD-071 GPCM-SD-072 GPCM-SD-073 GPCM-SD-074 GPCM-SD-075
Report version number
ID: GPC-SD06 |
Source: Process 4.1 |
Description
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 federated consultation reports and to understand that there are earlier versions that can be discarded/updated.
Acceptance criteria - sender
- the sender system must identify if there are multiple federated 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 "Federated 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
Acceptance criteria - receiver
- when displaying the federated consultation report in the practice workflow/task list, the receiving system must display the Subject of the MESH .CTL file in the format "Federated consultation report for {patient name}, NHS Number {NHS Number}, seen at {Practice code}, {ODS Code}, Version {Version Number}"
Linked requirements
Supporting technical requirements
Send federated consultation report
ID: GPC-SD07 |
Source: Process 4.1 |
Description
As the authoring clinician...
I want the system to automate the process of generating and sending the federated consultation report to the registered practice...
so that the federated consultation report document is sent for 100% of federated consultations.
Acceptance criteria - sender
- the sender system must send the federated 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
Acceptance criteria - receiver
N/ALinked requirements
Supporting technical requirements
Patient confidentiality
ID: GPC-SD08 |
Source: Process 4.1 |
Description
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.
Acceptance criteria - sender
- the clinician must be able to set a consultation as confidential (or the clinical system's equivalent)
- the consultation record held at the federated 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
Acceptance criteria - receiver
N/ANotes
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
Linked requirements
Supporting technical requirements
Local record retention
ID: GPC-SD09 |
Source: Process 4.1 |
Description
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.
Acceptance criteria - sender
- 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
Acceptance criteria - receiver
N/ASupporting technical requirements
Data sharing
ID: GPC-SD10 |
Source: Process 4.1 |
Description
As a clinician (and 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 federated consultation report document is sent and received for 100% of federated consultations.
Acceptance criteria - sender
- data sharing controls must not prevent the consultation message being sent
Acceptance criteria - receiver
- data sharing controls must not prevent the consultation message being received and made available to the GP practice
Linked requirements
Supporting technical requirements