Stream: implementers
Topic: Token search using ":in" modifier
Richard Kavanagh (Jul 31 2020 at 14:38):
If a client performs a search on a coded data item using the ":in" modifier, passing a value set that the server cannot process, what is the correct way for the server to respond?
Does it just ignore the "code:in" search parameter or should there be a more explicit response?
Richard Kavanagh (Sep 04 2020 at 19:35):
This did not get a response the first time around - so I'm trying again...
Lloyd McKenzie (Sep 04 2020 at 19:39):
I don't think there's a specific rule. Is this something you think needs to be nailed down?
Richard Kavanagh (Sep 04 2020 at 19:43):
I guess I am lookimg to see what can be done that is more definitive thn just ignoring the valueset.
Vassil Peytchev (Sep 04 2020 at 19:55):
Would Prefer: handling=strict apply here?
Richard Kavanagh (Sep 04 2020 at 20:04):
@Vassil Peytchev I suspect that might be an option, though it relies on the client setting headers, which will often be missed.
I suspect we will opt to return an error as that would seem to be the safest thing to do.
Vassil Peytchev (Sep 04 2020 at 20:27):
I musinderstood that the question was from the client point of view. From the server point of view, returning an error is a valid approach, but do you need to handle clients sending Prefer: handling=lenient?
Michele Mottini (Sep 04 2020 at 20:27):
Observation?patient=[patient that does not exist] returns empty bundle, so I's say Observation?code:in=[value set that does not exist] should do the same
Michele Mottini (Sep 04 2020 at 20:31):
(but our server actually returns an error ... mhhh)
Last updated: Apr 12 2022 at 19:14 UTC
