Initial attempt at TP v GDL comparison (TB)

The main thing that we have found, and it's true on the ABD workflow project at Intermountain as well - is that care pathways, and things based on them - what we call Task Plans - are a messy mixture of:

Tasks - 'doing' nodes
Decisions - various kinds of decision nodes
data display and capture
EHR commits

The cancer prescription example I showed at Tromso is an edge case example, since it is mostly decision nodes, and could easily (I assume) be encoded by GDL. But that's not the mainstream use case. The main use case looks much more like groups of Task nodes separated by one decision node here, another there and so on (in fact it was a complete surprise to be asked by Moscow to encode a decision graph in TP, but that's what they did...). You can see examples e.g. in the NICE or Intermountain Acute Stroke Management or Sepsis care pathways. I don't think it make sense to try to encode single decision points as GDL guides and then call out to a GDL server to process them - it's much easier to define them inline (as they are defined in the care pathway) and process them locally, because they are logically very simple.

Currently there are three flavours of decision node, and I am not completely sure how they map to GDL yet. You can see them here in the spec. They correspond to if/then/else, switch/case/case, and when/then structures.

Additionally, we need to be able to state which data sets (openEHR templates) need to be displayed and/or captured at various points in time - so we have a bit more flexibility in the model than GDL gives us, because we can state that the data come from templates or other systems entirely, via pure API calls, including to non-openEHR systems, like an MPI system.

I think the main difference is all the different types of Task, Task Group, and Event - see sections 6.2 and 6.4 of the spec. There are 10 kinds of Event.

You might also find section 4 , the Design Principles, useful - the scope is a fair bit larger than GDL - it's really Task- and Work-oriented.

On the other hand, I think what GDL gives us is:

an efficient serialisation of a decision graph that can include references to any archetyped data
a technology that enables decisions/rules based on archetyped data to be easily authored and deployed

Let me know if I missed something (I've read the spec end to end a few times, so I think I understand it).

So I think they are largely for two different kinds of usage - TP enables work to be planned and managed; GDL allows data to be processed to generate inferences based on rules. If TP was used in pure decision mode, it might do the same thing, but I think it's like using a sledgehammer where a nutcracker is needed.

Things that we could do to align:

upgrade the GDL UML model and core semantics to be based on the openEHR BASE components, particularly base types and the new Expression language.
do a review to see if the core decision / rules semantics is the same / close, and try to align some details there
describe formally how to save a pure TP decision graph as a GDL guide, or to import a GDL guide to populate/create a TP work plan (which will just be a decision graph)
try to work out which use cases make sense in each technology.

When we built the TP spec, we certainly were not thinking of replacing GDL, and I don't think we should try to do that today, even though there is a lot of theoretical / formal semantic overlap. In terms of real world use however, the two technologies will serve two different kinds of user and usage. The groups implementing TP are trying to build tools to do in-patient drug administration, surgery planning and other such things. There are a few simple decision nodes, but mainly it is Tasks and timing and events that matter.

GDL, GDL2 (Rong)

I think your analysis is pretty accurate. The scope of v1 GDL is quite narrow, and limited to express clinical logic based on archetypes. GDL guidelines can be linked together to form more complex decision making support. Task planning, events and actions are definitely not in the scope of GDL, 5 years ago. On the other hand, we have never been asked by anyone to represent an entire clinical practice guideline (the only exception is my PhD student Nadim represented acute stroke treatment guidelines for visualization purpose not for execution). Mostly our use cases are about a single moment decision making support in the form of alerts, reminders and simple single screen applications similar to checklist, wizards. I guess the main reason is clinicians don’t expect to get fully automated support, just yet. It’s a lot simpler to design and use a simpler CDS application with very narrow scope than to figure out all kinds of possible variations of complex process support. So I agree with you on that GDL and TP are essentially two different technologies to solve different problems.

Now about GDL v2, as I probably mentioned in Tromsö, the main features are:

FHIR support;
CDS-hooks;
output templates

Adding fhir support is matter of responding to market trends, I just don’t like the idea to maintain a set of fhir mappings and archetypes at same time. CDS-hooks provides several building blocks to build CDS logic as well as a way to integrate remote CDS services with EMR user interface. As I indicated in the specs list, I believe we need something like that in the openEHR space to facilitate integration. The output templates is a way for GDL to produce complex object structure with dynamic values set by the rules. So perhaps from here it starts to look a bit like the actions in TP. In the C3-cloud project, personalized care plans including goals, medications, procedures and appointments are produced by gdl2 guidelines.

Another area we are making progress is to define a way to embed our web-based CDS apps into EMRs, either desktop or web-based. It’s similar perhaps to SMART apps but we don’t rely on fhirs only, and there is a lot more going on to make sure the embedded app works seamlessly with the hosting EMR. Most of the systems we work with have neither fhir or archetypes. It’s not exactly related to GDL or TP but I hope this work will someday be useful for the community.

I have started to document the v2 GDL design, and hopefully will be able to present it to you and the sec team in next face-2-face meeting, perhaps we can host it in Q3 or Q4. The new GDL2 editor is nearly ready, it’s new implementation from group up (not the same code base as the java swing v1 editor).

Future Steps

Finalise standard expression language for GDL and TP
- need to consider if there are when/then rules directly in the language.
Build and publicise a system overview diagram that shows how GDL and TP relate, e.g. something like this, but with GDL and CDS-hooks added.

Tech Qs

Multiple Inheritance - implem.
Review some issues: https://github.com/bjornna/TP-examples/blob/master/issues.adoc
REST API for Task Planning - initial discussion and plan the roadmap
Query language for TP - make a single API for TP related AQL queries?
- this would combine results from the EHR and TP engine

Examples

OpenEHR - TP examples Git repo.
Cambio / Rong

New requirements

generic listener requirement - Ian
notify external party & receipt
CDS / TP relationship - CDS-hooks relatonship; show how it would work
TP REST API - need to make more progress..