Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

Document Replacement

Document replacement semantics for Send Document

The Send Document capability allows for the replacement 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 a number of reasons, for example:

  • the original document contained an error - identified after the document sent
  • the sender has more up-to-date or complete information - the original is correct but further information is now available to make the document more complete or detailed
GPCM-SD-126 Receivers of replacement documents MUST process the replacement document and archive the replaced document

When the new document cannot be processed then:

GPCM-SD-127 the receiver of the new document SHOULD mark the original and replacement document as null and void and report a error to the sender using the ITK Response message and appropriate code see ITK3 response codes for further information
GPCM-SD-128 the sender of the new document SHOULD mark the original and replacement document as null and void once it receives the ITK3 Response indicating that the replacement document could not be processed

Replacement guidance:

GPCM-SD-129 replacements MAY be done more than once and the new document always refers to the previous document, multiple replacements SHOULD be avoided due to complexity of maintaining the audit trail
GPCM-SD-130 replacement documents SHOULD be sent within 24 hours of the original document

FHIR® elements used for replacement:

GPCM-SD-131 Composition.relatesTo.code MUST contain the fixed value replaces
GPCM-SD-132 Composition.relatesTo.targetIdentifier MUST contain the identifier of the old document - UUID of original document
Tags: mesh

All content is available under the Open Government Licence v3.0, except where otherwise stated