TECHNICAL NOTES Annals of Nuclear Medicine Vol. 12, No. 2, 119-126, 1998 Data base and management system for clinical positron emission tomography (PET) studies Hinako TOYAMA,* Yuko AMOU,** Kenji ISHII,* Keiichi ODA* and Michio SENDA* *Positron Medical Center, Tokyo Metropolitan Institute of Gerontology **Imaging Physics and Tracer Chemistry, Division of Advanced Technology for Medical Imaging, National Institute of Radiological Sciences A data base and management system connected to an image analysis system has been developed and utilized for clinical positron emission tomography (PET). This data base system, l) is based on "GBASE", a general purpose data base, which runs on a UNlX work station, 2) works on a network file system and is connected to PET cameras and other data acquisition devices as well as to an image analysis system "Dr View", 3) centrally manages the data stored in a data storage unit, 4) is easily modifiable and expandable, and 5) has a human friendly interface which requires minimum operation for registration, retrieval and management. We have been using this system to handle clinical PET data for seven years and have optimized the data base schema. As a result, this system has become a truly practical tool for the daily operation and is well-received by technologists, nuclear physicians and attending physicians. Key words: data base, PACS, positron emission tomography (PET), management system INTRODUCTION As NUCLEAR MEDICINE provides a good environment for the evaluation of the picture archiving and communication system (PACS) thanks to a relatively small amount of digital data, many authors have reported various systems and their clinical applications. Miller et al.1 at Washington University School of Medicine, reported a one-CPU system built in a nuclear medicine sub system that performs processing, display and archiving functions. Their system is simple and convenient owing to absence of complicated protocols for transfer of images to and from the computers that perform display and analysis. The patient information is brought from a radiology information system (RIS) on the main network of their university and is linked to the image data. Brown et al.2 proposed a conceptual design of a nuclear medicine PACS to one of the nuclear medicine computer venders. In their system, the computer node for each gamma Received October 27, 1997, revision accepted December 17, 1997. For reprint contact: Hinako Toyama, Positron Medical Center, Tokyo Metropolitan Institute of Gerontology, 1-1 Nakacho, Itabashi-ku, Tokyo 173-0022. JAPAN. camera or image viewer is independent of the others and communicates with them through a central host computer for image transfer. As a result, a hardware failure of one node does not affect another. Juni3 mentioned that such a system must be sufficiently "user-friendly" for all technologists and physicians to operate with minimum instruction. They settled on a system based on general purpose computers and network buses and purchased this system through a big nuclear medicine computer vender. Because most of the currently available nuclear medicine PACS are inseparable from the image display and analysis system, the schema of the data base strongly depends on the latter, making it difficult to customize or expand it. Generally, no PACS is commercially available that fits every institute because the principle of the system differs according to the institute and hospital. Furthermore, those PACS systems reported by the above authors obtain patient information from a much larger PACS such as a hospital information system (HIS) through complicated procedures. We have developed a compact, independent and human friendly database and data management system for clinical PET. This system is based on a general purpose data base GBASE (Ricoh Co. Ltd. Japan) which works on a UNlX work station separately from our image display and analysis system Dr.View (Asahikasei Joho System Co. Ltd. Japan). All PET data and related blood data and MRI are located on another node with two jukeboxes of 19 gigabytes Magnetic Optical disks (MO). Because the data base and management system is connected with Dr.View and the data storage through a network file system, physicians and technologists can have access to the data from any terminals. We have used this system for seven years and have improved the manner of operation and the data base schema. The system is practical and well received by technologists, nuclear physicians and attending physicians. SYSTEM CONFIGURATION Hardware system A block diagram of our entire hardware system is shown in Fig. 1. Our network consists of data acquisition devices (PET cameras and a blood radioactivity counting system), processing and display units, a data storage unit, a data base and management system and printing devices. For data processing and display, we use six medical work stations (MWS) and a Dr.View system. The data storage system consists of two jukeboxes, each with 16 platters of 1.2 gigabytes (GB) magnetic optical disks (MO) and 2 GB cash memory. PET images and associated data are trans-formed to Dr.View format and stored in the jukeboxes. If necessary, MRIs and SPECTs acquired in other hospitals are also transferred on- or off-line to the jukebox in Dr. View format. For personal data storage, 3.5-inch MOs connected to each MWS are used. The data in the jukeboxes are further stored in a rewritable compact disks (CDR) as a final backup. There are two types of work stations. DEC (Digital Equipment Corp. Maynard, MA USA) and SGI (Silicon Graphics Inc. Mountain View, CA USA). The data storage system works on the DEC work station, and data processing and display are performed mainly on SGI workstations. Almost all disk area in or connected to a work station is mounted on every other work station by the NFS (Network File Server) utility as shown in Fig. 2. The data areas (:/dvdata for centrally managed data storage and :/usrdata for private data storage) and source-file area for data analysis programs are shared by all work stations. There are two home-directories corresponding to SGI and DEC work stations, respectively. Software system As the basic data base for our system, we adopted "GBASE" which has been developed to handle various types of data such as images, characters, numerals and arrays. The advantage of this data base is to be able to represent the relation between data and their associated information with real- or virtual- "link" functions. In the "GBASE" system, only registered users can retrieve, register or update according to their privilege levels. The image analysis system "Dr.View" is used to process various types of medical images and to develop software for data analysis and display. Two sets of Dr.View modules, related to SGI or DEC workstation, respectively, are generated from the common source files. Application programs including AVS (Application Visualization System: Advanced Visual Systems Inc. Waltham USA), IMSL (Visual Numerics Inc. Houston, Texas USA), and Matlab (MathWorks Inc. Natick, MA USA) are also commonly used within the same types of work stations. Schema of database The data base consists of a tree structure of four main records ("Patient", "Study", "Scan" and Data") and several associated table records ("Institute", "Researcher", "Disease", "Study_Name", "Study_Paradigm", etc.). The tree structure describes the relationship between "Patient , Study" and "Scan" and affiliation of each data file as shown in Fig. 3- . These records have common fields "Patient_ID", "Study_Number" and "Scan_Number", used as a key to relate the records. Each table record has code-name pairs and some additional fields as shown in Fig. 4. The code values are used as an index in the retrieval process and the names are used in the display. For ex-ample, in the "Study_Name" record, the "Study_Code" <06> corresponds to the "Study_Name" . As the code value ("Study_Code") in the main record ("Study") is connected to the corresponding record ("Study_Code") in the table record ("Study_Name") by a virtual link, new items can be appended easily by input-ting a new code number and a new name in the table record without changing the data base schema or contents of other records. This link is called "virtual" because the connection between two records becomes effective only when the records are retrieved. Data filename In order to differentiate data files easily, the filename is given according to the following rule. A filename consists of five characters for patient ID, two characters for data meaning, three characters for version number, and a period and three characters for data type in this order. For example, 00001BF101.IMA means the blood flow image of the patient with ID # 00001. DATA MANAGEMENT SYSTEM The data management system has three actions: registration, retrieval and update. Figure 5 shows the structure of our data management system. The data management program consists of data base utility routines and user inter-face routines. In utility routines for data base handling, we use data manipulation libraries specific for our data schema supplied by Ricoh Software Inc. (Tokyo, Japan). These libraries contain functions for handling each record in the schema and facilitate access to the data base through C programs. User interface routines are constructed with a Motif tool kit, display editable texts, labels, buttons and pull downs at suitable positions in the window according to the display format definition files, which is a text file. This data base works on a network of work stations and is retrieved from any of them. The retrieval and update parts work quickly and connect smoothly with successive operations by using work sheets explicitly and implicitly. Registration Data are registered by typing in a command with a data file name without key inputs of the bulk of information. Figure 6 shows the registration sequence of a new image data file. The "Patient_ID", "Study Number" and "Scan_Number" in the file header are examined to verify whether the "Patient" /"Study" /"Scan" record for this data file already exists or not. If not, new records of "Patient", "Study" and/or "Scan" are created automatically. A new "Data" record that corresponds to the data file is created and the fields of this "Data" record are filled automatically with the information obtained from the header of the data file (Patient_ID, data acquisition condition, etc.) and from the system (address, create time, create user name, etc.). The other contents of the field in the records are given manually by means of the update tool described below. Retrieval A block diagram of the retrieving routine for the patient information is shown in Fig. 7. This structure follows the tree structure of the data base. At the beginning of the patient search, query conditions such as "Patient_ID", "Study_Name", "Disease_Name", "Organ" and "Study Name", etc., are selected from tables in a window by means of a mouse. They are given to the data base, and the system returns the list of patients that meet the condition(s). The results are shown in the window with the Motif widget and can be saved in a text file for optional print out. The display format of the result is defined by a format definition file written in a text format, which is easily customized by the user without re-coding the source program. When the user selects one of the patients by a click, the window that contains detailed information about the selected patient is displayed with the related study list. The study list is also clickable and relates to the window of the information of the selected study including the scan list. The system also provides the list of data files that belong to the selected study, together with data file related information. The user can click one or more data files in the list and send them to Dr.View for image display and further processing. Data files can also be retrieved directly f,or patients with conditions attributable to "Data" as well as "Patient", "Study" and "Scan" records (Fig. 8). The procedure starts with inquiry of the data record. "Patient", "Study" and "Scan" information can also be referred after selecting a data file. Meanwhile, when we click the data filename, the scan number and/or study number, the information related to the data, scan and/or study is displayed on the screen . Update A user friendly program for updating the patient scanning history is also available (Fig. 9). The patient history consists of the "Patient", "Study", and "Scan" records and has a hierarchical structure. The "Patient ID" should be specified to start the updating operation. An editable patient record window is displayed with the study list. An editable study record window with a scan list is displayed by clicking the study list in the patient window in the same manner as in the retrieval process. A scan record window is displayed in the same way as the study record. To avoid confusion, this program is designed so that only one study (scan) window is handled at one time. To update or insert to the editable record window, the operator selects corresponding items from the window of the appropriate table record such as "Disease Name", "Researcher" and "Institute", which show the codes and the names. After the editing operation, a command for update transaction is invoked by choosing the "update" menu from the menu bar. The last referred "Patient ID" in the update or in the retrieval operation is saved in a common work sheet file and is used in the next operation of either process. If the user finds an error or unfilled fields during browsing, he/ she can edit the patient history without explicitly specify-mg the "Patient_ID". Sharing the last referred "Patient_ID" provides a convenient connection to application pro-grams, i.e. the user does not need a tedious keyboard operation for specifying the "Patient_ID". Connection to data analysis system A feature of this system is its useful connection to the data analysis system "Dr.View". We can search for the data files to be processed either from "Study_Name", "Study_Date", "Radiopharmaceutical" or basic patient information and transfer them into the data processing tool automatically. CLINICAL APPLICATIONS We applied this system to I ,400 studies of 1,400 patients carried out in our PET center for the past six years. Figure 10 shows a CRT hard copy of a patient retrieval process. Brain" is selected for the organ, "FDG_QLT" for the study_name, "Demenna of Alzheimer type" for the disease_name and "fasting" for the study_condition from look up tables without typing. In this manner, we can retrieve patients within one second by means of the "Study_Name", "Organ", "Disease Name", "Institute" or attending "Physician". We can select them from the list in the windows by clicking. When picking up a patient and selecting a study from the retrieved list, the data list that belong to the study comes up as shown in Fig. 11. By clicking the "DV" button of a data filename in the list, the data filename and its address in the system are transferred to "Dr.View" so that the images are displayed instantly. Dr.View provides a tool to select and save ROI values in a text file together with the image filename and other information. We have also developed Dr.View modules for analyzing dynamic PET data by a compartment model analysis, in which mean values for estimated parameters are saved into a file with an ASCII format. Statistics can be calculated on these values with commercially avail-able software, based on the related data such as clinical diagnosis, age and gender obtained from a text file printed out by the retrieval tool. We also connected this data base to a reporting system which is described in detail else-where.5 DISCUSSION We started planning the system configuration and the data schema more than a year before our institute was opened. We planned to separate the data acquisition devices, the data processing and display system and the data base and management system from each other, and to connect them by a network and a common operating system. We can then easily improve the hardware or the software of the database system and the data processing and display unit independently. In fact we have modified the schema and retrieval process more than once since we first installed the system seven years ago with a minimum operation and without data loss in order to obtain the most effective processes, meet the clinical requirements and keep up with improvement of the operating system (OS) and the data base (GBASE). Because the central data storage unit is independent of the data base system, no space is taken up by disks, data transfer or data losses. The jukeboxes and cash memory system are very convenient for referring to data files without paying attention to the physical address in MO disks. The network file system has been established to occupy the minimum disk space for the data and the programs for data analysis and display, and has proved to be convenient for developing programs and processing the data without being aware of which computer to use. The good connection and independencey of the data-base and the data processing system is noteworthy. We can easily pick up a data file to be analyzed by the retrieval tool and send it to Dr.View as well as register in the database a data file newly created in Dr.View. This system has made possible a human friendly inter-face requiring minimum operation by allowing selection of items from look up tables in pop up windows without typing work and by making a connection with other operations through work files. Creation and registration of records for new patients (or study or data) is performed automatically with the information stored in the header of data files. Other information that is not found in the header is inserted manually with the update tool. This data base system has been running since clinical studies started in our PET center. Because we are handling only a few modalities such as PET, MRI and their associated data, the structure of the data scheme is simpler and the amount of data is smaller than in the radiology and nuclear medicine department in a standard hospital. This is the reason why our system has been successful, but it can be expanded to a bigger one such as RIS or HIS with a larger data storage and an appropriately designed scheme for the data base. Construction of a data bank is also possible with this system. For example, results of ROI analysis for the cerebral glucose metabolic rate in normal volunteers or patients with various diseases may be re-corded in the GBASE together with useful and necessary information on the patients and studies. Since the data management system is written in C language and uses MOTIF for screen management, it can be installed in other UNIX work stations with minor modifications. CONCLUSION A data base and management system has been developed and applied to clinical studies in a positron emission tomography (PET) center. This system is features by minimum operation for registering and retrieving data and updating the data base and efficient connection with other operations through work files. A good combination between the data base and the data processing systems has been achieved, so that this system has become a truly practical tool in the daily operation and is well-received by technologists, nuclear physicians and attending physicians. REFERENCES l. Miller TR, Jost RG. Sampathkumaran KS, Blaine GJ. Hospital-wide distribution of nuclear medicine studies through a broad band digital network. Semin Nucl Med XX: 270-275, 1990. 2. Brown PH. Krishnamurthy GT. Design and operation of a nuclear medicine picture archiving and communication system. Semin Nucl Med XX: 205-224, 1990. 3. Juni JE. NucNet. A single-vender clinical picture archiving and communication system-Description and reflections. Semin Nucl Med XX: 193-204, 1990. 4. Line BR. Nuclear Medicine information management sys-tem. Semin Nucl Med XX: 242-269, 1990. 5. Jamzad M, Ishii K, Toyama H. Senda M. A human friendly reporting and database system for brain PET analysis. Ann Nucl Med 10: 99-104, 1996.