As an RS engineer, I want date and datetime values to be handled uniformly so that transforms can be performed consistently.
Description/Use Case
The HL7 to FHIR mappings with regard to date and datetime values have generally been implemented ad hoc, which makes transforms involving all datetimes (e.g. timezone adjustments) difficult. A dedicated mapping to convert FHIR datetime to HL7 DTM or DT exists; we should ensure all date and datetime values in the resulting FHIR bundle are created in a manner consistent with this mapping.
Risks/Impacts/Considerations
Dev Notes
It may not currently be possible to create a universal HL7 to FHIR mapping for this purpose, in which case either the mappings must remain ad hoc, or the HL7 to FHIR converter library should change to make this possible.
In order to have datetime values be universally transformable, we should always have store datetime values as the FHIR dateTime primitive type so that the underlying dateTime can be transformed uniformly across the entire FHIR bundle.
A distinction needs to be made in cases where only the date is available with no associated time (on the FHIR side, date is a unique primitive type for this purpose). Storing date-only values as dateTime could have unintended consequences when performing global transforms on dateTime values.
The hl7v2-date-time extension needs a clear definition of what it represents and how it should be used; if it is intended to store the string representation of the HL7 datetime, it should be immutable (contrary to the manipulation introduced in #16542). If it is intended only to store the original HL7 value in cases where the FHIR mapping resulted in data loss (e.g. if HL7 provides a dateTime and the mapped FHIR only stores a date) and there is no need to preserve the string representation, then it should not be stored as a string and should not be immutable.
Acceptance Criteria
[ ] A strategy for uniform handling of datetime HL7 to FHIR mappings has been discussed and agreed to by both the Platform and Engagement teams.
[ ] Mappings have been updated with the agreed upon strategy.
User Story
As an RS engineer, I want date and datetime values to be handled uniformly so that transforms can be performed consistently.
Description/Use Case
The HL7 to FHIR mappings with regard to date and datetime values have generally been implemented ad hoc, which makes transforms involving all datetimes (e.g. timezone adjustments) difficult. A dedicated mapping to convert FHIR datetime to HL7 DTM or DT exists; we should ensure all date and datetime values in the resulting FHIR bundle are created in a manner consistent with this mapping.
Risks/Impacts/Considerations
Dev Notes
dateTimeprimitive type so that the underlyingdateTimecan be transformed uniformly across the entire FHIR bundle.dateis available with no associated time (on the FHIR side,dateis a unique primitive type for this purpose). Storing date-only values asdateTimecould have unintended consequences when performing global transforms ondateTimevalues.hl7v2-date-timeextension needs a clear definition of what it represents and how it should be used; if it is intended to store the string representation of the HL7 datetime, it should be immutable (contrary to the manipulation introduced in #16542). If it is intended only to store the original HL7 value in cases where the FHIR mapping resulted in data loss (e.g. if HL7 provides adateTimeand the mapped FHIR only stores adate) and there is no need to preserve the string representation, then it should not be stored as a string and should not be immutable.Acceptance Criteria