For many years, there has been a little-used capability in ADL which enables basic expressions to be stated such as the following in the Apgar Observation archetype:


/score_sum/: /data[id3]/events[id4]/data[id2]/items[id26]/value[id44]/magnitude = /data[id3]/events[id4]/data[id2]/items[id6]/value[id40]/value + /data[id3]/events[id4]/data[id2]/items[id10]/value[id39]/value + /data[id3]/events[id4]/data[id2]/items[id14]/value[id41]/value + /data[id3]/events[id4]/data[id2]/items[id18]/value[id42]/value + /data[id3]/events[id4]/data[id2]/items[id22]/value[id43]/value

where all those paths point to the various Apgar leaf data values, i.e. total, heart rate etc.

This kind of statement is intended to assert that the total value = the sum of the 5 elements, as per the Apgar formula. However, it was never that clear that it is an assertion, not a value-setting formula, which might also be something we want.

It's also not very readable, even if the paths were rendered with a tool, they are long and painful to read.

Another kind of assertion was to for conditional mandation of some part of the data depending on some other data element (or more generally, an expression), e.g.


/data[id2]/items[id21]/items[id15]/value[id50]/defining_code *matches *{[at19]} *implies exists */data[id2]/items[id21]/items[id20]

Here the logical intention is to mandate that the data at the second path, which is about details of transfer (i.e. discharge to other care) if the value of the datum at the first path, which is 'type of separation' = at19|transfer|. Other examples are mandating data containing details of tobacco use if the value of the data item 'tobacco use' /= at44|non-user|.

This also is not that easy to read, or clear in its intentions.

More recently, as part of the development of a simple expression language that can be used across openEHR (archetypes, Task Planning, GDL etc), I proposed some key improvements to expressions in archetypes, namely:

 * symbolic names for paths, done by bindings
 * an explicit 'check' instruction to make the intention of assertion
 * a defined() predicate to replace the use of 'exists'

Examples of how these changes look are shown here in the working copy of the ADL2 spec <>. In this form, the above Apgar example becomes:

*check *$apgar_total_value = $apgar_heartrate_value + $apgar_breathing_value + $apgar_reflex_value + $apgar_muscle_value + $apgar_colour_value


    content_bindings = <
        ["apgar_breathing_value"] = <"/data[id3]/events[id4]/data[id2]/items[id10]/value[id39]/value">         ["apgar_heartrate_value"] = <"/data[id3]/events[id4]/data[id2]/items[id6]/value[id40]/value">         ["apgar_muscle_value"] = <"/data[id3]/events[id4]/data[id2]/items[id14]/value[id41]/value">         ["apgar_reflex_value"] = <"/data[id3]/events[id4]/data[id2]/items[id18]/value[id42]/value">         ["apgar_colour_value"] = <"/data[id3]/events[id4]/data[id2]/items[id22]/value[id43]/value">         ["apgar_total_value"] = <"/data[id3]/events[id4]/data[id2]/items[id26]/value[id44]/magnitude">

And the smoking example is:

*check *$is_smoker = *True **implies **defined *($smoking_details)

Note that this does not address the possible requirement of being able to state a formula that /sets /a field, or defines a purely computed value at a path.

We are still working on details of the expression language, variable binding idea and so on. I am interested in feedback on the approach shown in the spec, preferably provided here in the first instance.

- thomas

openEHR-technical mailing list

Reply via email to