FHIR Chat · Extensions on inherited elements · shorthand

Stream: shorthand

Topic: Extensions on inherited elements


view this post on Zulip Gino Canessa (May 22 2020 at 16:03):

Morning all, I'm running into an issue and was wondering if I have something wrong or if this isn't supported in sushi (yet).

For context, I'm profiling the subscriptions backport, which includes extensions on Bundle.meta, which is inherited from Resource and not explicitly listed in the Bundle resource. So my rules like:

* meta.extension contains BackportSubscriptionEventCount named subscriptionEventCount 1..1

Returns an error:

error No element found at path meta.extension for BackportSubscriptionNotification, skipping rule

Any help/advice would be appreciated, thanks!

view this post on Zulip Nick Freiter (May 22 2020 at 17:20):

This doesn't look like something that isn't supported, so I'm not sure what is going on here. As an example, the following seems to work well for me:

Profile: MyBundle
Parent: Bundle
* meta.extension contains myslice 0..1

view this post on Zulip Nick Freiter (May 22 2020 at 17:21):

So I suspect there is something more going on here. Could you share more of the FSH definition so we can try to recreate this?

view this post on Zulip Gino Canessa (May 22 2020 at 19:25):

Thanks for the help Nick. I setup a sushi dev environment so I could step through and see what was happening.... and found it was an error on the previous line causing the issue:

* ^type = "history"

Thanks again!
Edit: not sure where I grabbed the caret from, but removing it fixed the issue.

view this post on Zulip Nick Freiter (May 26 2020 at 13:50):

Oh interesting. The caret syntax is used to set metadata on the Structure Definition itself. It would usually be used for setting something like the publisher, description, contact, or status. In this case you set StructureDefinition.type, to history, but you are making a profile of Bundle, so StructureDefinition.type should really be Bundle. In several places in SUSHI we depend on the fact that if you are making a Profile of Bundle, the type will be Bundle. It seems like we should probably disallow setting StructureDefinition.type on a Profile altogether, since I'm not sure any good can come of it...Anyway, thanks for the find!


Last updated: Apr 12 2022 at 19:14 UTC