# A step towards visual clinical programming **Category:** [Task Planning/GDL](https://discourse.openehr.org/c/task-planning-gdl/27) **Created:** 2020-08-30 11:17 UTC **Views:** 888 **Replies:** 3 **URL:** https://discourse.openehr.org/t/a-step-towards-visual-clinical-programming/952 --- ## Post #1 by @thomas.beale I have introduced some new syntax ideas into the evolving Decision Logic Module (DLM) language, which is intended to become the formalism for representing next generation GDL guidelines and also decision logic associated with Task Plans. The particular innovation here is to convert what programmers think of as if/then/else chains and also case statements to a tabular approach: ``` rules | | This is a case statement on the variable amniotic_fluid_state | amniotic_fluid_risk: Terminology_term Result := map amniotic_fluid_state ============================================ [premature rupture], [polyhydramnios]: [obstetric_emergency], -------------------------------------------- [oligohydramnios]: [refer_high_risk_care], -------------------------------------------- *: [normal_obstetric_care] ============================================ | | This is an if/then/else chain | hypertension_risk: Terminology_term Result := =========================================================== has_pre_eclampsia or has_eclampsia: [obstetric_emergency], ----------------------------------------------------------- previous_obstetric_hypertension or previous_pre_eclampsia or previous_eclampsia or has_pregnancy_hypertension: [refer_high_risk_care], ----------------------------------------------------------- *: [normal_obstetric_care] =========================================================== | | This is a single Boolean expression | gestational_diabetes_risk: Boolean Result := bmi.in_range ([high]) or previous_macrosomic_baby or previous_gestational_diabetes or family_history_of_diabetes or race_related_diabetes_risk ``` The proposition is that this approach, which is really just a cunning use of certain syntax elements like comment strings (`----` and `====`), and the `'*'` character to mean 'else', allows a way to represent a lot of simple logic in a way very similar to what is found in published guidelines, i.e. as visual tables. The idea (so far) is that the meaning of the text is the same without without the comment lines, which makes life fairly easy for implementers. In the future of course, we will have colourised syntax-sensitive editing and syntax display, as well as GUI tools for those who don't like logic programming. Nevertheless, my thesis at the moment is that if we can get the formal representation very close to the published natural language forms of guidelines, it will be relatively easy for (some) clinical / guidelines experts to do the authoring, with a bit of light training. See [full examples here](https://specifications-test.openehr.org/releases/PROC/latest/tp_examples.html#_rchops21_decision_logic_module). --- ## Post #2 by @erik.sundvall Would allowing if/then/else written inside the -----/==== lines make things better or worse? Perhaps something like ; ``` | | This is an if/then/else chain | hypertension_risk: Terminology_term Result := ==========================[ IF ]========================== has_pre_eclampsia or has_eclampsia: [obstetric_emergency], -----------------------[ ELSE IF ]------------------------- previous_obstetric_hypertension or previous_pre_eclampsia or previous_eclampsia or has_pregnancy_hypertension: [refer_high_risk_care], -------------------------[ ELSE ]-------------------------- *: [normal_obstetric_care] =========================================================== ``` Otherwise (or in addition to the above) using a https://developers.google.com/blockly based editor might be a good idea discussed before in: https://discourse.openehr.org/t/blockly-for-openehr-projects/535 (Not sure if i interpreted the "ELSE IF"-marked section correctly above though, maybe it should say something else...) --- ## Post #3 by @thomas.beale This is a very nice idea. I'll keep it in mind - maybe if we run it past a few people and see what they prefer. I guess the version for a case statement might be: ``` amniotic_fluid_risk: Terminology_term Result := case amniotic_fluid_state ================= [ IN ] ================== [premature rupture], [polyhydramnios]: [obstetric_emergency], --------------- [ ELSE IN ] ---------------- [oligohydramnios]: [refer_high_risk_care], ---------------- [ ELSE ] --------------- *: [normal_obstetric_care] ============================================ ``` What is on the left is formally represented as C_XXX primitive types from the AOM or similar, hence the 'IN'. Not sure if this one is as helpful, but again would need to be tried out on some representative people. --- ## Post #4 by @thomas.beale I've pushed up a [version of the examples](https://specifications-test.openehr.org/releases/PROC/latest/tp_examples.html#_multi_drug_chemotherapy) with both my original and Erik's idea, to give a feel for both. Erik's version makes the logic clearer, but adds a bit of visual noise; my version might have the author staring at the page trying to remember how to recognise when there is a Case v If/then structure. Needs a usability test! --- **Canonical:** https://discourse.openehr.org/t/a-step-towards-visual-clinical-programming/952 **Original content:** https://discourse.openehr.org/t/a-step-towards-visual-clinical-programming/952