HL7 Dates and Times
July 25th, 2008 by Dave Shaver
Posted in HL7 Messaging, HL7 Standard, HL7 Integration, HL7 Basics
Moving dates and times between systems via HL7 has two primary challenges:
- Clock skew/drift — the systems don’t agree on the definition of “now”
- Time zones — the systems differ in their offset from UTC/GMT
While both problems are easy to understand, the two challenges are solved in very different ways. Here is a summary of each problem:
- Clock Skew or Clock Drift: Systems exchanging data “almost agree” on the current date and time — but not quite. For example, the RIS system thinks it is 4:15pm while the registration system thinks it is 4:17pm.
- Time Zone: The receiver of a message needs to know if the dates and times in the message are using the same time zone as the receiver or a different one. e.g., a radiology clinic based in Tucson receives an order from a referring physician in California. The time zone on the message says the order was generated at “8:15am.” The clinic needs to know if the time is California time or Arizona time. The answer is, “It depends!” The challenge is that depending on the time of year, Arizona and California share a common time zone and at other times they do not.
The Clock drift problems cause issues in annoying, silly ways — i.e., actual events that are happening in the real world appear to be impossible based on the disagreement about the current time. e.g., the RIS system thinks it is 4:15pm while the registration system thinks it is 4:17pm. An HL7 ADT admission message is generated recording the date and time of admission is “4:17pm”. Within seconds the RIS receives the message and claims that this date is “in the future” so it does not process the message correctly.
The solution to clock drift is twofold:
- Attempt to synchronize clocks to one true time or a shared view of “correct time.” Many operating systems (including Windows) can automatically adjust the system clock based on a reference to a known, good time.
- Alternatively, there can be a shared, collective view of time using something like the Network Time Protocol (NTP). Ultimately the OS can maintain the clocks within a few milliseconds. Sadly, many Hospital IT shops do not use a system to synchronize times.
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.
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






How should a patient DOB be treated?
Within our applications this field is used to confirm we have the correct patient (e.g. are you so and so at this address please confirm your dob).
Therefore we don’t want this date changing because the PAS application is in a different time zone, the patient knows their dob and doesn’t care about time zone.