Note: This has been superceded by the Send Document v2.0.0 specification
Consultation summary
Note: The tables below outline the specific requirements for the Consultation summary use-case using GP Connect Send Document.
Sender
The following table outlines what the sender (or provider) needs to provide for the Consultation summary report use case of GP Connect Send Document.
| Reference | Guidance | Description |
|---|---|---|
| GPCM-SD-044 | Extension: Extension-ITK-MessageHandling-2 | The payload MUST contain a FHIR Extension-ITK-MessageHandling-2 resource populated with a fixed value of SendDocument-ConsultationReport within the LocalExtension element |
| GPCM-SD-056 | Using MESH | All messages sent for this use-case MUST use MESH automated message routing to ensure that the message is correctly routed to the citizen's registered practice |
| GPCM-SD-057 | How to configure MESH | Each instance of a Send Consultation Report message MUST include the following MESH Workflow ID in the MESH message metadata: GPFED_CONSULT_REPORT |
| GPCM-SD-076 | Consultation summary | "Send Consultation Report" messages MUST be sent for 100% of practice encounters to ensure that the registered practice care record is an accurate statement of care delivered in a primary care setting |
| GPCM-SD-077 | Consultation summary | The "Send Consultation Report" send facility MUST be implemented in such a way as to minimise administrative burden on the practice |
| GPCM-SD-083 | Consultation summary | If the patient registration type of the patient record at the appointment hosting practice is Regular (GMS/PMS), then the registered practice care record is already up-to-date, and a message MUST NOT be sent |
| GPCM-SD-084 | Consultation summary | A PDS lookup of the patient MUST be performed to determine the ODS code of the registered practice of the patient |
| GPCM-SD-086 | Consultation summary | The provider system MUST include all data entered by the clinician at the sender 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 |
| GPCM-SD-087 | Consultation summary | All data MUST be displayed in a format that matches how the consultation is displayed on screen or when printed |
| GPCM-SD-088 | Consultation summary | The provider system MUST include in the message all attachments relating to the consultation |
| GPCM-SD-089 | Consultation summary | Where the system does not have a concept of a consultation in its architecture, then the provider system MUST consider all data asserted about the patient for a specified date as part of the same consultation (this follows the same model as GP2GP) |
| GPCM-SD-090 | Consultation summary | The layout and content of the PDF MUST conform to the template and logical field model outlined within the Consultation Summary report wireframe |
| GPCM-SD-091 | Consultation summary | The version number MUST be displayed in the PDF in the relevant field and within the Subject of the MESH .CTL file |
| GPCM-SD-092 | Consultation summary | When displaying the Consultation Report in the practice workflow/task list, the message receiver SHOULD display the Subject contained in the MESH .CTL file:Consultation report for [patient-name], NHS Number: [nhs-number], seen at [location-name], [ods-code], Version: [version-number]Important: These items MUST NOT be displayed if the consultation has been flagged as confidential. |
| GPCM-SD-094 | Consultation summary | Where a consultation report is not successfully received/managed by the message receiver, the sender system MUST inform an appropriate person/team |
| GPCM-SD-095 | Consultation summary | Where either the infrastructure or business acknowledgements, or both, are not received for a consultation report, the sender system MUST inform an appropriate person/team |
| GPCM-SD-096 | Consultation summary | The message sender system MUST send the consultation report within 3 hours after the consultation was created, or last updated |
| GPCM-SD-102 | Consultation summary | If the patient has requested that the consultation is confidential then the following data items MUST NOT be sent in the PDF:
|
| GPCM-SD-113 | Profile: CareConnect-Composition-1 | The payload MUST contain a FHIR CareConnect-Composition-1 resource |
| GPCM-SD-114 | Profile: CareConnect-Composition-1 | The payload MUST contain a FHIR CareConnect-Composition-1 resource populated with a fixed value of final within the status elementNote: Updated documents may need to use the status of amended. |
| GPCM-SD-115 | Profile: CareConnect-Composition-1 | The payload MUST contain a FHIR CareConnect-Composition-1 resource, populated with a fixed SNOMED code with the value: 371531000 (Report of clinical encounter) |
| GPCM-SD-116 | Profile: CareConnect-Composition-1 | The payload MUST contain a FHIR CareConnect-Composition-1 resource, populated with the date and time that the message was created within the date element |
| GPCM-SD-117 | Profile: CareConnect-Composition-1 | The payload MUST contain a FHIR CareConnect-Composition-1 resource, populated with either the value N (normal) or R (restricted) within the confidentiality element |
| GPCM-SD-118 | Profile: CareConnect-Composition-1 | The payload MUST contain a FHIR CareConnect-Composition-1 resource, populated with a fixed value of Consultation report in the title element |
| GPCM-SD-119 | Profile: CareConnect-Composition-1 | The payload MUST contain a FHIR CareConnect-Composition-1 resource, populated with a summary of the consultation report within the text element (as outlined below)Consultation report for [patient-name], NHS Number: [nhs-number], seen at [location-name]*, [ods-code]*, Version: [version-number]Items marked with * MUST NOT be sent if the consultation is confidential (for example, where Composition.confidentiality has the value R. |
| GPCM-SD-120 | Profile: CareConnect-Composition-1 | Profile: CareConnect-Patient-1 | The payload MUST contain a FHIR CareConnect-Composition-1 resource, populated with a reference to a CareConnect-Patient-1 resource in the subject element |
| GPCM-SD-121 | Profile: CareConnect-Composition-1 | Profile: CareConnect-Patient-1 | The payload MUST contain a FHIR CareConnect-Composition-1 resource, populated with a reference to a CareConnect-Practitioner-1 resource in the author element |
| GPCM-SD-122 | Profile: CareConnect-Composition-1 | Profile: CareConnect-Organization-1 | The payload MUST contain a FHIR CareConnect-Composition-1 resource, populated with a reference to a CareConnect-Organization-1 resource in the custodian element |
| GPCM-SD-124 | Profile: CareConnect-Composition-1 | The payload MUST contain a FHIR CareConnect-Composition-1 resource, populated with a reference to the consultation report PDF in the section.entry element |
| GPCM-SD-128 | Consultation summary | The sender of the new document SHOULD mark the original and any replacement documents prior to the new document, as null and void and report a error to the sender using the ITK Response message and appropriate code see ITK3 response codesfor further information |
| GPCM-SD-129 | Consultation summary | Replacement documents MAY be done more than once and the new document always refers to the previous document, multiple replacements SHOULD be avoided due to complexity of maintaining the audit trail |
| GPCM-SD-130 | Consultation summary | Replacement documents SHOULD be sent within 24 hours of the original document |
| GPCM-SD-133 | Consultation summary | If the local system supports setting individual data items as confidential, then each item flagged as confidential MUST contain the warning text: Confidential item when sent in the consultation report |
| GPCM-SD-134 | Consultation summary | If multiple data items are flagged as confidential, the warning text: Confidential item MUST be repeated for each item |
Receiver
The following table outlines what the receiver (or consumer) needs to return to the sender (or provider) in the form of an ITK3 response header or FHIR ITK-Response-OperationOutcome-1 resource.
| Reference | Guidance | Description |
|---|---|---|
| GPCM-SD-058 | How to configure MESH | Each instance of an acknowledgement message generated as a result of receipt of a Send Consultation Report message MUST include the following Workflow ID in the MESH message metadata: GPFED_CONSULT_REPORT_ACK |
| GPCM-SD-093 | Consultation summary | The message receiver MUST make any attachments included with the Consultation Report available to the end user |
| GPCM-SD-125 | Consultation summary | Where binary documents are included in the payload in addition to the Consultation Report, the message receiver MUST process these accordingly, ensuring all attachments remain in the context of the encounter information delivered to downstream systems |
| GPCM-SD-126 | Consultation summary | Receivers of replacement documents MUST process the replacement document and archive the replaced document |
| GPCM-SD-127 | Consultation summary | The receiver of a replacement document SHOULD mark the original and any replacement documents prior to the new document as null and void and report an error to the sender using the ITK Response message and appropriate code see ITK3 response codes for further information |