1 / 18

XDS Link-Unlink Support

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. The Problem.

tevy
Download Presentation

XDS Link-Unlink Support

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. The Problem • 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. • 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. 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. • Lack of a IHE-supported standard approach will lead to adoption of a locally-developed solution

  4. 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. 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. 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. 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. 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. • 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 Manager

  9. 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. • It has been supported through IHE consultations during the preparation of the XDS Identity Management Whitepaper that is that foundation of this proposal.

  10. 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.

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

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

  13. Discussion • 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 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 registry • 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. Backup • More detailed review of alternative solutions.

  15. 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: • “The correct XAD-PID for MRN 77654 is 11111” • 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. 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. • 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. 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. • 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.

  18. 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. • 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.

More Related