Six reasons we will not have health IT interoperability without an architecture

Where's the plan for interoperability?

By John W. Loonsk, MD
07:19 AM
Frustrated doctor at laptop

It is a simple question: “Why doesn’t electronic health information flow after the nation spent $26 billion on electronic health records?" Suggesting a 10-year timeframe or arguing that there is progress if you look hard enough just doesn’t answer it.

Congress does not think so either. Despite the HITECH funds’ accomplishing a significant degree of EHR adoption there is still a large amount to do to achieve modest interoperability. And the question posed above is going to politically fester until something significant is done.

Part of the interoperability problem is that only a limited amount of the HITECH meaningful use leverage has been used to encourage data exchange. Interoperability took a back seat to adoption of EHRs and other things in meaningful use plans.

But another part of the problem is that there is no real technical plan. From a health IT perspective, the kind of “plan” that is needed would describe high-level functional needs, identify important technical elements, and show how they all fit together. It would be an architectural blueprint to guide technology in the very complex, loosely coupled system that is the health sector. And it would strategically articulate critical, but limited, pieces of the national health IT infrastructure. It would also show how what exists needs to be supplemented and changed to achieve the future state. It would be, in short, more of a high-level technical architecture than a roadmap.

A roadmap can help too but the nation needs to know where it wants to go in order to use a map for how to get there. Some, who not infrequently would rather go their own way, attack the word “architecture” as meaning “top down control.” So call it a “technical plan” or a “framework,” call it a “design pattern,” a “schematic” or whatever you want; interoperability will suffer until we have a picture that helps articulate and guide where we are going.

[See also: Time for hard HITECH reboot.]

Without such a plan, the multiplicity of approaches makes for bad interoperability math. Each participant has too many variations with which they need to integrate. Software vendors can’t pick one approach and sell to the whole market – they need to pick them all or narrow their opportunities. Without a plan, we cannot communicate well about specific needs and how they fit together. Critical elements will be missing. Without a plan, funds and mindshare are invested in dead-ends that will take years, or decades, from which to escape. Without a plan, we will be highly susceptible to the whims of changing personalities, politics, and administrations. Without a technical plan, many of the health outcomes that assume information liquidity and on which HITECH was “sold” will be elusive.
External reports from notable experts including the President’s Council of Advisors on Science and Technology, or PCAST, and the JASON group have said that a technical plan is necessary. PCAST was ignored. The more recent JASON report is now being picked apart for flaws in its sample architecture. But the plea both reports share is to develop an architectural plan not necessarily their specific one.

[See also: Commentary: What about interoperability?]

So, to substantiate the need for a technical plan, here are six barriers to interoperability that are the result of not having one. It is our hope that discussing these issues will help us constructively move forward to having a technical plan that resolves these issues now and prevents similar issues in the future.

1. Chasing the Technology and Not the Need – A technical plan starts with functional needs, not the standards or the technologies that are used to address them. The difference here is evident in the current problems with the Consolidated Clinical Document Architecture, or C-CDA. The history of this actually did start with a good functional/business need – a discrete “summary record.” A highly specified summary record could be an important starting point for interoperability; begin with something small, make it tight and well constrained, and push hard on its exchange with incentive funds. This would be a more viable approach than trying to advance the exchange of the whole medical record.