HL7 Time Zone Qualification

July 25th, 2008 by Dave Shaver

 Votes | Average: 0 out of 5 Votes | Average: 0 out of 5 Votes | Average: 0 out of 5 Votes | Average: 0 out of 5 Votes | Average: 0 out of 5 (No Ratings Yet)

Loading ... Loading ...

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

  1. Assume that “all dates and times” are local to the sender
  2. Never apply the MSH time zone to other, non-qualified times in the message
  3. 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
2 Responses to “HL7 Time Zone Qualification”
  1. HL7 Dates and Times says:

    […] 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. […]

  2. Grahame says:

    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.

Leave a Reply

Discover the NeoTool Healthcare Integration Solution for Your Market.