Stream: fhirpath
Topic: New operation(s) to compare date/datetime/etc. w/ Period
Lloyd McKenzie (Jan 22 2022 at 23:26):
FHIR#28443 proposes defining a new convenience operation (or set of operations?) to allow easy comparison of date, dateTime and instant with a Period. Please share your thoughts on:
a) whether that is something that should be added
b) what you think it should look like
Brian Postlethwaite (Jan 23 2022 at 05:47):
This would indeed be useful - I'd use it.
Brian Postlethwaite (Jan 23 2022 at 05:48):
(though haven't used an equivalent as yet)
Bryn Rhodes (Jan 24 2022 at 16:57):
The proposed operation is pretty far afield from what we currently do in FHIRPath for this sort of thing. It would be important to work through some specific examples. It's proposed as a shorthand, but there isn't a lot of detail about what it's actually a shorthand for.
John Moehrke (Jan 24 2022 at 20:23):
@ryan moehrke ?
ryan moehrke (Jan 25 2022 at 02:44):
I'm not sure what bonus functionality you'd get from adding the list of datetime search prefixes as comparison functionality in fhirpath besides being able to deal with periods
(adding functionality for datetime periods would be really interesting because: it would allow miss-matched precision to be compared instead of not being possible in fhirpath)
As long as we ignore 'ap' - which if someone thinks it could be useful I have no qualms, I just don't personally see much need for it at all -
then the only search prefixes we don't already have (with = != >= > <= <) are sa and eb, which both hold no meaning if the comparison isn't a period
So what I'm seeing is actually a request to support periods natively (i.e. defining what the above operators mean when one or both sides are a period, defining how and when to implicitly convert between periods and datetimes, and deciding on if we want an explicit starts-after and ends-before method that can compare with start/end values if compared to a period but can default to < or > functionality when only a single value is given)
note, this is really complicated which is why we've had multiple long discussions and plenty of detail and rewriting in the fhir spec about what their search prefixes actually do, (and that's with the simplification that one must be a single value of any precision), but going through the effort to do this instead I think would actually suffice a need instead of duplicating FHIR Search functionality that isn't necessarily applicable
Last updated: Apr 12 2022 at 19:14 UTC
