Interoperability or the perceived lack thereof is one of the hottest topics in healthcare and the health information technology (healthIT) industry. Improved interoperability is at the top of the agenda for the Office of the National Coordinator for HealthIT (ONC), which just issued a road map for the next decade. Meanwhile, fingers are pointing everywhere in very public ways at the perceived lack of interoperability. Everyone, it seems, is to blame.
In our view, while there is definitely room for improvement, coordination and innovation across the healthIT landscape, much has been accomplished already. In our view, the interoperability glass is more than half full. Heres why.
Jason Report. The guidebook for interoperability bashing is the JASON Report, which was issued a year ago with funding from the Agency for Healthcare Research and Quality (AHRQ). Highly critical of the status and trajectory of interoperability, it concluded that meaningful use (MU) stages 1 and 2 have not achieved meaningful interoperability in any practical sense for clinical care, research or patient access due to the lack of a comprehensive, nationwide architecture for health information exchange (HIE). The report pointed to the lack of an architecture supporting standardized application programming interfaces (APIs), as well as electronic health records (EHR) vendor technology and business practices, as structural impediments to achieving interoperability. JASON recommended that health care interoperability be reoriented away from “siloed legacy systems” toward a centrally orchestrated interoperability architecture based on open APIs and advanced intermediary applications and services.
ONC sponsored a task force to conduct an analysis of the JASON Report, which rebuts many of its assertions. According to this analysis, JASON does not accurately characterize the very real progress that has been made in interoperability, especially in the last 2 years. Second, JASON’s description of current generation clinical and financial systems does not accurately portray the broad range of functionality of these systems, or the innovation occurring on those platforms. Third, the report addresses software engineering and architecture aspects of interoperability but explicitly does not examine policy, legal, governance, and business barriers to health information exchange. Yet, the report recommends aggressive timelines for change that would be difficult to achieve when taking into account policy, legal, governance, and business barriers. Fourth, the software architecture recommended by JASON assumes a high degree of centralized orchestration; however, the report does not describe the source, structure, and process for achieving such orchestration We couldnt have said it better ourselves.
We would also add that while useful, APIs are not the end all and be all. They are one way to allow third-party programmers (and, hence, users) to bridge from existing systems to other software. However, APIs can impede interoperability particularly how they are supported. Companies can discontinue or limit the services and APIs that are necessary to make certain applications work. Terms and conditions of use can change dramatically at any time. Prices can escalate. Worse yet, companies offering APIs can simply go out of business, leaving users high and dry. Also, as previously noted, the healthIT landscape is rapidly changing. Consequently, an API that is necessary in todays world may not be needed tomorrow.
Vendors. Vendors are feeling the brunt of the blame game for this perceived lack of interoperability. Some of this is fueled by the overwhelming number of vendors. There are more than 600 EHR vendors alone, by last count. Do they all do the same things in the same way? No. Should they? According to many users and government agencies, they should do everything the same way so they can talk to each other. In reality, not all systems will do all things the same way because the functionality, cost and innovativeness of individual products speak directly to branding, competitive advantage and market share. Nonetheless, the sheer number of vendors and their functional differences (good, bad or indifferent) make it easy for government agencies and users to perceive a lack of vendor interoperability.
Some of the blame game is being fueled by the very public infighting among vendors themselves specifically those belonging to the Commonwell Alliance and those who are not members (one major player, in particular). Will pushing all vendors into one camp or another crack the interoperability code or lessen the perceived lack of interoperability? We dont think so. However, there is considerable interoperability gravitas in both camps, which have done much work and have real foundational elements on which to build.
All that being said, we believe vendors are getting a bad rap. The bottom line is that there is a core level of interoperability for EHRs which have met certification standards for MU. And yes, the certification processes and requirements must be met by everyone as they have been mandated by the government and grudgingly adopted by the industry. While the one-size-fits-all MU requirements and processes have tended to stifle innovation, they have left a core of basic interoperability across all EHR vendors. The glass is definitely more than half full.
Providers. Some blamers point to providers, who often appear conflicted about what they want. Providers are concerned about receiving volumes of clinical information from other caregivers and then being tasked with the responsibility for reconciling them to try to find pertinent information. Overarching this concern is potential liability. What happens if an important piece of information was inadvertently overlooked and then harm comes to a patient? Identifying the pertinent information that providers want is a significant challenge because needs vary widely by circumstance and preference. The problem is not so much lack of interoperability as it is legitimate differences in the practice of medicine from provider to provider, as well as their business needs and priorities.
The business case: the missing piece of the puzzle. We at Point-of-Care Partners believe the missing piece of the interoperability puzzle is the lack of a business case.
No one can argue the public health benefits of an interoperable EHR. Study after study have shown that providers can take better care of patients by having access to the full breadth of a patients care records. Other studies have pointed to the cost effectiveness of an interoperable health record that reduces the possibility of duplicate testing and administrative overhead.
From a competitive perspective, sharing patient records may not make sense. In markets having multiple integrated delivery networks (IDNs), participants are vying for the same patients. A significant advantage promoted by IDNs is their ability to offer all of the services a patient needs primary, specialty, and emergency care; surgery; etc. One way to ensure that patients stay in network is by enabling complete and seamless access to patient records within the network, and to make records available in a less convenient (on paper) and slower manner (i.e., faxed) outside the network. Why? Because theres no business case for a network to make it easier for a patient to choose a competitor.
No IDN would ever publicly admit to such a notion, but the lack of success among HIEs points to this conclusion. IDNs give lip service to a desire to share data but are slow to act, and the HIEs created as hubs to share the data close in bankruptcy while waiting.
Competition also contributes to the bad rap EHR vendors are receiving. While one could argue that it is the design of EHRs to create silos of data, could it not also be that for competitive reasons, IDNs silo their data?
In short, we have done a poor job creating a viable business case for interoperable healthIT. The answer isnt to create new standards and mandate via regulation that records be shared. Creating incentives and removing competitive barriers to data sharing will enable the market to self-adjust based upon supply and demand. Existing healthIT technologies already talk to each other. Addressing competitive barriers will enable us to confidently build on the base that has already been created.