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.
0 Comments
Trackbacks/Pingbacks