Sunday, February 9, 2014

IHE Connectathon 2014: Chill out with XDS-I

Engineers concentrating on
their systems pass the tests
There could not be a bigger difference between the HL7 meeting in San Antonio, where temperatures were in the mid 60s (18 degrees C) and the connectathon meeting in Chicago, which was under a wind chill warning. For those not used to these conditions, according to my smart phone’s weather app, a wind chill warning means “very cold air creating dangerously low wind chill values resulting in frost bite, and can lead to hypothermia or death if precautions are not taken.” Well, 30 degrees below (-35 degrees C) is kind of cold, it penetrates several layers of clothing and even walking one block to a convenience store to pick up breakfast was a challenge.

Last years’ big news was the IHE certification effort, which caused a lot of anxiety among the vendors, as they viewed it as yet another requirement they had to meet requiring additional cost and effort with no obvious benefits except for another “stamp of approval.” I kind of have to agree with their positions, as the initial “passing” of the connectathon effort would basically demonstrate that a vendor is able to meet the corresponding requirements anyway. As it turned out, the number of vendors that pursued certification has been minimal anyway, so this might be an effort ready to fizzle out slowly.

The number of attendees in 2014 was about the same as last year’s effort, with 100 companies testing 140 different systems supported by 540 engineers from all over the world, who had to prove to a cadre of 60 or so monitors that they pass the IHE profile requirements. I spent time verifying the XDS-I (Cross enterprise Document Sharing for images) profiles. These allow for a source, such as local PACS system, to register its documents, which could be an image manifest, pdf file, text document, or CDA (Clinical Document Architecture) document. The registration takes place against one of the 27 registries that were present, after which the documents can be exchanged with one of the 36 repositories. These registry/repository combinations are typically provided by a Health Information Exchange (HIE), of which many are in the process of being implemented, either as public (e.g. on a state level) or private entities. A vendor will have to prove to one of the 60 or so monitors (me being one of them) that it can successfully connect with three different partners in order to claim to have passed the test requirements.

Unlike documents, which could be discharge documents, text reports, and any other medical documentation, images will most likely not be archived in a central (HIE) repository, but instead, an image manifest would be archived with a so-called Key Object that contains information about what the significant images are with a reference back to the source, e.g. the local PACS where they can be retrieved. The Query/Retrieve part of the XDS could be either a 3-way communication, i.e. query a registry by a consumer such as a PACS viewer, and retrieval from the repository, or a 4-way whereby the repository provides the manifest for the images, which are subsequently retrieved from the original source. Image retrieval can be done using the standard DICOM Query/Retrieve protocol or the so-called WADO (Web Access to DICOM Objects), which is basically an http call using Internet protocol for a DICOM image.

The connectathon test and verification process is highly automated as there are not only electronic work lists available for the monitors to manage their workload for the profiles they are assigned, but there are also many test transactions and verification and simulation tools that are used in the process. These tools and test transactions are available in the public domain and a great resource for anyone who would like to perform testing and verification of his or her system. The NIST (National Institute for Simulation and Testing) provides downloadable simulators of the so-called “actors” with sample transactions and validators that check the messages for compliance with the IHE profile definitions.

XDS is a relatively simple protocol, and based on the many implementations that I saw during the connectathon, it works well. The XDS deployment varies widely based on the locale. In the US, there are relatively few implementations, which is probably related to the slow adoption of Health Information Exchanges (HIE). Exchanging images is still very much a “sneaker net”-based activity using CD’s and/or performed through private companies serving as a proprietary cloud storage or exchange provider. The landscape is quite different in Canada, which for better or for worse has a government managed healthcare system and where the implementation of HIE’s and corresponding regional repositories is enforced by the provinces. XDS plays an important role in the information exchange between the local entities and HIE.

In contrast to the US, the XDS implementations in Europe are much farther along. France has a national, government supported infrastructure for a patient portal which can exchange information using XDS with the national HIE’s. Despite its widespread implementation, its usage is still minimal, which could be due to a marketing and or unfamiliarity problem. The UK is undergoing a major effort to connect their institutions with PACS Vendor Neutral Archives (VNA) getting a central role in this architecture. However, despite the fact that the majority of the installed VNA’s have XDS capabilities, its usage is still in its infancy as well. There are several patches of successful implementations, notably in the Netherlands, Austria, Switzerland and Scandinavian countries where XDS is used extensively.

Despite the slow start and sparse implementation of XDS in the US, it might take off with the increase of HIE’s, especially the private ones, which are increasingly being installed by Integrated Delivery Networks (IDN’s). These are coming under pressure to reduce costs, which can be achieved by elimination of supplicate tests and procedures through image availability. If the full-fledged XDS is going to be used or the variants called XCA (Cross Community Access) or XDR (Cross Document Reliable Interchange), which is a direct push, remains to be seen, but there is definitely potential. As a matter of fact, as of today, there are no really good alternative ways to do it in a standard manner, except for using proprietary solutions. The fact that vendors are implementing XDS in other locales will definitely help as experience with these implementations will be gained and can be used to assist US pilot sites.

The XDS and XDS-I profile testing was a small but significant portion of the literally thousands of tests that were successfully performed during the US connectathon. The implementations were relatively mature and many vendors passed the validation and verification process. That means that the industry is ready, it is now the turn of the many healthcare institutions, supported by government incentives and requirements, to start implementing.

No comments:

Post a Comment