 Jim Herrewynen |
Proper planning minimizes the impact of integration. This is crucial to understand. Even at the request for information (RFI)/request for proposal stage of the process, we try to prepare organizations for the requirements and basic needs that they must meet in order to implement a picture archiving and communications system (PACS). They need to know how the implementation is going to change and enhance their work flow. There are going to be changes made not only to the information system, but also to the radiology department. Increasingly, the PACS will involve other departments, too.
The goals of the integrated delivery network (IDN) in implementing enterprise PACS have implications for how the facility plans its PACS solution. Discussions of PACS and imaging also involve more than future growth in radiology; now, they include cardiology, pathology, and ophthalmology as well. Today’s PACS decisions will affect all those departments as well as the enterprise users. The IDN will want a PACS architecture that can support that sort of long-term growth.
Integration has two primary aspects: the departmental side, where there are different work-flow issues for each department, and the enterprise side, which involves how the enterprise links with departments from an electronic health record (EHR) perspective. How can the different departments be linked easily? That is an integration question, but its scope is broader than the departmental level. If all that the organization has thought through is PACS at the departmental level. It basically connects its PACS to its radiology information system (RIS) and its modalities, and it is finished.
Imaging, however, is a major component of the EHR, so it is important to include that enterprise context in planning. PACS is not a departmental solution; it is an enterprise solution. After all, who are the users? They are not primarily the radiologists. Radiology is a high-volume service department. The information comes in, the tests are done, the reports are made, and the results are sent out to the enterprise, to the clinicians and referring physicians who ordered the tests. PACS has to be thought of in an enterprise context, and from that perspective, today’s decisions will affect long-term growth.
WORK-FLOW MANAGEMENT
For integration to be effective, the IDN needs the right tools. When we speak of integrating the PACS with information systems, we are not talking about point-to-point interfacing alone. Point-to-point interfacing takes one vendor’s system and connects it to a second vendor’s system. In the departmental situation, if the organization has several point-to-point interfaces, it does not have a centralized integration strategy. It cannot leverage the data going between two systems and take advantage of that information for use on a third system. If there are only point-to-point interfaces in the department, then the admission/discharge/transfer (ADT) system must send or create a different interface for each of the systems to which it connects. A centralized integration strategy probably would include an interface engine, but it should also include a work-flow manager. That is what we term our PACS broker because it deals not only with messages sent by the interface engine, but with the data and context inside the messages to trigger work flow tasks.
That is the major difference between an interface engine and a work-flow manager: interface engines send messages, while the work-flow manager uses the information within the message to activate components to perform certain tasks. The PACS broker causes the PACS to prefetch relevant prior studies, holds work-list data for querying by a modality, or sends a report from the RIS to a workstation. The PACS broker or work-flow manager is a bridge between the hospital information system (HIS) and RIS, which typically store reports and patient data in Health Level 7 (HL7) format, and the PACS and modalities, which store data in Digital Imaging and Communications in Medicine (DICOM) format.
Most information systems can only push information outward; they cannot be queried. If a user needs a report at the workstation, that report has to be cached somewhere. The PACS broker has typically been acting as the cache for that report as it goes to the workstation. The PACS broker is only the temporary cache, though, because the primary repository of the report is usually the RIS. We do not want to duplicate data if there is no need to do so, but some of the challenges we face in not having completely open systems is that we have to provide a proxy for some of the functionality that the RIS should have (or that some other system should have). That proxy activity is what a work-flow manager may or may not have to do, depending on the information systems with which it is dealing.
THE HIS AND RIS
The HIS in radiology and RIS are the foundations of integration. The HIS is important because it identifies the patient and manages the patient’s flow through the facility. The RIS acts at the level of the radiology department to manage the examinations that need to be performed and the utilization of modalities. How does the department move patients in and out to complete those examinations? The PACS comes into play to manage the images. At this point, the system is getting a mixture of text data and imaging data that need to correlate. That is where the PACS broker comes into use, managing the text data to be associated with the imaging data in the PACS.
Historically, the HIS and the RIS have been in place when we have performed PACS installations, but if they are not in place, the hospital needs to purchase them. In the past, users of PACS systems without a HIS or RIS encountered system difficulties because data entered at the modality was the only data associated with the images. They were not validated data because there was no system against which to check the demographics; the information was highly subject to data-entry error. Today, no institution would (or should) consider implementing PACS without the other information systems in place.
An administrator buying a RIS should ensure that RIS can talk to any PACS. The Integrating the Healthcare Enterprise (IHE) initiative addresses this very well. IHE defines the messaging that needs to go back and forth. If the RIS vendor can comply with IHE standards, then the organization should be able to purchase any PACS to use with the RIS (and an administrator may want that flexibility). By communicating through standards like HL7 and DICOM, the system is able to integrate disparate pieces of equipment. That provides the customer with the ability to choose, which is what standards are all about. The same situation also applies to modalities.
When we have been involved at the RFI stage with our clients, we have been able to let them know ahead of time the generic items that they will need to put in place to communicate with PACS. Primarily, they need three kinds of messaging from the RIS and HIS. One of them is ADT, so that the system can communicate changes in patient demographics. That is the basic purpose of the HIS. Second, and most important, is the radiology scheduling feed from the RIS, because that triggers prefetching and the sending of work lists to modalities. Third, the results, which reside on the RIS, must be available for display at PACS workstations and web-based image viewers. Those three interfaces need to be purchased prior to installing PACS.
INTEGRATION DURING INSTALLATION
When the interfaces are in place and the PACS installation starts, we bring in our integration team to start connecting those interfaces together. What we do is normalize the data. It does not matter which HIS or RIS we are connected to, or whether they speak HL7, use a flat file interface, or speak structured query language (SQL). We can normalize that in the PACS broker and then convert it to DICOM so that it is always the same DICOM going out the other side. We can remove the complexity of dealing with different dialects, and that normalization process is one of the key pieces of the work-flow management.
Everything flows through the PACS broker. It is at the center of the work flow in the department. Because everything flows through the PACS broker, all integration problems become our problems, but we manage the complexity of integration in the department.
That is part of the experience that we have built up since 1994 (when we started) that no other vendor has been able to match. We have run into situations where the site has upgraded the RIS; this would normally break the whole flow, but it does not, because of the normalization process we completed on the PACS broker. All we have to do is configure the new interface for the new RIS, and we are back up and running. If a facility adds a modality, we just add a connection, configure, and we are finished. We do not have to do any programming.
Whenever we plan for integration, we always plan for the longer term. The way that we proceed allows the hospital to follow its own growth pattern and move forward, too. What can happen with single-vendor systems is that the hospital becomes dependent upon the vendor’s strategy for moving forward. They may take the IDN a long way, but it is dependent on their schedule. Quite often, one sees a brokerless solution advertised, but in a heterogeneous environment, the concept of brokerless operation does not make sense (because it just means that another vendor is managing the work flow). That is why our integration team gets involved in all aspects of an installation. We are not leading the charge, because the installation is typically run through the PACS vendor, but we work with the PACS vendor and the modality vendors, one by one, to create a centralized work-flow management system. If there is integration at the EHR level for the distribution of images, then we will work with that vendor as well.
MAINTAINING CLINICAL OPERATIONS
Installing a PACS should not interrupt clinical operations. The PACS typically is going to start from a point forward. This is a transition phase. The facility can still operate the modalities manually, as it has in the past, until it starts integration. The RIS will continue to operate as always. The organization is adding work flow to increase productivity, instead of interrupting work flow and productivity. The work flow will change. It will become more efficient because systems have been connected and enabled to communicate. The need for duplicate data entry at different points in the work flow has been reduced. PACS is downstream in the department. It is dependent on close integration with the RIS and modalities. That is why PACS can look inadequate if there is insufficient integration.
The dependence of a PACS on a RIS is high. If the RIS communicates an event in an odd way (for example, if one cannot determine the status of a particular examination), then the PACS is going to reflect that. There could be discrepancies in the ways that the PACS and the RIS display data. We have, in the past, encountered situations in which we had to get the RIS vendor to change or add data to an event so that we could properly feed the PACS and provide the right context for that information. One RIS vendor took 6 months to fulfill an order for their HL7 interface, and that whole PACS project had already been planned as a 3-month installation. That is why it is so important to get information to all vendors as early as possible.
PROCESS CHANGE
Work-flow analysts manage process change. Going from a film environment to a digital environment involves change management. Any information-technology product’s installation is going to require process-change management. In fact, change management is probably a more crucial element than the software itself, in terms of whether a system is going to be successful in its installation. If it cannot convince radiologist to use the system, for example, then everything fails. Integration will not address that kind of problem. On the other hand, if the organization is proving to people, through integration, that productivity and work flow are going to improve, then they are going to see an advantage to using the software, even though it is going to require an initial learning effort from them. The trick is to manage the process change, weaning users from old processes by giving them new processes with added value (such as eliminating the tedium associated with the need to access multiple systems).
STANDARDS
Administrators involved in a PACS project should ask themselves why standards are desirable. If integration is important, then standards are, too. Standards help customers make informed decisions about the vendors that they choose. Standards allow for apples-to-apples comparisons between products to be conducted, with the confidence that the systems chosen can be connected. Standards promote competition and innovation, both beneficial to the customer. Customers should expect vendors to support and implement standards like HL7 and DICOM, and they should practice an open-connectivity policy, as well. That is the whole purpose of the IHE initiative.
Jim Herrewynen, is market segment manager, connectivity, Agfa HealthCare Informatics, Waterloo, Ontario, Canada.
