Stream: implementers
Topic: Combining search parameters
Alex Kontur (Jul 19 2018 at 13:22):
Let's say I have practitioner resources at [base]/practitioner/... and organizations at [base]/organization/...
Let's assume both resources have a simple string element for name, and we want to create a corresponding parameter(s) to select resources based on name.
What happens if I use a combined expression for the parameter (e.g. Practitioner.name|Organization.name), and I run a query such as GET [base]/practitioner?name=Joe.
Am I "wasting" computing resources by evaluating a bunch of Organizations?
If I'm using similar parameters across multiple resources, what are the advantages/disadvantages of combining them into a single parameter vs. creating separate parameters?
Grahame Grieve (Jul 19 2018 at 13:41):
the answer is that it all depends. We define some parameters as across resource parameters, but not otheres
Grahame Grieve (Jul 19 2018 at 13:41):
it's really a matter of how to you implement it. it doesn't make any difference for performance to my server
Alex Kontur (Jul 19 2018 at 13:47):
Ok thanks. If the parameter uses a combined expression, but the server hasn't implemented one of the resources in the expression, what happens? Will it reject the query?
Grahame Grieve (Jul 19 2018 at 13:50):
Well, that's up to the server; what's right depends on the local context
Alex Kontur (Jul 19 2018 at 13:59):
If I don't know how it will be implemented, sounds like it's probably safer to use separate parameters
Christiaan Knaap (Jul 19 2018 at 14:53):
There are many standard searchparameters having this 'or' construction, so most implementers will be able to handle it gracefully.
Brian Postlethwaite (Jul 20 2018 at 00:35):
In our directory product we have a specialized custom system level operation for performing specific free text searching across resource types, kinda like a google search in our directory.
But I wouldn't be expecting us to define something like this at the International or IG level.
Last updated: Apr 12 2022 at 19:14 UTC
