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, or 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, or 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 come 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, or 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 EHR/HIE 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 its requirements for query. The 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 a NHIN architecture that 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 that has 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 patients 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/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 create a technical plan now because we will not have another $26 billion HIT investment anytime soon and interoperability will not wait.