Stream: implementers
Topic: Search Patient's name
Yunwei Wang (Jul 14 2016 at 03:35):
Patient resource has a search parameter Patient.name which is defined as "A portion of either family or given name of the patient". Should I be able to search patient's full name, as displayed in Patient.name.text? For example: Patient?name=John Smith.
Chris Grenz (Jul 14 2016 at 03:39):
Was just writing a test case for that exact scenario and was unable to find any direction in the spec.
Grahame Grieve (Jul 14 2016 at 03:40):
you should find it today. I added the guidance yesterday. And the answer is yes: I made explicit that text is included in the search.
Grahame Grieve (Jul 14 2016 at 03:40):
or maybe we just approved it in MnM call and I haven't aded it yet
Chris Grenz (Jul 14 2016 at 03:41):
Where would it go? In the data type section?
Grahame Grieve (Jul 14 2016 at 03:41):
interesting question. which means we approved it and I haven't added it yet
Chris Grenz (Jul 14 2016 at 03:42):
Is there a similar directive for address?
Grahame Grieve (Jul 14 2016 at 03:46):
there will be
Chris Grenz (Jul 14 2016 at 03:46):
thx
Yunwei Wang (Jul 14 2016 at 03:58):
great. thx
Jorge de la Garza (Jan 24 2017 at 20:15):
Hi,
Just want to make sure I understand how search on Patient.name is supposed to work. If a patient resource has:
<!-- Peter James Chalmers, but called "Jim" -->
<name>
<use value="official"/>
<family value="Chalmers"/>
<given value="Peter"/>
<given value="James"/>
</name>
<name>
<use value="usual"/>
<given value="Jim"/>
</name>
Then all of the following queries should get that resource:
/Patient?name=chalmers
/Patient?name=pete
/Patient?name=james
/Patient?name=jim
Yes?
What about the case where a <name> has no text.value, as here? Am I as a server expected to return this resource for:
/Patient?name=Peter%20James%20Chalmers
?
The way the description on Patient.name is worded initially made me think that it is a "contains" search:
"A portion of either family or given name of the patient"
So the above patient would be returned for:
/Patient?name=almer
But now I'm thinking that's not right. Is it?
Lloyd McKenzie (Jan 24 2017 at 21:30):
@Simone Heckmann I know we talked about how this was going to work in Amsterdam, but I don't remember exactly where we landed - or if we've updated the spec to align with our discussion. (So your thoughts here would be welcome :))
Simone Heckmann (Jan 24 2017 at 21:39):
I think we agreed that searches for names should try to match at the beginning of the value, or after whitespace or Apostrophes/dashes
So searching for almer would match Almer, D'Almerio or Jones-Almers, but not Chalmers.
I wouldn't expect a server to be able to Match "Peter%20James%20Chalmers" unless there's a field (name.text) that in fact matches this string. But then again, clients should split multiple search string into a proper query like ?name=Peter&name=James&name=Chalmers.
Also, Servers may decide to automatically populate empty text fields with a default concatenation of all given name parts to improve search results.
Simone Heckmann (Jan 24 2017 at 21:41):
BTW if a client specifically wants to get partial matches, it's have to use the :contains modifier, e.g.:
?name:contains=almers would in fact match Chalmers
But a contains search by default would return too many false positive results!
Ewout Kramer (Jan 30 2017 at 15:21):
I am pretty sure the spec does not say anything like this, except that server behaviour could differ based on what kind of indexes the server has and what kind of searching would be performant enough to allow on the REST interface...
Grahame Grieve (Feb 06 2017 at 03:50):
what we do say is that searches on string type tokens is not meant to be determinate
Lloyd McKenzie (Feb 06 2017 at 04:36):
Does that mean it's legitimate to have a search result where none of the name parts start with the value specified in the search string?
Grahame Grieve (Feb 06 2017 at 06:27):
I think so. It woudn't be good or wise, but making it illegitimate would lead us to dive down a rabbit hole we've avoided so far
Lloyd McKenzie (Feb 06 2017 at 14:12):
My fundamental question is whether it's legitimate for a back-end that does an EMPI-style probability based match that accounts for day/month swapping, typos, spelling mistakes, sounds like issues, patient's who've moved, etc. from pretending to support a FHIR RESTful search but not actually following any of the criteria rules as written. To me, that seems wrong.
Grahame Grieve (Feb 06 2017 at 19:12):
that's what the $match operation is about - moving away from literal indexes.
Lloyd McKenzie (Feb 07 2017 at 01:31):
I understand. The question is whether someone whose back-end is suited to doing a $match can/should expose a RESTful search interface if they're not actually going to be compliant with the definitions of the search parameters as defined.
Grahame Grieve (Feb 07 2017 at 01:42):
no, I think it shouldn't be
Lloyd McKenzie (Feb 07 2017 at 03:06):
But you also said that searches don't have to be determinate. I'm not sure what the dividing line is.
Grahame Grieve (Feb 07 2017 at 03:34):
no. there's no magic bullet here. If you start trying to draft text that makes the line clear, you'll get tied up in knots. In principle, the search parameters are for character based literal matching, and the $match operation is for smarts. But we don't delineate a precise border here
Brian Postlethwaite (Feb 07 2017 at 08:12):
There's more than 1 reason to search for patients, one is to find a single patient for treatment (where MPI $match is appropriate), or for searching for patients for population or group analysis (search for all patients in a specific team, or for a managing organisation, or having a specific identifier type etc) these others are not appropriate for $match style queries
Michelle (Moseman) Miller (Mar 09 2017 at 16:58):
Is there any guidance around whether search should look at ALL HumanNames (regardless of period and/or use =old)?
Lloyd McKenzie (Mar 09 2017 at 17:02):
I would expect the search to look at all of them, but I don't think there's a requirement that all servers must implement that way.
Last updated: Apr 12 2022 at 19:14 UTC
