Stream: conformance
Topic: Modifier Extension mismatch
Grahame Grieve (Mar 08 2022 at 20:45):
I've just found an issue in the FHIR test cases
Grahame Grieve (Mar 08 2022 at 20:46):
<element id="Patient.extension:animal">
<path value="Patient.extension"/>
<sliceName value="animal" />
<short value="Test Extension" />
<min value="0" />
<max value="1" />
<type>
<code value="Extension" />
<profile value="http://hl7.org/fhir/3.0/StructureDefinition/extension-Patient.animal" />
</type>
</element>
Grahame Grieve (Mar 08 2022 at 20:46):
only, that's a modifier
Grahame Grieve (Mar 08 2022 at 20:47):
should the snapshot generator process that, and leave it to the validator to complain, or should it fail with an error? Any opinions?
David Pyke (Mar 08 2022 at 20:47):
I think I'd prefer to let the Validator catch that one.
Josh Mandel (Mar 08 2022 at 20:48):
I think the snapshot generator should bail. Assuming the actual path is Patient.modifierExtension, talking about an Element.path of Patient.extension is wrong and also confusing. (Or if I'm not understanding the story here, I'm confused anyway ;-))
Grahame Grieve (Mar 08 2022 at 20:50):
it is wrong and confusing. The only question I'm asking is where in the tooling stack it should emerge as an issue
Josh Mandel (Mar 08 2022 at 20:50):
Since the input to the snapshot generator is wrong, my perspective is that the snapshot generator should fail (early and loud is good here, and the snapshot generation is upsteam of the validation IIUC).
Josh Mandel (Mar 08 2022 at 20:51):
Otherwise put: snapshots shouldn't define elements that can't exist.
Grahame Grieve (Mar 08 2022 at 20:51):
there's lots of other things that the snapshot generator does not catch because it's task is to generate the snapshot, not validate the profile
David Pyke (Mar 08 2022 at 20:52):
As long as it's valid path, etc., the snapshot generator should accept it and the validator should scream bloody murder
Josh Mandel (Mar 08 2022 at 20:58):
I think I understand better now -- OK, I buy David's position.
Related to the test case: http://hl7.org/fhir/StructureDefinition/patient-animal is defined here and probably shouldn't be (anymore)?
Grahame Grieve (Mar 08 2022 at 20:59):
why not?
Josh Mandel (Mar 08 2022 at 21:00):
Because the backport extension http://hl7.org/fhir/3.0/StructureDefinition/extension-Patient.animal does the same job in a standard way
Josh Mandel (Mar 08 2022 at 21:00):
(Or, again, I'm confused -- increasingly likely ;-))
Grahame Grieve (Mar 08 2022 at 21:02):
well, it might. but the committee decided they wanted to update the definitions and be explicit about some things, and also to mark it not as a modifier
Grahame Grieve (Mar 08 2022 at 21:03):
I would put it the other way around: it's invalid to use that versioned extension ,but the tests cases often involve weird edge cases like that
Josh Mandel (Mar 08 2022 at 21:05):
Wait, it's invalid to use http://hl7.org/fhir/3.0/StructureDefinition/extension-Patient.animal as extension, but OK to use it as modifierExtension, yes? And we're saying that PA explicitly decided to also provide a non-modifer way to talk about animal extensions? The resolution to FHIR-14880 does not make me think that's what happend.
Josh Mandel (Mar 08 2022 at 21:07):
Instead of:
* We know about backport but want a dedicated way to express this
* We want to surface this extension specifically as a non-modifier
... the resolution from FHIR-14880 makes me think the decision really just was designed to say "let's move .animal out of Patient and still have a way to express animal details outside of the core elements". And the standard backport modifierExtension manages that just fine.
Josh Mandel (Mar 08 2022 at 21:08):
OK, the resolution was succinct but the comments were clear:
Futher discussion was held on this topic, and the standard extension suggested should not be a modifier. And also verified with someone from veterinary who is ok with this.
Never mind me. If standard backport extensions were considered at the time though, the decision might have gone differently.
Lloyd McKenzie (Mar 08 2022 at 21:12):
Does the snapshot process even always have access to the definition of the extension? It shouldn't need to if the differential doesn't drill down inside the extension. And if it can't access the definition, it'd have no basis on which to yell.
Grahame Grieve (Mar 08 2022 at 21:27):
it does drill into in this case, but yes, if it doesn't, the snapshot generator doesn't need the target
Grahame Grieve (Mar 09 2022 at 06:32):
ok well, the next version of the validator will validate this.
Grahame Grieve (Mar 09 2022 at 06:32):
it didn't. though you could never build an instance that would validate against the profile.
Josh Mandel (Mar 09 2022 at 14:08):
it didn't. though you could never build an instance that would validate against the profile.
You mean the validator didn't detect this problem but would fail validation for a different reason?
Lloyd McKenzie (Mar 09 2022 at 16:06):
The validator would catch it when validating an instance against a profile, but not when validating the profile itself
Josh Mandel (Mar 09 2022 at 16:43):
Ahh! Little by little I'm understanding what this thread is about ;-)
Josh Mandel (Mar 09 2022 at 16:43):
So now if somebody tried to put a profile like this into an implementation guide, the publishing tool chain would reject it even if they didn't have any examples at all.
Josh Mandel (Mar 09 2022 at 16:44):
( in addition to throwing a warning that no examples were provided...)
Lloyd McKenzie (Mar 09 2022 at 16:52):
Right. Even before, the publishing tool chain would have complained about the lack of examples - but there are times when suppressing that warning is reasonable and so this issue could have slipped in.
Grahame Grieve (Mar 09 2022 at 21:49):
the publishing tool chain would reject it even
well, yes, where 'reject' means noting the issue in the qa page
Last updated: Apr 12 2022 at 19:14 UTC
