Flexibility will be the Key Ingredient

As we get closer to talking about HOW to address specific Health Care product/service issues, I want to point out that simply overlaying 'what we have' with something else is no guarantee for success. Nor are we guaranteed a REAL solution by moving in the direction of 'adapting' an existing program which is already known to be 'broken' and in need of 'repair'.

I would like to state for the record that, IMHO, the most serious problem we face - in Health Care and most other areas - is the tendency (desire?) to apply 'rigid controls' upon a complex system because 'we don't like the way things are'. Unfortunately, this attitude gets in the way of Addressing The Real Issue system with any Long-Term prospect for success simply because: CHANGE HAPPENS... Whatever we design *must* be able to cope with sociological and political changes that WILL happen in a fluid, modern environment.

Therefore, I submit for our consideration, Ashby's Law aka "The Law of Requisite Variety". It comes from the field of cybernetics and is stated in many ways, one of the simpler (?) versions is something like:

"The variety in the control system must be equal to or larger than the variety of the perturbations in order to achieve control." (And that's one of the simpler ones?)

When you break it down, it simply means that a system (any system) that is flexible, e.g., has many options, is better able to cope with change.

Let's agree with the obvious - no matter where we start or what we propose for Health Care, conditions will change over time. A system that is tightly optimized for an initial set of conditions might be more efficient at the beginning while those conditions prevail - but IT WILL FAIL should (e.g., when) conditions change. And in today's world, conditions change: frequently daily or even on an hourly basis. When you add Human Behavior into the mix, you can be absolutely certain that change (usually unwanted or unanticipated) will occur.

In its original setting of control theory, Ashby's Law focuses on trying to keep a system stable. The more options the program has, the better able it is to deal with fluctuations in the system. Variety of input can only be dealt with by variety of action. This principle is well known to anyone who has played (studied) a non-trivial strategy game. An obvious example is Reversi (aka Othello) where the best strategy for the beginning of the game is counter-intuitive because it emphasises minimising the opponent's options.

For our Health care project, the application of Ashby's Law is obvious. Our (*NEW!*) system absolutely MUST be sufficiently adaptable to cope with a changing environment. A bureaucratic system [shudder] that is too rigid faces potential danger if its environment changes, especially when conditions change rapidly.

Consider the rise of digital photography. Companies that specialize in the production and processing of film are having to adapt and develop new products and services in order to survive.The music industry has had great trouble adapting its business models to the internet - it's old models were excellent for the age of physical goods such as CDs but cannot cope with the system perturbations introduced by the existence of downloaded digital music.

These Real World business examples show why in the long term innovation and creativity are essential for success in any complex enterprise (which Health Care certainly qualifies). Encouraging a creative environment means taking some risks, of course. A rigid environment that stifles innovation is effectively storing up greater risks for the future.

Short form: Our system needs OPTIONS. Lots of them. Which means functional checks-and-balances and periodic reviews are critical - things which stop working must be re-engineered or DISCARDED.

Therefore, IMHO, that means we must *carefully* address developing a system with both public and private segments, each designed and implemented in consideration of the other, with flexibility of individual choice (and its associated individual responsibility/accountability) as the ultimate goal in both arenas.

It doesn't mean we must address everything on the table at once. Nor does it guarantee what we develop will be 'perfect' or 'ideal' or 'do everything' - which is a typically matter of personal preference and desires, anyway. But *if* we start from a logical position, ignore ideology wherever possible, carefully prioritize what we can and cannot do, address the issues in priority order (even if it mean some highly desirable features must wait), while building in the flexibility to adapt to changing conditions while also expanding the program over time, then we *might* have some reasonable hope for success.

Whew! That will not easy, to be sure - but I still believe it's possible... Provided we don't let the past be a straight-jacket for our thought processes.


Just some food for thought...

- Steve