Why healthcare APIs will save lives, money and time
APIs have a toe-hold in the healthcare space today but that has to change, and quickly. Stan Huff, M.D., explains why open source has to be healthcare's future.
Stan Huff, M.D., chief medical informatics officer at Intermountain Healthcare, made a strong case for medical platform interoperability, healthcare APIs and an open source approach to health IT at an Object Management Group conference in Boston on Monday.
IT departments in most industries have long been enthusiastic users of APIs – standard software building blocks that make development and interoperability easier. They've also participated in the open source movement, where code is shared, reused and improved upon for the common good.
In the health IT space, however, these concepts have been slower to gain traction, and Apple just recently became the first company to open up its Health Record API to developers. Apple's API is based on the Fast Healthcare Interoperability Resources (FHIR) standard, which was created in 2014 and is arguably the most talked about of the healthcare APIs today.
But being talked about is a long way from being implemented, and that, Huff was quick to stress, is the major problem. "FHIR is really easy to implement," he told a room full of physicians. "It's had unprecedented support from EHR companies. But it's young still. We have a vision, but we just need to get there."
What healthcare APIs can jump-start
The vision is a world where any electronic health record system could communicate with any other system; data could be gathered and mined; and, ultimately, decision engines could be built that could improve patient care, cut costs, reduce medical errors and even help with doctor burnout, Huff said.
To make his point, he shared some stark data. Citing a Johns Hopkins study, Huff said approximately 250,000 people die a year due to medical error, making errors the third-leading cause of death in the U.S. That is five times the amount of people who die in auto accidents, he said.
And then there is the issue of cost, because each EHR system at each hospital needs unique applications created for it. "That's like saying we need 50 different versions of Yelp for each hospital," he said. "Our architecture is wrong. It's set up so that we can't share what we've created. We're paying an incredible price for software. Each useful app is created or re-created on each platform, and we pay for it."
To be more specific, Huff said Intermountain, based in Murray, Utah, has developed 150 clinical decision support engines that offer best practices and advice on everything from diabetes to heart health.
"But that 150 really represents the low-hanging fruit," he said. "We need 5,000 rules or modules, and there's no scalable path to get there. And there's no scalable path to pass that information on to community hospitals."
If we do this right, we could save 100,000 lives a year.
Stan HuffM.D., chief medical informatics officer, Intermountain Healthcare
One large hospital was able to develop 13 of these decision engines in six months, but they're specific to the EHR in use and would be "cost-prohibitive" to share with other hospitals.
Asking, and then answering, those questions will kick-start the interoperability journey, help decide on the correct healthcare APIs and eventually will lead to sweeping changes in medicine.
"If we do this right, we could save 100,000 lives a year," he said. "We could go from being right 50% of the time to 80% of the time. And we could get new EHR systems for millions, rather than billions."
Dig Deeper on Healthcare IT management and organization
