FHIR Chat · Choice Type Renaming · conformance

Stream: conformance

Topic: Choice Type Renaming

view this post on Zulip Chris Moesel (Sep 28 2021 at 00:12):

@Grahame Grieve --choice type renaming has has come up in several threads (here in August and here just today) -- but I feel we still have not come to resolution on it. Can you clarify whether or not you can use choice type renaming in a differential element's id and/or path?

For example, if I want to add a value set binding to Observation.value's CodeableConcept type, is this allowed in the differential?

{
  "id": "Observation.valueCodeableConcept",
  "path": Observation.valueCodeableConcept",
  // rest of element
}

The fire.ly blog on Type Slicing in R4 describes the whole concept of choice type renaming, indicating that it is supported in FHIR R4:

In FHIR R4, choice type element renaming is only allowed in the StructureDefinition.differential component, as a shortcut notation. When generating the StructureDefinition.snapshot component, renamed choice type element constraints are normalized to the regular slicing syntax, reverting the new element name back to the original name with [x] suffix (e.g. value[x]) and initializing the slice name from the new element name (e.g. valueString).

In addition, several core profiles use choice type renaming in their differential ids and paths. For example, the BodyWeight profile contains this element in the differential:

{
  "id" : "Observation.valueQuantity",
  "path" : "Observation.valueQuantity"
}

I haven't found this explicitly discussed in the spec except in passing in section 2.30.0.4.2:

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

Note that the above was added in R4, so it is not just a remnant of previous versions.

Last, when the IG Publisher encounters StructureDefinitions that use this choice type renaming in the differential, it does correctly "normalize" them to the full ids/paths in the snapshot (according to the approach documented in the fire.ly blog above).

Based on these things (fire.ly blog, use in multiple core profiles [and many IGs], mention of it in the spec, and explicit behavior supporting it in the IG Publisher), I think that this may be an intended feature that is poorly documented. @Lloyd McKenzie, however, says that he doesn't think it is supported (anymore?). @Grahame Grieve - do you have any insight on this topic? SUSHI uses type renaming and if it's wrong, I need to fix it.

view this post on Zulip Chris Moesel (Oct 03 2021 at 18:43):

Does a definitive answer to this question exist? Or is it going unanswered because nobody actually knows for sure?

view this post on Zulip Grahame Grieve (Oct 03 2021 at 19:50):

it's on my todo list

view this post on Zulip Ewout Kramer (Oct 05 2021 at 14:38):

I think this is the issue that set this in motion: https://jira.hl7.org/browse/FHIR-12259

view this post on Zulip Ewout Kramer (Oct 05 2021 at 14:40):

  1. A type choice element must remain in the profile snapshot as-is and will be interpreted as applying to all instances of the element regardless of type.

  2. Constraints limiting the acceptable list of types must be applied to the original "[x]" element as this is where the list of acceptable types is defined. The inclusion of a type specific path (such as "Patient.deceasedBoolean" shall not be interpreted as constraining allowed types).

  3. Type choice elements are treated as being implicitly sliced by type with the slice names that are displayed in the standard documentation (e.g. deceasedBoolean is the boolean slice of deceased[x]).

  4. Constraints applied to a named type slice apply only to instances of that type. For instance, an element in a profile with name "deceasedBoolean" constrains only boolean instances of the deceased[x] element. Note that this is simply the normal behavior of a slice.

  5. Paths to the type slices may directly use the type slice name (path="Patient.deceasedBoolean") or may use the slice form (path="Patient.deceased[x]", name="deceasedBoolean").

view this post on Zulip Ewout Kramer (Oct 05 2021 at 14:41):

But it did miss the R3 timeline, and Michel implemented in R4.

view this post on Zulip Eric Haas (Oct 18 2021 at 23:56):

What is the answer to this? I have a tracker whose outcome depends on it: https://jira.hl7.org/browse/FHIR-33233 ?

Should

"id: "Extension.extension:ombCategory.valueCoding"

be

id: "Extension.extension:ombCategory.value[x]:valueCoding" ?

view this post on Zulip Lloyd McKenzie (Oct 19 2021 at 01:34):

Latter

view this post on Zulip Chris Moesel (Oct 19 2021 at 12:32):

I know this has always been @Lloyd McKenzie's view on this, but there is enough inconsistency in the spec regarding this that it was on @Grahame Grieve's TODO list for further investigation. Grahame -- if we want to adopt Lloyd's position on this, that's fine, I just want to know so that we can update SUSHI. If we do adopt this view (that choice type renaming is no longer valid) then this affects several of the Vital Signs profiles in FHIR core since they do use choice type renaming (which also may affect @Eric Haas since I think US Core points to these vital signs profiles as well).

view this post on Zulip Corey Spears (Oct 21 2021 at 00:32):

Hopefully we can get this resolved before too long. This is also causing build errors on an IG (Da Vinci Formulary) we are looking to ballot this cycle.
https://build.fhir.org/ig/HL7/davinci-pdex-formulary/branches/stu2-draft/qa.html#internal

view this post on Zulip Chris Grenz (Oct 27 2021 at 18:00):

I think the decision was again reaffirmed: https://jira.hl7.org/browse/FHIR-33233

view this post on Zulip Chris Grenz (Oct 27 2021 at 18:02):

The element ids must be value[x]:valueCoding form. Also, there is no distinction in the spec between the differential and snapshot forms, regardless of the blog post.

view this post on Zulip Chris Moesel (Oct 28 2021 at 12:24):

OK. @Grahame Grieve was also going to think on this. Grahame, do you agree that the resolution to the US Core issue linked above applies to all of FHIR? E.g., using choice type renaming is not allowed in FHIR profiles/extensions? If so, then:

  • The SUSHI team needs to fix SUSHI to stop using choice type renaming.
  • The firely team should provide a disclaimer on their blog article saying it is no longer true.
  • We should file tickets to fix the following profiles in core FHIR that use choice type renaming: cdshooksguidanceresponse, devicemetricobservation, resprate, oxygensat, heartrate, headcircum, bp, bodyweight, bodytemp, bodyheight, bmi, cholesterol, triglyceride, hdlcholesterol, ldlcholesterol.
  • We should file a ticket to remove the reference to Patient.deceasedBoolean in section 2.30.0.4.2 and anywhere else choice type renaming is referred to in the spec.
  • We should file a ticket to have the IG Publisher warn or error on use of choice type renaming (although, I think that at least for now the functionality to handle it in IG Publisher should remain intact).

view this post on Zulip Alexander Zautke (Oct 28 2021 at 13:01):

Chris Grenz said:

The element ids must be value[x]:valueCoding form. Also, there is no distinction in the spec between the differential and snapshot forms, regardless of the blog post.

As far as I remember we have a difference between differential and snapshot. See https://chat.fhir.org/#narrow/stream/179177-conformance/topic/Slicing.20a.20non-repeating.20element/near/167975569

view this post on Zulip Alexander Zautke (Oct 28 2021 at 13:05):

Which systems can't currently handle choice type renaming? We have support for it in SUSHI, IG Publisher and the .NET SDK, right?

view this post on Zulip Alexander Zautke (Oct 28 2021 at 13:10):

I agree with @Lloyd McKenzie above that it should be changed as proposed in the tickets, but breaking all these implementations seems not a good way forward to me. Especially given the fact that sooner or later someone wants to have the same behaviour in .NET and the support would need to be removed there as well.

view this post on Zulip Ewout Kramer (Nov 02 2021 at 08:52):

Based on these things (fire.ly blog, use in multiple core profiles [and many IGs], mention of it in the spec, and explicit behavior supporting it in the IG Publisher), I think that this may be an intended feature that is poorly documented. Lloyd McKenzie, however, says that he doesn't think it is supported (anymore?). Grahame Grieve - do you have any insight on this topic? SUSHI uses type renaming and if it's wrong, I need to fix it.

So, this behaviour has been discussed, decided on, been made part of a normative section of the spec, has been blogged about and implemented. Why would we remove it?

view this post on Zulip Ewout Kramer (Nov 02 2021 at 09:11):

Reading the history of the issue, it seems there are two major points:

  • Whether there are bugs in its implementation (no value[x] generated in the snapshot to allow all other types)
  • Whether the id needs to follow the pattern of the path (and Chris is wondering what the advantage of a shortcut notation is if you need to fully expand it in the id)

I have missed where it says we should retract the choice type renaming (as Chris discusses in his Oct 28th post) ("do you agree that the resolution to the US Core issue linked above applies to all of FHIR? E.g., using choice type renaming is not allowed in FHIR profiles/extensions?").

I wish we could just sit together behind a whiteboard!

view this post on Zulip Grahame Grieve (Nov 11 2021 at 02:17):

see comments here: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Odd.20IG.20broken.20link.20build.20issue.20with.20choice.20data.20elements

view this post on Zulip Chris Moesel (Nov 12 2021 at 19:29):

Thanks again, Grahame. We'll add a task to update SUSHI to stop using choice type renaming in a future version. At that point, it will always use the full form slice syntax for the id and original choice[x] path for the path. This will affect the output of many IGs, but should be safe since it's effectively saying the same thing.

view this post on Zulip Ewout Kramer (Nov 16 2021 at 09:58):

So, copying the summary from that thread:

We will follow through on your guidance and update SUSHI so that it always uses the full slice syntax in choice ids when creating the differential (e.g., Observation.value[x]:valueQuantity rather than just Observation.valueQuantity). We'll also avoid things like Observation.valueQuantity in the ElementDefinition path, and prefer simply Observation.value[x].

Let me double check:

  • this means you could still use type renaming in the differential, but SUSHI will not use it, so the differential will use the path value[x] instead?
  • Grahme's snapshot generator will (at some point) generate the value[x] in the snapshot to allow other types if a type rename is used in the differential?

view this post on Zulip Chris Moesel (Nov 16 2021 at 13:16):

My take was that @Grahame Grieve said you can "continue to get away with" using choice type renaming, but the "correct" form is the long form, and that is what is "guaranteed to work". So it seems a pretty strong stance in favor of always using the long form.

As for the snapshot generator, I thought it already was doing the right thing w/ choice type renaming now (particularly since he fixed the link anchor generation bug).

view this post on Zulip Grahame Grieve (Nov 16 2021 at 18:30):

I'm not exactly sure what this means:

Grahme's snapshot generator will (at some point) generate the value[x] in the snapshot to allow other types if a type rename is used in the differential?

view this post on Zulip Ewout Kramer (Nov 16 2021 at 22:30):

"continue to get away with" ;-) Good, so we don't need to remove code then - it's just Forge that might need to change policies on how to write differentials in a "guaranteed to work" way!

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -