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.