Database Design Patterns for Healthcare Information Systems M. Muji1, R.V. Ciupa1, D. Dobru2, C. Bica2, P. Olah2, V. Bacarea2, and M. Marusteri2 1 2
Technical University of Cluj-Napoca, Cluj-Napoca, Romania University of Medicine and Pharmacy, Tirgu-Mures, Romania
Abstract—This paper presents some general design patterns for databases in Healthcare Information Systems. The presented solutions were validated in a research project for early diagnosis and treatment of the patients with major risk of esophageal and gastric cancer. Our emphasis is on the generalization capacity of the database structure, which is able to serve other medical specializations, with no compromises for the integration of the entire system. Keywords—healthcare information systems, database design patterns.
I. INTRODUCTION Healthcare Information Systems require highly specialized solutions from an Information Technology perspective. There are important requirements of the medical domain, which determine the success or the failure of this class of projects. This paper addresses the following issues related to the special nature of healthcare information systems. •
•
•
The continuous change of information requirements (due primarily to the advancements of the medicine as a science), while the importance of historical data is not decreasing in time (like in the majority of the classical business information systems) [1]. The business-oriented approach of the IT development teams: while there are administrative and operational requirements which resemble with any business information system, the most important requirements (those particular to the medical field) need special treatment at the design stage of the information system lifecycle [2]. The lack of integration of the medical records, across different specializations and/or health care institutions. This creates great difficulties for historical data analysis and medical research studies [3].
To be able to respond in a satisfactory manner to the above requirements, an information system needs two important features: 1. The existence of a standard, integrated, vocabulary - as a dictionary of concepts and terms, accepted and used by the medical community [4][3].
2. The capacity to provide the various applications (e.g. applications serving different specializations, department, and/or healthcare institutions) with specific information, without compromising the data integration at the conceptual/community level of the system. We propose a data-oriented approach [5] for the development of healthcare information systems, which implies a database-centric system, where the various applications share the same integrated data source. The database design solutions presented in the next sections of the paper, were validated in a medical research project for early diagnosis and treatment of the patients with major risk of esophageal and gastric cancer [6][7]. We argue that our solutions provide the necessary scalability to cover other specialized applications (with medical or administrative purposes), without structural changes at the database level. It follows that the presented data structures can be used as design patterns in a variety of health care information systems. Section II presents the main information requirements of our project, and gives us the means to illustrate by examples the general design pattern exposed in Section III. We conclude showing how our proposal supports the information requirements of healthcare information systems, as exposed in the present introduction.
II. SHORT DESCRIPTION OF OUR PROJECT, IN TERMS OF INFORMATION REQUIREMENTS
There are two major information requirements identified by our project team [6]: one related to data inputs, and the second related to ad-hoc information requests, formulated by specialists for research purposes. The first requirement basically imposes the existence of different ways to structure the data inputs of the system. The particular structure of the data entered in the system by a certain user depends on multiple criteria (e.g. the more or less subjective preference of a particular team of physicians, current investigation instruments, or current research emphasis) and is subject to continuous changes over time. This is why the system should allow changes of the standard (structured) files completed on a daily bases for every patient.
S. Vlad, R.V. Ciupa, and A.I. Nicu (Eds.): MEDITECH 2009, IFMBE Proceedings 26, pp. 63–66, 2009. www.springerlink.com
64
M. Muji et al.
Here are some examples of standard data files: •
The Screening File: personal identification data, patient’s medical history, results of the conventional endoscopy; • Barett Esophagus Observation File; • Chronic Gastritis Observation File; • Gastric Adenoma Observation File; • Gastric Ulcer Observation File. All the above standard files have a hierarchical structure, which permits the natural grouping of the effective data items in chapters and subchapters (see Figure 1).
possible questions like this at the analysis phase of the system development, so we need to design the system in a way that will enable this kind of requests by any user without IT expertise, and at any time after the system is implemented. The information system built supports effectively the above requirements, and has also a great potential for other application areas. The main reason resides in the way the database was designed, which is the subject of the next section of the paper.
III. THE DATABASE DESIGN As we have already emphasised in the introductory section, there are two important features that could determine the success or failure of a healthcare information system. The first is related to the existence of a common vocabulary of generally accepted terms for all the medical concepts or administrative data used by the system in connection to any patient. The second refers to the capacity of the system to provide the specific information for every application, without compromising the integration of the central database. This requirement is, in fact, valid for any Enterprise Resource Planning System (i.e. an integrated business information system), but in health care it has a special importance. In fact, the abundance of unstructured and/or non-integrated data appears to be one of the most important problems of healthcare information systems [3]. The ANSI/SPARC three levels architecture [8] provides a good illustration of this matter, identifying three different views about data: the internal or physical view, the conceptual or community view, and the user view (see Figure 2). EXTERNAL LEVEL
User view 1
CONCEPTUAL LEVEL
INTERNAL LEVEL
Fig. 1 The hierarchical structure of standard data files The second major information requirement of our project, i.e. the need for ad-hoc requests, basically means the possibility to search for any combination of data items values which may have been occurred in the historical data. An example would be: “get all the patients with age less than 50, who were positive to Helicobacter Pylori, but did not have gastric ulcer”. Obviously, we cannot foresee all the
Fig. 2
User view 2
...
User view N
Community view
Physical view
The three levels architecture
Our challenge, while designing the database, is to be able to provide the required data at any user view, but to avoid the fragmentation of the community view, at the same time. Thus, we have created at the conceptual level of the system a common catalogue of ‘standard data items’, which will be accessed by all the applications (i.e. the user views
IFMBE Proceedings Vol. 26
Database Design Patterns for Healthcare Information Systems
of the system). However, every user view needs to structure these data items in a particular way (e.g. all the different ‘standard patient files’). In order to provide the required flexibility to the system, i.e. the possibility to define any standard patient file without changes in the database structure, we have created an open ‘file type’ catalogue, and the means to dynamically build the particular hierarchical structure of each file type declared in the catalogue. Every node in these structures should be standard data items previously defined in the ‘standard data item’ catalogue (see Fig. 3). Finally, the actual patient files, which in fact constitutes the transactions of the system (i.e. the data entries in the system, which documents the basic operations of the health care business), are dynamically generated based on their correspondent ‘patient file type’ definition.
65
Item_Option_List
Data_Value_Type PK
Data_Val_ID
PK
Option_ID
Data_Val_Name
FK1,U1 U1
Std_Item_ID Option_Order Option_Name Option_Description
Std_Item PK
Std_Item_ID
FK1 FK2
Std_Item_Name Std_Item_Description Std_Item_Type_ID Data_Val_ID
Std_Item_Type PK
Std_Item_Type_ID Std_Item_Type_Name
File_Type
Std_Patient_File PK,FK1 PK,FK2
File_Type_ID Std_Item_ID
FK3
Parent_Node Child_Order
PK
File_Type_ID File_Type_Name
Patient_File PK,FK5 PK,FK3 PK,FK2 PK
Patient_ID File_Type_ID Std_Item_ID Child_Order
FK4
Parent_Node Val_txt Val_number Val_date Val_img Option_ID
FK1
Patient PK
Patient_ID Patient_Name External_ID Other_Data
Fig. 4 Attribute level database diagram
Fig. 3 Entity level database diagram A high level picture of the described entities is represented by Fig. 3. After the entities were populated with attributes, we have arrived at the entity relationship diagram represented in Fig. 4. While the attribute names in the diagram are generally self-explanatory, it is important to emphasize the compact design of the standard patient file’s hierarchical structure. The ‘Std_Patient_File’ table allows us to define any number of tree-structures, one for every ‘File_Type’. When a particular file should be completed for a patient, the system will automatically generate its structure, based on the standard structure found in the ‘Std_Patient_File’ table, simply applying a filter on the ‘File_Type_ID’ of interest.
Another entity which requires a short description is ‘Item_Option_List’. By means of this table, we offer to the end user (i.e. the specialist physician) the means to declare predefined values for a standard data item. Thus, besides numbers, text, dates, or pictures, a data item can take in a certain patient file a predefined value from its own ‘option_list’. This is of a particular importance for statistical analysis studies. The described database schema provides a flexible model for the construction of hierarchical data structures, which can be applied not only to structure the inputs of the system, but also to build, in an ad-hoc manner, data reports which regroup, for research purposes, data from different standard input files. This constitutes a valuable tool for data mining the historical data. However, any data mining tool is useless as long as the common vocabulary is not kept up to date over time [4]. This is why the ‘Std_Item’ entity needs an extension which
IFMBE Proceedings Vol. 26
66
M. Muji et al.
will permit the association of two or more data items, as different terms that describe the same concept [9]. Thus, the medical teams will be able to maintain a semantic data lineage [10] of the terms contained by the common vocabulary over time. We see this as a mandatory extension of the proposed design pattern, especially for large integrated healthcare information systems. Another possible future extension would be to allow the end user to build more complex interrogations, i.e. be able to express filtering conditions linked in any succession by AND’s and OR’s. This can be accomplished using the same structuring mechanism employed for the standard data files. Thus, the same hierarchical pattern can serve two different purposes related to the dynamical construction of custom data reports: 1. To specify the content of the report, in a similar fashion with the construction of the standard input files; 2. To specify the filtering conditions of the report, in a customised succession of logical connectors (e.g. and, or, not). This would be possible, for example, by defining special purpose standard item types (as records of the Std_item_type table), one for each logical connector. By convention, where the data filter is specified as a hierarchical structure, all the children of one of these nodes will be linked by the corresponding logical connector. Thus, the user will be able to build complex conditional expression, which can also be saved as custom data filters, simply by saving their hierarchical structure in a table with a similar heather as ‘Std_patient_file’.
IV. CONCLUSIONS Enabling the medical specialists to define new standard patient files, without the intervention of the IT specialists, the proposed database design pattern ensures a high degree of scalability for the external level of the system (see Fig. 2). Thus, every team of physicians may create its custom ‘view’ of the system, which best fits some particular research or administrative purposes. At the same time, the integration of the database at the conceptual level is
preserved, regardless the number of new external views defined by the users. For these reasons, we see the proposed design pattern as a viable solution for the development of scalable, integrated Health Care Information Systems.
ACKNOWLEDGMENT This paper presents the results of a study funded by Romanian Education and Research Department, under contract PN-II-RU-TD-2008-3/218/2008.
REFERENCES 1.
Armoni, Adi. (2000) Healthcare Information Systems: Challenges of the New Millenium. s.l. : Idea Group Inc (IGI). 2. Inmon, Bill. (2007) Data Warehousing in a Heathcare Environment. The Data Administration Newsletter - TDAN.com. January 1, 2007. 3. Wager, Karen A., Lee, Frances Wickham and Glaser, John P. (2005) Managing Health Care Information Systems: A Practical Approach for Health Care Executives. s.l. : John Wiley and Sons. 4. Muji, M., et al. (2007) Best Practices in the Design and Development of Health Care Information Systems. Acta Electrotehnica, Vol. 48, 4, pp. 51-54. 5. Lewis, Bill. (2007) Data-Oriented Application Engineering: An Idea Whose Time Has Returned. The Data Administration Newsletter TDAN.com. January 1, 2007. 6. Muji, M., et al. (2007) Information Systems as Tools for Medical Research Activities. Acta Electrotehnica, Vol. 48, 4, pp. 47-50. 7. Dobru, D., et al. (2007) Program de supraveghere prin sistem informatizat a leziunilor esofagiene cu potential malign. Revista de Medicina si Farmacie Tg. Mures, Vol. 53, pp. 54-57. 8. Date, C. J. (2003) An Introduction to Database Systems (8th edition). s.l. : Addison-Wesley. 9. Ross, Ronald G. (2005) Business Rule Concepts - Getting to the Point of Knowledge. s.l. : Business Rule Solutions, LLC. 10. Lewis, Bill. (2008) Data Lineage: The Next Generation. The Data Administration Newsletter - TDAN.com. August 1, 2008.
Author: Institute: Street: City: Country: Email:
IFMBE Proceedings Vol. 26
Marius Muji Technical University of Cluj-Napoca 26-28 G. Baritiu Cluj-Napoca ROMANIA
[email protected]
