FHIR Chat · Querying Periods · implementers

Stream: implementers

Topic: Querying Periods

Richard Kavanagh (Mar 24 2016 at 14:06):

I'm going to use the Schedule resource but this applies to querying across all "Period" data types.

If I have the query http://[domain]/Schedule?date=ge2010-01-01&date=le2011-12-31 which of the following (if any) is true...

1) Return all Schedule resources where the planningHorizon wholly lies between 01-Jan-20101 and 31-Dec-2011

2) Return all Schedule resources where the planningHorizon peiod overlaps the time period on between 01-Jan-20101 and 31-Dec-2011

Assuming it is one of the above, how would you do the other?

James Agnew (Mar 25 2016 at 21:38):

I believe it would be (2)

To do (1) you're looking for http://[domain]/Schedule?date=sa2010-01-01&date=eb2011-12-31 if I'm reading the explanations here correctly

Chris Moesel (May 12 2016 at 16:49):

I think there is some inconsistent language in the spec regarding how date queries work with periods. Rather than start a new topic, this one seems appropriate. Here are the inconsistent statements:

A description of the date parameter from Encounter

This corresponds with what is implied by some of the examples on the search page too -- and is generally what I expect is the intended approach.

That said, the Prefixes section of the search page states that the default prefix is eq and defines eq as such for ranges (which include periods):

the range of the search value fully contains the range of the target value

This definition does not mix well with the former descriptions. In the former case, the search value must be contained by the target period. In the latter case, the search value must fully contain the target period.

So, which is it? If I say Encounter?date=2016-05-15 does it match an Encounter with a period from 2016-05-10 to 2016-05-20?

Chris Moesel (May 12 2016 at 16:51):

Once we have a consensus on the answer, I'm glad to file a change request (if one is deemed necessary)

Chris Moesel (May 12 2016 at 17:11):

This also leads to the followup question, which correlates to the original question on this thread: If the search param value is an implicit range (e.g., Encounter?date=2016) that only partially overlaps the actual period (say 2015-12-29 - 2016-01-4), then is it a match? The spec seems to indicate that the ap prefix indicates an overlap, so I guess maybe not?

Grahame Grieve (May 12 2016 at 18:31):

firstly, I agree that the definition is the wrong way around .

Grahame Grieve (May 12 2016 at 18:31):

secondly, I think that it is not a match, and you need ap

Chris Moesel (May 12 2016 at 18:42):

Thanks, @Grahame Grieve. So you're saying that the definition should be:

the range of the search value is fully contained by the range of the target value

Correct? To be clear, this means that Encounter?date=2016 doesn't even match an encounter which happened entirely in 2016 (e.g., 2016-05-10 thru 2016-05-20). Is that the intent?

Josh Mandel (May 12 2016 at 18:43):

That would be a very surprising result (i.e. that should not be the answer).

Chris Moesel (May 12 2016 at 18:46):

@Josh Mandel: I only mention it because that result (matching on Encounter?date=2016) might be exactly how servers who implemented the spec definition as written might behave today. I wanted to be sure that the inverse really is the intended behavior.

Josh Mandel (May 12 2016 at 18:47):

My server responds returns resources with dates like "2010-05-02" in response to a query for "date=2010".

Josh Mandel (May 12 2016 at 18:48):

Are you saying this is different for periods?

Chris Moesel (May 12 2016 at 18:49):

Ah. OK. I misunderstood what you were saying was unexpected. My server is currently implemented the same way! So I hear you.

Josh Mandel (May 12 2016 at 18:50):

And

curl "http://fhirtest.uhn.ca/baseDstu2/Encounter?_id=5728&date=2016"
curl "http://fhir3.healthintersections.com.au/open/Encounter?_format=json&_pretty=true&_id=87&date=2016"

return encounters that occurred with start and end entirely in 2016, etc.

Grahame Grieve (May 12 2016 at 18:51):

sigh. this is too hard for this time in the meeting

Chris Moesel (May 12 2016 at 18:52):

I'm saying that there seems to be some confusion in the spec around periods. I can see why date=2010 should return anything that happened in 2010. But, according to the definition of Encounter, the date param represents a date that occurred during the Encounter period. But I think the spec indicates that date=2016 implicitly means the range from 2016-01-01 to 2016-12-31. That range did not fully occur during the encounter period.

Chris Moesel (May 12 2016 at 18:53):

It overlapped. But according to spec, overlap is ap, not eq.

Chris Moesel (May 12 2016 at 18:54):

I'm not sure what the right answer should be. Unlike my contributions to some other topics, I actually don't have a predetermined opinion here -- I'm just trying to figure out how it is supposed to work.

Chris Moesel (May 12 2016 at 18:54):

;-)

Chris Moesel (May 12 2016 at 18:58):

BTW-- reversing the definition would have serious implications for number too. If eq is defined as "the range of the search value is fully contained by the range of the target value", then value=4 would not match 4.0, because "4" has implicit range [3.5, 4.5) and "4.0" has implicit range [3.95,4.05). So I don't think we can/should reverse the definition like that.

Chris Moesel (May 12 2016 at 19:00):

So, back to the original question. Should Encounter?date=2016-05-15 match an Encounter with period 2016-05-10 to 2016-05-20? According to definition of eq, it should not -- but some aspects of the spec imply otherwise.

Chris Moesel (May 12 2016 at 19:08):

BTW -- HAPI seems to not match it. So maybe it's just a matter of the wording in some of the search param descriptions (like Encounter.date).

James Agnew (May 12 2016 at 19:28):

Really? I just tried this in a unit test and it matches for me. Any chance you have a URL you can point to?

Chris Moesel (May 12 2016 at 19:50):

Shoot. I lied. It was Health Intersections that didn't match it. Sorry. I have the wrong base path.

Josh Mandel (May 12 2016 at 19:50):

I thought I tested both (with my curl commands above) and both behaved the same.

Chris Moesel (May 12 2016 at 19:51):

@Josh Mandel: I was talking about testing if a date within in a period matches on the period. You were testing if a date representing a superset of the period matches the period.

Josh Mandel (May 12 2016 at 19:52):

Gotcha!

Chris Moesel (May 12 2016 at 19:55):

For example, this one matches on a period from 11:30am to 12:30pm, even though the date param is for 12:00pm:
http://fhirtest.uhn.ca/baseDstu2/Encounter?date=2016-02-23T12:00:00-04:00

Chris Moesel (May 12 2016 at 19:56):

But this violates the currently documented definition of eq for ranges:

the range of the search value fully contains the range of the target value

Chris Moesel (May 12 2016 at 19:57):

But satisfies definition of Encounter.date search param:

A date within the period the Encounter lasted

Chris Moesel (May 12 2016 at 19:57):

Therein lies the rub.

Chris Moesel (May 12 2016 at 19:59):

Conversely, on Health Intersections, a similar query does *not* match on a date inside the period:
http://fhir3.healthintersections.com.au/open/Encounter?_format=json&_pretty=true&_id=87&date=2016-01-17T16:15:00%2B10:00
(16:15 is inside the period of 16:00 - 16:30 defined in encounter with ID 87)

James Agnew (May 12 2016 at 20:02):

Ahh interesting. I don't remember that definition being there last time I looked... I wonder if it's new.

One way or the other, I would say HAPI is doing the wrong thing.

Chris Moesel (May 12 2016 at 20:06):

If that's the intended definition then (and I think it needs to be, especially considering the issue with numbers and implicit ranges), then I think it would be good to figure out a better way of describing search parameters that go against periods. The current definition on Encounter.date is quite misleading.

Chris Moesel (May 12 2016 at 20:15):

While we're here, I think that maybe the period definitions (3rd column) for sa and eb might be backwards. What do you think?

Shouldn't sa indicate that the range above the search value contains the range of the target value?

Chris Moesel (May 12 2016 at 20:17):

Yeah, I'm pretty sure that's wrong. I'll file a bug for that.

Last updated: Apr 12 2022 at 19:14 UTC