Jim Herrewynen

There will never be a perfectly integrated environment. Different applications will always be at different levels of integration capability. That becomes more true as one starts moving across the clinical domains, and it becomes even more true when one starts to move outside the hospital environment. The integrated delivery network (IDN) will end up with some stand-alone systems that cannot integrate with anything. In our business at Agfa Healthcare, we are tackling integration in the most common departments in the hospital, but there are many less common departments that still operate as real islands of information. In trying to establish the electronic health record (EHR), it is almost as if one must move back to square one each time that a new area is entered, because much of the work flow is manual.

This is one reason that the institution must think in terms of real-world integration. How can it integrate a system that it has already purchased with one that it is planning to purchase? How can it integrate a system that it has already purchased with another system that another entity has purchased? Integration is always going to be important in a heterogeneous environment. One vendor will never solve all problems. It may say that it can, but no single vendor can do it all. That will continue to be a fact for a long time because no one vendor has all of the necessary pieces of this puzzle. We do not have all of the pieces, either, but we do have the ability to integrate many of these pieces. Leveraging an institution's current information-technology investment by adding to the infrastructure already in place provides a much greater value than switching out all of its systems. That augmentation approach should also be much more palatable to the CEO or CFO.

INTEGRATION VERSUS CONNECTIVITY

Integration is sometimes confused with connectivity. Connectivity is an aspect of integration, but it is integration at its most basic level. Connectivity is essentially one system passing information over the wall to a second system. When two systems communicate, there is unidirectional or bidirectional work flow. One-way work flow means that one system pushes out the information and the second system, or whatever systems are listening, can pick it up. That is basic connectivity. In integration, the system goes one step further.

One example is that of technologists at modalities performing studies. When they complete a study, they traditionally have had to go to a second radiology information system (RIS) terminal and go through the completion process on that RIS manually. They have a terminal for the modality and a terminal for the RIS, and they have to navigate those two different systems to complete their work. Today, there is integration functionality that allows information to flow between the modality and the RIS, so that the technologists only have to deal with a single terminal, display, or system. The modality messaging and background data can be passed into the RIS automatically. This functionality is highlighted in the scheduled work flow profile of the Integrating the Healthcare Enterprise (IHE) initiative.

Integration is connectivity that enhances work flow. It is not just connectivity because it has a work-flow component. Data pass back and forth between two systems. Those data are relevant, and they can trigger actions in either system so that they improve the work flow of the people who are using the system.

TYPES OF INTEGRATION

Back-end integration is essentially the simple communication in Digital Imaging and Communications in Medicine (DICOM) and Health Level 7 (HL7) protocols that takes place on the primary level of work-flow enhancement that modest integration allows between two systems. There is messaging between the two systems such that the message from the first system prompts an action by the second system. There is integration because there is work-flow enhancement. The first system sends a prompt and the second system responds.

Front-end integration takes the communication between systems a step further into context sharing. The Clinical Context Object Workgroup (CCOW) effort is an example of context management tools. The user can log in once and access multiple systems in the context of the patient or study of interest. If a radiologist at a picture archiving and communications system (PACS) workstation, for example, wants to access the history of the patient whose images are being viewed, the radiologist can do that through context sharing. The RIS can be integrated with the PACS so that the RIS, where the reports usually reside, responds to a prompt from the PACS workstation. The radiologist can access the reports on the PACS without having to log into the RIS separately, navigate through the RIS to find the patient, and then find the examinations. All that information is managed through the context server. There are multiple levels of context sharing that can occur, and it can become very complex. The higher the complexity, the greater the value of having the disparate applications act as one.

Enterprise level integration begins to add context sharing based on the EHR. Departmental integration is essentially encounter centered. Everything in radiology centers on a study or an examination. Images are created and reports are created based on that examination. The EHR takes place at the enterprise level, and it is usually patient centered. The perspective of the user is different at the enterprise level than it is at the departmental level, so the integration must link the same information together in a different way. At the enterprise level, the user would click on the patient's name. Then, to view radiology studies, the user would see a list of studies, click on one, and then click on the image icon to view the image. That would provide the context to the PACS, and the PACS would push those images for display to that EHR web portal.

Integration at the enterprise level involves more than just the departments or even the hospital itself. It deals with users within and outside the hospital, so it spans the health care continuum. PACS is part of enterprise-level integration because it is pushing images out to those clinical users.

INTEGRATION IS NEEDED

Because intradepartmental work flow traditionally has been encounter centered, each department has tended to become its own island of information. There have not typically been cross-departmental linkages. Now, that is changing because of the push to create the EHR. The EHR implies the need to bring together the informational components from various departments, clinics, and even, in some cases, physician groups.

In order to build an EHR, the departmental subsystem or the work flow with the various departments needs to be well established. One cannot start with an EHR that has no links to the information system because there would be nothing to view. Traditionally, radiology has been at the forefront of technology development and integrated departmental work flow. The integration of the modalities, the RIS, and the PACS has translated into higher efficiency and better productivity. Hospitals were compelled to pursue this integration if they wanted to improve their bottom lines. Now, they are compelled, in the same way, to pursue integration through IDNs that can transmit PACS data and other information between various sites within the same enterprise or beyond it.

The push to create the EHR and its use within IDNs to distribute data have both meant that many disparate systems have had to be integrated. As hospitals have merged and as large integrated delivery corporations have bought up new hospitals, the need for an enterprise PACS and an IDN to connect all these hospitals has become uppermost. Traditionally, each of the merging hospitals had its own information-system infrastructure, which might not have been the same as those at sister facilities. This means that each hospital will have its own patient identification domain, but there is no crossover between the sister hospitals, nor is there an enterprise master patient index (EMPI) that would allow one PACS to serve the whole enterprise. One way around this is to replace all the existing systems with a new single-vendor system. This can be expensive, and it has other drawbacks. A second way is to manage the integration between each hospital that allows the disparate systems to communicate. Both are methods of integration, both can be successful, and both can involve trade-offs. Some method of integration is needed, however, if the enterprise is to save expenses by maximizing work-flow efficiency.

THE BEST-OF-BREED APPROACH

An enterprise integration strategy can be powerful if constructed correctly. The advantage of having such a strategy is that the institution can leverage its current information-technology investment. Assuming that systems from different vendors are talking to each other, there is always going to be a limit on the information that passes from one system to the other. As long as the facility can maintain a level of work flow that allows the disparate systems to operate, it has maximized work flow without having to buy all systems from the same vendor. But if the organization does buy multiple systems from the same vendor, it might have more control over its data. Despite this, there are many advantages to pursuing a best-of-breed approach and purchasing each component of information technology based on which vendor produces the best component. One vendor may have a terrific PACS, but the same vendor's RIS may only be average. Every choice will involve trade-offs; many of them relate to cost. This is also what the IHE initiative promotes: the maximization of integration between disparate systems to achieve a tightly integrated departmental work flow.

If a facility abandons its previous information-technology investment to purchase all components from a single vendor, it must account not only for the hardware and software outlay involved, but for the cost of retraining all employees to use the new system. If the organization has an information-services investment and is adding a PACS, it will want to maximize work flow but minimize the extra training involved. We believe that taking the integration approach to a problem can sometimes place the institution further ahead. Our integration software is packaged with our PACS, so the return on investment is calculated in the context of what the PACS provides (digital imaging versus the manual, film-based process).

Whenever standards have been unavailable, we have standardized the proprietary interfaces, and that has worked well for us. We do not approach integration from a customized perspective. Our connectivity work-flow engine involves a complete tool set that is at our disposal, that is fairly generic, and that has been successful for us over the years. It has been proven in more than 1,200 hospitals worldwide. It is that model that we continue to use as we move across departments in the enterprise.

With single-vendor solutions, there is an added caveat. If a hospital purchases all of their systems from a single vendor, then it is locked into that vendor. It proceeds at the pace of that vendor, as far as innovation is concerned. The institution is not in control. This is another trade-off that the hospital has to weigh. In some cases, a single-vendor solution may make sense, but the hospital is going to evolve according to that vendor's product road map.

There are also good arguments against the best-of-breed approach; for most institutions, the best choice probably lies somewhere between the two strategies. Sometimes integration has received a bad name because one vendor has little motivation to cooperate with another vendor. In the real world, however, that cooperation happens all the time because there is a need for it.

STANDARDS IN THE REAL WORLD

Standards are important. The whole idea behind standards like HL7 and DICOM has been to allow different vendors' products to communicate and to be integrated in order to give the customer the best product at the lowest cost. In the real world, however, standards are not uniformly adopted. HL7 and DICOM implementations have different dialects. That is why a strategy must go beyond standards, and one has to remember that standards also evolve. A good example would be HL7's recent change to version 3.0, which is based on a totally different model. Whichever vendor the enterprise chooses will ultimately need to support that kind of evolution.

True interoperability means extending beyond standards. IHE is predicated upon the collective cooperation of all vendors whose products need to integrate with each other. IHE is still young, yet it is moving in the right direction and it is gaining momentum. It will take time for the industry to adopt the work flows, as defined by IHE.

Today, real-world integration is the key issue in the industry. It does not involve choosing one single-vendor solution versus another. We believe that the best-of-breed approach is going to dominate, at least for some time to come. Typically, one vendor will be very good at one thing, but not so good at everything. The single-vendor approach (with the same vendor supplying both the RIS and the PACS) is not going to be dominant any time soon because hospitals have already made a considerable information-technology investment, and they want to leverage that investment. In the real world, an effective integration strategy provides the best leverage.

Jim Herrewynen is market segment manager, connectivity, Agfa HealthCare, Informatics, Waterloo, Ontario, Canada.