GP Connect - Send Document

Release notes

Historical versions and their release notes can be found below, including links to the respective version of the specification.

2.0.1-public-beta

Released on 15th August 2023 THIS VERSION

Link to specification

Changes

Generic example	Example updated to valid FHIR
Profile: ITK-Document-Bundle-1	Guidance around usage of meta.lastUpdated as per HL7 documentation added.
How to handle updates to documents	MESH cannot be used to reliably determine the version number if MESH API is used over the client, this is due to the `version` header not being available in the MESH API.
How to configure MESH	Previous guidance was incorrect and referenced the incorrect headers - this has been resolved a reference link to the MESH documentation has been added. Removed section around MESH and the use of version - while it can be populated, it cannot be reliably used to indicate the current version since the MESH API does not carry a concept of version.

2.0.0-public-beta

Released on 26th August 2022

Link to specification

This is a major release version of the GP Connect Send Document capability and includes changes to the way documents are identified, and cardinality of the Practitioner FHIR resource.

The change will allow any attachment (e.g., PDF / TIFF) to be sent using this capabiltiy, subject to approval by the NHS, and harnesses the potential of SNOMED to:

identify the type of document being sent
the care setting in which the activity took place (if known)
an optional SNOMED code to provide further context about the event

Receivers (consumers)

Receiving systems need to be updated to accordingly to:

Identify payloads using Composition.type rather than MESH workflow ID and the LocalExtension in Extension-ITK-MessageHandling-2
Take note of the SNOMED codes within care setting and event information within the required Composition.extension:careSettingType and optional Composition.event and present alongside the attached PDF in the patient record
Update their implementation to start receiving on the new MESH workflow ID - while also supporting the legacy workflow ID in the short-term to allow providers (senders) to update their implementation
The RecipientType element (i.e. 'For Action' and 'For Information') to be checked to ensure that is is visible for GP Practice users to allow identification of cases that they may wish to prioritise. Ideally it would also be possible to sort or filter by the 'For Action' or 'For Information' flag.

Senders (providers)

Once the receiving systems are capable of supporting this version of GP Connect Send Document, sending systems will need to be updated accordingly to:

Use the new MESH workflow ID
Ensure the correct SNOMED code is being used within Composition.type
Provide additional information if known / necessary within Composition.extension:careSettingType and Composition.event

Changes

Updated MESH workflow ID	updated workflow IDs to be generic, allowing for multiple use-cases of the GP Connect Send Document capability updated `GPFED_CONSULT_REPORT` to `GPCONNECT_SEND_DOCUMENT` updated `GPFED_CONSULT_REPORT_ACK` to `GPCONNECT_SEND_DOCUMENT_ACK`
Updated usage for `CareConnect-Practitioner-1` to Required	some upcoming use-cases do not have an interaction with a healthcare professional, and as such the usage has been downgraded from to
Updated guidance on `CareConnect-Composition-1`	added clarification for the `text` element the `extension(careSettingTypeExtension)` is now a required element the `event` element now has guidance in relation to which SNOMED codes can be used
`LocalExtension` usage within `Extension-ITK-MessageHandling-2` deprecated	the value of this element has changed from `SendDocument-ConsultationSummary` to `None` this element must not be used for the purpose of document identification
Added guidance around handling different use-cases (document types)	this version supports multiple use-cases and guidance has been added to help identify them, as well as how to handle legacy (`v1.x`) payloads of GP Connect Send Document

1.3.2-public-beta

Released on 25th May 2022 CURRENT VERSION

Link to specification

Important: This version has moved from private-beta to public-beta.

The GP Connect Send Document 1.3.2-public-beta release in which the documentation has been migrated from the developer network to the Firely Simplifier platform.

The guidance has been adjusted to focus on the Send Document capability, rather than a specific use case for a Consultation Summary Report.

This includes expanded guidance on how to populate FHIR resources, details of which can be found below.

Changes

References to 1.4.0 and 1.5.x private-betas	both versions hosted, previously hosted on the NHS developer network, have now been removed
ITK3 Message Distribution standard	requirement to support version 2.9.0 from 2.5.0
All FHIR resources	clarified which elements are in UK Core vs CareConnect
ITK-Message-Bundle-1	clarified which elements should be populated along with examples
ITK-MessageHeader-2	clarified which elements should be populated along with examples `receiver` can optionally be used `response` can optionally be used
Extension-ITK-MessageHandling-2	clarification and guidance regarding this resource, along with examples relaxed the requirements for `extension(LocalExtension)` to allow for any string
CareConnect-ITK-Header-Organization-1	clarified which elements should be populated along with examples
ITK-Document-Bundle-1	added optional support for replacement documents by including the version of the document within `meta.versionId` clarified which elements of the profile should be used, along with examples - in particular around the `entry` element
CareConnect-Composition-1	clarified which elements should be populated, along with examples `extension(careSettingTypeExtension)` can optionally be used `class` can optionally be used (it is not required and not in UK Core) `encounter` can optionally be used `attester` can optionally be used `event` can optionally be used expanded guidance on `status` and the possible values that could be contained within the code system expanded guidance on `type` as multiple SNOMED codes can be used and mandated that this value MUST be used to identify the type of document being received, rather than the value provided in the MESH workflow ID, or `LocalExtension` value within the `Extension-ITK-MessageHandling-2` resource
CareConnect-Patient-1	clarified which elements should be populated, along with examples `extension(ethnicCategory)` can optionally be used `extension(religiousAffiliation)` can optionally be used `extension(patient-cadavericDonor)` can optionally be used `extension(residentialStatus)` can optionally be used `extension(treatmentCategory)` can optionally be used `extension(nhsCommunication)` can optionally be used `extension(birthPlace)` can optionally be used `extension(nominatedPharmacy)` can optionally be used `extension(deathNotificationStatus)` can optionally be used `active` can optionally be used `telecom` can optionally be used `gender` can optionally be used `address` can optionally be used `maritalStatus` can optionally be used `multipleBirth` can optionally be used `photo` can optionally be used `contact` can optionally be used `generalPractitioner` can optionally be used `managingOrganization` can optionally be used `link` can optionally be used
CareConnect-Practitioner-1	clarified which elements should be populated, along with examples `extension(nhsCommunication)` can optionally be used `active` can optionally be used `address` can optionally be used `gender` can optionally be used `birthDate` can optionally be used `photo` can optionally be used `qualification` can optionally be used
CareConnect-Organization-1	clarified which elements should be populated, along with examples `extension(mainLocation)` can optionally be used `extension(organization-period)` can optionally be used `active` can optionally be used `type` can optionally be used `alias` can optionally be used `address` can optionally be used `partOf` can optionally be used `contact` can optionally be used `endpoint` can optionally be used
ITK-Attachment-Binary-1	clarification and guidance regarding MIME types, available extensions - along with examples
OperationOutcome	added clarification and guidance regarding this resource, along with examples
Use case: Consultation summary report	new page to consolidate multiple pages in the previous specification - this is to support the specification being a "Send Document" capability, rather than use case specific
How to configure MESH	clarification around using the element in the MESH configuration
How to handle updates to documents	clarification around terminology (replacement) clarification on how to use version number reference to the `CareConnect-Composition-1.meta.versionId`
Examples	examples updated
Use-case guidance	a seperate guide has been created for individual use-cases - this includes the existing Consultation Summary use-case

1.3.1-private-beta

Released on 25th August 2021

Link to specification

The GP Connect Messaging 1.3.1-private-beta release is a patch release including:

additional requirements to support sending LocalID when using MESH

Changes

MESH message configuration

GPCM-SD-145 added - LocalID MUST contain the ODS code of the sending organisation
GPCM-SD-146 added - Mex-Localid MUST contain the ODS code of the sending organisation

1.3.0-private-beta

Released on 30th April 2021

This is a patch release including:

payload alignment with the Transfer of Care and Digital Medications programmes
the Task and DocumentReference resources have been dropped from the capability
the CareConnect-Composition base resource is being used as a wrapper for the consultation report PDF
the ITK-Payload-Bundle has been replaced with ITK-Document-Bundle resource
the use case to send the consultation report within federations has been removed, and has been - replaced with a more generic Send Consultation Report use case
the receiver-side validation requirements from the error handling page have been removed
Document Replacement page has been added to describe how messages should be re-sent/replaced if necessary
requirement GPCM-SD-108 has been added to support mandatory population the meta element in profiles being utilised
requirements to trigger when a consultation should be sent have been simplified
requirements added to support confidential items being sent in PDF
requirement added to support consultations being deleted at the sending practice
the response messages example have been fixed
any broken links have been addressed

Changes

Send Document - payload structure	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 and GPCM-SD-079 have been removed these requirements have been replaced by GPCM-SD-103, GPCM-SD-104, GPCM-SD-105, GPCM-SD-106, GPCM-SD-107, GPCM-SD-109, GPCM-SD-110, GPCM-SD-111 and GPCM-SD-112 requirement GPCM-SD-108 has been added to make meta mandatory across all resources
Document replacement	new page added describing document replacement requirements GPCM-SD-126, GPCM-SD-127, GPCM-SD-128, GPCM-SD-129, GPCM-SD-130, GPCM-SD-131 and GPCM-SD-132
Error handling	requirements GPCM-SD-067, GPCM-SD-068, GPCM-SD-069, GPCM-SD-070, GPCM-SD-071, GPCM-SD-072, and GPCM-SD-073 have been removed
User stories	uplifted to remove references to "federations" uplifted the requirements listed against each user story based on the removal/addition of requirements GPC-SD11 and GPC-SD12 have been added to support confidential items and consultation deletion
Payload requirements	requirements 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-078, GPCM-SD-080, GPCM-SD-081, GPCM-SD-082, GPCM-SD-092, GPCM-SD-093 and GPCM-SD-027 have been removed these requirements have been replaced by GPCM-SD-113, GPCM-SD-114, GPCM-SD-115, GPCM-SD-116, GPCM-SD-117, GPCM-SD-118, GPCM-SD-119, GPCM-SD-120, GPCM-SD-121, GPCM-SD-122, GPCM-SD-123, GPCM-SD-124 and GPCM-SD-125
Triggering message creation	requirements GPCM-SD-085, GPCM-SD-097, GPCM-SD-098, GPCM-SD-099, GPCM-SD-100 and GPCM-SD-101 have been removed requirement GPCM-SD-096 has been reworded to state that the consultation report must been sent within 3 hours of creation GPCM-SD-135 has been added to support deleted consultations
Message example	example uplifted to represent all the resource changes made to align the capability
ITK3 header requirements	GPCM-SD-055 updated to - Timestamp MUST contain the date/time when the response was generated
PDF layout	requirements GPCM-SD-133 and GPCM-SD-134 have been added to support confidential items being sent in the PDF, where supported by the local system the description for `Clinical notes` has been updated
Requirements list	Page added to list all requirements in the specification
PDF layout - following review	Updates following provider review date format changed from `dd-mmm-yyyy hh:mm` to `DD-Mmm-YYYY hh:mm` additional information added for the populations of `Surname`, `Forename` and `Current Tel No` `Registered Address` renamed to `Home/Registered Address` `Date seen` renamed to `Date of consultation` `Date consultation sent` renamed to `Date consultation letter sent` `Current Tel` updated to `Current Tel No` `Tel No.` and `Current Tel` have been moved to the right of `Home Address` and `Current Address` `Date of consultation` and `Date of letter` have been moved to the bottom of their section, below `Place of consultation` `Place of consultation` updated to contain the full address `Surgery Tel No.` updated to `Consultation Surgery Tel No.` `Surgery Email` updated to `Consultation Surgery Email` Blue colour used on template has been updated to NHS blue Updates following first of type review Multiple field names have been updated and moved (please ensure all field names and locations match the PDF template) Section header font sizes and background colours have been updated (please ensure all header sections match the PDF template) `Gender` has been removed `Date consultation letter` sent has been removed `Mobile No` has been added `Consulting Organisation` section title has been added to reduce wording of other fields associated with the consulting organisation `Branch Location` has been added `Receiving GP Practice` has been added `Summary Reason` has been added to support a brief description of why the summary PDF has been sent `Follow-up Actions` has been added to highlight any required follow-up actions being suggested by the sending organisation Requirement GPCM-SD-136 added - all titles in Clinical Notes [notes] area are formatted as bold Requirement GPCM-SD-137 added - all sections in Clinical Notes [notes] area have a carriage space between them Requirement GPCM-SD-138 added - Clinical note section titles and Clinical Notes are tab separated Requirement GPCM-SD-139 added - patient name must be in a larger font for quick easy reading Requirement GPCM-SD-143 added - NHS colours must be utilised as per the PDF template Requirement GPCM-SD-144 added - Summary Reason text
Triggering message creation	Updates following first of type review Requirement GPCM-SD-140 added - only clinically relevant encounters are sent Requirement GPCM-SD-141 added - configurable control is in place as a final check that the user wants to send the document

1.2.0-private-beta

Released on 4th February 2019

Link to specification

The GP Connect Messaging 1.2.0 release is a minor release including:

workflow IDs added for GPFED_CONSULT_REPORT and GPFED_CONSULT_REPORT_ACK
statement added to for sending and receiving practice operating the same GP principal system
improved requirements layout; splitting user stories, PDF layout, process map and clinical engagement into separate pages

Changes

Send Consultation Report - MESH message configuration	workflow IDs added
Design principles	`Task` and `DocumentReference` profiles
Design principles	Business requirements
Send Consultation Report - PDF layout	PDF format

1.1.0-private-beta

Released on 21st September 2018

Link to specification

The GP Connect Messaging 1.1.0 release is a minor release including:

Task resource is profiled to https://fhir.nhs.uk/STU3/StructureDefinition/GPConnect-Task-1
DocumentReference is profiled to https://fhir.nhs.uk/STU3/StructureDefinition/GPConnect-DocumentReference-1
High level business requirements regarding the Send Consultation Report use case
Details of the format of the PDF to be included in the Send Consultation Report payload

Changes

Send Consultation Report - Payload requirement	`Task` and `DocumentReference` profiles
Send Document - payload structure	`Task` and `DocumentReference` profiles
Send Consultation Report - example message	Updated example message
Send Consultation Report - Business Requirements	Business requirements added
Send Consultation Report - PDF layout	PDF format

1.0.0-private-beta

Released on 31st August 2018

Link to specification

The GP Connect Messaging 1.0.0 release aligns with information shared with GP System suppliers for the GP Connect use case “Send Consultation Report”.

This initial release builds on this information and provides some additional clarification.

Changes

Priority capabilities for GP Connect Messaging	Introducing the Send Document capability and future roadmap capabilities
Design principles	Outlines the context of the GP Connect Messaging capabilities
Send Document - payload structure	Details of how binary documents are included in the payload
Send Consultation Report - payload requirement	Changes to fixed values required in the `Task` resource
Send Consultation Report - ITK3 requirement	Removal of the Priority handling key Addition of `LocalExtension` handling key set to fixed value
Send Consultation Report - MESH requirements	Changes to fixed values required MESH configuration - Subject
Send Consultation Report - error handling	Details provided for handling MESH automated message routing error conditions