The seven levels of PACS integration

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

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

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.

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 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.