FHIR Chat · Profiles embedded in Bundle · IG creation

Stream: IG creation

Topic: Profiles embedded in Bundle

Max Masnick (Nov 06 2021 at 18:39):

I just noticed that between the STU2 ballot build for mCODE (back in April 2021) and now, it appears that the snapshot of our Bundle profile now includes the contents of the entirety of each profile under entry:sliceName.resource. Here's an example:

• The STU2 ballot build does not have any child elements off resource.
• The current CI build has an entire copy of each slices profile inside resource.

My question: Is this an intentional change? If so, what's the thinking behind this? (Apologies if I missed previous discussion on this -- I searched and couldn't find anything easily.)

Max Masnick (Nov 06 2021 at 18:42):

This is what the STU2 ballot build looks like:

image.png

Compare to the current CI build:

CleanShot-2021-11-06-at-14.41.182x.png

Max Masnick (Nov 06 2021 at 18:44):

I looked at the JSON generated by SUSHI for our profile of Bundle, and it doesn't include any of the contents of the profiles that are slices in the Bundle -- just what I would expect to see in a Bundle StructureDefinition. So I think whatever changed happened after SUSHI in the IG Publisher pipeline.

Max Masnick (Nov 08 2021 at 10:29):

@Grahame Grieve can you please take a look at this when you have a minute? We want to try to resolve this before we publish mCODE STU2 (which is close)

Grahame Grieve (Nov 08 2021 at 10:29):

it's on my lsit

Max Masnick (Nov 15 2021 at 15:36):

@Grahame Grieve we are on the agenda for mCODE STU2 publication for FMG's Nov 17 meeting...any chance you'll be able to put in a fix before then? :grinning:

(FYSA I logged https://github.com/HL7/fhir-ig-publisher/issues/334 describing this issue as well.)

Grahame Grieve (Dec 05 2021 at 19:27):

ok finally got to this. I should've looked first because I assumed that it was actually something I did. But no.

Grahame Grieve (Dec 05 2021 at 19:28):

In your STU2 ballot:

Grahame Grieve (Dec 05 2021 at 19:28):

     {
        "id" : "Bundle.entry:tumorSize.resource",
        "path" : "Bundle.entry.resource",
        "type" : [
          {
            "code" : "Observation",
            "profile" : [
              "http://hl7.org/fhir/us/mcode/StructureDefinition/mcode-tumor-size"
            ]
          }
        ],
        "mustSupport" : true
      },

Grahame Grieve (Dec 05 2021 at 19:29):

in your current draft:

Grahame Grieve (Dec 05 2021 at 19:30):

      {
        "id" : "Bundle.entry:tumorSize.resource",
        "path" : "Bundle.entry.resource",
        "type" : [
          {
            "code" : "Observation",
            "profile" : [
              "http://hl7.org/fhir/us/mcode/StructureDefinition/mcode-tumor-size"
            ]
          }
        ]
      },
      {
        "id" : "Bundle.entry:tumorSize.resource.meta.profile",
        "path" : "Bundle.entry.resource.meta.profile",
        "min" : 1,
        "patternCanonical" : "http://hl7.org/fhir/us/mcode/StructureDefinition/mcode-tumor-size"
      }

Grahame Grieve (Dec 05 2021 at 19:31):

by walking into the resource, you make it necessary for the snapshot generator to include the entire resource in the profile.

Grahame Grieve (Dec 05 2021 at 19:35):

you said:

I looked at the JSON generated by SUSHI for our profile of Bundle, and it doesn't include any of the contents of the profiles that are slices in the Bundle

by specifying content inside the target profile, you make the snapshot generator reconcile the contents of the profiles, and publish the reconciliation. So from my pov, what happened is expected

Max Masnick (Dec 10 2021 at 18:05):

Agreed, the behavior makes sense. Apologies I didn't catch this initially.

Grahame Grieve (Dec 10 2021 at 19:45):

next time I'll check immediately rather than assuming there's some nasty issue I need a clear head for. But the question is, how to do what you're trying to do more effectively

Max Masnick (Dec 14 2021 at 02:02):

@Grahame Grieve So fundamentally we are trying to make sure meta.profile is populated for resource instances within Bundle instances conforming to our "mCODE Patient Bundle" profile.

But we don't want to require meta.profile in every profile in mCODE as there may be cases where meta.profile can't be copied.

What we're doing now is slicing Bundle.entry by entry.resource.meta.profile, and then (as you say above) adding a constraint like entry[sliceName].resource.meta.profile 1..* MS. (We also make entry[sliceName].resource.meta required.)

We looked at instead doing entry.resource.meta.profile 1..* MS, but this causes errors if entry.resource 1..1 MS is set (related to entry.resource.meta.profile being an invalid element path, I believe).

If we remove entry.resource 1..1 MS so entry.resource.meta.profile 1..* MS "works", but this breaks validation of Bundles (it seems like the validator stops looking at the referenced profile if entry.resource.meta.profile is constrained in the profile of Bundle).

So unless some of this behavior is surprising to you, it seems like our current approach is the best one. However, this makes the .html page for "mCODE Patient Profile" less usable than would be ideal -- the snapshot tab is veeeeeeeeery long.

I have a sample project I can share with you if you want to reproduce any of this.

/cc @Mark Kramer @Saul Kravitz

Grahame Grieve (Dec 14 2021 at 04:05):

well, firstly:

But we don't want to require meta.profile in every profile in mCODE as there may be cases where meta.profile can't be copied.

I'm thoroughly on board with that

we are trying to make sure meta.profile is populated for resource instances within Bundle instances conforming to our "mCODE Patient Bundle" profile

why?

Grahame Grieve (Dec 14 2021 at 04:06):

let's talk about that before looking at alternative approaches - I can think of some you haven't mentioned, but the why is important in that regard

Max Masnick (Dec 14 2021 at 18:59):

@Grahame Grieve We slice Bundle.entry by resource.meta.profile because otherwise it’s hard to identify which instances in the bundle are supposed to conform with which profile. (True both for validation and for an implementer receiving one of these bundles and trying to process it.)

Specifically, we’re trying to discourage/prohibit implementers including resource instances in the Bundle that are intended to fit in one of the slices, but don’t have meta.profile populated. Our Bundle is open and most slices aren’t required, so it’s possible to this could happen.

Grahame Grieve (Dec 14 2021 at 19:02):

in other words, the resources aren't really differentiated, so there's no way for a reader of the bundle to know what's going on unless the writer specifically adds extra metadata to differentiate them?

Max Masnick (Dec 14 2021 at 19:07):

Exactly -- for example, an Observation resource might be included in the bundle but it's not meant to conform with mCODE. For someone trying to process the Bundle, they might just want the Observation resources that are meant to conform with a specific profile. They might be able to tell based on specific characteristics of the profile, but this isn't always possible or easy.

It's much simpler if the producer of the Bundle just indicates their intent (simpler at least for everyone except the producer :grinning:).

Grahame Grieve (Dec 14 2021 at 19:13):

so the core of your problem is that you are conflating "intent" with "conformance". The profile tag is a statement of conformance to a profile. So it someone adds a resource that happens to conform to the profile but doesn't meet the intent, then what?

Grahame Grieve (Dec 14 2021 at 19:18):

I suppose it's too late to consider the solution that I would think matches the intent then - the bundle can contain a set of information as specified by the mCode profiles, but possibly other content as well, and the resources themselves aren't obviously differentiated - that calls for a manifest that lays out the bundle. That's what a composition is for - gives the bundle context and structure, and who built it. And the profile on composition establishes the structure of the bundle

Grahame Grieve (Dec 14 2021 at 19:24):

you could do the same thing a little more simply with List as well

Lloyd McKenzie (Dec 14 2021 at 21:05):

Profile isn't allowed to contain information that isn't in the resource. It must always be possible to tell what profile(s) a resource complies with. And if a resource complies with multiple profiles, it should be fine to list all of them in .meta or none of them. Profile can't ever tell you what to do with a resource - you should always be able to figure that out by just looking at the data in the resource. You can use profiles as a shortcut in the validation process to figure out what something is likely valid against.

Saul Kravitz (Jan 11 2022 at 19:51):

Hi @Grahame Grieve ,
We have a proposed resolution for the issue that caused the mCODE bundle profile to blow up in size.
The solution we adopted balances the need to enumerate/constrain the contents of the bundle with the burden on the implementer.
Rather than require implementers to add a manifest to indicate the intent of inclusion of each instance, we decided to limit the specified slices in the bundle to the Cancer Patient, and establishing the expectations for content inclusion in the bundle in the narrative.

Your suggestion for a composition with a manifest seemed like a big change to make this deep in the STU2 process and should be considered once we have feedback from implementers on STU2.

@Mark Kramer @Max Masnick @Lloyd McKenzie

Grahame Grieve (Jan 11 2022 at 19:58):

well, that's not a compromise that's thrilling, but that's the nature of compromises. And I understand why selecting that compromise. I agree about the magnitude of the composition change

Saul Kravitz (Jan 11 2022 at 20:42):

Thanks for the quick response and your agreement.
We will move forward with publication. There are two spurious (based on my examination) terminology errors....

Last updated: Apr 12 2022 at 19:14 UTC