HL7 Time Zone Qualification
July 25th, 2008 by Dave Shaver
Posted in HL7 Messaging, HL7 Standard, HL7 Integration, HL7 Basics
Both HL7 V2.x and V3.x support complex date structures. In the real world most V2.x messages are encoded using the local time on the system that generates the message. In addition, many interfaces do not support the concept or use of time zone.
This can be a big challenge when building interfaces and often site-to-site negotiation is required should the data moving across the interface need interpretation in another facility in a different time zone.
Said another way, historically HL7 messages were “always local” within a hospital or clinic. As the scope of using these messages pushes to regional or national level, the time zone is much more critical. In addition, the challenge of time zones directly applies even at the local level when daylight savings time kicks in and out.
As noted in chapter two of the HL7 specification, the time zone of the sender “should” be sent as an offset from the coordinated universal time (UTC) (previously known as Greenwich Mean Time or GMT). The problem is that the time zone specification is optional in V2.x — it “should be sent” but is “not required.”
This means that we need some general guidance on how to interpret an unadorned time. The rule proposed in the HL7 standard is that when the time zone is not present in a particular field but is included as part of the date/time field in the MSH segment, the MSH value will be used as the default time zone. Otherwise, the time is understood to refer to the local time of the sender.
In the real world most HL7 2.X interfaces
- Assume that “all dates and times” are local to the sender
- Never apply the MSH time zone to other, non-qualified times in the message
- Don’t even support specification of time zones on any dates/times.
Ultimately the conversion of a time to a different time zone is almost always the responsibility of the receiver.
HL7 V3 has an almost obscene number of words regarding dates and times. Ultimately, the typical use for time stamps is summed up very nicely:
The value of a point in time is represented using the ISO 8601 compliant form traditionally in use with HL7. This is the form that has no decorating dashes, colons and no “T” between the date and time. In short, the syntax is “YYYYMMDDHHMMSS.UUUU[+|-ZZzz]” where digits can be omitted from the right side to express less precision. Common forms are “YYYYMMDD” and “YYYYMMDDHHMM”, but the ability to truncate on the right side is not limited to these two variants.
Last 5 posts by Dave Shaver
- Massachusetts Hospitals Must Have CPOE by 2012 and CCHIT-Certified EHRs by 2015 - August 13th, 2008
- HL7 Dates and Times - July 25th, 2008
- HL7 Time Zone Qualification - July 25th, 2008
- RHIOs vs. Peer-to-Peer Communications - July 11th, 2008
- Hospitals Allowed to Pay for EMR Interfaces and Not Violate Stark - June 3rd, 2008






[…] The solution to the time zone problem is simple: All systems should send time zone along with every date and time. Sadly most HL7 interfaces do not include the time zone. This issue is covered in detail in another posting. […]
Even more complexity: given that you know the timezones, it’s not clear whether it is appropriate to convert a time to a local time or leave it in the original timezone when displaying it to a user.