Cathedral & Bazaar Revisited: Healthcare Information

One of the problems we face when we talk about electronic medical records, personal health records, etc. arises because we think and talk about them as systems. A recent post on LinkedIn says:

What was apparent from the first 23 comments is that opinions and perspectives are all over the place. It’s not clear folks are all of one mind with respect to WHO constitutes the users, WHAT constitutes an EHR, what constitutes usability, and/or HOW one should be assessing usability. Many look at usability only from, ultimately, the safety perspective (decreasing medical errors), but how about efficiency, including impact on overall workflow? User acceptance/satisfaction? What are the appropriate usability measures by which to evaluate EHRs?

These are systems related questions. Systems lend themselves to being defined, developed, deployed and used. That is not the case with healthcare information. The information requirements of healthcare providers, patients, and the supporting infrastructure are evolving rapidly as we learn what works and what doesn’t. Supporting technologies – iPhone and iPad to name just two – are evolving and enabling new cost effective services to be provided. The economics of health care are changing because the current medical business model doesn’t fit any economic model that makes sense and the economics of health care are what will provide much of the funding for information solutions. The problems and opportunities of health care information don’t lend themselves to the discipline required for traditional systems.

In 1997 Eric S. Raymond published an essay called The Cathedral and the Bazaar that described the traditional system development process as centrally managed and built to last like a cathedral as contrast to a bazaar that is constantly being modified by its users to meet their evolving needs—in his essay: Linux. The article was sold and is now copyrighted and available only for a fee.[1]

Eric now points to In Praise of Evolvable Systems by Clay Shirky which points in the same direction. I think Shirky’s definition of Evolvable Systems provides and apt description of what is required to realize the benefits promised by improvements in health information:


Evolvable systems — those that proceed not under the sole direction of one centralized design authority but by being adapted and extended in a thousand small ways in a thousand places at once — have three main characteristics that are germane to their eventual victories over strong, centrally designed protocols.

  Only solutions that produce partial results when partially implemented can succeed. The network is littered with ideas that would have worked had everybody adopted them. Evolvable systems begin partially working right away and then grow, rather than needing to be perfected and frozen. …

  What is, is wrong. Because evolvable systems have always been adapted to earlier conditions and are always being further adapted to present conditions, they are always behind the times. No evolving protocol is ever perfectly in sync with the challenges it faces.

  Finally, Orgel’s Rule, named for the evolutionary biologist Leslie Orgel — Evolution is cleverer than you are. …  it is easy to point out what is wrong with any evolvable system at any point in its life. … However, the ability to understand what is missing at any given moment does not mean that one person or a small central group can design a better system in the long haul.

Evolution is messy, brilliant ideas don’t work, money is wasted, efforts are duplicated, but the Internet has shown that the process is capable linking growing requirements with expanding capabilities to produce solutions to problems we don’t even know we have. The Internet is a better model than traditional, cathedral like systems for what we are dealing with when we talk about converting and sharing medical information in an electronic format.

It’s dinosaurs vs. mammals, and the mammals win every time. … Infrastructure built on evolvable protocols will always be partially incomplete, partially wrong and ultimately better designed than its competition.

There will be some large systems to deal with complex environments. Small systems to deal with special needs. “Apps” to deal with general needs, and forms we haven’t imagined to deal with opportunities undreamed of. We need to recognize that lack of clarity and structure is just part of the process. We need to learn to live with it and occasionally laugh at it, curse it, and celebrate it

[1] Eric S. Raymond (1999). The Cathedral & the Bazaar. O’Reilly. ISBN 1-56592-724-9.

Short link:


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s