FHIR Chat · Benefit of slicing · implementers

Stream: implementers

Topic: Benefit of slicing

Sadiq Saleh (Feb 28 2017 at 14:36):

I have currently built a profile on condition, with condition.stage.assessment referring to several other profiles on observation.
Currently I have used the | to sepearate the references (i.e. Reference(Observation){profile 1} | Reference(Observation){profile 2} | ...) but I am unclear if I should be slicing condition.stage.assessment instead?
As far as I understand, the resultant paths are not affected by slicing, only the ID's are, and that a discriminating factor between the references is alread provided (each has different profile uris) is there a benefit to slicing in this case?

Michel Rutten (Feb 28 2017 at 14:41):

@Sadiq Saleh if you just want to define a couple of (external) element type profiles to choose from, then you don't need to slice the element. Instead, you can simply extend the element type collection:

        <type>
          <code value="Reference" />
          <profile value="http://example.org/fhir/StructureDefinition/CustomProfile1" />
        </type>
        <type>
          <code value="Reference" />
          <profile value="http://example.org/fhir/StructureDefinition/CustomProfile2" />
        </type>

Sadiq Saleh (Feb 28 2017 at 15:18):

Thanks for your prompt response @Michel Rutten , that is currently how I have it set up. So I guess the issue is that I don't quite understand the contexts in which slicing is beneficial (other than in the examples given w.r.t. blood pressure, etc.).
A follow up question is that given an instance where this profile is populated by data, how would I refer to a specific reference from this list (i.e. specifically to CustomProfile1)? As I mentioned I know we can distinguish it using the profile tag, but is there another way which I am unaware of?

Michel Rutten (Feb 28 2017 at 15:27):

@Sadiq Saleh Slicing is an advanced profiling technique. You use slicing if you want to define additional profiling constraints on the individual slices from within the referencing profile. The discriminator allows you to define the unique aspect(s) that identifies each slice. I suggest you examine some examples on the FHIR website or on Simplifier to get a better understanding.

Michel Rutten (Feb 28 2017 at 15:27):

https://www.hl7.org/fhir/profiling.html#slicing

Sadiq Saleh (Feb 28 2017 at 15:29):

Thanks again. I have looked through the examples on the FHIR page, but will also take a look at those on Simplifier to further my understanding.

Eric Haas (Feb 28 2017 at 17:39):

Michel is the slice king. I tend to avoid slicing and use invariant where I can instead especially since I expect my profiles to be reprofiled and I worry about burdening downstream with profilers reslicing. Check out the section on reslicing as well.

Sadiq Saleh (Feb 28 2017 at 17:46):

Thanks @Eric Haas
Could you give me an example of how you would use an invariant as a replacement to slicing?

Eric Haas (Feb 28 2017 at 18:05):

In my case most slicing by type, code or valueset so for example category here instead of a valueset slice I used:

 us-core-1: A code in Condition.category SHOULD be from US Core Condition Category Codes value set. (: where(category in    http://hl7.org/fhir/us/core/ValueSet/us-core-condition-category').exists())"

Michel Rutten (Feb 28 2017 at 18:10):

Slicing is a bit more explicit. A slice definition in a profile is easier to parse and understand than an expression constraint. For example, if you render a sliced profile, then the result will typically show the slice elements. However there is no such expectation from expressions; hence this information is a bit more implicit.

Sadiq Saleh (Feb 28 2017 at 19:14):

That is what I understood from looking at the results from slicing Condition, that the slices were explicitly linked to a specific profile and that this was reflected in differing ids, but not in differing paths. For example slices on Condition.category would look like Condition:Profile1.category:Slice1, but the path for all slices is still Condition.category. Thus the only way to differentiate them is to use the discriminator to understand the data that is provided at that path.

Last updated: Apr 12 2022 at 19:14 UTC