At iHT2-Cleveland, Micky Tripathi Offers a Nuanced View of FHIR and Its Transformative Potential

April 27, 2016
Industry-leading expert Micky Tripathi of the Massachusetts eHealth Collaborative shares his perspectives on the promise and pitfalls of leveraging the FHIR standard for application development going forward

With the journey towards interoperability turning out to be a very bumpy ride in U.S. healthcare, many in the industry are pinning at least some of their hopes on the adoption of the FHIR (Fast Healthcare Interoperability Resources) standard, a standard that has begun to get real traction of late.

The subject of FHIR came up during a session on interoperability on Wednesday, Apr. 20, at the Health IT Summit in Cleveland, sponsored by the Institute for Health Technology Transformation (iHT2, a sister organization to Healthcare Informatics under the Vendome Group, LLC umbrella). The panel, entitled “Interoperability & HIE: Strategies for an Evolving Health System,” was moderated by Mark W. Stevens, principal at ARRAHealth Consulting, Inc., and included as its other panelists John Santangelo, senior director, information technology, at Cleveland Clinic Florida; Kerry McDermott, vice president, public policy, for the Center for Medical Interoperability; Jitin Asnaani, executive Director of the CommonWell Health Alliance; and Micky Tripathi, president and CEO of the Massachusetts eHealth Collaborative.

During the panel discussion, when asked about FHIR, Tripathi said that “There are reasons to believe FHIR could help us. My caution: it is still a very nascent, primitive standard; it’s just a technical standard,” he added. “There are business, legal, and cultural issues. I don’t think we should kid ourselves and believe that a new standard will fix everything. But FHIR does democratize to help us move to the next level,” he continued. “It is based on the same types of interoperability processes in other industries. Other industries see healthcare as a backwater that they would never want to get involved in, because we use moribund standards from about 1985. FHIR is based on principles and basic Internet patterns that Facebook, Google, Amazon, Uber, are using. So there’s a democratizing aspect of it, so developers will start to come into the space as we move forward with it.”

Micky Tripathi

Tripathi went on to say of FHIR, “Also, it’s a true data-level standard. Right now, we’re exchanging continuity of care documents, which is important, but you’re not able to get to the next level, app engagement, until you have true data-level standards, and FHIR does that. So at Argonaut, we’re saying, let’s have this as a workable standard and build on that. There’s a lot of FHIR hype, which is both good and bad.”

Immediately following the conclusion of that panel discussion, HCI Editor-in-Chief Mark Hagland sat down with Tripathi and asked him to elaborate on his comments during that discussion. Below are excerpts from that interview.

I really appreciated your comments in the panel discussion. Can you frame for me at a high level how you perceive FHIR right now, in terms of its potential to help transform the path forward towards healthcare IT interoperability?

Speaking first to the opportunity side, I’ll discuss why you should be excited about FHIR. When you talk to developers from other industry verticals, they’re wondering, first, where are all the technologists in healthcare? They’re really surprised. And that’s because, I think, we have these very arcane, old standards that are cumbersome. I was in Silicon Valley in the fall, at a conference sponsored by [the Palo Alto, Calif.-based] Venrock, one of the VC [venture capital] firms. And a guy said, ‘I downloaded a guide that was over 1,000 pages on CCD [continuity of care document] and other types of document exchange! And we work with APIs [application programming interfaces] are one-offs, and that can be developed in, like a month. And is this like hieroglyphics?’

So the opportunity is that FHIR is based on a set of Internet principles like RESTful API [which stands for “representational state transfer API”] that people use every day. So that’s the opportunity; it’s something more aligned with the way the rest of the economy works. And that will be an opportunity for developers to come in. It will be the crowdsourcing phenomenon. They’ll bring fresh eyes and new use cases. And then that will enable me to exert real demand on vendors. Because right now, how do I get my data, as a patient? Now all of a sudden if there’s an API I can download from somewhere, that gives me the opportunity as a consumer to exert leverage.

The concern about the hype is this: KLAS [the Orem, Ut.-based KLAS Research] did an interoperability study in the late fall. And one of the things they asked providers was, what do you think will be the biggest opportunity and hope for interoperability in the future? And FHIR was number one. And I’m going to bet you that 90 percent of those people don’t really know what FHIR is. In working with FHIR, I still have to figure out the trust issues—legitimate security and privacy issues—how do I know that you’re authorized, from a HIPAA [Health Insurance Portability and Accountability Act] perspective, to interact with my data? A standard doesn’t solve those issues. Those are business and legal issues.

So that’s one concern I have with the overhyping of FHIR. Another issue is, people assume for example that we’ll have all these APIs. But there is still a question of, who’s going to be responsible for those APIs? There are already reports on security issues around them. Who’s going to be responsible for the fact that an API is making ten behind-the-scenes calls when you sign up or sign in? And there are no regulations around any of that. If it’s patient-authorized, vendors aren’t even covered by HIPAA. Anything patient-authorized is not covered by HIPAA. So there’s that question, and there are all sorts of business associate questions. For example, you could download the Uber API from the Internet. Does that mean you could connect to the Uber network? No. You could write the code, but you’d have to sign the contract to be involved with Uber. So there’s all of that that needs to be figured out. And it gets more complicated in healthcare.

Let’s take a few examples. There’s Partners HealthCare in Boston: they may want to vet which entities access their data. They don’t want patients to access apps that might harm them. And Mayo Clinic sells its clinical pathways—it has intellectual property interests. And now over the last month, the Office of Civil Rights has been pushing out guidance; they’re telling providers they’re not responsible for guaranteeing the security of data once it’s in patients’ hands. So it’s not your worry if your patient misuses data… but in reality, they are concerned. So there are still lots of questions out there in the ecosystem about how APIs will be developed and used, just like with Direct. That was a standard that got pushed out into the market, but there was no market ecosystem around it, and it’s taken nearly four years for the market to develop an ecosystem around it.

What about SMART on FHIR? Might that be helpful in this context?

Smart on FHIR’s great. And they’re really the first place that has said, there’s an app store concept we should think about. They’re trying to incubate, to get vendors to develop vendor-agnostic APIs. For example, there’s one I’ve seen, the pediatric growth chart app that Cerner developed, that provides a great example of how to develop apps that integrate well.

Why should or would large EHR vendors be interested in FHIR and SMART on FHIR, in this context?

A couple of reasons. One, there is growing demand for all sorts of things that people want to do with data, and the vendors recognize that they won’t be able to meet the demand. And the youngest generation of physicians, a lot of them are coders themselves, they’re pushing. Residents are creating apps themselves. And so Cerner and Epic are saying, you know what? We can’t develop all those apps, go ahead and ride on our system. But let’s figure out how we do it in a way that scalable across the country.

What does this landscape look like two years from now?

A couple of things. One is interoperability in general. Interoperability, what it’s going to look like, is more and more the way ATM networks and wireless cell phone networks work, we’re not worried about the way that every single physician office is connected. Just how networks are connected.

Are you predicting the demise of HIES [health information exchanges]?

No, those could be other networks as well. So the way cell phone networks work, AT&T, T-Mobile, Verizon—Verizon actually uses their own standard, but they’ve built the adapters to connect to the GSM networks. So connectivity will happen at the network level. So within each network, we don’t have to worry about how each individual network will connect to the other networks.

What will the landscape around FHIR look like two years from now?

I suspect that we’ll start to see some real production use of FHIR, first off focused on the meaningful use-required things. Vendors have to get certified. And so there will be a consumer-facing API requirement, which I think will also be a provider-facing API requirement. And vendors will realize that if something doesn’t work for providers, it won’t work for patients, either. So we’ll start to see patient portals having maturing API capabilities. So Epic, Cerner, athenahealth, will all have their own API stories. And maybe you don’t have interoperability across the yet, maybe they’ll just enable some of the same apps.

Let me give you an example from outside healthcare: just last month, a big event in interoperability was that Microsoft Xbox announced they are open to allowing users of other gaming systems to play with their Xbox users. So if you’re a Sony PlayStation4 player, Microsoft said, we are open to connecting up with PS4 so that we have cross-platform capability for multiplayer games. In this context, Electronic Arts had created the FIFA game, and they had created an Xbox version and a PS4 version, and each of them has a set of users from all around the world not being able to play across platforms. That’s kind of like CommonWell and CareEverywhere. And each of those systems has been live for ten years, and they still don’t have that capability. And Microsoft said, we are willing to open up our network to Sony users, and Sony said, OK, we’ll think about it. So these issues exist in other industries. But these networks allow for connectivity.

In the same way, that’s where we’ll be with interoperability in healthcare. And with FHIR, I see that more as a bottom-up thing. Maybe that will be the basis for network interoperability, but it’s too early to say. What does it mean to connect up a network? With Verizon and AT&T, there are still things I can do within the Verizon network that I can’t do outside it. On AT&T, I can forward voice-mails to other AT&T users, but you can’t do that across networks, because that wasn’t seen as something work making interoperable. So I can see that being the same in healthcare. Epic will always have things that their users can do within CareEverywhere, and CommonWell will be the same, but there will be some things that could happen. I ought to be able to push a document to you regardless of the network you’re on, or send you a query.

That’s a huge thing.

Yes, and if CommonWell wants to do other things, they can. That’s how athenahealth can say, you should go with us, because we’re a part of CommonWell, a broader grouping than Epic, for example. So the question of where FHIR intersects with that—we’ll see more of this API store concept in the next few years. Maybe similar or the same APIs. The market will have to figure that out. And part of that will be this complicated intersection from providers, payers, vendors… Part of the push for interoperability in the gaming industry was from the makers of the games, voicing to Xbox and PS4, why don’t we have interoperability?

Are you optimistic about this trajectory around standards and interoperability?

I’m really optimistic, because I think we’re now at the point where you have this kind of network maturity where you can figure out ways to mimic what’s happening in other industries. Now, these networks are starting to form. It’s thanks to network maturity. CommonWell, Epic, Surescripts, and some of the HIEs like MassHighway, DirectTrust, legitimate networks. And until now, we didn’t have enough of those networks to solve those connectivity issues. And if it’s ten networks or seven networks, covering 80 percent of the market—either way, you have [a market-based quorum for moving things forward]. I remember the first ATMs: they weren’t connected. And six or seven ATM networks finally got together… And we’re now all connected. And ATM networks allow some things you can do across networks, but still, you can’t go to ATM and deposit money, you can only go to your bank and deposit money.

Consider this: in 1901, there were two million phone users in the US. And two-thirds of those users were on one network, AT&T, the Bell System. One-third were on multiple networks. There were 2400 networks covering the remaining one-third. And that’s kind of where we are now in healthcare: two-thirds or so are on CareEverywhere and CommonWell and Surescripts, and the rest are on one of the hundreds of those others, like the HIEs. So the HIES may then goa way. So HIES will have to move upmarket and offer population health tools or capabilities or disparities research.