By LEONARD KISH

Leonard Kish talks to Douglas Fridsma, President and CEO at American Medical Informatics Association, about his work in the Office of the National Coordinator for Health Information Technology, or ONC, and the barriers to implementing MIPS in the most useful and transparent way. In order to communicate the data, of course, we’ll need informatics; but how will that work? And which comes first, policy or technology?

Leonard Kish: When you first began your studies in medical informatics, was there a sense that the field was a science?

Doug Fridsma: After working on the Standards of Interoperability Framework for the National Cancer Institute – which was essentially crowdsourced, I engaged government, research and other pharmaceutical companies and standards organizations to basically come up with what that standard should be – I had an opportunity to go out to the University of Arizona and ASU. Ted Shortliffe, who had been my mentor at Stanford, had just been appointed to be the Dean of the new medical school at the University of Arizona.

Fundamentally what physicians do is information management. The thought we had was, if we really wanted to change the way we use technology in medicine, then one of the biggest ways we can make an impact is to train medical students to engage in and to learn this information, then we can actually start to develop the physicians of the 21st Century.

It was a great opportunity to get in on the ground floor with a blank slate, so there could be there was a new effort to include informatics and information management into the training.

As I started working on developing the curriculum at ASU, we approached informatics from a new angle. If you want to teach someone about pharmacology, and you want them to prescribe medication, you need to teach them pathophysiology, pharmacology, and basically all of the basic sciences. You don’t teach them how to write a prescription – that’s not the first thing you do. You certainly don’t have the pharmaceutical companies come in and teach how to write good prescriptions.  ˇhe way information technology was being taught at the time was just that. You would bring in the big vendors, who would spend a week teaching medical students how to use their system and then reaping the rewards.

We had to figure out if there was a way to educate the students with the basic sciences about how to represent and use information, why to collect it in certain ways (and not in others), how you collect it is often times determined by how it will be used afterwards. It was a very interesting set of activities and much of that work is continuing even today.

LK: Teaching the actual care delivery, which health IT is a part, hasn’t until recently been a part of medical curriculum, and still only at a few medical schools so far. Now that we’re focusing economic attention on value and outcomes, you see a little more of it.

DF: I think we have to change the way to document care delivery. We use something called the SOAP Note (Subjective, Objective, Assessment, Plan) as an outline of how medical information is captured by physicians and others. The problem is that none of those talk about outcomes.

We talk about the subjective complaints, objective tests, physical exams and given that information, what is our assessment of what’s going on? And then we describe a plan of what we want to do. But, nowhere the approach to documentation do we capture what the outcome is. The next time you as a patient are seen, you talk to your medical provider about your subjective, objective, assessment and plan. But no one ever just asks the patient, “Did those medications work for you?”

As we think about value-based purchasing and quality measurement, we go through these conniptions to infer what the quality and outcome was, whereas sometimes, maybe we just need to ask the patient or have the doctor record what the outcome was. I think that there needs to be fundamental changes in medical school curriculums just for us to make outcome assessments happen.

LK: We work with a telemedicine company and your description of SOAP falls into our conversations. We talk about going from event-based encounters where a plan has to be made, versus a really longitudinal perspective. Information technology is just beginning to allow us to track a patient day in and day out, and this shift necessitates interoperability.

Interoperability is becoming an unusually hot political topic. Perhaps because of the high tech industry; some of it coming out of 21st Century Cures, the bill making it through the health committee; and some of it is with the Precision Medicine Initiative. There seems to be recognition that for medicine to move forward, it’s based on the availability of information. In your opinion, what’s going on there?

DF: I’ve tried to maintain for the last six years a consistent definition of what interoperability is. The first thing I can describe is what interoperability is not. It is not a state of utopia in which there is this information liquidity. You will hear this all the time: we want ubiquitous information, and free-flow, data liquidity and all those things.

But interoperability is not that state of the world. Interoperability is defined operationally. I use one of the definitions by the IEEE folks. The best version is that interoperability has two parts: the first part of the ability of two or more systems to exchange information and the second one – the one we usually overlook – is the ability of the systems to use the information that has been exchanged. It’s about exchange and use.

The example is that I use a Mac and you use a PC. I use my mail program and set up an e-mail and send it to you. We can exchange information if you open up Outlook and open my message. We’ve exchanged information. But, if I wrote my e-mail in German and you only speak French, then we’ve exchanged information but there’s nothing you can do with that information… unless you translate it.

The question is: have we had true interoperability? We’ve had exchange, but not really interoperability. The reason why I like the definition of exchange and use is that, when someone says, “I’m so upset, my system is not interoperable,” my first question can be, “What do you want it to do?”

Interoperability cannot be achieved in the abstract. It can only be achieved, given a definition, in the concrete. Interoperability is the exchange and use forces us to ask ourselves “what do we want to try to accomplish?”

When I was seeing patients at Mayo Clinic, I often worked in their Urgent Care Center. I saw a lot of folks that had been seen the night before, perhaps in the emergency room, and they just needed follow up.

Frequently, they’d come to me and have this yellow carbon copy that was written with a felt tipped marker, where the notes didn’t come through as well as they could have. I’m trying to look at this yellow sheet of paper to determine what medications they’re on, what tests they got, what were the results of the test, and it’s all scribbled at 3 o’clock in the morning and I can’t really read any of it.

If I had an electronic copy of that in my inbox, even if it was a scanned image of the original one, I’d have interoperability because I’d be able to exchange the information and use it for the purposes of understanding what happened that night before.

On the other hand, if my goal is to have that document and any new medications that they had been prescribed automatically incorporated that into my electronic health record, I wouldn’t have interoperability for that function.

Interoperability for legibility is different from interoperability for long-term care. If we have “exchange” and “use”, then it’s the “use” part that really defines what interoperability is.

LK: Where can we go from here in terms of the baseline of interoperability? I perceive there is a base level of frustration in the industry at large: how one hospital on one system can get basic information to another system. What are the best measures to figure out whether it’s about “uses” or about something else? How can we assess the quality of our interoperability?

DF: Healthcare is what I would term an “ultra large-scale system,” and a report that the Department of Defense did back in 2006 is illuminating. What do you do when you have a billion lines of code that all have to work together and seamlessly exchange information across these systems? The report was focused on communication and navigation and other kinds of systems, but does a good job of articulating the characteristics of a large scale system.

We need to frame the question. If you frame it as “we need to build some giant architecture that makes this all work,” you’re going to end up with AOL and not the World Wide Web. If you frame it around achieving a policy, like lower costs or higher quality outcomes, technology can help you get to that policy.

I think you need to think more strategically, realizing you are building an ecosystem, not a product. The large scale approach frames the problem better, accepting that we’re never going to centralize medical informatics; it’s always going to be decentralized.

The World Wide Web, which is probably the best example of a successful ultra large scale system, breaks down the technology into a fundamental stack of building blocks. One of our biggest challenges is that we haven’t thought strategically about how we create a set of fundamental building blocks so that the next use case can actually leverage what has been done instead of starting over with new approaches.

It’s sort of like those early telephone systems where they had all the cords and you had to pull the cord to connect it to the right connection. It becomes tremendously complicated because everything is a one-to-one connection; scaling becomes unmanageable.

Whereas, if as with the World Wide Web, you create individual packets to be routed and transferred, you can have set of standards rather than these one-off solutions.

LK: It seems like the lack of interoperability is in some ways used as a strategic advantage.  So how do we get from this insular or institution-based perspective of interoperability to a global perspective? Does it have to be a legislative solution? And how do we communicate and bridge to the consumer (which may actually be key to decentralized thinking)?

DF: There are three fundamental things we need to turn the ship in a better direction. The first step is I think we need to focus on those fundamental building blocks; for how we represent meaning, how we structure information, how we transport it, and how we secure it.  Those four things are really just an API.

But unless we think about what those fundamental building blocks are, even if we develop APIs, we’re still going to be in the situation with the switchboard and the cords. The building blocks are the first goal, and one of the pieces that’s missing is “how do we represent granular data” because most of our exchange right now is document centric.

We need to move from document-centric to data-centric exchange. We need to have a way to represent data at a granular level because that’s how we’re going to be able to calculate quality measures, that’s how we’re going to do decision support, and a lot of the other sophisticated computable things that we need to do.

The second thing we need to realize is that it’s very likely that we’re going to develop ecosystems with a high degree of interoperability within the ecosystems and a low degree between the ecosystems. It’s like smart phones or computers: some people have iPhones, others have Androids; some people use PC’s, some Macs, and some people use Linux.

APIs can be really helpful within an ecosystem but can be challenging between ecosystems. We don’t require that Android works on iPhones or vice versa, but it’s really useful to have ways of exchanging information between those things so that if I’ve got a PC and I’ve got my iPhone, I can still move music back and forth because there’s this thing called an mp3 or an mp4.

I think in healthcare we need that granular data that will help us develop good APIs and clinical decision support, but I need to be able to move from the Android system to the Microsoft system if I need to.  To me, that is having the ability for a patient to have a full extract in a computable, maybe not interoperable, but computable format that they could take from their Cerner System and move to their Epic system or take from Epic and move to NexGen system.

HIPAA allows that to happen but there’s been a lot of pushback and defenders would rather say “well we’re not going to give patients the entire extract, we’re going to give them access to selected information in an API that we develop.”  The issue with that it’s then the vendors who get to decide what information they share and what information they won’t.  That creates an establishment of those ecosystems and sort of locks them in.

If you can create a way of having granular data for these things like clinical decision support and quality measurement and the like, and the ability for patients to have a full extract of their information and actually move information between ecosystems, not entirely interoperable but at least computable, it makes it possible that things like precision medicine can be supported.

Precision medicine is about discovery of new associations and new ways that you can relate genetic information to behavioral and environmental and medical information.  API’s presuppose that you know precisely what information you need to share.  Precision medicine says, “We don’t even know what we’re looking for.”  So we need to have a way to have all the data accessible, to move between ecosystems and to be available for discover for science.