Stream: implementers
Topic: Search and parameter prefixes
Stefan Lindstrom (May 31 2021 at 06:24):
Hi,
Have a question regarding how to best handle prefixes in search params. Our FHIR-application is mainly a facade towards a legacy system, mapping fhir -> legace and back. As such, the legacy app does not have the functionality needed to support prefixes, e.g a date will most often be treated as an implicit 'ge ' with no option to reverse the condition (and we are unlikely to get that support implemented).
So, as I see it there's a few ways to handle this:
1) We try to solve things programatically, i.e there's no prefix on a data param so defaults to eq, or a prefix the legacy search does not supprt, we do normal search and then apply our own filter logic to fulfill the constraint given. Might not work for all variants and might yield a complex and not very maintainable code.
2) We ignore prefixes all together. This seems to be the worst solution, someone searches with prefixes, we ignore prefixes and give back results that does not match what the user think they should get.
3) We simply check prefixes in our searches, and if it is not one of those that the legacy service supports, we generate an error.
My gut feeling is that:
#1 is probably the best and would be standard compliant,
#3 might be easiest to implement but might violate at least the spirit of the standard and
#2 is right out, it would both violate the standard and would risk external actors on our system to get erroneous data
So, which is the best option in our case? is #3 acceptable? Or is #1 the only option if we want our app to behave in a good manner?
Josh Mandel (May 31 2021 at 12:53):
FHIR calls these prefixes comparators (http//build.fhir.org/searchparameter-definitions.html#SearchParameter.comparator).
From a practical perspective I'm not sure I have good advice here other than "not (2)". It's fine not to support a search parameter at all (aa long as you're not trying to support a specific implementation guide requiring it) .
As far as the standard goes, you could technically use http://build.fhir.org/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.searchParam and http://build.fhir.org/searchparameter.html to create your own search parameters describing how your server works, but there's no computable way to say that you require a comparator.
Josh Mandel (May 31 2021 at 12:53):
Bottom line, your gut sense seems well tuned.
Stefan Lindstrom (Jun 02 2021 at 11:56):
Thanks for your input. Seems our team might have a bit of implementation work ahead of us :)
Last updated: Apr 12 2022 at 19:14 UTC
