Question

Details of main methods (up to 3) that currently exist for interfacing HIS and RIS with PACS

Answer 1

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 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.