Dr. Doug Fridsma, CEO of the American Medical Informatics Association, has been working on the nuts and bolts of interoperability for a very long time. Prior to joining AMIA, he served as chief scientist at the Office of the National Coordinator for Health IT, leading management of the Federal Health Architecture and Standards & Interoperability Framework during the pivotal post-HITECH period.

Since then, Fridsma and his AMIA colleagues have been vocal proponents of a forward-thinking and creative approach to interoperability, with an eye toward the health system of the future – one fed as much by data from medical devices, apps and other consumer-facing technology as by the clinical elements of the electronic health records.

In a future driven by new types of patient-generated information and social determinants data, most of it coming from outside of traditional health systems, Fridsma says it's critical to think of interoperability not as a goal to be strived for, but as an ongoing process, driven by diverse stakeholders, that will continue to evolve and be reshaped by emerging developments.

Fridsma spoke recently with Healthcare IT News about some lessons learned from his tenure at ONC; what AMIA thinks about the proposed interoperability rules from 21st Century Cures; the importance of staying focused on achievable use cases for data exchange, why it might be useful to share first and standardize later, and what lessons can be learned from the APIs undergirding the World Wide Web.

Q. What's AMIA's take on interoperability? Both where we are now, and where we're going? The organization takes a pretty expansive view of how it should develop. What are the components we need to be thinking about, beyond the walls of hospitals and practices?   

A. What is the purpose of interoperability? What is it that we're trying to achieve with the interoperability specifications and the standards and all that other stuff? I think it's really important that we don't lose sight of that. The reason we want things to be interoperable is that we can exchange information and then use that information that's been exchanged in powerful ways.

Is it because we want to be able to have apps and other devices that help empower patients to be first order participants in their care?

There's a whole host of things that we need to consider, and in my view of the world, interoperability can't be separated from the thing you want to do. Because interoperability isn't some kind of abstraction, some verdant green pasture where, you know, it's flowing with milk and honey – or flowing with data – it really is about being able to do something now that you couldn't do before, because you have the data in a format that allows you to make that happen.

And so, to me, that's part of what we really have to make sure we do, is to recognize interoperability is difficult in the concrete, but impossible in the abstract. You have to think about what you're trying to do, or what you're trying to accomplish with interoperability.

Now, that has a couple of good outcomes, right? It becomes much easier to measure it. And it also becomes much easier to see if you're making progress if you've got something tangible that you couldn't do before that you now are able to do as a result of systems being interoperable.

Q. Have we even truly gotten to the point of having a reasonable sense of what we really want and need to be able to do, beyond bi-directional exchange?

A. As the world progresses, we're going to want to start doing new and different things that we didn't anticipate that we were going to do 10 years ago, right?

So if interoperability is defined by what you want to do, and over time you want to keep doing more and more things, in some sense you lose sight that it appears as if interoperability is fading away. Because the gap between what you want to do and the data standards and the infrastructure to help support that seems to be widening.

But it isn't so much that interoperability isn't moving. It's that the things we want to do with it are changing and becoming more complicated. So we lament interoperability, but in fact we've made good progress. But then, you know, as we make that progress there's new things that we want to try to do: Now that we've been able to exchange this information, let's try to do some more sophisticated analytics, or let's try to make sure that semantically it's integrated. There's a whole variety of things that we could think about in that space.

Q. There's a lot of frustration out there, and perhaps rightfully so, that we're still talking about this after all these years. But what can we do now, that we weren't able to do, say, back when you were still ONC? What have we been able to accomplish in the past few years?

A. Well I think there's a lot more data that's flowing. It's very specific. You know we've got things like consolidated CDA, and there's exchanging of that of that kind of information. I think one of the challenges that we have is that at ONC we pushed to make sure that we would use standards to support interoperability. And so we pushed very, very hard to make sure that there were structured, discrete data elements, things that were kind of well formulated from a semantic perspective.

When you press for structure and standardization first, and then sharing second – what ends up happening is that you have to speculate as to how to structure or standardize in anticipation of that thing you want to do. You sort of say, "If you build it they will come." That if you standardize it, people will use it. And sometimes we got it right and sometimes we didn't get it right.

When I take a look at the descriptions of the USCDI, for example, the plan there is that as standards mature, they'll add to the USCDI, and they'll expect more and more information to be shared. My own feeling is that it has the equation upside down – or has the value proposition upside down.

I sort of feel like we should share everything, and then standardize it over time. So what ends up happening is, if you've got the entire designated medical record set, right, there are some very basic standards that give you a little bit of metadata. They'll say: This document is about Mrs. Jones from Dr. Smith at General Hospital; medical record number, date, and it's a pathology report.

So rather than trying to standardize disease progression or disease classification, or the ontology of possible malignant diagnoses, or structuring the way in which all the elements that might be captured in a pathology report are there, we should get that pathology report out and to have just a minimum amount of information, and then all of the rest of it pretext. And computable. Not necessarily standardized, but computable.

Because then I think what happens over time is that all the pathologists get together and say, "You know, I'm getting all these pathology reports, and they're all different. What if we just got together? Because it would make my life a whole lot easier if we all did it in a similar way.”

What ends up happening is that you actually share at first, recognize the value and then have sort of a value-based standardization process that you can prioritize, based on what people think are going be important to standardize because they've looked at the data, they've seen what's in it and they can figure out ways to do it. Because there may be other things where you say, “You know what? I'm just going to use Google Analytics. Or, I'm going to go to natural language processing. Or, I'm going to convert this to FHIR resources and that'll be enough for me.” We don't have to do a whole bunch of standardization.

Google did a really nice Brain study where they took huge datasets and they used an NLP, created FHIR resources, and used that as a way of providing some structure, after it was shared. Now, they basically said it's not worth it to try to standardize all those reports before we share them. We actually can use other techniques to be able to get get value out of it. So if interoperability is really about exchanging and use, they figured out a way to use it without those standards in place.

Q. When we look to the future, though, we're talking about even more complexity: patient-generated health data, medical devices, etc. How well-positioned are we to be able to capitalize on some of that, given the ongoing challenges with just "basic" EHR data?

A. If we try to standardize or structure it all before we have an opportunity to share it, it'll never get shared. It will never get there. And so it even gives more impetus. Right? Just like I was saying: The gap between the goal of ubiquitous interoperability and where we are now has widened – in large part because we want to do more things with the data. The gap has also widened because there's more kinds of information that are out there as well.

Even if we spent all of our time, money and energy right now to standardize what it is that we've got, and tried to create some sort of interoperability specification that would help us exchange that information, next year there's going to be new data types and new kinds of information. We're never going to actually be done with this job. So let's not wait, and let's not let the perfect be the enemy of good. Let's not let good be the enemy of better either, but let's try to make sure that the information is shared and then smart people are going to tell us what we should prioritize, and then we can use free text and other techniques to get the value we want out of it.

I think one of the things that we have to be very careful about is that many of the people that are in healthcare are thinking about how all these things can interact with healthcare systems.

But the reality is that the healthcare system is one of many players in this. There are consumers. There's billing. There's you a whole host of different groups, and more and more data that's going to be relevant to healthcare is going to actually be found outside of the healthcare environment, rather than inside.

For example, things like social determinants of health. One response is: Let's standardize and let's create kind of social determinants of health that are captured in the healthcare system.

The other way is: How are we going to get to a point where we can have interoperability with social services, for example, so that we we actually are able to both send and receive data on patients from social services.

So then it becomes even a bigger problem. I think when the problems get bigger and bigger like that, you no longer can look at this from a traditional, kind of architectural view. You have to really step back and say this is more like the World Wide Web than it is creating a program or creating, you know, integration within a single enterprise.

And when that happens, you have to have different ways of solving those problems and the World Wide Web is built on a set of standards – kind of a stack of standards, but they're pretty simple. There are essentially four APIs that run the World Wide Web.

The World Wide Web operates on a "get," which is clicking on the link; on a "post," which is when you order something from Amazon and click OK to buy it; it has a delete function, which usually only is put into place for a wiki, and an update function. And those four APIs are what really manage the World Wide Web. So what are those kind of basic functions that we need in health care? Because if we can do that and simplify it then it's going to be much, much easier for us to be able to sustain it as it grows.

We've got this push to develop APIs in healthcare, and there's potentially hundreds or thousands of them. That isn't necessarily going to be sustainable unless we think about what are the most basic kinds of functions that we need to do. And if we can standardize on those, it isn't like I have to learn 1,000 or 2,000 different API for Cerner and Epic and Allscripts and Apple and everything else.

Maybe what we need to do is simplify the approach. And I think FHIR is going to help us because it gives us a more constrained set of building blocks to work with. But you know, what are the basic functions that we need to be able to do?

Q. What do you think are the biggest remaining challenges? Are they related to technology and standards? Or are they more kind of cultural, people and process related?

A. You go to the technology folks, and they'll say it's all a people problem. You talk to the people, and they'll say it's a technology problem. Everybody likes to point fingers at the other group.

I actually think that from a technology perspective, we have some of the basic functionality that we need. But when we start talking about meaning and value and kind of more human characteristics, whether it's on the technology side or the people side, I think that's where we struggle. Because meaning is really important. But it's much more complicated than just having a syntax for how you would engage.

And then, as you said about business processes and drivers for information sharing versus information blocking, it really becomes a people and a cultural problem. There's governance issues. Those are the sticky things that are problematic. It's easy to come up with the security and transport standards, and everybody kind of agrees upon those those. Those are much easier than to really understand what the nuances are about business drivers that would allow people to share or standardize things. Or integration in a dynamic way, so that not only do you know the context of the data, but you know where it fits in the workflow. Because people have different ways of doing that, and if you send someone a diagnosis code and it's an admission diagnosis and not a discharge diagnosis, that has implications in how those systems should view that information and if it doesn't capture that context, bad things happen.

Q. Obviously, where the rubber hits the road on this stuff is going to be in the private sector. But what can policymakers be doing better or differently?

A. There are a lot of ways to solve these problems. I'll just give you an example from usability – it's not interoperability, but it's illustrative. One way to solve it is to assess usability using standardized criteria. NIST has that. The airline industry has certain kinds of requirements for the way in which usability occurs. And you just require everybody to meet the characteristics of a certain usability. I'm not proposing that that's the right way to do things.

That carries with it a very heavy regulatory arm that requires people to do certain things in a certain way. I think it tends to inhibit innovation and novel user interfaces that could get better. And regulation is a very, very blunt instrument to try to effect change. Because the more specific you get about it, the more brittle or difficult it is to manage it over time. The world changes and regulations take a long time to run through the process.

The other way you could do it is to figure out a way to let markets drive increased usability, and let people vote with their feet that if they've got a good system that has high degrees of usability they should be able to use those systems. And if they've got low degrees of usability, then we should, you know, leave those systems and go in and buy other systems that are going to be better.

We see this in cell phones and we see this in other kinds of technologies in which usability, because people can move their phone number and they can move their contacts and they can transfer all the information from one phone to another, they're able to get increasingly innovative and better products.

Q. Which would be the better approach, if we can pick just one?

A. We don't have a real good market in healthcare. You know, you spend a billion dollars implementing a system. And you spend $600 million if you want to transfer to another one. You don't have the market liquidity that would drive some of those behaviors that you'd like to see.

The regulations are trying to address that. This electronic health information, or EHI, export function that's described in 21st Century Cures, says I should be able to take all the information – billing, administrative and clinical – and I should be able to export it from my electronic health record in a format that's intelligible, and that somebody could import into a new system. I think that's an effort to address some of the market failures, or the liquidity of things. But that's going to be a really hard thing for vendors to swallow.

The challenge is that you can't or shouldn't have it both ways. You can't have a low regulatory environment in a market that's locked up. You've got to figure out some way to either unlock the data, and let the market drive innovation and interoperability, or you're going to have to have a heavy hand of regulation to force people to do things that they're otherwise not going to want to do or have any need to do.

I tend to favor ones that are going to drive better innovation and empower physicians and patients, because it's all about getting the data out of the systems. If you get the data out of the systems, even though the vendors may or may not like that, in the end I think it's going to drive better engagement with the physicians and the patients and probably lead to better innovation and interoperability, because people are going to have to compete on a much more level playing field because if you don't like a particular system, the cost of converting to another system is lower and that makes it easier for you to make decisions that could potentially improve the product.

Q. One last question. Speaking as we did earlier about the ONC and CMS rules, where does AMIA stand, and what will you be telling those agencies during the public comments period?

A. We've got a set of policy principles that help guide the kinds of things that we pay attention to. We really want to make sure that data is used to make patients first order participants. We like the things that are about getting patients access to their full medical record.

I don't want the regulations to put in kind of a two-tiered system, so that patients, if they want their full medical record, have to accept it in a format that is less useful than if I wanted to exchange my consolidated CDA using the Argonaut profile, for example.

We really want there to be a more unified infrastructure so that patients can access their entire medical record using the app infrastructure. And there are some standards and other things that could be useful. Because that, I think, is going to drive a whole lot more value for patients than some kind of one shot export function that occurs just for patients.

That's going to be really challenging for anybody to do anything with that information. So we really would like to have patients be that first order participant in their care and make them part of the app world, even while they access all of the information that's present in their electronic health record.

Ultimately if you can get the data out, people are going to do interesting and useful things with it. And that can help us inform the interoperability conversation because you can get that data to prioritize as your next initiative, based on taking a look at what's there, how close it is to becoming a consensus-based standard and then focusing your efforts on that low-hanging fruit.

We've looked through some of the information blocking and there's a whole set of information about what can you charge, and things like that. Because AMIA doesn't sell apps – we're an individual membership organization, not a trade organization – those things are really important and we want to make sure that it doesn't limit patients and providers access to that information. But we probably have less skin in the game about how much is going to be charged or what's legal to be charged for, as long as it doesn't impede the ability for patients and providers to get access to their information.

The information blocking is complicated. In some sense, it feels like there's gonna have to be a lot of smart lawyers to try to figure out what's going on there. Like if there's a violation based on a policy, is that one violation or is it the 100 million patients that were affected by that policy?

We as an organization have developed three response teams that are meeting every week for the next five weeks. So we've got kind of about 30 hours of work from our members, times about 30 or 40 members. So we'll have a lot of eyes and thought into this. I'm hopeful that we'll be able to produce something that is thoughtful and constructive, because this is really what's going to define health information exchange and the health IT space for the next five to 10 years.

Twitter: @MikeMiliardHITN
Email the writer: mike.miliard@himssmedia.com

Healthcare IT News is a HIMSS Media publication.