A Q&A with ONC director Micky Tripathi

When it comes to working on behalf of health data interoperability, few people are better qualified than Micky Tripathi, Ph.D., M.P.P., the new head of the Office of the National Coordinator for Health Information Technology (ONC).

Tripathi has spent his career in the health information technology field, most recently as chief alliance officer for Arcadia, a health care data and software company. While there, he served as project manager of the Argonaut Project, an industry collaboration to accelerate the adoption of Fast Healthcare Interoperability Resources (FHIR).

Earlier, Tripathi was president and CEO of the Massachusetts eHealth Collaborative, a nonprofit health IT advisory and clinical data analytics company. Before that, he founded and was CEO of the Indiana Health Information Exchange.

Tripathi recently spoke with Medical Economics® about his goals as ONC director, especially in the areas of health data interoperability and electronic health record (EHR) usability. The interview has been edited for length and clarity.

Medical Economics® (ME): What are your top priorities for ONC?

Micky Tripathi: I divide them into two categories. One is the immediate priorities with respect to the pandemic, and those are related to trying to help with specific things like improving the scheduling experience that patients have so that vaccination gets easier.

And we’re doing a lot of work in public health. We’re working on an executive order in partnership with the CDC (Centers for Disease Control and Prevention), looking at evaluation of public health systems, evaluating what we’ve learned through the pandemic and then making some recommendations about the future.

Then we have the regular stuff that ONC does — first and foremost being interoperability. We have a couple of dimensions of that. One is information blocking. The applicability date for the (21st Century Cures Act) information blocking rule was April 5, so we’re doing a lot to educate the industry to help it move forward on that.

We also have the Trusted Exchange Framework and Common Agreement, which is the nationwide interoperability governance. The final thing I would add is we’re doing a lot of work in social determinants of health and outcome disparities and how can we think better, deeper, more broadly about how to enable health information technology to identify and help to solve the disparities in health care that exist today.

ME: I don’t usually think of HIT (health information technology) as having a role in that. Can you explain in more detail what form that would take?

Tripathi: The first step to even knowing how we’re doing with respect to health equity and health disparities is to be able to measure it, and you can’t measure it unless you’re capturing the right data so that you’re able to ask, “How am I doing once I stratify according to different demographic characteristics?”

So that’s fundamental to HIT. You’ve got to have that data capture in EHRs and then structure it in a way that you can aggregate it and run the kind of analytics to be able to understand that minority, marginalized, underserved communities are getting disparate care compared to other groups. Then ideally you want to be able to provide decision support or tools back to providers and other frontline people who are using those systems to be able to help them take actions when their areas are identified. So all of those are part of HIT.

ME: I want to go back to the 21st Century Cures Act. ONC has said its initial focus is on the elements in the core data for interoperability, such as transitions of care and clinical information reconciliation. Why focus just on those elements?

Tripathi: Information blocking covers the broader category of information called EHI, or electronic health information, which is (a of piece) of the designated record set, which is defined in HIPAA (Health Insurance Portability and Accountability Act of 1996). That’s what the Cures Act said is EHI, which is basically everything you or I might have in a provider’s office, assuming they use an EHR and whatever has been migrated to an electronic form.

So information blocking covers all of that. We recognize that it’s hard to just flip the switch overnight and say all of that should be made available on demand when we haven’t been doing that. It’s not a common practice, and systems aren’t set up to do it. Provider organizations don’t have workflows for that. We realize it’s a complicated thing to do.

So we said let’s focus at the beginning on what we call the Core Data for Interoperability, which every certified EHR system is already required to be able to generate, either in the form of a continuity-of-care document or soon in a FHIR API (application programming interface). So we said those things are already available because providers are already required to exchange those for transitions of care, for example. So why don’t we start with those, and we’ll call that EHI for the first 18 months; and after that, hopefully everyone is understanding information blocking and the workflows, and then you can open it up. And it also prepares them for how they are going to open it up beyond those data sets.

ME: Pulling back a little to the issue of interoperability generally, on a scale of 0 to 10, with zero being no ability to send data and 10 being the ability to do it as easily as we send regular emails, where would you say our health system falls now?

Tripathi: It depends on what you’re doing and what health system you’re in. For example, if you’re in an academic medical center and you’re on a fully certified EHR system that’s connected to CommonWell or Carequality or a health exchange, that exchange is actually happening in the background already, millions of times a day across the country. And that’s a continuity-of-care document that contains the CDI we were just talking about, which is 24 to 25 data elements. And those are like if you and I sat down and said what do we think are the basic elements that the physician should be able to have access to on any given day for any given patient. You and I would come up with pretty much what’s in the CDI. It’s problems, allergies, meds, dates of encounters, most recent lab results, etc.

So that’s exchanged in those systems today. It doesn’t even require effort. Providers in a large system will see it in the background and often they don’t realize that it’s come in from other places. Similarly, if you’re on any system and you want to do e-prescribing, you can do it pretty much out of the box on most EHR systems in a very automated way that’s familiar now.

On the other hand, if we’re talking about the ability to, in any setting, be able to get a record in almost any place, if you’re on like a small vendor that isn’t connected to one of these nationwide networks, then there’s going to be a gap there because all those systems haven’t adopted the technologies and not all of them are connected to the network.

The last thing I would say is we’re never going to feel like we’re at a 10 because just like when we first got our cell phone, it was pretty primitive but we thought it was the coolest thing in the world. But if we went back now and asked, “Am I satisfied with that?” the answer would be “Absolutely not. It’s terrible.”

It’s the same way today with interoperability. We’re always going to want more. Next it’s going to be what about genetic information? What about algorithms, why don’t we have those? So I don’t want to pretend there aren’t problems and gaps, but I think it depends on the use case.

ME: Doctors often complain that EHRs are designed as billing and coding tools rather than for their ability to improve clinical care. Can ONC do anything to change that?

Tripathi: We’re very sensitive to that, and we completely appreciate that clinician burden from health information technology is a huge issue. We’ve worked on the clinician burden report, and we continue to look at burden issues that come from the HIT itself as well as the things that are pushed through the HIT. One of the things we’ve started to understand as we think about these systems is that a lot of what physicians feel as “burden from the system” (are sometimes) things that organizations are pushing through the system that (physicians) didn’t do before — more documentation requirements, for example. Then the EHR gets blamed for that when it’s actually just a vehicle for things that couldn’t have been done in the paper world and now are being pushed through that system.

So we work a lot with our partners at the Office of (Burden Reduction and Health Informatics) at CMS to try and understand these burden issues and how can we reduce (them) through better usability and through reduction of some of those requirements — because some aren’t really necessary or they are very cumbersome because what naturally happens in these kinds of transitions is you take a paper process and try to ram it through an electronic system it wasn’t designed for. If you said this is an electronic system, we should think of it natively, we could probably take better advantage of the electronic tools that we have.

We do what we can to highlight those through our program on clinician burden. We also have usability as a part of the certification that vendors are supposed to go through. Then we also have things like in the next generation of EHR certification, we are requiring real-world testing rather than just testing in a laboratory, which as we know, just like with drugs, there’s a big difference between testing something in a lab and testing it with people in the real world.

ME: Is there any evidence that EHR vendors are focusing more on usability now than they were five or 10 years ago?

Tripathi: I think there is. There’s a very heterogeneous set of vendors so it’s hard to say this is true for every vendor. But I think vendors have big usability programs, and they have physicians on staff and they have programs (in which) they apply usability science as well as input from physicians who are using the system. An individual may feel frustrated by their system; they may feel like it isn’t usable. That doesn’t necessarily mean there haven’t been usability considerations behind the system. It’s just that it’s a complex system, and it can’t be perfect for everyone.

But I will add two things: Systems don’t get better without people using them and providing feedback. Software engineers sitting in a room by themselves can’t design a perfect system. They need to be able to put those in the field and get constant feedback from users. So as we’re maturing, I think we’re starting to see those systems are better.

The second thing I’d point out is that the whole move toward FHIR APIs, which are now required by ONC regulations, is that you ought to be able with your EHR to download apps and use them on your EHR, just like you do on your phone. And the beauty of an app on your phone is that when you open it, it’s usable in ways that you want it to be.

And that’s what apps in the API world promise as well — that if you’re in your EHR system, you ought to be able to have a set of apps that don’t lock you in to that EHR system. If you have a different way of doing something, you can do it through an app as well. I think that’s a really important part of usability that may not be obvious now to a lot of doctors, but it is coming in the next few years as apps and APIs start to mature.

ME: Does ONC have the ability to nudge EHR manufacturers in that direction and make sure they’re following through?

Tripathi: Absolutely. Our regulations — the information blocking rule and the corresponding EHR certification rule — require that the vendors make available FHIR APIs. And those are supposed to be open APIs so that apps from the outside can connect to them without special effort. And there’s a whole set of provisions that are part of that regulation to make sure that’s a level playing field, so you don’t have vendors trying to close out things that they see as competitive or create too many burdens for a provider to be able to get an app on to their system. There are fixed dates that the vendors are required to meet. And that’s the hope — that we can create platforms you can have apps on of your choosing. And hopefully that makes it a better experience for everyone.