GP Connect - Send Document

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.

gpc-send-doc-identification

Note: A full list of changes for version 2.0.0 of the GP Connect Send Document Specification can be found in the release notes.

The sections below contain guidance for Consumers (receivers) around how to handle payloads using the GP Connect Send Document capability.

Confidentiality

Confidential items contain information the patient has asked not to be shared.

Under previous versions of the spec, confidential items would be redacted but a notification still sent, with Composition.confidentiality set to value R (Restricted).
Ideally the patient's intent in relation to why the document is restricted should be captured in consultation notes.
Despite all this, in some scenarios ingestion of the Send Document message could still result in accidental disclosure of confidential information via the context and SNOMED coding. Therefore the following guidance has been included to mitigate the risk of disclosure.

For Senders:
Confidential items should NOT be sent via Send Document.

For Receivers:
Although confidential information should not be sent, it is still possible a receiving system could receive such a transmission.
If the value of Composition.confidentiality is R, the document should be rejected by the receiving system. Upon rejection, an ITK response code 20009 (Payload content validation failure) should be sent back to the sending system.

MESH workflow ID

The MESH workflow IDs were updated in v2.0.0 to the following:

GPFED_CONSULT_REPORT was changed to GPCONNECT_SEND_DOCUMENT
GPFED_CONSULT_REPORT_ACK was changed to GPCONNECT_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.

Note: The ONLY use-case for this messages sent using a MESH workflow ID starting with 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.

Warning: Messages sent to the new worklow ID GPCONNECT_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:

734163000 | Care plan (record artifact) |

`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:

789718008 | Cardiology service (qualifier value) |

`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.

Note: A use-case has not been identifier for populating the 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.