What is a pathway? (in human and computer terms)

Continuing the discussion from HL7 UK Roadshow 2016:

@karen.j.green it would be amazing if you can share some insight into your pathways work. The term ‘pathways’ often cause great confusion as it is often mixed up with protocols/ guidelines/ ordersets etc… I’m sure it is somehow all related. This is an important concept those and one that needs to be understood before we can create ‘pathway’ functionality into an EPR/ application and or a pathway type API that can help track patients across different oragnisations (and the IT systems that they use)

I always want to see the opposite of paths : goals.


In software engineering we see a lot of systems that are driven by stating a goal and traversing the dependency graph backward.

i.e. Linux package managers ;

  • I want to install this…
  • Which needs these libraries…
  • Which in turn need these libraries


It gets more complex : dependencies are stated in broader terms than just one package that satisfies them. The relationship might say “this package, as long as it’s newer than version 2.01”. Or “a package that provides Java”. And some packages say things like “you can install this, but not alongside that”.

I get the feeling that this is more flexible and easier to declare than the front-facing approach that I’ve always seen in pathways.


  • I want my diabetic patient to be discharged
  • This means their blood glucose needs to be controlled
    • For this you need success in a “pathlet” that says it “controls blood glucose”
      • Metformin
      • Insulin
      • Weight loss

Afraid you’ve lost me!

Fair enough, what is your background? Clinical, technical … ?

When a person and a health care prof decide the person then they are put on a
patient pathway to sort it
The patient pathway, like the person, is unique and can be identified by the
patient pathway identifier (converted unique booking reference number)
The patient pathway will be of a type I.e. a care pathway (bit like a template)
Care activity can be recorded against a patient pathway rather than just the NHS
number, this helps sort out what has become a mess I.e. loads of health activity
data just dumped into a bucket
Patient pathways cross different care settings e.g hospitals and those that app
lay to social care
Hope that makes sense

@clive.spindley I think it is fair to say that I’m a technically switched on Doctor.

I completely get your what you mean by having a Pathway ID that can be linked to the particular care activity. For eg. a cancer OP appt can be linked to a Pathway ID for a cancer pathway, scans, blood tests, chemo and so forth.

The tricky bit is when the pathway becomes a bit of like process map. For example one that can be represented by a BPMN diagram. Gets even worse then there are different actors and the progression on the steps on the pathway is conditional.

For eg. 2ww cancer referral -> Triage -> If scans done already go to [1] else go to [2]
-> [1] book OPA
-> [2] book scan -> have scan -> go to [1]

You get the idea. And each point of the pathway can act as a trigger. For eg. once scan is done, inform MDT coordinator via an email.

And then of course the same activity can be related to two pathways! For eg. a patient with two cancers, on two pathways can have the same Holistic Needs Assessment, so then a HNA will have two pathways IDs?

Maybe I’m complicating matters! IMHO, BPMN provides most of the requirements for a pathway modelling specification on which a pathway tool/ service can be based on.

I think we’re all describing the same thing…

We seem to have gravitated to what I would call workflow/Business Process Engine. I was thinking ‘are we describing BPMN2 system’ and a little bit of Business Rules.

Example BPMN for generic referral workflow. Would a pathway be part of that?

Wouldn’t it be the other way round, i.e. the referral and possibly others would be part of a pathway (e.g. for a specific cancer care) The referral might initiate it a pathway, or the diagnosis event for a specific condition might initiate the pathway.

My understanding is that many clinical pathways are too complex for modelling using eg. BPMN to be feasible. Possible yes but very hard and time consuming. Even what seems on the face of it to be a simple paper administrative workflow in the real world gets really complex when you start considering all the edge cases and exceptions. At LTHT we found attempting to model the inpatient electronic discharge process as a simple flowchart was unfeasible, and that it was best represented as a state machine. You can model the high level flow like that e-Referral example like that but when you get into the detail it gets messy.

I was reading on Camunda’s BPMN (Real Life BPMN 2.0 book). They split processes up into several parts, first one being the generic process - something simple that everyone grasps (as in my previous diagram).
This gets broken down into two main areas one for the process engineers and one for the technical. They are similar but not the same.

Maybe you don’t need to model the edge cases or go into too much, they may make the diagram so complex it fails to get the simple model across? [Model the 20% that occurs 80+% of the time].

I think @adrian.wilkins is onto something with making the distinction between ‘imperative’ process mapping - where you map a pathway in terms of a fixed series of things that happen in a fixed order, and ‘declarative’ process mapping, in which you state the end point you want, and let the system figure out what needs to be done to get you there.

The difference is, that if I am being declarative, and I say the ‘end point’ of this stage of treatment is to get the patient to their first cancer MDT, then I just state ‘get them to MDT’.

The system knows that before they can go to MDT, the patient will need

  • to have had a CT scan, and the results back
  • to have had blood tests, and the results back
  • booking for MDT made
  • transport booking

And it will arrange these with the appropriate intervals.

It has several advantages in that it allows for complete concurrency of the tasks, and if a new pre-MDT requirement is added, this is easy to add and doesn’t require re-mapping of the process to find out where the new bit fits in.

It also probably encourages us to think of “small, reusable units of process” rather than heroically trying to map the entirety of cancer care onto one great big BPMN chart.

We need a domain specific language for declarative care planning. @adrian.wilkins - up for it?

My background is a medical degree, a short spell in the clinical trenches, and 17 years experience in healthcare IT on both private and public sides of the fence.

I’ve been hearing the noun “pathway” throughout those 17 years but have yet to see a compelling implementation…

Looks like a point in favour of declarative vs imperative process…

A declarative system could catch this ; if say, your conditions were “must have a recent Holistic Needs Assessment report on file”, the report for the first pathway would satisfy the second without having to be repeated.

This reminds me of what’s called a “promise” in certain protocol libraries ; if your first goal declaration is processed and creates a promise that there will be a HNA report, then second goal declaration can pick this promise up and run with it, rather than having to create it’s own promise, so even if the HNA assessment hasn’t happened yet, the second goal declaration can still make use of the units the first declaration is being met with.

I’d be tempted to start with some Graphviz dot / digraph files just to illustrate the point ; we could definitely illustrate @wongwaikeong’s point that two goals could have their steps merged (in the case of Graphviz, just by merging the list of relationships). It doesn’t seem a complex thing to specify in that the core of it is “this thing needs these things”. I’d probably just go for one of the existing base dialects : YAML seems a nice fit - it looks a lot like the Debian package control file which is the basis of this notion.

Package: parted
Version: 1.4.24-4
Section: admin
Priority: optional
Architecture: i386
Depends: e2fsprogs (>= 1.27-2), libc6 (>= 2.2.4-4), libncurses5 (>= \
5.2.20020112a-1), libparted1.4 (>= 1.4.13+14pre1), libreadline4 (>= \
4.2a-4), libuuid1
Suggests: parted-doc
Conflicts: fsresize
Replaces: fsresize
Installed-Size: 76
Maintainer: Timshel Knoll <timshel@debian.org>
Description: The GNU Parted disk partition resizing program
 GNU Parted is a program that allows you to create, destroy,
 resize, move and copy hard disk partitions. This is useful
 for creating space for new operating systems, reorganizing
 disk usage, and copying data to new hard disks.
 This package contains the Parted binary and manual page.
 Parted currently supports DOS, Mac, Sun, BSD, GPT and PC98
 disklabels/partition tables, as well as a 'loop' (raw disk)
 type which allows use on RAID/LVM. Filesystems supported are
 ext2, ext3, FAT (FAT16 and FAT32) and linux-swap. Parted can
 also detect HFS (Mac OS), JFS, NTFS, ReiserFS, UFS and XFS
 filesystems, but cannot create/remove/resize/check these
 filesystems yet.
 The nature of this software means that any bugs could cause
 massive data loss. While there are no known bugs at the moment,
 they could exist, so please back up all important files before
 running it, and do so at your own risk.

I’ve also heard the term “pathway” discussed and debated more times than I
like to recall.
The challenge is that if you get clinical/IT folk in a room to try to agree
the definition of a “care plan” or “care pathway” you’ll get a different
definition every time.
Such is the state of maturity of the art/science of informatics, we have
some distance to go to get a common language between the
clinical/management/technical folk that need to be involved.

Having looked at this in the past, if you want to delve into pathways I
would draw attention to a few things.
“Designing Guideline-based Workflow-integrated Electronic Health Records”
& a related (brief) paper here

I would suggest that pathway material generally involves crafting a blend
of people + process + information + technology.
One way of explaining it, which Barretto does so well in her thesis is that
the information elements involve a mix of
#WHAT needs to be done (clinical content, ie archetypes/EHR content)
#WHY (rules , such as IF, ELSE etc… rules engine)
#WHO #WHEN (workflow/task management … workflow engine)
So to support any 1 pathway could require quite a bit of kit… IF you
are trying to support pathway(s) at scale…otherwise you’d hack something
together… that won’t scale ;o)

To start that journey, many of us focus on the WHAT first … the clinical
content… which usually closely relates to the clinical process.
One other nugget is that typical business process analysis/management (eg
BPMN) usually explores a change from the Physical As-Is … to Physical
If you look at healthcare with those eyes you see a dizzying variety of
What is missing is the fractal patterns of generic/logical clinical process
that underpin the breadth of healthcare…
So whats needed to make sense of this space is a generic/logical modelling
layer is needed in the middle…
Physical As Is
+Logical As Is
+Logical To Be
Physical To Be

That search for logical/generic clinical process support led me to openEHR,
which has 4 core/generic process-oriented classes (Observation, Evaluation,
Instruction & Action) which is why openEHR imho is the critical foundation
layer we are currently building out… the more fanciful/sophisticated
“pathway” support can come later…

More related writings here…

Hope that helps>hinders.


Sorry about the #Shouting… not sure why that happened!

Great conversation.

@tony.shannon are you doing this as part of Ripple?

I think this can be very exciting. Next steps?

Yes we are building this thinking into Ripple.

Next steps are to get the Usability and Clinical Content (openEHR)
Foundations right… the workflow & rules engine will come later…

See this article on the UI/integration/openEHR Foundations here

So for example for openCancer we should get base clinical content up before
adding those bells/whistles…imho


I like the shouty part.

Do you envisage the WHAT openEHR being both clinical and technical? Could we put the clinical content in pdf format - I know this removes features and not the where we’d want to go but it’s practical. (Many trusts just moving from paper).

What do you mean by this? the PDF carrying the structured info (an openEHR composition) in it’s metadata somehow as XML/JSON, does it support that?? Or the generation of a PDF from an openEHR template?

The latter is just and application issue and not part of the openEHR spec per se.

I believe Kev means rendering the structured content into a human readable formatted PDF document. as CDA supports both structured and unstructured payloads.
@mayfield.g.kev What kind of use case are you referring to, an electronic workflow notification to a clinician containing a readable attachment containing the clinical info? In case the recipient clinician is using a non-EHR compliant system. That would sound useful.

@wongwaikeong If this sort of thing is outside the scope of the openEHR spec I would say it limits its usefulness in the messaging space. It would require wrappers/headers from another messaging format to implement. I wouldn’t say it is purely an application issue, it is one of interoperability infrastructure. That is off topic for this thread though.