Stream: conformance
Topic: STU3: Observation invariant obs-7 broken
Alexander Henket (Jul 13 2018 at 08:51):
I keep running into the same issue with every STU3 validator that does schematron: the implementation of Observation invariant obs-7 is broken. The intent is clear:
obs-7: If code is the same as a component code then the value element associated with the code SHALL NOT be present
But the implementation in schematron is off:
not(exists(f:value)) or not(count(
for $coding in f:code/f:coding
return parent::*/f:component/f:code/f:coding[f:code/@value=$coding/f:code/@value and f:system/@value=$coding/f:system/@value]
)=0)
I'm assuming the fhirpath implementation of "value.empty() or code!=component.code" is correct as I don't see complaints there. Imo the correct implementation in xpath/schematron would be:
not(exists(f:value)) or count(
for $coding in f:code/f:coding
return parent::*/f:component/f:code/f:coding[f:code/@value=$coding/f:code/@value and f:system/@value=$coding/f:system/@value]
)
I can fix my own environment, but if every implementation of FHIR STU3 might have the same issue then interoperability would be a guessing game.
Am I interpreting this correctly? Recommendations?
Jason Walonoski (Jul 13 2018 at 19:11):
I agree, it is broken. I override obs-7 with this java code:
return (obs.hasComponent() && !obs.hasValue()) || (obs.hasValue() && !obs.hasComponent());
Jason Walonoski (Jul 13 2018 at 19:14):
Which probably isn't right either. But I can't figure out what that invariant is supposed to do.
Alexander Henket (Jul 13 2018 at 20:36):
I get the invariant: you don't want the same code in Observation.code and Observation.component.code and potentially have the value in .value and/or .component.value. It is effectively saying that if you 'have to' have the same code in .code and .component.code, the value shall be under component.
Grahame Grieve (Jul 15 2018 at 23:49):
I don't understand the proposed fix, but I don't understand that xpath anyway. @Lloyd McKenzie ?
Lloyd McKenzie (Jul 16 2018 at 02:18):
I agree with getting rid of the not()
Grahame Grieve (Jul 16 2018 at 02:18):
want to fix it?
Lloyd McKenzie (Jul 16 2018 at 02:21):
It looks like R4 is already fixed. This is an R3 issue. What's the mechanism for fixing that?
Grahame Grieve (Jul 16 2018 at 02:32):
wel, the only one is a technical correction, but I think it's not justified in this case
Alexander Henket (Jul 16 2018 at 10:44):
It's in the way for sending/uploading instances from/to Touchstone, @Richard Ettema : would you feel comfortable fixing this one manually?
Alexander Henket (Jul 16 2018 at 10:47):
I don't understand the proposed fix, but I don't understand that xpath anyway.
I'm assuming you do understand the fix and that is a typo. The xpath tests for equivalence of any Observation.code.coding to any Observation.component.coding. I'm assuming you would need to do the same thing upon implementing the fhirpath expression?
Grahame Grieve (Jul 16 2018 at 12:22):
I don't understand why removing =0 makes any useful difference
Richard Ettema (Jul 16 2018 at 13:30):
@Alexander Henket, yes, to support the Nictiz testing use case I can update the STU3 obs-7 invariant. I'll let you know when it's available via JIRA.
Alexander Henket (Jul 16 2018 at 13:45):
@Grahame Grieve it’s not about removing =0 but about removing not(). The way it is, it is a double negative not(count(...)=0)
Alexander Henket (Jul 16 2018 at 13:46):
@Richard Ettema thanks. Now let’s hope no systems we test suffer the same issue.
Lloyd McKenzie (Jul 16 2018 at 23:06):
The =0 still needs to be there. (The removal of the =0 was a typo in Alexander's proposed solution, which makes me feel slightly less bad about getting the original wrong... :))
Alexander Henket (Jul 17 2018 at 08:37):
Ah... now I get the confusion... sorry about that. :-)
Last updated: Apr 12 2022 at 19:14 UTC
