1. XDS Link-Unlink Support Brief Profile Proposal for 2011/12 presented to the IT Infrastructure Planning Committee José Mussi (JRS Partners – IHE Canada) September 25, 2010

2. IT Infrastructure Planning Committee The Problem The IHE XDS profile does not give definitive guidance regarding management of patient identifiers but does provide some general approaches and requirements of its use. This allows for a variety of models for managing patient identifiers.The IHE XDS profile does not give definitive guidance regarding management of patient identifiers but does provide some general approaches and requirements of its use. This allows for a variety of models for managing patient identifiers. In particular, the IHE XDS profile contains no explanation on how to handle link/unlink events triggered by the XDS Affinity Domain patient identity source. This gap becomes evident in implementations that relies on the PIX Manager system to map local identifiers to the affinity domain patient ID where link/unlink events can happen.In particular, the IHE XDS profile contains no explanation on how to handle link/unlink events triggered by the XDS Affinity Domain patient identity source. This gap becomes evident in implementations that relies on the PIX Manager system to map local identifiers to the affinity domain patient ID where link/unlink events can happen.

3. IT Infrastructure Planning Committee Market Readiness/Risks This issue was raised by on-going implementation needs in Canada where the EHR model promotes the use of central XAD-PID (e.g. ECID) matching.This issue was raised by on-going implementation needs in Canada where the EHR model promotes the use of central XAD-PID (e.g. ECID) matching. Lack of a IHE-supported standard approach will lead to adoption of a locally-developed solutionLack of a IHE-supported standard approach will lead to adoption of a locally-developed solution

4. IT Infrastructure Planning Committee Use Case Patient presents to a service location in a XDS Affinity Domain for the first time and that a set of documents from that encounter are published to the XDS infrastructure: The local patient ID (MRN 77654) is linked by the PIX manager to an existing XAD-PID (76576). Documents are published using that common identifier.

5. IT Infrastructure Planning Committee Use Case At later time, it is discovered that Patient A should not have been linked to that XAD-PID and that in fact, it should have been linked to another identifier:

6. IT Infrastructure Planning Committee The correct XAD-PID is 46573 and the change occurs within the XDS Affinity Domain patient ID source. However, the previously published document (DOC 34245) needs to be corrected and reflect this change. Given that the original document source system may not be aware of the link/unlink event, it cannot be expected to deprecate and re-publish the document itself. Currently the IHE XDS profile does not provide a mechanism to address this situation and propagate the link/unlink event to the XDS document registry.

7. IT Infrastructure Planning Committee Proposed Standards & Systems As with the existing XDS transactions, this problem can be solved using existing HL7 v2 messages.As with the existing XDS transactions, this problem can be solved using existing HL7 v2 messages. The question is which one(s) should be used and then describe the expected behaviour from the XDS Document Registry when such events occur.The question is which one(s) should be used and then describe the expected behaviour from the XDS Document Registry when such events occur.

8. IT Infrastructure Planning Committee Discussion The key challenge with this proposal is choosing the best approach that can:The key challenge with this proposal is choosing the best approach that can: –Address the link/unlink use case –Minimize changes/addition of complexity to the document registry Most of the effort will reside in working through each of the candidate solutions and ensuring that it does not introduce any instabilities or conflicting states to the registryMost of the effort will reside in working through each of the candidate solutions and ensuring that it does not introduce any instabilities or conflicting states to the registry