DCMs – clarifying the confusion

Detailed clinical models are certainly a buzz term in the health IT community in recent years, commonly abbreviated to DCMs. Many people are talking about them but unfortunately, often they are referring to different things. The level of confusion is at least as large as the hype. Intermountain Health have published about their work in development of detailed clinical models as far back as 2003. Detailed Clinical Models are currently being balloted in HL7. ISO TC215 (Health Informatics) is currently developing an international standard about DCMs. And in some places ISO 13606 or openEHR archetypes are referred to as instances of DCMs. Confusion reigns supreme.

Borrowing from the HL7 wiki, a Detailed Clinical Model is:

"an information model of a discrete set of precise clinical knowledge which can be used in a variety of contexts."


Searching on Google, there are many references to 'detailed clinical models' – some dating back to 2003 & 2004. Those from Intermountain Health are reflecting the use of computable models in systems, others are calling for standardisation of clinical content to support interoperability of health information.

I'm told that informal discussions between experts from various groups including HL7 and openEHR began to explore a common approach in 2006-7, and finally in August 2007, immediately following the Medinfo conference in Brisbane, a number of experts gathered to discuss a way forward. The report from that meeting [Detailed Clinical Models: Report of a Workshop in Brisbane, August 25, 2007 - PDF] is a useful resource documenting the existing approaches to clinical modelling. I did attend that meeting, but unfortunately there is no mention in the report of the other attendees – it would be an interesting historical record. [Update: The list of attendees is indeed included in the Appendices.]

Conclusions and recommendations from that meeting included:

"During the meeting presenters and participants discussed the question whether we can get one representation model that covers all of the requirements of Detailed Clinical Models for different technical developments: GUI design, database design, message design, algorithm design, rule-based DSS design? It still remains the question if this as a whole is too difficult. Is it wise and appropriate to do so? Is the effort worth it? True semantic interoperability however goes beyond the individual variable and terminology bound to it. The context of healthcare requires more in depth approaches. On top of this intrinsic need, the pragmatics of resources – always necessary for their primary task of caring for patients – requires that we spare clinicians. Clinicians should not have to worry about all the technical nuances. However they would need to be able to verify and control the quality of content in order to trust the EHR and the message content presented to them.

Participants of this workshop on Detailed Clinical Models were members from ISO, CEN, HL7, openEHR and other groups. There was a general feeling of these 35 experts that it is important to take this work further. Four action areas identified include clinician involvement, quality of detailed clinical models, representation formalisms and establishing and maintaining repositories.

Clinician involvement means to facilitate them in sharing expertise to achieve best practice, to share the work in making useful materials for practice. Governance of the clinical domain is important to ascertain. The detailed clinical modelling work is where standards developers come into the picture and librarian skills for the repository management.

Based on the panel on clinician involvement, it becomes obvious that ongoing standards work needs to distinguish between the Clinical Template and the building blocks or Detailed Clinical Models. The Clinical Template is about all information that clinicians want for a patient problem / clinical domain area. The main responsibility here is clinical, with a focus to support clinical practice with adequate data entry similar to forms already in use.

Quality criteria that are agreed as core areas include the use of meta-data, setting levels against which to judge the content of DCM, establishing methods for vocabulary binding and tackling language and mapping issues via the conceptual approach.

A general consensus is emerging on the representation of Detailed Clinical Models being standards and technology independent. Existing examples of DCM include the openEHR archetypes, HL7 R-MIMs / templates and other HL7 or local materials, but most are standard or technology bound. Here the responsibilities are with the modellers, system and message developers, but also to repository managers. UML and plain XML are mentioned as possible candidates for agnostic modelling and formalisms, because they would easily transform into R-MIMs, archetypes and technology. However, to keep the clinicians on board, a clinical format, such as the clinical template forms is essential part of a Detailed Clinical Model. In particular this is necessary to recognise the clinical relevance for particular items and the context specificity of domains. One recommendation for HL7 as organisation would be to rename HL7 template work to better reflect the exact meaning, because it is different from the clinical template work described here. HL7 technical template would perhaps do the job.

Maintaining national / project repositories and establishing an international repository of repositories is important for future work in this area. To paraphrase Hoy (2007): "By developing clinical templates: we share our expertise, we share the work, we can include terminology and classifications in a consistent way",… and we deliver domain content for standards. These outcomes of this workshop are relevant for joint standards work of ISO, CEN, HL7 and openEHR, but also of many clinical communities wishing to use EHR and messages for better patient care based on evidence and demonstrated with clearly defined patient outcomes."


A mixture of:

  • quality criteria for all clinical content models
  • creation of specific instances of clinical models known as DCMs and developed according to a single, specific methodology
  • creation of, or re-use of existing, clinical content models that have been transformed to DCMs.

This is where the confusion arises....


In October 2008, in Istanbul, a new work item proposal was accepted by ISO TC215 (Health Informatics) – ISO 13972 Quality Requirements and Methodology for Detailed Clinical Models - targeting an international standard as the final outcome. Initial scope included quality criteria covering 4 areas:

  • Clinical involvement and endorsement
  • Meta-information and content
  • Modeling and model transformations
  • Repositories
  • [Safety, added later]

To date, the common übermodel, proposed in section 6.3 of the 2007 Brisbane report, has not been identified or ratified such that it could be transformed to each reference model formalism eg HL7v3 or openEHR.

At the ISO TC215 meeting in Rotterdam in October, 2010, the proposed standard was split into two parts:

  • Part I - Quality processes regarding detailed clinical model development, governance, publishing and maintenance
  • Part II - Quality attributes of detailed clinical models

The scope now reflects development of quality processes and attributes for any and all 'detailed clinical models' – whether a theoretical future übermodel or current HL7 artefacts, archetypes or any other models. The section on methodology for modelling or transformation has been removed from scope for now, at least until there is broader international consensus on how this should be approached.

This standard development is ongoing (albeit slowly) with a Committee Draft of Part I being proposed to the next ISO TC215 meeting in Finland next week. There is no publicly available version of this document, however it is my understanding that it can be made available to members of stakeholders in the ISO JIC process via the primary author William Goossen.

DCMs in HL7

In parallel, HL7 Patient Care (led by William Goossen) has commenced a Detailed Clinical Model project, exploring some concrete examples of clinical content models, also known as Detailed Clinical Models. Ten DCMs have been made public, and five of these have recently undergone a HL7 balloting process. (I tried hard to find an up-to-date status for each of these ballots but have not been able to. If anyone can provide a link to this, I'd be happy to update this section.)

The current DCM modeling methodology has been proposed to the Modelling and Methodology committee in HL7 for ratification.

DCMs in Netherlands

In Netherlands it appears there has been a Dutch DCM foundation formed, with IHE, HL7 Netherlands, Nictiz and William Goossen's Result4Care as partners.

I understand the DCMs being developed in Netherlands are the source of the current HL7 DCMs under ballot.

Additional background to DCM development is also found on this site.

DCMs in NEHTA, Australia

From the National eHealth Transition Authority website:

"NEHTA is actively engaging with the healthcare community to develop computable clinical content definitions known as Detailed Clinical Models (DCMs)."...

"The collaboration process in the NEHTA Clinical Knowledge Manager (CKM) will result in a library of archetypes (initially openEHR archetypes) based upon requirements identified by Australian clinicians and other health domain experts, and drawing from comparable work overseas. To create the DCMs, these archetypes will be transformed into platform and reference model agnostic models (based upon ISO 11179). They will then be uploaded to the National Information Component Library that NEHTA is in the process of building."

DCMs in New Zealand

Just today I've become aware of a newly released New Zealand Interoperability Reference Architecture Draft for Comment. In Section 7.3 of this document they describe Detailed Clinical Models and provide examples.

Their Directive:

"The archetype (ISO 13606 or openEHR) should be used to describe the DCM."

And their Rationale:

"Archetypes are increasingly used internationally to represent clinical information. They include mechanisms for automated transformation to other artefacts – such as HL7 CDA."


Some final thoughts, but first, in the interests of full disclosure:

  • I am Director of Clinical Modelling for Ocean Informatics and leading development of the Clinical Knowledge Manager;
  • I am an Editor for the openEHR Clinical Knowledge Manager;
  • I am a nominated Australian expert to the ISO 13972 Quality project; and
  • I am involved in the NEHTA CKM archetype development process as an Editor.

I am commonly asked for clarification about DCMs – this is my attempt to provide some context and background, plus some examples of ongoing DCM-related work. Now I've tried to provide an unbiased overview, you can judge the result. Please feel free to comment if you disagree, and I'm happy to update this post if you identify any gaps.

Some DCM work, and especially the ISO standard, is abstract and related to quality criteria applicable to all clinical content models. I fully support this as a constructive approach, furthering the efforts of all clinical modelling to ensure that our resulting EHRs will contain content that is high quality, safe and fit for clinical purpose.

The work around instances of DCMs remains contentious, with many approaches. A few thoughts and comments in the meantime:

  • Informal discussions immediately preceding the Brisbane 2007 meeting were suggesting that feasibility for selection of a single model selection as a 'source artefact' should be explored, with work on transformations to other Reference Models following, automated wherever possible. I'm told that openEHR archetypes were mooted but this has never progressed for multiple reasons, not the least being political :)
  • Interestingly, at the recent HL7 meeting in Sydney in January, 2011 a DCM feasibility demonstration project has been proposed, led by Grahame Grieve with input from the Patient Care, Models & Methodology and Templates groups.
    • Start with openEHR archetypes as the base
    • Establish adornments that map these to the V3 Ontology (Structured Vocabulary and RIM)
    • Create tools that then consume these to produce useful HL7-V3 artifacts (templates, or such)

    It will be interesting to watch this project evolve, although I understand that there has been little progress to date. The next HL7 meeting is due to commence tomorrow in Orlando, USA, so we may have an update very soon.

  • And finally, just as an aside, my preference would be that the ISO standard on quality criteria and any references to the entire group of clinical models express them as "detailed clinical models" (no capitals) as a possible slight differentiation to the explicit models based on the specific methodology being produced in HL7 as "Detailed Clinical Models" (all capitalised).

I sincerely hope that this post has helped to lift the veil of confusion just a little.