Stream: fhir/infrastructure-wg
Topic: FHIR#23937
Bryn Rhodes (Oct 21 2019 at 19:30):
Tracker GF#23937 suggests the dateOp parameters need to be documented. The operation is expected to transform from the string representation of a date/time to a date/time-value. Discussion on FHIR-I today raised the question of whether there are some existing patterns we could use to inform this. Specifically, FHIRPath documents date/time formatting patterns that it uses for the toDateTime, toDate, toTime, and toString functions: http://build.fhir.org/ig/HL7/FHIRPath/branches/master/N1/#conventions
Grahame Grieve (Oct 21 2019 at 19:32):
@Alexander Zautke
Alexander Zautke (Oct 28 2019 at 11:32):
I don't mind using FHIRPath in this case. It would look like the following, right? src.element as dateSrc -> tgt.dateTgt = evaluate(dateSrc, "'2019-10-28'.toDate()"). We could make it shorter by using the shorthand syntax for evaluate here: src.element -> tgt.dateTgt = ("'2019-10-28'.toDate()")
Alexander Zautke (Oct 28 2019 at 12:47):
Related question: The description of the evaluate function in the mapping language says that 'it must start with a reference to one of the defined variables' if the shorthand syntax is used. Does this sentence imply that you can't begin the statement with a constant as in the example above?
Alexander Zautke (Oct 30 2019 at 19:15):
Any advice @Grahame Grieve ?
Lloyd McKenzie (Dec 16 2019 at 20:41):
Plan (from FMG call) is to use this thread to make a list of the various things we may want to do with date. Then we can evaluate which of those we can do with FHIRPath vs. mapping language vs. what might want changes to one or the other or both.
Grahame Grieve (Dec 16 2019 at 20:48):
known requirements for dates+times in the mapping language:
- initialise a target element with a fixed date or with [now]
- specify an alternative string format for either source or target
- allow conflating separate date/time elements, or splitting to separate date/time fields
- switch between local and UTC (in either direction)
- convert a date/time + duration to a new date time, or calculate a duration between two dates (v3 IVL)
- specify a running century window for dates with YY not YYYY ?
Bryn Rhodes (Dec 16 2019 at 20:54):
CQL defines duration and difference to support date/time duration calculations at a given precision.
Grahame Grieve (Dec 16 2019 at 20:56):
do you want to bring other requirements suggested by the CQL semantics?
Bryn Rhodes (Dec 16 2019 at 21:27):
Yes, CQL also defines date/time component extraction
Bryn Rhodes (Dec 16 2019 at 21:28):
Date, Time, and DateTime selectors
Bryn Rhodes (Dec 16 2019 at 21:31):
And precision-based comparison of date/time values (e.g. comparing two date/time values to the day, even though they may be specified further)
Grahame Grieve (Dec 16 2019 at 21:31):
and these things are relevant to the transformation problem?
Bryn Rhodes (Dec 16 2019 at 21:35):
date/time component extraction is "splitting to separate date/time fields" above
Bryn Rhodes (Dec 16 2019 at 21:36):
Date, Time, and DateTime selectors is "initialise a target element with a fixed date"
Bryn Rhodes (Dec 16 2019 at 21:36):
I'm not sure what's meant by "allow conflating separate date/time elements"
Bryn Rhodes (Dec 16 2019 at 21:37):
Precision-based comparison, I'm not sure, we've found it to be indispensable in quality improvement, so I imagine it would be applicable.
Grahame Grieve (Dec 16 2019 at 21:38):
source has 2 elements, date and time. Target has one, which is a dateTime (or vice versa)
Bryn Rhodes (Dec 16 2019 at 21:41):
Ah, gotcha
Christiaan Knaap (Mar 02 2020 at 13:05):
While working on ccda mappings we (Firely) needed an implementation of the dateOp function. We implemented three overloads:
-
dateOp(string input, string datetimeType)
with 'input' in a valid partial datetime format; where datetimeType is either 'Date' or 'DateTime', turning input into a FHIR Date or FHIR DateTime -
dateOp(string input, string inputFormat, string datetimeType)
as above, but inputFormat allows you to specify the format of the input so it can be parsed into as FHIR Date / DateTime. So the input need not be a valid partial datetime. -
dateOp(string input, string inputFormat, string outputFormat, string type)
allows you to specify the format in which to write the output and 'type' is the datatype you want returned (could als be a custom datatype, defined by a Logical Model).
For input/outputformats we used the formats that .NET recognizes (https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-date-and-time-format-strings). That is a superset of the informal format strings suggested in FHIRPath.
Alexander Zautke (Jan 24 2022 at 10:12):
FHIR-I is trying to move towards a resolution of this issue.
Taking the requirements into from @Grahame Grieve into account, we could have the following solutions:
-
initialise a target element with a fixed date or with [now]. This can be solved with FHIRPath.
src -> tgt.element = ("now()") -
specify an alternative string format for either source or target: Any ideas on how to come to an agreement which format strings to use here? Do we think this should be solved in FHIRPath?
-
allow conflating separate date/time elements, or splitting to separate date/time fields. With the addition of string manipulation in FHIRPath, this seems to be solved as well. See FHIR#27757.
-
switch between local and UTC (in either direction). Should be part of the format strings.
-
convert a date/time + duration to a new date time, or calculate a duration between two dates. Can this be done with date math logic in FHIRPath?
-
specify a running century window for dates with YY not YYYY ?. Format string issue as above.
Alexander Zautke (Jan 24 2022 at 10:15):
My proposal would be that we add the the overloads as outlined by @Christiaan Knaap above. Should we leave the format strings up to the implementation?
Brian Postlethwaite (Jan 24 2022 at 23:14):
Local/UTC conversions - that sounds like fun and danger...
Last updated: Apr 12 2022 at 19:14 UTC
