PACS and patient data management systems

Computer Methods and Programs in Biomedicine, 36 (1991) 107-112 © 1991 Elsevier Science Publishers B.V. All rights reserved 0169-2607/91/$03.50

107

COMMET 01223

PACS and patient data management systems Michio Kimura Department of Mathematical Engineering, University of Tokyo, Faculty of Engineering, Tokyo, Japan

It is important for a PACS to have access to the patient data, as well as to the images themselves, for the purpose of sophisticated image archiving, retrieving, viewing and interpretation. There are many kinds of patient data concerning image examinations (i.e., patient name, ID, age, examination date and time, examined regions, methods, findings on images, diagnoses or diagnostic impressions, etc.). Some of them are acquired from image examination apparatus, some are supplied by diagnostic radiologists, while some need be retrieved from the radiologyand hospital information systems. To facilitate this data exchange, a PACS-R1S-HIS coupling is required. The author has constructed at Tokyo University Hospital a small PACS called TRACS, which adopts one of the possible PACS-RISHIS coupling configurations. PACS: HIS/RIS coupling; Interfacing; TRACS

1. PACS benefits by integration with RIS and HIS One of the most important impacts of PACS on radiological services is the improvement of the availability of images themselves [1]. Images from different modalities can be viewed in different places at any convenient time without fear of lost films. However, raising the availability of images alone does not improve patient care. Currently, the radiologist possibly has to deal with hundreds of films in one film jacket in order to find the ones h e / s h e needs. Even with PACS, the radiologist has to deal with the same number of images which are then stored into an image database. Integrating PACS with hospital and radiological information services (HIS and RIS) enables the preparation of the patient's past appropriate

images for comparison, the retrieval of images using flexible keys like disease names, findings, and the presentation of image examination history for browsing. These things could be done by making use of the demographic data (non-image data) of image examinations. The patient data originate from different sources. Patient name, ID, and other patient proflies come from HIS. Examination date, time, methods, region, and other examination data are generated at image modalities on site and RIS. Diagnostic reports (findings, diagnostic impressions) are generated by the radiologists. Other case data (lab data, signs, other reports, etc.) come from HIS. To make all these data accessible, a flexible HIS-RIS-PACS coupling must be established.

2. PACS-RIS-HIS relation Correspondence: M. Kimura, Department of Mathematical Engineering, University of Tokyo, Faculty of Engineering, 7 Hongo, Bunkyo, Tokyo 113, Japan.

Table 1 shows for PACS its possible domains, functions and functionalities, required techniques

108

and environments, and integration with RIS and HIS. Based on this, there is no fundamental reason why PACS (at least, the demographic data processing part of the system) should be designed in a completely different manner than HIS.

2.1. Implementation scenarios Fig. 1 shows three alternative implementations for the HIS-RIS-PACS coupling [2]. In the figure, a hatched box stands for interfacing hardware

TABLE 1 HIS-RIS-PACS domains, functionalities, required techniques on each function. T, transmit; R, receive from RIS, HIS Domains

Functions

Functionalities

Techniques and environments required

Integration (Data exchange between PACS, RIS and HIS)

PACS alone

Image viewing at CRT

view at different conditions, image processing

conventional digital image examination apparatus (XCT, MRI, DSA, CR), advanced image workstation

no interactive information transfer

Archival, retrieval

comparison with past images, data format standardization

large scale archive, image database management system

prepare standards such as 1D, diagnostic codes, for later interaction

Same as above (high level)

easy retrieval, comparison of same disease images, educational use

diagnostic code (or other examination summaries), Interface for acquisition

Report processor

ease of report making

sophisticated interface (word processing or speech recognition)

Radiological examination reservation & management

ordering of image examination from HIS, management of examination history

interface with HIS

T: order of image examinations R: examinations schedule confirmation

Output of exam results to HIS

case history of image exams at each department

report (or summary) should be attached to each exam, Interface with HIS

R: exam, results (report or summary)

View of images at each department

view of images immediately after exams, no need to search for films

high-speed data transfer, large size memory

Case history from HIS

no need to make summaries at exam. ordering, more appropriate exams, performed

automatic making of case summary at HIS

T: case summary

real time transfer, no interruption of routine care at both hospitals, no duplicate image examinations

PACS should be established at both hospital, high speed transfer net

image examination database should be managed and transferred inbetween

No need to make summaries

HIS and PACS should be established at both hospitals

R1S-PACS coupled

HIS-RISPACS coupled

Teleradiology, Image transfer Telemedicine to/from other hospitals

Case transfer to/from other hospitals

109

HIS[~~ b.

I HIS RIS I

O,

L ,sl .,s

[

PACS

IZ PACSI PCS i

enormous software libraries accumulated on general operating systems (UNIX, MS-DOS, O S / 2 , etc.), especially on network interfacing features. Data security and system uptime issues can be solved more easily. However, few manufacturers make a PACS that allows an external data interface except for image data.

2.2. Use of image standards in HIS-PACS coupling

Fig. 1. Three scenarios for HIS-RIS-PACS coupling. Shaded boxes represent interfacing hardware and software.

and software between HIS, RIS and PACS. In this figure, RIS is incorporated into HIS. In most cases under current situation, the HIS-RIS-PACS coupling needs additional hardware or software. If any of HIS, RIS or PACS was developed on a flexible operating system, this interfacing subsystem could be only one board added to the system. In scenario a, the interfacing subsystem is within RIS and HIS, and is directly controlled by them. In the implementation of this form, the following difficulties are to be solved: Mostly, HIS has been built on an inflexible operating system installed on a large main-frame computer, which seldom allows this kind of addition. Special software, custom-designed for PACS, is required, which tends to discourage development attitudes and increase development expenses, and causes difficulties in updating and revising. In certain situations, procedures for image management must be initiated from RIS or HIS terminals, which adds requirements for the RIS or HIS terminal design. In scenario h, the interfacing subsystem is inside PACS and is directly controlled by it. In the current situation of PACS development, few vendors allow this kind of hardware addition to their systems, neither does their PACS have enough features to manage patient data. Scenario e has the following advantages. By isolating the interface hardware from HIS, RIS and PACS, the implementation can be based on the latest hardware any time at a reasonable expense. The implementation can make use of

To make the integration between PACS and HIS easier, an interfacing protocol between them is required. Up to the version released in 1988 [3], the A C R - N E M A digital imaging and communications standards have not included requirements for a HIS-RIS-PACS interface. Furthermore, data structures of HIS or RIS have no major standards. In this situation, a local protocol definition on the application layer at each HISPACS implementation is required. A C R - N E M A committee now has a working group VIII for the HIS-PACS interaction. They are going to release a new version of standard which includes HISPACS interface protocols.

3. TRACS TRACS (Tokyo University Hospital Radiologic images Archiving and Communication System) [4] currently comprises three X-CT scanners, an image data archive, image display workstations, and a workstation for patient data processing (Fig. 2). The unique character of TRACS is that it puts emphasis on the management of the patient data of image examinations. For this purpose, TRACS employs a 32-bit workstation to control image display, interface with users, and communicate with HIS. The TRACS configuration is as follows. The three Y M S / G E X-CT scanners at the hospital and the medical image filing system Toshiba TDIS-FILE [5] cannot be connected directly, because of insufficient image transformation features and different image data standards. Therefore, it was necessary to connect the X-CT scanners to a local image station, D A T A V I E W [6] with TDIS-FILE connected to this local image

110 station. MIPS-87 standard [7] is used for the image standard between these two. The MIPS-87 standard is similar to the A C R - N E M A standard [3], with minor modifications, concerning Japanese character processing. (One Japanese character needs two bytes.) In every X - C T examination, image data is sent automatically to T D I S - F I L E , where it is archived on optical discs. The 32-bit workstation for patient data processing and user interface is a Toshiba AS3160 (model 3160 of series AS3000, which is an O E M of SUN 3/160). With a Japanese language wordprocessor and installed RDBMS, this workstation provides examination history, and diagnostic report making, on the same window manager of the workstation. Every time image data arrive to T D I S - F I L E , patient data of the examination (patient's name, ID, examination data and time, method, etc.) are sent automatically to AS3160. These data and the diagnostic reports done at the workstation form the database of X - C T examina-

tions. AS3160 issues commands to T D I S - F I L E , which images to display, on which CRT, in what window width/level, etc. T D I S - F I L E has optical discs and magnetic discs. The capacity of the former is enormous (3.6 GB per disc), but the access time is much longer than that of the magnetic discs. On the other hand, the capacity of the latter (120 MB, basic configuration, expandable up to 6 GB) is crucial for image data. If image data which are expected to be viewed (i.e., the new images and also the patient's old images for comparison) were copied from the optical discs to magnetic discs, the user would have no complaint about the slow access time of an optical disc. This prefetching can be done according to data on patient submission and examination reservation. These data can be acquired from HIS. By making use of these features, intelligent reading support and flexible key search for research and education are possible.

DATAVIEW (Local Image Workstation by YMS) to HIS TDIS-FILE 24 optical

I

discs

I

(3.6GB each) with disc changer

(Medical ImageFiling

System

by TOSHIBA)

. ~ . . . . ~ ~

-

[ AS3160

Image Displaysat RadiologyDept.

ImageDisplaysat ReferringDept. Fig. 2. TRACS system configuration. Thin arrow deno.tes patient data only; thick arrow denotes image data with patient data. (i) Image data of three CT's are sent to DATAVIEW. (ii) DATAVIEW sends data to TDIS-FILE by interconnection with MIPS-87. (iii) TDIS-FILE sends patient data of image examinations to AS3160. (iv) Image examination data base is constructed at AS3160.

(v) AS3160 makes interconnection with HIS and RIS. (vi) J3100 is a terminal of AS3160, located at referring departments. (vii) AS3160 and J3100s control image displays.

111

4. Implementation of TRACS

Scenario c' of Fig. 1 is the format which is implemented in TRACS. The interfacing subsystem is closely attached to TDIS-FILE. In TRACS, it is AS3160 which has the main control of the patient data of image examinations. AS3160 has multi windows, one of which can be a terminal of HIS, by remote logging. The image display of TDIS-FILE is controlled by the user through AS3160 or its peripheral terminals. Image examination data base (all the patient data) is managed at AS3160, and it sends reports to HIS. The advantages of this implementation type have been discussed in the previous section. Thinking of the architectures of current HIS and PACS, scenario c (or e') is the only feasible form of coupling. One of the unique features of TRACS is letting the interfacing subsystem manage all the patient data of image examinations.

5. Control of TRACS image workstations

There are many researchers trying to improve the user interface of the PACS image workstation [8-10]. They are all working with image workstations exclusively designed for PACS. Needless to say, image displays need to be designed to accommodate the functional requirements of PACS, because there is no other area that is handling this amount of image data with this quality and speed. The author, however, adopted a modified approach by utilizing a 32-bit multi-purpose workstation to control image displays. The advantages of this configuration are: (a) Multi-purpose workstations have shown evolution even faster than that of image displays. They provide high performance hardware at reasonable prices. (b) We can make use of the enormous software libraries accumulated on general operating systems (UNIX, in this case), which also give excellent environments for system programming. (c) By isolating the user interface from other PACS subsystems, we can enjoy the latest fruits of them. (d) Connected to HIS, the image workstation can

serve also as a terminal to HIS. This contributes to space and cost savings. To make this configuration possible, both patient data management and PACS should be designed with a direct connection to both patient and image data origins, to handle the large amount of data archiving and high speed data transfer. The user interface should be designed based on local intelligence of each terminal, and should be designed so as to allow local upgrading. Comparing the HIS terminals and PACS image workstations, the requirements for PACS workstations are much more complicated than for HIS terminals, because of image display features, while PACS workstations still have to handle patient data, too. Therefore, PACS terminals can serve also as HIS terminals, provided that they are designed to have the roles described in the preceding section. The author thinks that image displays controlled by a multi-purpose workstation are the future PACS components. In this environment where the user interface is easily upgradable, where workstation cost is optimum, and where both image data and patient data can be handled, the PACS workstation can be an ideal clinical workstation.

6. Final remarks

Recent hardware evolution has made PACS possible. Most efforts have been devoted to large-scale image memories, high-speed fiberoptic networks, and high-resolution displays. Now, the software bottleneck is coming in sight through these fading hardware issues. The research described in this paper is one trial in this direction.

References [1] A.H. Rowberg, Clinical Overview of IMAC System, Proc. of 1st Int. Conf. on Image Management and Communication (IMAC-89), pp. 290-291, 1989. [2] R. Arenson et al., The overlapping domains and interface between radiology informations management system and medical image management system (PACS), Proc. CAR (Computer Assisted Radiology) '88, 1988.

112 [3] NEMA; ACR-NEMA 300 digital imaging and communications, A C R / N E M A standards version 300-1988 (NEMA Publications, 1988). [4] M. Kimura et al., Tokyo University Hospital PACSystem: TRACS Importance of Non-Image Data Management and Integration to Hospital Information System, Proc. of MEDINFO-89, pp. 385-388, 1989. [5] N. Shigemura et al., Development of a medical image filing system, Proc. of the 4th JAMIT-PACS Symposium, 1987. [6] K. Takarabe et al., DATAVIEW: network image station, Proc. of the 6th JAMIT-PACS symposium, Med. Imag. Technol. 7 (2) (1989) 215-216. -

[7] MIPS Committee, MIPS-87 image standard (JIRA (Japan Industries association of Radiation Apparatus) Publications, 1988) (in Japanese). [8] J.B. Massicotte et al., A menu-driven user interface for a physician's imaging console, SPIE Vol. 536, PACS III, pp. 158-164, 1985. [9] F. van der Voorde et al., Development of a physicianfriendly digital image display console, SPIE Vol. 626, PACS IV, pp. 541-548, 1986. [10] D. Beard et al., Prototype single-screen PACS console development using human computer interaction techniques, SPIE vol. 767, Medical Imaging, pp. 646-653, 1987.