HIStalk Interviews Grahame Grieve, FHIR Architect and Interoperability Consultant

Grahame Grieve is a principal with Health Intersections of Melbourne, Australia and was the architect-developer of HL7’s Fast Healthcare Interoperability Resources (FHIR, pronounced “fire”) specification that allows EHRs to exchange information.

Tell me about yourself and what you do.

I qualified as a bench scientist in a hospital, but got dragged into working for a lab systems vendor. I got more and more involved in interoperability. Eventually I cut loose and consulted in interoperability and system integration in healthcare. Then I got gradually more and more involved in leading the standards in the area. Mainly I consult with the national programs.

Programmers call FHIR public API for EHRs. How would you define FHIR to a clinician and explain to them why it’s important?

It’s a framework for finding and exchanging data between two different systems so that they can exchange data in the background to provide services in the foreground that make people’s ability to do medicine better. You have to sort out flows, data contents, and agreements about responsibilities. FHIR focuses on doing those through modern technology, the same kind of agreements that support the massive systems around Facebook, Google, Apple, and the current social web system.

What lessons have we learned from the adoption of HL7?

It’s really hard to get people to agree. The content agreements and business agreements are valuable things that accrete very slowly. People line up with very long life cycles to them. You can’t expect quick change. You can legislate for it, you can pay for it, but you won’t get it. It takes time to get people to perform surgery on their systems while they’re going.

The criticism of HL7 is that vendors took advantage of its flexibility in making it less of a standard and more of a general framework. Is there a fine balance between being prescriptive enough versus making a standard too open?

Yes, it’s really difficult to find the right balance there. This variation in implementation was because vendors didn’t know any better and we didn’t have any way to encourage consistency of interpretation. We’ve tried to do what we can about that more recently.

There’s also variation because we have no authority to tell people to behave better, to act consistently, to make consistent decisions. Because we can’t dictate behavior, we have to tolerate a lot of inconsistency in the base specification. That fosters inconsistency in interpretation. It’s an ongoing process getting people to agree about those decisions.

What they don’t like is telling them how their business should work. But they do like to tell us that we should solve their business problems.

Are there concerns that the FHIR standard may fall short in meeting the lofty expectations that have been set for it?

There’s people out there who think that with FHIR we’ve solved all the problems. We haven’t, because we’re not authorized to solve lots of the problems.

What we’re trying to do is to get the interoperability format and framework out of the way of the problems that exist. They’re still real problems that will require real hard work to solve. I’m proud of what we’ve done with FHIR, but we only solve one of the set of problems that exist.

What else has to be done beyond developing and using FHIR?

There’s a set of things around security and understanding the balance between usefulness and risk in healthcare. Until we get a degree of agreement across a broad set of stakeholders about what risk is acceptable and what the trade-offs between risks and benefits are, that will continue to be a roadblock.

Then there’s a bunch of things needed around legal liability for exchange of data. There’s always ongoing tension about how much data people want to exchange. Exchanging data and commoditization are related. People will always resist commoditizing their core business. They’ll always be in favor of commoditizing their plumbing. Not a lot of awareness about the relationship between people’s interoperability and commoditization and plumbing in core business. Until core businesses align, then that will continue to be a challenge as well.

Finally, at the clinical level, there’s strong disagreements about clinical content and what kind of clinical statements you should be able to make and be able to exchange. Until the clinicians agree about what clinical interoperability is — not IT interoperability, but clinical interoperability, and that we actually need that — then the amount of clinical interoperability we have will be highly limited.

Was the past focus on document-based exchange a good learning experience and a good alternative or did it take us away from where we should have been going all along?

One of the things that I keep saying within the standards community is that you’ve got to accept your limitations. You can have what’s possible. We weren’t in a position to offer a data-centric standard. The industry went with a document-centric approach. It has great limitations around the ability to do workflow and data integration, but it has a great advantage around the ability to have some kind of immediate, computer-assisted data exchange for humans, where you have low agreement about workflow and clinical content.

Lots of the systems that have come to exist have come to exist because we did what you might call the low-coherency, document-based exchange approach. That’s continued to be a valid thing to do. We’ve gone out of her way to make that possible with FHIR while at the same time allowing people to cherry pick things and do data-based integration and exchange where the clinical processes support and need that. It’s going to continue to be a mixed picture.

When you look at the lack of interoperability, what do you think are the most important or the most difficult issues to address?

Moving data around costs money. Nobody really knows how much that should cost. There seems to be a strong view that the market value is not a fair value because the market is rigged. But none of the proposals that I’ve seen to fix that involve less rigging of the market. They’re just rigging it differently.

It’s extremely difficult to have any sense of what fair value for the cost of exchanging data is. It’s too easy to extract rent one way or another. That will continue to be a major obstacle because for most data exchanges I get involved with, there’s a real asymmetry between the cost of moving the data and the benefits of moving the data. The benefits typically accrue further downstream to someone who’s not paying for the data exchange and really thinks they shouldn’t need to. That will continue to be a big barrier to progress.

Other than that, getting clinical agreement about what the clinical interoperability needs to be and driving clinicians to change their practice to be consistent and to practice medicine consistently rather than inconsistently. That’s a huge cultural gulf that they’re going to have to confront soon.

How long will it be before patients can reasonably expect a new provider to have instant access to their existing data?

It’s a process. In the past, we didn’t have any way of exchanging data. We figured out how to exchange billing and identification data and some diagnostics. Then we added the ability to do some pretty crude document-based transfer of the data. That was a big achievement. I worked on that.

Now we’re extending that to cover through the JSON API task report to cover availability of limited data that can be looked at and maybe processed a little bit. A bunch of consortiums are working on getting better quality and more consistent data. That will take a lot longer.

You build a mountain, you stand on top of it and see a bigger mountain that you can go and stand on top of. The urgent need to build bigger mountains never goes away. We’ll just keep climbing up the stack towards a useful system. Each mountain is about a 10 to 15 year building process. That’s how it has gone historically.

Are we trying to do something in healthcare that other industries haven’t done in asking competitors to share their customer data with each other?

There’s a number of industries where they have data sharing arrangements of one kind or another. Those things are possible and they work to some degree. They need some kind of governmental interference or mandate to make them happen. Very often, most of those industries wouldn’t go back to the chaos they had before.

I live in a country where there’s not a lot of competition for business, but the interoperability picture is not very different. It’s really hard to move data. The US focus on competition and anti-competition is a bit overstated. Countries that don’t have a lot of competition still have trouble exchanging data unless they have a single provider providing all of the clinical systems. It’s just a matter of time to drive consistency.

One big problem people don’t talk about very much is legacy data. Almost all of us could easily get to an interoperable state if we simply one day turned off our legacy data and threw it away. Most practicing clinicians and clinical institutions are kind of reluctant to part with their legacy data. They call it ongoing care of a patient. As long as take that attitude — which we should — to healthcare interoperability, it’s got to be a slow process to move everything forward.

You mentioned that there’s a disconnect between who gets benefits from sharing data versus who pays for the cost of sharing data. What would be the ideal model? Should those who contribute data be rewarded in some way by those who receive it?

I don’t really know. Standards arise in a broken market. That’s a question that I’ve heard a lot of speculation about, but no convincing story. If the incentives were aligned, we wouldn’t need standards and people would just do it. We’re trying to move the market to a better, stable place.

Perhaps countries where they have a more holistic approach to funding … there’s a professor at my local university who says that we have an "ill-thcare" system rather than a “healthcare system.” If we focused on health and paid for health, then maybe the incentives would align differently. I don’t think that’s a very easy transformation to make.

What do you think of the work of the SMART group that uses FHIR as their data query method?

We love SMART. The SMART team are members of the FHIR team and vice versa. We have a very strong working relationship indeed. I think that 80 to 90 percent of the deployment of FHIR systems will also be a deployment of SMART on FHIR systems. It’s possible, although not certain, that SMART on FHIR will eventually become part of the FHIR specification. That’s water to go under the bridge yet. They’re doing great work. I really personally endorse their goals and they endorse our goals to the point where at some stage we might just be one team.

If you could wave your interoperability magic wand and have one wish granted, what would it be?

I wish the clinicians would believe in clinical interoperability the way that the IT people believe in IT interoperability. We’ve had doubters in the past, but pretty much everybody believes in it now if only we can get there. I wish the clinical people thought that that was a clinical problem.