It is hard to underestimate the impact and importance of the IHE (Integrating the Healthcare Enterprise). However, there are a lot of unknowns and an under appreciation of the effect IHE has, especially on potential workflow improvements and increases in efficiency. Therefore, I’ve compiled this (limited) list of benefits. There are many more benefits than listed here, but these are the most important. This is an abstract of an IHE presentation at HIMSSME in April in Jeddah, Saudi Arabia. You can also watch a video of the presentation here.
|The Interoperability Showcase was |
very well attended
1. To increase the chance of plug and play: In general, the standards that form the foundation for the IHE have too many options, the reason being that most of them are developed as part of a semi-democratic process, which makes sure that all stakeholders (read vendors) can be facilitated, i.e. none of them are greatly benefitted and none of them severely handicapped by the choices that are made during the standardization process. However, in practice, most people go overboard with creating these standards such as DICOM and HL7. There is typically no thought given to determining what is the minimum necessary, but rather, what “might be nice” to have. The effect is that the ADT family of messages has grown to include 60 messages, each of 20 segments, with an average of 30 fields, resulting in 600 data elements. A similar feature creep has taken place with the DICOM standard, where a work list at a modality can contain up to 120 attributes according to the standard. IHE reduces these options greatly, for example, the IHE Scheduled Workflow Profile (SWF) definition limits the 600 HL7 attributes to 39 as part of 4 messages. The DICOM Worklist is also limited i.e. 42 instead of 120 attributes are specified as part of the SWF profile.
2. To reduce on-site testing: The connectathons, where hundreds of vendor representatives get together for a week and test literally thousands of use cases is definitely reducing the integration time for these systems on-site. My guess is that the productivity for testing a system at a connectathon is at least twice, if not higher, than having to figure out the problem at a customer site. The other advantage is that these test environments provide a level playing field, i.e. small vendors have an equal opportunity to test their systems with one of the major players as the big guys in this field. Another major by-product is the widespread availability of test tools, test transactions and test images in the public domain that are created as part of this effort and are available to test against.
3. To provide a simple selection mechanism: I always like to compare the IHE profiles with the fast food “value meal” choices, i.e. instead of having to think about the exact configuration of your hamburger and what type of sides or drink size, you can just pick a meal number. Choosing IHE profiles is similar, instead of having to specify what list of DICOM or HL7 transactions, and what attributes should be supported, one can just specify “profile x.” The Scheduled Workflow (SWF) profile for the modality actor is a good example. If a modality supports SWF, you can count on it supporting the Modality Worklist, Storage, Modality Performed Procedure Step and Storage Commitment functionality. There is only one (or at most a couple) of boxes to check off when considering purchasing a device instead of having to include pages of interface specification requirements.
4. To eliminate gaps and overlaps in functionality: In addition to the fact that no two RIS or PACS systems are equal, vendors also like to come up with very creative non-descriptive names for their system components. It is confusing for their customers who are wondering what exactly a workflow manager, connectivity manager, intelligent router, gateway. or broker does, and more importantly what it does NOT do. This also adds to the current confusion on what is exactly a VNA does. If one is very specific about which profiles are supported in what function, there is no confusion about, for example, whether or not image deletions and corrections are automatically communicated between a PACS and VNA using the IOCM (Information Object Change Management) profile. Similarly, there is no confusion on whether one can connect a univiewer to that same VNA using standard DICOM RESTful services for web access, or that information that is archived is registered to a regional repository using XDS. I understand the urge of vendors to use nice sounding names, but in my opinion it confuses users more than it actually helps.
5. To address workflow, including exceptions: Integration profiles are defined based on real-life use cases. These use cases address real-life problems such as the performance of an exam, creation of a report, exchange of a discharge document, retrieval of a set of documents by a physician, etc. To support these workflows, the IHE committee picks the minimum necessary services and tools to do this in the most efficient manner. As a matter of fact, I would argue that if every institution would implement these workflows and fully utilize their features, there would be a major improvement in efficiency and productivity. Knowing that real life situations do not always follow the same rules, there are also several profiles defined to address exceptions and corrections to reconcile patient information later on, or deal with unscheduled cases.
6. To address display requirements: Communications standards such as DICOM and HL7 typically do not focus on how information is presented, but rather on the reliable exchange of the information. This causes major issues with regard to performance and functionality. For example, the capability of receiving digital mammography images at a workstation is useless unless the same workstation is able to display these in exactly the order needed for interpretation. In the case of digital mammography, the same view is presented with one mirrored and displayed against each other with the chest wand. In the case of nuclear cardiology the images are also displayed in a certain order and one should be being able to change the different windows in a specific way. Not only the presentation of the images is critical, the persistency and consistency in greyscale and color rendering is even more important. Modality specific profiles are created to address this issue.
7. To re-enforce the standard: Some parts of the standard were so poorly implemented that a profile definition that specifically calls out these requirements is very helpful. This is the case with the Portable Data for Imaging (PDI) profile that addresses the exchange of images on CD’s and DVD’s. This profile reiterates the requirements as stated in the DICOM standard about making sure that there are DICOM encoded images being exchanged, not some proprietary version of the images, which can only be viewed by the embedded viewer, and that there is also a DICOM DIR included providing a directory of the images stored on the media. A related profile is the IRC profile that basically takes care of reconciling the image information that is being imported in the PACS with a new or existing patient, who can be uniquely identified without jeopardizing the information integrity of the PACS.
8. To provide a shared infrastructure platform: Many applications have similar needs with regard to patient information management: security, including access controls and audit trails, personnel management, such as the availability of provider names, unique identifiers, and many more services that can be shared, and more importantly, be implemented in a single standardized manner. For example, there is no reason that an audit trail for a physician accessing a diagnostic image should be implemented, recorded and accessed by a system administrator differently than an audit trail for someone accessing a lab result or any electronic medical record. Defining a unified set of profiles to deal with this in the form of the ITI (IT Infrastructure) domain is a great asset and will lead to efficiency because of its re-usability and economy of scale.
9. To provide enterprise and regional exchange capabilities: Even though the information exchange mechanisms to the outside, using cross enterprise document sharing profiles, is considered part of the ITI (although for imaging it is included in the radiology domain), it is still important enough to be mentioned separately on its own merits. Registration and access of medical information is critical for the sake of patient safety, and to reduce costs due to duplicate tests and procedures. In addition, we really don’t know yet what the impact will be of having all that information available for outcome measurements and decision support, but I am sure we will find a way to use this “big data” in a way to benefit patients and improve the overall efficiency of healthcare delivery.
10. To exchange information about images: Using DICOM, we can create a very simple object that refers to one or more other objects such as images, and tell something about these objects in a standard manner. It is encoded as a DICOM Structured Report (SR). A good application of this feature is to point back to “key images” so that a physician knows which images to review. This could be a major help during surgery, for example, to be able to pull up just a few images out of a set of potentially thousands of axial CT slices. Another application would be to exchange information between an archive and any other location where there might be a copy of its images, to determine if the image needs to be deleted, or replaced or changed in any way for synchronization purposes.
This list of the top ten advantages or reasons to use IHE could easily be larger but these are probably the most significant. Again, if you are more of a visual or auditory learner, I suggest you check out the more complete version of this write-up here. Details about the individual profiles can also be found in my blog postings, you can just search for the appropriate keywords, or at OTpedia. Enjoy!