Currently, ADL has no way of constraining timezone as part of date/time constraints. I’m not currently aware of any expressed need to do this from the clinical modelling community, but technically speaking, it is missing from the ADL standard.
Within the Specifications Editorial Committee (SEC), it has been suggested that we could add it in into AM Release 2.3.0. If we do that, tool builders would theoretically be obliged to implement it, if they progress to supporting ADL 2.3.0, which contains other frequently requested changes (binding strengths a la FHIR, negative durations for obstetrics, for example).
So the question for us here is if we include such a change which might be a cost to tool implementers (maybe @borut.fabjan , @yampeku , @sebastian.garde and any other tool implementers would like to comment) but have little or no real world value for modellers.
If it is a low value change, I would suggest we push it to ADL 3, however if it is something that is needed, we can do it in the current release.
Would anyone from the clinical modelling side care to respond?
Here is the current proposal for expressing constraints on timezones.
Constraints on time-zone
Timezone within dates, times and date/times may be constrained by adding one of the following to the main constraint pattern:
(+|-)??:?? – TZ optional (same as having no constraint)
(+|-)??:XX – TZ minutes not allowed, hours optional
I’ve never seen one either. The only thing I can think of is organising healthcare interventions such as robotic surgery or MDT meetings across time zones. Perhaps more common in countries that actually have more than one time zone, like ?
We actually did come across a TZ issue in a recent project, which was due to erroneous imported data (and I guess “TZ required” might be helpful) but practically what we really needed to establish was whether the data was normalised to GMT prior to commit.
So I think we should park this to better understand the real practical constraints we might want to apply in cross TZ scenarios. Perhaps offer guidance on best practice, then see how any adl constraint requirements fall out of that?
That seems like a useful minimum, and it shouldn’t create much implementation burden. I’ll retain that in the current CR and push the rest to a later one.
THe problem is that this really only defines the format of the datetime string. It says nothing about the required behaviour, and can be misleading.
i.e The example which foxed us in a recent project was that exported data carried correctly TZ formatted data (which would have passed the constrain test) but the data was actually not TZ normalised, in particular was not adjusted for Summer time, and when unpacked, presented incorrect time (as it assumed that the TZ was normalised).
My worry here is that we seem to fix a gap but leave too much room for misinterpretation
I was thinking about it all yesterday while I was doing the change (see this section in ADL2; I’ve replicated that in ADL1.4 spec as well).
At the moment I limited the pattern extension to a visual form that I think most people will get, i.e. things like yyyy-mm-ddThh:mm:XX±hhmm, hh:mm:ss±hh. Summer time is built into the timezone (although it is not that clear in ISO 8601:2019) i.e. 2019-09-07T15:50-04:00 is ‘3:30 pm on September 7, 2019 in the time zone New York (UTC with daylight saving time)’ - outside of summer, east coast US is -05:00 not -04:00.
As far as I can see we would need to rely on systems creating time data to create it properly, including summer time. This should normally be done by an OS call or similar, so I don’t think it’s usually going to be wrong.
The only way to go further on Summer time would be to add some sort of constraint capability for putting things like ‘BST’, ‘CEST’, ‘MST’ (Mountain summer time in US) and so on - that sounds complicated to me…
So it seems to me reasonable to at least provide a way to require TZ info to be provided - otherwise, it is treated as optional - anyone want to have a way to prohibit it?
I came across those issues while creating test cases for conformance verification. The source of all this is that AOM 1.4 actually has a constraint for timezone in C_DATE (which is incorrect there because date has no time part), C_TIME and C_DATE_TIME constraints. But then in ADL there was no clear mapping for the TZ constraint, since in ADL the date/time constraints are string expressions and in AOM those are individual attributes of the date/time constraint classes, named minute_validity, hour_validity and so on.
My personal opinion would be to:
remove anything that has to do with the TZ from the AOM
always require TZ on time and datetime expressions, and maybe have a sensible default to UTC
The way I see it is: if any two openEHR systems will exchange data, those could be in different timezones. If we have one client sending data and one server receiving data, then one option could be the client sends data with it’s local timezone included, then the server can process accordingly and do one of two things:
store the data using the client’s timezone information, so data will have many different TZs and when retrieved might retrieve the data as-is of transform the data to a given TZ (if the client TZ was negotiated before the data retrieval)
store the data using the server’s TZ or a chosen TZ, like UTC, then all retrieved data will be in that TZ or transformed to a previously negotiated client TZ.
In EHRServer in particular, the times and datetimes are transformed to UTC and retrieved in that TZ too, so the client can choose to transform and display in any TZ, so there is no TZ negotiation there.
Generally speaking I don’t see much value on having constraints over TZ in archetypes or templates, and I don’t know one modeling tool that supports it, I guess for the lack of spec in ADL maybe.
I didn’t either, that’s why they were never in ADL in the first place. But having asked the clinical modellers, the answer seems to be yes, sometimes useful. So the fairly minimal change to the spec will hopefully not create much tool impact but solve the need.
?