MEDINFO 2004 M. Fieschi et al. (Eds) Amsterdam: IOS Press 2004 IMIA.

All rights reserved

Integrating Detailed Clinical Models Into Application Development Tools

Stanley M. Huffa ,b, Roberto A. Rochaa, b, Joseph F. Coylea ,b, c, Scott P. Narusa, b
a

Department of Medical Informatics, University of Utah, Salt Lake City, Utah b Intermountain Health Care (IHC), Salt Lake City, Utah c 3M Health Information Systems, Salt Lake City, Utah models describe the structure of clinical data that might be stored in an EMR, sent in a standard data exchange message between two clinical information systems, or referenced in a decision support rule. One of the core purposes of a clinical information model is to guide how standard coded terminologies are to be used in the structure of the model. This topic has been discussed at length by Alan L. Rector [4]. For example, in a name-value pair paradigm using LOINC codes (Logical Observation Identifier Names and Codes) [5] and SNOMED codes (Systematized Nomenclature of Medicine) [6] as our standard coding schemes, a babys birth weight could be represented in at least two possible ways, as shown as an XML snippet in Figure 1. In the first example, a single molecular LOINC code is used to represent the meaning of the observation. In the second example, an atomic LOINC code is associated with a qualifier. The meaning of the qualifier is represented as a combination of a LOINC code and a SNOMED code. Pre-coordinated representation

Stanley M. Huff, Roberto A. Rocha, Joseph F. Coyle, Scott P. Narus

Abstract Several groups are currently working on defining detailed clinical models (also called templates or archetypes) that are refinements of abstract medical models like the HL7 (Health Level Seven) Reference Information Model. At IHC, we have created over 3,000 detailed clinical models in the last five years. These models have become an essential part of the architecture of our electronic medical record (EMR) system. As a result, we have created an increasingly sophisticated set of tools that allow the models to be searched, viewed, and ultimately incorporated into medical applications. These browsers have some commonality with terminology browsers, but are distinct in that the explicit structure of the information models must be accommodated. In this paper we report our experience in making browsers for detailed clinical models that are integrated with application authoring tools. Keywords: Information models, modeling tools

Introduction
At IHC we have implemented an electronic medical record system that contains a clinical data repository (CDR). The repository contains clinical information on 1.4 million people, and data is being added at the rate of about 200,000 results a day. The results can come from 50 different HL7 interfaces, hundreds of different structured data entry screens, the output of decision support rules, or other clinical applications. Dolin and his co-authors have discussed some of the complexities associated with executing queries when data is stored using different levels of pre and post coordination [1]. Our goal is to have the data in the CDR in a consistent coded representation regardless of the source of the information so that decision support queries will be simple and easy to maintain. It is a constant challenge to keep the data consistent because the information models and terminologies of the interfaced applications may be very different from the consistent model and terminology that we are trying to maintain in the CDR. An important and recurring topic within medical informatics is clinical information models. Alan Rector and his co-authors were among the first to discuss these types of medical models [2]. Stephen Johnson has also described the value of models in making clinical data understandable [3]. Clinical information

<observation> <cd>Weight at birth (LOINC 8339-4) </cd> <value>3500 gm</value> </observation> Post-coordinated (compositional) representation <observation> <cd>Weight (LOINC 3141-9) </cd> <qualifier> <cd>Weight circumstance (LOINC 8337-8) </cd> <value> Birth (SNOMED F-88005) </value> <qualifier> <value>3500 gm</value> </observation> Figure 1 - Two possible representations for an observation of an infants birth weight using LOINC and SNOMED codes are shown. Each representation has its particular advantages. The model used in the first (pre-coordinated) representation is intuitive for clinicians. It is easy to implement on a data entry screen and to

1058

SM. Huff et al.

reference in a decision rule, because it has fewer coded concepts. The model used in the second (post-coordinated) representation allows more clinical situations to be described as sensible combinations of codes, but it has a more complex structure. This model could be used to represent birth weight, prenatal weight, preoperative weight, etc. by simply changing the value of the weight circumstance code. Several groups are working together on the various aspects of these kinds of detailed clinical models. DICOM has used templates as a part of its imaging standard for many years [7]. Thomas Beale and Sam Heard have defined a syntax for defining archetypes [8] and are collaborating with the CEN general purpose information components (GPICs) initiative [9] and with the HL7 templates initiative [10] to define a formal syntax for representing these models. They are also defining a structure and process that will allow the creation of a repository of these models. IHC has been defining and using detailed clinical models as an essential component of our CDR that was co-developed with 3M Health Information Systems. In the last 5 years, IHC has defined over 3,000 detailed clinical models using ASN.1 (Abstract Syntax Notation One) as the formal definition language [11]. The detailed clinical models define the canonical form of data that we store in the CDR. As we have integrated detailed clinical models into our CDR processes, it has become increasingly important to have good tools to aid in viewing and using the models during the development of clinical applications. For example, the models are used to guide creation of structured data entry screens, clinical reports, and decision support rules. IHC has developed an increasingly sophisticated set of tools for searching, viewing, and incorporating detailed clinical models into clinical applications. Our tools are different from standard terminology, object model, and ontology browsers in several ways. Our tools deal with terminology in the context of an explicit structural information model. For example, there are different models for drug orders versus allergy records, but drugs participate in both models, and there are hundreds of unique models at this level of abstraction. Our browsers need to be able to find drugs in the context of any models in which they participate. Reference terminologies may include description logics, but they typically do not include an explicit metamodel of clinical data, and the browsers are typically looking for phrases or aggregate concepts, not models, that contain a particular word or a more primitive concept. Editors and browsers for UML (Unified Modeling Language) deal with complex models, but the models are not explicitly linked to coded terminologies. Also, the UML tools deal with a single possibly very complex model at a time, and are not generally built to search for a specific model in a library of thousands of complex models. Finally, ontology browsers explore the relationships between concepts in a particular field, but not the concepts as integrated with a structural data model, i.e., the boundaries and dependencies between the information model and the terminology concepts are not explicitly recognized. Ontologies are mostly agnostic as to how the information is stored or used in the patient database.[Rector]

In this article we would like to share our experience in integrating tools that browse detailed clinical models with application development tools.

Description Of Browsers
Simple Unix Tools: The ASN.1 models were initially authored using a simple text editor. All of the ASN.1 source files were placed in source code control in a particular directory, and the regular expression matching capabilities of grep were used to find models that contained a user specified combination of letters or words. While this is admittedly a primitive strategy, the power of regular expression matching is impressive, and finding a given object is very fast and flexible. For some low level tasks, using UNIX utilities to filter the ASN.1 source files is still the gold standard for determining if a given type of model exists. The ASN.1 source definition for Weight Observation is shown in Figure 2.
W eightObs ::= PatientObservation (W CS { obsId (RCodedTerm (W eightId)), decUObsVal (MassUnits), abnFlag (RCodedDomain (Num ericAbnorm al)), deltaFlag (RCodedDomain (NumericDelta)), refRange, status, reportFlag, comments (RComments (PatObsComment)) , obsMods (W ITH TYPES { NormalizedW eightObs % , W eightMeasureInstrumentObs % , W eightMeasurementTypeObs % , PatConditionObs % , PatTimingObs % , W eightMeasureMethodObs % , OccurredAtOrDuringEventObs % , PatPositionObs % }) })

Figure 2 - The ASN.1 definition for weight observation (WeightObs) with its associated concept identifier, units of measure, and allowed modifiers. The ASN.1 definition contains the following information. WeightObs is derived from the parent type of PatientObservation. It has an observation identifier (obsId) that is set to the coded value of WeightId, which is the internal IHC name for the LOINC code for patient weight (3141-9). The third line (starting with decUObsVal) is a cryptic way of saying that this weight observation will have a value that is a decimal number with units of measure that represent mass. The six items following the observation value definition represent the abnormal flag, the delta check flag, the reference range, the status, the reporting flag, and comments that can be associated with the observation. The final (obsMods) section of the definition lists ASN.1 types that can qualify the meaning of the observation. The allowed qualifiers are normalized weight, weight measurement instrument, weight measurement type, patient condition, patient timing, weight measurement method, when the weight was obtained relative to other patient events (admit weight, pre-op weight), and the patients position at the time of weighing.

1059

SM. Huff et al.

A1Browse: The first true browser that we created (A1Browse) reads compiled ASN.1 models and creates visual depictions of their contents. A1Browse searches for detailed clinical models by name. Once the object is located, its contents are displayed by double clicking the icon of the object and then by recursively double clicking on elements within each level of the model. When an element of interest is found, it can be selected and then automatically incorporated into C++ programs that can set and get values from instances of ASN.1 weight observations in the runtime environment. A view of the WeightObs object as it is displayed using A1Browse is shown in Figure 3.

compiled ASN.1 files. The relational tables are populated with the model content by a program that reads the compiled ASN.1 models and creates multiple rows in the relational database to represent the elements of the model. The capabilities of this browser are shown in Figures 4 and 5. In figure 4, the user has entered the keyword Weight in the search window, and then pressed Go. Using names and synonyms that exist in the HDD, the program searches a relational database of clinical models, and displays all models related to weight. If the user wants to see more of the internal structure of the model, s/he can select a model and then press the wrench and hammer icon that will cause the details of the model to be displayed. Once the user has selected the model of interest, they press the New button and the user moves to the next step in creating a data entry screen.

WeightObs

obsId

obsValue

obsM ods

abnFlag

PatTimingObs PatientConditionObs NormalizedWeightObs WeightMeasurementTypetObs WeightMeasurementMethodObs WeightMeasurementInstrumentObs

Figure 3 - The A1Browse display of the WeightObs model. Browsing HTML Representations: The next mechanism that we developed for viewing the detailed clinical models uses any standard HTML browser. A program (fmttype) was written that reads the compiled ASN.1 models and renders them as HTML with embedded links between the objects. The HTML looks just like the ASN.1 source shown in Figure 2 except that it has embedded hypertext links. The HTML representation of the model is very good for drill down and for general understanding of the content, but it results in large files, and it is easy to lose context as you traverse from object to object. The ChartNotes Wizard: The fourth browser we created is fully integrated with an application development wizard. The ChartNotes Wizard is an application that can be used by nonprogrammers to develop structured data entry screens. The user selects a model from a database of models and the object appears in a work area with the same appearance that it will have in the runtime environment. The user can then move the object using drag-and-drop capabilities, and other behaviors and visual attributes of the object can be set. This browser is more sophisticated in supporting user searches. Each ASN.1 object is represented as a concept in our Healthcare Data Dictionary (HDD), which means that it can have multiple names and synonyms, and the object can be retrieved by any of its names. Standard substring searches are also supported. In order to achieve fast performance, this browser reads the models from a relational database rather than reading the models from either source or Figure 4 - The initial search screen in the Chart Notes Wizard. The user entered the key word Weight and all detailed clinical models that matched that keyword have been displayed. Figure 5 shows how the screen builder uses the information from the detailed clinical model to generate a data entry form or profile. The left side of the screen shows the internal structure of the clinical model that was previously selected. Items that are checked are required elements. The user selects parts of the model that s/he wishes to have as part of the data entry screen and presses the Add to Template Button which causes the element to be added to the palette on the right side of the screen. The right side of the screen represents how the data entry screen will look during runtime execution. Objects on the right side of the screen can be dragged-and-dropped to the correct location. Other capabilities of the Chart Noteswizard allow the visual and behavioral

1060

SM. Huff et al.

Figure 5 - The user selects elements from the clinical model on the left hand side to add to the data entry template on the pallet on the right. Items that are checked are mandatory attributes (colors, fonts, list box versus picklist, etc.) of the data element to be set or modified. For coded fields, the browser accesses the data dictionary dynamically to show the user the allowed values for the field. A Dynamic Web Browser (ASN1 Search) The final browser that we have created is a web based dynamic viewer that we named Asn1Tool. It is shown in Figure 6. This browser supports lookup by the numeric concept identifier (NCID) of the model, the ASN.1 name of the model (the concept identifier name, or CID), or by any word or words that exist as synonym(s) for the model in the HDD. It reads the models from the same set of relational tables that are used by the Chart Notes editor. Clicking on a particular model causes sub-elements of the model to be displayed. As with A1Browse, recursively clicking on sub-elements within the model will in turn cause display of their substructures. Consistent with the behavior of the ChartNotes Wizard, Asn1Tool also accesses the HDD in real time in order to show the possible values for coded elements within the model. ible search capabilities, the ability to write Unix scripts for simple maintenance tasks, and the syntax checking that is provided in the Unix editor. Detailed clinical models have been invaluable in keeping data consistent in our CDR. The models guide users who are creating computer-to-computer interfaces, data entry screens, clinical reports, and decision support modules. Maintaining the formal models is time consuming, but it is our impression that it is less work to maintain the models than to deal with data inconsistencies. Without a formal model, developers forget how a given type of data is stored and they create a second (or third) storage form. These database inconsistencies ultimately lead to incomplete data retrieval, missing data in clinical reports, or errors in the execution of decision logic. Searching the database to discover and correct inconsistent data is very resource intensive and time consuming. We are in the process of migrating our ASN.1 models to XML Schema. Our goal is to use open source or commercial tools whenever possible. Besides the browsing and application development use cases we noted above, we are also investigating commercial tools for authoring the detailed clinical models, and native XML databases to store our XML models. Our early experience indicates that we can represent all of our existing ASN.1 structures in XML. However, some things were much easier to represent in ASN.1 and XML Schema is much more verbose than ASN.1, so we are using a locally developed XML shorthand to represent our new models. When needed, the XML

Discussion
The different browsers were developed over the period of a few years. All of the tools are still in use except for A1Browse, which was replaced by the Chart Notes Wizard. The Chart Notes Wizard is used the most because it has a convenient graphical user interface and it is integrated into the application development process. The Unix tools are used primarily for updating and adding new ASN.1 definitions. They remain useful because of flex-

1061

SM. Huff et al.

Figure 6 - A web browser of the detailed clinical models. The user enters a keyword and matching models are displayed shorthand expressions can be transformed into XML Schema. We are realizing some of the benefits of moving to XML. For example, a simple style sheet renders our XML shorthand easy to read and understand. Acknowledgements
We would like to thank Wei Jiang, Harold R. Solbrig, and Steve P. Schrank for their intellectual and technical contribution to these tools.

[9] CEN/TC 251/N03-21 prEN 14822. Health Informatics General purpose information components Parts 1-3. 2003. [10]Health Level Seven (HL7). HL7 Version 3 Templates, Release 1.5 (Memphis Draft, August 28, 2003). Health Level Seven, Ann Arbor Michigan. 2003. [11]S.M. Huff, R.A. Rocha, H.R. Solbrig, M.W. Barnes, S.P. Schrank, M. Smith. Linking a medical vocabulary to a clinical data model using Abstract Syntax Notation 1. Methods Inf. Med. 1998: 37 (4-5): 440-52. Address for correspondence
stan.huff@ihc.com

References
[1] Dolin RH, Spackman KA, Markwell D. Selective Retrieval of Pre- and Post-coordinated SNOMED Concepts. Proc AMIA Annu Fall Symp. 2002: 210-14. [2] Rector AL, Nowlan WA, Kay S, Goble CA, Howkins TJ. A Framework for Modelling the Electronic Medical Record. Methods of Information in Medicine 1993: 32 (2): 109-19. [3] Johnson SB, Generic Data Modeling for Clinical Repositories. J. Am. Med. Inform. Assoc. 1996: 3 (5): 328-39. [4] Rector AL. The Interface between Information, Terminology, and Inference Models. MEDINFO 2001. 2001: 246-50. [5] Huff SM, Rocha RA, McDonald CJ, et al.: Development of the Logical Observation Identifier Names and Codes (LOINC) vocabulary. J Am Med Inform Assoc. 1998: 5 (3): 276-92. [6] Spackman KA, Campbell KE, Cote RA: SNOMED RT: A reference terminology for health care. Proc AMIA Annu Fall Symp. 1997: 640-4. [7] Bidgood WD. Documenting the Information Content of Images. Proc AMIA Annu Fall Symp. 1997: 424-28. [8] Beale T, Heard S. Archetype Definition Language. 2003: http://www.OceanInformatics.biz.

1062