Co m p ure rize d Me d uxl lm a g rng a nd G ra p htc s. Vo l 15. No . 3. pp. 171-176. 1991 Printe d m the USA All rlg hts re se rve d . PACS DATABASE ARCHITECTURE AND DESIGN Ricky K. Taira *, Brent K. Stewart and Usha Sinha Medical Imaging Division, Department of Radiological Sciences, UCLA School of Medicine. 10833 Le Conte Ave., Los Angeles, CA 90024-1721 (Received 2 I February 199 1) Abstract-PACS (Picture Archiving and Communication Systems) database design requires careful under- standing of the data and processing needs of radiologists, referring physicians, radiology staff, administra- tors, and researchers. Due to access requirements, the physical implementation for the management of small text data sets differs from the implementation strategy for large image data sets (centralized vs. distributed storage strategies). In this paper we discuss the database structure, storage architecture, file placement strat- egies, and administration considerations of the UCLA PACS. Key Words: Database management systems, Fault tolerance INTRODUCTION The architecture and design structure of a PACS (Pic- ture Archiving and Communication System) database is critical for the efficient access and integration of PACS operations. A common predicament among PACS de- signers is the integration of preexisting heterogeneous database management systems (DBMS) which have different views of the overall PACS goals. For exam- ple, the first release version of the UCLA PACS sys- tem has operational the following data management systems: (a) local DBMS’s for each commercial imag- ing system (GE, CT, and MR scanners, Philips com- puted radiography, Fuji computed radiography, etc.); (b) a radiology information system (Maxifile IV by Di- mensional Medicine, Inc.); (c) a DBMS for a pediatric radiology PACS module (1); (d) a DBMS for a neuro- radiology module (2); and (e) a DBMS for a coronary care unit module (3). Each of these DBMS’s has its own PACS data schema and manipulation language and as such, cannot easily access the data stored and managed by the other DBMS’s. Each are centralized DBMS’s without sufficient networking software. To a large extent, the problem rests on the fact that there are no PACS database standards (data schema, manip- ulation language, etc. ) . A good DBMS design should address the follow- ing issues: (a) Integration-PACS modules must be able to share information. Heterogeneous hardware and software systems may exist; (b) Performance-effici- ent access to user and program requested data; (c) *To whom correspondence should be addressed. 171 Scaleable-easy to accommodate growth as the appli- cation scope increases; (d) Reliability- hardware re- dundancy and automatic database recovery capabilities; (e) Open Architecture-interface to other DBMS: (f) Advanced Development Tools-3GL, 4GL, object ori- ented; (g) Flexibility-easy to make database schema changes. 2. DATABASE DESIGN There are two general database design methods: to>p- down and bottom-up. In this section, we describe the top-down approach in which the system is designed from scratch. Three levels of data modeling are per- formed including a external user model, a logical con- ceptual model, and a physical storage and access model. The designer has total freedom of the database structure and its implementation. For new PACS instal- lations, this is the best method. In Section 3 we dis- cuss the bottom-up approach which entails the inte- gration of preexisting database management systems into the PACS operation. 2.1 External data model The first step in database design is the establishment of an external data model. This model is a database representation of the real “micro-world” whose static and dynamic behavior is being mimicked. The external model should consider all data and processing require- ments for all users to be encorporated into the PACS schema. This extensive data gathering activity is per- formed via observation, interviews, and surveys and typically requires several iterations.