DL vs GDL2 - Purpose and difference

Specifications Task Planning/GDL
1

Hi,
I am looking at the new TP & DL specs. I also see GDL and an a bit confused between what DL is for and what GDL is for. If we are building a new CDSS solution in openEHR, should we be using DL or GDL? How will that change if we are developing the decision logic for a TP solution?

regards

1 Like
2

Hi Dileep,
DL is still in development, although we are pretty close to finished on the meta-model. The idea is that it will replace GDL2 expressions & rules. If you look at GDL2 rules, they are serialised in a way that is not easily human readable, they are intended to be read only by tools.

Part of the idea of DL is to provide a human-readable, clear rules language as you can see in the examples. It is also intended to provide some more powerful primitives than GDL2 has, such as functional condition chains and case statements (those are the tabular-looking things you see), and also to build in ranges and ‘currency’.

However, GDL2 also has bindings and ‘output templates’ - it is more or less a fully integrated, fairly simple formalism, and we still have to recreate some of that.

GDL2 will do a lot, and as you probably know is quite widely deployed for some years. It will take care of most ‘single-shot’ rule computation use cases, based on score-like guidelines like CHA2DS2-VASc, qRisk etc. Have a look at the GDL2 guideline library (https://www.openEHR.org/gdl) to get an idea - there are more than 500 of them.

In the future we think GDL2 guidelines should be machine convertible to TP/GDL structures, so there is not reason not to use GDL2 today if it serves the purpose.

If your deployment time scale is longer, then you might want to get involved in the TP/DL work!

@rong.chen , head of Cambio CDS, and creator of GDL2 may have more to say.

1 Like
3

Thanks Thomas,
Just to restate my understanding, If I am starting on a CDSS or WP/TP implementation, I can use GDL2 and then consider migrating to DL later. Alternatively, I can take a calculated risk to choose to go with TP/DL and help mature it in the process.

Couple of more questions

  1. Does GDL2 cover what TP is designed to cover(I guess not)? or only what DL will cover?
  2. If anyone sets out to use TP/DL now what are the areas that they will find lack of clarity? Can we borrow ideas from GDL2 for those?
    On a related note, I would like to get involved in the TP/DL work if that can help in any way. Let me know where I can be of use.

regards

1 Like
4

A mental reference is fig 4 from the Planning/CDS Overview:

plans-rules-data
plans-rules-data699×586 54.5 KB

There is a lot more in TP than was intended in GDL - TP is oriented around ‘plans’, i.e. something like a BPMN view of work items, timing, events, wait states and so on. DL does the rules part. To achieve the data part, the Subject Proxy service is being developed. Thus:

  • TP = the pink part
  • DL = the green part
  • Subject Proxy = the blue part

GDL doesn’t try to do the plan part - it is oriented around rules, data access and generating outputs, so it is a smaller, more integrated formalism, less flexible, but easier to deploy. Its coverage of that diagram is:

  • GDL rules = the green part
  • GDL data bindings = the blue part

I have been the main coordinating architecture of TP, and it has included significant input from groups at DIPS, Better, Cambio, Moscow / Solit-clouds, plus cross-fertilisation from a major ongoing project at Intermountain Healthcare. Better and DIPS have partial TP implementations (and indeed, some quite impressive functionality).

I am also connected fairly closely to BPM+ activities in the US, and am continually scanning this work to incorporate useful ideas and semantics, as well as thinking about model convertibility in the longer term (BPM+ is still ‘emerging’, and 3 of the specs are new drafts).

DL originally emerged as a single expressions and rules language to (hopefully) cover what are currently 4 separate mini-expression languages in openEHR: rules in ADL; AQL expressions; GDL expressions and TP expressions (which, prior to DL, stated the conditions on decision task outgoing paths).

I have worked with @rong.chen on ensuring we cover all the semantics available in GDL2 within TP/DL/SP, and I am pretty confident will will manage this. We will also cover CDS hooks connections at some point. Our intention is to ensure we manage, or get very close to GDL2 → TP/DL via machine upgrade.

The TP/DL specifications work is not moving quickly right now due to many organisations being diverted on Covid19 related activities, however it is proceeding in the background, and as I mentioned before the meta-models (the main architectural definitions) are close to complete (for example, a year ago, we did a major analysis on TP exceptions, adhoc task insertion, and cost tracking).

You will appreciate I am sure that a platform solution for this whole area is still pretty much ‘leading edge’ in healthcare. The industry as a whole has:

  • no agreement on formally representing CPGs / Care pathways / order sets - BPM+; HL7 CQL; openEHR and many others are working on this;
  • no agreement on a standard architecture, but the 3-way split illustrated above (and which I have advocated in US standards circles) is becoming an accepted view, and is pretty much the view of the BPM+ effort. I think the HL7 ‘CPG on FHIR’ activity is coming around to it as well, but of course they are very … FHIR-focussed :wink:

So there is no nice product you can go and buy from anyone that does all this. You can buy a lot of products, mostly proprietary, and/or limited to doing specific functions (which they might do well). The challenges to be solved in this area are among the most difficult in IT I would say.

So, even though you will undoubtedly have needs for right now, a timeframe of the next 2-5 years would be a realistic one for thinking about comprehensive solutions. The TP/DL/SP specs will be complete enough much earlier than that (all specs keep evolving of course). GDL2 does very useful things for right now.

2 Likes
5

Thanks for your detailed reply. I think I am getting a fair picture. All the parts are moving at a fast pace and openEHR TP solutions will also have to evolve continuously over the next 3-5 years to remain aligned to the specs.

regards

6

Good summary @thomas.beale !

@Dileep_V_S please get in touch if you need input on GDL2-based CDS projects, contact me at rong.chen@cambio.se.

7

Thanks @thomas.beale @rong.chen for the offer of help. I will connect separately

regards

8

Hi everyone!

Sorry for opening this forum almost one year later! I am a doctoral student and I have been investigating the use of DL to verify the expressiveness of language in the field of nephrology. I saw in this conversation that a year ago GDL was the best option for short-term projects considering the status of DL. Is the recommendation currently the same or have we advanced to the point where it is safe to use DL instead of GDL for projects that need to be completed in a maximum of 1 year?

Thanks in advance!

9

Hi Ana,
I am not aware of a design specification named DL in the openEHR space. GDL2 is fairly stable specification with solid implementation (editor and execution engine), GDL2-based decision support applications have been in production use for many years in different markets.

For academic projects, it’s definitely feasible to get started with GDL2 and implement certain CDS use cases within a year with publicly available GDL2 Editor (including execution and test engine) and detailed documentation, Guides and Tutorials – CDS Apps

You can even take a look of the open source project that publishes openEHR archetypes and GDL2 guidelines, GitHub - openEHR/gdl-guideline-models: Common clinical models in the forms of openEHR archetypes and GDL guidelines, there are over 600 models now and quite many are in the nephrology area, GitHub - openEHR/gdl-guideline-models: Common clinical models in the forms of openEHR archetypes and GDL guidelines