1 / 8

XDS Link-Unlink Support

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

dione
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 Brief Profile Proposal for 2011/12 presented to the IT Infrastructure Planning Committee José Mussi (JRS Partners – IHE Canada) September 25, 2010

  2. 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. • 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. 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 77654) is linked by the PIX manager to an existing XAD-PID (76576). 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 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. Proposed Standards & Systems • 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.

  8. Discussion • 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 registry

More Related