Stream: argonaut
Topic: FHIR-27906 : search by date
Eric Haas (Oct 22 2020 at 16:27):
in J#27906 @Robert Scanlon asked to clarify search by date precision conformance expectations.
What do implementers think is a low enough bar. by day ???
e.g. : add bullet in Search Syntax to say...
- Servers SHALL support search by date to at least day precision
(but obviously implied is MAY support to even more precise datetime searches )
Michele Mottini (Oct 22 2020 at 17:16):
When searching by _lastUpdated you need much more than that - at least second
Michele Mottini (Oct 22 2020 at 17:17):
For everything else I'd say day is fine
Jenni Syed (Oct 22 2020 at 17:36):
@Eric Haas There is a statement in the specification that there "may be dragons" when you search without a time
Jenni Syed (Oct 22 2020 at 17:37):
I would prefer not requiring this complexity/support of day precision only if the underlying field always includes time+zone
Eric Haas (Oct 22 2020 at 17:40):
@Jenni Syed can you clarify? Are you proposing no guidance on precision for search by date?
Jenni Syed (Oct 22 2020 at 17:43):
I'm proposing to not require servers to support the timeless precision if their underlying server/field is always a date with a timezone, given that there are issues with searching with imprecise dates as called out in the specification
Jenni Syed (Oct 22 2020 at 17:43):
This implies a server may need a way to declare the precision supported :)
Jenni Syed (Oct 22 2020 at 17:44):
http://hl7.org/fhir/search.html#date
Jenni Syed (Oct 22 2020 at 17:45):
IE: it makes sense to search a patient by birth date with year, year/m/d, because the field is typically timeless
Jenni Syed (Oct 22 2020 at 17:46):
But if searching an observation's date, if the system only ever has a fully qualified date set for that field, you're going to run into "dragons" if you don't search with the time + zone
Eric Haas (Oct 22 2020 at 17:51):
What I would like to establish is a minimum expectatation ... if there is one. @Robert Scanlon ?
Eric Haas (Oct 22 2020 at 17:51):
is this a element by element decision?
Jenni Syed (Oct 22 2020 at 17:52):
Minimum may be to support the full timezone search
Jenni Syed (Oct 22 2020 at 17:53):
Do we know of servers that don't support that?
Jenni Syed (Oct 22 2020 at 17:54):
It's the "safest" or "most well understood" I think
Eric Haas (Oct 22 2020 at 17:57):
but for Patient.birthDate that seems burdensome for client?
Eric Haas (Oct 22 2020 at 17:59):
(waiting for @Robert Scanlon to chime in....)
Jenni Syed (Oct 22 2020 at 18:30):
That field is unique in that it is defined specifically as a Date and not a DateTime. Maybe it's as easy as looking at the field definition?
Jenni Syed (Oct 22 2020 at 18:31):
I think that's pretty rare in the spec
Robert Scanlon (Oct 22 2020 at 18:54):
Sorry for the slow response @Eric Haas , I was offline for a bit. My primary concern is that I think there needs to be some well defined rules so a client can know which precisions a server can handle that doesn't involve trial-and-error. Those rules could be 'every precision must be supported for every element'. Or 'this single precision must always be supported'. Or 'do this precision for this element and this other precision for this other element'. Or 'check the capabilitystatement for an extensionthat tells you which precision the servers supports'.
Robert Scanlon (Oct 22 2020 at 19:14):
When searching by _lastUpdated you need much more than that - at least second
Search by _lastUpdated isn't required in US Core is it?
Michele Mottini (Oct 22 2020 at 19:27):
You're right, it is not. It is the _only_ search by date our client uses though (if the server implements it).
Robert Scanlon (Oct 22 2020 at 19:49):
Yeah that's too bad, it would be very useful to clients that want to synchronize their copy of the data. Is it widely implemented?
Robert Scanlon (Oct 22 2020 at 20:31):
That field is unique in that it is defined specifically as a Date and not a DateTime. Maybe it's as easy as looking at the field definition?
I took a look at the types associated with all date searches. All except two parameters search elements of type period, dateTime or instant: Goal has a search of target-date that points to Goal.target.dueDate of type date, though it is not part of a required search. Patient has a search of birthdate that points to Patient.birthDate of type date, and is part of a required search.
Robert Scanlon (Oct 22 2020 at 20:34):
| Resource | Search Parameter | Required? | Fields | Types |
|---|---|---|---|---|
| CarePlan | date | CarePlan.period | period | |
| Condition | onset-date | Condition.onset[x] | dateTime, period | |
| DiagnosticReport | date | x | DiagnosticReport.effective[x] | dateTime, period |
| DocumentReference | date | x | DocumentReference.date\ | instant |
| DocumentReference | period | DocumentReference.context.period | period | |
| Encounter | date | x | Encounter.period | period |
| Goal | target-date | Goal.target.due[x] | date | |
| Immunization | date | Immunization.occurrence[x] | dateTime | |
| MedicationRequest | authoredon | MedicationRequest.authoredOn | dateTime | |
| Observation | date | x | Observation.effective[x] | dateTime, period |
| Patient | birthdate | x | Patient.birthDate | date |
| Procedure | date | x | Procedure.performed[x] | dateTime, period |
Michele Mottini (Oct 22 2020 at 20:45):
Is it widely implemented?
No, just a couple of places I believe. In other cases we have to get everything and then filter client-side
Eric Haas (Oct 22 2020 at 21:16):
CapabilityStatement.rest.resource.searchParam.documentation can used to document the server and client behaviour. on a resource+sp basis. So the "how " is not the big issue to me is the "what" level of precision. What I have heard so far is to the day for type date and the "the full timezone search" otherwise
Eric Haas (Nov 06 2020 at 01:46):
trying to document "full timezone search" and what that means
a precision to the time + timezone ?
so hour is good as a minimum precision?
and what if I want all the hbac1 since Feb.
GET [base]/Observation?patient=06e1f0dd-5fbe-4480-9bb4-6b54ec02d31b&code=4548-4&date=gt2020-01-01
I think the time is unnecessary here. so I think with modifiers gt,lt,ge,le to the day is good
Jenni Syed (Nov 06 2020 at 15:49):
If you have a time at all, FHIR requires it to be precise to offset so you couldn't just send hour
Jenni Syed (Nov 06 2020 at 15:50):
following the recommendations above, Observation's field being searched is defined as a dateTime, and to avoid the "dragons" in the spec, that would require the fully supplied dt/tm
Jenni Syed (Nov 06 2020 at 15:51):
b/c you may say after january 1, but behind the scenes, that's jan 1 in the server current offset... which can really result in unexpected results
Jenni Syed (Nov 06 2020 at 15:52):
(again, minimum bar of support - a server could decide to support more)
Eric Haas (Nov 06 2020 at 15:53):
but my query is "since February? how is a time zone relevant? The ask is imprecise so why should the client have to tack on an hour and timezone?
Josh Mandel (Nov 06 2020 at 15:56):
I don't see the difficulty here from the client perspective. The client can easily construct a timestamp that means "since February".
Eric Haas (Nov 06 2020 at 15:56):
this is a client expectation btw
the server's expectation is also unclear to me as I try to document it. ..
SHALL servers support all the way to fraction seconds, seconds? + time zone. ( I have not checked what the base spec says so may be premature to discuss here)
Eric Haas (Nov 06 2020 at 15:57):
Josh Mandel said:
I don't see the difficulty here from the client perspective. The client can easily construct a timestamp that means "since February".
that is Ok but I just want to be clear about the client 'burden'
Eric Haas (Nov 06 2020 at 15:59):
All the example in the guide and other guides have been pretty lax with re to precision...so I expect this will require a lot of updates.
Eric Haas (Nov 06 2020 at 16:00):
Would this imply that the above query would/could/should fail? My assumption was it would but it is not that clear to me.
Jenni Syed (Nov 06 2020 at 16:05):
We don't have anyone I'm aware of that uses our (most popular of our APIs) Observation API without an offset
Jenni Syed (Nov 06 2020 at 16:07):
And yes, we would fail that when it doesn't have the offset today. For us, it's especially hard to get something that would meet what an app would "expect" there as our data sources are multi-time zone
Jenni Syed (Nov 06 2020 at 16:07):
so even using the current server offset to query behind the scenes gets weird
Eric Haas (Nov 06 2020 at 16:08):
OK that is helpful to know.
Jenni Syed (Nov 06 2020 at 16:08):
I'm fixing my language to be more precise.. we pass in offsets which aren't zones...
Last updated: Apr 12 2022 at 19:14 UTC
