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
- HL7 Working Group Meeting Includes Strong International Attendance - September 16th, 2008
- Integrating EMRs with Reference Labs - September 3rd, 2008
- 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
Please note: NeoTool is now Corepoint Health! Please visit our new Corepoint Health IT Blog for recent insights. Also visit our new HL7 Resources section for additional information.


[…] 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.
To make this more fun, just because you send the time zone in the MSH as designated, does not mean that the receiver will take on the responsibility of doing the conversion. In addition, what if you have a user and a patient time zone designations in your system and the reciever does not have either designation? Which one do you send: the user of the system’s time zone or the patient’s time zone?
[…] recorded first by nickjonasluv17 on 2008-12-07→ HL7 Time Zone Qualification […]