Stream: IG creation
Topic: IG Publisher error on ImagingStudy uid elements
Rob Hausam (Nov 15 2018 at 14:57):
In the current build for ImagingStudy the previous (3.5.0) series.identifier and series.instance.identifier elements have been changed from 'identifier' to 'uid', but the latest IG Publisher doesn't seem to recognize them:
The link 'StructureDefinition-ImagingStudy-uv-ips-definitions.html#ImagingStudy.series.uid' for "uid" cannot be resolved The link 'StructureDefinition-ImagingStudy-uv-ips-definitions.html#ImagingStudy.series.instance.uid' for "uid" cannot be resolved
The other paths in ImagingStudy-uv-ips.structuredefinition.xml are resolving as expected.
Grahame Grieve (Nov 16 2018 at 06:57):
can I reproduce this?
Rob Hausam (Nov 16 2018 at 07:57):
you should be able to - just build https://github.com/HL7/fhir-ips
Rob Hausam (Nov 28 2018 at 17:10):
@Grahame Grieve Did you ever look at this? I'm still getting the error.
John Moehrke (Nov 29 2018 at 14:49):
@Rob Hausam Can you remove the constraint? The uid element is already a 1..1 element, so adding must-support seems odd.
Rob Hausam (Nov 29 2018 at 15:56):
@John Moehrke I see your point about must support on a 1..1 element, but that shouldn't be an error. And there seems to be a fundamental issue here, as I note that the snapshot view rendered by the current IG Publisher (after first trashing the ig output and temp folders) is showing the series.id and series.instance.id elements, rather than the .uid elements as in the current build. So something is out of sync. @Grahame Grieve?
John Moehrke (Nov 29 2018 at 16:54):
okay, but does the problem go away if you remove these unnecessary constraints?
Grahame Grieve (Nov 29 2018 at 20:57):
@Rob Hausam ips doesn't build for me right now...?
Rob Hausam (Nov 30 2018 at 00:27):
I'll check, but it's been building for us locally
Rob Hausam (Nov 30 2018 at 15:16):
The last ips auto-build succeeded (as the previous ones have been). But I've also noted that these particular errors don't actually show up in the qa in either the auto-build or when I build on Windows, but they do occur when I build on the Mac. That is a consistent difference which seems to be showing a real issue which apparently may be masked when building on Windows (for whatever reason). The snapshot view in both the auto-build and Windows output shows both an 'id' element (which doesn't exist in the core spec) plus the correct 'uid' element (and it has a little different rendering but is still an issue in the Mac build) - obviously that shouldn't be happening.
Grahame Grieve (Nov 30 2018 at 20:56):
that's bizarre
Rob Hausam (Dec 02 2018 at 00:11):
agree - any thoughts?
Grahame Grieve (Dec 03 2018 at 19:33):
mainly that since I publish from windows, I can worry about it later
Rob Hausam (Dec 04 2018 at 16:23):
ok - sounds like I should ignore it, too, then :)
Grahame Grieve (Dec 04 2018 at 18:47):
for now. I may have time next week now that I've published the ballots and R3/R4 conversion is nearly done
Lloyd McKenzie (Dec 10 2018 at 23:50):
@John Moehrke minOccurs of 1 doesn't mean mustSupport=true. You're free to ignore mandatory elements as a receiver, not let a user see them, not take them into account in decision support, or any of the other things that mustSupport might imply.
John Moehrke (Dec 11 2018 at 00:02):
I was approaching it a different way... since cardionality is 1..1, there is little added value of mustSupport. This cardiolnality was a change in R4 from prior ImagingStudy models... I was just looking to help get @Rob Hausam through being able to build his IG. I was just offering a hack that might have minimal negative impact. I agree that mustSupport is defined in that IG however that IG wants, and thus it is very possible that the flag is needed in this case.
Lloyd McKenzie (Dec 11 2018 at 01:37):
There's significant added value. 1..1 says what will be present on the wire. mustSupport says what you actually need to do something useful with.
Lloyd McKenzie (Dec 11 2018 at 01:37):
1..1 doesn't imply you need to pay attention to it.
Richard Townley-O'Neill (Dec 11 2018 at 02:02):
I think of 1..1 as implying "must write" but not "must read".
Lloyd McKenzie (Dec 11 2018 at 02:19):
It's a "must write" but it's not even a "must write usefully". You can satisfy a 1..1 by sending a fixed value (or even an extension saying something like "not applicable") without exposing the element to a user or giving them a chance to provide a meaningful value. On the other hand, if it's marked as mustSupport and mustSupport indicates that user entry must be allowed, that's a much tighter set of expectations.
John Moehrke (Dec 11 2018 at 13:42):
mustSupport means nothing... it is given meaning in that Implementation Guide... so you can't make any statements about what mustSupport means until you indicate which IG is providing the rule for the tag. http://build.fhir.org/conformance-rules.html#mustSupport
Lloyd McKenzie (Dec 11 2018 at 15:48):
It always means something. The specific meaning is variable. The point is that 1..1 mustSupport=false and 1..1 mustSupport=true can drive very different implementation expectations.
Last updated: Apr 12 2022 at 19:14 UTC
