Stream: implementers
Topic: Default Search Filters
Karl M. Davis (Mar 01 2018 at 18:56):
What are folks' thoughts on us putting in place a default search filter for one of our resources? Specifically, ExplanationOfBenefit.disposition. Most of our API users aren't going to want to see inactive/superceded claims, so it makes sense to me to set ?disposition=active unless folks explicitly set it to something else. Does this horrify anyone or generally seem reasonable?
Karl M. Davis (Mar 01 2018 at 19:04):
The main problem I see with this is that it removes the ability to search for what would be ?disposition=* -- you can't run a single search for both active and cancelled resources at once. (Unless I further cheat and special-case "*" or "any" or something like that.)
Grahame Grieve (Mar 01 2018 at 20:54):
our collective opinion of defaults is gradually hardening to complete rejection where ever we can. the downstream consequences are pernicious.
Grahame Grieve (Mar 01 2018 at 20:54):
I think this is a bad idea too - the clients should always be specific - anything else will lead to unsafe consequences later.
Karl M. Davis (Mar 01 2018 at 21:08):
Graham, thanks -- your input is VERY appreciated.
In this case, I just worry more about unsophisticated API users getting back resources that have effectively been logically deleted. I'd rather make it harder for them to accidentally show their users data that's out of date. Any further thoughts?
Grahame Grieve (Mar 01 2018 at 21:17):
I understand the desire. And there's a value question here - make it easier for newbies makes it harder for non-newbies. Sometimes, that's a good tradeoff. But sometimes it's not. and in this case, the converse is that the applications expecting standard behaviour won't get it.
Grahame Grieve (Mar 01 2018 at 21:18):
having said that, Argonaut interfaces work this way, because of your concern. I think it's a mistake that will become due eventually, but they didn't listen to me on that subject. So you wouldn't stand alone on this
Karl M. Davis (Mar 01 2018 at 21:21):
To make it slightly less-not-supported (hah), it might be good to add an official mechanism for text wildcard searches?
Karl M. Davis (Mar 01 2018 at 21:21):
(On a specific field/param that is, unlike the _content param.)
Grahame Grieve (Mar 01 2018 at 21:23):
can you describe this further?
Karl M. Davis (Mar 01 2018 at 21:24):
And FWIW, I entirely understand your concern: it's definitely a risk/tradeoff/whatever. I'm still not 100% on it, but I'm leaning towards it being the right move for our use case.
Karl M. Davis (Mar 01 2018 at 21:25):
can you describe this further?
If the service assumes a default ?disposition=active, how would an API user negate that when they explicitly want to, such that results aren't filtered by disposition?
Grahame Grieve (Mar 01 2018 at 21:26):
well, yes, that's a question. One way would be to list the ones they do want:
disposition=active,errorr
Karl M. Davis (Mar 01 2018 at 21:28):
!
Duh -- great idea. Okay, so that's a nonissue. Thanks.
Elliot Silver (Mar 01 2018 at 21:44):
That would work unless disposition has no value, but an extension.
Grahame Grieve (Mar 01 2018 at 21:46):
yes you'd have to rule that out
Karl M. Davis (Mar 01 2018 at 23:01):
For this specific implementation, it'll only ever have one of two values.
Karl M. Davis (Mar 01 2018 at 23:03):
@Josh Mandel You have anything to say about how default search params is working out so far for Argonaut? Any particular things I should be nervous about if we do that on CMS' Blue Button to filter out logically deleted EOBs?
Josh Mandel (Mar 01 2018 at 23:11):
My preference is to have consistent API behavior -- no defaults, and apps that want to filter can filter.
Karl M. Davis (Mar 01 2018 at 23:18):
Are ya'all using them in Argonaut? If so, what for/where? (Apologies if not.)
Grahame Grieve (Mar 01 2018 at 23:34):
in the argonaut context, searching for any clinical resource (e.g. Condition) will only return conditions out of the current problem list. There's no access to search past historical problems
David Hay (Mar 02 2018 at 00:27):
Where does it say that? I'm looking at http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-condition.html and can't see anything...
Grahame Grieve (Mar 02 2018 at 01:33):
it's even better because it doesn't say that. That's just how it works
Jenni Syed (Mar 02 2018 at 15:37):
I believe that if you want "current" you search with statuses. You can see that in the example. No default behavior
Jenni Syed (Mar 02 2018 at 15:38):
If there are servers defaulting that to some set of statuses, that is news to me :)
Jenni Syed (Mar 02 2018 at 18:38):
@Grahame Grieve Have you seen this work that way in a FHIR server?
Grahame Grieve (Mar 02 2018 at 20:15):
no I admit I have not tested this, I was only going off the argument on the argonaut email list about 2 years ago
Jenni Syed (Mar 02 2018 at 22:37):
I think that was more in regards to having the capability to get "current' state of lists from the normal query than requiring List. I don't think anyone would argue that getting "snapshot in time" lists would require List.
Jenni Syed (Mar 02 2018 at 22:38):
But it's been a while :)
Jenni Syed (Mar 02 2018 at 22:38):
And it's Friday.
Grahame Grieve (Mar 02 2018 at 22:43):
but getting the current state of the lists from the normal query rules out processing the query more generally. I didn't argue for support for List, but for _list, which is a different thing. Though it's water under the bridge now
Last updated: Apr 12 2022 at 19:14 UTC
