Stream: implementers
Topic: AND/OR semantics required for server
Robert Lichtenberger (Nov 28 2016 at 10:15):
While the support for search-parameter modifiers (:exact, :contains, etc.) is optional (and indicated by the CapabilityStatement), I can't find any indication on whether a server is allowed to NOT support AND/OR combinations of search parameters.
Is there any way of doing this? Or is every FHIR-server required to support AND/OR combinations on EVERY search parameter ?
James Agnew (Dec 01 2016 at 22:03):
Servers are definitely not required to support any particular combination of parameters. The specification outlines how AND/OR works, but that just means you can't choose your own way of doing AND/OR in FHIR.
The public test servers pretty much all support all combinations.. In the real world however I've seen lots of examples of FHIR interfaces on pre-existing systems where the exposed AND/OR combinations aligned to whatever database indexes already existed.
FWIW there is a CapabilityStatement (aka Conformance) extension which can be used to declare support for particular combinations: http://build.fhir.org/extension-capabilitystatement-search-parameter-combination.html
Grahame Grieve (Dec 01 2016 at 22:04):
right. restricting to what indexes you have is expected.
Grahame Grieve (Dec 01 2016 at 22:04):
Josh's proposal solves *this* problem. But it breaks the general case. And his hybrid is ... a mess
James Agnew (Dec 01 2016 at 22:05):
@Grahame Grieve wrong topic :)
Grahame Grieve (Dec 01 2016 at 22:05):
sorry
Robert Lichtenberger (Dec 02 2016 at 06:16):
Thank you for the pointer to the extension. But as far as I can see, this extension only specifies combinations of search parameters that are allowed, i.e. you must specify "a" and "b" and optionally "c". What I was looking for would be a way to declare that: for "a" you can only specify a single value; for "b" you must not use comma to give different values.
Brian Postlethwaite (Dec 02 2016 at 06:16):
I'd rather that information was in the SearchParameter resource than in the capability statement, that thing is huge enough as it is.
(I'd also like to see the Search param and operations removed from the capability statement too, and have a seperate operation to ask for the ones supported by the system (that you could search for too, limiting to only stuff you're interested in - but that's another story...)
Grahame Grieve (Dec 02 2016 at 10:42):
we moved the most verbose details out of CapabilityStatement
Last updated: Apr 12 2022 at 19:14 UTC