Ringholm-Logo Ringholm
Ringholm page header

The seven levels of PACS integration

The contents of this whitepaper are public domain.
See http://www.ringholm.com/docs/02040_en.htm for the latest version of this document.
Author: Herman Oosterwijk - president of OTech Inc. [OTech]
Document status: Final, version 1.0 (2004-04-22)
Adapted from the "PACS Handbook" written by Herman Oosterwijk.
Please sent questions and comments to herman.oosterwijk@ringholm.com


PACS integration means different things to different people. One can distinguish between seven different levels of integration, ranging from No Integration up to API Level Integration. The current trend seems to gravitate towards the use of messaging standards (e.g. DICOM) and integration profiles (e.g. IHE). All integration levels have their advantages and disadvantages.

1. Introduction

When people think about PACS integration, they typically seem to relate it to the type of integration that is covered by Integrating the Healthcare Enterprise (IHE) effort [IHE]. Integration means different things to different people.

Some vendors claim that their system is seamlessly integrated, only to find upon closer inspection that they indeed use interface boxes, or conversion software between the systems. Other applications are totally integrated. A claim by a vendor that they support DICOM [NEMA] doesn't necessarily mean that the system can be integrated into a PACS.

This whitepaper discusses the different levels of integration, their advantages and disadvantages, the role of standards, and current trends.

2. Levels of System Integration

Within a PACS system one can distinguish six levels of integration (and one level of non-integration):
  • Level 1: API Level Integration
  • Level 2: Procedure-Call Integration
  • Level 3: Messaging Integration
  • Level 4: Integration Profiles
  • Level 5: Context Integration
  • Level 6: Physical Integration
  • (Level 7: No Integration)

2.1 Level 1: API Level Integration

This type of integration resides on a computer, and links two software applications. It is called API (Application level Programming Interface) level integration because the interface consists of a well-documented software library.

A good example of this interface is a scheduling application/database that talks with a DICOM Toolkit software package, to provide a DICOM Modality Worklist, which contains a schedule for a particular modality. This is the tightest integration level possible.

2.2 Level 2: Procedure-Call Integration

In this case, an application on a device, issues a remote procedure call, or a standard command such as a SQL (Structured Query Language) to another application. An example is a PACS workstation, issuing a SQL query, to a PACS archive having an Oracle database, requesting a list of the studies for a particular patient including study date, modality type, and number of images, displayed in a mini-image (postage stamp) directory for a physician.

This is a rather tight integration because the workstation must know the exact database scheme, and supported record in order to be successful. Except for the fact that SQL is an ANSI accredited, standard database language, the user must know a lot of information about the particular software product, requiring intimate knowledge of the vendors� specifications.

2.3 Level 3: Messaging Integration

This level of integration is probably most familiar to people. It is achieved by using standard messaging, and protocols between applications, such as DICOM for imaging; or HL7 for patient demographics, orders, and results.

An example is the usage of an HL7 order message from an order entry application to a scheduling system. In principle, vendor A, providing the order entry software, does not need to know anything about the specifics of the scheduling software provided by vendor B, but must know sufficient detail about what type of HL7 message it supports.

Figure showing the 7 levels of integration
Figure 1. Levels of integration

  Details Users increasingly want their PACS system and workflow manager to support DICOM services with the same functionality as they provide to their other products sold by the same vendor.

For example, DICOM just standardized the general purpose Worklist service whereby workstations can access the list of exams to be read, update the reporting status, and exchange information about the data needed for the reporting.

Supporting messaging standards alone is not sufficient. Efforts are being made to define additional profiles such as defined by IHE, and to require vendors to support these.

Unfortunately, there is a lot of variation in HL7 messaging, often requiring the usage of interface engines to map certain HL7 attributes to those required by the receiver. The good news is that ongoing conformance activities within the HL7 standardization are addressing this, and the new version of HL7 3.0 it is much tighter defined.

DICOM messaging is better defined, and DICOM-compatible devices require a conformance statement, which exactly defines, in a pre-described format, the services, and messaging content.

2.4 Level 4: Integration Profiles

Just supporting a messaging standard is not sufficient: the definition of standard �profiles�, defining a specific subset of the standard is required to enable seamless integration.

An example of this integration is the usage of a DICOM Modality Worklist and Performed Procedure Step to exchange patient demographics, and scheduling information from a scheduling system to a modality such as a CT or MRI, and image management information to the PACS.

The IHE integration profile specifies exactly which attributes, i.e. information should be exchanged, the timing of a service in relationship with other DICOM services, and even mapping between different standards, i.e. DICOM and HL7 messaging.

2.5 Level 5: Context Integration

This level is similar to the previous one. One could actually argue that it is the same, because two applications also exchange messaging. However, the applications by themselves are more disjoint than when using standards such as DICOM or HL7.

An example is a physician workstation that runs multiple applications, such as an image viewer, a viewer to display EKGs, and one that displays lab results. The information exchanged among these applications is limited to their context information.

A �context manager� functions as an intermediary, passing any context changes between applications. For example, as soon as a physician switches from Mr. John Smith to Mrs. Jones on the image viewing directory, the application signals the context change to the context manager which passes it to the other application so it also automatically displays the EKG, and lab tests for Mrs. Jones.

As with Messaging Integration, vendor A, who provides the imaging software, does not require knowledge of the lab, or EKG system from Vendor B, but can use the information exchange as defined by the CCOW (Clinical Context Object Working group) standard.

CCOW is not only a blessing for a user who wants to integrate different applications on a single desktop, it also enables vendors who are consolidating to offer software packages that were developed by different companies, to show a somewhat integrated view.

2.6 Level 6: Physical Integration

This level integrates the physical hardware, typically only sharing the operating system that run the applications. This type of integration is critical in many departments due to space and power restrictions.

With the increase in computing power, memory and disk capacity, there is rarely a reason to have more than one computer monitor at a worksite. A good example is a dictation system using speech recognition, which until recently required its own processor, but can currently run on the same platform as a viewing station.

2.7 Level 7: No Integration

One might wonder why this is even defined as a level at all. The reason is, to highlight these occurrences, and make the user aware of these so he can work with a vendor to start the migration of these systems to a higher level of integration.

It is unfortunately not uncommon to see more than one monitor and/or computer on a physician�s desk. As a minimum, some level of physical integration would prove beneficial.

  Details What is the role of standards in these different levels of integration?

Without the messaging and profile-level integration, the communication between Information Systems and Modalities, Workstations and other PACS components would all be proprietary.

For example, Japan, has a lower penetration of DICOM for PACS, because many vendors provide complete systems that are tightly integrated which hospitals seem perfectly happy with.

Similar situations exist in Europe, where in some countries the institution by default purchases from one single (usually domestic) vendor.

3. Advantages and Disadvantages

Advantages and Disadvantages of the Different Integration Levels include:
  • Reliability: As a general rule, the tighter the integration, the higher the reliability.

    For example, a Radiology Information System (RIS) passes scheduling information in the form of an HL7 message to an interface box (commonly known as �broker�). The box then serves modalities requesting a DICOM Modality Worklist for their daily exam schedule.

    Compare this to a RIS that has an API to a DICOM application that provides the Worklist directly to the modality, without having an extra to perform HL7 to DICOM mapping. There is no question that scenario two is more reliable because yet another box increases the chance for hardware failure.

  • Single Point of Failure: A tightly integrated system, consisting of relatively few components is risky because if one part goes down, more of the features and functions are affected.

    Imagine a single image manager/archive that serves all of radiology, the physicians in their offices, as well as the radiologists that read the images from their home. If for some reason this system goes down, no-one has access to any images. In contrast, if an institution provides a web server in addition to the image archive, a physician can still view images from their office, or home even if the main archive is down.

    One could argue however that the same level of availability can be achieved by a tightly integrated system, e.g. by having a dual processor, back-up storage, hot swappable drives, etc. However, it is necessary to make sure that the architecture allows for this, and that the system is configured accordingly. Given the option, most customers are tempted to purchase more workstations, or other additional features, instead of, for example, a dual database archive/server for system backup.

  • Cost: This is difficult to assess, as there does not seem to be an increased cost when purchasing a tightly integrated system from a vendor.

    One of the advantages of a more loosely connected system is that it allows for using components such as monitors, and workstations from different vendors. This could provide cost savings, however, the cost of testing, and integrating foreign components increases.

4. Conclusions

What is the current trend? As shown in the Figure below, the integration seems to gravitate to the center levels, i.e. towards the messaging and profiling levels (levels 3 and 4), and from physical integration to context integration (level 6 to level 5).

Figure showing the trend in PACS integration towards levels 4 and 5
Figure 2. Trends in PACS integration

The push to context integration (level 5) is caused by:

  • the need to provide physical integration for the different applications that are currently running on different platforms, and for different applications to exchange context information;
  • institutions that understand the importance of integration, and are starting to require all their applications to support CCOW.

The ultimate goal of integration is to facilitate an Electronic Health Record (EHR) whereby a user can access the complete patient record from a single location, which today is typically a terminal, but tomorrow may be by wireless PDA. This will allow a physician to be able to assess a patient from an integrated view, having access to not only lab tests, but also dental records, diagnostic images, previous reports, etc. This fits the trend that physicians are starting to look at a patient as a whole whereby realizing that an infected tooth can cause a headache, impact the person�s laboratory result, or even affect vision and hearing. The support of standards and the converging of the different integration levels to profiles is critical to make this happen.

5. References

[IHE] "IHE Radiology Technical Framework", http://www.ihe.net
[NEMA] "Digital Imaging and Communications in Medicine", http://medical.nema.org
[OTech] http://www.OTechimg.com/

About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.