Technical Considerations > DateTime Values and Time Zones
Technical Considerations

DateTime Values and Time Zones

Our engine connects and enables communication between organizations across the world. With part of that communication containing information that’s linked to or dependent on time, it’s natural to wonder how we manage differences in time zones.

This is something we had to consider very early on while developing our technology, and it’s something we want to share with developers so that they can understand more about how our engine works.

Date and DateTime Formatting
Values sent from the Redox API will be formatted to the ISO 8601 Standard.

  • Date values will use YYYY-MM-DD , for example: 2016-09-22
  • DateTime values will use YYYY-MM-DDThh:mm:ss.sTZD, for example: 2016-09-22T10:20:30.000Z

Source and Destination Time Zones

Redox Source and Destination records contain a time zone attribute designating the expected time zone of values. This is particularly relevant when a system connecting to Redox assumes a time zone. Specifically, HL7 engines often assume a local time zone and do not generate or parse time zone offsets in a timestamp.

How Redox Handles DateTime Values and Time Zones

We will parse values sent with a time component using the source time zone and convert the value to the destination time zone in transmissions. If no time component is included, no time zone adjustments will be applied.

It is important to not include a time value if only the date value is appropriate.

For example:

  • ”Patient.DOB” : "2016-09-22T00:00:00.000Z" will be translated to
  • ”Patient.DOB” : "2016-09-21T20:00:00.000-0400" if the destination is in US Eastern Time.
  • Note the change in date.

Instead, ”Patient.DOB” : "2016-09-22” should be sent so that the correct date is maintained when sending to the destination. In this case, no time data is sent, so time zone conversion does not take place.

If you send an offset in your timestamp, for example: 2007-04-05T12:30-0200 , we will use this value instead of the source time zone when parsing the date.

You may be wondering why our Date of Birth field (and perhaps other fields in our data models) is defined as a DateTime data type to begin with—great question. In some healthcare scenarios, a timestamp may be relevant and provided (such as a birth). Therefore, we only use DateTime values and look to the time component sent to Redox to determine if time zone conversion is required.