Time and DICOM 4
"Time is the simplest thing" - Clifford Simak
Core recommendation
Always use different attributes for observed times and predicted or scheduled times. Never use the encoding to indicate observed vs scheduled.
Store only atomic time (TAI) in the database and objects. (There is an exception for some scheduled times that should be kept in then-there-time.)
Convert to and from local time in the GUI. Only the GUI has the context needed to know the proper local conversion, and it may need to ask the user what to do in ambiguous situations.
This will not be easy. It places a large burden on the GUI implementations. But it is impossibly difficult for the object creators or database system to determine and perform the appropriate conversions to and from local time when the user looks at the data. They lack context and cannot ask the user to clarify the intended use.
Date/time encoding
Both ISO and XML have encodings that can handle TAI. The XML encoding has many fewer options and is easier to implement correctly. Neither deal with the issues of precision or accuracy sufficiently.
Observed time (is not predicted time)
The time of an observation is always in the past, which makes things simpler. But the accuracy is highly variable in healthcare. Some observing systems are properly synchronized and can capture the correct time to within nanoseconds. But lots of observations are made by people, who make mistakes. When it depends on human recollection, e.g., "I got that vaccination a few years ago" there can be both huge accuracy issues and extreme lack of precision.
An observed time (even in TAI) may be modified to reflect correction of mistakes or improvement of accuracy. It is not otherwise expected to change.
If issues of accuracy or precision matter, create separate attributes to capture that information. The standard encodings for time are not sufficient.
Predicted time (is not observed time)
The time and event is expected to occur may be either future or past. An example of a predicted past time is "The flight should have landed an hour ago". All of the issues mentioned for observed time also apply to predicted time. In addition, predicted time is expected to be revised. A common use case in healthcare is the scheduling of activities. The predicted (scheduled) time of events is routinely revised.
It’s important to never mix observed with predicted time in the same attribute. Not only are the expected behaviors different, there is often a need to record both when an event was predicted to happen and when it actually happened.
There are special cases where predicted time should be kept in then-there-time.
Then-there-time (TTT)
This is closely related to time zones, but also encompasses other calendar issues. People often use “EST” when they actually mean "in New York at that time". Time zones change, summer time rules change, etc. If I genuinely mean the absolute time 1800h EST it is safest to say 2300h TAI. That avoids many mistakes caused by implementer confusion. Using "in New York" is the kind of rule that a GUI can use to pick the proper local time. Standard software and time zone datasets can manage conversion between TAI and local. The datasets provide historical data about past time zone changes and expected future changes. This software can also deal with other variations like local solar time.
When you get into day of week and other calendar issues the better quality packages can help. In some locations and local conventions the day ends at sundown. That means that 11PM Friday is before 11AM Friday. If the database is in TAI and the GUI handles conversion to local you can avoid a lot of problems with this kind of location.
A GUI can deal with the nasty confusion that afflicts anyone who studies the Russian civil wars. The then-there times in Russia are thirteen days different than in Germany or UK. The February Revolution (Russian calendar) took place in March (using the English calendar). This was more than just a time zone difference. Russia was still using the Gregorian calendar, which has different leap day rules. This is of more than historical interest. Local solar time and lunar calendars are an ongoing issue.
With a user interaction at the GUI you can manage all these conversion issues, although this may require asking the user what location they want used for time entry and time display.
One nasty problem that TAI time does not solve is the scheduling issues that arise for scheduled events when the rules for summer time change. If an appointment is scheduled for “3PM New York time on <date>” it is possible that the summer time boundary will change in a way that affects the corresponding TAI time. This is one of the special cases where time should be kept in then-there-time rather than TAI time, or have another attribute to indicate the desired then-there time.
International Atomic Time (TAI)
This is almost UTC. It does not do leap seconds and references only atomic vibrations rather than including earth rotation synchronization. It matched UTC in 1958. Subsequent leap seconds made it 37 seconds ahead of UTC in 2017. Healthcare does not need to maintain sunrise and sunset coordination to the second. Avoiding the 61 second minute (a leap second) and the many associated bugs in many incorrect time libraries justifies using TAI. If the precision needed is to the second and the local user genuinely needs UTC, the GUI can deal with it. The time databases include the times of all the leap seconds.
The challenges for a GUI
The user interface often has the information needed to determine what to show the user. It can be a mixture. A travel application may show the expected departure time, arrival and departure times where making a connection, and expected arrival time to pick up a rental car. In the context of a travel itinerary it knows the locations for all these predicted events, and can assume that “then there time” is the proper time to display. If all these locations are in different time zones the GUI should be able to pick the correct zone and label the correct time for each step in the itinerary.
There is a lot of context that goes into deciding what time or times to show a user, and to clarify what inputs to expect. In highly routinized applications like healthcare, the GUI will often have sufficient context to know what the expected locations are and what is appropriate. It will have to interact with the user in situations where it lacks sufficient context.
This is hard, but within the scope of a GUI. It’s impossible for a database to have this context. That is why the recommendation is that data objects use TAI. The GUI knows that the data object uses TAI and only has to adapt to varying user needs. In DICOM 4 objects only a few attributes will deal with predicted times that might be subject to changing summer time or other such disturbances. They can be special cases and have additional attributes to deal with specifying the location for then-there times.