Detailed clinical models: a review.

OBJECTIVES: Due to the increasing use of electronic patient records and other health care information technology, we see an increase in requests to utilize these data. A highly level of standardization is required during the gathering of these data in the clinical context in order to use it for analyses. Detailed Clinical Models (DCM) have been created toward this purpose and several initiatives have been implemented in various parts of the world to create standardized models. This paper presents a review of DCM.
METHODS: Two types of analyses are presented; one comparing DCM against health care information architectures and a second bottom up approach from concept analysis to representation. In addition core parts of the draft ISO standard 13972 on DCM are used such as clinician involvement, data element specification, modeling, meta information, and repository and governance.
RESULTS: SIX INITIATIVES WERE SELECTED: Intermountain Healthcare, 13606/OpenEHR Archetypes, Clinical Templates, Clinical Contents Models, Health Level 7 templates, and Dutch Detailed Clinical Models. Each model selected was reviewed for their overall development, involvement of clinicians, use of data types, code bindings, expressing semantics, modeling, meta information, use of repository and governance.
CONCLUSIONS: Using both a top down and bottom up approach to comparison reveals many commonalties and differences between initiatives. Important differences include the use of or lack of a reference model and expressiveness of models. Applying clinical data element standards facilitates the use of conceptual DCM models in different technical representations.

I. Introduction

In the past 10 years different developments took place to specify data elements for clinical use and their re-use in health care information technology (HIT) to address a multitude of purposes. Clinicians, researchers, managers, institutions for quality control, regulatory agencies, health statistics developers, among others, have an increasing interest in data element standards for clinical data [1-4]. Of particular interest are the relationships among data elements that represent clinical concepts. In addition, standards organizationson national and international levels have an interest in this work because only standardized data element will reveal the full potential [5-8].

We see many synonyms used for clinical modeling, such as clinical elements [1], templates [9,10], care information models [11], clinical content models [12], clinical templates [9], archetypes [9,13], clinical fragments [9], general purpose information components, detailed clinical models (DCM) [1,2,4], and more. Each of these usually comes from a project or initiative that aims at one or more of the following goals:

1) Analyzing, sorting, formalizing, structuring and standardizing data elements for clinical use.

2) Conceptual modeling of data elements, structures and relationships for clinical use, independently of their technical implementation.

3) Deploying such data elements standards in different technical representations, e.g., for use in Electronic Health Records (EHR), data warehouses (DWH), and electronic message (e.g., Health Level [HL] 7).

4) To ensure quality control of DCMfor clinical purpose, based on clinical needs and involvement, governance and applying measures for patient safety.

There are many commonalties in the different developments around the world, however some differences as well. The purpose of this article is to give a brief overview of existing developments and discuss their differences and commonalties. We will use the word DCM for these initiatives in the remainder of this text.

1. Background of DCM

Goossen discussed developments around DCMand outlined what can be part of standards work on DCM [1]. A brief summary is given below as background for this review. Two level object modeling has been introduced in recent health care information technology. In particular HL7 version 3 and CEN/ISO EN13606 use this approach [10,13]. Two level modeling is largely based on the work by Rector et al. [14], Johnson [15], and Beale [16]. Rector et al. [14] where among the first that modeled the electronic patient record via separating out the clinical observation models and the meta-information about the clinical observation models. Johnson [15] argues that the traditional modeling approaches of clinical data lead to complex models consisting of hundreds of entities. Also, Johnson [15] states that such complex models in addition represent a rich set of constraints about the patient care domain which is inefficient in electronic patient records. Therefore, Johnson [15] transformed these complex models and constraints into a generic model resulting in a small database of a dozen tables which is efficient for patient-oriented queries. Further, Johnson's approach is highly flexible in adapting to the changing information needs of health care [15]. With respect to DCM, it is relevant that Johnson found that changes involving the collection of new data elements where accommodated via this generic model.

Beale [16,17] describes how archetypes, as small constraint models of domain concepts, can be deployed in the electronic patient record environment and significantly improve interoperability, software economics and quality of care. The core approach with archetypes is this two level modeling in which a reference model guides system development and archetypes define clinical content. This two level modelingapproach is used in the ISO/CEN EN13606 series [13] and OpenEHR [18]. It is also used in HL7 v3 Clinical Document Architecture and Care Provision messages [10].

Functions of EHR, DWH, and electronic messages hence can be developed in such a way that they become almost independent of the specific data elements, but still allow data management upon them [1]. Clinical data elements are elicited from clinicians, researchers, evidence base materials and are modeled in the form of clinical statements (HL7) or archetypes (EN 13606) [10,13]. Such clinical statements or archetypes can be standardized and deployed in the technology of choice of clinicians. This facilitates a flexible development of EHRs and messaging and allows using and reusing collections of clinical models. However, although this approach has many similarities, and often is handling equivalent clinical content, most of these approaches are not, or difficult, mutually exchangeable. In addition, relationships between data elements and linkage to terminologies are crucial [11,19].

DCM organize health information via combining knowledge, data element specification, relationships between data elements, and terminology into information models that allow deployment in different technical formats [1,2,4,7]. This is in particular the case when IT is build upon different standards such as ER diagrams, HL7 Reference Information Model [10] or ISO/CEN EN13606 [13]. The term DCM originates from Huff et al. [1] of Intermountain Healthcare (IMH), USA. According to Huff et al. [1], DCMdescribe the structure of clinical data that are stored and managed in electronic patient records, send between clinical systems, and referenced in decision support rules. A DCM is a relatively small, standalone information model designed to express a clinical concept in a standardized and reusable manner [7]. It documents clinical information as a discrete set of precise clinical knowledge for that concept [7]. Structurally a DCM provides the data elements and attributes of a clinical concept, including the possible values and types of attributes, and relationships needed to convey the clinical reality in a fashion that is understandable to both clinical domain experts and modelers [7].

In a modern, model driven application development, the position of DCM needs to be visible in the overall health care enterprise, in the system development cycle and in the various domains of interest. We will use Blobel's Generic Components Model (GCM) for health information architectures as framework [20]. This model has been introduced to the ISO 13972 team creating the DCM standard and it achieved great support because it does clarify the relationship of DCM to many external architectural issues. Hence, the position of DCM in HIT architecture will be part of the methodology to review DCM.

In summary, we will briefly describe existing initiatives for DCM creation and maintenance, will review these according to content of DCM formats, and place these initiatives in model based architecture for health care information technology.

II. Methods

1. Selection of Examples

This paper is not a systematic review, since the work on DCM is still in an early stage and not all initiatives and work hasbeen included in the scientific literature yet. Hence, we will review existing initiatives, in particular of countries and/or projects that participate in the work on the ISO standard for DCM [7]. Another criterion used is that actual modeling, e.g.,of relationships between data elements needs to be part of initiatives selected.

Six examples are chosen to illustrate commonalties and differences. This must be seen as a convenience sample. The following six projects are included in the review:

1) IMH, clinical elements from Intermountain Healthcare as part of DCM [1]

2) 13606 Archetypes [13,16] (ISO/CEN EN13606/Open-EHR, Australia, National Health Service [NHS] England, Sweden)

3) CTS, Clinical Templates Scotland [9]

4) CCM, Clinical Contents Models [12]

5) HL7, Health Level 7 templates [10] (HL7, US, UK, Netherlands), and

6) DCM, Detailed Clinical Model instances [4,11] (Netherlands, ISO, HL7).

Other work is ongoing e.g., by the Clinical Data Interchange Standards Consortium (CDISC) [5], Tolven Healthcare Innovations [8], National Cancer institute Common Data Elements Dictionary for research data [21], Shafarman and Gilliam for Canada [22], etc. We assume that there will be other efforts underway, but cannot take all in consideration here. NCI only addresses single data elements, where clinical models address more, Shafarman and Gilliam plea for similar developments in Canada, but have no actual format or examples at this stage. Hence, at this stage, the work presented here cannot have all characteristics of a systematic review.

1) Example 1: Intermountain Healthcare

Huff et al. [1] discuss the development of DCM. DCM concern a collection of information models for precise clinical concepts and its data specification and relationshipsin a way that allows consistent use throughout the whole health care enterprise consisting of many locations and applications. Huff et al. [1] argue that the systems user interface, the storage of data in the EHR, recollection of data, data use in decision support applications, data exchange via HL7 messages and data use in records are all based on one and the same DCM specification.

Parker et al. [2] describe the use of DCM in the SAGE project for clinical guideline representation and exchange. They argue that common DCM give precise semantics and make the task of mapping between models manageable. They have applied HL7 RIM artifacts, in particular the observation class and attributes to specify guideline content. Parker et al. [2] envision a standard for DCM bringing us closer to semantic interoperability.

According to Huff [23], the need for the clinical models is dictated by what we want to accomplish as providers of health care. The best clinical care requires the use of computerized clinical decision support and automated data analysis. Clinical decision support and automated data analysis can only function against standard structured coded data. Therefore, DCM provides the standard data structure and terminology needed for clinical decision support and automated data analysis.

2) Example 2: 13606/OpenEHR Archetypes (13606)

Since the development and approval of the ISO/CEN EN13606 standard [13], work has been carried out to create archetypes. Archetypes are both 'computable definitions of single, discrete clinical concepts' and 'computable expressions of a domain content model in the form of structured constraint statements, and are based on a reference model' [13,16,17]. These definitions are described in the same single artifact, that allows operations in compliant EHR systems [18]. Each archetype is designed to be inclusive of all attributes about a given concept for all possible use cases - a maximal data set for a universal use case, with minimal, universally applicable constraints [18]. The openEHR Clinical Knowledge Manager is an online resource to develop and store archetypes and on which a formal content review process can be initiated on each archetype and once consensus is reachedon the clinical content and design, the archetype can be published [18].

Differences between the 13606 and OpenEHR Archetypes exist, they are preliminary based on the fact that EN13606 is now a few years old and stable, and OpenEHR has moved further based on experiences in projects. However, an EN13606 consortium is working on implementations of the 13606 archetypes. In this review, the differences are not explicitly mentioned, because they do not affect the content.

3) Example 3: Clinical Templates project of the Scottish NHS

The Scottish NHS started a clinical template project to achieve consistency and predictability across health care data and health system processes, and to save effort through reuse, and raising quality [9]. The project developed context-specific domain models as the basis for standard components for clinical information systems. Core part of the project included the on-line collaboration for working groups, and reuse of materials. Hoy et al. [9] identified the drivers for clinicians to participate in this project: these include evidence base, limited time, text to EHR conversion, reuse of vendor content, and retrievable material among others. With respect to clinical content, Hoy et al. [9], come up with an approach in which the Clinical Templates are treated as combinatorial representations of smaller clinical domain models or fragments that can be reused across different domains and therefore need to be standardized. They work from a subset in a domain to the details and are available on www.clinicaltemplates.org.

4) Example 4: South Korean Clinical Contents Model project

The Center for Interoperable EHR (CiEHR) in South Korea develops core technologies necessary to implement lifetime EHR (http://ehrkorea.org:8082/detail/plan.aspx) [12]. Part of the work of CiEHR is developing CCM to support semantic interoperability and reusability of EHR data [12]. The CCM project promotes patientdata entry in convenient and accurate way, composes clinical data logically, and supports Clinical Decision Support (CDS), clinical studies and clinical document templates [7]. CCM have been developed as domain specific models, which domains are clinical finding, medication, laboratory etc.The developed CCM reflect current medical information standards such as terminologies, UCUM and HL7 V3 data types [12]. Presently, DCM evaluation metrics to measure CCM's quality is developed and used [24]. On the website (www.clinicalcontentsmodel.org) the current, over 2000 results,are distributed and feedback is gathered, in order to improve and adjust the Clinical Contents Models.

5) Example 5: HL7 templates in CDA and messages

In the HL 7 community there is a promise to create reusable message fragments, so called templates. In the HL7 v3 standard there exist several of such artifacts, such as common message element types or CMETs. However, at even smaller level,templates are extensible markup language (XML) representations of message sections, e.g., to express a date. Templates in HL7 can be used for any data, however the focus for this review is on HL7 templates that contain clinical content only. The most generic pattern in HL7 v3 is the clinical statement pattern,which allows clinical content to be specified in other HL7 artifacts such as refined message information models and indeed the HL7 templates (HL7, 2010).

This generic message component has been applied in different projects, such as CDA based implementation guides the NHS template project, the Care Provision referral and record exchange message and others. This revealed that in most clinical domains, a basic set of clinical statements could be used and reused, such as body length, blood pressure and assessment scales.

6) Example 6: Dutch Care Information Models / DCM

Van der Kooij et al. [11] evaluated a series of instances of Care Information Models (www.zorginformatiemodel.nl) from projects carried out by the Dutch National ICT Institute for Health Care (Nictiz). This evaluation revealedcurrent quality criteria for DCM. Items include version management, aim of clinical concept for target populations, evidence base, appropriate application of the concept, interpretation of results, copyright issues, among others [11]. Bel [25] uses these care information models in a HL7 v3 template expression for the development of an EHR. In this EHR, the database is configured against the HL7 reference information model. This EHR allows DCM to be integrated, speeding up development, querying and definition of user interfaces.

The initial Care Information Models where expressed in HL7 v3 format. However, the use of that leads to combinatorial explosions in the message development. For each instance a new message schema was necessary. Hence, work started to move to the current conceptual model approach of DCM, which is neutral with respect to the technical representation, and covers only the basics of the logical models.

Currently, the Parelsnoer initiative in the Netherlands uses a UML constraint DCM approach for getting access to research data and define the core content for EHRs [26]. Asmall set of frequently used DCM expressions in Unified Modeling Language have been created [26]. In addition, these are represented in HL7 v3 template via mappingthe DCM concepts and data elements to the HL7 v3 Clinical Statement Pattern. Also, these examples are modeled into an archetype using an archetype editor. Currently the format of this work has informed the ISO 21090 draft standard work [7], pending approval of the particular content in future voting.

2. Method for Reviewing

The review is based on the approach taken by the Netherlands Normalization Institute (NEN) expert mirror panel [26,27]. Comparisons between the HL7 templates approach and the 13606 archetypes object model (AOM) exist and mostly cover a top down approach, i.e., the start is on an architectural level and compares the reference information models used [28,29]. Blobel [20,28] for instance, discusses architectural components against which the different standards can be compared. Bointner and Duftschmid [29] compare the template and AOM models and find several differences between them. For example, there are differences e.g. ininheritance of characteristics, definition of semantics of reference model instances rendering them incompatible at this level [29]. These discussions are consistent with earlier debate in the HL7 and CEN standards organizations themselves. This type of analysis is the result of architectural design or object modeling using a top down approach that is based on the whole standard, and starts with the Reference Information Model downwards.

In order to review DCM initiatives appropriately, it is important to place them in a relevant architecture for health care information. Blobel [20] gives us a useful framework. He describes how different approaches towards creation and maintenance of HIT can be integrated through a GCM based architecture-centric, model-driven, and formalized process. Blobel [20] argues that all aspects of the design and development process of personalizedhealth care have to be considered from an architectural viewpoint in order to fit the multitude of drivers seamlessly together. Hence, domain-specific, organizational, and technical paradigms, requirements and solutions for care can be developed. Blobel [20] emphasizes the formal aspects of modeling and implementing eHealth and personal health interoperability and focuses on the multidisciplinary integration. He argues that this way exploiting all interoperability levels up to service interoperability becomes possible. Further, in the context of this approach, a special focus is put on ontology's and knowledge representation in the different domains. Blobel suggests that the English NHS Logical Record Architecture [30] is currently the only project that shows similarities to his ontological and architectural model driven approach. Other architectural frameworks of relevance include the HL7 Domain Analysis Models, Architecture of the EHR [31], and Reference and Functional Models for Electronic Health Record Systems [13,32].

For clinical modeling however, the starting point is the clinical relevant concept that clinicians use and work with in diagnosing conditions and setting treatment plans and carrying them out [19]. Also, mostly these concepts are represented in the scientific literature and/or in clinical practice documentation, records and guidelines. When a bottom up approach is taken based on the conceptual model level, the comparability of different approaches to clinical modeling can be improved significantly [26]. This however, requires a bottom up approach on the conceptual level. Examples of this approach to comparison are presented by Cuggia et al. [33]. They compare the Apgar score representations in HL7 v3 and OpenEHR Archetype. They find some differences, but mostly commonalties,in fact the clinical material at concept level is modeled equivalently [33]. White and Hauan [19] explain how careful a modeler must be to not change the exact wording or relationships of data elements and/or value sets when these represent assessment scales or scoring systems. Precision is required in clinical modeling and coding. The NEN serves as the CEN/ISO mirror panel for health informatics standards. In the mirror panel the two approaches HL7 v3 and 13606 have been part of ongoing debate for many years [27]. Based on the concept oriented bottom up approach we were able to further disentangle the clinical concept modeling from the technical modeling and to identify adequate levels of equivalence [27]. This conceptual model analysis allows comparing data element by data element based on reviewing medical knowledge on the specific topic. The underlying assumption here is that for interoperability, data elements must be equivalent in order to ensure safe patient care. The concepts represented by the data elements and their relationships should remain the same despite the applied logical modeling approach and despite their technical implementation.

In other words: if a patient has diabetes type II as disease, a receiver of information should not see femur fracture in the problem list. Or, if a Barthel Index isassessed, or a blood pressure is measured, then the results of such observations must be exchanged without loss of meaning, leading to appropriate clinical decisions by the professional receiving such electronically exchanged information.

Hence, an approach that comes from the bottom up conceptual level modeling, justifiesthe clinical domains. Instead of "pressing" all clinical materials into a reference information model, the concepts are analyzed as phenomena in itself. The DCM approach guides this comparison [26]. Technical constraints that might block a full comparison of the clinical relevant material have been ignored [26]. This of course does require a later step to transform the DCM format into technology, but first examples have shown that it is quite easy to remodel a DCM in UML format to HL7 v3 template or 13606 archetype [26]. Not all steps are relevant for this review however.

The following levels of comparison are used in the bottom up conceptual analysis because they deal with the atomic or molecular levels of data elements and their relationships, or DCM:

1) Data types: that is the use of different types of data such as free text, (coded) value sets and physical quantities (ISO 21090), including units of measurements (Schadow and McDonald [34]).

2) Encoding: that is the manner in which each approach refers to external terminologies (IHTSDO [6], Riegenstrief [35]) for the semantics of each data element.

3) Concepts: that is the level of the clinical concept, the unit of thought representing the clinically relevant matter.

4) Meaning: is created by combining concepts, including component data elements and linking this with the context and knowledge for use in health care. Often meaning is derived from the scientific literature bringing evidence to what clinicians do.

In addition to this bottom up approach there are the categories included in the current draft work on ISO 13972 Health Informatics DCM [7]. These categories include: 1) clinician involvement, 2) content specification, including metadata, 3) modeling approach, 4) governance and repository, and 5) patient safety measures. For this review, the patient safety issues have not been addressed, they are only recently introduced in the ISO 13972 work from the assumption that in the future this is becoming more important, but actually is not addressed in most initiatives.

III. Results

The results section is building upon these different approaches. At first the general approach of each initiative is briefly reviewed. Next, the top down approach is used to identify the position of DCM in the architectural frameworks provided in the GCM of Blobel [20]. Then, the DCM initiatives are reviewed on more detailed level addressing DCM content, DCM Meta data and processes around DCM creation and governance. The latter is loosely based on the work of the NEN Mirror group [27] and ISO 13972 [7].

1. Results as in Approach to Modeling of Clinical Artifacts

There are two principally different approaches to DCM development: the deductive approach which creates the DCM against a reference model that determines all the features, or the inductive approach which allows for a bottom up, more phenomenal approach. In the latter inductive approach we see also two lines of development, the first is the clinical template approach [9] in which a whole clinical area is explored and from there the single DCM are derived. This functional or system approach is taken in both HL7 for the Domain Analysis Models, and in EN13606/OpenEHR for the template development. The other comes from projects like the Dutch national EHR infrastructure, where the same data elements tended to be remodeled for different clinical domains, but in fact it was the same concepts [3]. In this project data elements are specified in the format of Care Information Models [11], or currently DCM [4], and only if strong relationships between different data elements are required, they are combined. This is an atomic or molecular approach. See Table 1 for an illustration.

Table 1

Generic approach to the modeling of clinical artifacts

EHR: Electronic Health Records, CDA: Clinical Document Architecture, GCM: generic components model, NHS: National Health Service, SAIF: Services Aware Interoperability Framework.

2. Architectural Considerations for DCM

Based on Blobel's GCM [20], the relative position of DCM in each of the three axes is further explored and explained. The axis include 1) domain, 2) systems components, and 3) system development. Its use for DCM results from a discussion amongst experts working on the ISO 13972 draft standard materials [7].

1) Domain

In Domain Analysis Models (DAM), the business of a particular clinical domain is explored and analyzed, leading to identification of actors, workflow and data and data structures [10]. DAM really dealswith the vertical axis of Blobel's GCM. On the bottom level of a DAM, the data elements and data structures required in the domain link to DCM. In addition, the EHR architecture of ISO 18308 [31] links the health care business requirements to logical models for records. It addresses also the cross domain aspects of GCMfor the top level of health care. Although there is potential to link EHR requirements to specific DCM, only a generic link from business to the detailed specifications would suffice. However, that is different for the EHR system. In the functional model for EHR systems, such as Electronic Health Record Systems Functional Model (EHR-S FM) [32], there is ample opportunity to link the required content to DCM specifications.

2) System components

DCM is a placeholder for expressed clinical conceptual and logical content in the Reference Model of Open Distributed Processing (RM-ODP) framework ISO/IEC 10746-1; ITU-T X.901 [36]. The RM-ODP is a coordinating framework for the standardization of open distributed processing. RM-ODP usesa five component analytical model including an enterprise viewpoint, information viewpoint, computational viewpoint, engineering viewpoint and technical viewpoint [36]. The focus of the analysis is to facilitate the open distributed processing via distribution, internetworking, platform and technology independence, and portability. It can be seen as the horizontal base of the GCM in an enterprise architecture framework for the specification of ODP systems. DCM fit in the first three parts: enterprise, information and (some) computation.

3) System development

Model Driven Architecture (MDA) provides an open, vendor- neutral approach to the challenge of business and technology change [37]. MDA separates business and application logic from underlying platform technology [37]. MDAis seen by many as the way forward to create the consistency and to keep healthcare IT aligned [38]. MDA is part of the solution to create an integrated healthcare IT landscape that allows data use and reuse, bridges gaps between systems and facilitates aggregation from clinical data. MDA is depending on standards, on traceability, and in particular on the relationships between components [20]. In MDA, DCMs are important. DCMs provide thisconsistency, traceability and the reusability. Full traceability allows to find out what processes and systems are affected when a single information definition changes. In MDA a relation from the whole to the DCM suffices, there is no need for duplications and thus no inconsistencies. In MDA, the DCM addresses the conceptual level, and expresses links to the logical model, illustrating relationships between data elements and constraints. DCMs do not address the physical implementation level. However, in an EHR system or HL7 message, there might be a reference to a particular DCM stored in a repository for full description.

Health Level Seven International is a standards development organization [10] HL7 traditionally developed messages for interoperability, but current standards include the EHR-S FM, Clinical Document Architecture and Services. HL7 is adjusting its standards development to the Services Aware Interoperability Framework (SAIF) [39]. The SAIF goal is to create and manage easy-to-use, traceable, consistent and coherent Interoperability Specifications regardless of the paradigm. SAIF is not an architectural framework, but aligns with an architectural approach to manage the interworking among distributed systems that may involve information exchanges or service interactions and state changes [39]. DCM is to be placed in the Information Framework in HL7 SAIF. SAIF connects ODP-RM with MDA. In the case of DCM this is an important addition. This connection ensuresthe conceptual definitions are aligned and traceable to the physical implementation, thus enhancing the quality and value of the information. This architectural framework and the position of DCM is illustrated in Figure 1.

Figure 1

The relative position of DCM in an health IT architecture (GCM), expressing domain, system components (RM-ODP), and systems orientations, including services paradigm (SAIF) and model driven application development (MDA). GCM: Generic Components Model, DAM: Domain Analysis Models, FM: Functional Model, DCM: Detailed Clinical Models, RM-ODP: Reference Model for Open Distributed Processing, SAIF: Services Aware Interoperability Framework, MDA: Model Driven Architecture.

3. Data Types

The fundament of DCM is the differentiation in types of data. In particular differences in numbers, dates, value sets, and pictures are important. Even if one is using a native expression for data types, these usually can be mapped to the ISO 21090 standard [40]. However, that might be a cumbersome task initially, which can be avoided to some extend using a subset from ISO 21090. Commonalties and differences of the data types in clinical modeling are listed in Table 2, including the use of units such as Unified Code for Units of Measure (UCUM) [34].

Table 2

Comparison of data types in clinical modeling

EHR: Electronic Health Records, UCUM: unified code for units of measure.

4. Coding and Concepts

Concepts refer to the principle in which the clinical "units of thought" are represented in the clinical models. It is common to use both terms and a definition to specify the meaning of the concept. Systems in use for assigning meaning to concepts include classifications and terminologies such as the International Classification of Diseases (ICD), International Classification of Functioning, Disability and Health (ICF) [41], and Snomed CT [6]. Coding refers to the principle in which each clinical concept is represented with a unique code allowingeasy storage, recognition, querying, retrieval, aggregation, decision support among others. Each initiative follows the principle of one unique code per data element, taken from one to more external classification, terminology or coding system. See Table 3 for a brief overview of concepts and coding in clinical modeling.

Table 3

Comparison of concepts and coding in clinical modeling

EHR: Electronic Health Records, SNOMED-CT: Systematized Nomenclature of Medicine-Clinical Terms, UMLS: Unified Medical Language System.

5. Modeling of Structure and Relationships

Clinical modeling illustrates the data elements, binding to data types and coding systems for semantics, structural relationships between data elements, constraints, and behavior. Here we look more carefully at defining data elements [42]. In general, DCMs are underspecified. DCMs assume it pertains to patients/subjects, assume a care provider documents it, and assume there is time and location involved. However, since these aspects would require unnecessary duplications, these are mostly left out. For the modeling parts of DCM there is consistency in the different initiatives on what constitutes a proper conceptual model of clinical content. However, there is ongoing debate around the idea that a DCM must be expressed against a reference model or an ontology. Although these principles are not to be ignored, it has been proven in different projects such as IMH, DMC-NL and CCM, that there is no need for an explicit reference information model. On the other hand, 13606 archetypes can only be expressed as entries against the reference models, and HL7 templates are constraints against the HL7 Reference Information Model.

For the ontology more or less the same situation exists: it is perfectly possible to model clinical content against ontological principles [20]. However, it is not necessary for each DCM to fit into an ontology. In fact, the detailed clinical model is a micro ontology, expressing its content as a knowledge base. Table 4 shows some of the modeling aspects of clinical models.

Table 4

Comparison of modeling of content, structure and relationships in clinical modeling

EHR: Electronic Health Records, CDA: Clinical Document Architecture, XML: extensible markup language, DSS: Decision Support Service, ADL: Archetype Definition Language.

6. Meta Information and Knowledge Expression

Meta data are data that define and describe other data according to CEN/TS 15699:2009 [43]. In clinical modeling it does not specify the content itself, but presents the information necessary to identify and qualify the clinical content. Important for patient safety reasons is that users need to be able to verify the quality of the DCM. ISO 13972 aims to facilitate in this process. However, more general aspects can be addressed. In particular if the source of the materials can be tracked and traces, similar to a scientific publication, it becomes more trustworthy compared to an anonymous specification. If versioning is carefully maintained, the user can identify which is the latest and hence mostly the best version to use. Whether something is draft versus finalized is another important characteristic of clinical modeling.

The purpose of the clinical use is made explicit in 13606 and DCM NL, others depend on clinicians deciding based on the name of the model. In fact, in most initiatives, the knowledge remains implicit and assumed, where 13606 and DCM NL make that explicit. Reasons for this are to allow contextualization;in particular since these models are used for future aggregation, this can be very important. It further gives more details for the systems developers of what is intended with this clinical model.

Given that ISO 13972 currently has about 20 meta data elements, and in addition has a knowledge expression section of about 10 categories, it will be clear we cannot just copy that here. Hence, Table 5 addresses some core Meta data and the core knowledge categories.

Table 5

Comparison of meta information and knowledge expression in clinical modeling

EHR: Electronic Health Records, CiEHR: Center for Interoperable EHR, NHS: National Health Service.

7. Clinician Involvement and Endorsement

It is obvious that clinicians determine what they want to use in an EHR. However, their roles in projects can differ. In two of the projects (CTS and DCM-NL) we see a strong clinician determination of their needs in national projects, where in all six initiatives clinicians work jointly with modelers. Not all projects require an external endorsing authority, but it can be convenient if the role of content experts, modeler, reviewer and endorser are clearly laid out. At this stage each initiative uses such approaches. With respect to the content, there are two principal approaches: use the specific clinical practice environment as thesource, or use the scientific evidence as the source. However, neither of these initiatives follows one approach only but blends experience with knowledge. Hence, the comparison of clinical modeling approaches on the level of arrangements for clinician involvement and endorsement does not reveal significant differences.

8. Repository

A repository is the name for a place where example instances of DCM are stored and made available to target audiences. Differences here include whether they are publicly accessible, or meant for a closed group. Further, the use of keywords for search is important. See Table 6 for a summary.

Table 6

Comparison of clinical modeling approaches on the level of arrangements for a repository

EHR: Electronic Health Records, CiEHR: Center for Interoperable EHR.

9. Governance

Governance is about the manner in which each of the initiatives is maintaining its clinical models. At this stage, each initiative, except IMH are in a developmental stage. While governance has been acknowledged, it is too premature to review the governance structures. In IMH there is a team of about 30 persons full time available for the overall maintenance of the clinical elements, coding, mapping to LOINC [35], XML representations and deployment in the EHR, user interfaces, interoperability, reports and decision support rules and applications. This illustrates that it is important and significant resources are required.

IV. Discussion

It might be clear that with this approach to conceptual clinical modeling, we face a whole new approach to the EHRdevelopment, data exchange and data use and reuse. Instead of the traditional approaches where data are more or less locked in a particular application, or shared between a fixed set of applications, the detailed clinical modeling approach disentangles the knowledge, data elements and structure specification from a specific application. This has the advantage that users become less dependent on a particular technology or vendor. It has also the advantage that an EHR system can be configured to user needs much quicker compared to traditional ways of data specification and configuration. However, these assumptions still have to be proven.

Limitations of this review are present. We did not include a complete overview of available work on clinical modeling. Commonly cited are the HL7 CDA templates, CEN/ISO 13606/OpenEHR Archetypes, and DCM from IMH. In addition 3 other initiatives where included that actively contribute to the development of ISO 13972. This will introduce some selection bias in the review. Using the criterion of involvement in ISO 13972 and the approach of combining data elements suffices only to some extent.

Other source of debate is the approach taken to review materials. Some believe only the top down/reference model/architecture driven comparison would be accurate [16,17], others suggest that a bottom up approach reveals sufficient insight to compare approaches [26,33]. It can be questioned if the GCM model based approach, even with the domain, system components and system development cover all aspects. At this stage we agree with Blobel [20] that it does allow a comprehensive analysis. The bottom up approach might not be complete. However, both approaches give insight in where to place DCMs in the different axis and what aspects to consider.

Specific differences between DCM approaches include the required use of a reference (information) model (OpenEHR/13606 and HL7 templates) versus a more inductive approach covering the phenomenon as a self contained material. The representation formats however, do differ. In modeling, archetypes do not clearly show hierarchical and other relationships between data elements. Clinical Templates does cover more abstract levels where a set of DCMs is combined in forms.

We presented in the tables only a subset of the categories addressed in the ISO 13972 draft standard. However, there is increasing consensus that what is presented here does cover the core. Additional items are necessary, but cannot be expressed here in full. Content wise there is always a possibility that a particular characteristic has not been published or made explicit and is forgotten here. With that respect, this paper must be seen as a first attempt to compare the different approaches. Finally, although the categories for comparison could be determined, measures of each of the categories quality are needed and work on quality metric has been carried out and is currently submitted for publication [24].

Further, it does sometimes lead to confusion what is exactly meant with DCM. In the ISO 13972 team this is expressed as; do we call any kind of clinical modeling a DCM, or is DCM the conceptual model approach following the guidelines in ISO 13972? We believe the DCM pertains to any kind of clinical model that addresses the conceptual level, and which, for implementation needs to be transformed e.g. into an archetype or HL7 template.

V. Conclusions

There is a huge need for DCM in order to enhance data quality and data use and reuse in health care information technology. In particular the goal of establishing semantic interoperability cannot be dealt with via terminologies alone. DCM can be used to analyze, sort, formalize, structure and standardize data elements for clinical use. Doing so at the conceptual modeling of data elementsand their relations for clinical use, allows creating and maintaining a DCM set independently of the technical implementation in which they will be deployed.

Examples of DCM initiatives around the world do reveal that they can be placed in an eHealth architectural framework, as offered in the GCM, and that they can be analyzed and compared at the most granular level following the bottom up approach. These two approaches augment each other.

Applying data elements standards for clinical purposes hence facilitates the use of DCM as conceptual models, in different technical representations such as for use in EHRand Personal Health Records (PHR), DWH, and electronic messages (e.g., HL7).

To ensure quality specifications of clinical concepts for different purposes, based on clinical needs and clinician involvement,the expression of data elements, their relationships and structures and coding are the core of DCM. Adding contextual knowledge and Meta information to it contributes to overall DCM value. In order to achieve a long term quality control of DCM, organizing the governance, enabling access via repositories,and applying measures for patient safety are important. The presented initiatives have these characteristics in common. Standardization of such features is underway in ISO 13972 and will facilitate the exchange and use of DCM worldwide and will contribute to borderless quality healthcare.