The Demo site for our new HL7 Version 2+ (plus) Standard
visit the hl7 website

Draft Website - For Review Purposes Only

DTM - date/time

HL7 Component Table - DTM - date/time
Seq# Description Implement Flags Cardinality Length C.LEN Vocabulary Data Type
DTM
1 Date/Time SHALL # [0..1] [4..24]   8

Definition: Specifies a point in time using a 24-hour clock notation.

Minimum Length: 4

Maximum Length: 24


The number of characters populated (excluding the time zone specification) specifies the precision.

Format: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ].

Thus:

  1. only the first four are used to specify a precision of "year"

  2. the first six are used to specify a precision of "month"

  3. the first eight are used to specify a precision of "day"

  4. the first ten are used to specify a precision of "hour”

  5. the first twelve are used to specify a precision of "minute”

  6. the first fourteen are used to specify a precision of "second”

  7. the first sixteen are used to specify a precision of "one tenth of a second”

  8. the first nineteen are used to specify a precision of " one ten thousandths of a second”

Example: |199904| specifies April 1999.

The time zone (+/-ZZZZ) is represented as +/-HHMM offset from Coordinated Universal Time (UTC)

  • For implementations prior to V2.9 +0000 or -0000 both represent UTC (without offset).

  • For implementations starting with V2.9

    • use of the plus sign (+0000) represents the civil time zone offset is known to be zero,

    • use of the minus sign (-0000) represents UTC (without offset)

  • This supports medical devices that are capable of sourcing UTC but do not have reference to local time offset. Use case is London in the winter.

This provides a solution for the use case where the device can source UTC. It is up to the implementation to determine the storage form.


The specific data representations used in the HL7 encoding rules are compatible with ISO 8824-1987(E).

Note: If the time zone is not included, the time zone defaults to that of the local time zone of the sender. Also note that a DTM valued field with the HHMM part set to "0000" represents midnight of the night extending from the previous day to the day given by the YYYYMMDD part (see example below).


Examples:

Example

Description

|19760704010159-0500|

1:01:59 on July 4, 1976 in the Eastern Standard Time zone (USA)

|19760704010159-0400|

1:01:59 on July 4, 1976 in the Eastern Daylight Saving Time zone (USA).

|198807050000|

Midnight of the night extending from July 4 to July 5, 1988 in the local time zone of the sender.

|19880705|    

Same as prior example, but precision extends only to the day. Could be used for a birth date, if the time of birth is unknown.

|19981004010159+0100|

1:01:59 on October 4, 1998 in Amsterdam, NL. (Time zone=+0100).

The HL7 Standard strongly recommends that all systems routinely send the time zone offset but does not require it. All HL7 systems are required to accept the time zone offset, but its implementation is application specific. For many applications the time of interest is the local time of the sender. For example, an application in the Eastern Standard Time zone receiving notification of an admission that takes place at 11:00 PM in San Francisco on December 11 would prefer to treat the admission as having occurred on December 11 rather than advancing the date to December 12.

Note: The time zone [+/-ZZZZ], when used, is restricted to legally-defined time zones and is represented in HHMM format.


One exception to this rule would be a clinical system that processed patient data collected in a clinic and a nearby hospital that happens to be in a different time zone. Such applications may choose to convert the data to a common representation. Similar concerns apply to the transitions to and from daylight saving time. HL7 supports such requirements by requiring that the time zone information be present when the information is sent. It does not, however, specify which of the treatments discussed here will be applied by the receiving system.

The DTM data type does not follow the normal truncation pattern, and the truncation character is never valid in the DTM data type. Instead, the truncation behavior is based on the semantics of dates and times.

Unless otherwise specified in the context where the DTM type is used, the DTM type may be truncated to a day. When a DTM is truncated, the truncated form SHALL still be a valid DTM type. Systems should always be able to persist full date / time information including the timezone. Refer to Chapter 2, section 2.5.5.2 "Truncation Pattern" for further information.