@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:
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:
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:
Which should be handled by the