May All Your Standards Be Simple and Evolvable

I was in a roundtable yesterday talking about Health IT with a bunch of very smart people in the bay area. It was sort of a briefing of ourselves and others about the real issues underpinning what it would take to generate real disruptive innovation in health technology and health costs. The vast majority of the conversation centered on payment reform, which is outside my ambit.

But we did spend some time talking about health data standards, and the problem of getting standards that are so geared to the existing market-dominant companies that they actually froze out new market entrants. My contribution in all this was pretty small, and to me seemed obvious. The standard that works best tends to be the least powerful solution to the problem, especially if it's an openly released solution. This can be counterintuitive - why wouldn't we want the most powerful one? - but it's been proven again and again.

In technology, standards propagate like kudzu. Most of them go nowhere, representing an enormous sunk cost of time and money. And that's because most of them are way too complex. The more powerful they are, the more brittle they are, the more expensive they are to implement, and the more they restrict the re-use of the system.

Tim Berners-Lee calls this the Rule of Least Power, and it's one of the most important lessons I learned working at the W3C. There's a simple reason for this - the more basic the markup of the content, the easier it is to write applications that process the content.

Thus TCP/IP, created simply to move bits between computers, begat a variety of new protocols like FTP, Gopher, Finger, many other protocols that layered atop the basic bits standard. Complexity from simplicity. Attempting to embed file transfer into the bits protocol would have made this whole process a lot harder.

And of course HTML/HTTP begat the entire Web, all the way to YouTube and Amazon and everything else. Writing video codes into HMTL wouldn't have worked nearly as well as writing a standard that was simple enough to be extended by smart users coming along ten years later.

To the rule of least power we can add the rule of openness - the standards process should be as open as is feasible, and the standards themselves must be open. Users have to be able to read a standard, and to have the freedom to implement the standard, to be able to innovate atop it with new systems.

There's a lesson here. Gathering the relevant powers that be to figure out a standard is an important task. The W3C, the IETF, the OMG (that's Object Management Group, not the internet acrony, for you younguns), and what feels like every different data discipline on earth does standards this way.

But there's a lot of fingers on the scale for most of this work. That's because data standards tend to get created by well-meaning, overworked, and underpaid people who are making a real sacrifice to work on the standards. And those people are going to depend on a lot of in-kind work from the interested parties, who are always going to try to bend the standards to their will.

That can go multiple ways. The paranoid conclusion is that the for-profits involved will try to use the standard to increase stock prices, which is why smart standards efforts include patent policies to prevent enclosure. But there's a bigger problem out there, which is much less visible but much more of a force in the creation of standards that don't get used, or that don't do what we want them to do.

It's what I call the problem of standards completeness. Experts in the field, interested parties, impassioned volunteers - these people by their nature tend to want to make the standard they build as complete as possible. They want to cover the most ground with the standard. They understand the space so well that they want to build standards that address vast swaths of work.

But that violates the Rule of Least Power. And as we move towards a web of data, even a web of patient data, we'll do well to make our standards by solving real problems with the simplest possible solutions, then releasing those solutions for others to build on.

The impact of the simple evolvable standard in short term is probably less than a more complete, perfect standard. Certainly TCP/IP didn't scare the systems integrators at its inception. But it's the power of the crowd that can build on the open standard that breaks open the market. Thanks to simple standards, two talented programmers can start a company in a garage that changes the world.

If we're going to bring that level of innovation potential to health IT, we need to keep the lessons of the simple standard in mind. Because right now, if you're a bright young entrepreneur, you don't get into health IT. And the lack of not just standards, but the right kinds of standards, is the first barrier we have to knock down to change that reality.