1. XDS Link-Unlink Support Profile Proposal for 2011/12 presented to the IT Infrastructure Planning Committee José Mussi (JRS Partners – IHE Canada) Karen Witting (IBM – ITI Planning Committee) October 19, 2010

2. IT Infrastructure Planning Committee The Problem The XDS Profile does not adequately address management of patient identifiers. This is a KNOWN GAP.The XDS Profile does not adequately address management of patient identifiers. This is a KNOWN GAP. In real world settings adjustment is needed to address errors in associations between real patients and local and regional identifiers.In real world settings adjustment is needed to address errors in associations between real patients and local and regional 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. –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 22222) is linked by the PIX manager to an existing XAD-PID (33333). 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 11111 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 Technical Considerations A whitepaper has been published by the ITI Technical Committee called XDS Patient Identity Management which describes this problem in detail, discusses technical solutions and recommends an approach. Recommended approach: HL7 V2 message sent from XAD-PID source to XDS Document Registry containing new association of local and XAD-PID. XDS Document Registry searches for local identifier and updates document metadata with new XAD-PID. Alternative solutions include notification of linkage sets and use of XDS Metadata Update.

8. IT Infrastructure Planning Committee Alignment with healthcare business The need for supporting link/unlink events results from the fact that patient identify management processes, specially in healthcare settings, cannot be perfect. Patients IDs will be linked incorrectly and once identified, the error must be corrected promptly and accurately.The need for supporting link/unlink events results from the fact that patient identify management processes, specially in healthcare settings, cannot be perfect. Patients IDs will be linked incorrectly and once identified, the error must be corrected promptly and accurately. In order to avoid cascading errors, most of the complexity for the fix needs to be handled by the services running behind the scenes, such as the XDS registry and the PIX ManagerIn order to avoid cascading errors, most of the complexity for the fix needs to be handled by the services running behind the scenes, such as the XDS registry and the PIX Manager

9. IT Infrastructure Planning Committee Benefit to global community The use case scenarios used for the development of this proposal are real cases that are occurring in the deployment of the Canadian interoperable EHR.The use case scenarios used for the development of this proposal are real cases that are occurring in the deployment of the Canadian interoperable EHR. It has been supported through IHE consultations during the preparation of the XDS Identity Management Whitepaper that is that foundation of this proposal.It has been supported through IHE consultations during the preparation of the XDS Identity Management Whitepaper that is that foundation of this proposal.

10. IT Infrastructure Planning Committee Alignment with Government Programs The use case scenarios are derived from the national EHR blueprint developed by Canada Health Infoway. They provide the foundation of the relationship between the identity matching services (i.e. Client Registry) and the XDS systems.The use case scenarios are derived from the national EHR blueprint developed by Canada Health Infoway. They provide the foundation of the relationship between the identity matching services (i.e. Client Registry) and the XDS systems.

11. IT Infrastructure Planning Committee Alignment with other IHE Domains The proposal deals just with IT infrastructure services and does not impact other IHE domains.The proposal deals just with IT infrastructure services and does not impact other IHE domains.

12. IT Infrastructure Planning Committee Alignment with ITI Domain Growth Addresses a KNOWN GAP in an important profile.Addresses a KNOWN GAP in an important profile. Encourages growth of XDS by addressing a crucial gap in capability.Encourages growth of XDS by addressing a crucial gap in capability.

13. IT Infrastructure Planning Committee Discussion Low Effort:Low Effort: –Analysis and definition is complete, see white paper –Significant background knowledge and experience coming from Canada –The only remaining challenge with this proposal is choosing the best approach that can: Address the link/unlink use caseAddress the link/unlink use case Minimize changes/addition of complexity to the document registryMinimize 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 registry High Value:High Value: –Fills in a critical gap in a vital IHE ITI profile –Satisfies short term needs of significant national program and long term needs of most XDS users

14. IT Infrastructure Planning Committee Backup More detailed review of alternative solutions.

15. IT Infrastructure Planning Committee Approach 1: Notification of new XAD-PID Link As the error is discovered and the PIX manager changes the local identifier to a new linkage set it would send out a notification that basically would be saying:As the error is discovered and the PIX manager changes the local identifier to a new linkage set it would send out a notification that basically would be saying: –The correct XAD-PID for MRN 77654 is 11111 With this notification in hand, it is fairly straight forward how to fix the registry:With this notification in hand, it is fairly straight forward how to fix the registry: –For every document where SourcePatientID=MRN 22222, assign PatientID to 11111

16. IT Infrastructure Planning Committee Approach 1: Notification of new XAD-PID Link This change would ideally be done directly by the XDS registry, as it would have the ability to perform the database update efficiently and reliably.This change would ideally be done directly by the XDS registry, as it would have the ability to perform the database update efficiently and reliably. An alternative would be to have another system determine which documents need to be changed and issue a series of metadata update request to the XDS registry.An alternative would be to have another system determine which documents need to be changed and issue a series of metadata update request to the XDS registry.

17. IT Infrastructure Planning Committee Approach 2: Notification of Linkage Set Updates Another approach would be to have the PIX Manager send out notifications with the entire linkage set anytime one changes.Another approach would be to have the PIX Manager send out notifications with the entire linkage set anytime one changes. The idea here is that receivers of this notification (e.g. the XDS registry) would maintain their own internal copy of the linkage sets for every valid XAD-PID and would use these sets to maintain the correct relationship between documents.The idea here is that receivers of this notification (e.g. the XDS registry) would maintain their own internal copy of the linkage sets for every valid XAD-PID and would use these sets to maintain the correct relationship between documents. This approach requires that a first message be sent to unlink the local ID from the current XAD-PID and a second message to re-link the same ID to a new XAD-PID.This approach requires that a first message be sent to unlink the local ID from the current XAD-PID and a second message to re-link the same ID to a new XAD-PID.

18. IT Infrastructure Planning Committee Approach 2: Notification of Linkage Set Updates Using two asynchronous messages could leave the registry in an incorrect state if one fails. It would also require the document registry to perform a differential comparison with the information it previously had about that patient and identify any changes to the local patient IDs assigned to the corresponding XAD-PID.Using two asynchronous messages could leave the registry in an incorrect state if one fails. It would also require the document registry to perform a differential comparison with the information it previously had about that patient and identify any changes to the local patient IDs assigned to the corresponding XAD-PID. Fixing the XDS registry would be somewhat more complex, since either the XDS registry or an external actor would have to figure out what has changed (the messages are not explicit, rather just reflect the current state of the linkage set) and then performed the necessary database updates.Fixing the XDS registry would be somewhat more complex, since either the XDS registry or an external actor would have to figure out what has changed (the messages are not explicit, rather just reflect the current state of the linkage set) and then performed the necessary database updates.