The Laws You Need to Know for EHR Partnerships: Part 2

In my last post, I wrote about how referrals are a much more nuanced topic in healthcare than they are in non-regulated industries. But boy oh boy, was that just the beginning. Perhaps even more complicated and gray is the art of data partnerships in healthcare.

In as simple terms as possible, we can split partnerships into those that are focused on lead sharing and revenue and those that are product partnerships.

This article is more about product partnerships, as in you need to integrate your product with an EHR.

Similar to anti-kickback, different regulations come into play when you’re a certified health IT developer. There are also federal regulations that apply when you’re talking about sharing data via that certified technology or other integration methods. I deal with this nearly every day in my role leading an EHR marketplace. EHR marketplaces are probably the hottest way to get into an EHR’s integration program but they’re typically not the only route. Some programs may be designed around a specific integration method, such as a non-certified method, meanwhile you can still select to integrate via a certified method. Athena and Epic kicked off the concept of an app store. Athena has hundreds of listings and Epic’s used to be nicely named the App Orchard and has since been reimagined as the Epic Showroom.

Subscribe

What I’m getting at is… Information Blocking.

HealthIT.gov introduces information blocking as “Information blocking is a practice by an "actor" that is likely to interfere with the access, exchange, or use of electronic health information (EHI), except as required by law or specified in an information blocking exception. The Cures Act applied the law to healthcare providers, health IT developers of certified health IT, and health information exchanges (HIEs)/health information networks (HINs).”

Note that “actor” is defined in the last sentence. In addition to providers and HIE/HIN, “health IT developers of certified health IT” is added as an “actor.”

So what or who is a "health IT developer of certified health IT?” 

The easiest way is to go to the chapel. No, not a church, but CHPL. CHPL is the Certified Health IT Product List. The list is mainly EHR and EHR related products. If you search Epic, Greenway, Nextgen, Cerner, Athena, Healthie, Elation, etc you’ll find their certified products. Therefore, all these companies are considered “actors” in the above definition. You’re less likely to find technologies that serve cash pay and solo providers on this list. Companies like SimplePractice, Grow Therapy, Alma, TherapyNotes, Practice Better are not found on this list.

Where did Information Blocking come from?

In 2016, the Cures Act made sharing EHI expected and essentially required in health care. It also authorized the Secretary of Health and Human Services to identify "reasonable and necessary activities that do not constitute information blocking." - which are the information blocking exceptions that will get into later. In 2023, some definitions were updated or changed as a part of the phased rollout. Chiefly among these changes were, “Specifically, ONC removed language that applied before October 6, 2022, that limited the definition to the subset of electronic health information (EHI) represented by data elements identified in the USCDI v1).” This broadened the scope of what EHI could be included in information blocking.

First, let’s get it out of the way. So, what about companies that aren’t “actors?”

Well, if you want to read a super interesting thread about how companies who are not “Actors” think about Information blocking, you can read this thread in SimplePractice’s support forums. The attitude is a bit of, well were not certified so we don’t have to comply. While the thread starts out with sharing client notes, it broadens into SimplePractice’s ability to not comply with the Cures act because they’re not a certified health IT developer. SimplePractice’s team clarified to their providers that “you'll see that non-certified EHRs are required to make the sharing of Electronic Health Information possible; however, they're not required "to have direct access capacity." Since you can download any part of a client's medical record, or the entire record at once and "Share" it with them through the Client Portal, SimplePractice is fully compliant with HIPAA and this new rule.” Whether you agree or not, SP isn’t wrong legally.

_{Personally, I think creating opportunities for direct access is a huge opportunity for SimplePractice. I’m biased as a Director of Marketplace for an EHR, but with more than 200,000 providers, SimplePractice’s provider volume gives them huge opportunities in forming an API partnership program.}

What it means for you, a company that wants to integrate? 

If you’re trying to integrate with EHRs, companies that are not certified health IT developers don’t have to let you connect directly. Technically, they provide their customers with ways to get the data out of the system and then share that data with other parties. Trying to work with an EHR that would force their providers to download and upload information to a new system or share PDF-like documents practically makes it so difficult to work with additional technologies that many providers don’t. When I was a sales leader at a telehealth company, we implemented the prospect’s EHR as a key indicator of how qualified a lead was because it played such a big part in whether we’d win the deal.

However, many solo providers or small group practices don’t want to manage 10+ vendor contracts. If their EHR provider offers everything that providers need to run their practice, then that’s all they want. They don’t want a fully certified EHR and ten other tools if they don’t necessarily need them.

So, what DO certified health IT developers have to do?

You can see below that definition isn’t super clear other than saying it’s something “likely to interfere.” Though, there are some guidelines where the government makes it extremely clear. For example, there are certified and non-certified methods of integrations. Actors have some more control in their non-certified methods of integration.

You want to know just how “gray” this all is? The government literally provides an FAQ of what could be considered information blocking in different scenarios and their answer is - it depends. It needs to be evaluted on a case-by-case basis. There’s an FAQ section available here that outlines scenarios like when would a delay in fulfillling request be considered information blocking.

When it comes to APIs, the article points to this answer, it is likely an interference “where a delay occurs in providing a patient’s EHI via an API to an app that the patient has authorized to receive their EHI.”

Certified Integration Methods

The ONC office put together this splendid deck for us when it comes to certified APIs. There are very limited cases where you can charge fees related to certified APIs and as you can see below even in those instances, the EHR must ensure the fees are based on verifiable criteria and uniformly applied while being related to that EHRs cost of supplying the certified API.

For certified APIs, the EHR may charge its provider customer to use the API, but then can not also charge the third party application using them. An easy real-world example of this is Epic and Healthie. Both EHRs make their FHIR APIs available at no cost to third parties. Below is a screenshot from Epic’s website stating that FHIR resources are free “for developers who create apps for use by patients and healthcare organizations.”

If you want to dive deeper into the different scenarios and methods on how EHRs can charge their customers for access, checkout slides 18-20.

If you’re reading this and you want to integrate with EHRs, slide 21 is more relevant.

When it comes to certified APIs, the only time the certified health IT developer can charge the third party tech company, or in the deck “API User,” is for value added services. It’s essential that they’re truly value added as you can see the deck straight up points out that the fees can not be related to developing production ready software. It truly has to go above and beyond.

It’s important to note that these are certified APIs. Many EHRs, like Healthie, Elation, Athena, offer proprietary APIs that allow for more flexibility than the above. These organizations are thus providing multiple options for integration. For example, if you’re working with an organization that provides a GraphQL API - that is not a certified API.

What exceptions are there to information blocking?

Thankfully, they’ve been nicely curated here.

The following are exceptions:

1. Preventing harm

2. Privacy

3. Security

4. Infeasibility

5. Health IT performance

6. Manner

7. Fees

8. Licensing

There are some obvious exceptions to the rule. But, interestingly enough there are areas where these exceptions don’t apply where you think they would. For example, you would think security being an exception means that an EHR is allowed to vet a third party for its security practices before giving it access to the API. Well, the government takes a stance that certified APIs have security measures already in place and the Standard API certification criterion focuses on read-only requests. Therefore, if the patient consents to the data being shared, then you can’t block it for security reasons.

When it comes to EHR partnerships, the most common exceptions used are Manner and Fees.

Manner Exception

The manner exception states that it’s not information blocking for a company to limit the ways in which it provides access to electronic health information. The government states, “This exception supports innovation and competition by allowing actors (like an EHR) to first attempt to reach and maintain market negotiated terms for the access, exchange, and, use of EHI.” Therefore, it’s perfectly reasonable for actors to require you to accept a set of terms and conditions. The manner exception can go hand in hand with the feasibility exception.

Fees exception

The fees exception means actors don’t have to do everything for free. In fact, it allows actors to generate a “reasonable profit margin” by providing access to EHI. There are a number of conditions that must be met to satisfy the fees exception.

There are two big conditions to point out for the fees exception. The first is that fees should be applied uniformly for all similarly situated classes of persons/entities and requests. In practical considerations, this can negate the ability of the requestor to negotiate the fees, if the fees have already been fairly applied to other requestors. The second condition is that competition can not be taken into consideration. Therefore, an EHR couldn’t try to increase their fees for a similarly situated set of requestors if they thought that set was competitive to the EHR’s offerings.

In summary:

Information blocking was established from the Cures Act to encourage a standard set of rules for ensuring organizations that needed access to electronic health information could access it. As the holders of EHI, many EHRs are a primary focal point for needing to comply with the regulations. As a result, over the past several years many EHRs have overhauled their API programs. Whether Epic announcing the Epic Showroom,EHRs that straight-up blocked access now providing ways to access basic certified FHIR APIs, or EHRs offering various ways to access EHI through both certified APIs AND non-certified methods, we increasingly see some second-order effects as a result of information blocking.

In needing to share information, it’s not necessarily information blocking to have to agree to standard terms the EHR (or other actor) sets forth or to have to pay for it. But, always ask the actor what methods of integration they make available.

Also - remember that there needs to be EHI involved for any action to be information blocking. It’s not information blocking if you have no mutual customers or zero right to access EHI from an Actor’s system.

If you enjoyed this article or know someone in healthcare partnerships who should take a read, share this with a friend.

If it’s your first time reading and you’ve made it this far, subscribe for more content on digital health go-to-market and my unfiltered opinions on the industry.

Looking for more healthcare interoperability content? Check out Brendan Keeler’s HealthAPIGuy newsletter.

Shout out to Brendan for helping edit this edition of Talking Health.