Fairhaven, The River

US Security terms (sensitivity vs confidentiality vs consent)

There is a confusion that I found in some HL7 documents, perhaps copied from some ISO documents, about how US Security classification terms work.  They seem to think that these are sensitivity terms.  In fact, they are much closer to consent OIDs and confidentiality categories.

The simple form of US categories is:

•   Confidential
•   Secret
•   Top Secret

A person having a clearance for Confidential means that they have passed one form of background investigation.  Secret and Top Secret mean passing more stringent background investigations.  Rating a sentence in a document as "Secret" means that it is approved for disclosure to a person having a Secret or Top Secret clearance, but not to someone with only a Confidential or no clearance.  That is like the consent for disclosure in Healthcare.  The document is specifying a category of people to whom the information may be disclosed.  There is no hint as to what the consequences of this disclosure might be, so this is not like sensitivity.

The rules are of course more complex than that over-simplification.  There are also need-to-know rules.  These are vary similar to the patient and role-based rules found in healthcare.  Regardless of clearance levels, a classified document should only be disclosed to people who have a need to know.  This is usually because they are working on the project (analogous to Patient ID) and on a specific aspect of the project (analogous to role-based access).

There are also project or category specific access terms, which can generically be called codeword access.  Gaining codeword access requires additional clearance effort.  This may be merely an administrative matter or it may require substantial background investigations and other steps.  These usually require (but not always) a top secret clearance.  There is a large number of codeword projects and the codewords themselves are sometimes secret.  This kind of clearance is generically called "Special Access" and "Special Compartmentalized Intelligance".  But their operation is very much like a consent OID.  The difference from the general form is that it also has codeword specific clearance activity.

A document that is "Top Secret" with code word "Wet Cat" is only disclosable to someone approved for "Top Secret - Wet Cat".  That is basically the same as a document coded as available to any person approved for OID 1.2.3.4.5.  Both are opaque pointers that reveal nothing about the nature of the sensitivity.  You don't know whether "Wet Cat" is related to diplomatic activity, weapons technology, intelligence gathering, or anything else.  You don't know what the implications or severity of an unauthorized release will be.  All this is hidden, and that is by design.  The nature of sensitivity is itself often sensitive information.  This is like the healthcare consent model.

So there is a very clear misunderstanding in these documents when thay claim that these are sensitivity categories.

A cruel standards writer

  There is a cruel standards author out there somewhere who said that SNTP could be used to achieve micro-second level synchronization.  This has led far too many people into mistaking it for an easy task.

  First, consider the timing issue of transmitting the SNTP query/response over ethernet.  The message size is about 100 bytes, including prefix and trailer sync signals.  So, on a 100 Mbit/s link this is 8 microseconds.  But, if it's a switch there is another prefix related delay.  And, if there is another message in transit at that moment the switch will buffer the SNTP message until that other message finishes.  A maximum length message (1500 bytes including prefix and trailer) will take 120 microseconds.  Since the switch will start the next message as soon as possible, this introduces a variation of 0-120 microseconds.  SNTP does not include the statistical estimation information needed to remove these variations.

To potentially reach microsecond level synchronization with query/response you must do the following:
 - Have a direct connection between client and source with no other systems or any other use of that link.  It can only be a one to one connection.  This eliminates the variability from other traffic.  (NTP has statistical estimator logic, so the variability can be removed.)
 - OR, have a single purpose network with only source broadcast and all client query eliminated.  This also eliminates that potential variability.  This allows one source to send time to other clients.  The clients must dedicate a network device to the exclusive use of the time system.

But, that is just eliminating the network variability.  What about system clock variability?  How long does it take for the OS to process the incoming network message and adjust its internal time?  When an application issues a time query to the OS, how long is the delay between request and response?  how accurate is the internal time computation?

The OS network delays can be measured.  You just need a high precision interval timer, logic analyzer, and strict configuration control over the ethernet switch.  Then you measure these delays for your system.  The biggest difficulty is within the OS.  Real time OS usually have stable interrupt response characteristics, so once you measure it, you can then use that as a correction factor.  But, general purpose OS, such as Windows, do not have a predictable interrupt response latency at the microsecond level.  If the OS gets really busy on high priority internal tasks it can take hundreds of microseconds to respond.  The network is usually treated as a low priority interrupt by general purpose OS.

Again, NTP uses statistical estimators to reduce this variability.

The next issue is, how accurate is the internal time?  The SNTP broadcasts can't be too frequent.  If you are constantly pinging the systems with high priority SNTP traffic, there won't be any time for the primary function.  The practical limit is usually 100-1000 pings per second.  So for at least a few milliseconds the local system clock needs to provide that microsecond level time measurement.  How will it do it?

The very old clock methods were simple but inaccurate.  The clock would just be incremented when the clock tick arrived.  If the SNTP broadcast is 100/s, then you increment the clock by 10ms each time.  This works fine if all you care about is 1s accuracy and don't mind that everything that happens during that 10ms interval is assigned to the exact same time.  For lots of administrative tasks this is a good solution.  It's cheap and easy.

For the microsecond level timing none of the purely tick related approaches will work.  There is no OS that can both get useful work done and process a million timing ticks per second.  Even the network cannot manage that.  You need a gigabit network before it can carry that many tick messages.  Instead, you need a local free running clock that provides a short term timer for periods of about a second.

Most simple CPUs and systems have such a timer.  The original PC had a separate interval timer chip that had three clocks.  One was programmed to provide an interrupting clock tick at a slow interval of 10-100 ticks per second.  This was used to maintain the long duration system clock.  Another could be programmed to increment an internal timer much more rapidly.  A typical increment rate might be every 10 microseconds.  This rate was usually limited by the available hardware crystal timing source.  The same capabilities are present in modern CPUs, usually with a faster hardware crystal and often integrated with other components onto a single chip.

In a system like that, when the application needs a time marker, it issues an OS request.  The OS uses the long duration system timer to get a base time and then corrects this by reading the high speed timer value and computing the proper offset.  If the OS has a proper real time priority structure this all happens with a fairly stable speed.  You can measure it with proper interval timer, logic analyzer, and similar equipment.  You get microsecond level accuracy.  Another excellent and easy to use high speed timer is the CPU cycle counter available on most CPUs.  But, multiprocessor CPUs and power saving through clock speed changes make this impractical on most new CPUs.  This is one reason that measurement equipment tends to avoid the very high performance CPUs.

The NTP systems will use the same approaches to obtain accuracy.  They use statistical estimation theory to eliminate some of the variability, so they can be used on a wider variety of operating systems and often without the use of logic analyzers to measure internal computer state.  (With new integrated processors it is hard to get the access needed to use a logic analyzer for these purposes.)  But we're dealing with the claim of microsecond level accuracy from SNTP.

The NTP systems also enable the use of atomic clock controlled pulse generators.  These can be attached to internal interval timers or they can be used as simple edge pulse timers.  SNTP lacks the logic to manage combining of clocks into a single more accurate time estimate.  The NTP use of atomic clocks as internal interval timers or as edge timers is based on using the atomic clock to measure the drift rate of the other clocks.  It is normal for the internal timer clocks of computers to be inaccurate by up to 1 ppm.  This can usually be ignored for administrative purposes.  One ppm is a drift of 1 second every two weeks.  It's stable enough to be accurate through a very long network dropout.  When using NTP and an atomic clock the drift rate can be measured, and it can be removed every second.  (Most simple atomic clocks are set at 1 pulse per second).  With a measured drift rate there is a residual drift due to temperature and atmospheric pressure changes to the crystal.  These are usually under 0.01 ppm.  So you've met the sub microsecond requirement.  SNTP does not include the information needed to do this.

So we have a cruel standards writer.  Yes, you can make microsecond level accuracy with SNTP.  Of course you also need specialized network design, logic analyzers, a real time OS, precision interval timers, and a lot of custom product engineering. 

 

Encrypted Disks

The May CACM has an article on recovering passwords from RAM and using that to break protection on encrypted hard disks.  It remains crucial to decide what risks you have and what the real threat is.  DICOM just approved the standards for using password protection on removable media.  (It already had PKI based encryption covered, but in practice the password based in far more usable.  With suitable precautions it is probably just as robust against the real threats.)  It protects reasonably well against exposure through media theft, but only with the assumption that the passphrase is well protected.  If you write the passphrase on the media, you eliminate most of the protections.

My risk analysis based on their work is this:

1. If you are personally a target, all current disk encryption methods will be breached.  You might be a personal target through criminal activity, military activity, political activity, etc.  Disk encryption is not protection for you.
2. If you are a target of opportunity, disk encryption alone can be breached.  Actually, some techniques like the default TPM and basic Bitlocker of Vista reduce your protection because they fool you into thinking that you are protected, while in fact you are not.  Most people are a target of opportunity.  If a thief steals your laptop and thinks - "I wonder if there are any worthwhile secrets on this thing?" you just became a target.
3. If you are worried about parts depot repair, recycling, re-sale, etc. then current disk encryption is usually good protection.  Just make sure to shut down a few hours before handing over the system, or make sure that they remove the disk and are not left alone to play with the system.  Of course erasing the disk is even better if you know that the disk will be sold or re-used.

The problem is that at room temperature the RAM bits take too long to zero.  There is ample time for someone to reboot the system using either USB boot or PXE boot and copy out the contents of RAM.  You need to be power off for 30+ minutes before there is much confidence that data will not be recoverable.  They did the proof by implementation that automated RAM scanners can find passwords and break in to all of the popular open source and proprietary disk encryption systems.  The keys are right there.  (If you use TPM and basic Vista bitlocker, you can have power off forever and still get the keys.  The keys are in non-volatile RAM.  Bitlocker users should use one of the more advanced modes.  Microsoft should remove the basic mode.)

In practice there is also the extremely serious problem that laptops are basically left on all the time, although for power reasons they may be in standby or hibernate modes.  This is because it takes too long to boot, and it takes too long to restore user context.   One of the reasons that I and others like the Mac is that you can just close the lid and it goes to sleep within seconds (and nothing breaks).  You can restore operation by opening the lid, and again it is ready within seconds.   You can configure it to ask for a password, but the keys are not scrubbed from memory, so a sleeping system can be stolen and keys retrieved.

If boot were really fast (through techniques like saved context information on disk), the memory (or at least keys)  scrubbed on sleep/shutdown, then systems might be somewhat secure.

Something to think about when protecting information from opportunistic theft.

Pace Layering and standards

Pace layering is a concept that I first saw in Brand's book "How  Buildings Learn."  The concept is that there are different layers of organization and structure that evolve at different paces.  In a building I might have:

1. My desktop, where contents are re-organized hourly or even more often
2. The equipment layout, which changes every few weeks
3. The cubicle walls and furniture, whose layout changes a few times per year.
4. The internal walls, which only change every few years or longer.
5. The building envelope and infrastructure core (plumbing, etc.) that change every decade or two.
6. The multi-structural components (like electrical outlets) that very rarely change their design.

These layers are in a constructive learning tension.  I am limited by the interior walls.  They constrain the available cubicle and furniture placements.  They also support the workflow, privacy, and operations.  I may complain that I want a wall or door moved.  If it is important enough, this may happen, but it will be at a different pace than my furniture layout changes.

This same situation is present in standards.  The building example has standards at several layers.  The cubicle maker has standard heights, shapes, and possible layouts.  These are moderately ephemeral, changing as models change.  They are somewhat multi-vendor, but that is not well coordinated.  The electrical outlets are extremely stable and very restrictive, with uniform implementation by every vendor of electrical outlets.

You need to think about the pace levels of your problem space when working on standards.  Putting a standard at the wrong pace level is a serious problem.  So it is important to consider the stability of the problem space, the process and speed of standardization, and other pace related characteristics.  You need to ruthlessly separate items that are at different pace levels.  The standards process for something that changes rapidly (like furniture layouts) must be very different than that for something that changes slowly (like building walls).  Mixing the two may be tempting from an organizational perspective, but it is a bad idea.

Creating this separation will lead to some difficult and emotional conflicts.  Excluding something "important" because it is at a different pace level creates difficulties.  The use of terms like levels helps, because the excluded work is at least recognized.  But telling the advocates to go find another home can still be very difficult.  There will also be strong process conflicts.  The rapid, informal, error tolerant process appropriate for furniture layout is much easier than the slow rigorous process needed for changing the building envelope.  People working on the envelope will be tempted to take shortcuts that are not appropriate, especially if they also are working on furniture layout problems.

The rapid pace may be envious of the "power" that the slow paced standards have.  There is a temptation to seize the power that the envelope standards have to control and limit the available furniture layouts.  But furniture layouts should not be subject to the kind of strict controls that are appropriate for a building envelope.

There is no simple easy answer.  But proper consideration of pace levels is critical when defining the scope of new standards efforts.

(Why am I thinking of this now?  The current HITSP effort needs to think about pace leveling, and I was just reminded of Brand's book because I found it while cleaning up my office area.)

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.

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)

What else is wrong with the compromise?

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?

The other big problem is that the compromise assumes that none of the processing software implements UTC leap seconds fully.  One problem point is time difference computation.

What is the time difference between 20081231235959 and 20090101000001 ?  Almost all systems will say "2 seconds".  It's the obvious answer, but it's wrong in UTC.  According to UTC, there is a 3 second difference.  That's because there will be a leap second at the end of December 2008.  The UNIX-NTP compromise was pragmatic.  The compromise is motivated by allowing use of the extensive library of existing software that does not handle leap seconds. 

Implementing leapseconds completely means having configuration files that list all the leap seconds and which check every time difference computation to see whether that happens to include a leap second.  UNIX can do this.  But it means that you need to regularly update this configuration file.  Leap seconds are not predictable more than a year in advance.  This greatly complicates both system administration and software development.

The compromise is pragmatically correct.  Very few applications make use of the leap second configuration file as part of their time difference computations.  But it is a potential problem whenever systems get updated.  You never know when an old application will be updated.  (I know of systems that deal with this issue by intentionally changing the configuration files to eliminate the list of leap seconds.  This may mean deviations from UTC in some instances, but those deviations don't matter.  Eliminating these leap seconds ensures that all of the time analysis programs (both UTC aware and not) give the same results.

Quite a mess isn't it.

The UNIX-NTP real world compromise

Previously:

Leap Seconds
State of the Standards
What Matters When measuring

It's inescapable that a real world solution will need to deal with applications that cannot generate nor accept UTC.  Some may be in compliance with one of the self-contradictory standards, or be earlier versions of software that complied with a standard that was at that time ambiguous or self-contradictory.  They may have simply ignored the standards also.  SQL92 may win the record for first to be correct, but it doesn't take long to find widely used implementations of SQL that do not support UTC properly.  And some applications just made up their own formats because there was no standard applicable.

The UNIX-NTP compromise is based on the following assumptions:

1. The scope is an operating room scope, so a large phase error relative to real UTC is permissible but only the small phase error is permissible between machines within the scope.  The frequency error needs to remain very small within scope, but can be larger when compared with UTC.
2. The clocks are all under control and all synchronized to a common operating room scope source.  No exceptions can be allowed.  The clocks might be external clocks or they might be operating system clocks.  Any clock used in the data gathering must be controlled and synchronized.  (This can be done without too much cost if you are careful.)
3. The applications are a mix of UTC and non-UTC supporting applications.  So the clock time must never show more than 60 seconds in a minute, even during the leap second of UTC.

You do this by deliberately selecting an inaccurate but well behaved clock for the operating room scope.  If you intentionally slow down the scope clock by 0.01% starting 5000 seconds before the leap second, your scope clock will be at 59.5 seconds when UTC is at 60 seconds.  This is 500 ms slow, but that's fine for administrative scope.  All of the operating scope clocks can remain synchronized to this slower clock to within 10ms.  The frequency error of 0.01% is well below the frequency error limit for operating scope.  Then, when UTC time is at 60.5 seconds, the scope clock rolls from 59.99 to 00 in the next minute.  Suddenly, instead of being 500ms slow, it's 500ms fast relative to UTC.  But this is OK because UTC is only in the administrative scope.

Eventually, about 5000 seconds after the leap second, the scope clock can be returned to normal speed and continue to track UTC.

This trick will not work if UTC needs to be within operating room scope.  Fortunately, I know of no medical reason to have UTC within operating room scope.  Administrative scope is adequate.  The UNIX-NTP trick is actually the default configuration for many UNIX NTP systems, because operating system scopes like this are very common in many applications.

The most demanding and difficult part of making this work is:

1. Having local system clocks with NTP support that permit frequency control to this level.  Almost all PC hardware and other hardware is capable of it, but the default clock drivers for most versions of Windows do not support this level of control.  (I haven't checked Vista, but non of the others have this degree of control).  So Windows based systems need to have the default windows clock drivers replaced with special NTP capable drivers.  These are available from third party vendors.
2. You need to find and fix every machine without exception.
3. You will have significant difficulties later if you need to synchronize this data with other external data and need better than administrative scope synchronization.  The clocks are intentionally not matching UTC.  You will need to tolerate these mismatches.

Those conditions are reasonable, and there are thousands of little islands of synchronized time that are using the UNIX-NTP solution.

Time (What matters when measuring)

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.

Time (State of the Standards)

Standards that explicitly support UTC

SQL92 wins the award for earliest standard that I've found that correctly specifies support for UTC.   It explicitly states that time contents should be UTC and that a minute may have 59, 60, or 61 seconds.  (Actual implementations have not always complied with this part of the standard.)

W3C clarified XML's time format in the 2002 version to make clear that time should support UTC and that a minute may have 59, 60, or 61 seconds.  Unfortunately, it was silent in earlier versions.  Worse yet, the early drafts incorrectly stated that there were 60 seconds in a minute.

DICOM clarified it's time format in 2005 to make clear that time should support UTC and that a minute may have 59, 60, or 61 seconds.   Unfortunately, it was self-contradictory in earlier versions.  It said both that UTC should be supported and that a minute had 60 seconds.

Update: Michael Decker (in comments) notes that ANSI C 1988 got this right.  So it's the new winner.  As with SQL, actual implementations have not always complied with the standard.

Standards that are self-contradictory

The ANSI HISPP MSDS work for healthcare in 1992 was self-contradictory.   It stated that time should be UTC, and that a minute contained 60 seconds.  This was copied either directly or by reference into HL7, DICOM, and other medical standards.

The IEEE POSIX interface standard is similarly self-contradictory, stating both that time should be UTC and the minute contains 60 seconds.  (There are many different implementation variations and there is no assurance that a UNIX system implements this aspect of POSIX.)

Standards that are silent agnostic

The ISO 8601 is silent agnostic, and a great many other standards use the 8601 standard as a reference for time formats.  8601 merely requires that there be from 1 to 99 seconds in a minute.  The problem is that everyone "knows" that there are always 60 seconds in a minute. 

Update:  It documents the formatting of leap seconds.  As a format specification, it does not have application behavior requirements on how to implement support.

Next: What healthcare needs