Stream: fhirpath
Topic: GF#21606
Bryn Rhodes (Oct 16 2019 at 04:33):
Lloyd correctly pointed out that this disposition is incorrectly assigning semantics to annotations in UCUM. Therefore the disposition should be applied with the following adjustments:
-
Quantities in FHIRPath use _either_ a UCUM unit or a calendar duration keyword
-
Calendar duration keywords are represented as the keyword as a string (without curly braces), and are not represented as UCUM units.
Updated the proposed disposition for this tracker to reflect the use of calendar duration as the unit, rather than a UCUM annotation.
Bryn Rhodes (Oct 16 2019 at 04:36):
I have applied this adjustment to the publication draft. @Bas van den Heuvel , @Ewout Kramer , @Lloyd McKenzie, @Grahame Grieve , @Paul Lynch , @Brian Postlethwaite, please take a look and let me know if you have any concerns with this adjustment.
Paul Lynch (Oct 16 2019 at 14:17):
Previously, GF#20682 effectively made 'a' be treated as "year" (calendar) for arithmetic purposes. So I think the only change here is to disallow the use of 'min' through 'a' in quantities being added to date/times. That should not be a difficult change from an implementation point of view. However, I am a little concerned that if the quantity is not under the expression author's control (e.g. if it comes from some FHIR resource) then there could be difficulties if those quantities come with UCUM units like 'a' or 'd'. For instance, if a Questionnaire author is pulling some time value from an Observation and trying to add it to a date, I am not sure what facility the Questionnaire author would have for ensuring that the time Quantity is first converted to 's' or 'ms'.
Paul Lynch (Oct 16 2019 at 14:19):
Oh-- there is "toQuantity". I guess that should work, though it will require an adjustment to existing FHIRPath expressions (if there are any doing date/time & quantity arithmetic).
Bryn Rhodes (Oct 16 2019 at 14:41):
@Paul Lynch , note also that GF#24856 indicates that when FHIRPath is used within FHIR, UCUM time quantities are implicitly converted to their calendar equivalents, on the grounds that that is how the implementations already work.
Paul Lynch (Oct 16 2019 at 15:42):
@Bryn Rhodes That one (GF#24856) also mentions "1 '{year}'". Is that resolution going to be updated as well?
Bryn Rhodes (Oct 16 2019 at 17:05):
Oops, I see that I had some outstanding changes on that (never clicked Save on my browser)
Bryn Rhodes (Oct 16 2019 at 17:06):
Should be updated now
Paul Lynch (Oct 16 2019 at 17:19):
Okay, so in GF#24856, when does that implicit conversion happen? If it happens immediately prior to being used in arithmetic, then I think we are back the behavior of GF#20682-- you can use 'a' as a unit, and it means "year" in date/time arithmetic. That sounds different than what GF#21606 is saying.
Bryn Rhodes (Oct 16 2019 at 17:24):
When FHIRPath is used from FHIR, yes, that's the behavior. You can still get the definite quantity behavior if you want it, but you have to be explicit about it.
Bryn Rhodes (Oct 16 2019 at 17:24):
GF#21606 is only about FHIRPath.
Last updated: Apr 12 2022 at 19:14 UTC
