FHIR Chat · AND/OR semantics required for server · implementers

Stream: implementers

Topic: AND/OR semantics required for server


view this post on Zulip 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 ?

view this post on Zulip 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

view this post on Zulip Grahame Grieve (Dec 01 2016 at 22:04):

right. restricting to what indexes you have is expected.

view this post on Zulip 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

view this post on Zulip James Agnew (Dec 01 2016 at 22:05):

@Grahame Grieve wrong topic :)

view this post on Zulip Grahame Grieve (Dec 01 2016 at 22:05):

sorry

view this post on Zulip 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.

view this post on Zulip 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...)

view this post on Zulip 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