How can CIMI ‘standard’ clinical models be created?

In CIMI, we mostly seem to assume two pathways:

• de novo authoring, e.g. with an archetype tool that consumes the CIMI RM
• accession and conversion of external models, e.g. CEMs, openEHR, 13606, R4C, VA, etc

Neither of these is as simple as it sounds, and they are likely to have different outcomes. Below I have tried to tease out some issues in order to think about CIMI’s approach from here on in.

De novo model authoring

This entails getting competent people to work on models of specific kinds of content. A realistic example would be obstetric-related models, which include all basic concepts like vital signs, typical labs, as well as the pregnancy and birth-related content.

The people who can realistically do this are either/or a) clinical professionals b) lab / diagnostics experts c) other healthcare professionals (e.g. admin, allied health, etc). These people have limited time, and by and large are not interested in (to them) the strange line and box models of IT people. They just never know what such pictures are really saying.

For them to work together and actually really produce models means some way to enable the correct kind of discussions to take place, within a tooling / documentation environment that accurately enables recording of what they say. In my knowledge, there are two ways this happens.

Method 1: working in clinical language

The first involves working in the language of clinicians, or something very close to it. Versions of this that have produced a lot of models that clinicians feel comfortable with are:

• Intermountain health, with 6000 models (~ 6000 primary data points). The method of production is organised in face to face workshops led by Dr Stan Huff & colleagues, who act as a clinical/informatics bridge; in the environment are tools and formalisms which enable the CEMs to be formally expressed and displayed for review…
  • model authoring is done by a small group of specialists who are present at the meetings
  • the model formalism (over the years ASN.1, CEML, CDL, CEML2) is powerful and really can express nearly every clinical concept clinicians ask for; it has had 20+ years of refinement
  • models can now be displayed in generated mindmap form
  • the meetings take place regularly and are well-organised and attended
  • data set models are ‘panels’ or ‘collections’ of the more atomic models and developed with the method and tools
• openEHR.org, with ~300 models (taking say openEHR.org + Nehta repositories; about 5000 primary data points). The method of production is fully distributed, and requires a special tool to enable the human interaction…
  • the actual model authoring is done by a relatively small number of people who use tools to build archetypes
  • the formalism (ADL / XADL 1.4, limited ADL/AOM 1.5) is also powerful and like the CEM formalisms has been shaped directly by the clinical modelling activity over many years
  • models can be displayed in ways (mindmaps and pseudo-forms) that clinicians can directly engage with – this helps overcome the lack of face to face & whiteboard discussion
  • ‘reviews’ take the place of meetings, and reviewers can comment on individual data points, with no need to refer to any underlying formalism nor box & line diagrams
  • ‘editors’ are key actors in the process  – they facilitate review rounds and online discussions
  • the model is a social media one, with tooling to back a) the social interactions and b) the model representation
  • data set models (templates) are done by a similar process, with (currently) a slightly different formalism (being replaced by ADL 1.5)
• I don’t have much visibility of the work, but I suspect that where VA with MDHT-based tooling and modelling is achieving some level of efficient model development based on clinical input.
• There are other instances of working processes, e.g. in Nehta, various UK and Scottish NHS projects, and in some places using 13606 as the base reference model. I don’t know how the many different Dutch models get done but I would bet money on the efficient model factories being ones that work somehow like either Intermountain or openEHR.

Method 2: working in technical languages

The other broad approach is that clinical professionals / health informaticists / other domain experts go to standards meetings and try to build models there. The difference in this approach is primarily that the ‘language of interaction’ is the technical language(s) of the SDO, e.g. HL7 RIM, CDA related variants, 13606, and so on. I don’t believe this approach has been anywhere near as successful in terms of outcomes.

What Works…

My point here isn’t about which RMs are better (it’s not a determiner given the fact that Intermountain and openEHR RMs are very different); nor that any of the people or organisations doing modelling in the clinical space are somehow superior to the SDO space. Rather it’s about process. The lesson from the evidence is that without the following:

1. very efficient social interaction
2. of a wide range of competent (and busy) healthcare professionals
3. with the work done in language/formats essentially natural to clinicians – basic mindmaps and/or screen forms
4. and powerful formalisms sitting underneath capturing the numerous difficult requirements, but hidden from view,
5. that can be computationally mapped to the formats referred to in point 3 above

clinical content modelling is just not likely to succeed. I think that the standards meetings approach (primarily HL7, CEN TC251 and ISO TC215) have been very strong on the first two, but weak on number 3. Whether SDOs have been any good at number 4 & 5 is open to debate, but essentially an academic question if no 3 isn’t being achieved. It’s interesting to consider the fact that no lack of clinical professionals has attended SDO meetings. But they are forced to talk UML, RMIMs or other unnatural and mal-adapted formalisms.

IHTSDO is probably a special case, but given the more domain-oriented formalisms of SNOMED CT, the number of published sub-sets and ref-sets has been notably low. As for the content model space, I think that is also to do with lack of ways for clinical people to easily engage, rather than anything technical.

I suspect that other approaches that have not functioned particularly efficiently in the past have had to address at least one of the above 5 points to become more successful. I know openEHR started with very limited capability on points 1 and 2, and had to address that or fail.

At this point, I should point out that my colleague Dr Heather Leslie recognised early on the importance of efficient social e-interaction of clinical professionals in making clinical modelling work in an environment when face to face meetings is largely unachievable. On the technical side Sebastian Garde (chief architect of the Clinical Knowledge Manager) has made the flexible collaborative workspace concept a reality on the web, which has indeed proved that e-collaboration for this challenging task is essential.

One point that has slowly been crystallising for me is: none of this will work if reasonable numbers of clinical professionals can’t be involved, i.e. if it relies on a small number of the hyper-talented geek doctors / health informaticists we know and love so well. The fact is – no working MD knows everything or even that much about the details of clinical practice in areas they don’t currently work in. Everything’s changing, all the time, and there is a massive level of specialisation in clinical medicine. The ‘language of modelling’ simply can’t be an IT one.

Challenges for CIMI

I’m not here to criticise the standards organisations or anyone else, just to say that if we are really serious about developing shared clinical models in CIMI, and showing the world how to do it, we need to explicitly state under what circumstances we think it can be done. I think it is defined more or less by the above 5 points; others may be able to develop a better theory. Whatever the case, we need a common understanding of this.

Assuming the MO is agreed to be something like the above, CIMI needs to organise itself around certain challenges corresponding the above needs:

1. Efficient social interaction: an online social media environment will be needed, since there is no realistic hope of getting the relevant people routinely into f2f meetings
2. Attracting the relevant healthcare (not IT) professionals means several things:
   • making it clear that CIMI can talk healthcare professional ‘language’; this means models being visible online in completely natural formats that HCPs can interact with
   • providing ways for very busy professionals to efficiently review and comment on very specific data items they know about with essentially no tool or formalism learning requirements
   • demonstrating a path from the models to actual real benefit in the clinial computing realm – i.e. demonstrating a translational pathway
     
3. Actually having the technical means to represent models on the screen in HCP-friendly formats that really are formally connected with the underlying definitions
4. Actually having a powerful underlying formalism that can
   • represent all the requirements
   • enable both clinical interaction at development time,
   • and translate (somehow) into implementation.

Notice that I have not included requirements like ‘able to deal with any reference model’ etc. The reality is that working clinical professionals have no interest in technical information models – they are interested in only one thing: the final clinical semantics. Of course there is another raft of requirements to do with RMs and so on, but I don’t think that they matter if the above cannot be achieved.

Model Conversion – realistic?

A whole other theory of creating ‘CIMI models’ is based on the idea of importing ‘models’ from existing modelling environments of all kinds, no matter what under what process, formalism or other circumstances they were created (think: HL7v2 messages; CCR; Kaiser Permanente RMIMs, Microsoft HealthVault definitions etc). The attraction is justifiable – the clinical knowledge lying around in even the most difficult-to-engage-with models of the past is of undoubtedly huge value.

The question is: how should / could this model development path be operationalised? Is it even possible?

There appear to be two routes:

• the one technologists dream of – automated conversion of models from their native form to the target CIMI formalism
• reuse of requirements and design by inspection and remodelling

The first involves unavoidably complex semantic mapping technology. Many of us like to think it’s just a matter of ‘doing the work’, but the reality is that most such efforts have failed in the past. I personally think that it can succeed only in the specific case where:

• the source formalisms are sufficiently powerful and generic, like CEML, CDL, ADL (arguably XML Schema 1.1 +/- schematron);
• care has been taken to separate the domain content semantics from messaging other other technical attributes

Otherwise I think the only route is the second one: inspection and de novo development of CIMI models based on design reuse. Which means at some point entering the de novo modelling process above, just with a head-start on requirements. Even where batch conversion can be achieved in limited circumstances, I think that the resulting models will be useless unless heavily reviewed and undoubtedly modified..

So in my view machine model conversion directly to clinical models in the final CIMI formalism+patterns is only marginally applicable – an enabler that can potentially accelerate some model development, in a few specific cases.

Instead I think we should be looking mainly at extracting mindmaps and design meta-data from other extant models and using that as the semi-formal starting point for model development.

Conclusions

Eventually all successful model development will wind up in the ‘de novo modelling’ pathway. I would go so far as to say that approaches that fail to take notice of the above criteria will fail.

My thoughts on how CIMI can really succeed from here:

• seriously consider how a CKM-like environment is going to be created for CIMI as soon as possible;
• use the mindmap + meta-data path + design reuse for extracting value from the majority of models;
• realise the importance of modelling methodology that will enable clinical experts to design, build, review and maintain CIMI models within a CIMI collaboration environment – look primarily at the evidence of  how clinicians do this in the existing clinical modelling communities.

The short story is: machine transformation is of limited value; it’s time for collaborative online model building – both new and based on existing designs.