Stream: implementers
Topic: FHIRPath Implementation skip System.Date
Alexander Kiel (Sep 25 2020 at 15:38):
In FHIRPath we have the two system types, Date and DateTime. Both can handle year, year month and date precision. Date will implicitly convert to DateTime. So a Date 2020 should be equal to a DateTime 2020 because of this implicit conversion.
The JavaScript implementation seems to have no Date type. I was not able to construct one. @2021-01-01.type() results in DateTime. Furthermore the conversion table from primitive FHIR types to FHIRPath system types, also doesn't use the Date type: https://www.hl7.org/fhir/fhirpath.html#types Here FHIR.date, FHIR.dateTime, FHIR.instant are all converted to DateTime.
If a FHIRPath implementation skips the Date type altogether, it seems that this would only be perceivable through reflection and the is-operator.
My question: Do I have overlooked something or would it be save for an implementation to skip the Date type?
At the end, if the Date type has no value, wouldn't it be better to eliminate it from the FHIRPath spec?
Grahame Grieve (Sep 25 2020 at 15:42):
you might try asking on #javascript if no one answers here? (give it a day...) (@Paul Lynch)
Alexander Kiel (Sep 25 2020 at 15:52):
Also the FHIRPath parser of https://github.com/cqframework/clinical_quality_language has only a DateTime literal and no Date literal. So @2020 is parsed as DateTime literal. According the spec @2020T should be a DateTime literal and @2020 should be a Date literal. @Bryn Rhodes
Bryn Rhodes (Sep 25 2020 at 16:18):
@Alexander Kiel , I've just verified the translator has a Date literal, it has since the Date type was introduced in CQL STU3. Can you tell me where you're seeing the CQL parser return a DateTime for a Date literal? That would definitely be a bug if it's behaving that way.
Bryn Rhodes (Sep 25 2020 at 16:19):
I agree that FHIR.date should map to Date, that looks like just an oversight because that table was built before the Date type existed, can you log a tracker for that?
Paul Lynch (Sep 25 2020 at 17:17):
Alexander Kiel said:
The JavaScript implementation seems to have no Date type. I was not able to construct one.
@2021-01-01.type()results in DateTime. Furthermore the conversion table from primitive FHIR types to FHIRPath system types, also doesn't use the Date type: https://www.hl7.org/fhir/fhirpath.html#types Here FHIR.date, FHIR.dateTime, FHIR.instant are all converted to DateTime.
fhirpath.js was originally written for the previous version of the FHIRPath specification, which did not have a Date type. We are stilling working on completing support for the current FHIRPath specification. How important is support for the Date type in fhirpath.js to you? If you are not just exploring, but actually need it, I could try to prioritize it.
BTW, although I am subscribed to implementers, I usually ignore it for lack of time. A better stream to raise questions about the FHIRPath spec would be the fhirpath stream, and there is also a fhirpath.js stream for fhirpath.js (though questions about fhirpath.js also get asked on the fhirpath stream).
Alexander Kiel (Sep 26 2020 at 11:30):
@Paul Lynch I don't need the Date type in fhirpath.js. I just explore other implementations in order to decide wether I should implement the Date type in my Clojure implementation used for the Blaze server.
Thanks for pointing me to the fhirpath stream. I will ask further questions there.
Alexander Kiel (Sep 26 2020 at 11:46):
@Bryn Rhodes I saw the lack of a Date type in the org.cqframework.cql.gen.fhirpathParser in version 1.4.9. You added the Date type with https://github.com/cqframework/clinical_quality_language/commit/8e1ca7d1d6cedee98090a7acfe214e60389cdb48. So it will arrive with 1.5 or do you plan a back port in 1.4?
I raised the issue FHIR#28617 for the translation table.
Bryn Rhodes (Sep 26 2020 at 18:01):
@Alexander Kiel , if you need it in the 1.4 translator, we can pull that in, submit a Github issue. I'll note though that as of the current 1.5.0-SNAPSHOT, the translator is multi-version, there is a compatibilityLevel option that you can use to indicate what version of CQL you want to translate, and it works for the 1.3, 1.4, and 1.5 versions.
Alexander Kiel (Sep 26 2020 at 18:19):
@Bryn Rhodes Thanks, I'll first see if I really need it.
Last updated: Apr 12 2022 at 19:14 UTC
