Stream: united states
Topic: Non-conformant element ids
Chris Grenz (Aug 02 2021 at 22:24):
@Eric Haas @Brett Marquard The us-core extension profiles have non-conformant element ids in them. How can I report this officially?
For example, us-core-race has id Extension.extension:ombCategory.valueCoding which should be Extension.extension:ombCategory.value[x]:valueCoding
Also, an additional differential element is needed at Extension.extension:ombCategory.value[x] to limit the allowed value to Coding.
See http://hl7.org/fhir/elementdefinition.html#id and http://hl7.org/fhir/elementdefinition.html#typesx
Lloyd McKenzie (Aug 02 2021 at 23:21):
Is this happening in the most recent version of US Core?
Lloyd McKenzie (Aug 02 2021 at 23:21):
(Trying to figure out if this is a current publisher issue)
Chris Moesel (Aug 02 2021 at 23:59):
I'm looking at the latest US Core race extension, and the snapshot has an element with Extension.extension:ombCategory.value[x]:valueCoding. The differential does have Extension.extension:ombCategory.valueCoding, but that shortcut syntax is allowed in the differential (as described in this blog and hopefully the spec somewhere).
I agree, however, that the differential should also contain a type constraint on Extension.extension:ombCategory.value[x] constraining it to only Coding. The spec is clear about this as @Chris Grenz points out. The snapshot generator, however, is incorrectly inferring the constraint from the Extension.extension:ombCategory.valueCoding -- so if you look at the snapshot, it does have a type constraint. But this is a bug, not a feature (and one that I'm 98% sure I've reported before).
Chris Grenz (Aug 03 2021 at 00:27):
The R4 spec specifically disallows that id format in the differential. The blog post points out that this was unclear in R3.
valueCoding _is_ the correct value in the path.
Chris Grenz (Aug 03 2021 at 00:31):
@Michel Rutten I think the "Normalization" section of the blog post is non-conformant...
Eric Haas (Aug 03 2021 at 01:14):
make a tracker as a technical correction. @Grahame Grieve I expected the validator to catch this?
Chris Moesel (Aug 03 2021 at 01:27):
@Chris Grenz -- I am pretty sure that most (or all?) of the major tools support choice type renaming in differential element ids. The IG Publisher happily accepts it and translates it to the full id in the snapshot. Even the vital signs profiles included in FHIR R4 core use choice type renaming in differential ids (example). So if you're right that it is not allowed, then there are a lot of tools and definitions that need to change (including FHIR core itself). We should probably get to the bottom of this.
Chris Grenz (Aug 03 2021 at 01:41):
Hmm... That's how I read this: http://hl7.org/fhir/elementdefinition.html#id
SHALL be present and SHALL use this algo. And the algo specifically calls out the type choice scenario...
Lloyd McKenzie (Aug 03 2021 at 02:23):
My understanding was that valueCoding is not allowed in either id or path anymore.
Chris Moesel (Aug 03 2021 at 12:48):
@Chris Grenz -- yeah, that section of doc does read that way. I only know what I've seen and been told regarding this. I am having a hard time finding it in the spec though.
@Lloyd McKenzie - the spec at least mentions it in reference for paths:
The inclusion of a type specific path (such as "Patient.deceasedBoolean") SHALL NOT be interpreted as constraining allowed types, but instead, it constrains the use of a particular type
And that bit (quoted above) was specifically added in R4, so it's not just an unintentional carryover from STU3.
@Michel Rutten @Ward Weistra @Ewout Kramer - does fire.ly have any insight on choice type renaming and where it is and is not allowed? Since fire.ly wrote the blog article, I imagine you had some conversations around this back when it was decided.
Chris Grenz (Aug 03 2021 at 13:28):
It's important to distinguish between path and id. path: Extension.valueCoding is fine and refers to id: Extension.value[x]:valueCoding
id: Extension.valueCoding should be an error.
Chris Moesel (Aug 03 2021 at 13:34):
I guess I just don't understand the point of it then. It's not much of a "shortcut" syntax if you're still required to do the long form in the id anyway. If id was optional then you could argue that there's value if you're only doing the path, but sdf-17 requires every differential element to have an id -- so what's the point?
Ewout Kramer (Aug 03 2021 at 13:47):
I'm afraid not -- Michel (who wrote this) is out of the picture and he & Grahame worked on this stuff pretty much in isolation. @Marco Visser and me are now responsible for his code, but I would have to dig in the code. I do know that Michel wrote this after he implemented it in the R4 API (and thus forge).
Grahame Grieve (Aug 17 2021 at 04:26):
I'm not sure what the problem is here?
Eric Haas (Aug 18 2021 at 06:41):
See Chris’ original post on the syntax used in the differentials for choice datatypes
Chris Grenz (Aug 23 2021 at 22:04):
Submitted https://jira.hl7.org/browse/FHIR-33233
Last updated: Apr 12 2022 at 19:14 UTC
