Stream: implementers
Topic: slice on a non-immediate child
Rik Smithies (Mar 16 2021 at 20:35):
Does a slice discriminator path have to be an immediate child of the sliced element?
You can have this:
<slicing>
<discriminator>
<type value="value"/>
<path value="someelement"/>
But can you have this?
<slicing>
<discriminator>
<type value="value"/>
<path value="someelement.coding.code"/> <!-- possible? -->
Chris Moesel (Mar 16 2021 at 20:37):
Yep. That is fine. In fact, the BP profile does that... (Although I would have personally preferred a pattern discriminator on code in the BP profile).
Rik Smithies (Mar 16 2021 at 20:42):
cool! My aim is to slice on a codeableConcept but just the code and to leave the display optional. If the whole code is fixed then you force a decision on display, in or out.
Lloyd McKenzie (Mar 16 2021 at 20:50):
With code, you should generally slices on both code + system - which means it's actually easier to slice by pattern on the Coding
Chris Moesel (Mar 16 2021 at 20:51):
@Rik Smithies -- Understood. If you only care about code then that's a good approach. But if you care about system and code, then you may want to consider using a pattern discriminator on code and patternCodeableConcept to "set" the required system/code in the slice. When you use pattern[x], the unspecified properties (like display) can be any value (or absent).
Lloyd McKenzie (Mar 16 2021 at 20:54):
Caring about 'code' and not 'system' in a Coding is a dangerous thing to do... :)
Rik Smithies (Mar 16 2021 at 20:55):
I do care about system just hadn't brought it into the discussion, to keep it simpler :) But its good to know I can slice on both.
Chris Moesel (Mar 16 2021 at 20:58):
@Lloyd McKenzie -- if you are discriminating on a CodeableConcept to slice some higher-level array (like Observation.component), wouldn't it be preferable to slice on the code rather than code.coding? If you slice on code.coding then I think that in the slices you need to put the patternCoding on code.coding -- but then to avoid requiring every instance of that Coding to match the pattern, you also have to introduce a new slicing on code.coding, right? When given the choice between n slicings and n + 1 slicings, I almost always choose n!
Rik Smithies (Mar 16 2021 at 20:58):
is there an example of using patternCodeableConcept somewhere?
Chris Moesel (Mar 16 2021 at 20:59):
US Core Pediatric BMI: http://www.hl7.org/fhir/us/core/StructureDefinition-pediatric-bmi-for-age.html
Chris Moesel (Mar 16 2021 at 21:00):
It's not in the context of a slice, but if you're just looking for a patternCodeableConcept, it's in there.
Rik Smithies (Mar 16 2021 at 21:01):
thanks, I will try to put the pieces together :-)
Chris Moesel (Mar 16 2021 at 21:05):
Here's one from mCODE that slices Observation.component on code. But there's a lot going on in that profile, so it's easy to get lost in the weeds: https://build.fhir.org/ig/HL7/fhir-mCODE-ig/StructureDefinition-mcode-comorbidities-elixhauser.html
Rik Smithies (Mar 16 2021 at 21:14):
I seem to be able to get what I want by going back to descriminating on the child element itself (not the coding or code) and just putting a patternCodeableConcept on the element, rather than a fixedCodeableConcept. I take it that descriminating on a "patterned" element is allowed, as well on as a "fixed" one. It's a checkable constraint I guess.
Lloyd McKenzie (Mar 16 2021 at 21:28):
Slicing on component.code is fine. Slicing on component.code.coding.code without component.code.coding.system would be problematic.
Lloyd McKenzie (Mar 16 2021 at 21:29):
Discriminating on pattern is better than fixed because pattern will ignore differences in extensions, display, etc.
Chris Moesel (Mar 16 2021 at 21:31):
But note that in R4 if the slices use pattern[x] then the discriminator type needs to be pattern (as opposed to value, which is what you use if the slices use fixed[x]).
Lloyd McKenzie (Mar 16 2021 at 21:33):
I believe the validator doesn't care
Last updated: Apr 12 2022 at 19:14 UTC
