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.

12 thoughts on “DCMs – clarifying the confusion

  1. Dear Heather,

    Thank you for your overview of DCM developments. They are consistent with my experience. I think some minor corrections are required:

    1. Historically it would be of interest who where attending the Brisbane meeting in 2007. The full list of participants is in the document as appendix A.

    2. ISO 13972 Part 1: Part I – Quality processes regarding detailed clinical model development, governance, publishing and maintenance and Part II – Quality attributes of detailed clinical models
    still have as scope quality attributes for methodology for dcm / DCM modelling or transformation. This has not been removed from scope but was agreed to be based on an architectural approach introduced by one of the experts. In particular modeling issues that are in scope for archetypes, dcm’s HL7 templates are the definition of data elements, binding to vocabulary, expressing data types, expressing value sets, relating data elements to other data elements and such. These are the core parts of modeling clinical content and included in all the examples of dcm’s, archetypes, DCM’s and HL7 templates.

    3. All DCM materials from HL7 that have been discussed and approved are available on the HL7 Patient Care WG (PC) document section and to some extend on the HL7 wiki. Ballot comments on 2 of the 5 DCM examples will be part of the upcoming week’s PC agenda, which has been distributed on the PC list directly following the Sydney meeting in January.

    4. (perhaps more an addition than correction) The HL7 DCM stem from HL7 patient care template expression work (years 2003 – 2007). That used R-MIMs which technically leads to combinatorial explosions in XML variants. Hence they where converted into the current DCM format. That DCM format is largely similar to the archetype clinical content specification. That DCM format has been intended to be the Ubermodel that Grahame Greave suggested. This has been done by taking the best from the existing technical artifacts and using UML. UML was agreed in Brisbane as usable to all to get from there to the different technical artifacts, (not preferable to all).
    This will of course be on the agenda for further discussion in the different groups.

    5. The project with archetypes in HL7 CDA in Australia was presented several WGM’s ago (Rio?) to HL7 Patient Care WG (PC) by Hugh Leslie. The fact that this kind of work has not progressed in PC is simple: despite several request that presentation has not been handed over to a PC co-chair to be put in the PC documentation. Hence, we have not been able to look at this in more depth and work on dcm versus DCM. We are still willing to put that presentation on ours site and look into this. But perhaps we need a Fresh Look for that 🙂


    • Hi William
      Couple of comments.
      I don’t believe that any format including UML was agreed upon at the Brisbane meeting. Indeed one of the issues with saying UML is that you might as well say XML or HTML. UML is a representation formalism for models, however to represent something like an archetype, you need a methodology behind it. This has been my constant criticism of the HL7 process (as well as a number of others including Graham Grieve as you know). We are balloting models without any understanding of the methodology behind them. Perhaps your company has a methodology that needs to be published, but until then , we cannot really move forward with the UML approach. I would also continue to argue that the SDO standards approach is inappropriate to development of these models. Its far too slow and cumbersome and inflexible. If we need every model to go through the standards process we will never get where we need to go and certainly never get the amount of input from clinicians that we need to make sure that they are correct.

      I have emailed you the slides, however I have never had any discussion with you or at PC with regards to further discussion of this approach, so I am a little taken aback with your post in this regard.

      Looking forward to more robust discussion

      regards Hugh

    • Hi Heather,

      After reading the pieces on “DCMs” and “Diagnosis/Problem” a couple of observations came to mind.
      Some of the hurdles we confront may be helped by having two types of DCM; a DC information M and a DC process M. There is a lot of attention paid to what I call the “statics” of information and not a lot to the “dynamics”. It is the process dynamics of the clinical system that provides the context that gives information its meaning and makes inference possible.
      Our Healthcare Informatics in research, education and service (HIRES) project at McGill has as a deliverable a “Computable Patient Record” that supports the three mandates of the post graduate clinical teaching environment. We have completed a systems model of our facility and its processes and are starting detailed modeling of clinical processes. We will structure our modeling with OBO compatible ontologies and hope to enhance the constraint language for the archetypes we plan to use.

      Weed’s contributions to clinical process modeling led to the SOAP note and progress since then has mainly occurred in the chronic care model area.
      The hurdles with “Diagnosis/Problem” are related to inadequate modeling of the clinical process whose characteristics we are attempting to codify.

      “Diagnosis/Problem” is too vague for the machine. A diagnosis is a state for which evidence shows that the diagnostic criteria have been met. A problem is a much more vague term that is commonly used to characterize what I call the object of the medical concern (patient defined); the object of the medical encounter (MD or nurse defined); or as part of the object of the medical intervention (OMI) or that which justifies the medical act proposed.

      An OMI has multiple potential parts. For example the first part could be the reason for the encounter such as a discomfort, a dysfunction, a delta or change, a third party request or a confirmation of wellness. The second part could be either the diagnosis (if diagnostic criteria met) related to the reason for encounter if applicable or a differential diagnosis (if criteria not met). Then you can go on to things like severity, status, are results pending, interval to scheduled follow up etc. depending on what works for the clinician. This helps document and bind the clinical “intent” to the medical “act”. We hope to run some clinical trials at our facility to see what information and displays yield the best outcomes.

      The functionality and data needs required for research and education in the clinical teaching environment have given us some good insights since we have had to accommodate many masters. We will work in collaboration with openEHR, HL7 and the Ontology of General Medical Science and hope to produce some useful tools.

      Your observations are most appreciated. Will talk soon.

      best regards

      • Hi John,
        Great to hear from you.
        Totally agree with your observations about the nuances of problem/diagnosis and the need to support these through the process of clinical practice for all detailed clinical models.
        A few comments regarding the openEHR archetype environment, and in particular the Problem/Diagnosis archetype to which you refer:

      • The scope of Problem/Diagnosis archetype is quite narrow, effectively the static/persistent model as an evaluation at the end of a consultation or episode. It’s ‘Use’ states: to record detailed information about problems or diagnoses recognised by a clinician. There are many uses including: recording a Diagnosis during an Encounter; populating a Problem List or a Summary Statement, such as a Discharge Summary.”
      • Our feedback has been to record patient defined issues separately as there is significant semantic difference, and perhaps wise to keep them separate to clearly support clinical decision support etc safely. No doubt the eventual structure of the model will be very similar to Problem/Diagnosis.
      • Similarly the reason for presentation, presenting complaint and other similar are related but have significant semantic differences and need to be modelled separately.
      • The issue of ‘status’ is curly, with potential safety issues, and as such has been separated out as described in more detail in the Problem Diagnosis post.
      • Results/ Followup plans are modeled separately and outstanding results or plans for next visit can be flagged in the context of a composition comprising multiple archetypes – including the EVALUATION.problem_diagnosis, OBSERVATION.pathology_test and INSTRUCTION.”followup”
        Look forward to discussing this further soon, perhaps we should move this discussion to the Problem/Diagnosis post 🙂



      • Hi John,

        This is a very interesting area. I am not sure if you have read these notes http://www.openehr.org/wiki/display/healthmod/Problem%2C+Issue%2C+Diagnosis+and+Concern

        I think you will see some obvious parallels with your suggestions above. I agree that the progression of the problem/diagnosis is insufficiently mapped and understood especially in hospital settings. In theory I would agree with your definition of a diagnosis, but in practice most diagnostic definitions are poorly or very variably defined and can be somewhat artificial e.g ‘ Mechanical Back Pain’ – is that a problem or a diagnosis?? I think one of Larry Weed’s great breakthroughs was to make it acceptable for problems to exist on the Problem list alongside the ‘harder’ diagnoses. None of the UK general practice systems make a clear distinction between problem and diagnosis, that is ultimately left to the label itself e.g. ‘Back pain’ vs ‘Prolapsed disc’.

        We should definitely discuss further – I am very interested in you approach, though I have some doubts as to how to apply ontological modelling to some of these very human constructs, without a great deal more consensus-building.


  2. So we can live with having the same name for two different things as openEHR and HL7 templates but we can not have the same thing for detailed clinical models? How would you abbreviate it on a paper?

    • The name itself doesn’t matter, but seems common sense to me to name different artifacts differently. But hey, no-one ever asks me!
      We have what we have, and we just have to keep trying to clarify and differentiating between all these good efforts, be they dcms, DCMs, templates or templates 🙂

  3. Pingback: ICMCC News Page » DCMs – clarifying the confusion

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s