In a variety of recent private and panel discussions with health and policy leaders, I’ve heard encouraging talk around interoperability through open and available application programming interfaces (APIs). Public comments by Health and Human Services Secretary Sylvia Mathews Burwell and Centers for Medicare and Medicaid Acting Administrator Andy Slavitt indicate there is sincere commitment to making this a reality.
While this momentum seems promising, when Meaningful Use Stage 3 is mentioned – particularly its requirements for making data available to patient facing applications – I see the potential for unintended and terrible consequences for clinician workflows.
Though it has notable limitations, a patient- or consumer-centric approach to data portability and interoperability is currently the best framework. Individuals should own their data and have easy, real-time, plain-English ways of opting in and out of recording and sharing their data in both identified and de-identified ways with anyone they wish, for their own benefit or the benefit of society at large.
Yet Meaningful Use Stage 3 and open APIs for consumer-facing applications will not be enough to solve the interoperability challenges we face. For example, imagine the situation of a patient showing up to the emergency department. The physician describes needed tests that the patient knows were recently done by another provider. Even if that patient has an application on their phone that can access data from various sources, it’s still unlikely this could translate to a scalable, reliable, effective workflow for that physician. The more likely result is that the same issues that plague ineffective health information exchanges (HIEs) will arise: the data are incorrect, the solution is difficult to navigate, the focus is not tailored to the specialty of the user, or there is suboptimal data provenance, to name just a few.
By relying too heavily on a patient-centric approach, we risk diminishing the momentum toward enforcement of affordable, open, bi-directional APIs among all health information systems. This is a must-have to create innovative and intuitive workflow solutions for clinicians and consumers. In the scenario above, what is needed most is for the emergency department physician to have access to an integrated workflow that incorporates their own hospital’s data along with relevant patient data from multiple other and disparate sources. This will enable cost-effective and clinically accurate decisions to be made more efficiently.
Establishing the consumer as the broker in these situations may introduce unnecessary complexity. The ideal consumer-facing application would simply have two buttons: ‘record’ and ‘share,’ providing the consumer with control over their data and interoperability in a simple, real-time way. What should follow that consumer action is wide-open, bidirectional interoperability among the patient’s historical data sources that can support nimble, innovative workflow solutions geared toward clinician use and decision making. Ultimately, business models that simply monetize the hoarding and simple transmission of data from closed, Byzantine health information systems without creating meaningful insights and workflows will crumble – as they should.