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:
*rules*
/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.
*rules*
/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
clearer
* 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
<https://specifications.openehr.org/releases/AM/latest/ADL2.html#_rules_section>.
In this form, the above Apgar example becomes:
*rules*
*check *$apgar_total_value = $apgar_heartrate_value +
$apgar_breathing_value + $apgar_reflex_value + $apgar_muscle_value +
$apgar_colour_value
*data_bindings*
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
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
