GP Connect - Send Document

Part of the GP Connect product family

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 relatesTo element within CareConnect-GPC-Composition-1 MUST be populated with the code of replaces and the targetIdentifier containing the ID of the payload it is replacing
  • the version SHOULD be included in the CareConnect-GPC-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 payloads SHOULD be sent within 24 hours of the original payload
  • the sender may wish to contact the receiving practice to notify them of the change

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