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.

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.

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.

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.

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].

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].

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.

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.

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.

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.

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.

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.