Stream: implementers
Topic: Date search and prefixes
Jorge de la Garza (Feb 28 2017 at 17:38):
The documentation on prefixes for search values has for prefix "ge":
"the range above the search value intersects (i.e. overlaps) with the range of the target value, or the range of the search value fully contains the range of the target value"
So suppose my repository contains a patient with birthdate="2012". Then I would expect this search:
[base]/Patient?birthdate=ge2012-06
To return that patient, because the range of the search value (everything on or after 2012-06-01T00:00:00) intersects the range of the target value (implied range of 2012-01-01T00:00:00 to 2012-12-31T23:59:59). But suppose I have two "birthdate" search values:
[base]/Patient?birthdate=ge2012-06&birthdate=le2012-09
I would expect each of those conditions on its own to return a patient with birthdate="2012", so when they are combined that should also return that patient, right? But something about that doesn't seem right. I'm asking for patients with birthdate in a specific range, so is it really right to include a result that is most likely not in that range? I guess it isn't "more" right or wrong than the first case with a single condition. Any thoughts on this? Is it just up to the server to decide how to handle this?
Bryn Rhodes (Feb 28 2017 at 18:51):
I would not expect the patient to be returned in any of the searches because we don't know that the answer is true. If the patient's birthdate is "some time in 2012", then the answer to the question "was this patient born on or after June 1st, 2012" has to be "I don't know", which would mean they wouldn't be returned in the search.
Grahame Grieve (Mar 01 2017 at 02:09):
search errs the other way: it's better to include than to omit. So you include the patient if it might match.
Aditya Kurkure (May 06 2021 at 18:13):
Does the precision of the search parameter have to be >= the results returned?
Perhaps a better way to frame my question would be does eq2013-01-14T10:00:00 match with 2013-01-14?
Michele Mottini (May 06 2021 at 18:41):
No, it does not match: 2013-01-14 is a 24 hours period, the search parameter is a 1 second period, and equality is defined as 'search period must contains target period'
Aditya Kurkure (May 07 2021 at 05:37):
Michele Mottini said:
No, it does not match: 2013-01-14 is a 24 hours period, the search parameter is a 1 second period, and equality is defined as 'search period must contains target period'
Thanks. I am still a little confused because the standard specifies that 2013-01-14 could imply all times from 2013-01-14 till 2013-01-15. So that would include 2013-01-14T10:00:00 right?
Perhaps this could be specified in the standard?
Lloyd McKenzie (May 07 2021 at 13:12):
The challenge is that 'eq' doesn't mean 'contains'. You could propose we add a new relationship code for "interesects with".
Michele Mottini (May 07 2021 at 13:35):
So that would include 2013-01-14T10:00:00 right
Yes, so searching for eq2013-01-14 would match 2013-01-14T10:00:00 - but not vice-versa
The specs have all the details, see the third column of the table at http://hl7.org/fhir/search.html#prefix
Aditya Kurkure (May 08 2021 at 06:36):
Ah I see. Thanks :sweat_smile:.
Last updated: Apr 12 2022 at 19:14 UTC
