GP Connect Send Document

This guidance is under active development by NHS Digital and content may be added or updated on a regular basis.
This version of GP Connect Send Document supports one use-case which is a Consultation Summary (PDF).
Additional use-cases are expected to be supported in 2023.

How to handle updates to documents

Note: In FHIR, the terminology to update a document is known as a replacement.

The Send Document capability allows for the updating of a previously sent document.

This replacement is at a whole document level, in that the original document is replaced by a new one and the old document is only kept for audit purposes.

A sender may choose to send a new replacement document for several reasons, for example:

  • the original document contained an error, identified after the document was sent
  • the sender has more up-to-date or complete information - for example, the original is correct but further information is now available to make the document more complete or detailed
  • receivers of updated versions of documents MUST process the updated document and archive the previous one

FHIR elements used for replacement

The elements in the resources below can be used to indicate that a replacement document has been received:

  • Composition.meta.versionId
  • Composition.status
  • Composition.relatesTo.code
  • Composition.relateTo.targetIdentifier

Read more on how to populate these elements:

Replacement guidance

  • the initial version MUST be 1 and subsequent versions MUST increment by 1
  • the version MUST be included in the MESH .CTL file or MESH API configuration
  • the version SHOULD be included in the CareConnect-Composition-1 resource in meta.versionId
  • replacements MAY be done more than once and the new document always refers to the previous document
  • multiple replacements SHOULD be avoided where possible due to complexity of maintaining the audit trail
  • replacement documents SHOULD be sent within 24 hours of the original document

When the new document cannot be processed

  • the receiver of the new document SHOULD mark the original and replacement as null and void
  • an error SHOULD be reported to the sender using the ITK response message and appropriate code - see ITK3 response codes for more information
  • the sender of the new document SHOULD mark the original and replacement document as null and void if it receives an ITK3 response indicating that the replacement could not be processed
back to top