Stream: fhirpath
Topic: constraint on optional field
Nick George (Feb 25 2022 at 20:29):
A lot of resources have a name field, and a warning regex that name.matches('[A-Z]([A-Za-z0-9_]){0,254}')
My validation engine barfs on this when name is absent, because it says that this expression evaluates to {} which is not true.
Should this expression instead be name.exists() implies name.matches('[A-Z]([A-Za-z0-9_]){0,254}') ?
Nick George (Feb 25 2022 at 20:29):
Ex.: http://hl7.org/fhir/plandefinition-definitions.html#PlanDefinition
Nick George (Feb 25 2022 at 20:33):
Or else put the constraint on name rather than the root element
Lloyd McKenzie (Feb 25 2022 at 21:46):
As far as I can tell, this only exists on Questionnaire. And yes, it should be fixed. We can catch it in R4B if you submit a change request ASAP :)
Nick George (Feb 25 2022 at 22:06):
I saw it on a number of resources... did you see the plan def link I posted?
Nick George (Feb 25 2022 at 22:06):
will post a change request
Bryn Rhodes (Feb 25 2022 at 22:13):
Yeah, it's present on all the canonicals, it's inherited from the base pattern.
Lloyd McKenzie (Feb 25 2022 at 22:14):
In most places it has some funky escaping in the source, which is why my search didn't find it.
Nick George (Feb 25 2022 at 22:16):
filed https://jira.hl7.org/browse/FHIR-36127 with a list of affected resources (as identified by my engine)
Nick George (Feb 25 2022 at 22:17):
Bryn - not sure I follow about inhereited - the expression exists on root elements, not on canonical
Nick George (Feb 25 2022 at 22:18):
also name is a string, not a canonical? sorry if I misunderstand you
Bryn Rhodes (Feb 25 2022 at 22:20):
I just mean that it's defined on the CanonicalResource that is the "base" for all the canonical resources:
https://build.fhir.org/canonicalresource.html#invs
Bryn Rhodes (Feb 25 2022 at 22:20):
So it's not really "inherited" per se, but that's the root definition of that invariant.
Nick George (Feb 25 2022 at 22:22):
huh #TIL
Brian Postlethwaite (Feb 26 2022 at 06:02):
And also another example of why I don't like {} not being interpreted as true.
Brian Postlethwaite (Mar 08 2022 at 19:24):
(@Lloyd McKenzie this one)
Lloyd McKenzie (Mar 08 2022 at 19:30):
The presumption that "{}" equates to "false" creates issues with Questionnaire.enableWhen. If you have an enableWhen statement of "@1970=@1970-12-15", it's much safer for that to evaluate to 'true' than to 'false'.
Lloyd McKenzie (Mar 08 2022 at 19:30):
But right now, it evaluates to {}, which means 'false'.
Chris Moesel (Mar 08 2022 at 21:07):
An empty list ({}) means there is not enough information to assess if it is true or false (i.e., it means "maybe"). Sometimes you might want to treat "maybe" as true, but other times you might want to treat it as false. I personally think it makes sense to default to false.
If you want {} to be treated as true, then you can modify your expression to enforce that. To take Lloyd's example, you could do:
(@1970 = @1970-12-15).allTrue()
Since allTrue() is defined to return true on an empty list ({}), this would get you the behavior you want.
Or you could be a little more explicit if you prefer:
(@1970 = @1970-12-15) or (@1970 = @1970-12-15).empty()
Grahame Grieve (Mar 10 2022 at 19:31):
this has come up repeatedly. That constraint is wrong and problematic
Lloyd McKenzie (Mar 10 2022 at 20:04):
The extension has a tracker item to fix (assigned to me)
Last updated: Apr 12 2022 at 19:14 UTC
