Erasing Document

1. Proposed Transaction: Erase Document

• Proposal Editor: Manuel Metz
• Profile Editor: TBA
• Date: N/A (Wiki keeps history)
• Version: N/A (Wiki keeps history)
• Domain: IT Infrastructure

2. The Problem

Although there is a transaction to replace medical documents by a more up to date document, there is no way to delete a document.

This is needed when medical documents are not relevant any more (for instance a radiology manifest referencing images that don't exist any more) or when the legal framework allows patients to request deletion of a document (in Europe for instance).

For legal reasons, a medical document might not be completely destroyed; the transaction could result in the document no longer being findable/available through regular means but still existing in the system.

3. Key Use Case

Use Case #1: Patient A has suffered a trying childhood disease (disease 1) many years ago.

After a long treatment, the disease has been completely cured. Patient A is now treated for an totally different disease (disease 2) which bears medically non-relevant similarities with the childhood disease 1. Each time patient A sees a healthcare professional, queries (for documents on patient A's current health condition) sent to patient A's PHR result in documents on disease 1. Even though disease 1 documents are old, the healthcare professional considers them and speaks about the trying childhood disease before discarding it as obviously irrelevant to any later condition. Patient A wants to avoid being reminded of the trying childhood disease and as it is completely cured and has no relevance to any later condition wishes documents linked to disease 1 to be erased.

Counseled by his/her primary care physician, patient A selects the documents on disease 1 to erase. The list of the selected documents is submitted to the PHR which erases the documents. The documents cannot be found in the PHR through usual means. The documents as well as any disclosure log tracing their erasing still exist in the system and might be retrieved through specific procedures.

Use case #2: After each set of medical images produced by a PACS, a manifest is automatically produced and sent to relevant EHRs. After a while, the images are erased from the PACS for various reasons (accident, regular document life cycle, quality checks...). The manifest stored in the EHRs is referencing non-existing images. The PACS informs the relevant EHRs that the manifest is to be directly erased without being replaced by an other documents.

4. Standards & Systems

Existing systems possibly involved in the problem/solution:

Systems involved in XD* profiles, namely XDS Affinity domains (Repository and Registry) and end users' systems (document source).

Standards possibly relevant to the solution:

as for XD* profiles (i.e.: ebRIM, ebRS, SOAP)

5. Discussion

If deprecated documents are used as document history (and therefore are seen by users), there are no means defined in IHE-XDS for a user to erase a document.

Erasing a document is an interoperability issue between IHE actors dealing with documents life cycle (creation, storing, modification).

Erasing document could be solved by defining a new availability status signaling that a document has been erased. Erased documents would not be found by any regular query to the registry but would still be stored in the repository. It would also need a new transaction allowing a user (probably through a document source) to erase a document (and possibly all its deprecated parents). For traceability purposes it should be impossible to erase a deprecated document alone. This could be achieved through a new transaction allowing to directly change a document meta-data without submitting a new document or through the submission of a new document with an availability status at “erased” and an “erase” relation pointing to an “approved” document. While registering the relation, the registry would then have to update the availability status of the “approved” document and possibly all its ancestries (its parent document, its parent's parent document and so on...) to “erased”. The erasing transaction should be reversible allowing for a final document to recover its “approved” status (and depending on the policy allowing all its parents their “deprecated” status accordingly). Erasing a document should not destroy relations between documents.