Despite the growing number of health care facilities with high-tech machines and multigigabyte medical databases, the fact remains that considerable information work flow is paper-based and distributed by hand. The challenge facing the medical industry is that many automated solutions have been implemented departmentally. Most facilities live with a legacy of disparate systems that now need to communicate with each other if digital work flow throughout the medical enterprise is to be realized. One piece of the puzzle that must be in place is the integration of the hospital information system (HIS), the radiology information system (RIS), and the picture archiving and communications system (PACS).
The benefits of integrating the HIS and RIS into imaging systems or a PACS are many. The first meaningful benefit is the automation of Digital Imaging and Communications in Medicine (DICOM) modality work lists (DMWLs). When an order is entered into the RIS, the patient information is automatically available at the modality. This greatly increases the accuracy of the data entered during each examination and significantly reduces the time that a PACS administrator needs to spend correcting mistakes. Having the patient information automatically available at the modality avoids entry errors in patient names or identification numbers and eliminates orphan studies. Billing accuracy is improved, efficiency is enhanced, and historical study information is available with future examinations.
The true beneficiary of an automated DMWL is the patient. When patient information is accurately matched with imaging data, the PACS can automatically present relevant prior examinations for that patient with the current study. Information richness is improved because radiologists have both clinical data and imaging data as they read a study and render a diagnosis. When this information is at a radiologist’s fingertips, findings can be determined more quickly and results can be delivered to the referring physician sooner. The effective management of results is also possible with the marrying of PACS and RIS. As a referring physician reviews a radiology examination result, his or her decision making is enhanced by the availability of prior reports along with the current study’s data.
STANDARD AND BROKER APPROACHES
HIS/RIS installations today are designed to use the widely accepted Health Level 7 (HL7) standard introduced by the Healthcare Information and Management Systems Society. The HL7 standard allows for communication between information systems and many other components within the health care enterprise. Digital modalities have been using the DICOM standard to facilitate the transfer of images over networks for over a decade. For HL7 and DICOM to come together, the two standards need a translator. This function can be embedded on the either the information-systems side or the imaging-systems side. The function can also be housed in a bridge/broker that makes the necessary conversions from HL7 messages to DICOM data (which can be understood by the PACS).
The focus of the Integrating the Healthcare Enterprise (IHE) initiative is to present a framework of guidelines for integration and communications between vendors. These guidelines are not meant to replace the standards of HL7 and DICOM, but, rather, to provide seven Integration Profiles that better define how the standards are implemented. The IHE initiative has helped vendors become more aware of the need for integration, and successful examples of integration have been demonstrated at industry meetings. Participating vendors can interoperate with many others in an environment that allows engineers to work together.
Should an institution choose a single-vendor solution, employ an independent broker interface to provide the integration services, or use brokerless devices? This question should be considered carefully before the organization’s RIS/PACS solution is defined. Many RIS vendors are branching into PACS, and most PACS providers have an HL7 integration engine of some type or a RIS solution of their own.
The external translation engines, or brokers, can offer a flexible solution, with the freedom to cross-connect several vendors’ systems. They also have the longest list of tested and supported platforms, both DICOM and HL7.
The challenges for most facilities are the cost of adding a broker and the time needed to build a historical database. These independent broker devices have data repositories of their own. While that offers flexibility, it also requires the historical data that will be collected by the broker to be identified and organized within the HIS/RIS before the information is copied or sent to the device.
At first glance, a single-source solution appears to be a good idea in terms of interoperability. One would assume that this should be the most robust and tightly integrated solution. It is important to consider, however, that this solution is often the mating of two entirely different support and engineering divisions (many times, with roots in different companies that have been merged). One of the two standards, HL7 or DICOM, is most likely to be the company’s core competency. For this reason, the institution should carefully examine whether it will be delivered the best of breed for both the RIS and PACS solutions. If the merger has happened in the previous year, the potential buyer should also determine how much true field-tested integration the vendor has accomplished. If the organization decides that a single-source solution is best for its needs, it will probably gain an advantage because a single account team will be responsible for both the RIS and the PACS, and configuration data would be understood for both systems. Finger-pointing being eliminated, the single-source solution might then carry less risk of delay in correcting unforeseen data-specific coding problems.
Brokerless interfaces offer the benefits of both worlds. In this situation, the RIS and PACS are integrated without an interface engine needed to broker the translation between HL7 and DICOM. This can be as simple as a scaled down HL7-to-DICOM translator, or as robust as true bidirectional communication between systems. In this situation, each vendor supports the application it knows best, with the additional benefit of tighter integration between the RIS and PACS, bringing images and corresponding clinical information together. Since brokerless integration is specific to the two vendors involved, these solutions may still require a broker in a large multivendor enterprise installation, where several legacy HIS must communicate with the PACS.
READINESS TO INTEGRATE
Although they are manageable, there are some issues that must be addressed for any integration effort to be successful. The details of how the RIS and PACS will be used must be worked out, and work flow should be carefully defined. There are six key areas that must be considered:
- RIS/PACS capabilities
- modality readiness
- data-entry standards
- work-flow changes
- long-term data use, and
Understanding each existing system’s capability is very important. For example, if one of the integration goals is to have report-viewing capability at radiologists’ workstations, can the data from the image work list be used to build the RIS and broker query? The buyer should also ask the PACS vendor whether the PACS can use HL7 messages to automate demographic corrections. Can these messages be used to prefetch image data from long-term storage before the examination to improve overall performance?
There are a number of things that should be confirmed with the HIS/RIS vendor. For example, the HIS/RIS is designed to send out HL7 data, but are the hardware and software necessary to enable that output installed? How much do these modules cost? Which HL7 transactions can be forwarded (patient, study, and results)?
Whether the organization is purchasing a PACS to be integrated with an existing RIS or vice versa, understanding the current capabilities of the existing technology will help the institution to select the vendor most able to complement the current situation. The PACS/RIS integration will be much smoother when unexpected challenges are minimized.
Many digital modalities are compatible with DMWL. If the modality is not DMWL enabled, that capability can usually be purchased as an add-on package. Having DMWL compatibility available and understanding how the device uses work lists will ensure that expectations are correctly set, and will also give the implementation the highest probably of success. Organizations should be certain that they know which elements of DICOM are required and whether the device providing the work list, whether it is a broker or a module within the RIS, can provide these elements. Understanding which data fields are critical to the institution and making sure that vendors support these fields can prevent delays and the need to work around trouble spots.
Several key questions should be answered. How will this change modality work flow? Since work flow is largely built around the features and limitations of the hardware, will this new feature save any time or steps? Are all devices on a common network that can be served by a central work-list server? What is the plan for devices that are not DMWL-enabled? Will these be upgraded or, possibly, replaced?
One of the most common problems faced in RIS/PACS integrations is data inconsistency. It is quite common for the PACS and HIS/RIS to use the same data in different ways. Sometimes the differences are minor. For example, the leading zeros of a Medical Record Number are not used in a PACS, but are used in the HIS/RIS. In other situations, more serious differences exist. Accession numbers are often a challenge. Many modality vendors use accession numbers as unique identifiers of an examination. Often, these numbers are not used in the PACS or HIS/RIS at all. Some modalities only use a very small data set of the available work list; is this enough? Supported fields are outlined in each vendor’s DICOM Conformance statement and should be reviewed with prospective work-list vendors.
Work lists can make data available that would once have been too difficult to manage. Patient location and referring physician are examples of data that can be supported using a work list. These fields can be important, especially if the institution plans to implement automated results distribution. It will have powerful tools available in the DICOM data and should plan to leverage this to enhance work flow and improve the services that it provides to the referring community.
Once the integration implementation is complete, the matter of historical data must be addressed. Any information residing on the PACS that was acquired before DMWL capability was in place may be missing data and was subject to common data-entry error occurrences. The organization should confirm that its PACS vendor offers tools to help it identify and correct these problems.
Elements of Success
The factors that lead to success are highly dependent on the short-term and long-term goals of the enterprise. A phased approach is often the best way to tackle any integration project. A realistic expectation level for progress can be gained by working closely with vendors, who can help the organization understand the requirements and details of the project. Since improved work flow is the ultimate result of RIS-PACS integration, it makes sense to maximize that benefit through careful planning and data mapping. Institutions should look for potential trouble spots that might be caused by missing or unused data fields and should ask their HL7 and DICOM vendors for suggestions on how to minimize these problems.
Testing is critical to success. Tests should be plentiful and should cover a wide range of HIS/RIS message types and procedures, in addition to covering as many modalities as possible. When working with multiple vendors, bringing them together in conference calls or meetings helps facilitate the coordination of effort. With close cooperation, issues can be resolved to everyone’s satisfaction. With proper planning, open lines of communication, and clearly defined work-flow goals, RIS/PACS integration is within an institution’s reach.
David Tomczak is director, systems integration and services, eMed Technologies, Lexington, Mass.