Erasing Document

1. Proposed Profile: Erasing Document (Transaction ITI-XX)

• 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

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 allow patients to ask for it (in Europe for instance); medical documents have to be directly erased instead of being replaced by a more up to date document.

It is to be noted that, for legal reasons, a medical document might not be completely destroyed; the erasing of a document could end up in the document not being able to be found 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 had 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 sent to patient A's PHR to get documents on patient A's current health condition result in showing documents on disease 1. Even though disease 1 documents are old, the healthcare professional consider them and speak 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 select the documents on disease 1 to erase. The list of the selected documents is submitted to the PHR which erase the documents. The documents can not 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 inform 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.