For us the main requirement of the rules is to calculate the value of other
fields based on other fields. Only the checking of assertions has relatively
little added value for the use cases our customers encounter. I would find it
very hard to explain to any users or modelers that they can write checks that
do the actual score calculation, but that they cannot actually use the
calculated value anywhere. So we ignore this limitation altogether.
Also the value binding seems to have an case that has not been covered:
it is possible that a single path lookup results in a list of values. This
means a single path-bound variable will contain multiple values (so a list of
values). In the old case, you could handle this with a for_all statement to
express that the assertion should be valid within the scope of a single event,
for all events. How could value binding solve this? The same question applies
to output variable binding as well as input variable binding.
Related to this, both the current and proposed specification is missing
execution rules, especially when paths lookup to a list of values instead of a
single variable and how to handle that. For example what does the following
mean when /data/events/data/items/element[id3]/value/magnitude resolves to more
than one value?
/data/events/data/items/element[id15]/value/magnitude =
/data/events/data/items/element[id3]/value/magnitude + 3
And what if 3 is replaced by another path instead? What if the left hand side
matches one value? And what if it matches more than one? In Archie I
implemented ways to handle these cases by defining the operations on single
values, on equally sized lists and in cases where one value is a list and the
other one is a single value. But unless this is specified, this will be
different for different implementations.
Regards,
Pieter Bos
From: openEHR-technical <openehr-technical-boun...@lists.openehr.org> on behalf
of Thomas Beale <thomas.be...@openehr.org>
Reply-To: For openEHR technical discussions
<openehr-technical@lists.openehr.org>
Date: Friday, 1 February 2019 at 13:01
To: Openehr-Technical <openehr-technical@lists.openehr.org>
Subject: Rules in archetypes - what are the requirements?
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
