Diagnostic imaging and clinical information systems: An integration primer

Demand for diagnostic images outside the radiology department continues to grow. Time pressures among clinicians no longer allow for face-to-face case consultations with the radiologist. Patient safety and the interests of quality care, however, demand that clinicians have access to images at the point of care and in context of the complete patient record.

A picture is still worth a thousand words. But in most clinical settings today images are too hard to come by, isolated in their own silos, and owned by individual departments. Even when clinicians do have access to images, it is a rare organization that integrates them effectively with clinical workflow.

An enterprise vision

As more institutions adopt PACS and clinical information systems (CIS) -- including enterprise-wide order entry, electronic medical records (EMRs), and so on -- opportunities arise to close the loop in the core clinical workflows -- to deliver diagnostic images as an integral part of the EMR in conjunction with order information and diagnostic reports.

A comprehensive image-integration strategy enables the unified communication needed for collaborative care between radiologists and clinical providers, yielding more efficient enterprise workflow, better data integrity, and improved patient safety. To make this possible, integrated image functionality needs to be addressed at the enterprise level.

There is a great deal of confusion in the marketplace about what it takes to accomplish image integration, and what it means to be integrated. This article attempts to clear up some of this confusion, and helps provide some guideposts as organizations move toward this goal.

Caveat emptor (buyer beware): integrating systems is a complex task. While many vendors claim to be integrated or are willing to integrate, their definitions of integration vary widely. These variances often result in user dissatisfaction with the ultimate result.

There are various ways to categorize integration -- desktop versus server, standard versus custom, interfaced versus integrated, service level versus object level, Web-based versus database, and so on. There are also different types of data, including patient/visit demographics, orders, schedules, reports, and images.

For image integration, three systems are typically involved: a RIS, a PACS, and the CIS. In some cases, there may be multiple versions of the systems, particularly when it comes to PACS, such as mini-PACS and separate viewers.

The relevant standards

HL7 (Health Level 7): For the most part, HL7 is a set of server-based transactions that pass numeric and text-based data, after it gets saved in one system, to one or more other systems. The basics needed for image integration are admission/discharge/transfer (ADT) between the hospital information system (HIS) and the other systems, orders between the CIS and RIS, and reports from the RIS to the CIS (and perhaps to the PACS).

This is a "must have" feature, and most vendors really have it. However, HL7 interfaces are rarely plug-and-play, due to the many gaps and ambiguities in the standard. Although there are some standards for the exchange of reference data, vendor support for this capability is limited, and in some cases is not worth the trouble. HL7 comes in a number of versions and most vendors typically support version 2.1, 2.2, or 2.3, which are all fairly similar. Version 3 is radically different, and is not yet supported by most vendors.

DICOM (Digital Imaging and Communications in Medicine): DICOM is used for passing image-related data, usually between PACS and modalities, and also from PACS to PACS. Unlike HL7, DICOM is a fairly strict standard, which includes detailed conformance statements from vendors.

IHE (Integrating the Healthcare Enterprise): IHE provides a set of profiles describing what roles a system plays and what types of HL7 and DICOM transactions are supported by a system.

CCOW (Clinical Context Object Workgroup): CCOW is a standard to enable two or more desktop applications to have a single sign-on, and to ensure that they are both viewing the same patient at the same time. While most CIS vendors support CCOW, an organization usually needs to purchase a third-party context manager to make it work.

Most PACS vendors do not support CCOW. Although the latest CCOW standards mention exam-level context management, even CIS vendors do not generally support this. With or without CCOW, patient context is important for PACS users who need to use the CIS to view clinical data, and both patient and exam context are important for CIS users who need to view images. This is both a workflow and a patient-safety issue.

Custom integration flavors -- beyond the purview of standards

With all these standards in place, why do so many vendors invent their own solutions? In a nutshell, while the standards provide an excellent starting point, they only address certain pieces of the puzzle. The standards do provide a least common denominator integration level.

However, substantial workflow benefits can be achieved with custom integration that standards were not designed to address. Some custom methodologies used by vendors include:

Database level: This solution typically integrates products from a single vendor. Its meaning can vary widely. At one extreme, two products might share a single common database. While this scenario has many advantages, it makes it harder to separate the two products if the organization needs to replace one of them.

At the other extreme, it may be little more than HL7-type transactions that happened to be exchanged via database operations. One emerging solution, and the best option, is a federated database that allows the systems to be deployed together or separately, in a plug-and-play fashion, with functionality made available as each system is notified about the presence of the other system. Database integration does not, however, provide workflow integration.

Object level (application programming interface): This solution is usually offered by a single vendor or by technology partners. It may serve as a substitute for database-level integration, using objects as data sources. However, the real differentiator is that object-level integration can also operate at the user interface layer, allowing seamless workflow integration.

Service level: There is a lot of talk about Web services, extensible markup language (XML), and so on. Service-level integration does offer a number of technical advantages by addressing some of the communication plumbing and allowing the systems to be loosely coupled. Think of this as a well-structured way for systems to send and receive messages from each other. However, not much is being done yet that is relevant to image integration. Although service-level integration can help in many ways, the services provided usually cannot work together at a user-interface level to provide true workflow integration.

URL: This solution involves invoking a Web application, in this case an image viewer. It is easy to do a very basic launch, but the hard parts -- integrated security, context management, and a tight integrated workflow -- are less often (or rarely) done.

Essentials -- the goals and requirements

As a healthcare organization creates its image integration vision, the first question that needs to be addressed is what they are trying to accomplish, in both the short and long term. Once this is defined, the next step is to determine what integration pieces need to be in place to fulfill this vision.

Of course, needs vary widely among the disparate types of facilities, specialties, and department needs, but here is a common subset.

Primary integration goals for clinical users of CIS:

• Integrated workflow -- CIS plus image viewing
• Streamlined workflow -- usability benefits such as minimized clicks, screen transitions
• Consistent unified workflow regardless of image source
• Workflow appropriate for diagnostic image application -- easy to find what you're looking for
• Image viewing in conjunction with other clinical data -- lab values, medication history, clinical notes, and so on
• Unified display of images and reports with past, in progress, and future orders
• Patient safety foremost -- clear, understandable data and knowing what you're seeing and for whom
• Facilitated communication between clinician and radiologist -- collaborative care, annotations, and so on
• Availability of appropriate set of image viewing and postprocessing tools

Fundamental requirements needed to meet these goals:

• Interfacing or integration to support sharing the underlying text and numeric-based data. For the most part, this can be accomplished by standard HL7 transactions for ADT, orders, and results.

• Textual reports can be transmitted as HL7 results. However, for reports that include graphics, some other mechanism must be in place to either transmit the graphical report, or to allow an integrated viewer to access the report from its source.

• A means of embedding images or thumbnails into the user interface of the CIS to facilitate a more efficient workflow and a clearer understanding of what image sets are available for review.

• A single sign-on mechanism between the clinical application and the image viewer.

• A way of ensuring that patient context is maintained between the image viewer and the CIS. This is imperative to ensure that users cannot lose synchronization and mix the review of images and clinical data from different patients as they navigate in each respective system.

• A way of passing exam context from the CIS to the image viewer, and controlling access to the exams available for display in the image viewer. Access control must ensure that users only see what they are authorized to see.

• Response time should be virtually immediate.

• The system should be scalable to accommodate all anticipated uses and span the enterprise.

• Image quality needs to be appropriate for user needs. A user in the emergency department may need diagnostic quality images, while general clinicians may be able to use reference quality images.

Infrastructure -- the underpinnings

Common identifiers: Healthcare institutions need to have a clearly defined method of identifying a patient and an exam, both of which need to be shared among the CIS, PACS, and RIS. The exam identifier is usually an accession number, generated either by the CIS or the RIS, and shared via HL7 messages.

The patient identifier may be a trickier issue, but one that is worth solving at the enterprise level. In simpler cases, there is a single medical record numbering scheme used institution-wide, and this is used as the patient identifier. However, some sites have visit-based numbering schemes, and others may have more than one medical record numbering method as a result of multisite mergers. In these cases, another enterprise ID is needed to be used in all systems, for both past and present data. This may require data conversions.

Security: This includes user identification, authentication, authorization, and data transmission.

Bandwidth: Image viewing can require enormous bandwidth. The network needs to be able to support all the anticipated usage in a manner that doesn't compromise other applications.

Remote hosting: If the CIS application has a client component that is hosted remotely using Citrix (Fort Lauderdale, FL), Microsoft Terminal Server (Redmond, WA), or similar technology, this adds significant challenges to image integration. In these cases, the CIS user interface is actually running on a server in a remote data center, over a relatively low bandwidth wide area network (WAN) connection. The PACS would probably not be hosted remotely, due to its bandwidth requirements.

Without significant custom programming, if the CIS launches an image viewer, the viewer would also be running on those remote servers. When the viewer accesses an image, it would have to retrieve it across the WAN, and render the image display back across the network. This can be very slow, and can overwhelm the WAN. Solving this problem requires the capability to programmatically communicate between the CIS host and the client desktop, and to securely launch the viewer on the desktop while ensuring that patient context is maintained.

Frequently unasked questions

A healthcare organization may want to consider asking all its vendors the following questions:

• Is this interface unidirectional or bidirectional? Although reports usually only need to be unidirectional, orders usually need to go both ways.

• Is the viewer a separate application? Once it is launched, how does it communicate with the CIS? Is it really "fire and forget"?

• How do you maintain patient context? Does this require the purchase of another product?

• Is this context maintenance unidirectional or bidirectional (or perhaps multidirectional)? Maintaining patient context is critical, and if one component allows it to change, the others need to respond.

• Here is our institution's complete network diagram (including remote users), with link speeds, latencies, and current usage levels. How will your bandwidth requirements fit our environment?

• How do you handle single sign-on?

• How do you ensure that your solution is secure?

• What information needs to be manually maintained in multiple systems?

• How do you deal with historical exams? In-progress exams? Scheduled exams?

• How do you handle reports that include data from multiple systems?

• What version of your product supports each portion of your integration strategy (if RIS is hosted remotely)? Please explain in detail how the CIS running at the data center will communicate with a viewer running on the desktop.