Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »



Due date



The devices group would like to make a request for a change in the interpretation of the date/time data type (DTM 2.A.22).

Currently date/time is specified as

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

The time zone (+/-ZZZZ) is represented as +/-HHMM offset from Coordinated Universal Time (UTC) (formerly Greenwich Mean Time (GMT)), where +0000 or -0000 both represent UTC (without offset). The specific data representations used in the HL7 encoding rules are compatible with ISO 8824-1987(E).

We wish to point out that GMT is a legal time zone (UK in winter), and therefore HL7 DTM currently has no mechanism to distinguish between UTC (time zone unknown or not used) and GMT.

We therefore propose that (RFC 3339  - Unknown local offset Section 4.3)

  • +0000 be interpreted to mean the time zone is GMT
  • -0000 be interpreted to mean UTC

The same problem has been identified in ISO 8824-1987 and a request has been made for this to be resolved in any future revision. We have included this definition in the Continua Guidelines, now an ITU Recommendation.

We believe that Infrastructure and Messaging group has responsibility for data types and make this request to you.

Malcolm Clarke

So the issue is for a Medical Device  that has no local time reference so cannot provide it.


The following options were presented:

  1. YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ] where +0000 means GMT and -0000 means UTC.
    1. 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 +0000 represents the civil time zone offset is known to be zero, -0000 represents UTC (without offset)
        • This supports medical devices that are capable of sourcing UTC but do not have reference to local time offset.
  2. Malcom Clarke: The "best" approach is to accept FHIR/W3C/ISO8601 and use Z for UTC and +ZZ:ZZ for offset.
    1. YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ][Z] where the final Z indicates GMT instead of UTC.
    2. This breaks backward compatibility - the DTM currently only uses characters 0-9, .(period),+-.
    3. The regex is ^\d{4}(((0[1-9])|(1[0-2]))(((0[1-9])|([1-2]\d)|(3[0-1]))((([01]\d|2[0-3])([0-5]\d))(([0-5]\d)((\.\d{1,4}))?)?)?)?)?([+-](([0]\d|1[0-3])([0-5]\d)))?$
  3. Grahame: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]^[code] where code is an IANA timezone code for the timezone offset per BCP 175
    1. We cannot add a component to DTM because DTM is already a sub-component of existing data-types: CCD,CF,CNE,CSU,CWE,DIN,DLD,DR,FC,ICD,NDL,PPN,XAD,XCN,XPN,XTN.
    2. V2 has no provision for adding sub-components to data types that are sub-components of other datatypes.

Action items

  • No labels