Let’s talk about mindmaps and archetypes. Mindmaps seem to be fuzzy and friendly – we need them because they are incredibly efficient at transmitting information to humans. Archetypes seem über-mathematical, but we need them to do proper model-based computing.

Koray Atalag responded to my last post on the NZ Hive blog site (my emphasis):

…I think at this stage this discussion on DCMs need to go into further detail (perhaps on another thread) and that we must specify what we expect from these DCMs and how to achieve that. In my opinion this can be as simple as mindmaps (which definitely does not rely on anything) or on the other end ultimately in the form of archetypes & templates with proper terminology bindings and language translations plus assertions in place. Of course the computability of these artefacts will not be binary; but rather a spectrum. We may not even need a full level of computability (or even semantic interoperability!) as a start – but it is important to start with a proper approach which can then be extended to fulfill future needs. Like as they say for CDA ‘incremental interoperability’ perhaps we should look at a DCM approach which could provide ‘incremental computability’

Power and Beauty

There are a few points to make here. Firstly, we should separate the issue of visualisation is from that of the DCMs formalism and any underlying model. Visualisation is important, because it is about communicating intuitively and efficiently with human beings. Visualisations like mindmap, exemplified in the BP archetype mindmap above, is deceptively powerful. When mindmap software first came out, I did not take it seriously for any modelling purpose because it seemed to lack any rigour. Now it is always the first view I go to on CKM to get the general idea of an archetype. In CKM, just the right amount of formal ‘information’ has been added to make it really useful. Have a careful look above, you can see:

• the data / state / protocol separation, directly from the openEHR Observation / Entry classes (UML);
• the separation of ‘events’ from the data – as per the openEHR History/Events classes (UML);
• hierarchical structure, shown by both the hierarchy icon (next to ‘Location’ in the ‘Data’ group);
• the type of the events, shown by the ‘H’ symbol next to 24 hour average – this symbol corresponds to the ‘Interval’ event type in the UML model above;
• the data type of every leaf, shown by icons like the ‘Q’ (quantity; UML), ‘T’ (text/coded text; UML);

So, contrary to the first bolded statement above, mindmaps can indeed show formal elements – and in a very nice way, suitable both for technical people like me, and clinical people who use these models on a daily basis. Those who look carefully at the UML will realise that the mindmap is abstracting and simplifying just a bit, so as to get the detail / brevity balance right. So let’s not start debating about whether we have to do without formalism in order to communicate models well. We don’t. Further, if we do throw away a proper formal underpinning, mindmaps will go back to being fluffy and relatively meaningless. (And congratulations to the CKM designers for doing such a great design job on CKM mindmap facility).

The need for Expressivity

The above leads into my second point: the need for expressivity. As soon as you start trying to define anything realistic in terms of content, involving e.g. patient state, events in time, actions and states, if the DCM framework doesn’t support it you are instantly paralysed. And the DCMs can only support it if they are connected to some formal basis that supplies these things. Without it, authors have to resort to low-level hacking together of simple ‘nodes’ and connectors just to get to first base. These underlying patterns are the key to being able to efficiently author models that will actually be useful in the real world. That means the authoring side of DCM development does need a formal framework. Can authoring be made visually friendly as well? Well it is clearly going to be more complex, but even the existing Archetype Editor, which is not exactly cutting edge technology, does a pretty reasonable job.

Cut-price computability?

Koray says above “we may not need a full level of computability” with respect to DCM models. Well, that is were we were in about 1996. The problem is that without the ability to express key structural patterns, types, value ranges, and other details, we were stuck. Have a look at the v1.x draft of the archetype language from 2002 – it gives an idea of what we realised we needed to make any progress. The best content modelling tool of the time was the ‘Object Editor’ from CHIME, UCL. Even back in the mid-90s, it had quite a few ‘formal’ elements, all borne out of getting stuck somewhere in an implementation.

The thing about healthcare is that the most banal things, like Glucose Tolerance Test, Orthostatic BP, and Adverse reaction pose serious challenges to computability. We can’t just say, oh let’s leave the computationally hard things till later. Imagine telling a hospital or clinic, sorry, we can’t do OGTT, or any BP with multiple samples, or in fact any time-based data from your ICU devices… let alone typical orders, because we can’t work the state model out. We had to work it out. The many people who have slaved for years in health informatics working out so many things (e.g. the excellent state machine we use in openEHR, taken from Patrice Degoulet’s work, built in turn on the shoulders of…) do so because of this fact: what is simple in health can be seriously difficult to compute.

Tooling for the future

In sum, we need (formal) power, and we need (visual) beauty. I like mindmaps – more than UML in fact. I also like formalisms. Best of all, I like hiding formalisms behind things like mindmaps. In my view, the ultimate tool has:

• a strong formalism;
• a sufficient underlying information model (the patterns);
• a nice visualisation medium – some kind of mindmap on steroids;
• an intuitive model authoring and particularly model reviewing interface.

In openEHR, we have made some progress on these; certainly more is needed, particularly on the last point. However, I think doing less is destined for extremely limited progress.

Here’s another mindmap, just for fun…