Stream: mapping-framework
Topic: Rule Evaluation Order
Justin Pombrio (Jul 26 2019 at 18:02):
In what order are rules applied?
The docs for R3 say "Rules in a group may be applied in any order; there is no sense of sequentially applying one rule after another.". But the docs for R4 don't say anything one way or the other, as far as I've seen.
This seems to me like a very important consideration. If I understand correctly, since fields on target can be overwritten (if it has arity 0..1, and you set it twice), the order that rules are applied can make a big difference: the second rule to be applied could overwrite the result of the first rule. And since rules can have where clauses, it may not be obvious whether two rules might clobber each other, or in what situations. So if the order in which rules are applied is unspecified, then rule authors must be careful not to write overlapping rules, or else the output of the mapping cannot be fully predicted. Is this right?
Grahame Grieve (Jul 26 2019 at 20:10):
yes
Justin Pombrio (Jul 26 2019 at 20:28):
Then I think the docs should say that the rule order is unspecified, and that it's up to rule authors to avoid overlapping rules. (I don't aim to give you a huge list of doc fix-me-ups. My previous comment about trees vs. DAGs is pretty minor. _This_, though, is I think a very important point.)
Grahame Grieve (Jul 26 2019 at 20:33):
can you create a task?
Justin Pombrio (Jul 26 2019 at 20:47):
I'll try!
Justin Pombrio (Jul 29 2019 at 14:29):
Submitted!
Justin Pombrio (Jul 29 2019 at 20:07):
On the same note, I want to strongly recommend that future versions of the mapping spec either (i) fix an order for rule application (first-to-last), or
(ii) design the language in such a way that it can be statically verified whether rules overlap, and disallow overlapping rules. I'm scared by the prospect of health care data being improperly transformed due to subtle evaluation order issues.
Grahame Grieve (Jul 29 2019 at 20:44):
- we do not want to fix the order, else you cannot parallelise the processing.
- I don't think there's any prospect of static verification
- there's places where it's useful to not care about order
Grahame Grieve (Jul 29 2019 at 20:45):
@Keith Duddy
Alexander Zautke (Jul 29 2019 at 20:49):
For repeating elements you already have the list modes available, like 'first' and 'last'. So the you would only need to check for duplicate rules on non-repeating elements
Alexander Zautke (Jul 29 2019 at 20:51):
And if you really wanted to you could define a "guard" function in FHIRPath that does an "exist" check for you before applying a rule
Keith Duddy (Jul 30 2019 at 11:36):
Thanks for the @ mention Grahame, I've been distracted and haven't been following this topic. In the 3 model transformation projects that I've been involved with, the importance of "declarative" rather than "imperative" has been the key to the combination of rules and the ability of a transformation to be refined and added to. Think BASIC line numbering vs function/procedure definition and invocation from anywhere. 3G language compilers/interpreters work out what needs to invoke what in which order, rather than just going from 10 to 20 [to 23 and then] to 30 and then GOTO <somewhere>. The transformation compiler/interpreter needs to deduce from the dependencies between the rules what needs to be executed before the rules on which it depends.
It's always possible to write contradictory rules, or unintentional overwriting of the same content determined by another rule -- in these cases the compiler/interpreter should alert you to the rules that are inconsistent, and refuse to execute until you write a coherent set of rules that work together, rather than just producing a mish-mash output that seems to do what you specify, but in fact is arbitrarily creating bad outputs from your input.
...|<
Keith Duddy (Jul 30 2019 at 11:38):
Or you can just write XSLT transforms on the XML serialisation of FHIR if you want _that_ kind of transformation language....
Last updated: Apr 12 2022 at 19:14 UTC
