Stream: implementers
Topic: de-containment
René Spronk (Jan 25 2021 at 08:45):
Assuming one has a FHIR server that natively supports FHIR resources: if such a server is "updated' (by whatever FHIR-based method), when would one choose to 'de-contain' any contained resources? (A) If a contained resource (in the inbound data) already exists on the server (=can somehow be merged with an existing stand alone resource), (B) if the contained resource can be matched with some master data registry on some other FHIR server, .. any other footnotes / comments on a scenario like this ?
Lin Zhang (Jan 25 2021 at 10:22):
Good Question!
Vassil Peytchev (Jan 25 2021 at 13:07):
Somehow "never" seems to be at the top of the list of answers I can come up with...
René Spronk (Jan 25 2021 at 13:09):
Interesting - why?
Vassil Peytchev (Jan 25 2021 at 13:33):
I think because it introduces non-determinism - at one point I get a resource with contained content, at a later point that disappears. I think there are a lot of questions that need to be answered before a more concrete response can emerge, for example, how does the data get in the FHIR server? Is the use of contained resource profiled in an implementations guide? etc.
René Spronk (Jan 25 2021 at 13:38):
Hmm - yes, as always there are caveats. However, generally speaking, de-containing contained resources sounds like the proper thing to do, for it enhances referential integrity between resources, and in terms of 'data quality management' in helps to increase the overall quality and consistency of the data.
Lloyd McKenzie (Jan 25 2021 at 15:31):
A client can't ever have any expectation for de-containment. And typically there shouldn't be enough identifiable information in the contained resource to allow decontainment - if there is, it likely shouldn't have been contained in the first place. Containment should never be used as a mechanism to allow posting a single resource instead of multiple. If you want to do that, use transaction.
Lloyd McKenzie (Jan 25 2021 at 15:32):
If the sender sends something as contained, they're saying "this contained resource doesn't have any independent identity or relevance outside the scope of the containing resource". Ignoring that assertion is risky
René Spronk (Jan 26 2021 at 09:31):
I'm aware it's risky - but I'm also aware that clients may not play by the FHIR rules and contain things that shouldn't have been contained. Or rather: which in the limited scope of the client make sense to be contained, but which in the extended/larger scope of an EHR don't make sense to be contained.
Detlef Kraska (Jan 26 2021 at 09:45):
We had a similar discussion at our site when we talked about merging patient ressources from two different source systems in one FHIR server. Both systems use the same patient ID, but different FHIR profiles with different extensions for the patient ressource. To perform such a merge, you need business logic that is aware of the profiles and the context. I don't think a FHIR server can handle this on its own.
Lloyd McKenzie (Jan 26 2021 at 14:31):
Servers have full flexibility to do what they like with requests. They can throw data away, supplement it, change it. The key here is that the client can't have expectations about what's going to happen. If a client says "I'm going to contain this resource for convenience and expect the server to un-contain it", that's non-conformant. If a server says "this thing that you thought wasn't identifiable and had no independent existence, I can identify and choose to treat as independent", that's legitimate, though tricky. It may make subsequent updates from that client harder or impossible.
René Spronk (Jan 26 2021 at 14:41):
My point is, that if a server has the capabilities and logic to support it, it's (in general) desirable to de-contain, or to merge, given that this raises the overall quality level of your data. Would you agree with that statement ?
Lloyd McKenzie (Jan 26 2021 at 14:47):
I think it's use-case specific. If I receive two patient records that I think are talking about the same individual, there are times when merging them is totally appropriate. In other cases, I may very well want them kept separate - for privacy or other reasons.
John Moehrke (Jan 26 2021 at 16:15):
one specific use of containment that IHE leverages is within MHD/XDS to persist the patient demographics "at the time the document was published". There is a link to a managed Patient, that is expected to evolve with the patient demographics changes. The contained source patient information is explicitly contained so as to NOT be changed. Thus it represents the patient "as known" by the publisher of the document at the time the document was published.
John Moehrke (Jan 26 2021 at 16:18):
another I have seen is when there is supporting information, like Location, but where the data entered is not sufficient to match a managed supporting information....
John Moehrke (Jan 26 2021 at 16:19):
but I do recognize that there might be use-cases where there is sufficient information to de-contain, and policy that supports de-containment. right?
Grahame Grieve (Feb 02 2021 at 21:48):
it may be possible for a server to perform de-containment. The grounds on which this would be possible are that the server has access to business logic - specifically, statements about uniqueness that can be verified against some repository - that the client does not.
Joe Lamy (May 04 2021 at 01:33):
I'd like some clarification on something. If a server de-contains a POSTed resource within a transaction, then there is an extra resource. I'm assuming we would definitely want to keep the 1-1 correspondence between entries in the request and entries in the response, so a server should not (shall not?) add an extra 201 to the response entries.
Grahame Grieve (May 04 2021 at 02:51):
not, it can't. Like it couldn't if it was posted directly.
Joe Lamy (May 04 2021 at 03:16):
Perfect, thanks.
Lloyd McKenzie (May 04 2021 at 03:33):
The base resource would just change the reference. The client would have to resolve the reference to see what the de-contained resource had been resolved to.
Last updated: Apr 12 2022 at 19:14 UTC
