(Radiographics. 2001;21:781-787.)
© RSNA, 2001
Conceptual Database Modeling for Understanding and Developing Information Management Applications1
H. Hugh Hawkins, MD,
Scott K. Young, BA,
Katherine C. Hubert, BS and
Patrick Hallock, MS
1 From the Department of Radiology, University Hospital, 234 Goodman St, Mail Location 0761, Cincinnati, OH 45219 (H.H.H., S.K.Y., K.C.H.); and InConcept, Inc, St Paul, Minn (P.H.). Presented as an infoRAD exhibit at the 1999 RSNA scientific assembly. Received March 22, 2000; revision requested June 9 and received July 25; accepted August 7. Address correspondence to H.H.H. (e-mail: hawkinhh@healthall.com).
 |
Abstract
|
|---|
In response to rising health care costs and changing expectations concerning the quality of health care, information management is becoming increasingly important in the practice of medicine; more specifically, it is beginning to effect significant changes in radiology practice and patient care. Radiologic applications of information management include reporting diagnostic information generated from film interpretation as well as tracking utilization patterns of different imaging modalities and the variability of clinical outcomes, documenting the type of information sought by and provided to clinicians, and evaluating departmental quality standards and performance goals. Conceptual database modeling enables radiologists to understand and participate in the development of information systems, thereby improving the likelihood of successful results. In object-role modeling, groups of relevant objects and roles are identified and used to create elementary facts that form the "building blocks" for information models. The resultant models can easily be communicated, reviewed, and revised, allowing decreased development time and optimizing inclusion of relevant features in the target relational database. Increasing the amount of clinical and management input in the development process may help information systems better meet user needs, become accepted and more often used, and ultimately succeed.
Index Terms: Computers • Information management • Information management, systems • Radiology and radiologists, design of radiological facilities Radiology reporting systems
|
Introduction
|
|---|
Progress in radiology has traditionally been gauged in terms of the development of new imaging modalities. However, as the health care environment rapidly changes to meet the fiscal demands of managed care while responding to the higher expectations of health care consumers, a new nonimaging modality will emerge. Information management will be recognized as the means of bringing about significant changes and advances in radiology practice and patient care. Information management involves the creation and application of processes directed toward the collection and review of data in a structured and effective manner. The backbone of an information management system (IMS) is the database.
A database is any logically coherent collection of data organized for storage and retrieval by computers. Databases provide a high level of structure for the collection of data. Structured collection of data leads to a consistency that is essential for the operation of an IMS. Data within a database are captured electronically with a relatively small amount of storage space compared with conventional paper records. Databases also allow the use of queries and search tools, which make the retrieval of information from even large amounts of data fast and highly specific.
The two main types of databases are relational databases and flat-file databases, in both of which the data are placed in tables with columns and rows. However, in a flat-file database, the data are placed within a single, spreadsheet-like table. In a relational database, each of several tables contains a specific type of information, and the tables are linked by primary and secondary keys. Flat-file databases can be very efficient when there are simple one-to-one relationships between the data (eg, one patient to one medical record number [MRN]). When the data have one-to-many or many-to-one relationships (eg, one physician to many patients or vice versa), it is best to use a relational database. Relational databases are preferred to flat-file databases for all but simple applications that are limited in scope.
Information systems should facilitate the creation of searchable, measurable collections of data for the tracking and improvement of outcomes and performance. If the data manager and database user also have input into the design of the information system, there is a greater probability of high accuracy, quality, and usability of the collected data than if development occurs without such input (1). When the eventual users of an information system have insufficient or zero input into the development process, the resulting system will not meet user needs and will be poorly accepted and underused. It will eventually fail (2).
Because of their role as distributors of clinical information throughout the health care system, radiologists have great potential for participation in information management. Within the field of radiology, information management not only encompasses reporting of diagnostic information generated from film interpretation, but also includes (a) tracking the utilization patterns of different imaging modalities and the variability of clinical outcomes, (b) documenting the type of information sought by and provided to clinicians, and (c) evaluating departmental quality standards and performance goals. Unfortunately, many radiologists have little free time for nonclinical activities and lack the technical training necessary to develop software; as a result, their input into the fundamental design of information management applications has been limited.
Conceptual database modeling is a methodology that allows radiologists to participate in the creation and development of databases. In this article, we discuss the basic principles of modeling, describe and illustrate conceptual database modeling in particular, and discuss a specific type of conceptual database modeling known as object-role modeling (ORM).
|
Principles of Modeling
|
|---|
A model is created to represent reality, an approximation of reality, or a relevant structure. The model is then used as a substrate for analysis, database creation, or problem solving. Models are good tools because they are modifiable, scalable, and more easily constructed than a final product. Rather than focusing on the details of building the final product, the model emphasizes function and purpose while providing the basis for structural development. A software example of a model is an expert system, a program that recreates the decision-making process of an expert in a particular field of knowledge. The expert (eg, an experienced chest radiologist) is modeled so as to represent how he or she makes decisions. A modeler determines the essential aspects of the expert’s knowledge base and decision-making process. This information is entered into a software program that creates a model that makes the expert’s knowledge base and decision-making process usable by others. The modeling process allows participation as an end user (expert), modeler, or programmer. The radiologist may be the end user or may play two or all three roles.
|
Conceptual Database Modeling
|
|---|
Conceptual database modeling is the first step in database development and is the step at which those with little or no programming experience can have the most influence on the design of the IMS (3). A conceptual database model is like a blueprint. The graphical format of the model allows the end user (radiologist) to represent, using English sentences, the information needs of the application without worrying about technicalities such as programming languages, field sizes, and layout of tables. The model is in a format that end users, modelers, programmers, and information technology personnel can all understand, thereby facilitating open communication among these groups.
Conceptual database modeling is itself a process with several steps (3); the key steps for end users are the first and second steps: describing information examples with English sentences and representing this information in a graphical model (Fig 1). Conceptual models portray applications at a fundamental level, using terms and concepts familiar to users (3). The end user need not know or complete the subsequent steps; the person serving as the modeler can finish the process. Modeling software can link all four steps and can generate a database for any database management system for which it has a driver. Although there are several different types of conceptual database modeling, we chose to work with computer software that uses ORM, a method that has the advantages of using natural language, intuitive diagrams, and user-specific examples. There are other structured approaches to modeling (eg, entity-relationship modeling). Less structured approaches may serve as front ends, or interfaces, to databases.
|
Object-Role Modeling
|
|---|
ORM is based on the premise that any process can be described in terms of a group of objects and the roles they play. The basic building block is the elementary fact, which consists of a predicate with one or more objects (Fig 2). An object is a person, place, or thing about which data should be collected. A predicate is the association between one or more objects. Objects play various roles, which are described by the predicate.
View larger version (12K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 2. Elementary fact. Elementary facts consist of a predicate (rectangle) and two or more objects (ovals) with specific relationships and are the building blocks of an ORM diagram.
|
|
The first step in creating a conceptual database model with ORM is to verbalize, using English sentences, examples of the information required from the system. The examples may be taken directly from the end user’s experience or from input forms and output reports. Figure 3 illustrates information on patient demographics organized into a spreadsheet-like, flat-file format. This method of representation is less informative and intuitive than the conceptual model style of ORM. For example, the information in Figure 3 might be expressed as seven elementary facts: (a) "Patient has MRN," (b) "Patient has Last Name," (c) "Patient has First Name," (d) "Patient lives on Street," (e) "Patient lives in City," (f) "Patient lives in State," and (g) "Patient lives in Zip Code." In creating elementary facts, one is essentially identifying the objects and roles that are relevant to the desired information.
View larger version (31K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 3. Patient information arranged in a spreadsheet-like flat file format. Such a tabular arrangement becomes less intuitive and harder to work with as the amount of data increases.
|
|
Once the elementary facts have been determined, the next step is to identify how these facts fit together. In this case, "Patient" is an object that appears in each fact and plays various roles vis-à-vis other objects, including "First Name," "Last Name," "MRN," "Street Name," "City Name," "Zip Code," and "State (Code)" (Fig 4). The graphical representation of an elementary fact may be read from the perspective of any of the objects involved in the relationship, so that the diagrams may be read either from left to right or from right to left and still have meaning. For example, consider the relationship between the objects "Patient" and "Last Name." This relationship may be expressed as "Patient has Last Name" or as "Last Name is for Patient." Any number of objects may be interrelated, but ORM provides rules for making the descriptive sentences as simple as possible. In practice, very few sentences have more than two objects. The simplicity of the elementary facts is one of the aspects of ORM that make it accessible to the average radiologist.
Now suppose that we would like the information system to store additional data such as the patient’s work address. Building on our current model (Fig 4), we could state a new series of elementary facts describing a patient’s relationship to a workplace (eg, "Patient works on Street," "Patient works in City"). These facts would be translated into additional relationships between objects and added to the ORM diagram (Fig 5), resulting in a significant increase in the number of facts and a larger, more complex diagram.
View larger version (35K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 5. Expansion of the initial patient information model (cf Fig 4). Four additional facts have been added to the model to allow collection of data concerning a patient’s work address. This adds to the overall size and complexity of the model.
|
|
An alternative approach is to create an object called "Address" (Fig 6). The type of address (eg, home address, work address) is denoted by the fact, "Address has Address Type." The object "Address" is reusable, consistent, and easily tracked throughout the ORM diagram. It could be linked to any object for which address information is needed, such as "Physician" or "Contact Person." This is far easier than repeating all of the component objects for "Address" every time an address is needed in the model. Either approach to modeling "Address" works. One is conceptually cleaner and more visually accessible than the other, although in most cases, the two approaches would create workable and very similar databases. A benefit of ORM is that the modeler can reach the same endpoint in a variety of ways. Although some designs are more efficient than others, there is a lot of flexibility in how one arrives at a solution. Success can be achieved with any of a number of solutions.
View larger version (30K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 6. Simplified model derived by creating an object "Address" (cf Figs 4, 5), which represents both the patient’s home and work addresses. In addition, the MRN now represents the object "Patient." This is known as using a reference mode and is common in the modeling process. Uniqueness constraints (double-headed arrows) are determined by answering simple questions regarding object-predicate relationships. In this case, one question would be, "For each Patient, how many Addresses may be recorded?" The answer would be, "Exactly One." The second question would be the reverse of the first: "For each Address, how many Patients may be recorded?" The answer would be, "Zero or More." These answers could then be translated into the descriptive statement, "Each Patient has at most one home Address." This statement determines how the constraints are placed on the relationship between "Patient" and "Address." Black dots indicate that the object "Address" must play a role (ie, is mandatory) in six different relationships.
|
|
Although there are additional details within a model that must be specified, use of modeling software makes this process accessible to the nonprogramming community. Although the software may include technical database terms, specification of details can be performed with simple language. For example, uniqueness constraints, which are further descriptors of the relationships between objects (ie, one-to-one, one-to-many, or many-to-one), can be determined by answering simple questions about the relationships of the objects attached to a given predicate. These answers may then be translated into a descriptive statement that determines how the constraints are placed on that particular relationship. This process also determines whether a particular role is mandatory (Fig 6).
Figure 7 demonstrates a model designed for tracking patient movement during a single appointment. By reading the facts, one can deduce the steps through which the patient progresses during the appointment. Again, the diagram is descriptive, making it intuitive to work with. This model would generate a sufficient database for tracking screening and diagnostic patients in a mammography center. However, as with the transition from Figure 4 to Figure 5, adding more information requirements would increase complexity and perhaps necessitate modification of the database.
View larger version (39K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 7. First draft of a patient tracking model. This model would generate a database for tracking information about how much time the "Patient" spends at each step of an appointment for a "Procedure." Double-headed arrows indicate uniqueness constraints.
|
|
Figure 8 demonstrates the process of generalization, which has two significant advantages: simplification of the diagram and increased modifiability of the database. Merely adding a term to a list of events rather than changing the database structure may represent a new event at the mammography center, such as a biopsy. Figure 8 also demonstrates how derivations can be built into the diagram.
View larger version (20K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 8. Generalized version of the initial patient tracking model (cf Fig 7). The various aspects of an appointment have been generalized to the object "Appointment Event." This is a cleaner model that allows the tracking of different parts of an appointment without altering the basic structure of the database as information needs change over time. This model would also allow the database to arithmetically derive the duration (in minutes) of each "Appointment Event" from the start and end times. Furthermore, this variable does not have to be stored as a field, thereby improving efficiency. Double-headed arrows indicate uniqueness constraints.
|
|
After the conceptual model is complete, the modeling software checks the ORM diagrams for errors and generates the familiar logical tables that constitute the essence of a relational database (Fig 9). The tables are then integrated into a database management system, the backbone of an information management application. By participating in the design of the database, the end user provides valuable insights and information that enable development of a more usable information system.
View larger version (54K):
[in this window]
[in a new window]
[Download PPT slide]
|
Figure 9. Logical tables generated from the conceptual model. These tables are derived from the earlier ORM diagrams depicting Patient Address and Patient Tracking (cf Figs 4-8) and are linked by the Patient field. They illustrate how the various aspects of the model come together to form a relational database.
|
|
|
Conclusions
|
|---|
The examples presented in this article do not represent a completed project; they do, however, illustrate that conceptual database modeling allows end users to participate in the database development process. The resultant models can easily be revised and scaled, allowing decreased development time and easier communication of features of the target relational database. As implemented in modeling software, conceptual database modeling facilitates translation of database applications across different database management systems as well as reengineering of databases from existing applications. Increasing the amount of clinical and management input in the development process may help information systems better meet user needs, become accepted and more often used, and ultimately succeed.
|
Acknowledgments
|
|---|
The authors thank Robert Hankins, PhD, and Lin Guo, PhD, for their assistance as end users in the modeling process for the breast center database.
|
Footnotes
|
|---|
Abbreviations: IMS = information management system, MRN = Medical Record Number, ORM = object-role modeling
|
References
|
|---|
-
Davenport TH. Information and its discontents: an introduction. Information ecology. New York, NY: Oxford University Press, 1997; 1-14.
-
Berkowitz LL. Diagnosing doctors: four types of physicians require four approaches to promote clinical computing acceptance. Healthc Inform 1998; 15:93-96.[Medline]
-
Halpin TA. Conceptual schema and relational database design 2nd ed. Sydney, Australia: Prentice Hall, 1995.
Top
Abstract
Introduction
