A mental reference is fig 4 from the Planning/CDS Overview:
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
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.