This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Detailed Clinical Models

From HL7Wiki
Jump to navigation Jump to search

return to: Patient Care

further to: Detailed Clinical Model instance construction

further to: Detailed Clinical Model guidelines for creation

Status of this Wiki and of DCM in and outside HL7 space

The material on this part of the wiki on DCM cannot be considered as 'owned' by HL7. In contrary, it is to a large extend not (only) HL7 material. This wiki page is hosted by HL7 WG Patient Care to discuss these matters, as a result of different WGM meetings where participants of OpenEHR, CEN, ISO, HL7 and researchers in the area requested that at least one of the organizations facilitate further work. The more neutral website is currently not always accessible for such discussions and in particular it does not facilitate file storage. Further, the DCM website is highjacked almost every other week, rendering it unsafe for our work.

The top 10 draft examples of DCM presented in the area further on in this HL7 PC wiki are formally owned by Nictiz, the Netherlands, with Results 4 Care employees being the authors. Nictiz has a charter to make this material publicly available after being finalized. Public consultation is part of the finalization to take place. Feedback from within the HL7 community and from outside the HL7 community will be solicited.


A Detailed Clinical Model (DCM) is a formal specification of the semantics of discrete structured clinical information. It provides the data elements and attributes, including the possible values and types of the attributes, needed to convey the clinical reality in a fashion that is understandable to both clinical domain experts and to formal logics, including the potential for use in computer algorithms. It provides unambiguous detail which is intended to be cross domain and cross discipline. The DCM does include the clinical knowledge on the concept, the data specification, a model and where possible, technical implementation specifications.

In the ISO 13972 standard for Quality Requirements and Methodologies for Detailed Clinical Models (DCM) it is described as follows: Detailed Clinical Models are small items of clinical, preventive and care information that are well defined and for which knowledge, data definition, vocabulary binding, and information model for use in information and communication technology are standardized and reusable over domains, purposes, standards and implementations (adapted from Brisbane workshop, 2007). DCM work currently includes clinical content analysis, quality assurance, information modeling, and repositories.

Implementation of DCM

DCM is considered to be a specification that is first independent of a specific technology. In other words, more or less agnostic to a particular standard or technology. However, DCMs are only useful when implementable. Thus the DCM does require additional work to have them fit into for instance and OpenEHR archetype model, a database schema, a user interface or a HL7 message or document or service.

HL7 version of a DCM

The HL7 specific application of DCMs will be published as a Template which constrains the Clinical statement pattern following the TermInfo guidance on use of controlled terminologies. It is also likely that in addition to any template specification, it will include additional machine processable definition and constraints needed for a computer program to 'understand' a given DCM, with the intent of providing a plug-in type mechanism where ERHs and other healthcare IT platforms can add new content directly without requiring separate implementation.

DCM work at ISO

New Work Item Proposal 13972 quality criteria and methodology for Detailed Clinical Models was accepted by ISO member states in July 2009. This standard does not focus on creation of DCM, but on guidance on how a DCM should look like, and criteria that need to be met. The ISO DCM International Standard is in its first stage of development during the ISO work group meeting in Durham, NC, Oct 2009.

Currently core components of the ISO DCM standard include:

1. assuring clinician engagement and endorsement.

2. the quality of the content that forms a proper DCM.

In particular the following criteria have been established in earlier discussions:

  • a proper DCM has meta information, including authorship and endorsing authority.
  • a proper DCM has a terminology binding which is slot based.

This means that a DCM can work with any terminology upon choice of user, e.g. with LOINC, or Snomed CT or ICD9 or ICD 10.

  • a proper DCM does include particular rubrics such as what is the concept, what is the goal for use in clinical practice, what is the supporting evidence, the full specification of data elements and relationships, the guidelines for appropriate use, interpretation guidelines, and where necessary guidance for the care planning around its use.

3. guidance on modeling of DCM, where UML will be used as example, but might not become normative.

4. quality measures for repositories of DCM in order to be able to store, index, find, retrieve, update and maintain DCM.

One item which will be discussed is how guarantees will be given for patient safety.

Current focus at HL7 is on clinical findings

DCMs are of clear value in multiple areas of clinical data. Given the pressing needs the initial focus will be on capture and representation of clinical findings. This is a loose definition, but conceptually could be considered whatever a clinician would put into a health record which documents information about a patient. While this could include every laboratory report or medication administration, the unmet need is to document the intellectual work product of credentialed clinicians. Thus, while there are some aspects of some laboratory result reporting which may benefit from the more elaborate and formal semantics of DCMs, the actual representation of the data is largely encompassed by existing HL7 specifications. What is missing is the test specific set of diagnosis, or other interpretations, which would be based upon the test results. So while there isn't a pressing need for a DCM for serum sodium reporting, there is a definite gap when it comes to serum sodium interpretation (which would also include other clinical findings, such as renal function, serum and urine creatinine measurement--to calculate a FeNA--, as well as urine sodium, exam findings of volume status, mental status etc.). Similarly, the use of assessment scales is in this space of clinical work. Assessment scales facilitate clinicians in their decision making. More explanation on that can be found in the Patient Care Care Provision topic of assessment scales.

Use of SNOMED-CT to the point of exclusion of other code systems

One requirement for DCM is the slot binding to terminology that defines the concept of each variable or data element. Currently, the only controlled reference terminology which has the structure and the breadth of content suitable for representation of clinical findings in an electronic health record system seems SNOMED-CT. Although SNOMED-CT is far from perfect, nor complete. Other terminologies will be needed to supplement content in specific areas (e.g. use of ICD-O-3 or parts of NCI thesaurus to represent details of cancer diagnosis). Alternatively, some concepts are best represented in another terminology, for instance the example of the Braden scale that is in the DCM examples section. The Braden scale, including each allowable value in the value set has been fully encoded in LOINC.

Selected use of other terminologies

  • ICD9CM
  • ICD10, ICD10CM
  • ICD-O-3
  • NCI thesaurus
  • GO
  • RxNorm
  • FMA
  • Nursing specific terminology (NANDA, NIC, NOC, Omaha, ICNP)
  • ICF


This example uses a non-normative HL7 "flavored" UML. UML is a notation which can express a wide range of detail and modeling rigor. While UML does have a very useful serialization (XMI), the principle use of UML remains communication between humans. Readers are asked for some indulgence in this regard. As the methodology evolves over time, it is likely that there will be a formalism which is shared between all parties to specify the clinical content in EHRs. In addition to the conventional use of UML in software engineering and the common use of specific tools in creation of domain analysis models, we should investigate some of the more advanced used, particularly the OMG's Ontology Definition Metamodel [ ODM] which is supposed to be iso-semantic and transformable with OWL-DL.


Note: this example is released under conditions of the creative commons Share Alike with Attribution Non-Commercial license, with the exceptions that part may be covered under copyrights held by HL7 and/or IHTSDO which are included under fair-use. I will upload a better example when I can find the original (XMI) file --KevinCoonanMD 04:59, 27 October 2009 (UTC)

Use cases

The major use case for DCM is to create a consistent data element specification for concepts that need to be entered in an Electronic Health Record (EHR) and in a Message. This makes the first use case the clinical documentation of findings. In addition the following purposes can be defined, which are use cases in their own right.

  • Clinical decision support systems
  • Disease / syndrome surveillance
  • Quality of care metrics
  • Generation of human user interface components
    • Checklists
    • Review of systems (ROS) and physical examination (PE) 'templates'
    • Structured complaint/disease specific HPI
    • Disease specific datasets
  • Clinical research
    • Case report forms (CRF) and electronic data capture (EDC) in prospective clinical trials
    • Patient reported outcomes (PRO) and symptom diaries
    • Retrospective comparisons, case series, and other 'naturalistic' study designs
    • Ad hoc case-control analysis
  • Automatic claims adjudication
  • Provider credentialing and procedure logs


Publication format

The Netherlands has been creating examples of what is now called DCM since 2003. These examples have largely informed the current project and are available at The format will be published soon, following discussions in Durham at ISO.

UML (non-HL7 specific)

All DCMs SHOULD have a non-HL7 UML2 Class diagram which uses the ISO 21090 data types to represent the components of the DCM. Class/element and attribute names should match those used in clinical practice. Value sets can be represented as an enumeration with or without specification of the contents. This is very similar, if not identical to, a very detailed domain model.

HL7 Template

Value sets


DCM do require metadata. Which metadata are appropriate needs to be established. Currently we work with the list of metadata specification from HL7 templates and from the OpenEHR clinical knowledge manager.


Project to Compare existing formats of DCM

At the May 2007 WGM in Cologne we decided to carry out a project to determine if it would be feasible to compare the models in current use (e.g. UK NHS, Dutch Care Information Models, New Zealand data specification, Tolven examples, OpenEHR Archetypes, Intermountain Healthcare), and if so determine an approach for comparison/cataloging, and determine potential for harmonization efforts. During the Sept 2009 WGM this was reconfirmed following a presentation from South Korea's Center for Interoperable EHR.