Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Friday, April 19, 2013

Reboot or Re-boot?

I've heard the phrase "reboot" used several times recently.  A couple of days ago it was in reference to the HITECH act and Meaningful Use.  Today it was about the healthcare system [sic], and at other times, I've heard the phrased used with respect to interoperability and standards.

Rarely is a reboot possible.  Once a path is started down, there is simply too much momentum to shut it down and start over.  As much as I would LOVE to redesign our healthcare system from scratch, I realize that existing momentum is greater than my capability to stop and restart the system.  Also, unless you change something, reboot likely doesn't fix the problem.  I can count on one hand the number of times rebooting fixed my networking issues, and it never works for the cable-guys when I call them (because if it would have, I'd have already done it).

In mathematics, complex optimization problems are often challenged by getting stuck in local minima.  Various solutions to this problem usually involve successively larger and larger kicks.  This often works to dislodge the system from a local minima and enables discovery of a better solution.  Successive jolts are also useful when done in a repeated and rhythmic fashion (developing a harmonic).  Ever rocked a stuck car out of an icy or otherwise slippery hole?

So, it's not "Reboot" as in start over again.  By the time you've figured out that you are stuck with a non-optimal solution, the opportunity to start over probably doesn't exist.  Rather, "Re-boot", as in "Kick it Harder".  That just might work.  Or you could end up breaking it altogether (which according to my Stage manager wife, means that it just needed replacing anyway), or you could just wind up with a broken toe.  All of these are possible outcomes when you attempt to "re-boot".  It's never a guarantee of success.  The critical challenge with kick it again, or kick it harder, is figuring out where and how hard, and in what direction to apply that impulse.

So, if your advice is to "reboot", or even "re-boot", think again.  What is the right direction and force to apply to that kick that will dislodge the system and move it in the right direction.  It's pretty darn easy to say kick it again. The really hard part is to say "kick it right here".  And that is what differentiates an expert from a novice.



  1. I'll be passing this post around. I often find myself discussing this issue with certain people, who don't quite get how self-defeating it usually is to just "start over".

    By the way, I would have worded a key sentence in the third paragraph slightly differently:
    Successive jolts are also useful when done in a repeated and rhythmic fashion (exploiting a resonance in the system).

  2. Keith - Well put. However, the path that the healthcare institutions started was wrong. It was vendor centric and based on greed and no thinking. HHS just wasted money on their friends in the large institution vendors and the Beacon Communities are a joke. The term" the blind leading the blind" doesn't even come close to defining the greed and studity. The problem is complex...but the solution of interoperability is relatively a simple. First don't build more silos and say they are interoperable and second reach out to vendors (not the large 'can't do institutions') but the kids and emerging companies who will one day inherit the problem.

    best. Frank James Brown
    OR Tech Systems, LLC

    1. You won't get a whole lot of sympathy from me, mostly because your comments don't reflect the reality that I know.

      If you think HHS is "the friend" of "Big Vendors", you've clearly never worked inside a big vendor.

      Oh yes, we should all reach out to smaller vendors, because of course, they have no vested interest in profit, and they will fix the problem. How? By not building non-interoperable solutions. So, to be interoperable, you need to not be not interoperable. How is that anything but true, and anything else but obvious and not helpful?