You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 Added transform for converting datetimes to mountain time #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.
The text was updated successfully, but these errors were encountered:
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
dateTime
primitive type so that the underlyingdateTime
can be transformed uniformly across the entire FHIR bundle.date
is available with no associated time (on the FHIR side,date
is a unique primitive type for this purpose). Storing date-only values asdateTime
could have unintended consequences when performing global transforms ondateTime
values.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 Added transform for converting datetimes to mountain time #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 adateTime
and 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
The text was updated successfully, but these errors were encountered: