There has
been much controversy in the Health IT world over the issue of “data blocking”
– to what extent it truly exists and, if so, what to do about it.
It’s worth noting first that the magnitude of this problem may be
exaggerated. As recently
reported by ONC, an analysis of a nationwide survey of hospitals showed some
heartening results:
(N)ear universal adoption of EHRs by hospitals and significant increases in hospitals’ electronically exchanging health information with outside providers compared to past years.In addition, there are a number of technologies available – including DIRECT protocol – that are widely available, easy to implement, but simply underused.
However, even if
the extent to which systems are actively obstructing the flow is overblown,
there is much work to be done. In testimony before the Senate’s HELP Committee
on the subject of health IT “data blocking,” Dr.
David C Kendrick – who leads MyHealth Access Network (a non‐profit health
information exchange organization in Oklahoma) – provided some helpful
guideposts.
Dr. Kendrick first gave a succinct and workable definition of
interoperability, in which patients “have their complete, longitudinal
medical record available wherever and whenever decisions are made about their
health.”
 |
| Dr. David C. Kendrick offers testimony before Senate HELP Committee on Thursday, July 23, 2015. |
Kendrick went on to list drivers of data obstruction culled from his
experience. Some specific examples include:
- Excessive interface and maintenance costs
- “Hotel California” problem: vendors do not offer data portability as intended by ONC, so customers “can check out other EHR products any time they like, but their data can never leave”
- "Garbage in Garbage Out”: Poor data quality and standardization
- EHR-centered development that extends interoperability only to EHR+its partners
- Vendors achieving certification with one feature set, but features are not fully delivered post-certification
Where data blocking persists, incentives are lacking for collaboration. In Kendrick’s experience,
provider-based blocking was a challenge early in the existence of MyHealth, but
the problem has “quickly receded as value‐based payment models take hold.” “Data blocking,” on the whole, may simply be a more
loaded term for the obstacles that exist in pursuit of the Holy Grail of
interoperability.
It’s not easy
developing a universal secondary language for health care. But it is up to
health IT developers not to settle for “just good enough to pass." As an industry, we now know the ideal to which we are
striving and the major barriers.
And while software developers are not policymakers, we can offer our own
set of incentives for interoperability through ease of use, affordability and
functionality that goes beyond mere compliance. A good place to start is
putting data-sharing front-and-center in our applications.
One thing I'd like to add RE data/information blocking based on decades of HCIT systems integration experience is that there is both a "macro" problem with all EHR vendors (which as the blog post suggests "may be exaggerated") in the sense that few if any support or encourage their clients to (as one major EHR vendor once put it) "take a can opener to their database", and a "micro" problem with some individual EHR vendors, who I have seen behave in ways that I almost can't believe that their healthcare provider clients would put up with, like preventing clients from making ad hoc queries of their own data and then charging outrageous fees to extract data for them.
ReplyDeleteSo while it's arguably impractical to treat individual instances of the problem, and even recognizing that not all EHR vendors are evil, I think that treating the general problem by putting significant data blocking penalties in place could help to reduce the tendency of even a handful of EHR vendors to behave badly, even if only by giving hospital IT staff some leverage when trying to implement an interface or do some integration work.