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 |
