About the Synapta.org category

Archived Categories Synapta.org
1

##Welcome to the Synapta forum.

The discussion is for anyone interested in how digital workflow, pathways and clinical decision support can be of help to healthcare, from both a technical and practical view.

Our community is for discussing issues such as (but of course not limited to):

  • the challenges of developing, sharing and using clinical pathways.
  • working out how best to represent clinical workflows in a digital way.
  • how can we make practical improvements to processes and how can we best use clinical decision support.
  • questioning whether we are actually helping patients and asking if tech makes a genuine difference to care of patients and service users?

Join via the Synapta Community website here.

Synapta.org.uk

2

What is the starting point for Synapta in terms of publishing artefacts? I imagine some of the following:

  • a scope statement
  • some example requirements / use cases, e.g. types of care pathway and workflow
  • some sort of statement about assumed technical platform, models, representation etc
  • something about methodology of ‘modelling’ Synapta Care pathways, if there is (to be) such a thing
  • some actual models
  • some tools
  • eventually, some proof of concept implementations that consume the models and do something with them

Is this the sort of thing people are thinking about, or am I off course here?

3

Thanks Tom.

You imagine correctly, I think and that looks like a good start.

We have the intimidating pleasure of a blank canvas and we can decide where we think our efforts should be directed.

There might be a call to set out high level goals and aims at this early stage, but there is something to be said for starting in the ‘messy middle’ and getting on with it; i.e. based on the most pressing real-world problems that don’t have an adequate solution that we might be able to supply.

My real aims for Synapta include establishing / developing a sound, evolving theoretical basis for clinical workflow, process and CDS in the practical world, so anything we do should be tempered ideally by that.

I’m saying this in the sense that enthusiastic pragmatism alone, without the benefit of a supporting theoretical framework or model will just run into problems with the usual issues of scale, combinatorial complexity and interoperability, etc, in the end, as you know well.

Hopefully, Synapta contributors will help us find the necessary balance.

Mark

4

I don’t think we have a blank canvas, rather one that’s be painted over many times. In this are we have a classic case or “the good thing about standards is that there are so many to choose from”

I agree to become involved in Synapta because the model for an open platform I’ve been promoting has a requirement for an open, shareable, computable format to represent work-flows, care plans, care pathways and decision support rules and heuristics. There are some contenders for various bits of this space: BPMN, openEHR GDL, Drools, ProForma , ISO 13940:2015, etc. There have also been a number of attempts to use proprietary solutions of which the most notable was the failed attempt of the NPfIT to use Map of Medicine.

The scope here is wide. We might usefully try and refine what we mean by the words we use:

For me work-flow and care pathway are equivalent terms with the only difference being that work-flows can apply to any business process while care pathways are simple a sub-set of all work-flows where the business process happens to be the business of delivering care. I don’t see any requirements for care pathways that are unique to the domain - Am I right?

Clinical Decision support tools are those things that help clinicians make decision and might be used standalone (with the pathway in the clinicians head) or at the decision points of a formally represented care pathway.

Both CDS and Pathways can be very simple or very complex. While there are examples of complex decision making in other domains care processes are rich in complex decisions that are not tractable to the sort of rule-based deterministic approaches typical of generic tools.

One key issue for me is the extent to which we want to try automate complex decision making - There is a history of engineers spending too much effort trying to getting machines to do badly what people do well, in the hope of creating systems that can replace clinicians rather than focussing on how the technology can support the decision making process.

As to where we start I would suggest that it should be with some simple workflows, typical of new models of care, that there’s no support for in current systems.

e.g. I have seen a patient in a GP extended hours service, taken some blood and order some tests (using system A). I want to handover the review of the results when they arrive to the patients in-hours named GP (using System B) - I don’t want to know the outcome, but I do want to know that if the review doesn’t happen there will be an appropriate escalation to, say a care manager in a hub (using System C)

Food for thought?

Ewan

5

@ewan it is interesting to read your post because one of the conclusions
from the OpenOdonto user research is the clinicians quickly realised that
as part of building a new dental system “there are some things we need to
code and there are some things we should NOT code”. We also realised that
we are not alone in our thinking either…

For example, evidence shows clinicians generally base their decisions on
‘mindlines’—internalised and collectively reinforced tacit guidelines. The
user research undertaken as part of the OpenOdonto project confirms this
human based approach is a key part of community dentistry. I would go so
far as agree with the authors of this systematic review that ‘mindlines’
used by clinicians rightly challenge the naĂŻve rationalist view of
knowledge implicit in some EBM.

Furthermore, the OpenOdonto user research also highlighted the importance
of flexibility and value based judgements in clinical care. We found one
of the key roles of a community dental clinician was to synthesise
information and make complex clinical decisions. For example, every day
clinicians make best interest decision on behalf of a patient who doesn’t
have capacity to consent to treatment. This is a complex, decision making
process requiring flexibility and value judgement. Humans can do this well
but it takes time (and requires conversations with a variety of people to
do it well) and also in some way challenges the misguided view that
“doctors will eventually be replaced by computers”. However, we did
realised there were a whole host of other tasks (the ‘thankless tasks’)
that dentists waste time doing and that computers could do better/faster
for us. This article on the importance of values in evidence based
medicine, highlights the need to move beyond slavishly following evidence
based guidelines as part of clinical care

Thoughts?

Becky

Community Dentist / OpenOdonto Founder

6

Hi Ewan,
I have observed a certain obsession over the years by engineers and CS types who love to dream of making computers do medicine. I have warned many groups that that is not the main game (even though I am myself an engineer), and that instead we are in the game of using computer support to soak up common errors that occur in human workflows, lus add some value e.g.:

  • missed steps due to fatigue, hurrying, new / trainee staff; change of team member - e.g. by creating a check-list/sign off approach
  • missed handoffs of patients among team members, e.g. in UK, end-of-life and other innately multi-sector care - address e.g by modelling team communication network and tracking notifications, escalating unresponded-to notifications etc
  • supporting of fine-grained activity-based costing (may not be so big in UK, but it is important in parts of Europe and US).
  • create EHR documentation as a side-effect of the workflow executing. This corresponds to a goal of reducing time/annoyance of writing EHR documentation, especially for routine hospital nurse care
  • invoking appropriate CDS as an aid at appropriate point in a workflow

and so on.

I’ve noted elsewhere that I am working with an R&D team on workflow at Intermountain Healthcare in Utah, and they are looking at computational approaches to represent ‘adaptive workflows’ (i.e. ones where exceptions to the original definition have to be tolerated while running) and ‘cooperative workflows’ (multi-actor workflows. We’ve chosen some example use cases: intubation, cannulation, which are checklist style nurse workflows. We are also looking at simple clinic visit admin workflows to manage patients arriving at a large clinic and minimising waiting times; this may be doable with straight BPMN. So far we are fairly sure that BPMN won’t deal with workflows that have exceptions that can’t be planned for, at least not without modifications. This is what we are currently working on.

All of this is designed to work as a support to clinicians, and not get in their way, but help them not forget basic things (e.g. cleaning cannula, wound area, etc), and also (importantly) to make EHR recording easier and quicker.

The Intermountain group has a concept of an ‘Activity’ as the unit of work in a workflow. An ‘Activity’ has the following structure so far:

Activity:

Data Domain
    semantic models i.e. CEMs/archetypes = openEHR template
    + lifecycle state
    + potentially activity instance state
    + potentially queries to retrieve the data set
    ?+ transformation meta-data to enable tx to various operational formats
Presentation
    mostly derived from Domain
Workflow
Costing activity-based costing data e.g.:
    ICD codes
    consumed resources
    charge master ids?
    probably needs some expression logic
Qualification
    who can do this task? = conditions on Participations & roles (= Activity subjects / actors)
Invariants
    general dispatch (activation) criteria w.r.t. Activity targets / objects
?Scheduling
    when it has to be done, or frequency
Action
    e.g. notifications on completion, reaching a given state
?Escalation
    may be attribute of owning WF

This is just to give an idea of where they are at. They see the execution of an Activity as being intimately related to reading and writing data from the EHR, hence the core information being represented as something like openEHR templates.

This is ongoing research, and they are doing experiments in software, models etc, so things will change over time. As part of the team, I will be able to share outputs with this group if there is interest.

There are of course many other groups working on these things, and I think we need a research survey/tracking activity to be occurring. There is a lot of work around ProForma for example.

But we also need to make some choices. This is why I think we should potentially at least describe the scope, pick some example pathways / workflows and start to describe what our idea of a ‘good’ working system for these cases might be. And then work back to determining some architectural choices.

One of the things I am most keen on is that workflows / care pathways will be able to be modelled by clinical people using dedicated tools, and these definitions can be managed independently of particular deployment technology, more or less like archetypes. So we need to solve some representation questions (GDL is a simple version for guidelines), but we don’t have to solve the whole WF execution space in the same hit.

7

BTW I use ‘we’ here to mean the general community; I didn’t mean to imply anything specific about Synapta :slight_smile:

8

I agree wholeheartedly with the comment about workflows / pathways being modeled by clinicians using dedicated tools, independent of technology and resembling (or actually being) archetypes.

… I have begun to think of these as archetypes for quite a while now.

9

@beckywassall Becky, thanks for your thoughts here. I think the mindlines concept is really interesting. It echoes what I have been thinking and also heard from others on the point that rigidity of expression, or an expectation of some kind of rigid adherence is unrealistic and usually leads to failure.

As clinicians, we are constantly interpreting all guidelines, pathways , rules and instructions in a flexible way according to our human, professional knowledge, training and experience. Plus higher concepts like professional duty or obligation.

The linguistic science people refer to ‘pragmatics’ as the study of what is really meant or intended by an expression, beyond its literal semantic meaning or the meaning of its parts. This can vary a lot with context even when the literal syntax or semantics haven’t changed.

Computable knowledge must have a way of encoding or recognizing that flexible or adaptive quality Tom is referring to below, so that it can give the results we intend.

I remember being taught early on at in school in computing that computers can only do exactly what you tell them to and we haven’t manage to get away from that problem yet.

1 Like
10

… so the canvas is ‘pseudo blank’ … or just a mess? :grin:

11

@ewan I meant to say something about whether health is special w.r.t. workflows or not. I think qualitatively probably not - for every type of workflow in health there is probably an equivalent in another domain. But the ubiquity of a) exceptions / unexpected events b) team coordination coupled with c) severity of consequences of failure make health a bit special in my view. E.g. forgetting to clean piston rings before putting them back in will probably cause extra wear in the cylinder, but noone’s going to care that much. Forgetting to clean a canula or other device before insertion into the patient’s body can have extreme consequences for the patient, which is why ‘infection control’ is a whole sub-domain of its own.

I would be very interested to see some sort of scoping statements - either categorical or via a choice of exemplar care pathways / workflows intended to be addressed.

12

Very interesting reading the thread. Clearly it is imperative to understand and define scope and principals. Assuming that this is well underway (or at least there is a well founded, if not desperate community working to develop scope and principals), to my mind one of the key challenges is establishing the funding that will enable these principals and scope to be realised within a reasonable timeframe. Being a relative new comer into healthcare, I am over-awed by the somewhat glacial speed that NHS decision making works at, and am most keen that this workflow initiative can beat the odds, and progress at a healthy pace!!
Certainly I see that there needs to be concerted effort to identify, communicate and proselytize the huge benefit of open workflow solutions to people in control of funds that can be directed towards early development and implementation.
I believe this is main stream with Synapta’s objectives, and would very much encourage engagement and dialogue with the wider community to undertake activities to facilitate this, that will lead to funding to support Synapta’s aims, which i believe represents an increasing broad community of front line clinicians.

13

I had a think about what adaptive workflow means.

It occurred to me that it might be less about exceptions to the definition and more about the expressiveness of the workflow definition language and the scope of the execution technology.

At the moment I am thinking that for any given intended goal, that it relates to the ability of an execution technology to deliver a desired or optimal outcome under conditions of uncertainty and that it is a continuously varying ability. i.e. the greater the adaptive ability of the workflow execution pathway, then the more likely it is to deliver the outcome under an increasingly wide range of uncertain conditions.

I haven’t found much on Adaptive Workflow, but I’ve put a bit more on the Synapta Wiki here.

14

That’s quite an interesting thought about rigidity of workflows (being bound to concrete technology) being a source of non-adaptiveness. I don’t think it’s exactly adaptiveness (in the at-runtime sense) you are talking about here, I think it is something like ‘applicability’, i.e. an abstractly defined workflow definition can be deployed in a wider gamut of technology situations than one built for just one environment.

So I think we are talking about a distinct but important property here, one which we have not really discussed on the ABD team, but which I will share with them.

15

It is an interesting thought; the notion of applicability seems to raise more questions.

On a human level, doctors are expected to exercise their expertise under all reasonably foreseeable circumstances and to apply higher professional guiding principles (e.g. seek knowledge, share with a colleague, first do no harm, etc) when unsure what to do or how to do it. It means that medical knowledge can be expected to have wide applicability, but only in the hands of a skilled practitioner.

Also, doctors communicate to achieve these aims between each other using medical shorthand and jargon, backed up by long training and shared cultural and medical concepts.

I don’t think we need to worry too much about workflows in the more demanding situations yet, although that’s why CDS is relevant - to help make potentially difficult decisions. But we will also need to be mindful of the environments in which our ‘ordinary’ or ‘simple’ workflows will run, where as an intelligent human, we already have the capability to solve a given straightforward business process problem.

One of my particular aims with Synapta is to create a capability for workflows which are themselves interoperable. Interoperable workflows would imply that the ‘pragmatic’ meaning (i.e. ‘real’ or ‘intended’ meaning in the sense used in linguistic science) is captured and preserved consistently for use by all organisations, systems or agents involved in executing the flow (e.g. just as doctors have a shared medical model). It would work where the systems used by participating organisations are different. This would be separate from the syntax and semantics of the data itself.

To achieve that, the ‘pragmatic’ desired outcome would need to be expressed logically and would be independent of the task sequence (workflow) devised to achieve the goal. One way to do this would be to employ autonomous system agents to undertake some or all of the execution along the workflow. Each agent (including in different systems handing over to each other) would query, check, commit, declare and respond against / to other agents and the independently stored logic / current world state, working together to achieve the desired outcome.

Put like this, it sounds complicated, but my understanding is that the technology now exists to do it.

16

We certainly should be creating interoperable workflow definitions, and a flexible execution approach. That’s the ‘model-based’ approach after all. A base level of being able to do this is the archetype approach to model the data and basic workflow (orders etc) separately from downstream implementation technologies - and that is the approach being used by the Intermountain ABD group. Unfortunately, this approach is not popular with the FHIR crowd these days. It now seems hard to convince people working on e-health interoperability today of the most basic thing in the world - a separation of domain semantic modelling from concrete implementation mechanism.
I like the autonomous agent idea.