FHIR Chat · Slicing a discriminator element · conformance

Stream: conformance

Topic: Slicing a discriminator element

view this post on Zulip Pieter Edelman (May 14 2019 at 14:57):

Suppose I'm slicing Observation.component based on code.coding.code + code.coding.system. I then define my slices and I would like to say "SHALL use at least this SNOMED CT concept as coding, but could have other concepts as well". I could do either of the following:

  • In each component slice I could slice the component.code.coding with one required slice for the SNOMED CT concept leaving other codings open
  • In each component slice I could set a fixed component.code.coding.code and .system and leave coding set to 1..*

Both options lead to different outcomes in the .Net validator 1.5.2 UI and the Java validator 3.8.0 CLI. The former leads to unrecognized slices. I.e. when you validate, it cannot match data to slice definitions. The latter solution works well, but disallows adding additional codings on any of the slices.

Question:

  • Is my setup possible at all and if so what would be the recommended profiling method?

view this post on Zulip Michel Rutten (May 14 2019 at 18:37):

Hi @Pieter Edelman, both approaches are valid (with different behavior). Looks like a bug in the validator(s).
@Ewout Kramer?
BTW I think there's a third option. You could put constraints on the default child elements of the slice introduction element (with the slicing discriminator). These constraints should apply to all slices. This prevents you from having to repeat the same constraints in each named slice. However, I'm not sure if the validator(s), or any other implementations, support this already...

view this post on Zulip Oliver Egger (May 15 2019 at 05:23):

Hi @Pieter Edelman . the validation error you describe for the java validator is described it in GF#21472. But for your usecase I would suggest another profiling way. Use pattern/code slicing and patternCodeableConcept within the components which requires that you have of one of the mentioned codes in your slice. As an example to illustrate this, see the modified blood pressure profile: https://github.com/hapifhir/org.hl7.fhir.core/blob/30803a7a410bec0d9c3f52b34dd799c5aa3a9830/org.hl7.fhir.validation/src/test/resources/validation-examples/observation-bp-profile.xml .

view this post on Zulip Pieter Edelman (May 15 2019 at 07:39):

@Oliver Egger The pattern slicing works brilliantly. I have one additional twist to the whole setup: we have a bigger lab use case where a component should contain 2 codings. One in LOINC and one in a Dutch system. For the Dutch system the equivalency is not necessarily 1..1 so I just want to say "Use LOINC X + use a code from Dutch system"

A way to say this could have been:

      <patternCodeableConcept>
        <coding>
          <system value="http://loinc.org" />
          <code value="85354-9" />
        </coding>
        <coding>
          <system value="http://dutch.lab.system" />
        </coding>
      </patternCodeableConcept>

But the Java quite elegantly says:

Error @ Observation.component[1] (line 14, col16) : Unsupported CodeableConcept pattern - must be just one coding - for discriminator(code) for slice Observation.component:component1

Does this mean it is legal to specify, but just not supported, or does it mean that it is illegal to specify that way? If illegal: what could be a solution here?

view this post on Zulip Pieter Edelman (May 15 2019 at 07:43):

@Michel Rutten We'll file something for the .Net validator unless it has already been filed (pattern slicing). For Forge you might want to check the visual behavior for Forge STU3. The pattern title lists "no name" when you specify just system. It updates when you list both system and code. Just a visual glitch. If specifying a system + code is required then maybe a check could be added for that. We did not try R4 for reference on this.

view this post on Zulip Grahame Grieve (May 15 2019 at 07:43):

you can submit a test case for the java validator... I'll be doing a run of validator work shortly

view this post on Zulip Pieter Edelman (May 15 2019 at 13:25):

you can submit a test case for the java validator... I'll be doing a run of validator work shortly

@Grahame Grieve Do you have a ticketing system for the Java validator?

view this post on Zulip Oliver Egger (May 15 2019 at 16:12):

@Pieter Edelman @Grahame Grieve since i was working last week on GF#21240 for adding support to pattern[x] on elements I added an example to the validation suite and a pull request extending pattern[x] support for slicing, see https://github.com/hapifhir/org.hl7.fhir.core/pull/23

view this post on Zulip Michel Rutten (May 15 2019 at 18:30):

Hi @Pieter Edelman, thanks for the feedback! Forge tries to generate a useful name from the available info, should be easy to fix the pattern.

view this post on Zulip Grahame Grieve (May 15 2019 at 23:13):

@Pieter Edelman https://github.com/hapifhir/org.hl7.fhir.core/issues

view this post on Zulip Pieter Edelman (May 16 2019 at 07:05):

Pieter Edelman Grahame Grieve since i was working last week on GF#21240 for adding support to pattern[x] on elements I added an example to the validation suite and a pull request extending pattern[x] support for slicing, see https://github.com/hapifhir/org.hl7.fhir.core/pull/23

That's fast! Awesome :)

view this post on Zulip Pieter Edelman (May 16 2019 at 07:18):

Hi Pieter Edelman, thanks for the feedback! Forge tries to generate a useful name from the available info, should be easy to fix the pattern.

Cool! Do you need any additional info?

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -