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.

FHIR Security and Privacy - Open Educational Session

For those going to HL7 WGM in Dallas. I will be available Wednesday afternoon in an open educational session on FHIR Security and Privacy:

The best case is that everyone that comes to the session would have reviewed the freely available recorded tutorial sessions, and/or the freely available slides; so that we can have discussions and solve the world's problems regarding FHIR Privacy and Security.

- Recorded session -- https://vimeo.com/853094845/671e02f6db

- My slide deck -- http://bit.ly/FHIR-SecPriv 

Bonus points if people come having reviewed my IHE Privacy Consent on FHIR webinar

Super excited if people come with FHIR Security and Privacy problems that I have not yet written about. I would love to come out of this session scratching my head and inspired to create more solutions.

Why does IHE-MHDS not have a Document Repository?

The IHE-MHDS does not define a Document Repository Actor but does include architecture support for distributed FHIR Servers and thus the concept of a Document Repository is included in MHDS. The MHDS profile specifies how a collection of IHE profiles can be used by communities for exchanging health information, which includes support for patient identification, health document location and retrieval, provider directories, and the protection of privacy and security https://profiles.ihe.net/ITI/MHDS.

The Document Repository and Document Registry is an architectural construct that is foundational to XDS, but not necessarily part of Document Sharing. For example: XCA also does not make a distinction between a Document Registry or Document Repository, having a Responding Gateway Actor.

The MHDS profile defines a Document Registry Actor that persists, manages, and provides access using the MHD access methods. This supports IHE Document Sharing as described in the Health Information Exchange: Enabling Document Sharing Using IHE Profiles White Paper. The central HIE infrastructure defined in MHDS profile might be a single FHIR Server implementing all the defined central service actors or may be a virtual cloud of systems implementing the defined profile actors.

IHE-MHDS does not define the Document Repository Actor, as the concept of a set of distributed FHIR Servers is very natural to REST architecture. Thus IHE did not add complexity by defining a formal Document Repository Actor, as the concept can be addressed naturally with REST. For more detail see the Storage of Binary section in the MHDS profile. This is also explained in the HIE Whitepaper in section 3.2 Centralized Discovery and Retrieve

If you're looking for details on the functionalities or its implementation, the MHDS Volume 1 documentation would be a good resource to explore further. It outlines the core business functions provided by the MHDS Profile, including the publication of document-based information, persistence and lifecycle management of documents, and patient identity management among others. For broader discussion on the Document Sharing concept the whitepaper is more inclusive.

recording of my IHE Privacy Consent on FHIR webinar

I thank Health Samurai for making the recording of the Access Control meetup sessions available. Here is my presentation, and from that you can find the others.