Following the DCM meeting convened by Dr Stan Huff (Intermountain Healthcare) in Washington in July, reported in an earlier blog post, there is a further meeting this week in San Diego, which will discuss the issues of ‘data types’ and ‘reference models’ for the purpose of DCM (detailed clinical models).

I created two slideshows to explain my views on these matters (DCM_and_data_types and DCM_and_reference_model [both PDF]). Below is an extract of my arguments in these slideshows, based on experience, for adopting a particular approach to data types and reference model within the stated mission the DCM forum, which is to find formalism and attendant models in which to express universally shareable detailed clinical models. Naturally, my view on ‘the answer’ to that question is ‘openEHR (ADL/AOM) archetypes, templates and terminology’, but what I am providing below is not an argument supporting that, but one proposing how to proceed with respect to the ‘underlying models’.

[The following are extracts from the above slideshows; you don’t need to read both]

Basic concepts

Assumptions

• DCMs are based on an underlying model (ULM), rather than each being an independent model (e.g. Classes, RBD tables) for domain definitions
• DCMs are not themselves part of the software (although some generated artefact might be)
• This is the raison d’être for DCMs –to get out of the mess of endlessly growing and unmaintainable software and databases
• We assume that the ULM provides a shared definition of data and (some) semantics, i.e.
• Basis of at least data interoperability
• And potentially software interoperablity
• Therefore… DCMs cannot ‘break’ the ULM

‘Based on an underlying model’ means:

• The underlying model provides the ‘primitives’ needed for DCM modelling
• DCMs don’t have to redefine these primitives
• The underlying model provides commonly required patterns for doing DCMs

The golden rule:

• Every instance of a DCM element is also a valid instance of the corresponding ULM element
• Breaking this rule means:
• non-interoperable DCM instances
• No assumptions can be made by software

Data Types

The need for clinical DTs is well-known in health informatics, and everyone agrees that types such as are required:

• Identifiers
• Text, coded text
• Various quantity types, Ordinals, Dates, times, durations
• Time specification types
• Multimedia / encapsulated data
• Esoteric types

Possible starting points for DCM

• Existing published models?
• ISO 21090 / HL7v3
• openEHR
• Grahame Grieve’s Resources For Health data types
• A proprietary model, brought into the open?
• Intermountain Health
• A de novo model we build for DCM

My analysis then follows. My recommendations:

• Decide on a starting point that everyone can at least agree as the starting point!
• E.g. Grahame’s DTs
• Work on this to ensure it covers required types
• E.g. Some missing ones from openEHR –DV_PROPORTION
• Missing types from HL7/21090
• Then…. Determine a minimal definition of each class required for DCMs
• Only the core types have to be done initially, e.g.
• basic Identifiers
• Text, CodedText, Code
• Quantity, Count, Ordinal
• Date, Time, DateTime, Duration
• Boolean

Reference Model

Starting point:

• Data Types are the most basic patterns required
• The Reference Model is just higher-level patterns

Therefore…

• Rather than debating what reference model among published EHR and other models should be used, we should…
• Identify the key patterns needed for creating real DCMs, and define our DCM-RM based on that
• The DCM-RM should also provide good semantics for computing with data

I then go on to describe what an RM pattern is, and provide a lot of examples from openEHR, globally applicable to health, based on the list in this previous post.

My recommendations for the RM for DCM:

• A. The key is to define an RM consisting of the key patterns that need to be archetyped/ constrained in DCMs, leaving out details of messaging etc
• 1. Some of openEHR’sRM is potentially directly usable for this purpose, due to the archetype history
• 2. Some pieces of other models also useful –see e.g. Singapore LIM, various CDA patterns etc
• B. Don’t start ‘building’ this DCM-RM as a separate exercise; instead, define some key archetypes to be built and use these to determine what bits of the RM are needed
• C. Convertabilityof DCMs based on the DCM-RM to real world RMs has to be considered.