Posted on October 20, 2014 by Brian — 1 Comment ↓
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.