Stream: implementers
Topic: Promoting contained resources to standalone
Pascal Pfiffner (Jan 13 2020 at 18:27):
I haven't seen this scenario explicitly called out in http://hl7.org/fhir/references.html#contained : if a client creates a resource that contains another resource via POST, is it the server's call whether it pulls out the contained resource and creates a standalone resource for it (updating the reference of course) or should a server not decide that by itself and always leave contained resources as they are? Should we call out the preference and/or guidance on this scenario to the spec?
Grahame Grieve (Jan 13 2020 at 19:53):
if the client has provided a contained resource correctly - because there's not enough information to identify the contained resource - it would be futile and inappropriate to try to pull it out
Drew Torres (Jan 13 2020 at 19:56):
Can you elaborate? What determines there is or isn't enough information? If the contained resource had an identifier and others fields that the server determined could become standalone, wouldn't it be up to the server?
Lloyd McKenzie (Jan 13 2020 at 20:00):
If the contained resource has enough information to be stand alone, then it shouldn't have been sent as contained in the first place.
Lloyd McKenzie (Jan 13 2020 at 20:00):
'contained' isn't an expedient way to send multiple resources at once. It's a mechanism for sending resources that cannot live independently from their container.
Lloyd McKenzie (Jan 13 2020 at 20:01):
If you want a convenient way to send multiple resources in a single call, use a batch or transaction Bundle.
Grahame Grieve (Jan 13 2020 at 20:01):
contained resources really shouldn't contain an identifier. that would be a clear marker for someone abusing contained resources
Drew Torres (Jan 13 2020 at 20:03):
Would it be safe to say: The mechanism by which an additional resource can be sent would be up to the individual servers to decide.
Grahame Grieve (Jan 13 2020 at 20:05):
the mechanism?
Drew Torres (Jan 13 2020 at 20:08):
Batch vs post vs operation as an example.
Grahame Grieve (Jan 13 2020 at 20:10):
well, it can be up to individual servers, or it may be specified in some IG
Grahame Grieve (Jan 13 2020 at 20:10):
or it may be implied by the rules in the specification
Drew Torres (Jan 13 2020 at 20:11):
Fair enough. Then it really is up to the IG/Server to decide how handle the situation then.
Drew Torres (Jan 13 2020 at 20:12):
Example would be serviceprovider on encounter.
Drew Torres (Jan 13 2020 at 20:15):
The client may have a name/identifier for an organization, but nothing else. The server may deem that is sufficient for a standalone resource. Since organization (and many FHIR resources) doesn't require any fields, I thought the comment determining sufficient data was interesting because there isn't much required in that example. So one server may say post the organization first, another may say batch, and another may something else.
Grahame Grieve (Jan 13 2020 at 21:16):
in principle you are correct. The server is always on slippery ground when it's double thinking the client, but there's circumstances in which it can be known to be safe.
Michele Mottini (Jan 13 2020 at 21:42):
Our server (as many other I am sure) has no concept of contained resources, so if we receive such a thing the options are either reject or try to convert the contained into a 'proper' stand alone resource - and we do both depending on the case
Drew Torres (Jan 13 2020 at 22:15):
That is the type of behavior I would have thought would have been "standard", but in the case where you create a resource, what do you respond with on a subsequent get of the resource? Still the contained, or using the reference datatype you reference the "real" resource?
Grahame Grieve (Jan 13 2020 at 22:20):
the second
Drew Torres (Jan 13 2020 at 22:21):
That is what I would expect as well.
Lloyd McKenzie (Jan 13 2020 at 22:26):
Clients sending resource A that contains resource B should generally expect to get back what they submit. And they should expect that querying directly for B won't return anything (unless they use an advanced search mechanism that isn't widely supported). If the server that receives A happens to be able to figure out how to get B to stand alone, they're permitted - but not required to break it out and store it as an independent resource - or change the link to be an existing standard resource. (Just as they're permitted to change other data in the received resource based on 'special' knowledge or business rules they might have.) Any system that makes such changes must be aware that doing so may invalidate any digital signatures present in the instance or elsewhere that refer to the resource.
Michele Mottini (Jan 13 2020 at 22:28):
Yes, in the cases where we process a contained resource we convert it to a stand-alone one, and that's what the client would see - a separate resource, no longer a contained one
Paul Church (Jan 13 2020 at 22:52):
What does the client see in the response to the create when that conversion happens? It seems to me you can only return one resource at that point, even if multiple full resources were created.
Lloyd McKenzie (Jan 13 2020 at 22:56):
You would see what was stored in the 'created' resource (if you get back a copy) or warning messages about what changes occurred if you don't. If a contained reference got changed to a 'real' resource, you'd see the reference to whatever was pointed to (whether a newly created instance or something that existed before).
Grahame Grieve (Jan 13 2020 at 22:57):
right. you see the focus resource returned as the server accepted it. Which means, in this case, the contained resources removed, and the references updated to the new location of the resource that was contained when submitted by the client
Eric Haas (Jan 14 2020 at 01:22):
On a subsequent PUT operation, I am assuming the server will update both the focus resources and newly created ones?
René Spronk (Jan 14 2020 at 08:29):
Note that a contained resources could be promoted to a stand-alone one at any point in time, not just when the resource is posted.
Brian Postlethwaite (Jan 15 2020 at 10:18):
That's fun in the update. Was that an update to the existing, or a new one altogether. If you remove the reference and contained, does the server remember to cleanup the separate resource that is no pinger referenced?
Lots of fun little gotchas. Just like patient contacts in v2 adt messages.
René Spronk (Jan 15 2020 at 10:23):
Given that a contained resource doesn't have an identifier, one would have to assume some sort of 'snapshot' behaviour on the part of the client. But containment is not about grouping for the 'sole reason of grouping', so FHIR doesn't see snapshot as a valid behavior on the part of the client when containing resources.
If Client A sends a resource to a server, then who knows what other clients, or the server based on its own logic, will do/modify/delete that resource? There can't be any expectation on behalf of A that the server will leave "their" resource alone, unless there is some explicit agreement between a server and a client prior to the post by A of a resource.
Last updated: Apr 12 2022 at 19:14 UTC
