Stream: implementers
Topic: Search errors over OR parameters
Eric Lehner (Mar 04 2021 at 14:07):
Hi all, looking over the https://www.hl7.org/fhir/search.html#errors implementation, how should the server handle OR parameters (such as _id=1,2,3) if one of the values has a logical issue with it (such as id 2 is unknown)?
At the end it mentions that if the issue is a logical condition (e.g. unknown subject or code), the server should process the search, and the result may be empty or an OperationOutcome may be returned within the set indicating what went wrong. So in the case of a OR parameter, should it:
- Return a bundle just containing the OperationOutcome for the logical condition failure
- Return a bundle containing results interleaved with the OperationOutcome(s)
- Return a bundle containing just the valid results from the known parameters
Any help would be appreciated. Thank you!
Lloyd McKenzie (Mar 04 2021 at 14:16):
There can only be one OperationOutcome in a search-set Bundle. All warnings encountered are reported in that one instance. Where it falls in the Bundle isn't meaningful, though it should generally be returned with the first page of results. Whether you choose to return a warning in an OperationOutcome when some resources weren't 'searchable' is up to you - and whether you believe the client performing the search will find that information useful.
Brian Forbis (Mar 04 2021 at 14:57):
In this case, I think it is best to return the data that does match the set, rather than failing the whole search. For OR-style parameters that don't match any resources, they would just be ignored. Agreed that the decision to include an OperationOutcome with extra info is up to the implementer.
@Lloyd McKenzie is there somewhere in the spec that says only one OperationOutcome can be included in a bundle?
Lloyd McKenzie (Mar 04 2021 at 15:01):
Only that the wording referring to OperationOutcome is always singular. Given that OperationOutcome can report multiple issues, there's never a reason to have more than one. If you're willing to submit a change request, we can clarify this in the spec.
Brian Forbis (Mar 04 2021 at 15:18):
So, I'm not really sure what you mean by it needing to be in the first page of the bundle. My understanding is that page1 and page2 are entirely separate bundles, so they would have their own distinct OperationOutcomes for that particular page. This is probably needed when doing pagination with enforced page size limits, as likely the resource server will not know if there are any issues with the 1000th result if it is only looking at the first 10.
Lloyd McKenzie (Mar 04 2021 at 15:23):
What shows up on a page is based on sort order. If a resource couldn't be evaluated in terms of determining whether it's part of the result set at all, it won't appear in the sort order - instead you just have a result that in the overall result (the count of which is returned on the first page), there are some resources excluded because they did not have values on the searched element. There's no meaningful way to associate that with particular pages.
Brian Forbis (Mar 04 2021 at 17:04):
Sure, but to even get that info that certain results are not included, wouldn't you have to select the entire result set of resources to verify and then cross reference with the passed in search filters? This seems like it wouldn't work well with a server trying to enforce page size limits and only evaluating up to a max limit of resources at a time for performance reasons. Perhaps in that scenario, it may be better to just not include an operation outcome at all. But this all depends on the implementation and performance requirements.
Lloyd McKenzie (Mar 05 2021 at 04:42):
You have to select the entire result set to get the count - which is expected to be returned on the first page. Also, best practice is to freeze the search-set on the initial query so that subsequent paging isn't impacted by changes to the data.
Lloyd McKenzie (Mar 05 2021 at 04:42):
Paging is to save what comes over the wire at one time, not to save the server from having to find all the matching records.
Mike Wessler (Mar 05 2021 at 16:44):
If the search set needs to be frozen on the initial query, does that include the content of the response as well, or just the resource IDs being fetched? How long is the search supposed to be retained? When is it reset or released? Is the "here" link supposed to return the same content forever? This seems like an unsupportable performance and storage burden, especially for some wide-spanning bulk requests.
Lloyd McKenzie (Mar 05 2021 at 16:50):
FHIR doesn't dictate any of those things - and it's not mandatory to do it at all, just best practice. (If you don't, you risk data being missed when the user pages - which can be a clinical safety issue.) Different servers make varying choices about how long to maintain. In general, just storing the list of ids is probably sufficient. If a resource is changed such that it no longer meets the criteria and you display it anyhow, that might cause a bit of confusion, but is unlikely to cause clinical harm.
Last updated: Apr 12 2022 at 19:14 UTC
