I am currently working on a PR to improve search for Person resource. While writing tests for the DAO layer I noticed that the test FhirPersonDaoImpl.shouldReturnEmptyCollectionForNoMatchOnGender did not return an empty list for gender set as “wrong gender” (it returned a list of both male and female person), on changing the gender to “other” the tests pass, because the data set does not have a person with gender set as other. Is this the intended behavior, or should it test for incorrect parameters given?
Similar tests for NoMatchOnCity/State/PostalCode/Country return a non-empty list.
@captaindavinci Ooh. I understand the not matching on gender thing, but actually the city, state, postal code and country probably need a bit of work.
The gender thing happens because we treat invalid gender values, i.e., something not belonging to this valueset as if it were no value at all. That’s probably not the right behaviour and we should probably reject it with a 400 status code with an OperationOutcome pointing to the field. The problem is that we would want this error to be generated at a point where we can send the user a sensible message, so being able to distinguish between:
/ws/fhir2/Patient?gender=mermaid
and
/ws/fhir2/Observation?subject.gender=mermaid
seems important, but I don’t think we have that information by the time we get to the DAO level. There’s got to be a better way to do this, but I think it will require looking through the HAPI FHIR documentation.
On the city / state / postal code / country thing is it things like:
/ws/fhir2/Person?address-city=Ngerulmud
or just:
/ws/fhir2/Person?address-city=N
Because I’d expect the first to return no results (assuming there is no one from Ngerulmud in the database), but the second to potentially return results, assuming that they are in any city beginning with N. The semantics of FHIR search basically assume that the parameter is a prefix by default and that if you want an exact match you need to do something like:
/ws/fhir2/Person?address-city:exact=N
Which should be handled by the propertyLike() function.
What about generating the error at resource provider level for Person, Patient?
Edit:
Instead of throwing an error why not return an empty response which should be obtained when searching for a gender which does not exist?
So,
/ws/fhir2/Person?gender=wrong-gender
Should return 0 resources, similar to how the HAPI pubic server responds.
In this case, the BaseDaoImpl.handleGender method should return
Optional.of(ilike(propertyName, token.getValue(), MatchMode.EXACT)); instead of Optional.empty() when the gender is not present in the value set.
be handled by the