113 Comparing Different Approaches to Two-Level Modelling of Electronic Health Records Line Michelsen, Signe S. Pedersen, Helene B. Tilma, Stig K. Andersen Abstract Department of Health Science and Technology Aalborg University, Denmark Electronic Health Record (EHR) systems are being developed to improve the communication of patient data. The health care domain includes many different types of data and concepts, of which some are constantly changing, and some are more lasting. This makes the development of an EHR a complex task. In order to improve the handling of this complexity, a new two-level modelling approach in EHR system development has emerged, using a concept of archetypes as the pivot in the representation of the health care knowledge. The key issue in this approach involves dividing the problem field into two separate models: A generic information model and a domain knowledge model. By analysis of how this layering has been carried out in two different two-level EHR systems the OpenEHR (formerly the Australian GEHR, Good Electronic Health Record) and the EHR project of Aarhus County, Denmark. We have identified critical meta model parameters influencing the ability of the modelling paradigm to meet the expectation for easy handling of the development process (flexibility) and the capability to manage changing models (dynamics). The OpenEHR has defined the division line in such a way that it makes the generic model small and the domain model large. The opposite is the case of the Aarhus EHR system, where the information model is large, and the knowledge model is small. A small information model and a large knowledge model make more of the system changeable, but it also makes it less flexible to develop. The opposite is the case for a large information model and a small knowledge model. Keywords: Electronic Health Record (EHR); Two-Level Modelling; Archetype; EDD (Event Description Definition); Information Model; Domain Model; Generic Model, Meta Model 1. Introduction An essential motive for implementing Electronic Health Records (EHR) is the desire to utilize the opportunities of information technology to support the work and development taking place within the health care sector. The fundamental reason for implementing an EHR is to improve the possibilities of providing better, coordinated care, and to create better documentation of the events as well as the composition and the quality of health care contributions. There are many things to be considered when developing an EHR system. First of all, the EHR system must be designed for several types of users and hospital departments. The EHR system must therefore be flexible to fulfil the demands of the different users and departments and to cover a wide range of clinical domains. Secondly, the clinical domain is constantly encompassing new knowledge and improved technology. The process of modifying an EHR system should be flexible and dynamic.
114 The classical single-level model approach to develop an information system is to model domain concepts directly in software and database models. It is difficult to fulfil the demands of a flexible and dynamic EHR system with this single-level approach, as it uses one comprehensive information model. The single-level approach system can be seen as a snapshot of knowledge existing at the time the EHR system was developed. [1, 2] A new approach has emerged in EHR development where the idea is to divide the problem field into two separate models: An information model and a knowledge model [2]. This approach is often called two-level modelling. The information model depicts stabile and generic concepts, whereas the knowledge model expresses the variability and dynamics of the problem field. Terms like archetypes [2], event description definitions (EDD) [3], clinical templates [4], and clinical document architectures (CDA) [5] are used to describe concepts representing selfcontained parts of domain knowledge, acting as building blocks in the knowledge model. The purpose of the two-level model approach is to make it possible to change or extend the knowledge model without changing the basic functions of the system, as they are to remain static within the information model. The generic information concepts are steady in time, while the domain knowledge specific concepts express variability [1, 2]. The implementation of the dynamic aspect of the modelling process has to be sufficiently flexible to make it attractive in practice. In this paper we have chosen to analyze how the division between the model layers has been carried out, and what the consequences are in two different EHR systems using the two-level approach: the OpenEHR [2] and the EHR project in Aarhus County, Denmark [3]. In these two examples we have identified critical meta model parameters which affect the ability of the modelling paradigm to meet the expectations for (1) easy handling of the development process (flexibility) and (2) the capability to manage changing models (dynamics). 2. Methods Information about theories and principles of two-level modelling and the two EHR approaches is obtained from literature and websites of OpenEHR and Aarhus County, Denmark, and through semi-structured qualitative interviews and questionnaires. The analysis is a comparative study of the two EHR approaches, concentrating on their ontology structure and the division between the model layers. Moreover focus is chosen to be on three specific aspects: Version control, legislative requirements, and domain knowledge acquisition. Other aspects as economic circumstances, data security, structured querying, patient interaction, and use of terminologies are not treated in this analysis. 3. Two-Level Modelling and Archetypes In the OpenEHR approach the term archetype is used, while the corresponding concept in the Aarhus EHR approach uses the term EDD. In the following description of two-level modelling and archetypes, the term archetype is used as a general concept covering both the term archetype used in the OpenEHR approach and the term EDD used in the Aarhus EHR approach. The essential concept in two-level modelling encompasses the separation of information and knowledge, where all clinical information is created in the image of appropriate knowledge structures [6].
115 The information model includes software object models and database schemas, while the knowledge model contains the domain specific concepts, consisting of terminologies and ontologies. Archetypes are used to express self-contained domain knowledge chunks, which are expressed by the terms of a constrained information model. The advantage of separating knowledge from information is the possibility to make domain experts model the knowledge model using archetypes and make technical developers model the information model. Figure 1-The concept of archetype modelling. Modified from [8, 9]. An archetype is a constraint model that defines interpretation restrictions for EHR information, for instance information about the composition of blood pressure measurement expressed in information model terms. The purpose of archetypes is to ensure that only data with a certain structure can be added to the EHR. As the archetype is developed from the underlying information model, the ability to add new archetypes over time is present without having to remodel the whole information model [7]. Archetypes are used to drive the runtime features of software in the information model, entailing that the data shown to the user is a combination of the data in the information model and the restrictions prescribed by the archetypes. This principle is illustrated in Figure 1. On the knowledge side to the right, the knowledge model is illustrated. This knowledge model constrains its underlying information model. Archetypes are instances of this model [8]. The actual information obtains its structure from the information model via the archetype. The knowledge model provides a sensible health domain information structure of the elements in the information model [2], shown on the left. The archetype assures that data acquisition is processed in accordance with the information model, so that data can be stored in databases. 4. Results The OpenEHR and Aarhus EHR Approach Ontology levels: In order to classify the clinical domain knowledge, the OpenEHR approach makes use of six different ontology levels to structure its information model. The ontology levels are used to find classes in the information model and to classify and compose archetypes. The six ontology levels are labelled: principles, descriptive, organizing, unit of
116 work, historical, and communication [6]. Archetype is the crucial class in the information model from where the classes connected to the ontology levels inherit. This is illustrated in Figure 2. Figure 2 (a) The illustration shows the archetype class connected to all six ontology levels. (b) The illustration shows the EDD class connected to only three ontology levels. To compare the two models we have arranged the model of the Aarhus EHR in accordance with the equivalent six ontology levels used in the OpenEHR. The result of the comparison is shown in Figure 2. The EDDs are not related to all six ontology levels, but only the first three levels of abstraction. In the Aarhus EHR information model, the fundamental class is the Event class [3] (not shown in Figure 2). Consequently, archetypes can represent a wider range of levels of abstractions than EDDs. General structures: The OpenEHR approach is built completely as a two-level model, whereas the Aarhus EHR approach is built both as a two-level and a single-level model. The information model of the Aarhus EHR contains three main models: A process model, a logistic model, and a registration model [3]. The process model contains the classes shown in Figure 2 and is built according to the two-level modelling principles. The logistic and registration models are both single-level models. Figure 3 compares the general structure of the OpenEHR and the Aarhus EHR models. Domain knowledge acquisition: In the Aarhus EHR and the OpenEHR, maintenance of the EHR systems is managed in different ways. The Aarhus EHR has a specific organization developing EDDs. This is a technical organization co-operating with the domain experts in creating the EDDs [10]. No EDD editor is available for the clinicians. In the OpenEHR an archetype editor is to be used by clinicians and developers [11]. The archetype editor is a modelling tool for creating and editing archetypes in accordance with the information model [12]. Legislative requirements: In the Aarhus EHR the development of EDDs is influenced by legislation about national reporting requirements and clinical databases. For this reason, to make the automatic reports, the structure of some EDDs must be stable and follow the requirements established by legislation [13]. The OpenEHR must follow the same legislation about national reports, but archetypes have not yet been modelled for report use. With regard to this, an advantage in the OpenEHR might be that archetypes can be made up of smaller archetypes and can be reused in one large archetype corresponding to a report [12]. Version control: The advantages of EDDs and archetypes are that they can be modified,
117 which implies change management and version control. An EDD or an archetype may be changed due to omissions, legislation, technology, or traceability. The last point is due to the requirement that it must be possible to return to any previous version of the record [2, 6]. In the OpenEHR each archetype has its own version with version control provided by the information model. In the Aarhus EHR the single EDD is not version controlled, but the whole collection of EDDs is version controlled. In both EHR projects there are more dimensions of version control than indicated above. The information models, the archetypes/edds, and the terminologies are all to be version controlled independently. What makes the task complex is that these three aspects depend on each other. Figure 3-The OpenEHR model is built completely as a two-level model, while the Aarhus EHR model also contains single-level models. 5. Discussion and conclusion The OpenEHR and the Aarhus EHR have defined the dividing line between the information model and the knowledge model differently. The dynamic part of the Aarhus EHR covers fewer modelling aspects than the OpenEHR approach, leaving fewer clinical concepts to be modifiable. Consequently the OpenEHR seems to be more future-proofed with regard to the amount of knowledge structure that can be changed, although it may be irrational to model persistent concepts such as professional groups, departments etc. In the Aarhus EHR, EDDs are developed by one separate technical group in co-operation with clinicians. In the OpenEHR, the archetypes are to be developed by domain experts using an archetype editor. Archetypes may require a lot of insight into the information model in order to be able to model them. Modelling EDDs also requires domain knowledge and insight into the domain knowledge, and this might challenge the technical group of the Aarhus EHR. Version control is performed on each archetype in the OpenEHR and on the complete knowledge model in the Aarhus EHR. It is therefore difficult to compare how archetypes and EDDs are version controlled. Version control is a non-trivial task in both cases. The essential problem in version control is granularity. Version control of archetypes might be more complex than version control of EDDs, due to the fact that archetypes have more structures. The Aarhus EHR is performing version control on the complete model. By using this solution the basic properties of the EDD, which are reducing redundancy, providing reusability, and being replaceable, are not obtained.
118 Due to external circumstances, the dynamics of the Aarhus EHR system is restricted. Conditions concerning legislation about national reporting mean that some EDDs have to be structured in a certain way to comply with the reporting rules. In the OpenEHR the same legislation exists, but there is no practical experience with archetypes and national reports. Based on the analysis, our hypothesis is that the division between the model layers influences the flexibility and dynamics of the EHR systems. A small information model and a large knowledge model make more of the system changeable, but also make development less flexible. The opposite is the case for a large information model and a small knowledge model. There are no fully implemented and evaluated EHR systems using the two-level approach. Therefore experiences regarding this hypothesis are sparse. The hypothesis can be utilized to analyze the flexibility and dynamics of other EHR projects using two-level modelling. HL7v3 and CEN ENV 13606 are both EHR projects using the two-level approach [4, 5]. In the CEN ENV 13606 pre-standard for EHR a generic model for the EHR architecture has been constructed, together with archetype-like templates. In HL7 a knowledge model has been developed with the purpose of representing semantics and relations between concepts for all data in a HL7-message. 6. Acknowledgements We thank Mona Holm from the Virtual Hospital in Aarhus County, Trine Joergensen from Systematic Software Engineering A/S, and Inge Madsen from Skejby Hospital, Aarhus, for answering questions about the Aarhus EHR project. We also thank Thomas Beale and Sam Heard from Ocean Informatics for answering questions about the OpenEHR project. 7. References [1] Andersen SK, Nøhr C, Vingtoft S, Bernstein K, Bruun-Rasmussen M. EPJ-Observatoriet : statusrapport 2002. Aalborg Universitet; Center for Sundheds-telematik; MEDIQ. 2002. [2] Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. Deep Thought Informatics. 2002. URL: www.deepthought.com.au/it/archetypes/archetypes_new.pdf, accessed December 2004. [3] The County of Aarhus. Domaene Objektmodel. 2000. URL: www.aaa.dk/aaa/dom_2.pdf, accessed December 2004. [4] CEN/TC251 European Standardization of Health Informatics. URL: www.centc251.org, accessed December 2004. [5] Health Level Seven. URL: www.hl7.org, accessed December 2004. [6] Beale T, Goodchild A, Heard S. Design Principles for the EHR. Rev. 2.4. The OpenEHR Foundation. 2004. [7] Bird L, Goodchild A, Tun Z. Experiences with a Two-Level Modelling Approach to Electronic Health Records. Journal of Research and Practice in Information Technology, 35(2), 121-138. 2003. [8] Beale T. OpenEHR Modelling and Design Principles. Rev. 0.3. The OpenEHR Foundation. 2003. [9] Beale T, Heard S. Archetype definitions and principles. Rev. 0.5. The OpenEHR Foundation. 2003. [10] Interview with M. Holm. September 2004. [11] DSTC Titanium. Clinical Model Builder Software. 2002. URL: titanium.dstc.edu.au/gehr/clinical-modelbuilder, accessed December 2004. [12] Mail Correspondence with T. Beale. December 2004. [13] Private Communication with T. Joergensen. November 2004. Address for correspondence Assoc. Prof. Stig Kjær Andersen, Ph.D., Virtuel Center for Health Informatics (V-CHI), Department for Health Science and Technology, Aalborg University, Fr Bajersvej 7 D, DK-9220 Aalborg, ska@hst.aau.dk