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. 

DICOM images on your smartphone: DHIR instead of FHIR?

The DICOM protocol and metadata definitions have served the health care imaging community very well. Since its early definition which dates back to 1992, the protocol has not undergone any major changes. However, with the advent of mobile devices and need to use web services to exchange images, that is about to change. Similar to the HL7 FHIR activity, (see related blog post), which intends to leverage web services and resources to provide a fast implementation platform, DICOM is following the same path and has defined a new protocol for use over the web, and it is especially geared towards mobile device connectivity. I coined this new version “DHIR” after “DICOM Healthcare Interoperability Resources.”

The need to provide a web-friendly version of the DICOM protocol was acknowledged more than 10 years ago, when WADO (Web Access to DICOM Objects) was added to the standard. This option did not really gain any traction until it became part of the XDS-I (cross document exchange for imaging) profile definition several years later. WADO compatible viewers are also relatively new, they did not appear on the market until a few years back.

WADO was the first important step towards a more web-friendly protocol, instead of the traditional DICOM negotiation that has to take place before any image communication can happen, it provides a simple http call or uri (uniform resource identifier) request that includes a pointer to a specific DICOM object using a UID while specifying the content type, for example a dicom, jpeg, or could even be a xml or rtf for reports.

In the meantime, a group of healthcare IT professionals came up with a new concept which they named MINT (Medical Imaging Network Transport), which took the web transport mechanism a step further and also changed how the metadata is being packaged while exchanging the images. There have been a few implementations of MINT, but more importantly, since then, the Working Group 27 of the DICOM standard has taken this into account and included the key concepts of MINT into the DICOM standard as “RESTful DICOM” extensions, very similar again to the HL7 FHIR concepts.
What does RESTful DICOM mean? Well it uses the http protocol, including the authorization, and encryption capabilities of the web communication protocol. The major change is that a request can get the complete metadata of a DICOM object in one request. In addition it allows for “bulk” transfer of information with a clearly defined beginning and end. It is referred to as WADO-RS.

By the way, there is also a so-called WADO-WS defined, which basically requires a message “envelope” to be exchanged in the form of a SOAP message (simple object access protocol), another intermediate step to the RESTful WADO-RS.

As part of the RESTful services, in addition to the new capabilities for bulk transport (i.e. multiple images in a single transaction) and the capability to retrieve only the metadata (DICOM headers) for a study, there are also new protocol services defined, i.e. the WADO-RS, and the capability to do a web-services store (STOW-RS) as well as a query (QIDO-RS).


Does this mean that all devices supporting the “traditional” DICOM protocol today are going to be changed? Certainly not, similar to HL7 that has a very large installed base of version 2 implementations, there is also a huge installed base of DICOM enabled devices, so as HL7 is not going to move all of them to FHIR, DICOM is not going to move them to DHIR either. However, for new applications such as small footprint viewers, plug-ins, apps on mobile devices and tablets, these new standards are a great tool. I expect that it won’t take long before we will see implementations being offered.