Doug Fridsma, MD, President & CEO, AMIA
We all know that interoperability must be solved, but what’s the first step we need to take? Doug Fridsma believes it’s in changing the definition. “We need to stop thinking of it as a ‘utopian place’ where data can freely flow.” Rather, it should be viewed in a much simpler and more practical way — as “incremental added functionality.” In this interview, the CEO and president of AMIA talks about why interoperability wasn’t baked into Meaningful Use, why he thinks FHIR has great potential, and why patient access has become such a big priority for his organization.
Fridsma also reflects on his time with ONC, discussing some of the difficult decisions that had to be made and why he believes a “front-loaded incentive program” made sense when it came to Meaningful Use, and talks about the work AMIA is doing to advance the field of informatics.
Chapter 2
- ONC’s interoperability framework
- Redefining interoperability — “It’s not a utopian place.”
- Working as a physician with Scottsdale Mayo Clinic
- Thoughts on FHIR — “There are a lot of good things about it”
- 80/20 rule
- “You can’t let perfect be the enemy of good.”
- Barriers to sharing
LISTEN NOW USING THE PLAYER BELOW OR CLICK HERE TO SUBSCRIBE TO OUR iTUNES PODCAST FEED
Podcast: Play in new window | Download (Duration: 11:45 — 10.8MB)
Subscribe: Apple Podcasts | Google Podcasts | Spotify | Android | Pandora | iHeartRadio | Podchaser | Podcast Index | Email | TuneIn | RSS
Bold Statements
It’s about incremental added functionality. Going from a paper record to a PDF to something that is more structured — each one of those provides additional interoperability and the ability to both exchange information and use the information that’s been exchanged.
Interoperability is defined by the thing you want to do. That’s why the practical approach to measuring and defining interoperability is to say, what do you want to do, and given that, what’s the functionality you need to make it happen?
I’m pretty optimistic that FHIR is going to solve some of the problems we have with interoperability, and I think the people that are leading the effort and the governance structures that they’ve put in place have the potential to really make it useful.
You want something that you can constantly improve. I used to say the only standard you never change is the standard that you never use. If you use it, you’re going to find things that can make it better, and I think FHIR has that potential.
Gamble: One of the words that keeps coming up is interoperability. I saw that a few months ago, AMIA gave a statement supporting the ONC draft framework to measure the use of interoperability standards and recommended a measured approach that focuses on the clinician-patient experience. Can you talk more about this from your organization’s perspective what you’d like to see?
Fridsma: I think interoperability is one of those things that oftentimes is defined as a place — this notion that we’ll achieve this nirvana of data liquidity and interoperability when data can freely flow from one system to another. They define it as this utopian vision, but I think interoperability is not defined as this utopian place that we eventually will arrive at. Interoperability is really defined by the ability of systems to do things automatically that previously they couldn’t do.
If you want to measure interoperability, you have to define the thing you want to do. I like to give an analogy from when I was seeing patients. I would see patients the next day after they had been in the emergency room, and they’d pull out of their pocket this yellow carbon copy sheet from their visit. I was practicing at the Scottsdale Mayo Clinic — it gets hot there. If you take those yellow sheets and you put them on your dash in the 110 degree weather, they completely blanch, and you can’t see anything in it. You’d see someone the next day and they’d say, ‘here’s my sheet,’ and it was entirely illegible. I couldn’t read any of the things there.
To me, interoperability would be if somebody sent me an electronic copy of their visit in my inbox the day before I saw them. I’d be able to read that information and I’d be able to actually see the patient and know what meds or diagnoses or treatments were given. That, to me, would be a great improvement. But if what I want to do is add to their visit all their medications that they were seen, having a PDF of their ER visit isn’t going to be helpful. I’d need to have some sort of structured format that would allow me to import that directly into the electronic health record.
And so interoperability isn’t a utopian place. It’s about incremental added functionality. Going from a paper record to a PDF to something that is more structured — each one of those provides additional interoperability and the ability to both exchange information and use the information that’s been exchanged. I think that’s the fundamental advice; if we want to get to a place where we have better interoperability, we have to be able to measure it, and you can’t measure it in the abstract. You have to measure it in concrete functionality, which is to say if I went from paper to a PDF in my inbox, that’s one measure, but maybe we go from a PDF in my inbox to a structured import that it can be put directly into the electronic health record and be able to check for drug-drug interactions. That’s yet another level.
And so interoperability is this incremental additional functionality based on things that you want to do. Our advice has been — and will always be — that you have to ground interoperability into specific tasks and specific things you’d like to be able to see. And then you’re able to see whether you’ve achieved it or not. Once you have the PDF in your inbox, the next stage is going to, ‘this is useful, but it could be even more useful,’ and we need to keep pushing to do more.
Gamble: Right. I’m sure it’s no surprise to you that is a buzzword and something that’s talked about so much. When you break it down that way, it makes a little bit more sense and it’s more of a practical view on interoperability.
Fridsma: I think interoperability is fundamentally a practical thing. We talk about APIs and we talk about all these frameworks, but the reality is that interoperability says, ‘I can exchange information and I can use the information that’s been exchanged.’ If I can exchange but it’s in a format that I can’t use, that it’s really challenging, and you don’t have interoperability.
And the thing is, because we want to use the information for different things, like being able to read it, or check it for drug-drug interactions, or be able to do data mining on it — all the myriad things, interoperability is defined by the thing you want to do. That’s why the practical approach to measuring and defining interoperability is to say, what do you want to do, and given that, what’s the functionality you need to make it happen?
Gamble: One thing we’re starting to hear more about now is FHIR. There are people who are pretty strong advocates of it, and of course there are skeptics. What are your thoughts on FHIR and the potential it has?
Fridsma: There are a lot of good things about FHIR. By way of complete disclosure, I was on the HL7 Board of Directors when they launched some of their Fresh Look activities, one of those being FHIR. And so I’ve been a fan of FHIR for a while. There are a couple of things that make FHIR very interesting. The first is that it’s trying to hold fast to an 80-20 rule. They’re trying to solve 80 percent of the problem while recognizing that 20 percent of the problem is going to be really hard, and is going to add tremendous amount of complexity. They’ve done a pretty good job using their governance structure to stick to the 80-20 rule.
The second thing I find is interesting is that it’s not the modelers that are developing the standard, which was one of the challenges with the version 3 from HL7, but it’s the implementers. HL7 is written to help implementers’ jobs become easier. That’s a key point because that’s how I think achieves such rapid adoption — it doesn’t take three months to learn all the nuance of how to program it. It’s written in JSON and in XML, and it’s using modern languages that people understand.
Third, it has testing built into it for interoperability in the development of the standard and the implementation of the standard. So by creating FHIR servers that allow you to implement a specification and test it against a FHIR server, it helps you test both the sending and receiving of that information in a way that many of the other standards didn’t really give you that ability to dynamically do. And so it was often very arduous to test it, to see if things were working correctly.
The challenges for FHIR are going to be that because they’re solving the 80-20 rule, there is this notion of extensions. One of the criticisms of the version 2 HL7 standard is that you if saw one implementation of a version 2 standard, you’ve seen one implementation of a version 2 standard. And so while you could achieve interoperability within an organization or across a specific enterprise, it was difficult to exchange V2 messages between different organizations, because they’d have different versions of the same standard.
There’s been a number of different projects. The Argonaut Project is one in particular that has tried to take a look at the variations that are present and try to get some more national agreement that we should all implement things in similar ways. There’s a recognition of one of those challenges and efforts already underway to help mitigate some of those risks that the flexibility of FHIR will lead to lack of interoperability because everybody’s going to do things in a slightly different way.
There really isn’t right now an alternative to FHIR that has arisen. I think that’s why many people are trying to fix the challenges that FHIR has and trying to implement what’s there. I’m pretty optimistic that FHIR is going to solve some of the problems we have with interoperability, and I think the people that are leading the effort and the governance structures that they’ve put in place have the potential to really make it useful. There’s always the risk that people are going to develop proprietary solutions and try to have those become ubiquitous, but increasingly, I’m seeing people and organizations — including some large EHR vendors — that are really trying to work as a community to develop some consistent ways of implementing FHIR for important things like clinical decision support or document exchange.
Gamble: It’s interesting when you look at it that way. It’s not a perfect solution, but holding out for one just doesn’t seem like a very smart thing either, so maybe it’s better to try to improve upon what’s there.
Fridsma: Exactly. You can’t let perfect be the enemy of good, but you also shouldn’t let good be the enemy of better. And I think FHIR is one of those things that doesn’t let perfect be the enemy of good, and they also have processes that allow them to take what’s good and make it better. To me, that’s the best that you can hope for in a standard, because you’re going to learn so much in the process of implementing and testing. You want something that you can constantly improve. I used to say the only standard you never change is the standard that you never use. If you use it, you’re going to find things that can make it better, and I think FHIR has that potential.
I think the challenge goes back to some of the business processes around sharing. If you don’t want to share, you can oftentimes create technology barriers that make it hard to share, or you can adopt solutions that will make it easier to share. I think sometimes those things are not made based on the technical merit, but rather on the business cases that might drive them.
Share Your Thoughts
You must be logged in to post a comment.