When people think about picture archiving and communications systems (PACS) integration, they typically relate it to the type of integration that is covered by the Integrating the Healthcare Enterprise (IHE) effort. In addition to IHE, however, there are different levels of integration that could be beneficial, depending on the application. These different levels of integration have their own advantages, disadvantages, and places in the health care enterprise, as well as their own relationships with industry standards. Within a PACS, one can distinguish seven levels of integration (Figure 1).

1 APPLICATION-LEVEL INTEGRATION

This type of integration resides within a computer, typically between two software applications. It is called the application programming interface (API) level of integration because the interface consists of a well documented software library. A good example is the interface between a scheduling application/database and the Digital Imaging and Communications in Medicine (DICOM) Toolkit software package with which it communicates in order to provide a DICOM modality work list containing the schedule for a modality (such as a CT scanner). This is as complete an integration as one can obtain.

Figure 1: Levels of Integration

2 PROCEDURE-CALL INTEGRATION

In this case, an application resident on a device issues a remote procedure call or a standard command, such as a structured query language (SQL) command, to another application (typically resident on another device). For example, a PACS workstation might issue an SQL query to a PACS archive having an Oracle® database. The request could be for a list of the studies archived for a particular patient, with results to include the study date, the modality, the number of images in the study, and a miniature image (postage stamp) to be displayed in a directory listing for a physician. This is rather tight integration because the workstation has to know exactly what the database scheme is, and which records are supported in this database, in order to be successful. Despite the fact that SQL is a standard database language accredited by the American National Standards Institute, this level of integration calls for considerable information about the particular software product, requiring intimate knowledge of the vendor's specifications.

3 MESSAGING INTEGRATION

This level of integration is probably familiar to most PACS users. It is achieved by using standard messaging and protocols between two applications, such as DICOM for imaging; Health Level 7 (HL7) for patient demographics, orders, and results; or X12 for billing. An example is the use of an HL7 order message from an order entry application to a scheduling system. In principle, the vendor providing the order-entry software does not need to know any specifications of the vendor providing the scheduling software because there is sufficient detail available by knowing what type of HL7 message the software supports. Unfortunately, there is quite a lot of variation in HL7 messaging, often requiring the use of interface engines to map certain HL7 attributes to those required by the receiver. The good news is that there is a conformance activity within HL7 standardization that tries to address this; in addition, the new version of HL7 (3.0) is much more tightly defined. DICOM messaging is better defined, and DICOM-compatible devices require a conformance statement that exactly defines, in a prescribed format, the services and messaging content.

4 INTEGRATION PROFILES

Supporting a standard is not sufficient: the definition of standard profiles by identifying a specific subset of the standard is a requirement for seamless integration. An example of this type of integration is the use of DICOM modality work list and performed procedure step to exchange patient demographics and scheduling information among a scheduling system, a modality, and a PACS. The IHE integration profile specifies exactly the attributes that are involved, the information that should be exchanged, the timing of a service in relation to other DICOM services, and mapping between different standards (such as DICOM and HL7 messaging).

5 CONTEXT INTEGRATION

This level is similar to the previous one because two applications also exchange messages. The applications themselves, however, are more disjointed than when using standards such as DICOM or HL7. For example, a physician workstation might run multiple applications to display images, electrocardiograms (ECGs), and laboratory results. The information that these applications exchange is limited to context data (information about the particular patient whose health care data is being displayed). A context manager functions as an intermediary, passing any context changes through between the applications. For example, as soon as a physician switches from John Smith to Mary Jones on the image viewing directory, this application signals the context change to the context manager, which passes it to the other applications that are registered with the manager, so that they also automatically display the ECG and laboratory-test results for Mary Jones. As with messaging integration, the vendor providing the imaging software does not have to know any of the details of the laboratory and/or ECG systems from other vendors, but can use the information exchange as defined by the Clinical Context Object Workgroup (CCOW) standard, which is actually a part of HL7. CCOW is not only a blessing for a user who wants to integrate different applications on a single desktop, but a great help to vendors consolidating software packages that were developed by different entities; CCOW enables the vendor to offer a somewhat integrated view.

6 PHYSICAL INTEGRATION

This level integrates just the physical hardware, typically sharing only the operating system that the applications run. This type of integration is critical in many departments due to space and power restrictions. With continuing increases in computing power, memory, and disk capacity, there is almost no reason to have more than one computer and/or monitor on a desk. For example, a dictation system using speech recognition required its own processor not too long ago, but it can now run on the same platform as a viewing station. It is, unfortunately, not uncommon to see more than one monitor or computer on a physician's desk; at a minimum, one would want to achieve a least physical integration.

ADVANTAGES AND DISADVANTAGES

The general rule is the tighter the integration, the higher the reliability. Imagine a radiology information system (RIS) that passes scheduling information in the form of an HL7 message to an interface box, commonly known as a broker, which then serves modalities that request a DICOM modality work list for their daily examination schedules. Compare this with a RIS that has an API to a DICOM application that provides the work list directly to the modality, without having an extra box involved. There is no question that the second arrangement is more reliable because every additional box increases the possiblity of hardware failure.

A tightly integrated system consisting of relatively few components has a higher risk factor, however: if one part goes down, more of the system's features and functions are affected. Imagine a single image manager/archive that serves all of the radiology department, the referring physicians in their offices, and the radiologists who read images from their homes. If this system goes down, no one has access to any images. In contrast, if one has, in addition to the image archive, a web server that stores images for the physicians' homes or for various departments, one can still access the images from this server, even if the main archive is down. One could argue, however, that the same level of availability can be achieved in the tightly integrated system by having a dual processor, backup storage, or hot-swappable drives. Of course, one has to make sure that the architecture allows for this and that the system is configured accordingly.

The cost of integration is difficult to assess. There does not seem to be a large difference in cost between PACS from vendors that offer a more tightly integrated system and from vendors that offer the opposite. One of the advantages of a more loosely connected system is that it may allow for the use of components from different vendors. These can range from monitors to completely different workstations. While this could lead to cost savings, it increases the cost of testing and integrating these foreign components.

THE ROLE OF STANDARDS

Without messaging and profile level integration, the communication among information systems, modalities, workstations, and other PACS components would all be proprietary. Is that necessarily bad? The answer depends on the situation. For example, Japan has a low penetration of DICOM for PACS because there are vendors that provide tightly integrated, complete systems that the market accepts. A similar situation prevails in Europe, where, in some countries, the institution purchases from a single (usually domestic) vendor by default. For the user, features and functionality are often more visible than integration. A radiologist sees an image appearing on a workstation; he or she does not necessarily care (or even know) that the image was retrieved using a SQL command or a DICOM query/retrieve. If the same radiologist goes to an ultrasound miniPACS workstation and the annotations that were saved on the main PACS workstation are not displayed, then he or she may become upset.

CURRENT TRENDS

As shown in Figure 2, integration seems to gravitate toward the center (messaging and profiling) levels. There is a push from no integration to ward physical integration (from level seven to the sixth level) backed by the users of applications running on different platforms. There is another push favoring the exchange of context information (that is, movement from the sixth level of integration to the fifth) supported by institutions that understand the importance of integration. These organizations are likely to require all of their applications to support CCOW. More and more users also want the vendors of their PACS archive/image and work-flow managers to support DICOM services with the same functionality that they provide for their own products from the second level to the third) . For example, DICOM recently standardized the general purpose work list service so that workstations can access the list of examinations to be read, update reporting status, and exchange information needed for reporting with other system components. It should be remembered that to support messaging standards alone is insufficient; consequently, there is a major effort to define additional profiles (a move from level three to level four) and require vendors to support these.

Figure 2: Integration Trends

The ultimate goal is to facilitate creation of an electronic health record, allowing a user to access the complete patient record from a single location. Today, this location is typically a terminal; tomorrow, it could be a wireless handheld device or a computer built into the user's watch, eyeglasses, or clothing. This unprecedented access will allow a physician to assess a patient using an integrated view incorporating laboratory tests, dental records, diagnostic images, previous reports, and more. This fits well with the trend favoring assessment of the patient as a whole (for example, an infected tooth can cause a headache, affect laboratory results, or worsen vision and hearing). The support of standards and of the convergence of the different integration levels is critical to making whole-patient assessment happen.

Herman Oosterwijk, a participant in the DICOM and HL7 standardization efforts, is president of OTech Inc, Aubrey, Tx, a health care technology consulting and training firm. Information about standard related products and seminars can be found on www.otechimg.com. Questions can be addressed to herman@otechimg.com.