I looked for a relatively simple actual example of a score calculation, that is a bit more complex than the Apgar score. I found the Motricity Index. It’s a couple of simple sums, with two sub-scores, a summed total, and an average of the two scores as its final score. With the exception that the result of 33 + 33 + 33 is defined as 100 instead of 99. Below I added a simple visualization of the archetype and the rule, because it is slightly easier to read than the rules. All the elements are ordinals, except for the summed scores, which are DV_COUNTs.
This is a visualization of an ADL 2 archetype, I uploaded it as openEHR-EHR-OBSERVATION.motricity_index.v1.0.0.adls (22.9 KB)
Note that here some fields are both used as input and output bindings at the same time, and it assumes that the rules are evaluated from top to bottom. Whether this is correct according to the standard is impossible to say, since the execution model is not defined, but it is how we interpreted it.
Some observations:
- using subscores that make sense as a separate score in the model, that are also used to compute a total score is very common. That means there needs to be some kind of way to express that, for example with both input and output bindings at the same time
- naming the input/output in different languages is obviously useful in many places, but in archetypes specifically, I wonder how useful these are - they could also be auto-generated from the archetype, as shown in the visualisation. For CDS/GDL that is obviously very different.
- names for the tags for rules in many languages could actually be useful, as well as custom messages to show in language if validations defined in rules are failing.
- some earlier versions of a new syntax for this expression language did not allow for variables, only direct path bindings. This example would be a problem without variables.
- It could be a good idea to explicitly bind these rules to specific parts of the archetype, with the semantics ‘these should be executed and valid for every occurrences in this part of this archetype’. This could be as simple as defining a for_all block around all these rules, saying it’s for all events in the motricity score. Note that in these cases, it could still be required to use values outside the given scope, at least as long as they are single valued or processed with some operation or function that accepts lists.
But we probably need agreement on the following in order to agree on working on this:
- A clear list of use cases for these
- A list of goals we want to achieve
- A number of people actually wanting to help write and implement a new standard.
Without those being present, I find a new language very hard to justify.