FHIR Chat · Profile on Profile with core resources · shorthand

Stream: shorthand

Topic: Profile on Profile with core resources


view this post on Zulip John Moehrke (Jan 14 2021 at 00:00):

I have a profile that is defining a slice in Bundle for a couple of my profiles, but also a couple of core resources. Sushi seems to be treating the core resources differently, and not calling upon the core resource structureDefinition. See https://github.com/IHE/ITI.MHD/blob/master/input/fsh/provideBundle.fsh

view this post on Zulip John Moehrke (Jan 14 2021 at 16:06):

it seems that sushi did not like when I profiled the bundle by #profile, but sometimes using a core FHIR Resource (e.g. Binary and Patient). So I tried to do this in two different levels of profile. One level (dummy) that profiles by resource type, the second by profile... This second attempt fails differently in the IG build.

https://github.com/IHE/ITI.MHD

specifically this FSH file
https://github.com/IHE/ITI.MHD/blob/master/input/fsh/provideBundle.fsh

which sushi does create this structureDefinition that the build is failing on
http://build.fhir.org/ig/IHE/ITI.MHD/branches/master/failure/fsh-generated/resources/StructureDefinition-IHE.MHD.Comprehensive.ProvideBundle.json

view this post on Zulip John Moehrke (Jan 14 2021 at 16:07):

I really want to be able to do it the first way I did...

* entry contains
    SubmissionSet 1..1 and
    DocumentRefs 0..* and
    Documents 0..* and
    Folders 0..* and
    Patient 0..1
* entry[SubmissionSet].resource only
    IHE.MHD.Minimal.SubmissionSet or
    IHE.MHD.UnContained.Comprehensive.SubmissionSet or
    IHE.MHD.Comprehensive.SubmissionSet
* entry[SubmissionSet] ^short = "the SubmissionSet"
* entry[SubmissionSet] ^definition = "The SubmissionSet defines who submitted it, why they submitted it, when they submitted, what is in it, and where it is destine."
* entry[SubmissionSet].request 1..1
* entry[SubmissionSet].request.method = #POST
* entry[DocumentRefs].resource only
    IHE.MHD.Minimal.DocumentReference or
    IHE.MHD.UnContained.Comprehensive.DocumentReference or
    IHE.MHD.Comprehensive.DocumentReference
* entry[DocumentRefs] ^short = "the DocumentReference resources"
* entry[DocumentRefs] ^definition = "any and all DocumentReference that are part of the SubmissionSet. These might be new, replacements, or other associations"
* entry[DocumentRefs].request 1..1
* entry[DocumentRefs].request.method = #POST
* entry[Documents].resource only Binary
* entry[Documents] ^short = "the documents"
* entry[Documents] ^definition = "the documents referenced by the DocumentReference resources"
* entry[Documents].request 1..1
* entry[Documents].request.method = #POST
* entry[Folders].resource only
    IHE.MHD.Minimal.Folder or
    IHE.MHD.Minimal.Folder
* entry[Folders] ^short = "Folders"
* entry[Folders] ^definition = "any Folders being created or updated"
* entry[Folders].request 1..1
* entry[Folders].request.method = #POST
* entry[Patient].resource only Patient
* entry[Patient] ^short = "the Patient"
* entry[Patient] ^definition = "the Patient"

view this post on Zulip John Moehrke (Jan 14 2021 at 16:39):

It appears Moehrke-Research has come thru with a workaround... in my profile slice using #profile. I just explicitly point at the FHIR structureDefinition for the resources I mean...

* entry[Documents].resource only http://hl7.org/fhir/StructureDefinition/Binary

view this post on Zulip John Moehrke (Jan 14 2021 at 16:39):

so note to others wanting to profile slice by #profile and use core resources, you just need to be explicit and not expect sushi is going to do the smart thing (until some future release of sushi... I would guess).

view this post on Zulip Chris Moesel (Jan 14 2021 at 16:59):

I'm not sure I fully understand what you mean. Are you saying that this did not work:

* entry[Documents].resource only Binary

but this did?

* entry[Documents].resource only http://hl7.org/fhir/StructureDefinition/Binary

Because if that's the case, I am surprised -- and think that's probably a bug to be fixed. But if that's not what you're saying, can you elaborate on what _didn't_ work and what you needed to do to make it work?

view this post on Zulip Chris Moesel (Jan 14 2021 at 17:01):

I guess I'm not fully clear on what is "the smart thing" that we should consider implementing in SUSHI. Which makes it hard to implement it. ;-)

view this post on Zulip ryan moehrke (Jan 14 2021 at 17:14):

the issue that we ran into was not that "* entry[Documents].resource only Binary" wasn't recognized by sushi, just that it only populated the ElementDef.type and not ElementDef.type.profile element, meaning that slicing by profile had nothing to work with.

view this post on Zulip Chris Moesel (Jan 14 2021 at 17:26):

But using the full URL to Binary forced SUSHI to populate the profile field too? If so, I also find that surprising...

view this post on Zulip Chris Moesel (Jan 14 2021 at 17:30):

Based on discriminator docs I think that technically you are supposed to use #type discriminator for non-profiled resources and #profile discriminator for profiled resources. @John Moehrke -- did you try using a composite discriminator like this?

* entry ^slicing.discriminator[0].type = #type
* entry ^slicing.discriminator[0].path = "resource"
* entry ^slicing.discriminator[1].type = #profile
* entry ^slicing.discriminator[1].path = "resource"

I'm not positive it would work, but I think so?

view this post on Zulip ryan moehrke (Jan 14 2021 at 17:34):

honestly I didn't see the canonical url working myself, I did something similar for a different reason and I had to use the carrot overrides
as for why we weren't jumping on #type, the other 3/5 slices explicitly use profile, we were considering using both but I didn't know how well that was going to work

view this post on Zulip Chris Moesel (Jan 14 2021 at 17:37):

I think that if you use >1 discriminator, it discriminates on the combination of them together -- so I think it should work and seems more valid to me than trying to get a resource to specify the profile field.

view this post on Zulip John Moehrke (Jan 14 2021 at 17:44):

IG build didn't like two different slices. so the workaround is what I am going forward with for now

view this post on Zulip Jens Villadsen (Jan 15 2021 at 17:44):

Hmmm ... @John Moehrke I'm trying to do something similar to you: to profile a bundle (in my case its a message bundle), and I do discrimination on type and resource (like you do on https://github.com/IHE/ITI.MHD/blob/a2354642807a8d0cb9b119c5869a5e21dc87a0e8/input/fsh/provideBundle.fsh#L22).

Now, I can't get it to work, and If I do the following (this is on your work, and I don't know if it is supposed to work):

java -jar validator_cli.jar bundle.json -version 4.0 -ig http://build.fhir.org/ig/IHE/ITI.MHD/branches/master -profile http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.ProvideBundle

-where bundle.json is http://build.fhir.org/ig/IHE/ITI.MHD/branches/master/Bundle-ex-minimalProvideDocumentBundle.json - I see the exact same errors as I see in my own project (https://chat.fhir.org/#narrow/stream/179166-implementers/topic/validation.20quirks). I've tried to change nuts and bolts but I cant get it to work

The errors by the validator are the following:

FHIR Validation tool Version 5.2.13 (Git# 5f67b5bad03d). Built 2020-12-24T05:16:59.673Z (22 days old)
  Java:   15 from /Library/Java/JavaVirtualMachines/adoptopenjdk-15.jdk/Contents/Home on x86_64 (64bit). 4096MB available
  Paths:  Current = /Users/jvi/dk-medcom, Package Cache = /Users/jvi/.fhir/packages
  Params: bundle.json -version 4.0 -ig http://build.fhir.org/ig/IHE/ITI.MHD/branches/master -profile http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.ProvideBundle
Loading
  Load FHIR v4.0 from hl7.fhir.r4.core#4.0.1 - 4575 resources (00:04.0901)
  Load hl7.terminology#2.0.0 - 3749 resources (00:00.0987)
  Terminology server http://tx.fhir.org - Version 1.9.369 (00:02.0081)
  Load http://build.fhir.org/ig/IHE/ITI.MHD/branches/master - 33 resources (00:04.0633)
  Get set...  go (00:00.0031)
Validating
  Profiles: [http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.ProvideBundle]
  Validate bundle.json 00:00.0871
Done. Times: Loading: 00:12.0989, validation: 00:00.0871

*FAILURE*: 8 errors, 0 warnings, 1 notes
  Error @ Bundle.entry[1].resource.ofType(List) (line 76, col19) : Multiple profiles found for contained resource. This is not supported at this time. (Type List: http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.Folder, http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.Folder)
  Error @ Bundle.entry[2].resource.ofType(DocumentReference) (line 117, col31) : Multiple profiles found for contained resource. This is not supported at this time. (Type DocumentReference: http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference, http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.UnContained.Comprehensive.DocumentReference, http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Comprehensive.DocumentReference)
  Error @ Bundle.entry[0] (line 19, col6) : Slicing cannot be evaluated: Profile based discriminators must have a type with a profile (Bundle.entry:Documents.resource in profile http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.ProvideBundle)
  Error @ Bundle.entry[0] (line 19, col6) : Slicing cannot be evaluated: Profile based discriminators must have a type with a profile (Bundle.entry:Patient.resource in profile http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.ProvideBundle)
  Error @ Bundle.entry[1] (line 42, col6) : Slicing cannot be evaluated: Profile based discriminators must have a type with a profile (Bundle.entry:Documents.resource in profile http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.ProvideBundle)
  Error @ Bundle.entry[1] (line 42, col6) : Slicing cannot be evaluated: Profile based discriminators must have a type with a profile (Bundle.entry:Patient.resource in profile http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.ProvideBundle)
  Error @ Bundle.entry[2] (line 97, col6) : Slicing cannot be evaluated: Profile based discriminators must have a type with a profile (Bundle.entry:Documents.resource in profile http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.ProvideBundle)
  Error @ Bundle.entry[2] (line 97, col6) : Slicing cannot be evaluated: Profile based discriminators must have a type with a profile (Bundle.entry:Patient.resource in profile http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.ProvideBundle)
  Information @ Bundle (line 2, col2) : Bundle.entry:SubmissionSet: Unable to check minimum required (Bundle.entry) due to lack of slicing validation (from http://ihe.net/fhir/ihe.mhd.fhir/StructureDefinition/IHE.MHD.Minimal.ProvideBundle)

view this post on Zulip Jens Villadsen (Jan 15 2021 at 17:47):

Looking at the generated structuredefs, it seems correct to me, but I could be wrong. @Chris Moesel would you happen to have an example of a bundle being profiled where the discriminator.type is #profile and path is resourcewhere the validator doesn't complain, that is done using FSH?

view this post on Zulip John Moehrke (Jan 15 2021 at 21:07):

here is my FSH profile details https://github.com/IHE/ITI.MHD/blob/master/input/fsh/provideBundle.fsh

view this post on Zulip Chris Moesel (Jan 15 2021 at 23:25):

Hi @Jens Villadsen -- I haven't tried anything like that myself, but I think I recall seeing something like it in mCODE. So... here's something in mCODE that might be what you're looking for?

Note that the bundle SD uses the slicing definition here. I haven't run it myself, but here's the QA from the last auto build.

view this post on Zulip Jens Villadsen (Jan 16 2021 at 09:12):

@John Moehrke Here's the thing: the IG process/qa page doesn't flag the error. The errors shown above are from your IHE IG, John, using the validator on the example resources. Where the real issue is located I do not know

view this post on Zulip Jens Villadsen (Jan 16 2021 at 10:27):

@Chris Moesel running curl http://build.fhir.org/ig/HL7/fhir-mCODE-ig/branches/master/Bundle-scenario1-mcode-patient-bundle.json -o mcode.json && java -jar validator_cli.jar mcode.json -version 4.0 -ig http://build.fhir.org/ig/HL7/fhir-mCODE-ig -profile http://hl7.org/fhir/us/mcode/StructureDefinition/mcode-patient-bundle works as intended. No errors there

view this post on Zulip Jens Villadsen (Jan 16 2021 at 15:19):

whoops - I'm sorry - I can see that I didn't inspect the http://build.fhir.org/ig/IHE/ITI.MHD/qa.html#_scratch_ig-build-temp-FDM7HC_repo_fsh-generated_resources_Bundle-ex-minimalProvideDocumentBundle thoroughly as I can see that the QA page already complains. @John Moehrke I assume this is part of your current issue.

view this post on Zulip John Moehrke (Jan 18 2021 at 14:00):

that is my current set of errors, not the ones I originally had.

I am not sure how to do what I need to do. I have a Bundle that can't contain anything other than 4 resource types, two of those must be specific profiles.

I have tried to have a core profile that just picked the four resources, then profiled that to further refine to the two profiles. But this fails in the IG build.

view this post on Zulip Jens Villadsen (Jan 18 2021 at 14:06):

So far - it seems like your errors @John Moehrke are not directly related to mine. Mine seems to be focused on the fact that I've profiled the aggregation mode and my bundles are of type message. As you can see on my lates findings on https://chat.fhir.org/#narrow/stream/179166-implementers/topic/validation.20quirks , the Davinci IQ seems to have the same issues, but no one have responded yet. So my errors are probably not related to fsh

view this post on Zulip John Moehrke (Jan 18 2021 at 14:38):

I don't think mine are related to FSH either. except that when we all get these bundle profiling figured out, there will likely be some new features to be added to sushi


Last updated: Apr 12 2022 at 19:14 UTC