Skip to end of metadata
Go to start of metadata


Status

DONE

Stakeholders(mover/Second)
Outcome(Affirm-negative-abstain)(4-0-0)
Due date

Owner

Background

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.


Options

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.

Decision:- Change text is in Orange

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:

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

b)       the first six are used to specify a precision of  "month"

c)       the first eight are used to specify a precision of "day"

d)       the first ten are used to specify a precision of "hour”

e)       the first twelve are used to specify a precision of "minute”

f)        the first fourteen are used to specify a precision of "second”

g)       the first sixteen are used to specify a precision of "one tenth of a second”

h)       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)formerly Greenwich Mean Time (GMT)), where

  • 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.

 

 

 

 

 

Action items