Stream: implementers
Topic: Error severity for failed mapping of search parameter
Michael Donnelly (Jun 11 2018 at 20:23):
When a client provides a search parameter that the server doesn't recognize, the server can return a fatal OperationOutcome or include a non-fatal one in the Bundle with results.
In general, I believe a server should be as forgiving as possible in the face of unexpected client behavior. In this case, returning some results could be misleading.
Example 1: Failed mapping of a single parameter
The client wants a patient's progress notes.
[base]/DocumentReference?patient=1316024&type=http://loinc.org|11506-3
If the server can't map this LOINC code, does it return all DocumentReferences for that patient? That's certainly not what the client wants.
Example 2: One OR parameter can be mapped, the other can't
The client wants the patients progress notes and discharge documentation.
[base]/DocumentReference?patient=1316024&type=http://loinc.org|11506-3,http://loinc.org|18842-5
The server can map 18842-5 but not 11506-3. Does it return the discharge documentation? The client gets some of the data it wants, and it can tell from the OperationOutcome that the mapping for progress notes failed. But . . . what if the client doesn't check for the OperationOutcome?
Michael Donnelly (Jun 11 2018 at 20:25):
If the server returns a fatal OperationOutcome in the latter case, the client needs to do a second search to get just the discharge documentation if that's an acceptable compromise.
Michael Donnelly (Jun 11 2018 at 20:27):
1. How likely is it that a client will take note of a non-fatal OperationOutcome and take appropriate action?
2. How dangerous is it if a client fails to do this?
3. How useful are the results if a server ignores the mapping failure and returns results as if the client hadn't passed that parameter in the first place?
4. How inconvenient is it for a client to make a new request if the server doesn't return the compromise results?
Lloyd McKenzie (Jun 11 2018 at 20:47):
@Michael Donnelly The query response is required to include a "self" link that includes the portions of the query that it actually executed. So if it only searched on one of the LOINC codes, that's all that should be in the self link. Clients are expected to check the self link.
Grahame Grieve (Jun 11 2018 at 23:16):
we can't really know 'how likely' something is; we encourage clients to do it, and as the safety impact increases, it becomes more likely
Grahame Grieve (Jun 11 2018 at 23:18):
in this case, you're second guessing the client - trying to think what they really meant. Actually, what the client said is 'find me anything that has X'. your response is: I didn't find anything, with a note 'I'd never find anything because we don't accept X'. I don't think that should be an error unless you're really sure (somehow) that the client is wrong to ask for X and you won't accept it.
Michael Donnelly (Jun 12 2018 at 13:53):
Ah, I wasn't clear enough. If a client asks for X (example 1 above), and we don't know what X is, the question is whether we should return nothing or if we should return everything. If we pretended we didn't even receive parameter X, then we'd return results that aren't filtered on that parameter.
Michael Donnelly (Jun 12 2018 at 13:53):
To be clear, I'm not suggesting that's a good idea.
Michael Donnelly (Jun 12 2018 at 13:53):
I was trying to present the two options without including my bias.
John Moehrke (Jun 12 2018 at 13:56):
See http://build.fhir.org/security.html#AccessDenied
John Moehrke (Jun 12 2018 at 13:59):
With fully authorized clients, a very rich and expressive response can be given...
Michael Donnelly (Jun 12 2018 at 14:06):
@John Moehrke was this meant for another thread?
John Moehrke (Jun 12 2018 at 14:50):
nope, it was intended for you to see that we have already indicated that returning various kinds of responses exist
Ewout Kramer (Jun 12 2018 at 15:57):
So, it seems "return nothing" is the desired behaviour. But extending this to how we deal with unknown search parameters, we don't say "I'd never find anything because I don't accept X", we say "Didn't know about search parameter X, so I disregard X". Isn't that inconsistent?
John Moehrke (Jun 12 2018 at 16:06):
isn't the guidance on 'unknown' query parameters is to ignore that parameter? Thus returning results based only on the query parameters you know. This behaviour is common, it tends to simply return more results than one would expect, as parameters tend to reduce the results, not add to them (exceptions in FHIR are things like _include)... but I think what is being asked is if there could be a way to return some warning (lesser than a warning actually) that indicates whichquery parameters were ignored, so that the clent can undestand the results might not be as expected
Grahame Grieve (Jun 12 2018 at 22:48):
so we have a way to do this.
Grahame Grieve (Jun 12 2018 at 22:50):
@Michael Donnelly thanks for the clearer statement. I think it is more safe to return too much than to return unexpectedly little. Further, given that we already say that you ignore parameters you don't know, and that you confirm back to the client what parameters you did process, I think it would be most expected and safe to ignore parameters you don't support (and possibly return a note to that effect).
Grahame Grieve (Jun 12 2018 at 22:50):
It would be good when this subject arises at connectathons to point out to search users that they can and do get search messages back, and they should display them somewhere if they do - they can be very useful to users
Last updated: Apr 12 2022 at 19:14 UTC
