In a post two weeks ago, we were critical of some aspects of the JASON Task Force’s (JTF) Final Report on healthcare interoperability. Two members of the JTF reached out to us in order to clarify the intent of the report as it relates to EHRs and the use of a “public” API to help make healthcare applications more interoperable. During a long conversation, we had a chance to discuss the issues in detail. Following that discussion we took some time to reconsider our opinions.

We now have to agree that the JTF itself was not EHR vendor dominated and have corrected the previous post. The Task Force was comprised of a wide range of stakeholders including several providers. Unfortunately, however, the testimony the JTF received was overwhelmingly from HIT vendors, consultants, or their proxies. We doubt this was intentional, but simply the vendor community having a more vested interest in influencing the JTF. But it does lead us to the conclusion that it is incumbent upon the JTF to proactively solicit provider testimony before policymakers act on the recommendations of the JTF report.

Despite our long conversation with these members of the JTF, we still have a difference of opinion on one key issue: The central importance of the EHR with regards to public APIs and interoperability.

The original JASON Report points squarely at EHRs as the source of interoperability ills. It also called for EHRs to adopt the public API. By our count, the JTF Final Report uses three different ways to describe where the public API should sit: a “Data Sharing Network”, “CEHRT”, or “clinical and financial systems.” In our follow-up discussion, JTF representatives maintained that the intent to include EHRs is clear and that the task force struggled on this issue of how broad their mandate was.

The JTF decided to cast a broader net than just the JASON Report’s initial focus on EHRs. But they did not clarify an already complicated issue, nor did they unequivocally single out EHRs as where the need for a public API should begin. We think that their intention to include EHRs is sincere but maintain the position that the JTF should explicitly recommend that EHRs expose services and data with the public API. Without such clarity, the fuzzy language used in the JTF report could end up being adopted in future rule-making or legislation, creating the potential for uncertain outcomes.

Our Thesis:
Good, bad, or otherwise, the EHR is the dominant application supporting clinical workflows and the source of most patient healthcare data.

Every provider we have ever talked to says that improved patient care and more effective care coordination would be possible with better access to other providers’ EHRs. On the other hand, we have not talked to many providers who say that better patient care and better care coordination would be possible if only there was better access to other providers’ financial systems. The majority of providers have never heard of a Data Sharing Network (and no, we do not believe Direct can fill this bill) so the public API is pretty much dead in the water there as well – though most any HIE/CNM vendor worth their salt would welcome a public API.

So let’s be perfectly clear in the JTF report – if we want EHRs to adopt a public API, then let’s just say so rather than beating around the bush. To do otherwise sends the wrong message to the market – that EHRs are somehow not central to the interoperability problem.

The JASON Report created quite a fuss in the HIT marketplace as some screamed foul and others were encouraged that maybe, just maybe the JASON report may force movement to more open systems. To clear the air, the JASON Task Force (JTF) was formed to solicit industry feedback for policy makers. The JTF released their findings earlier this month.

The JASON Report was an AHRQ- and HHS-sponsored study of healthcare interoperability issues. Its basic conclusion was that the existing EHR-based HIT infrastructure should be superseded by something more open and amenable to use by other applications and across organizations. The JASON Report advocated radical solutions to the interoperability crisis: using MU3 to replace existing EHRs and requiring a uniform set of APIs for EHRs across the industry.

Vendor response was rapid and unified. HITPC appointed a task force representing stakeholders from across the industry (virtually all have been on other ONC workgroups, so somewhat cloistered) who worked with alacrity through the summer. The tone of vendor testimony before JTF reflected a level of alarm that contrasts sharply with HCO’s non-participation.

JTF and its vendor members have some legitimate beefs: the JASON Report is not exactly disinterested. It substantially reflects the view of the clinical research community which sees itself as the long-suffering victim of EHR intransigence. The JASON Report glosses over genuine, if crepuscular, progress in healthcare interoperability. Another point that we believe has not been made forcefully enough by EHR vendors is that they are constrained by their HCO customer’s ability to change. The organizational obstacles to healthcare data liquidity are significant and EHR vendors move only as fast as HCOs despite their claims to the reverse. However, we think that JTF is wrong to deflect attention away from the EHR-oriented APIs.

JTF’s proposed alternative to EHR supersession involves something it calls Data Sharing Networks (DSN). These are a rebranding of the HIE supplemented with a uniform set of APIs to support access to something never specified in much detail. JTF suggests that these APIs be based on the replacement to HL7 – FHIR.

Without doubt, FHIR represents a significant improvement over HL7 along multiple dimensions. But the idea that FHIR alone can cure the interoperability ills of healthcare is all smoke. Behind this smokescreen, EHR vendors are hoping that people eventually lose interest or stop talking about interoperability. With this bit of redirection, JTF has basically let the EHR vendors off the hook.

This begs the question: Where is the best place to have a uniform set of APIs reside, the DSN (HIE) or the EHR?

Our answer: Both!

The HIE is really a stopgap measure in the sense that discrete access to EHRs and other data sources across organizations via a uniform set of APIs and SOA will greatly reduce the need for an HIE. If applications could access all of a patient’s data directly from native data sources in different HCOs, there isn’t much point in maintaining separate and comprehensive CDRs at different sites in the overall healthcare system.

But rather than move in this direction, the JTF favors the politically powerful EHR vendors at the expense of the HIE vendor community.

No doubt creating a set of uniform APIs to EHRs would be costly. Upward and backward compatibility, a hallmark of every successful IT platform, requires deeper pockets than most EHR vendors can muster. But some EHR vendors are better positioned to support such APIs than others. Many hospital EHR vendors could make the investment. Smaller, community-focused, or client-server based EHR vendors and their customers though would struggle.

Our HIE research has shown – year after year – that data flows downhill from hospital to community. Hospital-based EHR data is valuable to community-based clinicians. It is also extremely valuable to those hospitals to ensure that physicians in a community get discharge summaries to minimize readmissions and associated penalties. Hospital-based EHRs are a good place to start with uniform APIs. The reality is that community-based EHR data could also be better used in hospital settings to facilitate care. This is especially true as we move away from fee for service to more risk-based payments models.

Unfortunately, facilitating data flows between community and hospitals is something we’ll be patching together with string, baling wire and duct tape for the duration. The JASON Report and subsequent JTF report have not moved the ball forward on this issue. It is our opinion that there is little that the policy folks in Washington D.C. can do with additional prescriptive meaningful use requirements. HHS would better serve the market by using financial incentives that promote healthcare organizations to demand better interoperability capabilities from their vendors as it is the customer that vendors really listen to, not D.C., policy wonks.

1.1 Introduction
The promise of improving health care through the ready access and integration of health data has drawn significant national attention and federal investment. David Blumenthal (former National Coordinator for Health Information Technology) and Marilyn Tavenner (current Administrator for the Centers for Medicare & Medicaid Services, CMS) have characterized the situation well:

“The widespread use of electronic health records in the United States is inevitable. EHRs will improve caregivers’ decisions and patients’ outcomes. Once patients experience the benefits of this technology, they will demand nothing less from their providers. Hundreds of thousands of physicians have already seen these benefits in their clinical practice.
But inevitability does not mean easy transition. We have years of professional agreement and bipartisan consensus regarding the potential value of EHRs. Yet we have not moved significantly to extend the availability of EHRs from a few large institutions to the smaller clinics and practices where most Americans receive their health care.” [1]

The two overarching goals of moving to the electronic exchange of health information are improved health care and lower health care costs. Whether either, or both, of these goals can be achieved remains to be seen, and the challenges are immense. Health care is one of the largest segments of the US economy, approaching 20% of GDP. Despite the obvious technological aspects of modern medicine, it is one of the last major segments of the economy to become widely accepting of digital information technology, for a variety of practical and cultural reasons. That said, the adoption of electronic records in medicine has been embraced, particularly by health care administrators in the private sector and by the leaders of agencies of the federal and state governments with responsibility for health care. Although the transition to electronic records now seems a foregone conclusion, it is beset by many challenges, and the form and speed of that transition is uncertain. Furthermore, there are questions about whether that transition will actually improve the quality of life, in either a medical or economic sense.