Nearly $26 billion spent, and the U.S. healthcare industry is still asking why information doesn’t move more easily between electronic health records.

That’s a loaded question, of course, and suggesting a ten-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.

[Healthcare IT News: The Cybersecurity cold war. CISO's share tips for savvier security.]

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

So, to substantiate the need for a technical plan, here are six barriers to interoperability that are the result of not having one. 

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

Along the way, the summary record morphed into just the “C-CDA,” and the standard became the target rather than the functional need. The C-CDA was what was discussed, specified, and required. But the C-CDA can be many things. It is almost infinitely extensible and the C-CDA support process does not have a history of providing strong constraints. As a direct result of the lack of a technical plan or architecture that targets the functional need, we now have numerous C-CDA variants, gigabyte-sized C-CDAs that providers rebel at receiving, at least five groups seeking to constrain C-CDA messages (will these be five new standards?), and we have few of the potential interoperability benefits. The C-CDA is not the target; it is a tool that if properly used could help get to it. A technical plan would clarify this relationship.

2. Bedazzled by bright and shiny objects: Technology and standards always look better when they are on the horizon. They seem pristine, powerful, and perfect. They seem capable of solving all problems. For those who were involved, the HL7 RIM was just such at one time and, later, the Clinical Document Architecture (CDA) was as well. And now there is “FHIR” (Fast Healthcare Interoperability Resources). We are not picking on HL7 here. They have done some of the best standards work health has. But ONC and its Federal Advisory Committees (FACAs) should not predicate interoperability accomplishment on the adoption of a new bright and shiny object on the horizon. FHIR is not even a balloted standard yet. REST, upon which FHIR is built, is an important direction, but there is a tremendous investment of mindshare and resources in what now exists as well. Rolling out anything new is always hard and slow. Doing so nationally is many times harder and slower. There are also always issues with new standards and technologies in implementation. With implementation comes complexity, challenges and concerns and invariably the new object does not look so bright and shiny any more.

Interoperability is not about bright and shiny object solutions, it is about the much less glamorous work of having a disciplined plan, focusing, disambiguating and then pushing toward it. It is about having well-documented, testable, specificity and holding folks to it. Bright and shiny objects are good to plan for a future state, but for immediate needs they add variability, generally have a lack of specificity because of the limited attention they have received to date, and don’t address many of the functional needs. Without a technical plan, people tend to bounce from one promising thing to the next and interoperability suffers.

3. Standards religion: A technical plan should put leadership above the fray. As an example, current approaches have chosen to not use almost any of the work that Integrating the Hospital Enterprise (IHE) has done. Surely there are pluses and minuses to the IHE work just as there are pluses and minuses to HL7. But should our takeaway from siding with one combatant in the “standards wars” be that none of the efforts of IHE have any value? What about the investments of the 78 organizational members of the eHealth Exchange, the 19 State Interoperability Workgroup, the numerous EHR and HIE vendors that already use them? The intellectual investments and the practical implementations that exist demand consideration and respect.

ONC and its FACAs should be above the fray making considered choices that are cognizant of where the industry is now as well as where it should go. Why is it an either/or situation to begin with? If there are competing approaches shouldn’t the ONC and its FACAs be brokering the differences? Shouldn’t they be developing bridging approaches? Shouldn’t they be forcing transition paths? Shouldn’t the huge amount of functional need specification that has been invested in one approach be leveraged for the other? A technical plan would help provide that. Interoperability cannot afford any more of an IHE vs. HL7 or any other kind of battle and government needs to be the “adult in the room.” Advancing a technical plan that considers the best of both would make sure this happens.

4. Siloed investments: It is hard to ignore the fact that some of the same folks who were recently promoting Direct and SMTP are now talking about using FHIR for everything including Direct’s “push” transaction. This switch, though, may not even be the biggest issue at hand. More problematic is that it is not clear that the huge national investment in Direct has any application to any other transaction. The NwHIN Power team has now expressed their requirements for query. Their requirements are a lot like the query requirements that were developed in the NHIN efforts in 2004. At that time, however, there was an effort to express an NHIN architecture which showed how “push,” “query” and “publish subscribe” transactions, as well as directory transactions, all could have a common security, transport and management platform. It is hard to see how the nation can invest in separate infrastructures for each individual transaction. Direct’s SMTP approach only does “push” and now the lack of a technical plan has led to an interoperability dead end. Even if Direct and SMTP were an appropriate decision at one point, shouldn’t the leadership who have moved on to FHIR articulate a path for the rest of the nation to reorient from the last place they took us?

5. The “portaled” patient: The lack of a technical plan is now forcing patients who want to access their health records to navigate multiple portals and be the integration and management function for their health records. Ill patients can have multiple portals with different views from each provider they see. Some patients actually need to access multiple portals for just one provider. Every patient deserves the right to access their health record, but because we don’t have a technical plan we don’t differentiate between the functional need of accessing a health record from the needs of managing and maintaining it in a patent-centric form. It is bad enough that there are multiple portals; we threaten to dump the responsibility of managing complex health information onto patients. Some patients may want to be these managers and be a sneaker-net health information exchange, but many don’t and cannot. It will be a health system failure driven by the lack of a technical plan if the management of patient data such as a current problem list, an allergy list, a medication list and a care plan can only be managed by the patient themselves and not by their care team.

6. EHRs über alles. A technical plan would invariably need to consider more than the EHRs that have been the almost sole focus of HITECH and Meaningful Use. It should be clearer and clearer that many of the outcomes that HITECH sold come from population oriented systems and not systems that are focused on supporting the direct provision of care. Population health management, research and public heath all operate in connection with, but outside of, EHRs. What are the standards for this connection? Without standards and a plan, how is population health management not becoming the next proprietary system category, driven by captive EHR markets and scoped to populations based on EHR sales? A technical architecture that can achieve the promise of health IT should help rationalize different population management and population analytic data stores external to EHRs. Interoperability for population systems is different from interoperability for continuity of care and a technical plan would show this.

A good technical plan for an architecture will not be easy to create. It must balance a high degree of specificity that can be easily tested in some areas with a non-limiting, openness to innovation in others. But the strategic standards and specificity of such a plan are not an impediment to innovation; they are a platform for it. The industry, including all of its participants who have been working toward interoperability, need to be brought together to push hard to a technical plan now because we will not have another $26 billion HIT investment anytime soon and interoperability will not wait.

John W. Loonsk MD FACMI is the CMIO of CGI Federal, and an Adjunct Associate Professor at the Center for Population Health IT in Johns Hopkins Bloomberg School of Public Health.

Related articles: 

Are patients really ready for the health data dance?

One surefire trick for getting C-suite's attention on IT security 

Avoiding interoperability pitfalls: Best practices for sustainable HIE