Over the last 6 months or so I have been working on two projects, but one theme: implementing computable clinical workflow. For as long as I can remember, ‘workflow’ and ‘process’ are the main words that excite most clinical professionals in health informatics. They get mildly enthused about data, modelling tools, and applications, but what they really want is for the IT layer to help them work with other clinicians and the patient through time. From my point of view, they’ve always been right, but I’ve also thought we needed to get something working in the data layer to even have a chance at solving process.

Today I think we have enough going in terms of a semantic health data platform in openEHR, and some of the smarter EMR systems, such as at Intermountain, Kaiser etc to consider the next layer. Serendipitously, I’ve recently had the chance to concentrate on the process question.

Making workplace processes computable is a huge challenge, and it would be difficult to over-estimate the effort that has gone into it over some decades. There are dozens of process languages and workflow tools, and endless reams of research to cover. In some industries, notably manufacturing, there have been successes, but creating similar solutions for healthcare seems endlessly elusive. Intuitively, it’s not hard to understand why. Most workflow solutions are based on the idea of modelling deterministic processes that can then be performed by agents, i.e. humans, robots, or other devices. This can work well in e.g. car manufacturing, where there are very few unknowns (the amount of time for specialist human welders to finish a weld will vary somewhat for example).

Many of the workflow languages on the market today, typified by the OMG BPMN standard, are designed for exactly this purpose. I would have to say that from my research so far, the YAWL formalism is probably the best attempt available for modelling real world processes, with proper attention (unlike BPMN) to performing agents, exception handling,, declarative definition and mathematical underpinning. (It also has to be said that the book by YAWL’s authors – Modern Business Process Automation: YAWL and its Support Environment is definitive on the topic of workflow).

However when processes are not very deterministic, and unplanned exceptions are common, the model-based process approach doesn’t work so well. Unfortunately healthcare fits this description far more closely than any idea of deterministic control. Further, it seems fairly obvious that non-determinism is only one of a range of factors that contribute to the challenge:

• shifting goals: the patient condition is always changing, so clinicians are always revising the plan for care in real time;
• shifting responsibility: multiple carer and institutional hand-offs are common, which creates a logistical communications and collaboration challenge;
• complexity: information and knowledge complexity and diversity;
• shifting care mandate: the patient him or herself has changing ideas about what they want to happen;
• autonomy: agents in the system (clinicians, patient, others) tend to operate independently, rather than mindlessly following directions from a ‘boss’.

The overall picture of healthcare is described better by theories of complex adaptive systems rather than deterministic models, as discussed by my friend and colleague Dr Tony Shannon on his blog, and by a new wave of experts looking at complexity in health, such as Rouse and Serban in Understanding and Managing the Complexity of Healthcare.

A metaphor for healthcare process: GPS navigation

An appropriate metaphor for the healthcare process during an episode of care is not that of a control system, such as the one that runs a modern dishwashing machine, but as my friend and colleague Bjørn Næss at DIPS suggested recently, the process of GPS navigation. When I thought about this, I realised he was right. When you get in your car, say in a foreign country while on holiday, you put in your destination to the GPS app and start driving. The path to get to the destination appears fully pre-planned and sometimes you go all the way with no deviations from that plan. But what if the goal changes? If the weather turns nasty, the beach may not be the place to go. What if you have to backtrack – perhaps your hotel rings and tells you you forgot your wallet? What if you miss a motorway exit? Then the GPS has to compute a new route. What if the map data don’t include recent roadworks, or if they take you into a dangerous place (such as in the case of Norwegian tourists in Brazil in 2008 who ended up driving straight into one of Rio’s favelas and getting shot)?

The general situation while driving with GPS navigation is that it and you are always working out your route ‘from here’. Now, imagine that instead of the pretty reliable roadmap data we have today in GPS navigation apps, there was a far patchier set of map data, with some well-mapped areas, and others still being worked on by surveyors.

I would argue that GPS navigation, with rough mapping data and changing goals is a better metaphor for healthcare process than deterministic workflow models. We can understand the position of the car on the journey as the position we are currently at in the care process for the patient, for a given episode of care. The clinicians (and patient) are always in the position of plotting a course ‘from here’.

One of the conclusions we can take from this metaphor is that solving clinical process is not just a question of implementing workflow support, but of implementing decision support as well, since completing the journey is full of decisions that determine the next steps. Workflow and decision support are intimately related.

The way I would characterise what we are really trying to build is a patient journey navigation system.

Another problem: multiple cognitive levels

It might be tempting to take the GPS navigation idea and run with it as the basis for some new kind of workflow engine, but healthcare is more complicated than that. We need to consider some other key aspects, the most important of which I would suggest is ‘multiple cognitive levels’ of operation and hence representation.

If you think about the docs, nurses, orderlies, and everyone else who takes care of you during an illness, it might seem that they follow relatively coherent patterns of activity, and indeed, outside trauma situations, this is superficially true. Can’t those routine activities be mapped out and defined in a computable way? As small islands of work, probably. But we need to remember that what those health professionals are doing is always a function of the current care plan, and the care plan (however precise or rough it might be) will change. Doctors can only see so far ahead, and they are most commonly in a position of waiting to see how your body responds to their most recent investigations and interventions. If they are searching for a diagnosis (a la the typical episode of House), then the process can be like a search for a needle in the proverbial haystack with the lights turned out. If you are being treated, they still don’t know how you will react to various drugs, if you will get an infection, suffer bleeding, or even if they themselves will make an error. So whatever passes for the ‘care plan’ is often only as good as today’s information. The care plan itself is a process, not a document.

Even if a care plan were reliable, we need to understand where any kind of care plan might come from. Consider a sepsis patient in hospital. Let’s say noone yet knows that the patient has a bloodstream infection, but is showing various symptoms that the ED department recognises as a risk. In some hospitals, guidelines like the NICE Sepsis Care Pathway will be used as a basis for navigating the problem, getting the order right of activities and minimising risk.

Is the sepsis care pathway the same as a care plan for the patient with sepsis? If so, then if we can represent the care pathway in a computable fashion, we might start to have a basis for implementing the workflow. Unfortunately, things are not so simple. A care pathway is a guideline for a ‘model patient’, created by studying actions and outcomes on numerous real patients and looking for what worked best, and codifying that. When it comes to an actual concrete patient, there are all kinds of other things to consider. What conditions do they have? They may be pregnant, have Alzheimers, or be injured. Perhaps two or more care pathways are implicated. What drugs are they on? The very fact that they, like any human being, have their own phenotype and individual capacity for reaction to drugs or pathogens has to be taken into account.

The general picture is that the care plan for the patient (or there may be more than one) is some potentially complex derivative of the ‘medical knowledge’ level of model patients and model conditions. The responsible physician(s) use their experience, access to standard care pathways and other resources, as well as the observations, test results and history of the patient in front of them to work out what to put in the plan. This sets the destination as per the GPS navigation metaphor, but of course that may change again tomorrow.

As far as I know, there is no generalised description of this relationship, but it is clarifying to know that clinical knowledge such as care pathways and care plans are different levels of representation. We can intuit the following cognitive levels:

• care pathways for conditions ⇒ care plan for an individual ⇒ workflow actions

The people who build guidelines, pathways and other medical knowledge are doing the work of creating something like GPS mapping data along which to navigate in model situations. The treating clinicians who formulate a care plan, which involves setting goals, are choosing a map set, stating the destination and defining some means of undertaking the initial few miles of the journey. And the workflow is the actual journey.

More levels: processes are fractal

A further complexity in the challenge of computerised workflow is the small problem of care processes being fractal in nature. Administering a course of antibiotics orally over 7 days is a very simple process, usually undertaken by the patient. Cannulation is a pretty simple process for a trained nurse. Intubation is a bit more complicated, but still very routine. Stabilising a patient after a major injury might require cannulation, intubation and a whole lot of other smaller processes. The episode of care for such a patient, from arrival in the ambulance to final discharge on crutches is a complex process indeed, consisting of a whole hierarchy of smaller processes. Is it useful to put the steps for cannulation on a screen? Probably not, although check-list proponents might argue that displaying an infection reminder is valuable. But when we get to the stabilisation process, or a condition like sepsis, it’s clear that treating physicians could make various choices about what to do next, and it might be very helpful to have some help – a clinical GPS navigation system – to determine the best direction.

What processes should we formalise?

What level of process should we try and formalise so as to implement such an engine? There are answers to this question, although they are not the most obvious to IT people who tend to think: ‘everything!’

Processes with significant cognitive complexity

A generic criterion for finding clinical processes that can benefit from workflow and decision support is as follows: any ‘process’ that when performed by similarly qualified professionals on similar patients that generates markedly different outcomes is a candidate for process-embedded decision support. Why? Because those similarly-trained professionals are not doing the same thing, even though they are doing ‘proper medicine’. Nevertheless, some of them are making better choices than others, generally without being aware of it. Only dedicated studies can find those better choices and develop the optimal care pathway for the relevant patient condition.

One might think that a proven care pathway for a condition would be included in next year’s medical text on that topic, and that medical students from some point on will know the proper way to treat the patient with the condition. But can we rely on those medical students to learn the whole pathway and execute it perfectly at point of care years later? And what about all of the working medical professionals in circulation today? Can they be trained within their institutions?

Possibly, but there is a confounding factor, to which I referred in a previous post on Intermountain Healthcare’s pioneering work in care pathways – cognitive complexity. While physicians are very smart people, they are just as limited by the 7 ± 2 mental buffer as the rest of us. But many decision points in guidelines for conditions like sepsis contain many more input variables than that. These decision points are clear candidates for decision support – a recommendations co-pilot.

Routine processes and human forgetfulness

There is another well-known source of errors in medicine as well: simple forgetfulness in very routine procedures. When a nurse is on automatic pilot, thinking of skiing with his wife on the weekend, it’s easy to forget one small detail – disinfecting a catheter for example, or to misread a chemotherapy drug dose due to fatigue. Small actions can have severe consequences. So another candidate for processes, or process steps that should be represented in the IT layer are key reminders for completely routine processes that have severe consequences for non-compliance.

Long-running processes with hand-offs & multiple carers

Some kinds of clinical process are routine, but have the complication of being performed by multiple carers in a serial fashion in time, that is to say, the responsibility for the work transfers from one agent to another. This might be within the same care organisation, e.g. inpatient medications administration continuing through multiple nursing shifts, or it might be across enterprises, such as end of life care in which GPs, home carers and hospice or clinic carers are implicated. In these cases, it is clearly going to be of great help to have a representation of a long-running process in the IT layer, whose individual tasks can be viewed, performed and signed off. This is often called a ‘task list’.

Processes that don’t need support

It’s worth asking: are there clinical processes where workflow support isn’t going to bring much value? Some examples come to mind. The process for dealing with cardiac arrest just after cardiac surgery probably isn’t a candidate: it’s a time-critical and life-threatening situation whose resolution is entirely dependent on good training, and with a high rate of survival (around 80%). Routine procedures like intubation, wound dressing, cannulation and so on are probably not going to benefit much either, because in clinical terms they’re fairly deterministic and also logically atomic rather than long-running. In all these cases, the decisional complexity is fairly low, and the process steps and exception handling are generally internalised by training. What we do want to know however is that these processes were performed (or not) within the larger plan of care, so they are likely to be represented as a step or sign-off in some larger process description.

The Case Management paradigm

Other than some islands of order, it doesn’t seem as if the deterministic BPMN workflows so dear to some are the main solution. This realisation is reflected in the more recent paradigm in workflow circles, case management. Case management is a paradigm shift from a control flow mindset to a data-object mindset. Some of the characteristics of processes that can be addressed by the new paradigm (from BPTrends 2009):

• knowledge-intensive
• variability
• long running
• information complexity
• collaboration and coordination
• multiple participants, multiple roles
• cases can be interrelated
• critical nature of timescales
• external events affect cases
• difficulty in gaining visibility of case progress
• strong reporting requirements
• history
• security
• isolated pockets of automation.

Sound familiar don’t they? In medicine, the ‘case’ is represented by the informational state of patient during an episode of care. Luckily we have something that implements this: the longitudinal EHR.

The OMG now has a Case Management Model and Notation (CMMN) standard, although having looked at it in detail I would say it is very early days. But it is the right kind of approach for one part of the problem.

What can we formalise?

The two key questions in all this are: what do we try to formalise and how? We’ve seen that there are various levels of representation, and also various types of process that are likely candidates for IT support.

Clearly there is some hope for formalising medical knowledge and guidelines. We have numerous computable examples already, including medical terminology, ontologies and the many guideline languages, including Arden syntax, ProForma, GLIF, Asbru and so on. And yet, we don’t see routine use of these at point of care: care pathways and guidelines are still mostly published as documents or websites, albeit in reasonably structured natural language, often including visual flow-charts.

There are probably two reasons for this. Consider the NICE Sepsis Care Pathway again, and think what it would take to put all of that into a computable form, say in Arden or ProForma. I suspect it can’t quite be done, which implies that the current guideline languages are not yet sophisticated enough to express everything that is needed. But I’d say they would go close (another approach would be rule-based representation, also powerful, but too big a topic to go into here). I think the primary difficulty isn’t representation, it’s knowing what to do with computable guidelines once we have them. How do we get to a care plan? How do we get to the final workflows of actions that need to be performed by everyone?

The current solution is the same as it was a hundred years ago: the most reliable machine for turning general medical knowledge into actions for a specific patient is … a healthcare professional. We have guidelines in a human-consumable form, we have the EHR or EMR as a recording device for typical pieces of information generated in that process, and we have a few decision support tools (mainly to prevent bad prescribing decisions) but we still lack the GPS navigation co-pilot, or in clinical terms, a coherent care plan concept.

Lastly, we can do something at the task list level. Task list support exists in some EMRs, but to my knowledge, it isn’t integrated with care plans or knowledge artefacts like care pathways.

To summarise, I would argue that the candidates for computable implementation are as follows:

• more accurate representation of the growing library of care pathways that describe best practice for cognitively complex processes – these are ‘standard decision pathways’;
• the process of creating and continually maintaining a care plan from a) internal and external medical knowledge and care pathways and b) current patient state – these are patient-specific decisions;
• task lists for care plan processes containing hand-offs and/or steps where non-compliance (forgetting, wrong dose etc) may have severe consequences – these are patient-specific actions.

 The kind of solution to implement this I would thus characterise as follows: a high-quality EHR and data modelling capability underpinning three layers of process representation: task lists, care planning and care pathways.

Right now the I am working on some careful first steps at the Task List level in openEHR, and at Intermountain Healthcare, on a slightly broader design framework in the Activity-Based Design (ABD) project. I’m working with great teams in both projects, with a huge amount of design, implementation and clinical experience. It’s early days, but I feel optimistic.