FHIR Chat · Support for slicing with type code 'Resource' and profile ?

Stream: shorthand

Topic: Support for slicing with type code 'Resource' and profile ?

Oliver Egger (Mar 27 2021 at 10:32):

We are working to convert our ch-core dependent ig's to sushi and like the tooling a lot, thanks a lot for that effort!

We encounter a problem constraining profiled sliced entries in a bundle with slicing:

We have a non Sushi ImplementationGuide and there the slicing is setup as following:

     "slicing" : {
          "discriminator" : [
            {
              "type" : "profile",
              "path" : "resource"
            }
          ],
          "rules" : "open"

a slice entry is then defined as:

   {
        "id" : "Bundle.entry:Composition.resource",
        "path" : "Bundle.entry.resource",
        "min" : 1,
        "type" : [
          {
            "code" : "Resource",
            "profile" : [
              "http://fhir.ch/ig/ch-core/StructureDefinition/ch-core-composition"
            ]
          }
        ]
      }

the slicing entry type code is set to 'Resource' according to testcase Grahame has setup for the Java validator and the setups works with our dependent non-sushi implementation guides for ch-core.

The following problem surfaces now when changing the dependent ig to a sushi version:

We want to restrict the slice with the composition, constraining that ch-orf-composition (dependent from ch-core-composition)
is used instead of ch-core-composition

* entry[Composition].resource only ChOrfComposition

Gives the error:
Sushi: error The type "ChOrfComposition" does not match any of the allowed types: http://fhir.ch/ig/ch-core/StructureDefinition/ch-core-composition (00:01.0533)

We noticed that this error disappears if we fix the ch-core parent slice to

   {
        "id" : "Bundle.entry:Composition.resource",
        "path" : "Bundle.entry.resource",
        "min" : 1,
        "type" : [
          {
            "code" : "Composition",
            "profile" : [
              "http://fhir.ch/ig/ch-core/StructureDefinition/ch-core-composition"
            ]
          }
        ]
      }

(type.code to Composition instead of Resource), however this not the recommended setup to be used for slicing as indicated in the zulip thread

If we use sushi alone for slicing bundle entry the following differential is generated for the slice entries:

   {
        "id" : "Bundle.entry:TestComposition.resource",
        "path" : "Bundle.entry.resource",
        "min" : 1,
        "type" : [
          {
            "code" : "Composition",
            "profile" : [
              "http://fhir.ch/ig/ch-ig/StructureDefinition/derived-composition"
            ]
          }
        ]
      }

Would it be possible to enhance sushi that 1) constraining of slices is allowed on type.code Resource and 2) that sushi generates the slicing with type.code Resource instead of the resource type?

Thanks a lot for any feedback.

Nick Freiter (Mar 29 2021 at 12:49):

Thanks for the detailed description. To my eye, SUSHI should allow what you are doing here. It looks like we are overly restrictive on how we determine if a certain type can be used to constrain an existing type. I will log this as a bug, and we will work to fix this so that you can constrain the slice with the type.code set to Resrouce.

Nick Freiter (Mar 29 2021 at 12:54):

Here is the issue, for your reference: https://github.com/FHIR/sushi/issues/789.

Chris Moesel (Mar 29 2021 at 13:03):

I'm still wrapping my head around this issue. I think the bug @Nick Freiter logged is a good one and agree it should be fixed. I believe that is request 1) in @Oliver Egger's thread.

Regarding request 2), however... I don't think I understand why the type.code must be Resource (not Composition) for this to validate. I see that Grahame says it must be so, but I don't understand it. When SUSHI processes an only rule, if the argument is a profile, SUSHI will narrow the type.code to the profile's type (in addition to adding the profile to type.profile). I think that some authors expect this and it is definitely in use in some IGs. If we just switch the behavior to not affect type.code at all then we will be affecting other working IGs. So I'd like to understand it better before making such a change.

Until then, have you tried any tricky workarounds like using the ^ syntax to set the type or profile instead of using an only rule? For example, instead of:

* entry[Composition].resource only ChOrfComposition

have you tried:

* entry[Composition].resource ^type.profile = Canonical(ChOrfComposition)

Oliver Egger (Mar 29 2021 at 13:48):

@Chris Moesel thanks for following up. Regarding request 2) I can confirm that

* entry[Composition].resource ^type.profile = Canonical(ChOrfComposition)

sets only the profiles and leaves the code to 'Resource', so this is a very nice workaround (i am not a sushi chef yet :-)), thanks a lot.

I have seen that you posted in the old zulip thread, so looking forward why it needs to be Resource and should not be the derived type.

Oliver Egger (Mar 30 2021 at 07:45):

the workaround works also for issue 1), thanks a lot @Chris Moesel

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Support for slicing with type code 'Resource' and profile ? · shorthand