FHIR Chat · Choice Type Renaming Should Not Constrain Types · conformance

Stream: conformance

Topic: Choice Type Renaming Should Not Constrain Types

view this post on Zulip Chris Moesel (Mar 24 2021 at 00:59):

My understanding from firely's excellent Type Slicing in FHIR R4 article and from section 2.30.0.4.2 in the spec is that the use of choice type renaming (e.g., valueQuantity) should not constrain the available types in the choice. That section of the spec specifically states:

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

This is a change introduced in R4. Prior to R4, the use of choice type renaming did constrain the available types. But in R4, that behavior was removed (as detailed in firely's blog).

view this post on Zulip Chris Moesel (Mar 24 2021 at 01:02):

But... @Max Körlinge discovered over in the #shorthand stream that when the differential contains elements that use the type slice renaming syntax, the IG Publisher is generating a snapshot that constrains the types only to the ones noted in the differential and produces a closed type slicing. This seems to go directly against what the spec states should happen.

view this post on Zulip Chris Moesel (Mar 24 2021 at 01:09):

I have an example project (which I will attach) that reproduces the behavior. The differential of an Observation contains only these two elements:

[{
  "id": "Observation.valueCodeableConcept",
  "path": "Observation.valueCodeableConcept",
  "min": 0,
  "max": "1",
  "type": [{ "code": "CodeableConcept" }],
  "mustSupport": true
},
{
  "id": "Observation.valueQuantity",
  "path": "Observation.valueQuantity",
  "min": 0,
  "max": "1",
  "type": [{ "code": "Quantity" }],
  "mustSupport": true
}]

but when you build it w/ the IG Publisher, the value[x] element gets generated like this (with irrelevant properties removed for brevity):

{
  "id": "Observation.value[x]",
  "path": "Observation.value[x]",
  "slicing": {
    "discriminator": [{ "type": "type", "path": "$this" }],
    "ordered": false,
    "rules": "closed"
  },
  "type": [
    { "code": "CodeableConcept" },
    { "code": "Quantity" }
  ]
}

view this post on Zulip Chris Moesel (Mar 24 2021 at 01:13):

This seems wrong to me based on my understanding of the R4 spec, but I wanted confirmation before I file a bug against the publisher. Also, I'm not sure where I am supposed to file bugs against the publisher (Jira? GitHub?). You can reproduce using this simple FSH project: ChoiceConstraintsIG.zip

view this post on Zulip Ward Weistra (Mar 31 2021 at 19:10):

Just verified that this does not seem to happen with the .NET SDK. This is the resource on Simplifier. Looking at the rendering or downloading (Download > Download with snapshot) the slicing is not constrained to Quantity only.

view this post on Zulip Grahame Grieve (Apr 16 2021 at 06:14):

I think it looks like a bug. The code is the snapshot generator, so bugs here: https://github.com/hapifhir/org.hl7.fhir.core/issues, and the test cases for it are here: https://github.com/FHIR/fhir-test-cases/tree/master/r5/snapshot-generation - see https://github.com/FHIR/fhir-test-cases/blob/master/r5/snapshot-generation/manifest.xml for an overview, and the relevant test cases of the obs-X ones

view this post on Zulip Ward Weistra (Apr 22 2021 at 15:25):

Seen this :point_up: @Chris Moesel ?

view this post on Zulip Chris Moesel (Apr 22 2021 at 15:42):

Yeah, but forgot to file a bug and didn't get a chance to look at the test cases. @Grahame Grieve -- are you looking for both a bug report and some failing test cases?

view this post on Zulip Grahame Grieve (Apr 22 2021 at 20:45):

well there's already test cases - do you think they're wrong?

view this post on Zulip Chris Moesel (Apr 22 2021 at 23:05):

OK. I just took a look. Unless I'm missing it, I don't see any test cases that actually exercise this feature. I'm concerned about how the snapshot generator handles choice type renaming in the differential. I see many tests with something like this:

<differential>
    <element>
      <path value="Observation.value[x]"/>
      <slicing>
        <rules value="open"/>
      </slicing>
    </element>
    <element>
      <path value="Observation.value[x]"/>
      <sliceName value="valueQuantity"/>
      <type>
        <code value="Quantity"/>
      </type>
      <binding>
        <strength value="required"/>
        <valueSet value="http://somewhere/something-else"/>
      </binding>
    </element>
</differential>

But the issue I raised would require a test that looks more like this:

<differential>
    <element>
      <path value="Observation.valueQuantity"/>
      <type>
        <code value="Quantity"/>
      </type>
      <binding>
        <strength value="required"/>
        <valueSet value="http://somewhere/something-else"/>
      </binding>
    </element>
</differential>

This test case should actually act exactly like the test case above it -- because when choice type renaming (e.g., path Observation.valueQuantity) is used in R4:

  • open type slicing should be inferred
  • correct sliceName (valueQuantity) should be inferred
  • value[x] base element should not be type-constrained to only Quantity (this is where I think the snapshot generator does it wrong)

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -