FHIR APIs Will Accelerate Patient Information Access in 2023

In a lengthy interview with HealthLeaders, ONC Chief Micky Tripathi says simplified data exchange will benefit providers, patients, and even public health.

Federal rules state that certified EHRs must support the standard FHIR application programming interfaces (APIs) by the end of this year. It's one more step toward transforming patient information access in a years-long process dating back to the birth of the EHR, and will touch the day-to-day information sharing of providers, patients, and even public health agencies.

HealthLeaders recently spoke with Micky Tripathi, PhD, MPP, director of the Department of Health and Human Services' Office of the National Coordinator for Health Information Technology, about the standardized FHIR API rule and how it will impact health systems and patients in 2023. This interview has been lightly edited for brevity and clarity.

HealthLeaders: What can healthcare IT professionals expect as API standardization is implemented at the end of 2022, as the legislation directs?

Micky Tripathi: They should have available to them the standard FHIR API in their EHR. If they don't already have that available to them, they should be asking their vendor where it is.

That will take time for that to get incorporated into workflows. ONC doesn't have the authority to tell a provider they're required to implement it. As you probably know, providers will often not purchase the latest and greatest software upgrade, so it may be that they lag a little bit. CMS rules do require that providers who participate in payment rules, by the third quarter of 2023, have it in their system as a part of certified electronic health record technology. This policy was finalized in the 2021 Physician Fee Schedule based on the updates to certified health IT finalized in the ONC 21st Century Cures Act final rule.

The other thing I think that they can expect is that they'll have the availability of more apps that are connected to their systems. Some may be apps for patients to be able to access their information. Some may be apps that are for provider-to-provider exchange, or other kinds of use cases. The idea of the standard FHIR API is to make EHRs a little bit more like open platforms that spur a lot of innovation for providers and patients to be able to have better use of data that's in EHR systems.

Right now, because you don't have a standard API across all these EHR systems, an app developer has to build one version for Epic, one version for Cerner, one version for eClinicalWorks, one version for Athenahealth [and so on]. And that undercuts the economics of it. It makes it really hard to scale. The opportunity here is to say that standard FHIR API ought to create more innovation that makes the economics better for truly scalable types of apps in the same way that we've seen in other industries.

We published a blog in August where we were tracking how many vendors were actually certified already. We noted at the time that only 5% of vendors had actually certified their system for the standard FHIR API, but those vendors were large vendors, so they actually covered, like, 60% or 65% of hospitals and 75% of ambulatory providers.

HL: Concerns have been raised about the fact that consumers could use these APIs to share their health data with non-covered entities. Such entities may or may not be adequate data stewards of this highly sensitive personal data. Is there a need for ONC to perform ongoing oversight of these entities to assure patient privacy, or is additional legislation or regulation necessary?

Tripathi: The first thing that patients need to know is that using these apps can provide great benefit to them. But when they use these apps, if it's not an app that's provided to them by their provider, then they are taking the protection of the data into their own hands, meaning they're responsible at that point for what happens. So they're responsible for doing the diligence on the app, or making sure that the app has the privacy and security protections that they want, and that the app is sharing information in ways that they deem appropriate.

That's a source of a lot of confusion for individuals in the country, and that's a real problem for us as a country. HIPAA has been called something like the most misunderstood, most important law in the country because people think that HIPAA protects medical record data wherever it lives. And it doesn't. It only protects medical record data when it's in the hands of certain entities, like a hospital, a doctor, or a health insurer. So that's the first thing: Patients absolutely need to know that they are the ones who are responsible, once they've downloaded the information and brought it into apps that they control that weren't provided to them by their provider. It's something that HIPAA didn't really contemplate back in 1996.

Right now, the protections that exist for entities that live outside of HIPAA, and data that flows outside of HIPAA, is FTC Section Five, a consumer protection kind of provision that affords some protection, but not nearly as much as a patient probably thinks it affords. Basically, FTC Section Five says that an organization needs to abide by its published privacy policies. You can have an app that lives outside of HIPAA, and has a privacy policy that literally says we're going to take your data and sell it to whoever we want, whenever we want. And of course, you just click through. That technically wouldn't be a violation because they told you, right? It was in the fine print, but they told you.

The data that that lives outside of the healthcare delivery system itself has a ton of what we would consider medical record information. It's just not in a medical record. Think about the information that is part of what we call the data exhaust, the data that I just leave behind when I'm using my phone. So I get a backache. And I start to search 'backaches.' And then I use Google Maps to go to my doctor. And then I use Google Maps to go to CVS or Walgreens. And then I get the prescription, then I look up the drug on Google, and then I, and then I have fitful sleep for two weeks and every night in the middle of night, I'm picking up my phone and looking at my phone. All of that information is information that one could put together and create what people call an inferred medical record, that I would argue is probably at least as good for that particular encounter as the medical record that my doctor actually has. Because it's a day-to-day track of how I'm doing.

The conversation about privacy is really a much bigger conversation. It's not just HIPAA. It's not just medical records. It's about privacy in general, and just the recognition that we have information that's out there that people can use to infer things about our healthcare that we may not appreciate.

HL: Another issue that comes up with this patient-directed data is provenance. Patients might want to carry their digital X-rays to their next provider. But today, the system seems more suited to asking the next provider to request the X-rays from the previous provider. And that's where lots of complication ensues -- how difficult it is to do that? And we're starting to get into the info blocking issue. Does this new API standardization in any way address the issue of provenance?

Tripathi: It does.

You just described two different patterns for exchange of information. One would be provider-provider, whereas we think of the B2B, and the other would be B2C2B. I get my records from one provider, and then I myself am the broker, or the custodian, of that data, and then I provide it to the next provider.

What we want is to support both, because we think both are really valid, and that provides resiliency and assuredness in the system. In an ideal world, it would actually be automated, so that the provider's scheduling system would see that you are coming in tomorrow, and I should blast out queries to find all the records on you that I can find, so that those are available to the provider when they're doing a review of your chart before you come in the next day. That's how a number of nationwide networks work today. They do look at the schedule one to three days in advance, and they go off and query the information. But we also want to enable, through these FHIR APIs, the ability for you to do just as you said, that you want to be in control of it for whatever reason. So it supports both. TEFCA [the Trusted Exchange Framework and Common Agreement], which we haven't talked about, would support that provider-provider exchange, and the FHIR API kind of capability would support that kind of focused exchange.

HL: Patients also want something that can be auditable. Do the API regulations themselves provide for that?

Tripathi: I totally agree with that. That's one of the ways in which that backbone infrastructure, TEFCA, provides that kind of high-volume, high-reliability capability in the back end that's traceable and auditable. It's a part of the technology and the technical specification. And it's also a requirement from a HIPAA perspective, if you're a provider organization, you're required to keep track of the disclosures that are made of that patient's information to you or to other parties. Now, again, a non-HIPAA entity, they don't have those requirements. So that's the thing to be cautious of.

HL: Will the new APIs help in any way with compliance with the information blocking regulations? Or are they two separate issues?

Tripathi: They are separate issues, but they are related.

The way in which they are separate issues is that information blocking is agnostic to technology, completely. Information blocking is focused on the data that says that there is a corpus of data called electronic health information, which is the electronic portion of the HIPAA-designated record set. And that information is what is required to be made available to patients or other authorized parties, by any actor under information blocking, which is providers, technology developers like EHR vendors, and health information networks. So that's agnostic to FHIR, to CCDAs, it's even agnostic to EHRs.

The data doesn't have to be in an EHR. It's really just about the data. It defines, there is this data and you as an actor are required to make that available if it's available to you electronically. The way in which it's related, and there's an overlap, is that FHIR APIs give a provider or technology developer or health information network another way of making that information available in an easy manner.

HL: It's been some months now since the implementation of information blocking. What is the data telling you from what people are reporting on the information blocking portal?

Tripathi: There's over 500 complaints now. I think it's running at probably something like one every day or two every three days. As you can see on the portal, where we, every month, summarize the data and break it out by category of the complaint, the complainant, and then category of who the complaint is against. The majority of the complaints are coming from patients, or their authorized representatives, I think over 80%, and those complaints are mostly against providers.

500, on one hand, seems like a lot. On the other hand, if we compare it to HIPAA complaints, which are in the tens of thousands per year, it's kind of a drop in the bucket. But we're just getting started here. So those proportions could change just because of small sample and all of that. But we're encouraged, actually, that a large number of the complaints are from patients.

I don't want there to be any information blocking. But to the extent that if you think about these regulations are somewhat arcane, and certainly providers are aware of them, but even a lot of small providers don't sort of fully understand the scope of it right now. And we're doing a lot to try to educate and provide outreach. Vendors understand that because they're actors, and they could get penalized if they don't comply with it. But it was surprising to me that it was bubbling all the way down to patients. So the patients actually knew there is this thing called information blocking, and they actually have recourse. They can actually come to the ONC web site.

HL: How do you process those reports? Do you reach out to the providers who have been named? Do you reach out to vendors who have been named? What does ONC do with that other than collect that information?

Tripathi: The law was fairly specific about the way this has to work, and it's pretty complicated. ONC is responsible for the policy, which is to say, to define what is information blocking, and to define what would be allowable exceptions to sharing of information. That's what we put into effect on April 5, 2021. We said, here's the policy, here's the regulation. You are from this point forward required to comply with this regulation.

But what the law specified was that the Office of Inspector General in HHS is responsible for investigation and enforcement. ONC is not a law enforcement organization. It isn't as if we have investigators who can go out to the field and determine whether someone is complying with that. OIG is responsible for enforcement. They haven't yet published their final rule on how they're going to do enforcement. So right now, in theory, you know, OIG isn't doing enforcement, because they don't have the final rule out.

Now someone can complain directly to OIG if they want, but we were the ones who were stated in the law to set up a portal and allow complaints to come into that portal. What happens with ONC is, we get a complaint, we'll do a high-level screen of it to determine certain things. Is this information blocking, at least on the face of it? Or could it be information blocking without investigation? Payers, by law, were not named, so ONC doesn't have the authority to say, this applies to payers. So we're not going to pass that forward to OIG.

To anyone who submits a complaint, we say that within 48 hours, we'll let you know what's happened to it. And so that means there are two things. One is we'll say if this does not appear to be information blocking, if you'd like to resubmit, please resubmit. But this does not appear to be information blocking. Or we say we have passed your complaint to OIG. And that's all we can do at that point.

HL: What's on your priority list for 2023?

Tripathi: TEFCA is a big one – nationwide network interoperability. To date, our nonprofit partner, the Sequoia Project, has gotten 12 letters of intent from different organizations who are stating that they intend to become [TEFCA] networks. We're anticipating that in early 2023, we'll be able to announce the first set of potential candidate Qualified Health Information Networks who have made it through the first big step, which is that their eligibility has been approved, meaning their application has been accepted and approved, and they are signing the common agreement.

HL: And when this goes live, that will mean a much greater velocity to the sharing of health records?

Tripathi: Yes, it should mean greater velocity. It should also mean a broader aperture to the type of information that can be shared. Now, that won't happen overnight. But we're working very hard to have public health be a part of these networks. For example, right now, you've got nationwide networks like Carequality and Commonwell that do great work, but public health agencies aren't connected, for a whole variety of reasons.

But now with ONC, and the CDC, and other parts of the US government involved, you're helping to provide that overall governance framework, and we're now working with public health agencies to say how can we get them directly connected to these networks, so they can get the information directly from providers in you know, in low-cost ways, that's a better deal for taxpayers. So we're not paying for all these complicated interfaces in every jurisdiction. And it also means higher performance and a better public health system overall.