Stream: implementers
Topic: Is a server allowed to include referenced resources
Ardon Toonstra (Sep 29 2021 at 11:40):
Is a server allowed to add referenced resources in the returned searchset Bundle (with a .entry.search.mode = include) without the client actually using the _include parameter in the request?
Josh Mandel (Sep 29 2021 at 13:14):
I don't believe we forbid this, but it's the kind of behavior that can lead to brittle clients
Josh Mandel (Sep 29 2021 at 13:14):
(they'll start making assumptions that work in one environment and will fail elsewhere.)
Chris Moesel (Sep 29 2021 at 13:20):
I'd also be concerned about unsuspecting clients misinterpreting the results. While it is good practice to check the entry.search.mode, I'm willing to bet there are clients that don't (or only do if they've specifically requested _include). It would probably be bad (in some cases) for clients to treat unexpected include resources like match resources.
Ardon Toonstra (Sep 29 2021 at 13:24):
To give more insight into our use case in the Nederlands (MedMij): we have a mixed environment of servers that are truly restful and ones that are based on facades and do not have an endpoint for everything. We state that all references should be resolvable. Servers can choose to support this by either allowing a read or include the referenced resource straight away in the Bundle. In this case, you would have them as contained resources or as included entries in the Bundle. The latter seems a better solution. Do you agree?
Josh Mandel (Sep 29 2021 at 13:30):
@Chris Moesel that's a really good point. In theory defensive clients would be consistent in checking bundle self links and entry modes before processing results; in practice I expect these checks happen ~never. (Are there other checks a client should do here? Was discussing with @Gino Canessa that this would be a good subject for a tutorial video or blog.)
Michele Mottini (Sep 29 2021 at 19:42):
would be consistent in checking bundle self links and entry modes before processing results
Our clients definitely do _not_ do that when processing generic search result - it expects that references are resolvable via REST call, not in the bundle
Vassil Peytchev (Sep 29 2021 at 20:56):
Would the use case for the Netherlands be better served by requiring unresolvable-via-REST references to use identifiers?
Josh Mandel (Sep 30 2021 at 01:34):
You'd still have the problem of returning them as Bundle.entry[] elements right alongside the "match" results, right?
Grahame Grieve (Sep 30 2021 at 02:06):
well, we can't mandate that systems aren't brittle. You can return included resources now, since we didn't say that you can't. I'd just document the issue clearly in the IG
Lloyd McKenzie (Sep 30 2021 at 02:11):
It might be worthwhile making that possibility explicit in the spec - change request @Ardon Toonstra ?
Josh Mandel (Sep 30 2021 at 03:51):
We can't mandate that clients aren't brittle, but it might still be good for us here in the chat to encourage patterns (especially for high profile national implementations with careful design) where clients opt in to this kind of inclusion.
René Spronk (Sep 30 2021 at 06:15):
Patient safety concerns may also lead a server to include resources that a client perhaps wasn't expecting. "You can't safely interpret this without also looking at these other things. Ignore the other things at your peril".
Ardon Toonstra (Sep 30 2021 at 08:47):
@Michele Mottini ,
Our clients definitely do _not_ do that when processing generic search result - it expects that references are resolvable via REST call, not in the bundle
The Bundle section about resolving references states:
"Applications reading a Bundle should always look for a resource by its identity in the bundle first before trying to access it by its URL externally."
Ardon Toonstra (Sep 30 2021 at 08:49):
I'd just document the issue clearly in the IG
You are right, I think we can improve our IG regarding this (made a ticket). I also made a ticket per Lloyds request: https://jira.hl7.org/browse/FHIR-34042
Michele Mottini (Sep 30 2021 at 13:28):
We do that for _transaction_ bundles, but not for search results one, if there are no requested includes seem pointless (and actually _is_ pointless on all servers we connect to now).
Lloyd McKenzie (Sep 30 2021 at 14:01):
Sending stuff that's not expected only helps with patient safety if the receiver can and will consume and do useful things with them - which strikes me as very unlikely.
John Moehrke (Sep 30 2021 at 14:06):
seems it might be useful to define a query parameter, similar to _include and _revInclude, that a client can declare their interest. I fully understand and agree that clients should expect extra stuff, but if you are not aware why that extra stuff is there then it is hard for me to expect clients will do the right thing. Where a query parameter is an indicator that the client is aware of this 'kind' of extra stuff and will use it appropriately.
Lloyd McKenzie (Sep 30 2021 at 14:10):
How could you pre-plan to use something appropriately? If you're going to build the capability to consume and do something useful with data, I can't think of any reason why you wouldn't then always ask for it. Building the capacity to consume the data but not ask for it seems like a super-odd design choice.
Last updated: Apr 12 2022 at 19:14 UTC
