A step towards visual clinical programming

Specifications Task Planning/GDL
1

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.

2 Likes
2

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: Blockly for openEHR projects

(Not sure if i interpreted the ā€œELSE IFā€-marked section correctly above though, maybe it should say something elseā€¦)

1 Like
3

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.

4

Iā€™ve pushed up a version of the examples 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!

1 Like