Models from Intermountain Health – pioneering lessons

I am back this week from a week in Salt Lake City, visiting Dr Stan Huff’s group at Intermountain Health, a globally recognised centre of excellence for clinical computing. I should have been 10 years ago, but better late than never. Stan has quietly been pioneering model-based health computing for nearly 20 years, featuring Clinical Element Models (CEMs) and terminology.

Intermountain / Caradigm CEM browser

It started with the ASN.1 models used in the (still deployed) 3M system, and progressed through the CEML form (a light-weight XML format developed by Joey Coyle, who just submitted a PhD thesis on the topic) to the current CDL format. CDL stands for Constraint Definition Language, and was co-developed by GE and Intermountain for the Qualibria product.

One of the key lessons I get from looking into the computing environment in some detail is that they have largely eschewed de jure standards, and just developed ‘stuff that works’. This is not to say that Stan and others have not been active in e-health standards. Quite the opposite, Stan is a past  chair of HL7, a core developer of the LOINC terminology, is very well known on the standards scene, and has recently set up the Clinical Information Modelling Initiative (CIMI), a quasi-standards forum for developing content models. As some readers may be aware, although I support the concept of standardisation, I have little time for most currently available de jure health informatics standards, other than a few tried and tested ones like HL7v2.x (in heavy use at Intermountain). It is more important to actually make things work, and by doing that, you work out what can be standardised. So hats off to Intermountain for going that route.

Obviously I can’t describe nearly two decades of development at Intermountain in the space available here, and in any case I only know bits and pieces. But one way others can get some understanding of what exists there is by a comparison with archetypes and the related formalisms and models. What is truly amazing is the similarities in the technologies – which have grown up in near isolation over the years (archetypes started life in about 1997, so there is no doubt that Stan’s work started earlier). If only we had known! (or maybe done better research 😉 In any case, one advantage of ‘splendid isolation’ is being able to observe parallel evolution. If two groups trying to solve the same problem both home in on essentially the same non-trivial architecture, then it says something important. Have a look at the table below. For those who know anything about archetypes, you will understand that the parallels are not superficial. You can see CEMs in this online browser, and archetypes in the Clinical Knowledge Manager (CKM).

Intermountain CEMs compared to openEHR archetypingThere are some things CDL and CEMs don’t do, including binding to arbitrary terminologies, support for other natural languages, block structuring and co-occurrence constraints, but these differences are minor compared to the common features. During my time there,  I discovered a couple of things ADL doesn’t do. Now we can build on that knowledge to improve it further.

This is of course not the first contact with Stan’s group and CEMs. My clinical colleagues at Ocean, including Dr Heather Leslie and Dr Sam Heard had a long series of calls with Intermountain in the last few years, designed to analyse the clinical aspects of CEMs and archetypes and to try to draw conclusions about where to go next on both sides. My visit there now enables us to understand better the technical aspects of the models (and they are technical), and will enable the next stages of collaboration.

One of the main reasons for the visit was to find out if and how CEMs could be converted into ADL archetypes and vice versa, and how that could help Intermountain – e.g. access to more tools and externally developed archetypes – as well as the international community – by providing access to Intermountain’s 6,000 CEMs, in a directly consumable form. We have done sufficient preliminary work to know that conversions of various kinds are possible, and now it is a case of doing some software experimentation. This is underway, and I’ll post interesting outcomes (by agreement with Intermountain) as they appear.

I believe the key goal in health informatics remains computable patient-centric health records. If we can achieve that, everything else will have already been achieved, including proper use of terminology, interfacing decision support to patient records, querying and secondary use computing. And clinical professionals can start to use their brains on what counts, knowing they can rely on IT to do what it can do well. One day. Maybe… Working more closely with Intermountain Health will surely accelerate this process.

My thanks to Stan (Intermountain Healthcare), Tom Oniki (GE/Caradigm), Alan James (GE/Caradigm), Todd Stevenson (GE/Caradigm), Joey Coyle (Intermountain Healthcare), and Craig Parker (Intermountain Healthcare) for the warm welcome and a great work experience.


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.

2 Responses to Models from Intermountain Health – pioneering lessons

  1. Eric Browne says:

    Great, informative post – thanks!

    Several questions spring to mind.

    1. ~6,000 CEMS at Intermountain Health implies a diverse range of systems that have been, are, or are intended to be supported. How can we learn from the implementation experiences involved in transforming specifications – information model, CDL, datatypes, terminologies, into working systems? Are the systems that deploy CEMs all bespoke, built by Intermountain Health?

    2. What can you say about the querying, if any, and the queryability of data in systems based on the Intermountain architecture and how does this compare with AQL?

    • wolandscat says:

      The 6,000 models = approximately 6,000 single data points. The CEM environment uses a kind of atom-combining method to make useful groups of things. The deployed systems include the 3M ASN.1-driven system. Qualibria is in test at the moment. Terminology is under total control, and probably a bit over-used – it could be separated out into various knowledge resources, including model ontology, general ontology server, clinical terminology, drug dictionary, and other things.

      Since modelling is in-house at Intermountain, governance is pretty informal, which has some impact on the CEMs – it’s why archetypes are larger governance units – because of the open governance situation in openEHR-land.

      I think querying is probably the main point of comparison, and I have not yet studied it at Intermountain that closely. There is no AQL equivalent yet. However, querying in the 3M system is helped by the use of blobbing in persistence (i.e. that enables more OO-like and non-table-based querying); in the CDL models used in Qualibria, there is a model-based path referencing system which leads naturally to an OQL-like querying approach, which is/was under development for the product. Like us, they realised long ago that querying needed to be on the basis of the content models, not on today’s relational table schemas.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your 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