Stream: implementers
Topic: date=ge%now
Ken Stevens (Sep 09 2019 at 16:10):
I am adding a new feature to hapi-fhir that allows users to search for dates in the future. I'm thinking of using %now as a value for now. Loosely inspired by the fhirpath environment variable syntax. Any recommendations for a better syntax? Should something like this make it into the fhir standard?
Paul Lynch (Sep 09 2019 at 17:13):
So, the server would substitute %now with the current DateTime? Why not have the client do that, and then you wouldn't need the syntax?
Slightly related is embedded FHIRPath in FHIR queries (see 5.4 in http://build.fhir.org/ig/HL7/sdc/expressions.html#x-fhir-query-enhancements). But the running of that FHIRPath happens before the query is issued.
John Silva (Sep 09 2019 at 17:21):
Who or how should the query deal with timezone differences between client and server? The client may not know how the server stored the date (UTC or local or other). Would it be the server's or the client's responsibility to get the timezone (offset) right?
Paul Lynch (Sep 09 2019 at 17:36):
A DateTime passed by the client can include the timezone offset.
Eric Haas (Sep 09 2019 at 17:39):
see our discussion on timezones here: https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/Language halfway through the stream we swtiched from languages to tz and in the end we punted on making any specific guidance in US Core.
Ken Stevens (Sep 09 2019 at 18:18):
This is used by subscriptions where the value of %now is different every time it's run, e.g. to filter on appointments that haven't happened yet. @Paul Lynch
Paul Lynch (Sep 09 2019 at 18:47):
I see. So, the Subscription.criteria field, which is a query, needs to be stored with "%now". So, then either the general search function of the server has to know about %now, or the part of the server that handles subscriptions has to know about "%now" (and replace it before handing it to the search function). I don't know which would be better, and it would probably be better to hear from others who are writing servers. @James Agnew ?
Paul Lynch (Sep 09 2019 at 18:49):
But in case there are more of these things, it might be better to use embedded FHIRPath (see link above).
Ken Stevens (Sep 09 2019 at 18:58):
@James Agnew and I came up with the %now suggestion together. I have it working in my hapi-fhir branch now. I expect it to be merged into hapi-fhir later this week. I posted here as this is a placeholder solution until we can find a more standards based solution. I'm coding it now because people need this functionality "now"...
Grahame Grieve (Sep 09 2019 at 20:06):
@Bryn Rhodes I'd think that if we had now in FHIRPath it would be now() or DateTime.now()? (not %now which is for external concepts)
But this is a search question, not a FHIRPath question, right? Do we have anything like this in search? or is it a subscription question? there's an applicable format defined in CDS hooks?
Bryn Rhodes (Sep 09 2019 at 20:18):
Yes, we currently define current date/time functions in FHIRPath here: http://hl7.org/fhirpath/2019May/#current-date-and-time-functions
Bryn Rhodes (Sep 09 2019 at 20:18):
We have now(), timeOfDay(), and today()
Bryn Rhodes (Sep 09 2019 at 20:26):
And we don't have a way to do this in the CDS hooks spec now, at least as part of prefetch, it would have to be done as part of a search against the endpoint passed in the request.
Bryn Rhodes (Sep 09 2019 at 20:26):
And I'm not seeing anything in the FHIR search either. You can search based on passed in dates, but not based on a "within".
Bryn Rhodes (Sep 09 2019 at 20:29):
You can express it with a DataRequirement, if you specify a Duration for the dateFilter, where it is interpreted as "those data items that fall within Duration before now".
Grahame Grieve (Sep 09 2019 at 20:30):
we don't have a way to do this in the CDS hooks spec now
there's a syntax: Observation?patient={{context.patientId}}. e.g. using liquid syntax... that would seem to be applicable to the subscription context
Bryn Rhodes (Sep 09 2019 at 20:35):
Agreed, and suggest using "Simple" FHIRPath within the Liquid token: http://hl7.org/fhir/fhirpath.html#simple
Bryn Rhodes (Sep 09 2019 at 20:36):
With the exception that you could reference the current date and time functions. (And should we consider adding the current date and time functions to "Simple" FHIRPath?)
Gino Canessa (Sep 09 2019 at 20:37):
Hasn't come up yet in the Argonaut subscriptions to my knowledge. We are keying off Search for filter parameters/types so far, but our use-cases don't expose any dates yet, so it makes sense that it hasn't.
I can see expressing this for a Topic in FHIRPath since it has the concepts already there, but it would likely need to be present in a filter parameter as well.
@Josh Mandel @Jenni Syed thoughts?
Josh Mandel (Sep 09 2019 at 20:43):
If the goal is to filter based on appointments that haven't happened yet, of course Appointment status values are probably useful ;-)
But more generally, if the goal is to subscribe to changes that can't be expressed in
1. a static fhirpath expression that generates candidate events +
2. a set of pre-defined search parameters expressions that further filter this candidate set
... then we don't currently have an approach. (i.e., we didn't in R4, and we haven't proposed to introduce one in R5.)
Josh Mandel (Sep 09 2019 at 20:45):
No reason we couldn't do so, but we'd probably want to introduce this at the level of FHIR's generic search capabilities, rather than doing something special for Subscriptions.
Grahame Grieve (Sep 09 2019 at 21:05):
subscription is different. it doesn't make sense to talk about a format for talking about things in the future when now has a known vlaue
Josh Mandel (Sep 09 2019 at 21:20):
Agreed that the need for current-time-as-a-variable doesn't arise in one-shot queries, since the client knows the current time (although on fine time scales, client doesn't know the network latency / when a query will actually arrive at a server, so even there the semantics of a "now" variable aren't totally useless). But what I wanted to say is: the general concept of variables probably does apply to search outside of subscriptions (e.g., in a search that incorporates server context variables like warning/debug levels, startup times, etc).
Josh Mandel (Sep 09 2019 at 21:21):
So I'd rather lay a framework for variables in search, and then decide which specific variables matter in a subscription.
Ken Stevens (Sep 09 2019 at 21:56):
It's true that "now" is known at the time of execution, but there are other "saved search" types of scenarios ourside of subscriptions where you need to search dates relative to "now" and it would be handy not to have to rewrite those queries at search time.
Ken Stevens (Sep 09 2019 at 21:58):
I leaned towards the %environment syntax because I can imagine installs where there are many fhir servers that share stored searches across them and want to set search parameters based on local configuration, e.g. Organization?identifier=%local_clinic_id
Ken Stevens (Sep 09 2019 at 21:59):
I could also imagine searches based on information available in the session e.g. /Patient?identifier=%user_id
Josh Mandel (Sep 09 2019 at 22:05):
Yes, these are great examples of the kinds of capabilities where server-based variables might be useful in regular searches (not just subscription notifications).
Grahame Grieve (Sep 10 2019 at 00:11):
there's yet another syntax to consider, from here, where we're doing this already: http://hl7.org/fhir/lifecycle.html#current
GET [base]/AllergyIntolerance?patient=42&_list=$current-allergies
Grahame Grieve (Sep 10 2019 at 00:12):
I think we should rationalise all this and use liquid syntax in the search format
Josh Mandel (Sep 10 2019 at 01:15):
That's a great idea (though https://handlebarsjs.com might be what I'd call it for broader compatibility; for simple expressions, same deal).
James Agnew (Sep 10 2019 at 13:44):
We talked about using $now as the syntax for this, but had decided against it given that $ is used as the composite parameter separator so it'd presumably need to be escaped
James Agnew (Sep 10 2019 at 13:46):
We also talked about coming up with a syntax to allow FHIRPath expressions (e.e. date={{now()}} ) which seemed neat, but at first blush I figured that seems misleading since I don't know how you could use the rest of FHIRPath as a part of a parameter value, but people would surely try and complain when they couldn't..
Grahame Grieve (Sep 10 2019 at 14:28):
Right would be tricky to explain that it doesn’t look in the target resources but it’s just a pre-process thing
Last updated: Apr 12 2022 at 19:14 UTC
