Monday, February 4, 2013

IHE Connectathon, standardization over the top?

The ultimate plug-fest for healthcare IT

The IHE (Integrating the Healthcare Enterprise) has organized so-called Connectathons since 1997. These events, also sometimes called plug-fests, provide an opportunity to test and demonstrate device and system interoperability, and to resolve compatibility issues. 

This particular event has grown steadily, and this year in Chicago, more than 500 engineers and monitors were working diligently for a week to test 163 healthcare IT systems representing 101 vendors from all over the globe. The number of tests that were verified were close to 3000.

This year however, the number of attendees was flat compared with last year, which begs the question, why? The healthcare IT industry is definitely booming, there is a big emphasis on implementing healthcare IT as part of the $20 billion American Recovery and Reinvestment Act (ARRA) incentives for deploying electronic health records, and healthcare is one of the fields where new innovations are definitely happening. Here are my guesses for its reasons for its stall:

1.    We have reached the max with regard to standardization ­­– As of now there are twelve domains ranging from radiology to pathology, including eye care, oncology, lab, cardiology, dentistry, pharmacy, infrastructure, patient care coordination and devices, and patient care coordination and public health. Each domain has numerous profiles based on specific use cases. The IHE website states that there are 350 members with 2,000 volunteers who work on various committees. Maybe IHE has become too big and the effort has become too much too soon, too fast.
2.    Vendors can’t keep up – Imagine you are a vendor and you have to update your software pretty much annually to meet the various IHE integration requirements. Market-driven companies might decide that there are other priorities that should be addressed before interoperability. The only way this would ever change is through customer pressure, i.e. if supporting an integration profile is either high on the requirement list, or, even better, a make-or-break purchasing requirement. However, despite the initiatives by RSNA and HIMSS to promote and advertise the need for interconnectivity and, in particular the need to support new IHE profiles, interconnectivity still appears to be low on the list of customer requirements.
3.    The need for a formal certification – It might be that the idea of a volunteer-driven, loosely managed activity is getting outdated and is being replaced by a more formal testing using standard guidelines resulting in official certified systems. The pros and cons of certification vs the more or less informal plug-fests are discussed elsewhere (see link). So maybe it is time to switch gears.
4.    Standards have become too complex – If you have ever looked at a sample clinical document (CDA), for example the one used to capture information for discharge from an emergency department, it is a very verbose XML document including ten pages of coding, which is not easy to interpret. It literally requires one to either be involved with the HL7 standardization effort or go through intensive training to be able to work with these. One could argue that other standards (DICOM comes to mind) are not that easy either, but people seem to have learned to work with it through the years. However, these standards bring complexity to another level, which definitely creates a barrier for implementation and deployment.
5.    Standards are still not tight enough – Despite its complexity and the extensive encoding used, there is still a connectivity problem as semantic interoperability is still missing. It is not sufficient to merely exchange pieces of data, if there is a different interpretation of the context, adding this information to a database might even be dangerous. If that means that we can only convey certain information in its original context and information model, we could resort to just sending e.g. a PDF document, which makes the current encoded information exchanges a massive overkill.
6.    Vendors are not motivated – It is not always in the commercial interest of a company to support standards, but, rather to keep their systems proprietary. A good example is the evolution of PACS systems. Even though some of the components, notably the image archive in the form of a VNA, were extracted from the monolithic PACS systems, the workstations are still very tightly connected with the image manager of these same systems, despite the presence of workstation work list standards. Except for a few open-source products, vendors have been very hesitant to implement that and want to protect their turf from third party workstation vendors.

Back to the Connectathon, I noticed the actual testing and validation process has definitely improved. There are relatively robust validation tools and plenty of samples available. In addition, we used to look for information structures in the past, now new tests and checks are available that also evaluate the content. This is overall a major positive development. However, the questions still remain whether or not we have reached a plateau or even the top.  Of course, I could be wrong and next year’s attendance could be back up proving that 2013 was just a fluke or temporary dip. But, I don’t think so; maybe we will get a better idea of the reason behind this by then.