One of the most interesting sections of the HIMSS 2011 exposition is definitely the Integrating the Healthcare Enterprise (IHE) showcase exhibit. Spread over a surface of one acre on the exhibition floor, dozens of vendors showcase their ability to seamlessly exchange information with other vendors and demonstrate interoperability. It is one thing to be able to communicate between different departmental systems and an EHR from the same vendor, the real challenge is when information needs to be exchanged between vendors. Obviously, this did not happen overnight as each vendor spent about a week during January’s “connect-athon” in Chicago where vendors gathered to work out the details of making such information exchanges seamless. After practice in freezing Chicago, they were able to show proof of their effort in warm and sunny Florida.
It was a true honor and reward for that hard work that the past ONC chief Dr. David Blumenthal was able to make time to look at the showcase exhibit and give a speech about the importance of interoperability. He rightfully pointed out that there are several countries that have successfully implemented electronic health records, however, it is impossible to repeat a success story from one country to another. For example, duplicating the successes in Denmark or New Zealand in the USA is not possible, if for no other reason than the difference in scale. Just the Dallas Fort Worth metroplex, where I live, has more than 6 million people and 60 hospitals, which is more than a lot of countries. Blumenthal used the analogy of a highway with many lanes, and many on- and off-ramps where cars are going at different speeds. As long as we are all going in the same direction, we will reach our destination. The IHE profiles are providing the framework that allows vendors and providers to move along toward the goal of interoperability, each at their own speed.
The complexity of an IHE cannot be overestimated. As an example, the endoscopy exam showcase, one of many that were shown, closes a circle from a physician to a specialist, hospital and back to another physician to the information that can be retrieved at the patient’s home. This specific case deals with a patient that has abdominal pain and is seeing his primary care provider. The patient is registered by the physician’s staff, and assuming the patient has seen other providers in this specific care domain, the information about this patient can be retrieved from a central registry. These central registries are being implemented right now, largely supported by US government grants, but can also be established by the participants in a specific patient care community. The physician will do an assessment and record this in his practice management system. In this specific example the patient was referred to a GI specialist. The patient’s medical summary will be posted in a central document repository and the regional registry will be updated to reflect the presence of the document.
The specialist will have a system from a different vendor and call pull up the document, which is being exchanged using the HL7 XDS interchange standard. It is imported to note that there are four different players involved in just this one information exchange. First of all the registry and repository, and in this specific case two edge-gateways as the specialist and primary care physician belonged to two different Regional Health Information Organizations. One could imagine that the physician might be based in Tulsa, Oklahoma, and the specialist in Dallas, Texas, which might belong to a different region. The information is pulled over by the specialist, and because the standard allows for exchanging the XML style sheets as well, the medical summary document looks identical on the specialist computer screen as it was displayed on the physician’s screen. Imagine that the GI specialist refers the patient to the hospital for an exam. The department will schedule the procedure on yet another vendor’s system and upon arrival will generate an entry in the modality work list.
In the procedure room, a technologist or the physician will pull up the work list for patients that are scheduled. The modality will generate a DICOM query to do this and the patient demographics and procedure information will be retrieved and used to generate the DICOM header information of the images to be generated. The images from an endoscope typically are JPEG images, which are converted into DICOM Visible Light objects and are sent to a PACS system. In addition, the endoscopy information system might also generate a report with structured content, which can embed the JPEGS as thumbnails to illustrate the procedure. These documents can be converted to a PDF, which can be encapsulated as a HL7 version 3 document (CCD) and also sent to the archive. Making this information available to physicians inside the hospital is not as challenging, the real challenge is to make these available again to a physician who happens to use yet another practice management system in his office.
The workflow to make this happen is as follows: the PACS stores the images and creates a so-called manifest that is exchanged with the regional repository and registered with the regional registry. The manifest contains information about the study. The intention is not to duplicate all the images at the regional repository but having a pointer or reference to the PACS system in the hospital where the procedure was performed, and generated the original images. A common practice is that a physician identifies certain images as key images, especially as the procedure has a lot of images, such as a CT or MR exam, which could contain literally thousands of files. The key image reference will direct the physician to which of the thousands of images are the ones he or she should be looking at. Using the XDS-I protocol, a physician can pull the images, for example, using a thin client that plugs into a standard browser. Again, as I have seen demonstrated, this is yet another vendor’s product. Last but not least, when the patient is at home, he or she can pull the information into his or her personal health record or PHR.
The showcase described above was just one of the many that were demonstrated. The big challenge will be twofold for the manufacturers to roll out these capabilities into their new releases so that customers can upgrade their systems to provide this interoperability. Second, there are missing pieces in the infrastructure that have to be provided such as regional registries, repositories and edge gateways to exchange information between the different regions. It can be expected that the meaningful use requirement for the implementation of electronic health records will give this effort a major boost. Remember that one of the MU requirements is the exchange of information with other EHR’s. The good news is that the showcase demonstration has shown that interoperability has been solved technically. It is a matter of Dr. Blumenthal’s successor to solve the political barriers for implementation.
Herman Oosterwijk, VP OTech Media, live from HIMS2011