The recent HIMSS 2007 annual conference highlighted the opportunities and challenges of achieving true plug-and-play capabilities in the health care field. As Yadin David, EdD, PE, CCE, said, “Most of what I see is still plug-and-pray; I can’t wait to see plug-and play!” This article will give you a better understanding of the three basic interoperability dimensions of the architecture that is being developed for health care within the Integrating the Healthcare Enterprise (IHE) program, described in earlier columns in 24×7 (June 2006 and December 2006).
IHE is an initiative by health care professionals and industry to improve the way computer systems and medical devices are used in sharing health care–related clinical- and process-oriented information. The three interoperability dimensions that the IHE addresses are: physical interoperability, enterprise interoperability, and domain interoperability, as described below.
Physical IHE Interoperability
Achieving physical interoperability requires mechanical, electrical, and software standardization. We are lucky today, because there are a number of well-accepted physical interoperability standards in the computer field, and these can meet a wide range of the IHE’s needs. Two commonly accepted examples can help illustrate this: the IEEE 802™ and USB™ standards. The IEEE 802 standards that most of us know best are used in many notebook computers: the CAT-5 Ethernet LAN system (IEEE 802.5™), the Wi-Fi (IEEE 802,11a/b/g™), and, in a growing number of situations, Bluetooth (IEEE 802.15™). The actual standards underlying these wired and wireless interfaces are available free at standards.ieee.org/getieee802/portfolio.html and www.usb.org/developers/docs/. Standards like these provide explicit details of the electrical, physical, and programming fundamentals that any developer or user must adhere to.
Because physical interoperability standards like those mentioned above meet the wide-ranging needs of many horizontal marketplaces, they are manufactured in very large quantities by many manufacturers, and their unit cost is so low that health care has little incentive to invent its own solutions. IHE generally presumes that hospitals have no need to invent their own novel physical interfaces and will use these existing commercial solutions.
|The USB standard is a well-accepted physical interoperability standard that can meet the IHE’s needs.|
This aspect of IHE interoperability covers common areas that virtually all health care applications need in order to successfully share data, and the task of each IHE framework is to specify the procedural and/or semantic coding systems that will be used by all systems. Some examples include patient and staff identity resources, audit trail management, user and node authentication, cross-enterprise document sharing, and consistent time services. Two of these, patient identity and consistent time, are discussed below.
Patient identity resources are particularly challenging for IHE, especially in US applications, where no unique patient identity numbers exist. Due to privacy and confidentiality concerns, our social security numbers cannot be used. Unfortunately, too, each of the multiple departmental- or clinical-task-specific information systems in a hospital (sometimes exceeding 150 different systems), is likely to use its own novel patient numbering. There is an IHE information technology infrastructure (ITI) technical framework document that addresses this, and it is known as PIX (patient identity cross-referencing).
In brief, PIX identifies a set of patient characteristics that includes items such as first name, last name, birth date, address, administrative gender, etc, to use to help match records from many systems to the correct patient. PIX uses standard codes and descriptions for these fields that are derived from the Health Level Seven (HL7) international standards (www.HL7.org). PIX helps deal with the question, “In which patient record should this particular piece of data be placed?”
The issue of patient identity management does not end with PIX, however, because health care’s life-and-death urgency demands service even if the patient’s identity is unknown, as in the case of a number of John and Jane Does who arrive at various emergency departments (ED) after an accident. By law, the ED cannot delay or refuse medical care to an unknown patient in a life-threatening situation, so one or more dummy patient records will have to be opened for the new arrivals. As emergency care is being delivered, the IHE systems are designed to segregate John Doe 1’s records from John Doe 2’s records. As soon as a John Doe’s true identity is known, the IHE framework describes precisely how the temporary records should be updated to reflect the real patient’s identity.
Consistent time also poses a unique challenge for IHE systems, because there is no existing technique to ensure all clinical documentation is date- and time-stamped correctly. A couple of simple examples can illustrate the problem that IHE’s consistent time tools address.
In the first case, consider a patient who requires hourly blood tests to ensure safe and effective multiple drug–cocktail dose management from several infusion pumps. If infusion pumps with internal clocks deliver the drugs, but the infusion pumps’ internal clocks are off by 10 to15 minutes from the real time, the data that is recorded into an IHE-enabled electronic health record may mislead a physician or nurse. This problem can be made much worse if the laboratory blood results are also time-stamped with yet a different internal clock. As with other IHE activities, the IHE-consistent time profile refers to an external agency (www.ntp.org) whose standards specifically address time synchronization for disparate systems.
In the IHE world, most of these enterprisewide requirements are addressed by the ITI, and all of those published frameworks are found in the ITI section of www.IHE.net.
Individual clinical domains such as cardiology, emergency medicine, patient care devices, and radiology have their own unique needs, which include specialized units of measures, unique workflows and process flows, and other attributes. For example, most radiological devices are fixed physical assets that are more or less permanently fixtured in a hospital, and the department or location in the hospital can be inferred if you know which device was used to create an image. By contrast, cardiology devices, such as echocardiology systems, are designed for mobile use, and can even be deployed at the patient’s bedside. Therefore, cardiology-specific IHE profiles may need to have flexible intrahospital location identification data attached to the patient data. In this case, the IHE profile may have to depend on an internal hospital coding standard for those identifications, because a national or international standard is not likely to match that institution’s.
As a second example, patient care devices such as anesthesia systems, ECG monitors, infusion pumps, and ventilators all use particular units of measures to describe their clinical records. Rather than define a new units-of-measure standard identification system, the IHE patient care domain (PCD) has adopted the IEEE/ISO 11073x standards, where such standards exist.
A third and final example of domain interoperability is one of those “the devil’s in the details” cases: identification of clinical gender. In the PCD, there are five different HL7 genders specified: male, female, other, ambiguous, and N/A. Here, flexibility is essential, because the data could be used for cardiac output, radiation/drug dosing, or other calculations, and an inaccurate gender identification could cause a patient safety risk.
This article is intended to take some of the mystery out of the IHE technical framework for clinical engineers and biomedical equipment technicians. All of the published technical frameworks are available at no charge through the www.IHE.net site. In addition, the upcoming frameworks in progress are listed at the site. As IHE-compatible systems are deployed in more health care settings, you will find these published documents are quite clearly written and complete. When you use the framework documents, though, remember that the three interoperability categories—physical, enterprise, and domain—must all be considered and used together in order to understand how the system should operate. Lastly, your input into the development of these frameworks is essential. The committees are open to anyone, so let us know if you are willing to contribute your expertise.
Elliot B. Sloane, PhD, Villanova University; cochair HIMSS/RSNA/ACC IHE Strategic Planning Committee; cochair ACCE/HIMSS IHE patient care device domain. For more information, contact .