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.