Search by duplicated query parameter

In the documentation regarding search of the REST API, the following is indicated about the case when a Resource has more than one field with the same name and a search by query parameters is to be done:

Some search parameters defined by resources are associated with more than one path in a resource. This means that the search parameter matches if any of the paths contain matching content. If a path matches, the whole resource is returned in the search results. The client may have to examine the resource to determine which path contains the match.

This means that the client is the one handling the responsability of these cases. My doubt is:

  • Is there any way to handle this behaviour in the backend? Maybe by making some kind of distinction between the duplicated query parameters?

This text isn’t talking about duplicated query parameters, it’s talking about repeating elements in the response. I.e. If you search for the name “smith” and the patient has 3 repetitions of Patient.name, the search will return the patient if any of the names match “smith”. If you send multiple repetitions of the “name” search criteria, they are treated as an “and”. So a search for name=smith&name=jones will return patients provided that one of the patient’s name repetitions includes a name part that starts with “smith” and one of the patient’s name repetitions includes a name part that starts with “jones”. (They don’t need to be the same name repetition though - and one might match on first name and another on middle name.)

Many thanks on your answer Lloyd.

Another question arises now, is it possible for a resource to have more than one field that matches a query parameter? i.e.: the field ‘name’ to be presented in two or more fields of a resource. If so, which is the proper way to solve this situations?

Thanks again

Each search parameter is tied to a specific element path (or occasionally to a specific set of element paths. So Patient.name will search Patient.name.given, Patient.name.family, Patient.name.prefix, Patient.name.suffix and Patient.name.text. However, it doesn’t search Patient.name.use (for example), nor does it search anything in Patient.contact.name.