Wes Rishel

A member of the Gartner Blog Network

Wes Rishel
VP Distinguished Analyst
12 years at Gartner
45 years IT industry

Wes Rishel is a vice president and distinguished analyst in Gartner's healthcare provider research practice. He covers electronic medical records, interoperability, health information exchanges and the underlying technologies of healthcare IT, including application integration and standards. Read Full Bio

Coverage Areas:

The Biggest Healthcare Interop Issue: Frozen Interface Syndrome

by Wes Rishel  |  April 13, 2012  |  7 Comments

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?

What 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.

7 Comments »

Category: Healthcare Providers Interoperability Vertical Industries     Tags: , , , ,

7 responses so far ↓

  • 1 Ed Hammond   April 13, 2012 at 10:09 am

    Altho it is a topic about which we have disagreed going into the past century, but your argument (excellent BTW) is why I propose regional centralization of EHRs. A given site deals only with one source, and all linkages and the n(n-1) is dealt with at that level.

  • 2 Wes Rishel   April 13, 2012 at 1:44 pm

    Thanks, Ed. I am not sure what you mean by regional centralization of EHRs. Does that mean every eligible provider and eligible hospital in a region would buy the same EHR?

  • 3 Chris W.   April 16, 2012 at 10:44 am

    I’m guessing that Ed means moving to a central EHR repository for a given region. In other words, replace multiple connected hubs in a region by a single hub with spokes radiating out to the provider sites. That single hub then is responsible for data exchange with other hubs, i.e., other regions. As a result, the combinatorics of data exchange across the overall network (national), not to mention within the various regions, become more manageable. At least, that’s the theory.

    Of course, given the topic of Wes’s post, this kind of begs the question. If you don’t have regional EHRs to start with, how do you evolve to them? Also, aren’t they just a waystation? Or is too much centralization of the data a bad idea?

    I’m reminded of Margalit Gur-Arie’s recent posts on the notion of a Universal Health Record. The first starts by expressing her deep misgivings about the feasibility and viability of health care data exchange interoperability in the terms currently being pursued:

    “I don’t know of any other industry where so many disparate software packages are able to communicate and cooperate with each other seamlessly, and yet this is the goal of the gargantuan effort of those who develop interoperability standards in health care. If you’ve ever been involved in software systems integration, you probably know all too well that the weakest and most unstable link is always at the interface between products, even those built by the same vendor, regardless of the agreed upon standard. When it comes to seamless operations and cost effectiveness, nothing beats true database level integration.”

    http://onhealthtech.blogspot.com/2012/01/arguments-for-universal-health-record.html (Part 1, 1/22/2012)
    http://onhealthtech.blogspot.com/2012/01/arguments-for-universal-health-record_28.html (Part 2, 1/28/2012)

  • 4 Wes Rishel   April 16, 2012 at 11:05 am

    Thanks, Chris, that’s what I though Ed was saying.

    If I understand it, this recommendation from you and Ed could go two ways.

    1) The US government chooses an EHR vendor for each region and all others go out of business. Choosing an EHR vendor per region didn’t work very well in England. It takes a really big government program to screw up that bad. One vendor was chosen based on its being a local firm, entirely on overhead-projector ware. The entire program did not include integration with the GPs, while we consider integration with primary care of (pardon the expression) primary importance.

    2) The government decrees that all EHR vendors must be regional and every vendor that has a different architecture has to redesign its products in order to compete. I have never been a fan of regulating architecture vs functionality, user satisfaction and performance.

    I am not aware of any industry where regulation stimulates innovation and we have the examples of the phone and airline industries where deregulation substantially changed the degree of innovation.

    Healthcare, of course, will never be completely deregulated. But in a market that doesn’t yet really understand what makes an EHR safe or highly usable I would fear programs to restrict competition. I would particularly fear a program that was basically designed to squelch competition on functionality, ease of use and safety in order to enhance interoperability.

    Interoperability is my thing, and I’m hoping to see some, but not that way.

  • 5 Chris W.   April 16, 2012 at 2:59 pm

    Acually, I wasn’t really recommending it, for the reasons you articulated and more. However, the arguments for it do suggest that we are impaled on the horns of a dilemma. :)

    Margalit Gur-Arie is highly skeptical of the ultimate viability of what she might call balkanization with data exchange interfaces. She doesn’t think the implementation of such interfaces can be made robust and worthy of trust by the parties to the exchanges. Another set of compelling arguments can be made for the proposition that balkanization with data exchange interfaces, albeit guided by an overarching RIM, is the only sensible way to go—and HL7 clearly bet on that horse.

    So, I see both sides, and expect an evolution in which the issues you discuss in your post will play a central role. This evolution may be too slow for some people, but I see it as a process of developing shared understandings and commitments among thousands of stakeholders, which can’t help being complicated, in light of all the technical, economic, political, and social concerns involved. Skeptics should go back to the early 1980s and consider what it was like when many (most?) of the standards we take for granted in modern computer systems and networking did not exist or existed only in nascent form. Many hard problems have been worked through in those 30 years. In fact, 30 years doesn’t seem like such a long time.

    By the way, see this interesting new post on the Health Affairs blog, which is not unrelated to all this:

    Bending The Health Care Cost Curve: More Than Meets The Eye?

  • 6 Chris W.   April 16, 2012 at 3:02 pm

    [A previous attempt at posting the following text apparently didn't take. This is a retry, with a small change.]

    Acually, I wasn’t really recommending it, for the reasons you articulated and more. However, the arguments for it do suggest that we are impaled on the horns of a dilemma. :)

    Margalit Gur-Arie is highly skeptical of the ultimate viability of what she might call balkanization with data exchange interfaces. She doesn’t think the implementation of such interfaces can be made robust and worthy of trust by the parties to the exchanges. Another set of compelling arguments can be made for the proposition that balkanization with data exchange interfaces, albeit guided by an overarching RIM, is the only sensible way to go—and HL7 clearly bet on that horse.

    So, I see both sides, and expect an evolution in which the issues you discuss in your post will play a central role. This evolution may be too slow for some people, but I see it as a process of developing shared understandings and commitments among thousands of stakeholders, which can’t help being complicated, in light of all the technical, economic, political, and social concerns involved. Skeptics should go back to the early 1980s and consider what it was like when many (most?) of the standards we take for granted in modern computer systems and networking did not exist or existed only in nascent form. Many hard problems have been worked through in those 30 years. In fact, 30 years doesn’t seem like such a long time.

    By the way, see this interesting new post on the Health Affairs blog, which is not unrelated to all this:

    Bending The Health Care Cost Curve: More Than Meets The Eye?
    http://healthaffairs.org/blog/2012/04/13/bending-the-health-care-cost-curve-more-than-meets-the-eye/

  • 7 Wes Rishel   April 16, 2012 at 3:47 pm

    Chris, interoperability is a small prerequisite to the bigger challenge of clinical integration across the various kinds of silos we build within and among healthcare delivery orgs (HDOs). Very large organizations have a potential competitive advantage in a world were efficiency and quality counts because they may have made progress on the cultural and procedural issues that go into clinical governance. Very large organizations that use a common EHR across the entire organization will generally find it easier to support many issues related to the total requirement for interoperability. These include common coding, coordinating CDS to templates and coding, dealing with patient problem resolution as a procedural rather than IT issue, coordinating the release of new clinical initiatives against all effected EHRs and, of course, data exchange.

    My point is that even if data exchange were perfect, which it won’t be, it is only the visible tip of a much bigger interoperability iceberg.

    OTOH, many larger organizations really can’t get out of their own way and are capable of having the whole iceberg even if they run on a single EHR.

    Furthermore, collaborative ACOs have so much low-hanging fruit to improving costs and care that they can attach the issues that require less clinical governance and less detailed exchange of clinical data and live for many years before competition is really much of a factor.

    You might ask, why do I bother? Well, we are unlikely to be out of mixed modes of payment for many years and even a little interoperability can go a long way. Sending structured lab data is technically a solved problem but most practices pay way to much because of the lack of use of the standards (in lieu of mapping solutions) and problems that are more procedural and regulatory. If we can provide the interop solution as a standard that actually gets used the cost and administrative issues would probably have less impact and more ACTUAL transmission of structured lab data would occur.

    If enough customers are enabled to extract structured data from CDA documents and feel the need to drive ICD-10 conversion, quality reporting or even (dare I hope?) clinical decision support then they will send more business to transcription houses that product structured CDA and radiologist and pathologists that produce reports with the codes inside.

    Getting some interoperability enables economic forces that can ultimately lead to more coding and interoperability.

    Hopefully we will see the full cycle before I retire from the health system. (As you may realize, the only way to retire from the health system is to die.)