Why does IHE-XDS not have a Delete Document?

This also applies to IHE: MHD, MHDS, XDS, and XCA. To some extent it applies to normal use of FHIR R4 DocumentReference

The IHE Document Sharing model is focused on document lifecycle, and thus supports Create, Append, Transform, Replace, and Signs of a document. When an existing document is replaced with a new document, the Replace action is used. This marks the old document as superseded and the new document points to the old document (in XDS the Association Object is bidirectional, but in FHIR the new document points at the old). Thus, when someone finds the document they have, they can see that it has been replaced.

This is a well understood model when one thinks about a clinical document. That clinical document may have various revisions, each replacing the prior document. With a clinical document the final version is left available forever (or for as long as the legal persistence policy identifies). This is the typical lifecycle, that is that eventually one gets to a final version of the document.

However, there are some documents that need to be deleted / removed / revoked / deprecated / etc. Some examples:

• Basic Patient Privacy Consent -- when the consent is revoked by the patient
• Advanced Directives -- when the advanced directive is revoked by the patient
• Entered in Error -- when a document gets incorrectly registered, and needs to be removed because of this error

With only Replace, these needs seem to be unachievable in XDS/MHDS.

Native FHIR R4

In FHIR R4 DocumentReference one can set the status to entered-in-error, but there are two very important considerations

1. This status is not supported in XDS, so it is not going to interact properly with any exchange that uses IHE Document Sharing. I will cover this later in the section on Just delete it.
2. This status does not include any evidence for why the document is marked as entered-in-error.  Meaning that there is often a need to explain why it was marked as entered-in-error. 
3. The status of entered-in-error is reasonable when a mistake was made. But the first two use-cases are cases where the original publication was not an error, the change is to indicate removal.

In FHIR R4 DocumentReference one can set the status to superseded, but there are is an implication that it has been superseded by another DocumentReference. This is not a requirement, so it is not a problem.

One could use an extension in FHIR DocumentReference that can carry a more refined status code... but that is not going to guarantee that everyone understands it... And those extensions will not be understood by IHE Document Sharing transports. Most important is that the .status codes in the Event pattern does not have a 'deleted' status.

Just delete it

FHIR Resources can be deleted, provided policy allows. A Deleted resource can be handled in multiple ways. If the FHIR Server supports versions, it can mark the version as deleted in a way that one could retrieve the deleted resources. 

XDS does have some methods available for document delete - Remove Metadata and Documents (RMD). The problem with delete in XDS is similar in that it does not convey the deletion to those that might have used it before, and certainly doesn't understand why it was deleted.

Document Sharing -- Recommended Approach

In Document Sharing, one would Replace the current document with a new document. The new document likely will be a brief summary of why the document was revoked or replaced. This kind of a flavor of the document would need to be profiled anyway to support the use-cases.

The new document could be an empty document, provided the policy allows that. 

The new document metadata could be either

1. A variation of the original document, so that it is discoverable in the same way the original is discoverable
2. Very different metadata that clearly indicates deletion. 
3. A variation of original content to support some discoverability, but also clear indication of the deletion.

So, how can the Metadata (e.g. DocumentReference) look like to indicate to everyone that might have pulled the previous document?  Well, realistically the fact that the previous document was Replaced, is the signal to any previous uses of the previous document. 

But, should the Metadata (e.g. DocumentReference) be good to have an indication that the previous has been rejected and that there is no new content. Meaning, a way to send a terminal signal using just the Metadata?

• In pure FHIR, the DocumentReference.docStatus  could indicate this, especially in newer versions of FHIR (given that FHIR R4 has a very limited vocabulary on docStatus).
• However, this element is profiled out of IHE Document Sharing
• The DocumentReference.type or .category could be different to indicate this is a Terminal document; but this might make it harder to find. So likely these should be the same as the original.
• The DocumentReference.content.format is the indication of the profile / formatCode of the document content. If one defines a new profiled document for this use-case of a Terminal / Revoked / Removed document. Then one could put this value here.
• The DocumentReference.context.event is the MOST USEFUL. This in both FHIR and XDS is a general useable code. Thus any code can be put in here. 

So, use DocumentReference.context.event and define a specific code to indicate a Terminal state of the previous document. I don't know if there is a useable code, but likely there is a code in CDA. Or you could put the Composition Status code from the updated CodeSystemComposition Status code from the updated CodeSystem in here

Conclusion

So, my conclusion is

1. Use Replace, with some differently profiled document

2. This document would be defined to indicate the context of the Removal / Revocation / Rejection / etc.

3. This document would have a defined set of codes to use inside the document

4. This document would have a different FormatCode / profile

5. This document would profile the Metadata (e.g. DocumentReference) to indicate this terimal status document. This could be all of the above, but most likely would be the FormatCode and an Event code.

Meaning this is a normal use-case analysis that results in a specific profiled document that replaces the previous document. This will be understood in simple FHIR Server, and would be understood in XDS / XCA / MHDS. Thus it has the broadest useability and clarity.