Stream: conformance
Topic: when are invariants triggered
Patrick Werner (Jul 23 2021 at 13:52):
I have an odd validation issue with an invariant on an Extension: i get an error in Java, but not in .net.
Lloyd McKenzie (Jul 23 2021 at 13:53):
Specifics?
Patrick Werner (Jul 23 2021 at 13:53):
It is an extension from the german base profiles: https://simplifier.net/basisprofil-de-r4/genderamtlichde which contains an invariant:
%resource.where(gender='other').exists()
Patrick Werner (Jul 23 2021 at 13:54):
If i dont have the Extension in an Instance and gender is NOT other: Java validator throws the error, .Net accepts it.
Patrick Werner (Jul 23 2021 at 13:55):
To me it seems, that .Net evaluates the expression only if in the instance the field is populated. The Java Validater evaluates the invariant independent from wheter the instance uses the extension?
Patrick Werner (Jul 23 2021 at 13:56):
I tried to get the correct behaviour from the FHIR spec, but wasn't succesfull.
Patrick Werner (Jul 23 2021 at 15:27):
To reproduce:
java
java -jar ~/Downloads/validator_cli.jar 'https://simplifier.net/isik/relatedperson-example/$download?format=json' -version 4.0 -ig de.gematik.isik-basismodul#1.0.0
will show an error
.net
https://simplifier.net/isik/relatedperson-example/$validate
won't complain about the invariant contained in an extension
used invariant inside an gender extension: %resource.where(gender='other').exists()
Lloyd McKenzie (Jul 23 2021 at 15:28):
Is the error one you would expect? I.e. is it the Java or .NET implementation that need fixing (or both)?
Patrick Werner (Jul 23 2021 at 15:28):
any ideas why? @Grahame Grieve @Ewout Kramer
The only thing in the spec about the correct behaviour was
"Expression : A FHIRPath expression that must evaluate to true when run on the element"
Patrick Werner (Jul 23 2021 at 15:28):
Which is ambigous to me
Patrick Werner (Jul 23 2021 at 15:29):
Lloyd McKenzie said:
Is the error one you would expect? I.e. is it the Java or .NET implementation that need fixing (or both)?
so i would say: i don't know?
Patrick Werner (Jul 23 2021 at 15:31):
i was thinking, that .Net is right here, and invariants are only invoked if the element on which the invariant is placed is present in an instance.
Patrick Werner (Jul 23 2021 at 15:31):
but now i'm not so sure anymore.
Patrick Werner (Jul 23 2021 at 15:33):
i tried to recreate a very simple example, placing an invariant on Patient.name.given, works in .net:
https://simplifier.net/patrickssandbox/testinstance/$validate
Patrick Werner (Jul 23 2021 at 15:36):
and no error in java.
Patrick Werner (Jul 23 2021 at 15:37):
To me these are 2 issues:
- when does an invariant hast to be run on an element? Always or only if present? I think the latter.
- the java validator evaluates invariants differently if they are part of an extension or part of the profile itself
Lloyd McKenzie (Jul 23 2021 at 15:47):
As I read it again, this does seem like a Java error. Invariants defined in an extension should only fire if the extension profile (based on URL slicing) is determined to apply. Can you submit a tracker issue against the validator?
Patrick Werner (Jul 23 2021 at 17:52):
sure: https://github.com/hapifhir/org.hl7.fhir.core/issues/563
Patrick Werner (Jul 24 2021 at 13:04):
Update: I mixed up the invariant yesterday.
The reason for the error was that the java validator imho does a correct fhirpath interpretation:
invariant: gender='other' implies gender.extension('http://fhir.de/StructureDefinition/gender-amtlich-de').exists()
Patrick Werner (Jul 24 2021 at 13:05):
if gender is missing -> gender = 'other' evaluates to []
Patrick Werner (Jul 24 2021 at 13:05):
[] implies ender.extension('http://fhir.de/StructureDefinition/gender-amtlich-de').exists() only evaluates to true if the right argument evaluates to true.
Patrick Werner (Jul 24 2021 at 13:07):
Will close the issue and start a new thread about the different behaviour of equals in different fhirpath implementations.
Alexander Zautke (Jul 24 2021 at 16:12):
@Patrick Werner I think we need to switch back and forth a bit between the issues. The latest version of the .NET SDK correctly returns an empty collection of the comparison part. However, it will return true for the following statement: {} implies true. If I understand the differences in the FHIRPath engines correctly, the java engine will return an empty collection in this case.
Patrick Werner (Jul 24 2021 at 16:42):
Thanks for the clarification. Will continue in the other thread: https://chat.fhir.org/#narrow/stream/179177-conformance/topic/different.20implementations.3A.20fhirpath.3A.20.5B.5D.20.3D.20'string'
Alexander Zautke (Jul 24 2021 at 16:48):
@Patrick Werner and I continued to debug the issue. All engines, in their latest versions, handle the implies statements with an empty input collection equally
Patrick Werner (Jul 24 2021 at 16:48):
Alexander Zautke said:
{} implies true```. If I understand the differences in the FHIRPath engines correctly, the java engine will return an empty collection in this case.
The java engines returns true and is compliant to the spec as well
Alexander Zautke (Jul 24 2021 at 16:50):
The potentially unexpected issue might be the case where gender is optional, than the result of the statement above depends on the existence of the extension
Patrick Werner (Jul 24 2021 at 16:54):
exactly
Alexander Zautke (Jul 24 2021 at 17:13):
As {} and false results in false, adding gender.exists() to the expression, should fix this
Ewout Kramer (Jul 27 2021 at 11:14):
For reference: http://hl7.org/fhirpath/#implies
Ewout Kramer (Jul 27 2021 at 11:15):
So, yes, {} implies true == true.
Ewout Kramer (Jul 27 2021 at 11:15):
If my memory serves me correctly, we added explicit unit tests to the FhirPath test suites at the beginning of 2020, so it seems these resulted in the latest versions of the engines aligning on this (if I understand Alex and Patrick correctly).
Patrick Werner (Jul 31 2021 at 13:02):
Correct. Only issue was Simplifier using an older/different .net version.
Last updated: Apr 12 2022 at 19:14 UTC
