Fairhaven, The River

What it will take for EHRs to achieve that Visicalc moment

John Halamka asks what will it take for EHR to have a Visicalc moment.  I'll answer based on three more examples:

• The IBM Selectric
• The HP 35 calculator
• The HP business calculator (a flop)

The first two were explosive successes that predate Visicalc and the personal computer.  They were at least as big as Visicalc.  The Selectric eliminated key jams, messy ribbons, manual carraige return, and added the correction tape.  The HP 35 removed the problem of doing scientific calculations with adding machine and slide rule. But the HP business calculator was a flop.  A marketing executive at HP explained why, and his explanation holds true for Visicalc and other would be successes.

The big winners win because the potential user instantly recognizes the product as a solution to a personal problem.  The business calculator flopped because potential buyers didn't see the problem.  What was wrong with using printed interest rate payment tables?  Occasionally a buyer would be in a negotiation with someone who had a caclulator.  The differential advantage the caclulator gave of immediately knowing the implications of changes to terms made the value apparent.  But these were uncommon.   Buyers were rare.  The HP executive analogized to the hoof-operated fence cutter.  It's a spectacularly important product to beef cows.  But cows don't grasp the problem or see this as a solution.  So it will never succeed as a product.

For the EHR the win will be when the users (physicians, nurses, etc.) must see the EHR as a solution to a problem.  It's fairly easy to talk with them and learn what is it about their job that they love.  You quickly find things that are described as "this is why I love my work".  Make sure that the EHR does not interfere with these. Equally easy is finding parts of their job that they hate.  These are usually the wasted time, screwed up schedules, missing information, time wasting data entry, and stupid endless form filling.

If the EHR genuinely eliminates the parts of the job that they hate, it will be a winner.

I have seen this effect in radiology with PACS equipment.   One example is the transition to CR from plain film.  Nurses and techs hated the darkroom, developer, and chemicals.  They hated the problems getting exposure right.  They hated the delays carrying films around.  The CR eliminated these and were immediately popular.  A very recent one is the use of DICOM for retinopathy screening.  It enables doctors to grab the next study and read it when a scheduled exam is slightly delayed.  They hate sitting around for 5-10 minutes doing nothing.  It's not very long, but it's enough time to read one study.  The PACS workstation let them grab the next study, read it, and report it during delays.  Not only were the doctors happy, but they found that screening throughput increased 20% without changing the hours on the job.  The administrators were very happy.

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.

Media Passphrases in DICOM

There is an issue regarding how DICOM should specify the use of a pass phrase as part of the addition of pass phrase based media encryption.  This discusses the issues and my current recommendations.

Meta-discussion (DICOM Philosophy)

DICOM provides a complete interoperability specification.  It does not leave out critical components.  But, DICOM does not want to re-invent wheels.  For example, DICOM devotes several pages to precisely specify the use of TCP/IP and several pages to how DICOM conformance statements will document the use of network options.

There are issues surrounding the pass phrases for media encryption that need some degree of specification.

Scope and Assumptions

I will assume that the users are able to convey the pass phrase somehow, most likely orally or in some printed form.  They can deal with issues of proper spelling, capitalization, writing system, etc.   An example of writing system selection is conveying whether the hanzi are in traditional or simplified form.  All of these can affect the use of a pass phrase as an encryption key.  Users will understand this and be able to convey this kind of information.

The problem arises because the RFC specifies how the byte sequence of the pass phrase is processed to create the encryption key.  The RFC does not specify the relationship between the byte sequence and the user conveyed pass phrase.

I believe that DICOM must specify this relationship and might give guidance regarding some of the operational pass phrase issues.

Issues

Encoding Systems

In China computer systems utilize Big5, GB2312, GBK, GB18030, and Unicode.  Internally the Unicode systems might use UTF-8, UTF-16, UTF-32, UCS-2, or UCS-4 encoding.  There are similar internal variants for GB18030.   So there are more than ten possible byte sequences that might be used internally to represent the exact same pass phrase.  With the exception of GB2312, GBK, and GB18030 using UTF-8 these will be different for a passphrase using normal Chinese and latin characters. 

Similar issues arise around the world with the mixture of ISO 2022 and 5 possible Unicode encodings.   The only major world segment where this is a lesser issue is in the English speaking countries.  The latin alphabet is encoded the same way for ISO IR-6 in ISO 2022, ASCI, Big5, GB2312, etc.  The issue of Unicode internal coding does remain a potential problem for the latin alphabet.

Unicode (and GB18030) specific issues

There are some further issues that are unique to Unicode and GB18030.  GB18030 inherits these issues from Unicode, so for the rest of this I will just refer to Unicode terminology. 

Composing Characters and related issues

Many languages have accented and modified characters.  Unicode includes some code points for pre-composed characters such as an accented "e".  These characters can also be represented by two composing characters: an "e" and an accent.  These will have two different byte sequences.  The Unicode report TR-15 discusses the issues of composing characters in much more detail.  Composing characters matter for string comparison, hash codes, and other computer functions.

The W3C, IHE, and others have recommended the use of Normalized Form C (NFC) from TR-15.  DICOM will need to specify the normalization in order to get consistent byte sequences for pass phrases.  NFC is the appropriate form to use.

Composing Languages

Some languages, like Thai, have no pre-composed characterset available.  For this kind of language there are language specific rules regarding the proper ordering of the code points used to compose the final representation.

Multi-lingual use

Many media exchanges will be among systems that all support the same language; but, there will also be exchanges that cross language boundaries. Issues that will arise when this happens include:

• homotypes - One example is the  Serbian "dot-less i".  This is a different code point than the composing dot-less i.  It is nearly impossible to tell these two apart visually, and in many fonts the two are identical.  A system configured for Serbian will use the Serbian character.  A typical configuration for other European languages is to use the composing dot-less i.  Data exchange between Serbian and non-Serbian systems will fail mysteriously.  It is not reasonable for users to recognize this kind of problem.

            Many of the punctuation marks, space characters, dashes, etc. are also homotypes.

• Ad hoc solutions - Enterprising users will try to use available alternative data entry systems for unsupported character sets.  For example, Greek may be entered by using the local equation support.  But some of the mathematical characters that look like the Greek characters are different code points.  These are not true homotypes because the characters do look somewhat different.  This difference is subtle and is likely not noticed by the users.
• Complete failure - There will be many system - language combinations that simply do not work.  It is not practical to enter any of the composing writing systems (like Thai) on a system that lacks data entry support for that language.

My Recommendations

It is not reasonable to expect users to know how their characters are encoded internally.  Only the software developers know what internal coding system is used and what byte sequence is provided to the encryption algorithm.

DICOM must specify the byte encoding algorithm to be used for encryption.  I would require that it be Unicode text in normalization form C encoded using a minimum length UTF-8 encoding.  This is regardless of the local system internal encoding preferences or language support.

We need proper wording to explain why this matters and that this is a requirement for defining the byte sequence used to generate the encryption key, not a requirement on the user interface.

The multi-lingual issues, and the need to support archival uses, also drive the need for an option that does constrain the user interface somewhat.  All of the encoding systems support the latin alphabet (ISO IR-6).  DICOM has mandated that at a minimum, any DICOM conformant system must support the latin alphabet.  (For those not accustomed to the jargon, ASCII is an encoding of the latin alphabet.)

DICOM should specify a pass phrase interface option that restricts the pass phrase to use only characters in the latin alphabet.  This option can then be used when describing a particular piece of media.  The name "International Latin pass phrase" could be used to describe a software capability as well.  The users can then specify that they want media with an "international latin pass phrase" when they need to ensure that any DICOM compliant system be able to process the encrypted media.

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.

Decent food at a conference

I regularly complain about the terrible things that travel does to my diet. For the first time that I can recall, I'm getting suitable food at a conference. The HL7 conference lunches are genuinely suitable food. There is a salad that is tastey components, not just an excuse for fat laden dressings. The fruit is large quantities that are expected to be eaten, fresh and tasty. This is not the fruit display that is expected to last all week. Then they have good fresh vegetables without a sauce and meat in it's own juice. The only traditional carbs and fat offering is the potatoes side dish.

This is a great improvement over the usual carbs (bagels, pastry, more pastry, more carbs)and coffee, with fat laden carbs and meats for the meals. It is much easier to eat properly when the food is suitable.

Tonight's dinner was with relatives. Fish and lean beef on an electric grill at the table, eaten wrapped in lettuce leaves.

This is the first trip in a long time that is not a dietary disaster. Being in San Diego does make a difference.

Physicians waiting room delays

A little while ago DB’s Medical Rants noted a proposal to penalize patients who miss appointments.  This got me to thinking about the overall problem.  First, it is true that there are some supremely self-centered jerks who pose serious problems to everyone because the jerks refuse to keep schedules.  But the proposal to simply penalize patients is also wrong.  Many patients are also facing difficult schedule constraints in their work and personal life.  The physicians failure to keep schedules is similarly a problem for the patient.

So perhaps the fair thing is to penalize both patients and doctors for failing to keep appointments.  A certain level of failure is inevitable.  Something like introducing penalties if more than 10% of appointments are not met is appropriate.

I expect doctors to be outraged at the thought.  I'm accustomed to hyperventilating self-importance about how their delays are necessitated by critical patient care.  This may be true, but it's hardly unique to doctors.  Many of us must meet schedules for important purposes while dealing with unpredictable delays and emergencies. 
Simple process engineering techniques like queueing theory exist to manage these problems.  I've worked in manufacturing environments with trained high school graduates who could handle these techniques.  If a high school education plus training is enough, the MD can learn them also.

I've even experienced this with an MD who genuinely managed his schedule.  He accepted a small loss of income and left several 15 minute gaps in each day.  These accomodated the occasional overruns, made space available for last minute problems, and if nobody needed the time the MD could use it to catch up on other work.  If you accurately measure the schedule arrival rate, overruns, and last minute arrivals you can determine how many gaps are needed and where best to put them in the schedule.

Most MD schedules are designed to maximize the efficient utilization of MD time.  Patients are insignificant nobodies whose time is worth nothing.  Patients understand and respond to this treatment with a corresponding hostility to the physician schedule.  The endless waiting room time is not welcome.

At the exceptional MD this was different.  In part, this was because long delays were unusual.  He also experienced a lower than usual level of missed appointments.  When you respect the patients' time value, they respect yours more.  This did not eliminate the occasional jerk patient.  But the problem was lower.  This was an environment where mutual penalties for missing appointments would not be a serious problem.  Only the jerk patients would be suffering penalties.