Timezone - FHIR datetime

In de definitie van een HL7 FHIR dateTime (https://hl7.org/fhir/datatypes.html#dateTime)[https://hl7.org/fhir/datatypes.html#dateTime] staat:

A date, date-time or partial date (e.g. just year or year + month) as used in human communication. The format is YYYY, YYYY-MM, YYYY-MM-DD or YYYY-MM-DDThh:mm:ss+zz:zz, e.g. 2018, 1973-06, 1905-08-23, 2015-02-07T13:28:17-05:00 or 2017-01-01T00:00:00.000Z. If hours and minutes are specified, a timezone offset SHALL be populated. Actual timezone codes can be sent using the Timezone Code extension, if desired. Seconds must be provided due to schema type constraints but may be zero-filled and may be ignored at receiver discretion. Milliseconds are optionally allowed. Dates SHALL be valid dates. The time “24:00” is not allowed. Leap Seconds are allowed.

Het idee achter FHIR is dat de communicatie onafhankelijk is van systemen of locatie en dat je dus altijd voldoende informatie in het bericht hebt staat voor de juiste interpretatie. Nu hebben we in Nederland geen verschillende tijdzones, maar we hebben wel een onderscheid tussen zomer- en wintertijd. Met de timezone in de datetime kunnen we dit onderscheid maken. In een MsAccess dataset kunnen we geen onderscheid maken tussen:

  • 2024-03-30 02:15 (wintertijd)
  • 2024-03-30 02:15 (zomertijd, maar is eigenlijk 03:15 in wintertijd wat de klok is 1uur teruggezet)

In FHIR stellen ze de timezones verplicht, en dat betekent dat het bovenstaande voorbeeld in FHIR formaat als volgt uit ziet:

  • 2024-03-30T02:15:00+01:00 (wintertijd)
  • 2024-03-30T02:15:00+02:00 (zomertijd)

Deze voorbeelden voldoen aan de regex die bij de definitie van dateTime staat vermeld:

([0-9]([0-9]([0-9][1-9]|[1-9]0)|[1-9]00)|[1-9]000)(-(0[1-9]|1[0-2])(-(0[1-9]|[1-2][0-9]|3[0-1])(T([01][0-9]|2[0-3]):[0-5][0-9]:([0-5][0-9]|60)(\.[0-9]{1,9})?)?)?(Z|(\+|-)((0[0-9]|1[0-3]):[0-5][0-9]|14:00)?)?)?

NICE tijd

In de traditionele MsAccess dataset kunnen we geen tijdzones plaatsen. Dit maakt dat FHIR precieser is, maar dat we op dit moment in de landelijke database geen rekening kunnen houden met de tijdzones. we accepteren op dit moment dan ook dat bijv de behandelduur van opnames die aanwezig zijn gedurende de wisseling van zomer- en wintertijd een uur korter of langer kunnen zijn. We hopen in de toekomst wel de database aan te passen opdat deze ook de tijdzones bewaard.