HealthManagement, Volume 1 / Issue 3 Autumn 2006
Author
John Griffith
CIO / Operations Director
EPIC Imaging
The Past, Present and Future of Systems Integration
When approaching the topic of interfacing withmost radiology IT professionals, one hears many tales about integration nightmares within the industry. However, with a better understanding of how integration typically works and the roles of the actors involved, it becomes easier to achieve successful integration between systems.
In the early days of healthcare IT,many freestanding facilities would simply purchase a complete radiology information system with built-in billing – and no need to provide integration with any other device. Subsequently, additional technologies such as Picture Archiving and Communications Systems (PACS), Mammography Information Systems (MIS), Voice Recognition Dictation Systems (VR), and Enterprise Document Management systems (DMS) arrived with the need to create interfaces for the entire IT infrastructure.
In the future, as PACS, which has been the primary domain of radiology, begins to dominate the healthcare scene for storage of all images created by all of the “-ologies” in healthcare, integration is going to be of the utmost importance. Let us begin by discussing the key players involved in integration.
The Main Standards Bodies
The main standards bodies involved in successful integration are Digital Imaging and Communications in Medicine (DICOM), Health Level 7 (HL7) and Integrating the Healthcare Enterprise (IHE) . They all share important roles in the process of different systems working together. DICOM is the standard for digital images, and covers areas such as transfer syntax, storage requirements, modality worklist compliance, modality performed procedure step (MPPS), storage commit, etc. HL7 is used for messaging between systems such as RIS and PACS using various message formats. Lastly, IHE is not a standard in itself, but is a set of structured rules that define how HL7 and DICOM will properly interact.
Idealvs. Common Integrations Scenarios
The ideal integration scenario would consist of a system that utilises components that could easily “plug-in” and have access to a single relational database containing all of the necessary tables for the healthcare enterprise. In thisway, one would just purchase the modules needed to expand the system as the enterprise grows. To the end-user, it would appear as a single application with a single-user interface.
Ultimately, this creates the tightest integration possible and allows for the fewest headaches and integration problems during implementation. If one is dealing with a true open architecture, one would then be able to plug-in the best of breed technology from different vendors. Presently, the only way to begin acquiring this type of tight integration is to go with a single vendor, which may leave one with making compromises with certain components of the system. Depending on the requirements, it may or may not be possible to find a vendor that can provide everything needed in one integrated product. Because most enterprises do not have the time to wait for the availability of a plug-in infrastructure, or the luxury of completely replacing their healthcare IT infrastructure when one does become available, the only option left is to integrate using the standards that are currently available.
The most common integration scenario involves separate products that utilise HL7 messaging for interfacing. Properly done, results closely resembling a single database product can be achieved. These systems can then reside on the same server or may reside on separate servers, depending on the particular application.
Common Message Types Used in Integrating Radiology Systems
One of the common HL7 message types utilsed in integrated radiology systems is Order Results Management (ORM), which is a general order message that contains all of the demographic information, procedure ordered, ordering physician, etc. There are hundreds of fields available in the ORM, with each one having a defined criterion for what is entered into those fields.
Most vendors do not populate all of the fields, but it may be beneficial to have the HIS / RIS vendor populate all available for a particular message type if the data is available in the master database. This makes it easier to utilise a single interface for multiple uses, instead of having a separate interface for each system being integrated. Twomain types of ORMs used in Radiology Information Systems (RIS) / PACS / VR and DMS integrations are new orders and cancelled orders.
The next message type commonly used is Admit / Discharge / Transfer (ADT).There are many types of ADT messaging defined in the HL7 standard. Within the radiology environment this message is used to provide demographic updates, medical record number changes, etc., but does not include any specific order information such as type of procedure, referring physician, etc.
The last message is the Observational Report Unsolicited (ORU). This message will contain the results of the radiologist’s interpretation, lab results, pathology results, etc. and is typically passed from RIS to PACS, but may originate in a voice recognition program and traverse directly to the RIS and PACS, or just to the RIS (with the RIS being responsible for forwarding to the PACS).
Typical Message Flow in an Integrated RIS / PACS / Dictation
System
In an integrated RIS / PACS / Dictation system utilising HL7 messaging, the typical message flow would go somewhat like this. + ORM goes to PACS and dictation (new or cancelled),
+ PACS sends accession number pass to dictation software,
+ Dictation sends ORU (preliminary or final) to RIS,
+ RIS send ORU (final) to PACS, and
+ RIS sends ADT message for demographic changes, etc. To RIS, dictation, mammography information, and document management systems.
Of course, this is just one variation of many possible combinations of message flows. Ultimately, the method flow of choice is going to depend on the vendors and preferences for the workflow of the facility.
The Need foraCommon Framework
IHE is becoming an important part of integrating systems. IHE uses DICOM and HL7 standards to define a framework for how these two standards will interact. The IHE committee has created integration profiles for radiology as well as other healthcare specialties that define actors and transactions within each profile. Current radiology profiles consist of multiple actors and transactions that include, but are not limited to: scheduled workflow, patient information reconciliation, consistent presentation of images, presentation of grouped procedures, access to radiology information, key image notes and simple image and numeric reports. Each of these profiles are responsible for defining the role of the actors and transactions within each one.The more a vendor complies with the different IHE profiles, the more likely it is that the integration project will be successful.When purchasing new equipment or systems, it is now important to have the vendor include their IHE integration statements with the completed RFP, in order to make a better informed decision as to which vendor will provide for the easiest integration.
Aside from using this information to help with integration, one of the most recommended investments would be in an HL7 interface engine to help solve integration issues and reduce the overall number of interfaces needing development by vendors or IT staff. Without an engine, the workflow for a typical radiology environment that has RIS, PACS, VR, Mammography Information Systems and enterprise document management would involve numerous bi-directional interfaces. In the previous scenario, bi-directional interfaces for the following would be required: RIS-VR, RISMammography Information, RISDocument Management, and unidirectional RIS-PACS.
Each vendor on each typically charges a fee in the range of US $10,000 to $25,000 (e 8,000 – e 20,000) for each interface. All of these interfaces normally utilise similar messaging standards. With an interface engine, youmay get bywith a single bi-directional interface between the HIS / RIS and the interface engine. Then, the interface engine will be able to provide all of the other interfacing necessary with all of the enterprises information systems. The interface engine allows IT staff tomaintain and create additional interfaces, as needed and at a fraction of the cost of separate custom interfaces.In the beginning stages of the widespread adoption of Electronic Health Records by individual practices, requests to provide electronic results different departments such as lab, radiology, pathology, etc. is growing. This can be a daunting task if one does not employ the benefits of an HL7 interface engine.
Facilitate the Process
Take time to be involved in the interfacing process, as it will make troubleshooting much easier in the long run. Insist on compliance from vendors to IHE standards when searching for new IT / modality products. Although radiology still has not reached the ultimate goal of “plug-and-play” among products, there have been enormous strides made in compatibility among products from various vendors.
