Fairhaven, The River

Medical standards and leap seconds (aka Navigators vs Doctors)

Previously:

Leap Seconds
State of the Standards
What Matters When measuring
The UNIX-NTP real world compromise
What about SNTP (e.g., Windows)
What's wrong with the UNIX-NTP compromise?
What else is wrong with the compromise
What should medicine do about leap seconds? (First thoughts)

Steve Allen's comment about navigators helped me reach a proposal for what standards need to do about leap seconds for medical records.

Navigators understand their use of time and have a degree of control.  Doctors do not.

• Navigators understand how time affects their work.  Doctors do not.  Doctors understand human physiology, pathology, etc.  Time became relevent only when machines were introduced.  Time is just an engineering issue to doctors, so they point to the engineers and say "fix it."
• Navigators can make appropriate feature and quality tradeoffs for timing systems.  Doctors and hospitals cannot do much.  This is partly due to the differences in understanding and training.  It is also due to differences in safety rules.  Patient safety rules mean that doctors either use a standard pre-qualified product from a vendor (subject to FDA rules) or they use an experimental modified product (subject to internal IRB review).  It is immensely easier to use standard pre-qualified product.  The time and expense of IRB review and tracking is justifiable for medical trials.  It is rarely justified for other uses.
• Purchase and configuration decisions are based on the primary medical characteristics.  Time related issues are just an engineering detail to be fixed.

The challenge for medical standard is to provide recommendations that reflect these differences.  The standard products need to be usable in the real world when they comply with the standards recommendations.

1. They must be fully functional when added to the existing mess of good and bad implementations that are found in hospitals. Hospitals will not scrap all their existing equipment.  At most, they will be willing to reconfigure it.
2. The standards must be something that can be followed blindly.  The engineers are able to understand all these issues, but engineering resources are limited.  Product management wants the engineers to spend their time on improving the medical features.  So, to be widely accepted the standard must not require much thought to inplement.
3. The standards must withstand the well meaning bad advice that will be given and found in regulation and SOPs. There will be a lot of well meaning bad advice that is appropriate for very different situations.  This means both that the recommendations must be unambiguous and simple, and that there must be tutorials or informative material to explain the tradeoffs and reasons behind the choices.

I think that some form of the Unix-NTP compromise is appropriate.  The existing systems are a mix.  Some will both accept and generate leap seconds.  Some will accept but not generate.  Some will neither accept or generate leap seconds.  Fortunately, medicine does not need highly accurate time.  The administrative uses can accept large errors, in what I call administrative scope.  The operating rooms need close synchronization within their scope, but are otherwise like administrative uses.

One well meaning mistake is attempting to make the entire hospital an operating system scope.  This is impractical.  It would mean that every Windows system would need customized drivers and networking to support NTP, IRIG, or something similar.  This is a complete waste of time and money.  Receptionists, heating controls, and other administrative systems have no use for this added accuracy.  It is far less expensive to just maintain accurate synchronization within each operating room on a per operating room basis.  The only step needed is to hammer home to the administrative software developers that they must accept the occasional time jump and mis-synchronization of a few seconds.  That's just the nature of SNTP on Windows.  It does no harm for administrative purposes as long as the administrative software is properly written.

Another well meaning mistake is attempting to make the operating system scope closely synchronized with an external time base.  There is no medical need for this.  It introduces a lot of problems if you insist on putting leap seconds into the closely synchronized time traces for things like angiography, EKG, sound, and endoscopy series.  Medicine cares about their synchronization.  It doesn't care if they deviate from standard time by a few seconds or even a few minutes.

The compromise of introducing intentional controlled deviations from UTC allows the mixing of systems that do and don't support leap seconds.  The intentional deviation never has leap seconds.  The controlled deviation is compatible with the medical synchronization needs.  With proper software drivers, the controlled deviation is compatible with highly accurate time sources.  (This does eliminate a few products, but most products can be configured to use the unix-ntp compromise.)

So, how to get agreement and promulgate this.

Two cheers for Apple

I'm somewhat disabled by the temporary loss of use of my MacBook, but Apple does do a good job for their customers.  When the battery failed a few months ago the replacement took under a minute.  It was a simple "Still covered by extended care? Yes.  Here's your new battery."   Too many retailers still bury you in paperwork and questions.

Now it suffered an LCD failure.  (Ugly blotches appeared on the screen.)  The "genius" took a quick look at it, said "It's a hardware problem of some sort.", inventory check showed that it will be a few days getting the replacement, so I've got a receipt rather than a laptop.  Again, no fussy questions or paperwork.  The only downside is the wait for its repair.  (They replace the entire LCD side of the clamshell, and didn't have the glossy screens in stock.)

The advice to buy extended care with their laptop is very good. 

What should medicine do about leap seconds? (First thoughts)

Previously:

Leap Seconds
State of the Standards
What Matters When measuring
The UNIX-NTP real world compromise
What about SNTP (e.g., Windows)
What's wrong with the UNIX-NTP compromise?
What else is wrong with the compromise

Wishful thinking:  Just switch to TAI.  (TAI is the basic atomic time used by UTC, but without any of the leap seconds.)   Medicine doesn't care if earth-astronomical times drift slowly away.  Details about sunrise and sunset don't matter.  TAI is simple, well behaved, and entirely appropriate to medicine.

Unpleasant reality:  Pushing all of our ISO/ITU representatives to support the removal of leap seconds is more likely to succeed.  It is easier than dealing with the constant education and explanation issues that would arise if medicine were to just abandon UTC in favor of TAI.  Two industries have succeeded in ignoring UTC.

• Telecommunications (both landline and cellular).  These systems depend upon extremely precise timings among equipment scatter across continents.  Their timing demands are much stricter than anything in medicine.  Introducing leap seconds would have cost a huge amount of engineering, reduced reliability, increased cost, and served no purpose.  So telecommunications networks all use variations on TAI.  They are mostly of the form TAI+n seconds.  Telecommunications has extremely little need to share data with the rest of the world, so they just convert to approximately UTC when necessary for things like billing records.  Many such records are only accurate to the minute, so the conversion is often just roundoff error.
• Global Positioning Satellites (GPS).  Like telecommunications, these have extremely precise timing requirements that pushed the state of the art of atomic clocks.  GPS time is also TAI+n seconds.  Sunrise, sunset, etc.  are irrelevant to GPS.   GPS time is an almost closed system.  If you want to get GPS time, some receivers will provide it.  (Be careful with this.  Many of the low cost receivers have rather high phase errors and jitter.  They were designed for accurate positioning, not accurate timing.)

Medicine has almost constant interactions with non-medical systems at the administrative level.  So while it could act like telecommunications, there would be a lot of potential confusion and explanation needed.

If we can get leap seconds removed from UTC it would eliminate all this explanation and solve our forward looking problem.  Maybe the 2012 efforts will be successful.  The 2003 effort by the US was not sufficiently persuasive.   Increasing numbers of people are understanding that how much more this is beyond a simple "fix your software", and by 2012 we may be willing to watch sunrise and sunset slowly drift in the clock rather than suffer with extensive software design problems.

Unfortunately, standards are only part of the solution.  We have an unpleasant and inescapable legacy problem.  What should we do with all the existing records.  Some are administrative scope, some are operating system scope, many are poorly documented scope, many have timing errors.  This is all part of the growing petabytes of medical record.

Until leap seconds are removed, this will continue to grow at the rate of petabytes per year.

I believe that some variation on the UNIX-NTP compromise will be needed when dealing with all these records.  At least properly implemented DICOM objects provide a UID that identifies their time synchronization source.  This can be used to automate some of the grunt work of correlating and correcting records when necessary.

Next: Medical standards and leap seconds (aka Navigators vs Doctors)