What is an application programming interface? One of the more evocative definitions in recent memory comes, of all places, from the U.S. Department of Veterans Affairs:
"Think of an API as a server in a restaurant," according to the VA. "Imagine you are sitting at a table with a menu of choices to order from, and the kitchen is the part of the system that will prepare the order. What’s missing is the critical link to communicate your order to the kitchen and deliver your food back to your table. That’s where the server, or API, comes in."
Like an overworked waitress during dinner time rush, APIs have been doing a lot of heavy lifting recently as this industry tries to solve its longstanding interoperability challenges – with a lot of hungry parties expecting tip-top service.
The past few years have seen the industry looking more and more to open APIs and HL7's FHIR specification to play instrumental roles in connecting disparate parties and devices across the care continuum.
The VA, in fact, is arguably the latest and highest-profile player to embrace that ethos. Even as it works with Cerner to iron out the details of how its new electronic health record will knit together with the one that's also being built, piece by piece, by the Department of Defense, VA is betting big on contributions from smaller private sector developers nationwide, enabled by open APIs.
[Also: Execs tout APIs, asks healthcare to 'share shamelessly']
At HIMSS18, VA Secretary David Shulkin, MD, touted its new API gateway, the Lighthouse platform: "We're going to be able to map the electronic medical record to the FHIR APIs," he said. "We're asking industry to help us build this API gateway, asking industry to open API access to all developers and are working with industry to stop the practice of information blocking."
Shulkin also called for more health systems to sign the VA's Open API Pledge. Eleven participants so far – heavy-hitters including Cleveland Clinic, Geisinger, Intermountain, Mayo Clinic, Partners HealthCare, UPMC and others – have promised to collaborate with VA to map that data to "industry standards including the current and forthcoming versions of the Argonaut Project specifications of FHIR API over the next 18 months."
And, of course, open APIs are already integral to the data exchange provisions of existing regulations such as 21st Century Cures and Stage 3 meaningful use. At HIMSS18, Centers for Medicare and Medicaid Services Administrator Seema Verma unveiled another federal program, MyHealthEData, which she said will also push the specs as an instrumental way to get data to patients.
"CMS believes the future of healthcare depends on the development of open APIs," said Verma.
National Coordinator for Health IT Donald Rucker, MD, echoed the sentiment– making the case that more healthcare data sharing efforts need to look more like the comparatively effortless communication of the app-filled devices consumers use every day.
"If you look at data liquidity, you look at the rest of the world, and in that app economy, many use services that are absolute mashups, roll-ups of a variety of different app technologies," said Rucker. "We're living in an environment where the computer in your pocket or purse is creating lots of different business models. We absolutely anticipate that to happen in healthcare, and some of it already is.”
Indeed, there's big momentum among vendors and developers of all shapes and sizes as companies adjust the calculus of what patients expect from connectivity and user experience – and what health IT vendors feel compelled to give them.
[Also: Apple to launch Health Records app with HL7's FHIR specifications at 12 hospitals]
Just look at Apple, which of course is working together with healthcare companies including Cerner to make personal health information accessible on its Health Records app. HL7's FHIR specifications are key to those efforts.
In turn, Cerner President Zane Burke told us that his company is "working with a range of partners and clients to turn up the heat on the conversation about interoperability."
Despite some well-placed skepticism about just how transformative Apple's efforts might end up being, it's easy to see how that can quickly snowball into real and widespread change – why Google, which launched its own Cloud Healthcare API at HIMSS18, said APIs are key to fixing interoperability and that developers should freely borrow and share ideas to help build on the momentum they're enabling.
Technology is easy, clinical vocabulary is hard
But there are some challenges along the way to a rhythmically thrumming ecosystem of freely flowing healthcare data, bouncing from point to point via open API.
A big one is the fact that legions of app developers – however well-intentioned they are, however enthusiastic, however code-savvy – aren't always as well-versed as they could be in the complicated details of medical data and clinical workflows.
That's led to a profusion of new technologies that often have limited utility for data exchange.
With a lot of emerging apps, "either you're looking at things that don't have medical data, or you're looking at things that just have medical data," as ONC chief Don Rucker explained. "You're not looking at things that synthesize knowledge about our environment and our lives and our behaviors with medical data. That is really the opportunity here."
Few people know more about FHIR and open APIs – and specifically their clinical applications – than Russell Leftwich, MD. His Twitter handle, after all, is @DocOnFHIR.
Leftwich is senior clinical advisor of interoperability at InterSystems and serves on the board of HL7, which developed the FHIR standard. He also teaches biomedical informatics at Vanderbilt University School of Medicine.
He said InterSystems' new FHIR sandbox could offer valuable tools for those looking to create useful apps, connecting to a multisource and vendor-agnostic development environment, giving them realistic clinical data to work with.
A typical U.S. Medicare patient sees two primary care providers and seven specialists across four practices in the course of a year, according to data from InterSystems – that means that app developers who want to make a real-world impact on interoperability need to be conversant with widely varying data types, beyond from different EHR systems, settings and sources.
HL7's FHIR – it stands, of course, for Fast Healthcare Interoperability Resources – has caught on faster than any other interoperability standards since it was first unveiled more than five years ago, thanks mostly to its ease of use compared to specs such as HL7 versions 2 and 3.
"It's easy," said Leftwich. "HL7 version 3 kind of fizzled because it broke under its own complexity – you practically had to have a PhD in it to build something simple with it. Not that it isn't used some, but it was never going to take off like FHIR did."
On the other hand, with FHIR, "there are hundreds of thousands of twentysomethings with web development skills who can get the idea of FHIR in a weekend," he said. "There are FHIR hackathons where somebody walks in on a Saturday morning and doesn't know anything about it, and on Sunday afternoon they've build a little app."
That’s not necessarily to say they understand the nuances of clinical data, disease processes, the way things actually work in a hospital or workflows enough to build the next killer app in 12 hours but it’s definitely a step in the right direction.
As developers start to understand use cases, what data they need for FHIR, how that gets represented, those apps will only become more sophisticated.
“To be really interoperable, you need to have data vocabularies, code systems – SNOMED, LOINC, etc. – that are the way you build the model for a particular piece of data," Leftwich said.
FHIR has already proven itself as perhaps the go-to spec for new development, and looks likely to continue to build on that momentum.
"You can see the whole data for an individual as FHIR," he said. "And you're not missing any of the data that you would be if your app was instead pointing toward a single EHR that has maybe a lot of data about that individual but not all the data. And the reality today is that a lot of data about individuals is not in the EHR. Not just social determinants, but everything: conditions, medications, etc.
Clinicians are people too
Patient-facing apps are a huge area of focus, of course, and there's enormous potential for clinical apps with FHIR and other open APIs.
As Apple, Cerner and others have realized, patients "want to see all of their data – they don't want to see all of it at once, but they want to have access if they're interested in one thing," said Leftwich. "The same is true for clinicians. They don't usually want all the data, they just want to be able to see what's important right now."
"Interoperability is changing. It's no longer about connecting two systems inside the hospital to each other. It's about trying to get all the data for an individual in real time, the way we're used to in other domains."
Russell Leftwich, MD
By its nature, FHIR is the first standard that's able to query for a piece of data, said Leftwich, "because FHIR is, in its essence, an API – a RESTful API. And because it's a freely available standard, it's an open API."
But all the openness in the world won't accomplish much if the apps enabled by it don't speak the same language. That is a challenge.
"It does get more complicated because we need to develop the FHIR profiles – the models of the information – because two people can build something with FHIR that does the same thing, and it's not interoperable because they built it a little bit differently," he said.
Leftwich said the roadmap for FHIR is trying to address by setting up a mechanism for sharing FHIR profiles for use cases to give everybody the same representation of specific data.
He's already been in touch with the VA, for instance, to get it some data types into the environment, to help nudge along interoperability advances envisioned by the Lighthouse initiative.
"They've created synthetic data to match their patient population, and we will be looking to get that data into our sandbox," he said. "The developers need to learn about FHIR and learn about what that real data actually looks like. Deal with the data that's the real stuff – or realistic – in the way it's represented in other systems."
So far, FHIR has been "more successful than anyone thought it would be," said Leftwich. "Unlike previous standards, where people waited to see what it's going to be like, with FHIR, people have taken it and run with it."
Very often, the applications being created with it are really cool. But the challenge is to create an ecosystem where the developers using open standards to build apps have a deep understanding of the issues they should be helping to solve – helping to up the ratio of new programs that are truly useful.
"The sky's the limit," Leftwich added. "Interoperability is changing. It's no longer about connecting two systems inside the hospital to each other. Or many systems inside the hospital to each other. It's about trying to get all the data for an individual in real time, the way we're used to in other domains.”
Twitter: @MikeMiliardHITN
Email the writer: mike.miliard@himssmedia.com