Assessment of the Integration of a HIS/RIS with a PACS

Abstract

The exchange of information between a Radiology Information System (RIS) and a PACS is essential to optimizing the utility of a PACS. Some of the benefits awarded by implementing an interface include a reduction or elimination of repetitious data entry, the availability of more accurate information on the PACS, a reduction in workload for the technologists, registration clerks, transcriptionists, etc, and the availability of more accurate data for automating the PACS. This paper discusses the Georgetown experience of interfacing an HIS/RIS and PACS, by describing the development of the interface and its impact on clinical operations.

INTRODUCTION

GEORGETOWN UNIVERSITY MEDICAL CENTER has an integrated patient information system solely supported by hospital staff. The departments within the hospital which are incorporated into the Hospital Information System (HIS) include: Clinical Laboratories, Continuing Medical Education, Emergency Room Admissions, Inpatient Admissions, Medical Records, Nursing, Pathology, Pharmacy, Poison Control Center, Private Outpatient and Inpatient Billing and Accounts Receivable, Radiology, and Transcription. The HIS software is written in MIIS, a dialect of MUMPS, and operates on five Data General mini-computers with eight 256M disk packs for archival storage and twelve 256M magnetic disk drives (3.072 gigabytes) of on-line storage.

The RIS is an integral part of the HIS and shares patient registration and order entry modules with other systems connected to the HIS. Also included in the RIS is a chronological index of patient activity, a film jacket tracking system, a report generating system, and an electronic physician sign-off. The HIS/RIS events which produce information required by a PACS include the registration of new patients into the radiology department (including modification to patient demographics), the creation of new radiology orders, modifications to and cancellations of the orders, and the generation of radiology reports, from preliminary to approved status. The Georgetown PACS network is based on an AT&T CommView system using ACR-NEMA messages to transfer information from the HIS/RIS to the PACS. The PACS configuration at Georgetown currently supports 11 imaging devices and 10 workstations. The HIS/RIS interface has been in clinical operation since June 1989.

NECESSITY OF INTERFACE

The importance of an HIS/RIS–PACS interface is evident to any institution employing both systems. The overlap of functionality between the systems (that is, patient registration, exam or order entry, and transcription) requires that the systems be able to share information as a means for eliminating repetitious entry of data while maintaining consistent database information. At the beginning of the Georgetown digital imaging network (DINS) project, the information available in the HIS/RIS and required by the PACS was manually entered into the PACS by technologists, registration clerks, etc. As can be expected, this resulted in both numerous mistyped data being entered into the PACS and missing data elements. Corrections on the HIS/RIS would have to be entered separately into the PACS and so were usually not made. The existence of a link between the HIS/RIS and the PACS virtually eliminates both of these problems, resulting in more compatible databases.

Besides the elimination of redundant data entry, the implementation of an interface between the HIS/RIS and the PACS has allowed for the development of a more automated, more intelligent PACS. Certain HIS/RIS data fields, (radiologist, modality, and referring physician) and PACS data fields (acquisition station, worklist category, and destination) are currently used by the CommView system for their auto-send feature to route exams to workstations as they are acquired. This works reasonably well within the Radiology Department where modalities or radiologists tend to use a single workstation. Outside of Radiology, it is not as easy for the PACS to determine where to send the exam. For example, auto-sending exams to the intensive care wards requires that the person capturing the images into the PACS first enter the destination of the images into the PACS. This is a workable solution although quite cumbersome. Information exists within most HIS/RIS (e.g., patient location or room number) and should be used by the PACS as an alternative key to determine to which workstations exams are to be routed. The auto-send feature available on CommView could be enhanced if this piece of information, currently available in an HIS/RIS, were used.

A thorough understanding of both systems’ databases, of how information is stored, sent, and acquired, and of the functional overlap between the systems is crucial from the beginning of the interface design. In developing Georgetown’s HIS/RIS–PACS interface, many conceptual, technical, and operational problems arose which were not evident at the start of the interface design. These issues, along with specifics about the Georgetown interface, will be discussed in the following sections.

TECHNICAL INTERFACE

Embarking on the development of an HIS/RIS–PACS interface requires a technical definition of the data format, communications protocols, and physical communications links, as well as an operational specification explaining what triggers the data transfer. All discussions in this section will assume an interface similar to the one existing at Georgetown, with data flowing uni-directionally from the HIS/RIS to the PACS.

Having a standard for transferring data, like ACR-NEMA, makes the interface design much simpler and more robust. The ACR-NEMA standard in its current form specifies a physical link as well as logical structure for connecting imaging equipment from different manufacturers for transferring image and text data. Working group VIII (WG VIII) of the ACR-NEMA Standards Committee is working on an extension to the original standard to define the transfer of information between an HIS/RIS and a PACS. This extension will define only the logical layers while maintaining the data formats of the current ACR-NEMA standard and expanding the already extensive data dictionary. The AT&T CommView system interface specification follows the ACR-NEMA format for receiving information from an HIS/RIS, however, it does contain extensions to the current standard. A Hexadecimal representation of an acceptable HIS/RIS-CommView message is shown in Fig. 1. Our HIS/RIS does not produce data for transmission in an ACR-NEMA format, thus requiring a gateway (an AT&T 6310 PC is used) between the two systems to generate ACR-NEMA formatted data from the HIS/RIS ASCII data. The HIS/RIS at Georgetown passes exam information to the PACS as shown in Fig. 2a, but passes report information as shown in Fig. 2b.

Figure 1.

Hexadecimal representation of acceptable HIS/RIS-PACS transaction.

Figure 2.

Example of an HIS exam message.

Figure 3.

Example of an HIS report message.

Similarly, the specified communications protocols for the PACS side of the interface are different from those defined by our HIS/RIS. The AT&T specification requires binary data sent over direct RS-232 lines using the KERMIT communications protocols, whereas our HIS/RIS sends ASCII data across a SYTEK network using the FTERM communications package which does not allow for KERMIT protocols. Again our converter box acts as a gateway for passing the data between the systems.

The use of a third computer system as a gateway between the HIS/RIS and PACS is a satisfactory solution, but not without its problems. Mainly, the question remains as to which system, either HIS/RIS or PACS, maintains responsibility for the data after it leaves the HIS/RIS and before it enters the PACS. If data was passed directly to the PACS, then responsibility for the accuracy of the data would be more evident. The need for user intervention increases when the systems are not directly connected and only one-way communication is permitted. An operator must check log files and determine the appropriate action when transactions are not handled as expected on the PACS.

Defining the physical and technical parameters for passing information may require negotiations with both the HIS/RIS and PACS vendors. The goal of these negotiations is to develop one specification acceptable to both parties. However, in reality the two interface specifications are often quite different. The amount of work required to pass information between systems varies depending upon the similarity of their file formats, transmission parameters, and communications media.

APPLICATION

The logical relationship between transactions which occur on the HIS/RIS and their counterparts on the PACS is not so straightforward. Determining which actions will trigger data to be passed to the PACS is specific to the HIS/RIS. For a very robust HIS/RIS system, many actions may have a similar effect on the PACS. The HIS/RIS transactions for registering patients and updating their demographics, creating, modifying, and canceling radiology exams and orders, and creating, updating, and deleting radiology reports all produce information needed by the PACS.

The Georgetown integration effort began with the transfer of order entry information from the HIS/RIS to the PACS. The initial goal was to bring signed reports to the PACS as quickly as possible. In order to bring reports to the PACS directly from the HIS/RIS, the order data in the PACS must be exactly as it appears in the HIS/RIS. Therefore, initial efforts focused on sending all exam data to the PACS as it was entered into the HIS/RIS, including the creation of new exam orders as well as the modifications to and cancellations of existing orders. Data from November and December 1989 was accumulated and analyzed to determine the average number of transactions coming across the interface daily. The results are presented in Table 1. Overall, an average of 156 exam transactions are transferred to the PACS per day, with 198 transactions per day on average during the week and 67 transactions per day on weekends or holidays. These numbers are broken down by exam transaction type in Table 1.

Table 1.

Average Number of Exam Transactions

Exam Transaction Type
	Add	Cancel	Edit	Total
Weekdays	90	9	99	198
Weekends   & holidays	37	4	26	67
Daily	73	8	76	157

One problem that has been avoided is the receipt of an add exam transaction for a patient not currently in the PACS database. The CommView system will first add the patient to the database before processing the add exam transaction. The obvious benefit of the CommView system handling this type of request is a reduction in the number of transactions sent across the interface. This is important for a system like that at Georgetown in which the RIS is a subset of a larger HIS and shares the same patient registration system with the rest of the hospital. The number of add patient requests which would come to the PACS each day, for patients not in the Radiology Department, would be prohibitive.

The most common problem seen at Georgetown with transferring exam transactions has been the mismatch of patient names between the systems thereby resulting in a PACS error. This is caused by errors in the initial entry of the patient name, or a newborn initially being recorded as Babyboy or Babygirl and named later. When the change is made in the HIS/RIS, that change is not captured in the PACS. In retrospect, the details for doing this should have been worked out as soon as exam transactions began coming across the interface. However, if every modification to patient demographics is sent to the PACS, since there is no easy method of determining from the registration system whether a patient has radiology exams on the PACS, this would result in a large number of unnecessary transactions. Any method for correctly limiting the transactions sent across the interface is desirable. To limit the passing of patient modification requests, the proposal is to have the PACS modify the patient demographics based on the exam or transcription requests received from the HIS/RIS. This may raise liability issues, but the specifics could be worked out, especially for hospitals with a single patient registration system used by both an HIS and a RIS. Compatibility between the two systems is the highest priority.

Limiting the number of transactions across the interface is important because of the expected volume. Filtering the information from the HIS/RIS is designed to capture only information that is deemed necessary on the PACS. The two criteria used at Georgetown are based on the imaging modality referenced and the patient location. If a transaction from the HIS/RIS references either a modality known to be on the network, or a patient unit which has a workstation, that transaction is accepted. Otherwise, while not rejected, it is not processed further.

Another possibility for limiting transactions across an interface is to limit the transferring of transcription data to signed reports only. As long as a one-way interface exists between an HIS/RIS and a PACS, only approved reports need to appear on the PACS. This will increase the time lag between matching report data to exam information, but should drastically reduce the number of transactions sent across the network. This time lag, caused by sending only approved reports, may cause further problems depending on the amount of on-line storage of the system. If exams are archived before the reports are sent to the system, this will currently result in an error and the report not being matched to the exam. The exam must first be restored and the report transaction retransmitted to match the information. This problem can be solved by increasing local storage, rethinking archiving criteria, or modifying the CommView software to restore these exams automatically, to connect the reports with them, and archive the new information.

Operational issues surrounding the transmission of exam transactions cause integrity problems between the two databases since modifications to and cancellations of existing orders take place at many different places within our HIS/RIS and are usually done after the study is complete and the images are acquired into the PACS. This generates confusion on the PACS and results in an error causing the databases to become incompatible. This type of operational problem is common among the modalities connected to the PACS and may require some changes either in the operations of the department or modifications of allowable transactions on the PACS. This issue was discussed with technologists, radiology administrators, and radiologists in order to determine an acceptable solution. Due to the constraints of a one-way interface, confirmation of the exams cannot be done on the PACS and returned to the HIS/RIS.

Because of these operational issues, the initial goal was modified to be the transfer of exam information to the PACS to aid in acquisition and review while maintaining HIS/RIS and PACS compatibility. One way to obtain this goal is to insist that technologists confirm procedures or modify the information on the HIS/RIS prior to the start of the exam. This is not acceptable at Georgetown since HIS/RIS terminals are not always convenient to the scanning areas. Another solution would be to allow the technologist to easily modify the information on the PACS, select the appropriate study and change the information that arrived from the HIS/RIS. This may reduce some problems but could cause others. The modifications would need to be controlled by the PACS in a method that would maintain compatibility with the HIS/RIS, for example selection of appropriate exam names and descriptions from a predefined list as opposed to freehand editing.

Matching information on the RIS to similar information on the PACS is not always easy. The Georgetown RIS allows radiology orders to contain multiple exams for a single modality. This results in a unique order number on the HIS/RIS for all exams in the order and not for the individual exams. The CommView system, however, does not permit multiple exam orders and requires each exam be handled independently with an exam number unique to the PACS. The two ways of dealing with this are either to separate the HIS/RIS orders into individual exams when sending them to the PACS or to treat all the exams on an order as a single exam. Both of these solutions have their benefits and problems for acquisition, primary diagnosis, and general review.

Creating unique exam identifiers for each exam in an order creates more work for the technologists. It requires them to end acquisition on the PACS and start a new exam while scanning the patient or filming the images. However, it is not always apparent where one exam ends and the next begins. Also it is sometimes necessary to re-scan an area to take additional slices. It does not appear that this issue will be resolved with the installation of digital interfaces to the imaging devices. With the current digital interface available to us in MR, images can be assigned different exam IDs but this requires that the technologist enter the image numbers and corresponding exam ID into a terminal before the images are acquired into the PACS.

This separation of the exams makes sense from the perspective of a radiologist or a referring physician. It will be easier to find the correct images if the exam procedures are specific to a type of study. For instance, if a physician is seeking an old chest exam on a patient, the exam should be clearly marked by procedure description, date, and time.

The other possibility for handling HIS/RIS orders is as a single exam. This solution is considered feasible only if one radiologist reads all the exams on the original order. This reduces the work load of the technologists since they would not be required to stop and start individual exams as they work. However, it would require anyone wanting to see one exam acquired from an order containing multiple exams to retrieve all the images and search through them until the desired ones are found. If the procedure descriptions could be generated to describe properly all the images in the study, this solution has its benefits. For primary reading, the radiologist only needs to pull up one exam, and the technologists would benefit as stated above. However, the referring physician or radiologist who requests only some of the images for comparison would receive superfluous information which could slow them down. Another potential obstacle is the CommView system’s current 175 image limit per exam. With an MR study, it is highly likely this limit would be exceeded, especially if the HIS/RIS orders are not separated.

After discussions with technologists and administrators, it was realized that technical solutions are not always the best, and changes in the operations of the department may be necessary. It was decided to separate the HIS/RIS orders and monitor the results to determine the problem areas. The number of failed transactions from the HIS/RIS to the PACS, the types of transactions failing, and the areas in the department generating the problems will then be reviewed further. We are prepared to initiate changes in the HIS/RIS in order to generate more compatible databases. It was decided, however, to allow certain exams to be combined into one exam on the PACS, in areas where the relationship between the studies is sensible and would therefore cause little confusion later on. The difficulty imposed by dealing with both an HIS/RIS which permits multiple exam orders and a PACS which does not, is not unique to the Georgetown system. Finding an acceptable solution requires input from many different users of both systems (radiologists, technologists, administrators) as well as the developers of both the HIS/RIS and the PACS.

Finally, matching HIS/RIS reports to PACS exams can be a problem because of the arguments considered above. At Georgetown, reports are generated on the RIS per order, not exam. Since we are splitting our orders into multiple exams, it was determined that instead of separating the report by exam, one report would be sent to the CommView system and automatically stored with each exam from the original order. This is possible since the exam number created for each exam in an order is a concatenation of the original order number and an exam identifier unique to the order. For the CommView system, the exam identifier is used to identify images, exam data, and reports as those belonging to a given patient. Therefore, the exam identifier is crucial to keeping all this information accurate as well as compatible with the RIS information.

ADDITIONAL CAPABILITIES

In general, HIS/RIS–PACS interfaces are still quite primitive and will need to evolve in order to approach the level of sophistication required to guarantee the compatibility of the databases, adapt to new transactions and operational issues, eliminate user intervention, and reduce failed transactions. The biggest change will be the inception of two-way interfaces and truly integrated workstations capable of accessing both the HIS/RIS and PACS databases. This would permit maximum access to all necessary information when reviewing a case and help maintain the integrity of the databases.

Until two-way communications or integrated workstations are realized, significant advances will need to be made to aid in the modification of information on the PACS in order to guarantee compatibility with the HIS/RIS. One way of doing this is to simplify the procedure for starting new exams on the same patient while acquiring images. A reduction in the number of steps required for this process would increase the technologists’ use of this and would help the PACS and HIS/RIS databases be more compatible. Allowing the technologist to change procedure descriptions, and cancel and add exams easily from the acquisition screens would decrease the number of failed transactions on the PACS. This would require a confirmation on the PACS that the procedure descriptions and other exam related information was correct for the exam being performed, and thus in concert with what will change on the HIS/RIS. One acceptable method for doing this is for the system to prompt the technologist to on whether the exam information is accurate on the PACS, or if not correct, to display a menu of allowable procedure codes the technologist may choose. Then the technologist could enter the exam number for the exam being done, and a unique exam id comparable to what’s produced on the HIS/RIS would be assigned.

As access to the information within an HIS/RIS increases, the “intelligence” of the PACS should improve. The information from an HIS/RIS scheduling module should prompt the PACS to restore related exams from the archive, compile a set of related exams for primary reading, and send the set to the workstation where the radiologist will read them. This should all take place during off-hours, when system usage is slow, but prior to the start of the Radiologist’s review. Other functions which would increase the intelligence of the system based on HIS/RIS information, include a more robust auto-send feature (as described earlier) and automatic modifications to demographics.