Stream: fhirpath
Topic: Nested where statements
Simone Heckmann (Sep 17 2019 at 16:33):
...are they allowed, and if they are, how can the expression in the inner statement refer to the current element of the outer statement?
Chris Moesel (Sep 17 2019 at 17:17):
Can you provide a more concrete example of what you're trying to do (e.g., demonstrating what you mean by "nested" where statements)?
Simone Heckmann (Sep 17 2019 at 18:05):
I stumbled over it by trying to get a list of all mustSupport Elements on a Profile, which was quite straight-forward:
StructureDefinition.snapshot.element.where(mustSupport = true).path
which gave me a collection like this:
- Claim.status - Claim.subType - Claim.patient - Claim.created - Claim.insurer - Claim.insurer.identifier - Claim.organization - Claim.organization.identifier - Claim.related
But the purpose of the list was to estimate the complexity of implementation and for that, I'd want to get rid of the duplicates, like
- Claim.insurer
- Claim.insurer.identifier
means youactually only have to implement Claim.insurer.identifier, whereas Claim.insurer is just a bit higher up in the hierarchy.
Of course that could be easily accomplished outside FHIRPath, but I got curious about whether it was possible to do with a FHIRPath statement by testing for each element in the Collection whether it was a substring of any other element of the collection, and the only way I could come up with to do that was with a nested where...
Simone Heckmann (Sep 17 2019 at 18:13):
it would have been something like
StructureDefinition.snapshot.element.where(
mustSupport = true
and StructureDefinition.snapshot.element.where(
mustSupport=true and path.startsWith($this)).exists().not())
...except this could only work if I could somehow make $this resolve to the current element of the outer loop...
I admit, that this use case is weird and could be easily solved outside FHIRPath, but I got curious because the spec doesn't say anything about nesting...
edit: sorry, took a couple of edits for this expression to reflect what I'm trying to do
Ewout Kramer (Sep 17 2019 at 20:05):
To make this work, we'd need to introduce lambda syntax. We've so far avoided that, since it would add complexity to the grammar and type system. E.g. when we added the aggregate function. Anyway, if we would add lambda's it could look like:
......where( $outer -> mustSupport = true and ...... part.startsWith($outer)....
This would be a natural extension, though, since internally, my parser is treating the current where in FHIR path as
....where ( $this -> .....)
Chris Moesel (Sep 17 2019 at 20:26):
To add to @Ewout Kramer's comments, this is supported in CQL queries and the underlying ELM -- so it seems there should be a way forward (given the relationship between CQL/ELM and FHIRPath). I like Ewout's syntax.
Grahame Grieve (Sep 18 2019 at 09:38):
and you can't implement without having stack of contexts, so this doesn't seem radical to name them
Last updated: Apr 12 2022 at 19:14 UTC
