Remember the term “bilateral asynchronous cutover.” By the end of this post you will understand and like it. You may even want to mention it in comments on the current CMS and ONC NPRMs for meaningful use.
I have spoken often of the biggest threat to achieving steadily improving interoperability: the tendency to stick with what’s working. It is expensive to change an interface, even to make a minor change. Attempts to force upgrades by regulation or treaty often fail.
The problem is not when you establish the first network. That may be hard, but changing it is nearly impossible. How do you get all participants to cut over on the same day? It can’t be done. You don’t shut a network down and start over. I call this frozen interface syndrome.
Perhaps the most famous failure of a “second network” was the ISO Open System Interconnect (OSI) protocol suite, which was the planned TCP/IP killer of the early 1990s. The complete replacement for all levels of TCP/IP fixed many known problems such as the paucity of IP addresses. Dozens of consultants with solid TCP/IP credentials spent years developing it. The DoD decreed that it would no longer by systems based on TCP/IP, NATO agreed on it, GM build a whole plant-floor architecture based on it and — guess what? It never happened. Instead we adopted network address translation until IP6 could be rolled out and many other less elegant fixes that could be introduced incrementally.
What “Sort of ” Worked?
One of the few national conversions in healthcare that has stuck is the upgrade from X12 4010 to 5010 but there was collateral damage. More important, the 4010 went live in roughly 2001 with known problems and that version became “frozen” (without corrections) until 2011 when CMS forced the issue as foreplay to ICD-10. Even then, the upgrade probably couldn’t have happened if it weren’t for the predominant role of clearinghouses, preventing many end users from having to undergo software changes. We can’t possible upgrade clinical standards at such a slow pace. What Has Worked?
The Internet provides many examples of major improvements being implemented over time, rather than all at once. A few examples include
- Plain-text email to multimedia email
- Secure Socket Layer (SSL) to Transport Layer Security (TLS) versions 1.0, 1.1, and 1.2.
These upgrades all have one thing in common not all the senders and receivers had to change their software at the same time. Instead there was bilaterally asynchronous cutover.
Let’s look at the change from plain-text to multimedia e-mail, with multiple fonts, bold-face, built-in pictures, video and audio and all that razzmatazz. One strategy would have been to change all e-mail clients to receive multimedia before any client starts to use it. But the Internet is not so orderly. Instead the IETF adopted an approach that required multimedia senders to send everything twice in each message, once in plain text and once in a multimedia format such as HTML E-mail clients that could not display multi-media would display the plain text. This way any combination of new or old sender or receiver could communicate the basic content of the message. This is the send everything twice approach to asynchronous cutover. It worked because the features of the old format allowed an old-style receiver to know what to ignore. It also worked because the rules with the old format called for accepting unexpected data without calling it an error. The old-style receiver was expected to ignore what it didn’t understand. This was the compatible upgrade approach, where the original protocol anticipated future upgrades even before their form was known.
SSL and TLS each have two phases: a setup phase and an operational phase. During the setup phase they say what security versions they prefer and which other versions they support. Either side has the ability to say no if they won’t accept a low level of security but generally the two sides find the highest level they both support and use that for the operational phase.
Relevance to NPRMs
Where is the healthcare industry with respect for frozen interfaces? If we really don’t have much information flowing across enterprises now, we are just specifying the first interface. If, however, (a) we have a lot of standard data flowing by 1 January 2014, (b) the CMS meaningful use measures for interoperability only include data sent in standard format, and, (c) the 2014 Edition standards are different than the 2011 Edition then the effect of the 2014 Edition standards is to force many EPs and EHs to convert working interfaces with all the bilateral agreement that entails. (Remember that many EPs and EHs will be required to adopt 2014 Edition standards in order to meet the requirements for Stage 1 of meaningful use.
The 2014 Edition NPRM allows preadoption of 2014 standards in 2013, which could help. However without bilateral asynchronous cutover the industry is still left in the situation where nobody in a network can begin to send the new format until everyone in that network can send the old? How big is the network that has to roll out the change? With Direct and the NwHIN it is essentially the whole country.
Even where the 2014 Edition is only establishing the first interface we need to ensure that we have the foresight to enable bilateral asynchronous cutover for the 2016 Edition.
It takes a careful reading of the NPRMs to ferret out where we stand. I hope to provide that in my next post, and to have it available in time for you to consider commenting on the issue in your NPRM responses.
View Free, Relevant Gartner Research
Gartner's research helps you cut through the complexity and deliver the knowledge you need to make the right decisions quickly, and with confidence.Read Free Gartner Research
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.