Moving to the Next Big Thing

Quite a bit is at stake for us in the US with respect to healthcare and healthcare IT.  The Federal government has invested billions of dollars to "make IT better" (pun intended).  One of the challenges though is to allow an appropriate amount of time for implementation to take effect, and to spur new growth through innovation.  Yet everyone seems determined to line up with the the next silver bullet, or is working furiously to invent it and make it the "new standard".

What we forget is that most standards are established by writing down the most common and/or best practices.  It's not really possible to determine "best practice" from a theoretical perspective.  That's why the word is "practice".  It means that it has to be used before it can be judged.  Theory can take you only so far.

Having then established standards, the next step is learn to use them and build from them.  The next "big thing" isn't a "new standard", but rather new uses to which we can put the newly established standard.  It takes time.  Crowd-sourcing new ideas isn't really feasible.  Adding more resources doesn't work.  You need the right pieces in the right place, at the right time.  I've seen it happen a couple of times and most often it's accidental.

A few years ago, one of the goals assigned to the team that I worked with was to create a certain quantity of inventions.  I didn't work on an R&D team, and in fact, I spent more than 50% of my time on the development of standards, for which the very idea of patents is nearly anathama.  I set myself a personal goal related to the team goal.  Trying to force creativity in that realm, no matter what I tried, though, really didn't work.  After an entire year, I completed filing on one new idea.  That one new idea though resulted from the confluence of right pieces, right place, right time, and right problem. 

I know of one organization that had learned how to manage invention, but they fragmented after building some of the coolest technology I ever saw in healthcare IT.  They worked on it this way:

1.  Define the problem.
2.  Determine what is needed to develop a solution.
3.  Break down the solution into known and unknown components.
4.  For each unknown component, learn what can be learned, and what isn't known yet.
5.  Plan out the necessary learning on the "what isn't known part".
6.  Execute on it.
7.  On successfully learning what is needed, plan on the implemention.

It takes a very process mature organization to be able to plan and execute on a learning activity, and to be willing to NOT plan beyond it until they have results of the learning.

We are still learning about how to use the standards we have, and to build innovations from them.  If I have to read one more report about "the best way" to solve the healthcare IT problem that includes theories on how to create the next big standard, with no industry examples to learn from, I must just scream.  Let's figure out what we can do with what we have today before we try to figure out what we must have tomorrow.  I think we'll find that what we have is much more capable than we've learned yet.

I've already seen some pretty cool ideas using just the CCD and CDA specifications.  Some of those are being used to solve real world problems in clinical decision support and quality measurement.