Thanks Pieter,
this is very useful.
On 01/02/2019 12:54, Pieter Bos wrote:
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.
the obvious solution to that requirement seems to be to a) use functions
and b) to allow assignment:
*rules
* -- assert that manually set total is correct
*check *$apgar_total_value == apgar_total ($apgar_heartrate_value,
$apgar_breathing_value, $apgar_reflex_value, $apgar_muscle_value,
$apgar_colour_value)
*rules
* -- assign total value
$apgar_total_value = apgar_total ($apgar_heartrate_value,
$apgar_breathing_value, $apgar_reflex_value, $apgar_muscle_value,
$apgar_colour_value)
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.
conceptually, rules statements are typed, so in this case, the type will
be List<Real> or List<DvQuantity> or whatever. In that case, expressions
need to treat it in the normal way, i.e. with List or Set operators that
obtain single values. E.g.
$systolic_bp_samples: List<Real>
there_exists v in $systolic_bp_samples : v > Systolic_bp_threshold
implies ....
These kinds of things (and for_all) are documented in the Expression
Language draft
<https://specifications.openehr.org/releases/LANG/latest/expression_language.html#_collection_operators>.
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?
I don't see how it can, since that path is defined to be of type Real
(not List<Real> or Set<Real> etc) by the RM definition of DvQuantity.
But I'm probably missing something in the sense of your question...
Anyway, the more I can find out about current requirements, working
solutions, workaround etc, the better - the intention is to evolve the
expression facility in archetypes to match those needs and to be as
useful as possible.
- thomas
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
