One of the basic elements of design common to all workflow languages, including YAWL and BPMN, is the inclusion of logical expressions on decision nodes. This seems harmless, and we followed it in openEHR’s Task Planning specifications. However, it is clear that this is a basic error, and that any workflow containing such expressions is unmaintainable and semantically unreliable.
Colleagues in e-health often say to me: why don’t you make openEHR easier to map to <insert popular interop standard> (used to be HL7v3, then HL7 CDA, now, HL7 FHIR… DSTU2/3/4/5?).
To which I usually reply: if you are implying there is any easy way to connect to today’s favourite message formalism, there’s not, there are only moderately difficult ways – which is why no-one has an automatic converter.
Following on from various posts in the past, including my 2014 post What is an open platform?, I thought it might be time to post a succinct (as possible) definition of the platform idea, for e-health.
As stated in that post, the key thing to understand about a platform is that it represents progress away from being locked-in to a monolith of fixed commitments, toward an open ecosystem. This is true both technologically and economically.
The above shows a typical web form calculator for the CHA2DS2-VASc score, used for estimating the risk of stroke in patients with non-rheumaticatrial fibrillation (AF), primarily for the purpose of deciding the use of anti-coagulant therapy [Wikipedia].
Nominalism is a philosophical doctrine usually understood to entail a rejection of universals, in favour of the belief that only the concrete exists. Universals are understood as instantiable entities, i.e. something like types. Another flavour of nominalism involves rejection of abstracta, such as mathematical entities, propositions, fictional entities (including possible worlds). You may read about them in the SEP’s rather dull entry on Nominalism in metaphysics.
How close can we get to making a clinical decision logic language look like the published guidelines which it is used to encode?
Below is an openEHR Decision Logic Module (DLM) example, in the current form of the openEHR Decision Language specification currently under development. Why another language? Well I’ll answer that with: show me a language that does this, and we’ll use it instead (e.g. why not ProForma, Arden, GLIF etc?).
Of course this language doesn’t yet solve all the problems, but we are taking two particular challenges seriously:
the problem of ‘subject variables’ (aka ‘curly braces’ or data access problem);
getting the cognitive level of the language as close as possible to the cognitive level of the source materials and authors’ thinking.