Stream: united states
Topic: Interpreting USCore "name" Patient search parameter
Aaron Moronez (Jun 03 2021 at 15:46):
I am trying to figure out exactly how the Patient "name" search parameter would/should be used by a user and interpreted by a server. If I were trying to find a patient "John Smith", I'd imagine I'd want to search by family and given explicitly (which we are planning on supporting) by doing something like "/Patient?family=Smith&given=John" The USCore spec dictates that a "name=Smith" search would/could search all parts of HumanName, meaning you'd get a patient whose family=Smith OR given=Smith OR suffix=Smith (since this is a "server-defined" text search, we will probably just limit to family and given). But how would/should a "name=John%20Smith" or "name=Smith\,John" search be handled? It seems like there is not enough guidance on this. What are other systems doing? And if interpreting a "name" search can be left up to an individual server's discretion, how useful is it really, given the point of FHIR is allowing an application to build an integration once and reuse it everywhere... it seems that "name" search would become a lot less useful if it behaved differently on each system.
Yunwei Wang (Jun 03 2021 at 15:57):
No. I think the instruction is pretty clear in FHIR base spec. If you search name=John%20Smith, the server will match "John Smith" in
any of the string fields in the HumanName, including family, give, prefix, suffix, suffix, and/or text
http://hl7.org/fhir/patient.html#search
Eric Haas (Jun 03 2021 at 16:14):
in the Quick Start for Patient we have:
if there is anything more that would make it clearer you can submit a tracker. Link at the bottom of any page in US Core.
Aaron Moronez (Jun 03 2021 at 16:14):
I am more interested in how people are interpreting "It is at the discretion of the server whether to pre-process names, addresses, and contact details to remove separator characters prior to matching in order to ensure more consistent behavior. For example, a server might remove all spaces and - characters from phone numbers. What is most appropriate varies depending on culture and context. A server may also use a free-text style searches on this property to achieve the best results.
When searching whole names and addresses (not parts), servers may also use flexible match or a free-text style searches on names to achieve the best results." from http://hl7.org/fhir/R4/search.html#string which seems to be the source of ambiguity in my mind. Taking the name field verbatim and just matching the HumanName elements against "John Smith" would return nothing, indeed, since none of the fields would match.
Aaron Moronez (Jun 03 2021 at 16:22):
Is anyone actually interpreting the "name" field flexibly and doing something intelligent based on its contents, or are people just taking it verbatim and matching as-is to each HumanName element (which will likely not be fruitful) because doing otherwise is too difficult to get done in time for meeting deadlines?
Michele Mottini (Jun 03 2021 at 16:26):
Our server takes it verbatim and matches it against first / last / middle name. Not a matter of deadlines, implementation choice
Gino Canessa (Jun 03 2021 at 16:50):
As a note, the name search parameter isn't defined in US Core, it's defined in the core spec (see Patient - Search Parameters). US Core just flags that servers must support it, which is important to keep in mind since the definition is applied internationally.
Overall, I believe it's described as server dependent because it needs to be. In some regions the custom is "FamilyName GivenName", in other regions it is "GivenName FamilyName", and there are a lot of variations within those (e.g., reversing the order by adding a comma). Trying to codify the rules for parsing that would not go well.
If a client wants to search with multiple name parts and doesn't know which is supposed to be which, it should submit a search along the lines of either name=Smith&name=John or (see: Composite Search Parameters) to get the most consistent results.name=Smith$John
Aaron Moronez (Jun 03 2021 at 18:15):
Good points. As a clarification, I believe composite syntax can only be used search params of type composite, and name is a string type. We will probably go with supporting multipleAnd for name (although that's a MAY requirement as far as USCore goes: https://www.hl7.org/fhir/us/core/SearchParameter-us-core-patient-name.html). It'll be interesting to see how useful that field turns out to be if more systems decide to not support it than do.
Gino Canessa (Jun 03 2021 at 18:42):
:face_palm: the first syntax is legal and I'll strike the second, thanks. It looks like we need to clean up that section, as some of the text describes the composite type and some is discussing the general syntax of joining search parameters.
Gino Canessa (Jun 03 2021 at 19:18):
For reference, FHIR#32851, FHIR#32852.
Michele Mottini (Jun 03 2021 at 19:20):
name=Smith,John should work - if you want OR
Gino Canessa (Jun 03 2021 at 19:23):
Yes - if you want AND name=Smith&name=John should work, correct? Though it would also likely match things like "Andrea Smith-Johnson".
Michele Mottini (Jun 03 2021 at 20:02):
Mhh, no, it won't match that - default string comparison is 'starts with'
Gino Canessa (Jun 03 2021 at 20:24):
Interesting Michele - and since HumanName.family is 0..1, you can't separate hyphenated names into distinct values either (had not given this any thought previously). Thanks for all the info.
Michele Mottini (Jun 03 2021 at 22:05):
Of course you can do name:contains=John and that will match Smith-Johnson (and a lot of other things!)
Yunwei Wang (Jun 03 2021 at 22:46):
Aaron Moronez said:
Taking the name field verbatim and just matching the HumanName elements against "John Smith" would return nothing, indeed, since none of the fields would match.
HumanName.text could have matched text.
Last updated: Apr 12 2022 at 19:14 UTC
