XDS Link-Unlink Support Profile Proposal for 2011/12 presented to the IT Infrastructure Planning Committee José Mussi (JRS Partners – IHE Canada) Karen

XDS Link-Unlink SupportXDS Link-Unlink Support

Profile Proposal for 2011/12Profile Proposal for 2011/12presented to thepresented to the

IT Infrastructure Planning CommitteeIT Infrastructure Planning Committee

José Mussi (JRS Partners – IHE Canada)José Mussi (JRS Partners – IHE Canada)Karen Witting (IBM – ITI Planning Committee)Karen Witting (IBM – ITI Planning Committee)

October 19, 2010October 19, 2010


The Problem

• The XDS Profile does not adequately address management The XDS Profile does not adequately address management of patient identifiers. This is a KNOWN GAP.of patient identifiers. This is a KNOWN GAP.

• In real world settings adjustment is needed to address errors In real world settings adjustment is needed to address errors in associations between real patients and local and regional in associations between real patients and local and regional identifiers.identifiers.– The IHE XDS profile does not give definitive guidance regarding The IHE XDS profile does not give definitive guidance regarding

management of patient identifiers but does provide some general management of patient identifiers but does provide some general approaches and requirements of its use. This allows for a variety of approaches and requirements of its use. This allows for a variety of models for managing patient identifiers. models for managing patient identifiers.

– The IHE XDS profile contains no explanation on how to handle The IHE XDS profile contains no explanation on how to handle link/unlink events triggered by the XDS Affinity Domain patient identity link/unlink events triggered by the XDS Affinity Domain patient identity source. This gap becomes evident in implementations that relies on source. This gap becomes evident in implementations that relies on the PIX Manager system to map local identifiers to the affinity domain the PIX Manager system to map local identifiers to the affinity domain patient ID where link/unlink events can happen.patient ID where link/unlink events can happen.


Market Readiness/Risks

• This issue was raised by on-going implementation needs in This issue was raised by on-going implementation needs in Canada where the EHR model promotes the use of central Canada where the EHR model promotes the use of central XAD-PID (e.g. ECID) matching.XAD-PID (e.g. ECID) matching.

• Lack of a IHE-supported standard approach will lead to Lack of a IHE-supported standard approach will lead to adoption of a locally-developed solutionadoption of a locally-developed solution


Use Case

Patient presents to a service location in a XDS Affinity Patient presents to a service location in a XDS Affinity Domain for the first time and that a set of documents from Domain for the first time and that a set of documents from that encounter are published to the XDS infrastructure:that encounter are published to the XDS infrastructure:

The local patient ID (MRN 22222) is linked by the PIX The local patient ID (MRN 22222) is linked by the PIX manager to an existing XAD-PID (33333). Documents are manager to an existing XAD-PID (33333). Documents are published using that common identifier.published using that common identifier.

Doc65565

Doc14354

Doc34521

Doc98876

Doc34245

Patient BXAD-PID

33333

PHN34544

ULI34573

RHRN34679

MRN87896

MRN22222

(patient A)

Patient Identity Source

Patient BXAD-PID

33333

XDS Document Registry

IHE Patient Identity Feed – [ITI-8]


Use Case

At later time, it is discovered that Patient A should not have 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 that XAD-PID and that in fact, it should have been linked to another identifier:been linked to another identifier:

Patient Identity Source

Patient BXAD-PID

33333

PHN34544

ULI34573

RHRN34679

MRN87896

Patient AXAD-PID

11111

PHN18905

ULI23787

RHRN12654

MRN45899

MRN22222

XDS Document Registry

Patient BXAD-PID

33333

Doc65565

Doc14354

Doc34521

Doc98876

Doc34245

Patient AXAD-PID

11111

Doc78923

Doc89087

Doc89031

Doc76886

IHE Patient Identity Feed – [ITI-8]


The correct XAD-PID is 11111 and the change occurs within The correct XAD-PID is 11111 and the change occurs within the XDS Affinity Domain patient ID source. However, the the XDS Affinity Domain patient ID source. However, the previously published document (DOC 34245) needs to be previously published document (DOC 34245) needs to be corrected and reflect this change. corrected and reflect this change.

Given that the original document source system may not be Given that the original document source system may not be aware of the link/unlink event, it cannot be expected to aware of the link/unlink event, it cannot be expected to deprecate and re-publish the document itself.deprecate and re-publish the document itself.

Currently the IHE XDS profile does not provide a mechanism Currently the IHE XDS profile does not provide a mechanism to address this situation and propagate the link/unlink event to address this situation and propagate the link/unlink event to the XDS document registry.to the XDS document registry.


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.


Alignment with healthcare business

• The need for supporting link/unlink events results from the The need for supporting link/unlink events results from the fact that patient identify management processes, specially fact that patient identify management processes, specially in healthcare settings, cannot be perfect. Patients IDs will in healthcare settings, cannot be perfect. Patients IDs will be linked incorrectly and once identified, the error must be be linked incorrectly and once identified, the error must be corrected promptly and accurately. corrected promptly and accurately.

• In order to avoid cascading errors, most of the complexity In order to avoid cascading errors, most of the complexity for the fix needs to be handled by the services running for the fix needs to be handled by the services running “behind the scenes”, such as the XDS registry and the PIX “behind the scenes”, such as the XDS registry and the PIX ManagerManager


Benefit to global community

• The use case scenarios used for the development of this The use case scenarios used for the development of this proposal are real cases that are occurring in the proposal are real cases that are occurring in the deployment of the Canadian interoperable EHR. deployment of the Canadian interoperable EHR.

• It has been supported through IHE consultations during the It has been supported through IHE consultations during the preparation of the XDS Identity Management Whitepaper preparation of the XDS Identity Management Whitepaper that is that foundation of this proposal.that is that foundation of this proposal.


Alignment with Government Programs

• The use case scenarios are derived from the national EHR The use case scenarios are derived from the national EHR blueprint developed by Canada Health Infoway. They blueprint developed by Canada Health Infoway. They provide the foundation of the relationship between the provide the foundation of the relationship between the identity matching services (i.e. Client Registry) and the identity matching services (i.e. Client Registry) and the XDS systems.XDS systems.


Alignment with other IHE Domains

• The proposal deals just with IT infrastructure services and The proposal deals just with IT infrastructure services and does not impact other IHE domains.does not impact other IHE domains.


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 Encourages growth of XDS by addressing a crucial gap in capability.capability.


Discussion

• Low Effort:Low Effort:– Analysis and definition is complete, see white paperAnalysis and definition is complete, see white paper

– Significant background knowledge and experience coming from CanadaSignificant background knowledge and experience coming from Canada

– The only remaining challenge with this proposal is choosing the best The only remaining challenge with this proposal is choosing the best approach that can:approach that can:

• Address the link/unlink use case Address 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 Most of the effort will reside in working through each of the candidate solutions and ensuring that it does not introduce any instabilities or solutions and ensuring that it does not introduce any instabilities or conflicting states to the registryconflicting states to the registry

• High Value:High Value:– Fills in a critical gap in a vital IHE ITI profileFills in a critical gap in a vital IHE ITI profile

– Satisfies short term needs of significant national program and long term Satisfies short term needs of significant national program and long term needs of most XDS usersneeds of most XDS users


Backup

• More detailed review of alternative solutions.


Approach 1: Notification of new XAD-PID Link

• As the error is discovered and the PIX manager changes As the error is discovered and the PIX manager changes the local identifier to a new linkage set it would send out a the local identifier to a new linkage set it would send out a notification that basically would be saying:notification that basically would be saying:

– ““The correct XAD-PID for MRN 77654 is 11111”The correct XAD-PID for MRN 77654 is 11111”

• With this notification in hand, it is fairly straight forward how With this notification in hand, it is fairly straight forward how to fix the registry:to fix the registry:

– ““For every document where SourcePatientID=“MRN 22222”, assign For every document where SourcePatientID=“MRN 22222”, assign PatientID to 11111”PatientID to 11111”


Approach 1: Notification of new XAD-PID Link

• This change would ideally be done directly by the XDS This change would ideally be done directly by the XDS registry, as it would have the ability to perform the registry, as it would have the ability to perform the database update efficiently and reliably. database update efficiently and reliably.

• An alternative would be to have another system determine An alternative would be to have another system determine which documents need to be changed and issue a series which documents need to be changed and issue a series of metadata update request to the XDS registry. of metadata update request to the XDS registry.


Approach 2: Notification of Linkage Set Updates

• Another approach would be to have the PIX Manager send Another approach would be to have the PIX Manager send out notifications with the entire linkage set anytime one out notifications with the entire linkage set anytime one changes. changes.

• The idea here is that receivers of this notification (e.g. the The idea here is that receivers of this notification (e.g. the XDS registry) would maintain their own internal copy of the XDS registry) would maintain their own internal copy of the linkage sets for every valid XAD-PID and would use these linkage sets for every valid XAD-PID and would use these sets to maintain the correct relationship between sets to maintain the correct relationship between documents.documents.

• This approach requires that a first message be sent to This approach requires that a first message be sent to unlink the local ID from the current XAD-PID and a second unlink the local ID from the current XAD-PID and a second message to re-link the same ID to a new XAD-PID. message to re-link the same ID to a new XAD-PID.


Approach 2: Notification of Linkage Set Updates

• Using two asynchronous messages could leave the Using two asynchronous messages could leave the registry in an incorrect state if one fails. It would also registry in an incorrect state if one fails. It would also require the document registry to perform a differential require the document registry to perform a differential comparison with the information it previously had about comparison with the information it previously had about that patient and identify any changes to the local patient that patient and identify any changes to the local patient IDs assigned to the corresponding XAD-PID.IDs assigned to the corresponding XAD-PID.

• Fixing the XDS registry would be somewhat more complex, Fixing the XDS registry would be somewhat more complex, since either the XDS registry or an external actor would since either the XDS registry or an external actor would have to figure out what has changed (the messages are have to figure out what has changed (the messages are not explicit, rather just reflect the current state of the not explicit, rather just reflect the current state of the linkage set) and then performed the necessary database linkage set) and then performed the necessary database updates.updates.