Stream: implementers
Topic: Search modifiers
Richard Kavanagh (Dec 08 2017 at 11:58):
When implementing a FHIR restful solution it may be the case that not all of the search modifiers are implemented. When this is the case what is the expected behaviour of the server.
So for example if
{base url}/Resource/DateElement=ge2018-01-01 is supported but
{base url}/Resource/DateElement=ge2018-01-01 is not - what response is expected?
similarly if
{base url}/Resource/StringElement:contains=foobar is supported but
{base url}/Resource/StringElement:exact=foobar is not - what response is expected?
Grahame Grieve (Dec 08 2017 at 11:59):
servers should ignore parameters they don't recognise (though see the Prefer header). But for parameters that they cannot support, they should return an error
Richard Kavanagh (Dec 11 2017 at 07:41):
From a client's perspective - I see no means for them to discover which modifiers are implemented. From what I can see there is nothing you can place in a CapabilityStatement to describe this. Have I missed something?
Vadim Peretokin (Dec 11 2017 at 08:13):
@Richard Kavanagh That's correct. One way to deal with this - you could fire off a search query you'd like to see work, then inspect the returned Bundle.link.relation=self. See http://hl7.org/fhir/search.html#conformance for more :)
Vadim Peretokin (Dec 11 2017 at 08:13):
If the params you're checking are there, then you're good to go
Richard Kavanagh (Dec 11 2017 at 08:31):
Thanks @Vadim Peretokin I'm fine with the conformance resource to understand which search paths a server supports - it does not however say which modifiers can be used on those search paths.
Vadim Peretokin (Dec 11 2017 at 08:37):
That's correct, it doesn't
Grahame Grieve (Dec 11 2017 at 13:05):
so capability statement merely lists the parameters available. To get details like this, you need to look in SearchParameter
Grahame Grieve (Dec 11 2017 at 13:06):
that does deal in this level of detail
Last updated: Apr 12 2022 at 19:14 UTC
