In the time since I left Ocean Informatics (the company I started with Dr Sam Heard and others in the late 1990s), I have been working with Intermountain Healthcare as well as various other openEHR vendor companies, notably DIPS (Norway) and Marand (central/south-east Europe). With both groups I am working on what could be described as the next layer of the open EHR: process.

For the whole time I have worked in health informatics (24 years and counting), clinical professionals have wanted two things: decision support, and workflow support. Both of these things properly belong to the world of clinical process. It’s taken many years to get a sufficiently good architecture of healthcare data and basic semantics in place to seriously attack process, but we’re ready to go there now. What we need now is a conceptual model of collaborative healthcare delivery during a whole care episode, extending into ongoing care and monitoring, leading to a new architecture for implementing process support.

We know a couple of crucial things at the outset: clinical process is an emergent phenomenon, not a deterministic one; and, any credible solution must be inherently adaptive, i.e. allow changes and exceptions to the clinical workflow during its execution.

An industrial R&D approach: ABD (Intermountain)

At Intermountain Healthcare, I work with the Activity-Based Design (ABD) team led by David Edwards, and lead architect Alan James. This project is doing a combination of academic and implementation-based research to find a model-based approach for formalising clinical process for use at point of care. It builds on the clinical modelling work of Dr Stan Huff and others over the years with the clinical element models (CEMs), which provide the project a basis for building semantic models (equivalent to openEHR archetypes). Now we need to extend this to activity and decision elements, in order to support care teams working with patients over their whole stay.

Doing this properly is not just a case of adopting a workflow tool or diagramming language, as some imagine. Indeed, languages such as BPMN (Business Process Modelling Notation) have been shown to be an ill fit for healthcare, which is characterised by constant exceptions and shifting goals.

In fact, the main challenge is to find a workable conceptual model, and this brings us into the territory of the ABD project owner Dr Brent James, head of clinical quality and research lead on healthcare delivery and medical education at Intermountain, and who has worked for many years on evidence-based clinical protocol development. A conceptual model for informatising healthcare process has to take into account questions like the following.

What can we formalise, i.e. convert to a computable form?

This is a trick question. Before we can formalise, we need to systematise – medicine itself, or at least parts of it, into evidence-based protocols, which can be linked together in Care Pathways. Developing protocols is a challenging activity for which a scientific approach has been pioneered by Dr James at Intermountain (this NYT report on his work is well worth a read) and is being copied in many other places. Intermountain has developed over 50 evidence-based protocols, so it’s one of the best institutions we could hope to be working at for this project. Of course there are many institutions developing formal protocols, for example the UK National Institute of Health and Care Excellence (NICE), which publishes Care Pathways for many conditions including CHF and sepsis. So, there are at least some things we can hope to formalise.

How do we formally express protocols and Care Pathways?

Today, protocols and pathways are expressed in all kinds of special forms, flow diagrams, charts and text. Some elements have been made computable via languages like Arden, Glif, Asbru etc. The big question is whether we can make them fully computable, and if so, what formalism can we use? A promising avenue will probably be a combination of case management, which unlike BPM, assumes the unexpected in process execution, and decision logic, to deal with decision points. There is a lot of prior research, including the various guideline languages and more recent work in business entity lifecycle modelling and case management to draw on (including various OMG standards like BPMN, CMMN, DMN); the challenge is synthesising a workable formalism that can be used with a model-based semantic EHR.

How do we turn Care Pathway(s) into a Care Plan for a real patient?

The next challenge is that a protocol or pathway is for a type of problem, not an actual person. Real patients often don’t have only one problem and even if they do, their personal phenotype will undoubtedly bring unexpected specificities (reactions to drugs for example) into play.

So even if we manage to formalise protocols, which are standardised models of care for a condition, we still need to find a way to use them, or their components, to create something like an ongoing care plan for each individual patient. It’s a bit like a pilot who has to figure out the actual flight based on an original plan, changing weather information, real-time communications with ATC and occasionally problems with the aircraft. This is new territory.

What is the model of cognitive interaction of clinicians with the IT?

One of my own little obsessions in this area is partly born of listening to programmers with little experience of healthcare telling us how easy all this is with BPMN. Just get a BPMN engine, encode the process, and execute it they say. It sometimes takes them a while to understand that it is not the BPMN engine that is going to put drugs into the IV, but real people, and that the ‘process’ is not known in advance, only after the fact.

Nevertheless, even if we think we know better (as per above), we still need to think carefully about the questions:

• when and how do care professionals interact with the IT at point of care?
• How can any computerised workflow support be synchronised with the real world at the bedside?
• Will every single small action require clinician interaction with a screen, or will there only be coarse-grained instructions, like ‘intubate patient’?

The answer to the last one is undoubtedly from the Dr James playbook: if ad hoc (i.e. variable, old school) medicine produces variable outcomes for similar patients in even simple procedures, then that procedure is a candidate for a protocol, and the steps may well need to be signed off at execution time. Recent research on the use of checklists in medicine would seem to indicate the same thing.

This is only one aspect of course. We need to know how to create a user experience that doesn’t slow the care team down and gives them useful information at the right time (only). Current results are already encouraging: ABD has a very nice demonstrable solution for user / screen interaction, including voice recognition, but of course supporting hand-overs, complex decisions and backtracking will be a whole new ballgame.

A Bottom-up approach: openEHR

Outside the ABD project, I spend time on new proposals to augment openEHR to implement … you guessed it, process. In this work, we are starting with a known, fully open EHR architecture which provides a bit of process support, and are looking to add facilities like:

• planned actions
• order sets
• care plans
• managed medications
• reporting

Here I am working with medical and engineering experts from DIPS and Marand, two openEHR implementers who have close relationships to their healthcare provider customers, from where they obtain a continual flow of experience and requirements.

All of the same questions as above apply for openEHR, with the added requirement to integrate the workflow support into the openEHR architecture, rather than having it bolted on the outside. openEHR is a semantic EHR architecture, and already has many features that will greatly aid the work of adding process support, such as its standard state machine for tracking order lifecycle, and its 500+ archetypes (detailed clinical models).

This work proceeds within the wider context of the openEHR community and the openEHR Specification Editorial Committee, which is responsible for the specifications.

The pathway to success

The work described above is very exciting and if we succeed we should have something valuable to offer the clinical care sector: an open architecture for a process-enabled EHR that helps the clinical team take a person needing care from where they are now to a goal state, via an efficient, evidence-based pathway tailored for the patient.

We can think of the approach as being like a GPS navigational system – even correcting for wrong turns and unexpected roadworks. We’ll need to make use of the decades of excellent research in clinical guidelines, pathways, protocols, and decision support, but we have an advantage: both the ABD and openEHR architectures are based on semantic models and terminology rather than fixed database schemas, and are consequently highly flexible and information-rich.

I don’t see this clinical process architecture as something that will ever be ‘finished’, rather it will rely on careful examination of the problem space and extensive implementation based testing. Watch this space!