Why the FHIR standard may not get us to interoperability

No common data language

Today, every company using the FHIR standard has created its own custom version. So, while it might be easier to connect applications together, there is no commonality across the healthcare industry for how data is identified or stored.

"It's true that using FHIR doesn't mean interoperability," acknowledged Stan Huff, M.D., chief medical informatics officer at Intermountain Healthcare in Murray, Utah, as well as vice chairman of HL7 and a well-known advocate for the use of APIs in healthcare. "It doesn't mean there is a flaw in the standard itself. But if you are going to get to true interoperability, you have to add further clarification and constraint on exactly how to use FHIR in a particular situation."

In other words, every provider and platform would have to agree on everything, from gender identification to terminology around high blood pressure, none of which was spelled out as part of meaningful use.

Niko Skievaski

Meaningful use, which jump-started the EHR industry, requires the use of APIs, but doesn't go further to mandate semantic interoperability. This is why FHIR is doomed, said Niko Skievaski, co-founder and president of interoperability platform provider Redox, based in Madison, Wis., and an active member of HL7.

"When you get down to how FHIR was developed and adopted, it will fail," Skievaski said flatly. "It will not provide semantic interoperability."

Skievaski put much of the blame on HL7, which he called a "pay-to-play" organization where larger companies end up with a proportionately bigger say in how the standard is developed. Many of those organizations don't have a vested interest in making sweeping changes, he said. They're not willing to force their customers to standardize on language or location of data, which they could do even if it was unpopular, he added.

"At that sort of detail level, the standard is compromised. You have incumbents defining [the standard] who can say how and when to adopt it, because they are the ones at the table actually creating it," Skievaski said.

Joseph Kvedar

Providers aren't going to step up, because the business case to make changes for interoperability does not exist, said Joseph Kvedar, M.D., vice president of connected health at Partners HealthCare in Boston, one of the nation's largest healthcare networks.

"That's why it keeps lagging," Kvedar said. "And I work for a healthcare provider -- it's in our best interest to keep your data from going to a provider down the street. It's in Epic's best interest to keep your data unique so you don't switch to Cerner. Until we see quality of care suffer massively or see revenues drop because patients are not coming to us because of interoperability, it's a nice-to-have."

Tweaking the API

Although Huff would disagree about the benefits of interoperability, he's also a realist.

"There are business and political issues [around FHIR], certainly," he said. "And those issues could cause companies more work to adhere to the standard. And there's some equivocating about whether companies really want those standards, because they could introduce competition to what they're producing."

Huff is the co-chairman of the HL7's Clinical Information Modeling Initiative, which meets weekly to try to reach agreement on semantic interoperability in the FHIR standard API. He can point to some successes, such as language around clinical staging of breast cancer, but admitted it's a slow process.

Meanwhile, Redox uses the FHIR API in all of its 350 healthcare platform integrations, but it's the "Redox" version, and customers aren't given a choice, Skievaski said. "We map all of their data into our standards," he explained. And then the company translates it all into FHIR, because Redox wants to support the vision of interoperability.

Shannon Sartin

In the end, each Redox installation is a custom effort, something API use was meant to eliminate or make easier. But the Redox model -- of a tweaked, but then settled-on API customers must use -- might be the place to start when it comes to making FHIR more useful, said Shannon Sartin, executive director of the U.S. Digital Service, a group that has used the FHIR standard API to develop an API for Medicare, Blue Button 2.0.

"I hear people, including people I work with, pick apart FHIR as a standard," she said. "[They say] it's a detrimental health standard. But as we are building tools, if we don't commit our own resources to make the standard better, [things won't improve]."

Instead of only looking at FHIR's problems, Sartin said she hopes the healthcare industry can start to act more like the broader open source software development world where standards are a work in progress and everything is shared.

"Proprietary data models have caused a lot of heartache for the industry as far as getting data out," she said. Working on FHIR the right way could change that, she said.

Huff, who described himself as an optimist, isn't ready to give up on FHIR yet.

"Even without semantic interoperability, there's still value in FHIR," Huff stressed. "There are lots of use cases where it makes sense and edge cases where [interoperability] doesn't matter."