Stream: implementers
Topic: nested contained
Emre Avsar (Sep 21 2017 at 14:05):
Is it possible to have a resource, which has a contained resource which has another contained resource inside?
Jeffy Mathew Jose (Sep 21 2017 at 15:12):
No, see reference
Yunwei Wang (Sep 21 2017 at 15:21):
Contained resources SHALL NOT contain additional contained resources.
Jenni Syed (Sep 21 2017 at 16:19):
I'm trying to find previous discussion on this - it may not have been on zulip. will keep looking
Jenni Syed (Sep 21 2017 at 16:19):
The way this would work is that primary resource essentially "contains" all of them
Jenni Syed (Sep 21 2017 at 16:20):
the contained resource would then reference the other contained... I thought
Eric Haas (Sep 21 2017 at 17:55):
What Jenni describes is demonstrated in this example: http://build.fhir.org/diagnosticreport-micro1.xml.html several of the contained Observations reference other contained observations.
Eric Haas (Sep 21 2017 at 17:56):
which are all contained within a single DiagnosticReport resource
Emre Avsar (Sep 22 2017 at 12:22):
ah i see thanks. well the problem is, that the parent resource does not know all details about it's children, and of it's grand children.
Emre Avsar (Sep 22 2017 at 12:23):
that's why i was interested in nested contained, but therefore i need a custom resource anyway
Yunwei Wang (Sep 22 2017 at 13:14):
You can add all resources in a Bundle and use reference at where you need, just like a Composition.
Jeffy Mathew Jose (Sep 22 2017 at 13:20):
Parent resource need not know about all contained resources directly.
@Emre Avsar , Can you share your case? Maybe we can reach to some better understanding.
Emre Avsar (Sep 22 2017 at 13:41):
@J Mathew Jose yes. here's my case:
I have the following internal domain:
Discussion Topics (will be a RiskAssessment in FHIR) with DiscussionTopicConfigurations (here i wanted to use a Basic reference as contained)
Discussion Topics have a list of Observations to have a base on what this discussion topic is about. and these observations have also a ObservationConfiguration inside.
when I have something like this now:
DiscussionTopic with a configuration with 3 observations with 1 observation configuration for each, and this has to be converted to fhir domain now.
i wanted to have something like
RiskAssessment with contained DiscussionTopicConfiguration, and a bunch of observations which are also contained and inside these contained observations i would have the contained observationconfiguration.
so it seems i have to create my own RiskAssessment extension with custom fields in it, rather than using contained. correct?
Jeffy Mathew Jose (Sep 22 2017 at 14:15):
@Emre Avsar
The idea is that the parent resource will have all the contained resources, while the children and grandchildren has reference to them.
So for your case, RiskAssessment will contain DiscussionTopicConfiguration, observations and their observationconfigurations.
RiskAssessment will refer to DiscussionTopicConfiguration and observations, while each observation will have reference to its observationconfigurations respectively
See quoted link for a detailed example
What Jenni describes is demonstrated in this example: http://build.fhir.org/diagnosticreport-micro1.xml.html several of the contained Observations reference other contained observations.
Emre Avsar (Sep 22 2017 at 14:17):
the problem is, that the converter which converts discussion topics to risk assessments does not contain the logic for converting observationconfiguration to a containted element. it only uses another converter to convert. so it has no knowledge of nested elements. that makes things a bit problematic. assume that this discussion topic is now embedded inside a episodeofcare resource, then the episode of care converter must check all nested elements and extract those and put them into it's contained field. this makes life harder. therefore this is not the approach i think which works out for my case. am i wrong?
Yunwei Wang (Sep 22 2017 at 14:31):
@Emre Avsar Root resource doesn't need to know how to convert all nested children. Each resource only need to convert itself and asks its direct children to convert.
Emre Avsar (Sep 22 2017 at 14:36):
so, each converter does then convert nested elements and put them to contained, and then you have nested contained elements.
Yunwei Wang (Sep 22 2017 at 15:22):
All contained resources are added in root resource. Only references to children are used inside parent resource.
Jeffy Mathew Jose (Sep 22 2017 at 15:49):
Before adding a resource to your parent container, move all the contained resources to parent container.
Lloyd McKenzie (Sep 22 2017 at 17:34):
You may also need to do processing to ensure that the ids of the contained resources remain unique when you move them up to the new containing resource.
Emre Avsar (Sep 25 2017 at 05:11):
that just does not work well. a nested object's container does not now anything about it's parent. this is just bad design, if i go this way. what i could do would be something like a go through all nested objects and move the contained elements to the root in a separate step, but this sounds like a lot of traversing work for nothing.
Lloyd McKenzie (Sep 25 2017 at 05:24):
In general, if you have contained resources, it's because they're acting like "properties" of the containing resource anyhow. The decision to contain a resource is because you don't have enough information for the resource to stand alone. I don't really understand why the containing resource wouldn't know about the contents of the resources it "owns". (Remember that containment isn't a packaging mechanism for transport - it's only for use when the contained content is inherently dependent on the containing resource for existence.)
Emre Avsar (Sep 25 2017 at 06:02):
Or rather than creating new resources, I could also go for this http://hapifhir.io/doc_custom_structures.html#Custom_Datatype_Structure right?
Emre Avsar (Sep 25 2017 at 06:03):
extending a datatype to hold multiple values in it
Lloyd McKenzie (Sep 25 2017 at 06:20):
That would be outside the standard and wouldn't interoperate with anyone with a standard FHIR interface. If your data is expressible with FHIR resources, you should use those resources. If your data isn't expressible with FHIR resources, you have a choice of operating outside the standard or using the Basic resource with a bunch of extensions.
Emre Avsar (Sep 25 2017 at 06:40):
thanks @Lloyd McKenzie that was also what i thought. alright. i'll go for custom resources anyway. since i cannot guarantee the contained objects to be in the root only
Jeffy Mathew Jose (Sep 25 2017 at 06:57):
Let me clarify
Say, we have types X->Y->Z in your domain which are mapped to A->B->C in FHIR. (arrow in direction of containment)
Also, mappings from X<->A, Y<->B, Z<->C are defined except for children(contained resources)
Now when Y is mapped to B, call Z<>C mapper, add C in B.Contained, add reference to C from appropriate property in B.
When X is mapped to A, call Y<>B mapper (defined above), add B in A.Contained, move everything from B.Contained to A.Contained, add reference to B from appropriate property in A.
You may also need to do processing to ensure that the ids of the contained resources remain unique when you move them up to the new containing resource.
For your case, before adding observations containing observationconfigurations to RiskAssessment, move everything from observation.Contained to RiskAssessment.Contained
Lloyd McKenzie (Sep 25 2017 at 07:48):
@Emre Avsar If you're going with custom resources, why are you using FHIR? You won't interoperate with anyone, which is sort of the point. Can you explain why you need contained resources? And why it's a problem for the logic that deals with containment to "migrate" inner contained resources to the outer containing resource? It may be a bit more code, but it's not more work than custom resources - and your interface will actually interoperate with other systems.
Emre Avsar (Sep 25 2017 at 08:30):
the custom resources will only extend Basic and all the stuff goes into extensions.
This part of the API is just too custom, it's like the 20% where the stuff has to be done custom. If there would be a matching resource, i'd take it. but there isnt.
Emre Avsar (Sep 25 2017 at 08:34):
in my case, it is more like a configuration which needs to be sent to the client, to know which things (for example observations) and how (coding, values etc.) are needed.
I'd love to take something more FHIRy but don't know really what
Emre Avsar (Sep 25 2017 at 08:35):
the only 'better' solution is the one with traversing all the children, find all the contained elements and put them to the root. and work with all these things, don't forget to put the contained into childs if only a child needs to be passed somewhere in the codebase etc. this sounds like a nightmare, not only more code
Lloyd McKenzie (Sep 25 2017 at 14:33):
Ok. If you're doing something that's outside the spec, Basic is fine. I'm a bit confused how that requirement is linked to "contained" resources though.
Last updated: Apr 12 2022 at 19:14 UTC
