Scope, Phase, and Frequency
Time is recorded for a purpose, and the proper response to leap seconds and other time related issues depends upon this purpose. In all cases time is used for some sort of synchronization activity. This synchronization has a use related tolerance to errors. (It is impossible to measure time with no error. See Heisenberg for theoretical limits. The practical limits are much larger errors.) To simplify the discussion, I find that there are three common characteristics of the use description:
- Scope, which describes the time and spatial area that needs synchronization. For example, one scope can be the equipment in a cardiac cath operating theater. ECG, imagery, sound recordings, and other data that is independently gathered needs to be synchronized using time stamps. The time stamps might also be for more than one scope. Those same cath machines might also be in the hospital administrative scope, using time to synchronize patient transport activities. These two scopes will have different accuracy needs.
- Phase error, which describes the time offset between a time measurement and the standard time reference, or between two time measurements. Phase error is of course variable. The major use of this term is specification of tolerable phase errors. Most hospital administrative time has a tolerable phase error of 50+ seconds. In the paper administrative world time was often recorded just to the nearest minute. When matching voice to video frames, the tolerable phase error is usually tens of milliseconds.
- Frequency error, which describes the stability of ongoing time measurements. A clock that drifts one second every 10,000 seconds has a frequency error of 100 ppm. For purposes that have a very large tolerance for phase error, there is frequently little or no limits on the frequency error. For administrative purposes where time is recorded to the minute, the tolerable frequency error tolerance is often just a statement that time must always run forward. The phase error tolerance is all that matters. For scientific purposes, like EKG measurements, and multimedia purposes, like synchronizing voice and image, there are often significant frequency error tolerances that are different than the phase error tolerances.
The frequency error is where leap seconds are especially problematic. The UTC time base suffers a staggering spike in frequency error if leap seconds are not properly handled.
Realistic frequency error tolerances in health care are those related to heart and breathing cycles. An EKG trace is expected to have a maximum frequency error of 1% over the length of the record. Often the phase error can be fairly large, provided the frequency error is small. Audio playback is another area where frequency error must be kept very small. Human hearing is quite sensitive to frequency errors, hearing them as hops or distortions in the audio. You can tolerate a moderate phase error much more easily, accepting a lag between voice and video playback. Unacceptable pops and distortions will be heard if the frequency error is too large.
Most of the health care scopes fall into two categories:
- The administrative/security scope that tolerates a phase error of a few seconds and tolerates a very large frequency error as long as the phase error limit is met.
- The operating room scope that limits the frequency error to a maximum 1% relative to the standard second, and prefers a internal phase error of tens of milliseconds. (This is good enough to match sound and video, or to match heart beats and imagery.) The external phase error (relative to UTC) can be hundreds of seconds, so it can be considered in the administrative scope, provided that the internal phase errors are kept small.
Leap seconds are an issue when dealing with the operating room scope. In the administrative scope a system that manages leap seconds will remain acceptably synchronized with a system that does not manage leap seconds. But in an operating room scope, either every system must ignore leap seconds (and thus not comply fully with UTC) or every system must handle leap seconds appropriately.
Ignoring leap seconds is not that bad a choice, but every machine involved must make this choice if that is the solution chosen. It is reasonable to postpone the introduction of the leap second until there is no operation in progress. The operating room scope only covers the time span while an operation is in progress. Having inconsistent application of leap seconds and the associated massive frequency errors and multi-second phase errors, do not matter to the administrative scope.
Next Implementation issues in meeting the needs of the operating room scope.
I would point out that intensive care units use sophisticated monitoring equipment that is networked at least within the department. It is highly probable that each such unit will always have at least one particularly critically ill patient being monitored and/or aspirated and/or intravenously fed and medicated.
As systems become more sophisticated, automated, interlinked and dependent on non-stop running, the possibility of a software glitch arising from the application of leap seconds will increase.
Posted by: Robert Jones | November 28, 2008 at 06:50 PM
That's part of why this series. Fortunately networked is not the same as operating room scope synchronized. Synchronization is something that can be designed. For a large part of the network, administrative scope will be sufficient. I may need millisecond level synchronization within an OR, but it is hard to find a medical reason that two ORs need to be synchronized to each other better than to the minute. If you design your applications and interfaces properly you can remain safe while tolerating administrative phase and frequency errors.
Doing this does require understanding the motivation for the time synchronization. Many scheduled tasks (patient transport, drug administration, etc.) tolerate errors in minutes. Those within the operating room scope need much more accuracy. This is something that should be designed rather than accidental. An accidental design will be more fragile and more hazardous to the patients.
There are real world issues beyond leap seconds that make synchronization more and more difficult as the acceptable errors get smaller or the number of machines gets larger. Part of ethical engineering is designing the systems to have the least sensitivity to these problems. It's part of safety engineering.
Posted by: fairhavenhorn | November 28, 2008 at 09:30 PM