When Interoperability Gets Exploited: What the UPMC-Health Gorilla Incident Means for Your EHR Exchange Logs

On March 13, UPMC began notifying patients that their electronic health records may have been improperly accessed through a national health information exchange network. The disclosure did not come from a ransomware attack, a phishing campaign, or a compromised server. It came from Epic Systems flagging unusual query patterns through its Care Everywhere interoperability platform - patterns that suggested someone was pulling patient records under false pretenses.

The entity behind the queries was Health Gorilla, a Qualified Health Information Network (QHIN) participating in TEFCA (Trusted Exchange Framework and Common Agreement) and Carequality, the two major frameworks that enable nationwide health record exchange. The accessed data reportedly included patient names, ages or dates of birth, diagnoses, clinical notes, medical histories, and encounter details. Social Security numbers were not involved. UPMC reported the matter to the HHS Office for Civil Rights and set up a dedicated phone line (1-855-460-8762) for affected patients.

This is not a standalone incident. It connects directly to a federal lawsuit filed January 13, 2026, in the U.S. District Court for the Central District of California, in which Epic and several health systems - including OCHIN, Reid Health, Trinity Health, and UMass Memorial Health - allege that Health Gorilla and affiliated entities enabled improper access to nearly 300,000 patient records across the Epic community, plus an unknown number from other EHRs and the VA.

If you manage IT or clinical systems at a health care organization of any size, this story has direct implications for your risk analysis, your exchange monitoring, and your incident response planning. Here is what happened, why it matters, and what you should be doing about it right now.

How National Health Information Exchange Actually Works

To understand how this happened, you need to understand the mechanics of TEFCA and Carequality. These frameworks were designed to solve a real problem: getting patient records to follow patients across different health systems and EHRs without requiring point-to-point connections between every organization.

Under these frameworks, participating organizations can query for patient records using basic demographics - name, date of birth, address - or National Provider Identifier (NPI) data. If a match exists, the system returns clinical documents or records. There is no manual review step on the disclosing side. The system relies on trust: the requesting party attests to a "Permitted Purpose," most commonly "Treatment" under HIPAA definitions. For legitimate treatment exchanges, no patient-specific authorization is required under 45 CFR 164.506.

This is the feature, not the bug. Clinicians need fast access to records when treating patients. Nobody wants a manual approval queue sitting between an ER physician and a patient's medication history.

The problem is what happens when someone abuses the trust model.

What the Lawsuit Alleges

The complaint filed by Epic and the plaintiff health systems paints a detailed picture. According to the allegations, entities onboarded through Health Gorilla as a QHIN and Carequality Implementer used sham or fictitious National Provider Identification numbers, shell companies, and fictitious websites to appear as legitimate health care providers. They asserted treatment purposes when requesting records, pulled high volumes of data - tens of thousands of records in single months for some defendants - and returned clinically useless "junk" data back into patient charts to create the appearance of actual care delivery.

The alleged end goal was not treatment. According to the lawsuit, the accessed records were summarized and provided to law firms seeking potential claimants for mass tort or class action lawsuits. Epic's Care Everywhere monitoring tools detected the scheme in part through non-reciprocal exchange patterns - the entities were pulling records at high volume but returning only clinically useless data, which is a significant red flag in any exchange relationship.

On March 13, one of the defendants - GuardDog Telehealth - admitted the allegations in a stipulated judgment filed with the court. GuardDog acknowledged that while it initially intended to provide chronic care management and remote patient monitoring, that never materialized. From the time it began operating in 2024, its business instead focused on requesting, reviewing, and summarizing medical records and providing them to law firms. If approved by the court, the judgment would permanently bar GuardDog from TEFCA or Carequality access, require deletion of all obtained patient health information within one week of entry, and prohibit any further use or dissemination of the data. GuardDog's website and social media accounts have since been deactivated.

Health Gorilla, which served as the QHIN and Carequality Implementer responsible for onboarding these entities, denies wrongdoing. The company has stated it acted immediately to suspend connections when concerns were raised and cooperated with investigations. Health Gorilla filed a motion to dismiss the lawsuit in February 2026, characterizing it as an attack on interoperability that limits competition and restricts access to health care data. The case against Health Gorilla and the remaining defendants continues, with no resolution as of this writing.

Why This Should Be in Every Covered Entity's Risk Analysis

The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough risk analysis of potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (45 CFR 164.308(a)(1)(ii)(A)). This is a Required implementation specification - not optional, not aspirational, not something you can skip if you are a small organization.

That risk analysis needs to account for reasonably anticipated threats. After this incident, exploitation of mandatory interoperability participation is no longer a theoretical risk. It is documented. It has a court filing. One defendant has admitted to it in a stipulated judgment pending court approval.

Here is where this connects to the operational reality of health care IT:

Your organization participates in these exchange frameworks because you have to. The 21st Century Cures Act's information blocking provisions mean that refusing to participate in interoperability is not a practical option for most covered entities. You exchange records through TEFCA and Carequality because that is how the system is designed to work. But that participation creates an attack surface that most organizations have not formally assessed.

Under 45 CFR 164.306(a), covered entities must protect against any reasonably anticipated threats or hazards to the security or integrity of ePHI. Under 45 CFR 164.308(a)(1)(ii)(D), you are required to implement procedures to regularly review records of information system activity - audit logs, access reports, and security incident tracking reports. That is also a Required specification.

The question for your organization is straightforward: do your logs capture external query activity from exchange frameworks? And if they do, is anyone actually reviewing them?

What the Security Rule Requires (and What It Does Not)

It is worth being precise about what HIPAA does and does not require here, because the compliance picture is more nuanced than the headlines suggest.

On the disclosure side, 45 CFR 164.506 permits disclosures of protected health information for treatment purposes without individual authorization. This is by design - it is what allows the system to function. However, 45 CFR 164.502 sets the general rules for uses and disclosures, and a disclosure made in reliance on a false representation of purpose is not a permitted disclosure.

On the technical side, the Security Rule's requirements for audit controls (45 CFR 164.312(b)) are Required - not Addressable. Covered entities must implement hardware, software, and procedural mechanisms that record and examine activity in information systems containing or using ePHI. This is how Epic detected the anomalous patterns in the first place.

A quick note on the Addressable versus Required distinction, since it comes up often and is frequently misunderstood: "Addressable" does not mean "optional." Under 45 CFR 164.306(d)(3), when an implementation specification is Addressable, a covered entity must assess whether the specification is a reasonable and appropriate safeguard in its environment. If it is, implement it. If it is not, document why and implement an equivalent alternative measure. HHS has proposed changes to the Security Rule that would eliminate the Addressable designation entirely, making all specifications Required. That proposed rule was issued by OCR on December 27, 2024, and published in the Federal Register on January 6, 2025, with finalization on the OCR regulatory agenda for May 2026, though the final rule's scope and timeline remain uncertain under the current administration.

On business associate relationships, 45 CFR 164.314 and 45 CFR 164.504 require that compliance obligations flow down through business associate and participant agreements. QHINs like Health Gorilla may not always fit neatly into the traditional business associate relationship, but participation agreements still impose compliance obligations your organization can and should enforce through reporting and audit rights.

UPMC's approach to breach notification - direct outreach to affected individuals plus a dedicated phone line - aligns with the requirements under Subpart D (45 CFR 164.404).

The Practical Challenge for Small and Mid-Size Organizations

If you are the solo IT person at a 25-bed Critical Access Hospital, or one of two people managing technology at a multi-location clinic, the idea of monitoring national exchange query logs for anomalous patterns might sound like one more thing on an already impossible to-do list. That is a fair reaction.

But here is the reality. The tools to detect this kind of activity are probably already in your EHR system. Epic's Care Everywhere platform has built-in monitoring and reporting capabilities. Other major EHR platforms offer similar audit tools. The question is not whether the data exists - it is whether you have configured alerts, whether anyone reviews the reports, and whether your processes would catch a volume spike or an unfamiliar requesting entity.

You do not need a dedicated security operations center to do this. You need a recurring calendar item to pull the exchange activity report, and you need to know what normal looks like for your organization so that abnormal stands out.

For larger organizations with SIEM capabilities, ingesting exchange logs into your security monitoring platform is a logical next step. But even without a SIEM, a monthly review of exchange volume and source entities is a meaningful improvement over no review at all.

What You Should Do Now

These are practical steps you can take this week, regardless of your organization's size or staffing.

Review your exchange logs. Pull external query activity from your EHR's interoperability tools for the past 12 to 24 months. Look for volume spikes, non-reciprocal patterns (entities pulling records but never returning useful clinical data), or requests from entities you do not recognize. Document your findings as part of your information system activity review under 45 CFR 164.308(a)(1)(ii)(D).

Update your risk analysis. If your risk analysis does not already include interoperability and national exchange frameworks as a risk category, add it. Assess threats from false-purpose claims, downstream data misuse, and your organization's reliance on QHIN vetting processes you do not control. This belongs under 45 CFR 164.308(a)(1)(ii)(A).

Set up monitoring thresholds. Work with your EHR vendor to enable or tune alerts for anomalous query patterns. Set thresholds for daily or weekly query volume per external connection. Test your ability to quickly investigate or suspend a suspicious participant.

Review your participation agreements. Confirm that your organization's policies define "treatment purpose" and require verification where feasible. Make sure your business associate or framework agreements include audit rights and downstream accountability. Update incident response plans to cover health information exchange-specific scenarios.

Prepare notification processes. Have templates and contact procedures ready for patient notifications and OCR reporting. UPMC's approach - direct outreach plus a dedicated phone line - is a solid model regardless of your organization's size.

Brief leadership. This is not purely a technical issue. IT managers and CIOs should brief governance committees and executive leadership on the incident, the lawsuit developments, and any forthcoming ONC or OCR guidance on TEFCA enforcement. If enhanced logging or third-party monitoring requires budget, now is the time to make the case.

The Bigger Picture

Interoperability delivers real clinical value when it works as intended. A patient who shows up at your ER after a car accident 200 miles from home should have their medication list and allergy history available to the treating physician. That is worth building toward.

But the UPMC incident and the underlying lawsuit expose a structural vulnerability in how these frameworks operate. The trust model depends on self-policing and after-the-fact enforcement rather than proactive verification of every participant. Framework governance is catching up, but slowly.

Watch for developments in the Epic case (including GuardDog's pending judgment approval), potential TEFCA policy changes around participant verification, and additional OCR enforcement actions. ONC's HTI-5 proposed rule, published December 29, 2025, has proposed removing the TEFCA Manner Exception from the information blocking regulations. ASTP/ONC has stated that the exception was intended to incentivize TEFCA participation but has sometimes been misapplied. If finalized, removal would eliminate a safe harbor that some organizations relied on to limit certain exchanges, potentially shifting reliance to other exceptions such as infeasibility, privacy, or security. That proposed rule's comment period closed February 27, 2026; it is not yet final. The regulatory landscape around interoperability is actively shifting.

Health care IT teams cannot outsource risk management of these exchange networks to the frameworks themselves. The audit data lives in your EHR - turn it into protection by reviewing logs, setting alert thresholds, and updating your risk analysis and incident response processes now. Watch the ongoing Epic case, GuardDog's judgment approval, TEFCA governance changes, and OCR enforcement developments as this situation continues to evolve.

This remains a developing situation as of March 2026. Check official UPMC, Epic, and HHS sources for the latest patient notifications and regulatory updates.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.