Detailed Clinical Models (DCMs) – some basic facts

The New Zealand e-health programme architecture task-force has published its Working Interoperability Reference Architecture blueprint document. With respect to the document and the comments posted (I tried to post myself,  but the comment disappeared), it seems worth making a couple of points on DCMs, of whatever flavour. If a DCM is to be expressed in a way useful to building and managing health IT infrastructure, there are two possibilities.

EITHER

  • A) Each DCM is a model of its own (typically in UML), that does not re-use or reference concepts from anwywhere else. This is how software and database development worked in the 80s, and is still done in too many places today: with a monotonically growing set of additions to the models, which cripple sustainability. There is no hope whatever for such an approach in health.

OR

  • B) Each DCM is connected to an underlying model of information in some formal way that enables the ever-growing IM/DB schema mess to be avoided. In this scenario, DCMs must be transforms, constraint statements or have some other computable mathematical relation to an underlying information model.

The idea of a ‘model-independent’ DCM corresponds to A), and won’t work in health (nor any domain with realistic informational complexity). It is a nonsense idea.

The problem that people really have here I think is socio-political. They hear ‘underlying information model’ and immediately leap to the conclusion that this must be one of the extant EHR or message standards such as CDA, 13606, openEHR etc, and they become competitive / defensive / political.

They should be thinking instead of what kind of information model is needed and what its purpose is in the scheme of things. As I explained in my post One information model to rule them all?, the ‘underlying IM’ has to be considered as a set of ontological patterns that can be used by the DCMs. These patterns define key agreed generic semantics of the domain – very low-level stuff. The core part of the openEHR RM (the part that is usually archetyped) was not only designed on this basis, but it was heavily modified over years by feedback coming from clinical people doing archetypes… yes that’s right, doctors had a huge influence on an IT model! Today, most of the model works as an extremely stable basis for archetype ‘DCMs’.

I don’t know whether NZ will use openEHR RM in any way, but until people in the programme there (as in other programmes around the world) understand the DCM/IM relationship, their plans in this area are likely to go badly awry.

With respect to the rest of the document, there is some good thinking there, but likely to be compromised by the ‘shopping basket of standards’ approach. I went through some of the dangers of this in a series of (overlong!) blog posts on The crisis in e-health standards. The basic facts are: e-health standards are a) not well designed, b) not directly compatible, and c), evidence has shown huge costs of trying to integrate them.

I would simply ask the question: which, if any, of these standards is fit for purpose, and what is it fit for? Mashing together a bunch of standards for the sake of being ‘standardised’ is not useful, the programme will just burn money. A coherent computing framework is needed. If incompatible standards are to figure in that, it must be shown how they can formally work together. Knowing whether to treat them as semantic entities or serialisation specifications is key to this.

Advertisements

About wolandscat

I work on semantic architectures for interoperability of information systems. Much of my time is spent studying data, ideas, and knowledge, and using methods from philosophy, particularly ontology and epistemology.
This entry was posted in Health Informatics, openehr and tagged , , , , , , . Bookmark the permalink.

5 Responses to Detailed Clinical Models (DCMs) – some basic facts

  1. Pingback: ICMCC News Page » Detailed Clinical Models (DCMs) – some basic facts

  2. Peter Jordan says:

    On the practical issue of how ‘incompatible’ standards can formally work together, there do appear to be (Ocean) products that can export data stored in openEHR-compliant EHRs as CDA documents and import the contents of CDAs into those EHRs. To what extent would you say that this illustrates that these 2 standards can work together – particularly given their different Data Types and Information Models? Is it actually possible or practical to serialise openEHR Templates directly to CDA documents, or does this have to be done at lower levels?

    • wolandscat says:

      Peter,

      There are such products, including made by Ocean. The point is that they can perform specific mappings, and there is quite an expensive framework to control the transformation. Each new transformation still requires new manual work of some kind, mainly due to the design of the RIM in the case of CDA (the HL7v3 data types also cause a lot of difficulties it as to be said – solutions to that are being furiously debated right now).

      There will probably never be a magic tool that will automatically convert never-before-seen CDAs to something else, assuming they are ‘templated’, because CDA templates are XSD schema restrictions and can also be very hard to computationally reason about (doing any serious modelling in XSD is contra-indicated – see James Clark on Relax NG particularly the bit on inheritance, and also this XML design page for why).

      Anyway, the point is that if such things are going to be done, the formal transformations must be understood and described, and the costs must be understood. For standards that are not well designed, it is rare to be able to find a single transformer algorithm; usually specific plug-ins have to be written for each new target.

      In general, my experience is that some standards can be made to ‘work together’, but it is never free. Not planning for this has cost (for example) the NHS CfH programme very dearly.

      BTW, one way to reduce the CDA problem would be to generate CDA schemas from openEHR tooling – such schemas are guaranteed to be transformable, because they would obey further rules, rather than just being manually built as is the usual case.

  3. Now, if only the formal governance of the openEHR foundation would become more community-focused and the licencing of the openEHR-hosted archetypes would become CC-BY instead of the contageous CC-BY-SA, then perhaps government programs could take the the years of experience and the wonderful technology-part of openEHR seriously instead of having to opt for less tested formal standards…

    • wolandscat says:

      Yep, I for one am working hard on that one, and will not stop until CC-BY is agreed and other aspects of governance are improved.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s