How to identify which documents have been sent
The original v1.x.x
versions of the GP Connect Send Document capability we designed to support a single document type: a Consultation Summary.
Additional use-cases have surfaced since its inception to account for other use-cases, and changes were made in v2.0.0
of the GP Connect Send Document speification to support additional use cases.
The sections below contain guidance for Consumers (receivers) around how to handle payloads using the GP Connect Send Document capability.
MESH workflow ID
The MESH workflow IDs were updated in v2.0.0
to the following:
GPFED_CONSULT_REPORT
was changed toGPCONNECT_SEND_DOCUMENT
GPFED_CONSULT_REPORT_ACK
was changed toGPCONNECT_SEND_DOCUMENT_ACK
Providers of data who have not updated their GP Connect Send Document implementation to support v2.0.0
, will be using the old MESH workflow ID.
GPFED_CONSULT_REPORT*
is a summary of a consultation which took place outside of a citizen's regular GP practice. The NHS are aiming to deprecate this workflow ID by 2024.
GPCONNET_SEND_DOCUMENT*
could be any type of document - including a consultation summary.
FHIR Composition
The GP Connect Send Document capability uses elements contained within the Profile: CareConnect-Composition-1 resource to identify a document, using SNOMED-CT.
Composition.type
A mandatory element used to represent the type of composition being sent using a SNOMED-CT code from the PRSB Document Naming standard (also know as the Clinical Document Indexing standard).
For example:
Composition.extension.careSettingTypeExtension
A required element used to represent the service that is sending the document using a SNOMED-CT code from the FHIR UK Core Care Setting Type valueset.
For example:
Composition.event
An optional element used to represent additional context about the document using a value from SNOMED-CT. The period
element may also be populated.
detail
element.
Extension-ITK-MessageHandling-2.LocalExtension
Previous versions of the GP Connect Send Document specification stated this the LocalExtension
element in the Extension: Extension-ITK-MessageHandling-2 profile must be populated.
Since v2.0.0
, this requirement has been deprecated, and the default value is None
.
It MUST NOT be used to identify the document that has been sent.