Stream: fhirpath
Topic: FHIRPath constraints
Aaron Nash (Jan 16 2020 at 20:41):
Hi, I have a question about FHIRPath constraints. When a constraint evaluates to an empty collection does that imply that the constraint is not satisfied (i.e. should it be treated as if it evaluated to false)?
Specifically, FHIR's Bundle.entry has a constraint, fullUrl.contains('/_history/').not(), that will evaluate to an empty collection when fullUrl is not specified on the entry. In this case, I believe I have to treat the empty collection the same as "true" since transactions and batches aren't required to have a fullUrl. However, this goes against my intuition that constraints should explicitly evaluate to true in order to be considered satisfied.
Grahame Grieve (Jan 17 2020 at 00:17):
empty collection is false, and I think that expression is in error.
Aaron Nash (Jan 17 2020 at 17:38):
Thank you, Grahame. I'm new to the FHIR community. Are there any steps I can take to help fix the constraint in the spec?
Lloyd McKenzie (Jan 17 2020 at 17:50):
You can sign up to HL7's Jira site (http://jira.hl7.org) and submit a change request here: https://jira.hl7.org/projects/FHIR
Aaron Nash (Jan 17 2020 at 20:35):
Reported: https://jira.hl7.org/browse/FHIR-25525
Nik Klassen (Jan 29 2020 at 19:46):
We are running into this again in some other places. Consider Questionnaire.name. The constraint on this field is name.matches('[A-Z]([A-Za-z0-9_]){0,254}')
in FHIRPath, but in XPath it's not(exists(f:name/@value)) or matches(f:name/@value, '[A-Z]([A-Za-z0-9_]){0,254}')
. To me this shows pretty clearly that the FHIRPath should have an exists()
check. In the case mentioned previously by Aaron, the XPath is not(exists(f:fullUrl[contains(string(@value), '/_history/')]))
. Again XPath has an exists()
check and FHIRPath does not. It is possible that there are more examples in the StructureDefinitions of XPath treating missing fields correctly with exists()
where FHIRPath does not?
Grahame Grieve (Jan 29 2020 at 20:00):
it is possible
Nik Klassen (Jan 29 2020 at 20:38):
Is the best thing to do just file bugs for every expression we find?
Grahame Grieve (Jan 29 2020 at 20:45):
sure is
Eric Prud'hommeaux (Jun 18 2021 at 04:41):
are constraint[n].expression and are constraint[n].xpath both tested? should one (presumably the former) be considered authoritative?
Eric Prud'hommeaux (Jun 18 2021 at 04:42):
I assume that .expression gets code-gen'd into java classes for run-time checks and .xpath is only used if you're e.g. building schematron rules
Grahame Grieve (Jun 18 2021 at 04:47):
expression is authoritative. We can say things using FHIRpath that aren't possible in XPath, and also, XPath only applies the XML serialization
Eric Prud'hommeaux (Jun 18 2021 at 04:48):
ack. is .xpath tested or is it caveat emptor?
Grahame Grieve (Jun 18 2021 at 04:49):
not tested to the same degree. I think I parse them all, but I'm not sure that they are correct statements
Eric Prud'hommeaux (Jun 18 2021 at 04:53):
i can imagine that .expression is compiled into java code which is executed during ingestion in hapi, which is then tested against the corpus of examples.
i can also imagine that the .xpath is translated into Schematron, which could be tested against the corpus of XML examples, but probably isn't.
Eric Prud'hommeaux (Jun 18 2021 at 04:53):
those seem about right?
Grahame Grieve (Jun 18 2021 at 05:06):
close: not compiled; there's a run time engine that executes FHIRPath
Schematron is generated, yes. And I do test it, but somehow the testing is deficient because people report expression issues that they don't against the FHIRPath - so inspecting my testing is on the to do list
Lloyd McKenzie (Jun 24 2021 at 17:37):
I have on occasion (generally before a publication) run the XSLT that results from the XPath schematrons through Saxon SA (when I happen to have a licensed version that doesn't blow up on our schemas). That at least checks that the elements and paths we're navigating are legitimate. It doesn't check that the rules are enforced correctly though.
Last updated: Apr 12 2022 at 19:14 UTC