Stream: shorthand
Topic: contained resources of different types
David Hay (Apr 21 2020 at 03:27):
I'm trying to add contained resources to an instance - where the contained resources are of different types, but getting the error:
error Cannot fix Resource value on this element since this element does not have a single type
Is this a sushi limitation?
* contained[0] = medicalHistoryEmpty * contained[1] = adverseReactionEmpty * contained[2] = immunizationEmpty * contained[3] = medicineListEmpty
The referenced instances are instances of profiled List resources
Chris Moesel (Apr 21 2020 at 05:23):
Hmmmm. I thought we had tested this situation, but maybe you found an edge case? Are you using SUSHI 0.12.2 (released on Friday)? That's the release that Ithought addressed this...
David Hay (Apr 21 2020 at 05:31):
Yep - 0.12.2 ...
Nick Freiter (Apr 21 2020 at 11:50):
What does the contained
element look like on the StructureDefinition that you are making an instance of? It looks like SUSHI is taking issue with the types on contained
. Does contained
have more than a single type? Or is that error incorrect altogether?
Nick Freiter (Apr 21 2020 at 14:24):
So what I'm guessing is happening here is that the contained
element on the Profile you are making an instance of is constrained to be a choice of several types of Resources. In other situations, SUSHI does not allow you to set an element that is a choice equal to a single value. As in you can't set value[x]
equal to some specific string, you must instead set valueString
. That logic was being applied to this situation as well. We would not let you set a specific value, since contained
is a choice of types. But I now see resources cannot be treated the same as other data types, so we should allow you to set resources inline into that contained
array, as long as their resourceType
matches one of the types of the contained
array. I've made an issue to track this here: https://github.com/FHIR/sushi/issues/377.
Nick Freiter (Apr 21 2020 at 14:27):
This is all assuming that the Profile you are making an instance of does have some choice of several types on its contained
array. If that is not the case, then all of the above is just a bonus that you've helped us discover!
David Hay (Apr 21 2020 at 18:52):
So this is the ancestor profile I'm constraining from : http://hl7.org.au/fhir/aubase1/StructureDefinition-au-composition.json.html
It has some constraints on contained - but not restricting to one type I believe. The actual profile doesn't constrain contained any further.
I can add one instance to contained (an instance of a profiled List) but cannot add an instance of another List profile...
David Hay (Apr 21 2020 at 18:53):
So sorry, glad to have helped with the bonus, but I don't think it's the issue here!
Chris Moesel (Apr 21 2020 at 20:37):
OK... so you're attempting to apply different profiles of the same resource (List). Maybe that's the difference here... I'm not sure if we've tested that -- although I would not have expected it to be a problem! We can take a look. Thanks for your patience!
David Hay (Apr 21 2020 at 23:30):
no worries! Thanks (as always) for your work on this...
Nick Freiter (Apr 22 2020 at 12:58):
After some further investigation, this just looks like a bug with how we are handling arrays of contained resources. It doesn't seem like there is anything specific to the profiles that is causing this. I've started work on a fix. Thanks for the find! (And the bonus)
David Hay (Apr 22 2020 at 17:53):
you're welcome!
Last updated: Apr 12 2022 at 19:14 UTC