The Covered Entity Conundrum: How TEFCA's Treatment Definition is Creating Unintended Barriers to Healthcare Data Exchange

Last week’s White House meeting on healthcare interoperability couldn’t have come at a better time. As I sat in on the urgent Commonwealth members call that followed, one thing became crystal clear: the healthcare industry is at a critical inflection point, and some of our well-intentioned policy changes are creating barriers we never anticipated.

For those of us who’ve been working in healthcare interoperability for decades, this moment feels both promising and precarious. We have an administration that’s putting serious emphasis on data exchange and interoperability, but we’re also grappling with regulatory definitions that are inadvertently excluding important healthcare providers from nationwide networks.

Let me walk you through what’s happening, why it matters, and what I think comes next.

The Great Treatment Definition Split

Before TEFCA entered the picture, participation in networks like Carequality was relatively straightforward. You needed to be a licensed provider following HIPAA rules, and the Carequality agreement outlined those responsibilities. The framework was broad enough to include the diverse ecosystem of healthcare providers who all play legitimate roles in patient care.

Then TEFCA introduced something new: two different types of treatment exchange purposes. There’s regular “treatment” that aligns broadly with Carequality’s existing definition, and then there’s “required treatment” – a more restrictive category that explicitly requires participants to be covered entities under the strict federal HIPAA definition.

This distinction was born out of legitimate concerns. The dispute between two Implementers last year highlighted questions about who should have access to patient data and for what purposes, based on a broad definition. And there is no question that a small number of participants began taking advantage of the situation. Patient Privacy Advocates, health systems, and EMR vendors wanted greater certainty about the legitimacy of network participants. The pendulum swung toward more restrictive definitions as a trust-building measure.

But here’s where unintended consequences kicked in: the original HIPAA covered entity definition was created decades ago, primarily to facilitate electronic transmission of claims data, eligibility checks, and remittances. It wasn’t written with today’s complex clinical data exchange ecosystem in mind.

The Real-World Impact

The theoretical has quickly become practical, and the results are troubling. Epic, as one of the largest implementers under Carequality, adopted TEFCA’s required treatment language as a business rule for their “phone book review” process. It is understandable that Epic wants to be consistent across both networks, especially since they’ve stated they want all their customers to join TEFCA by the end of 2025.

But the effects of this policy are beginning to have significant impacts. Every week, they publish Carequality Directory updates to Epic facilities across the country, and if a given new directory entry (participant) does not pass their covered entity review, they are effectively excluded from exchanging data with Epic sites.

This isn’t just a minor inconvenience – it’s a fundamental barrier to care coordination. When Epic represents the largest number of providers in most markets, being excluded from Epic data exchange can render network participation meaningless. I do want to commend Epic for being fair and transparent. They alert Implementers when an entry is being denied. But given that this is usually an unexpected result, it is creating delays and confusion.

We’re seeing this play out with several types of providers who deliver legitimate healthcare services but don’t fit the narrow covered entity definition:

Concierge medicine practices that don’t accept insurance but provide primary care and care coordination services. These providers often serve as medical homes and need access to lab results, specialist reports, and hospital records to deliver comprehensive care.

Free clinics that provide essential services to underserved populations. These safety net providers desperately need access to patient data to avoid duplicating services and to understand patients’ complete medical histories.

Assisted living facilities where licensed providers deliver care but the facility itself may not process insurance claims. There are over a thousand such facilities currently using Carequality today, getting tremendous benefit from data exchange for their residents’ care.

Specialty imaging and testing centers that operate on a cash-pay basis but generate critical diagnostic information that needs to flow back to referring providers.

A Practical Workaround

While we work toward longer-term policy solutions, we’ve found a practical approach. While some providers may not seem to be covered entities upon initial review of their website, they may actually be covered entities under federal HIPAA regulations.

Since many of these healthcare organizations have to coordinate care with other providers, they often have relationships with EDI service providers for eligibility verification, even if they are not accepting insurance themselves. This information is needed to verify patient coverage when referring to specialists, ordering lab work, or coordinating with other covered entities.

We are helping our clients by having provider groups document their use of EDI services – taking screenshots of their portals showing active accounts tied directly to the provider group name we’re registering in the directory. This isn’t about gaming the system; it’s about demonstrating that these providers are, in fact, performing EDI transactions that qualify them as covered entities under federal HIPAA law.

This solution works because it addresses the underlying reality: these providers are delivering legitimate healthcare services and need data exchange capabilities to do so effectively. The covered entity requirement shouldn’t become a barrier to appropriate clinical data flow.

Federal Momentum and Policy Signals

Yesterday’s White House announcement represents more than just political theater. Based on conversations with colleagues who were in the room, several important signals emerged:

TEFCA remains central to the federal strategy. Despite early concerns that TEFCA might be sidelined, both the Assistant Secretary for Technology Policy and the National Coordinator made clear that TEFCA continues to be an important pathway for participation in nationwide networks.

The emphasis is on “join a network” – any qualified network. Whether it’s TEFCA, Commonwealth, your local HIE, or other established frameworks, the message is to actively engage in community-based health information exchange rather than remaining isolated.

Speed and scale are priorities. This administration appears to want to overcome obstacles faster, encourage new use cases, and accelerate FHIR adoption.

Record locator services and provider identity are getting attention. The federal government recognizes the value of record locator services (RLS) and its role in solving persistent technical challenges that have hindered scalable interoperability for years.

Most importantly, some of the feedback received through the recent CMS RFI process and direct feedback from some QHINs, highlighted how the current approach may be creating information blocking scenarios – exactly the opposite of what interoperability policies are supposed to achieve.

The Path Forward

I’m cautiously optimistic that we’re approaching a solution.

The original TEFCA documentation actually anticipated an evolution with the Required Treatment definition. When they first introduced the required treatment definition, they explicitly stated their intention to “come back and open this up more” once the TEFCA framework was established. With TEFCA momentum back, hopefully, “now” is the moment.

Exchange Purposes and Payment Structures

Beyond the covered entity issue, we’re also grappling with questions about fee structures for different types of data exchange. TEFCA explicitly allows fees for healthcare operations, payment, care coordination, and even public health use cases. This reflects the reality that data has value and responding organizations incur costs in providing access.

But the practical implementation remains unclear. Payers who are being asked to join networks are understandably concerned about what they’ll be required to pay for data access, especially with healthcare operations becoming a mandatory response in February 2026. Without clear frameworks for payment structures and fee determination, adoption could stall.

The federal government has experience with fee-based exchange – the Social Security Administration pays a fee per chart they access through the national networks for disability determinations. This model could provide a template for other use cases, but the details matter enormously.

The Bigger Picture

After more than two decades in healthcare IT – from putting the first computers in doctors’ offices in the 1990s to building modern interoperability networks today – I’m more excited about our current moment than I’ve been in years.

We have an administration that seems to view healthcare interoperability as a strategic priority rather than a regulatory obligation. We have networks that are technically capable of supporting the full spectrum of healthcare data exchange. We have providers who understand the value of connected care and are demanding better tools.

What we need now is policy clarity that supports the full ecosystem of healthcare providers who contribute to patient care. The covered entity definition made sense for claims processing in the 1990s, but it’s inadequate for today’s complex care coordination needs.

The good news is that the conversations happening at the highest levels of government recognize these limitations. The commitment to federated networks, the emphasis on removing barriers, and the focus on patient benefit over bureaucratic definitions all point toward solutions that serve the broader healthcare ecosystem.

Looking Ahead

Over the next few months, I hope we’ll see significant movement on several fronts:

Policy clarification around “required” treatment definitions that better reflect the realities of modern healthcare delivery while maintaining appropriate trust and security measures.

Enhanced federal involvement in network governance, providing the leverage needed to overcome resistance and accelerate adoption, particularly for Individual Access Services (IAS) – whose time has come as a mandatory response exchange purpose under TEFCA.

Expanded exchange purposes with clearer implementation guidance, particularly around payment structures and fee determination.

Improved provider identity and record locator services that make nationwide networks more functionally effective for all participants.

The key is maintaining momentum while working through the practical challenges. We can’t let perfect become the enemy of good, but we also can’t accept policies that inadvertently exclude legitimate healthcare providers from the networks their patients need them to access.

For those of us working in this space daily, the message is clear: stay engaged, provide feedback, and don’t hesitate to escalate real-world problems to the policy level. The federal government is listening, and they want to solve these challenges. But they need to hear from practitioners about what’s actually happening on the ground.

The future of healthcare interoperability has never looked brighter – if we can get the policies right to support it.

Marilee Benson is President and Co-founder of Zen Healthcare IT, where she leads strategic initiatives in healthcare interoperability and data exchange. She serves on multiple national network advisory councils and has over 30 years of experience in healthcare IT, from early EMR implementations to modern interoperability frameworks. She holds monthly office hours for the healthcare interoperability community. You can sign up for Marilee’s office hours by clicking here.