Monday, November 3, 2014

IHE XDS Implementation Issues Part 2.

XDS is like an engine with several parts
This is the second part of the IHE XDS discussion that will focus on the relationship between XDS and the other profiles in the IHE ITI technical framework domain. Note: you can watch a video of this presentation here. As mentioned in part 1 of this series, the Integrating Healthcare Enterprise (IHE) Cross Enterprise Document Sharing (XDS) profile has been widely implemented and many vendors have tested and demonstrated its functionality at the previous connectathons, however, actual deployments have been very limited. One of the reasons is that XDS by itself does not make sense, as it is merely an engine, which has several components. For example, if we continue this analogy, it has a transmission, cylinders, alternator, etc. The same is true with XDS, it consists of several actors and it is important to validate that all parts are present to make it work. As an engine needs other parts such as a chassis, wheels, steering controls, etc. to make it into a fully functioning car, truck, or motorcycle, which is where the other ITI profiles, such as security, patient information management, workflow, provider, personnel and content management play a role. 

Let’s look at each one of these profiles needed to facilitate the XDS engine:
1.       Patient Identity Management: If a document or image is exchanged between two enterprises, we better make sure that we know who it belongs to, in other words, that we have unambiguously identified the patient. There are several profiles needed to facilitate this:
a.       Patient Administration Management (PAM) – to manage patient information locally, such as with a hospital information system or ADT system
b.      Patient Identifier Cross-Referencing (PIX) – to support linking patient identifiers across multiple patient identifier domains. This allows systems to register their patient identity, e.g. with a Patient ID, with a so-called Cross Reference Manager, such as present in a Health Information Exchange or HIE, so that potential consumers, i.e. physicians can query and be notified of any changes.
c.       Patient Demographics Query (PDQ) – to allow consumers to query for patient demographics and visit information.
d.      Cross Community Patient Discovery (XCPD) – to discover patient information across communities using a gateway to talk to.

2.       Security and Privacy Management: These profiles make sure that the information is exchanged in a secure manner using the following profiles:
a.       Audit Trails and Node Authentication (ATNA) – to provide authentication and also a standard protocol and format to exchange and archive audit trails
b.      Consistent Time (CT) – to synchronize multiple applications using a single clock. This is critical as some of the applications need to be very tightly coupled.
c.       Enterprise and Cross Enterprise User Authentication (EUA and XUA)- to provide a single authentication process
d.      Basic Privacy Consent Management (BPPC) – to manage patient consents, i.e. what he or she allows to be shared
e.      Document Encryption and Digital Signatures (DEN and DSG) – to provide the information encryption and data integrity.

3.       Provider and Personnel Management: These profiles identify provider organizations and people across different enterprises:
a.       Personnel White Pages (PWP)- to provide a resource to determine exactly which provider is involved
b.      A Healthcare Provider directory (HPD) – to make sure that the right provider is selected

4.       Workflow Management: This profile defines workflows in the different enterprises. It uses the XDW or Cross-Enterprise Workflow profile to do this.

5.       Content Management: The content management profiles are not really part of the ITI domain, but rather defined in the individual specialty domains such as patient care and several others. However I want to mention it here as it is essential to have an agreement not only about the protocol to be used (e.g. a HL7 transaction) but even more about the content of these messages, otherwise the receiver will not be able to interpret it and, for example, use it to store in its medical record system. It is easy to send over documents such as a PDF that can be added as a document to a patient folder, it is much harder to agree on a template for example for a discharge or medical summary report with all of the individual fields properly encoded so that they can be decoded and interpreted by a software application.

In conclusion, XDS needs many more parts, as it is just an engine, it require several more profiles to be able to use it in an enterprise setting. The next step is discussing what the XDS itself encompasses and how it works, which will be in part 3.