You have probably been impacted by this healthcare data breach.
In February 2024, attackers entered Change Healthcare’s network through a remote access portal with no multi-factor authentication. They spent nine days moving through the system, exfiltrating protected health information, before triggering any alerts that something was very wrong. By the time the attack was contained, the data of approximately 190 million Americans had been taken. That is more than half the country.
You may have experienced it as a pharmacist who could not fill a prescription for days. As a patient who could not get a prior authorization approved. As a provider whose claims stopped processing and whose revenue cycle ground to a halt. The operational chaos was visible. The data exposure was invisible. All of it was a real nightmare.
The Architecture of the Payer/Provider Data Problem
Change Healthcare is not a provider. It is a clearinghouse. It processes payer and provider data flows for 15 billion healthcare transactions annually. One in three US patient records passes through its systems. That is the architecture of the modern payer/provider relationship. Sensitive patient data flows continuously across organizational boundaries. It touches clearinghouses, billing vendors, health information exchanges, and dozens of technology partners before a claim settles or a prescription fills.
Every one of those handoffs is a potential breach event.
Sharing patient data securely means protecting every one of those handoffs. Not just the data sitting in your database. Not just the data moving across your network. The data as it processes through every system in your revenue cycle. That is where the exposure lives. That is what the breach at Change Healthcare demonstrated.
Why Every Handoff Is a Decryption Event
The payer/provider data flow problem is structural. Claims require patient demographic data, diagnosis codes, procedure codes, and insurance information to move between providers, clearinghouses, and payers. Eligibility verification pulls member data from health plan systems in real time. Prior authorization workflows pass clinical documentation across organizational boundaries. Pharmacy benefit transactions touch pharmacy systems, PBMs, and health plans before a single prescription processes.
Every system in that chain must decrypt the data to do its job. Every decryption event is a window. An attacker who accesses any system in that chain during processing finds plain-text patient data. Social Security numbers. Diagnosis codes. Prescription histories. Insurance records. Data that cannot be changed or cancelled after exposure.
This is the encryption gap the industry has not closed. At-rest encryption protects the storage layer. It offers no protection the moment a clearinghouse, a billing vendor, or a health information exchange reads that data to do its job. The full explanation of why is in The Encryption At Rest Myth.
The Liability That Lands on Your Name
Change Healthcare’s parent company UnitedHealth Group incurred over $3 billion in direct breach response costs. That number does not include the multi-year litigation tail. It does not include the patient trust that does not appear on a balance sheet.
Patient trust is the asset healthcare organizations spend decades building. It disappears in a notification letter.
The liability does not follow the data through every system it touched. It follows the name the patient associated with their care. The hospital. The health plan. The physician practice. Not the clearinghouse they never heard of. Not the billing vendor their provider contracted with. The legal and regulatory exposure lands on the covered entity whose relationship with the patient began the data flow. The breach may have occurred three handoffs later.
The cost structure of that exposure is documented in How Much Does a Data Breach Cost? Healthcare averaged $7.42 million per incident in 2025. That is the average. Change Healthcare was not average.
What Sharing Patient Data Securely Actually Looks Like
There is a solution. Donoma Seshat solves this by keeping patient data encrypted not just at rest and in transit, but at every processing node in the chain.
Using this example, the clearinghouse would decrypt nothing. Same for the billing vendor, the health information exchange, and any other data stakeholder. Every system in the payer/provider chain runs its queries and returns its results against encrypted data. An attacker who breaches any of those systems finds ciphertext. There is nothing to ransom, nothing to notify, nothing to litigate.
The architecture that protects every handoff in the payer/provider chain is covered in detail in How to Share Sensitive Data Securely. The specific application to healthcare data flows works like this:
- Donoma Seshat keeps patient data encrypted not just at rest and in transit, but during active processing.
- A clearinghouse processing Seshat-encrypted claims data never holds a decryptable copy.
- A billing vendor running analytics on Seshat-protected patient records cannot extract readable data.
- An attacker who breaches any system in the payer/provider chain during processing finds ciphertext with no operational value.
Seshat deploys at the application layer without replacing existing payer or provider infrastructure. It runs on standard CPUs with no specialized hardware requirement. It operates at native speed, so payer/provider workflows and SLAs are not affected. And it is post-quantum ready, which matters in healthcare where patient data carries a long tail of sensitivity that extends well beyond the current threat landscape.
When patient data flows encrypted through every system in the chain, a breach anywhere in that chain changes character entirely. The attack may succeed at the access layer. It fails at the data layer. No notification obligation triggers. No class action plaintiff has damages to allege. The breach event happens. The breach damage does not.
The Question Worth Asking Before the Next Handoff
Change Healthcare was the largest healthcare breach in US history, so far. It will not be the last. Every organization in the payer/provider chain whose data flows through systems that decrypt for processing carries the same structural exposure. The scale will vary. The mechanism will not.
The question worth asking your security team and your legal counsel today is not whether your own systems are secure. It is what every system your patient data touches is doing with it during processing. If the answer is decrypting it, the exposure is not yours to control. Unless you change the architecture.
The technology is ready. The business case is clear. The time for action is now.
If you want to see how Donoma Seshat protects patient data across your payer/provider data flows, at native speed, on your existing infrastructure, without specialized hardware, book a solution briefing with the Donoma team.
Frequently Asked Questions
What makes payer/provider data flows particularly vulnerable to breaches?
Payer and provider data flows require patient data to move continuously across organizational boundaries and through multiple processing systems. Every handoff, every eligibility check, every prior authorization request, every claims transaction requires the data to decrypt at some point for a system to read and act on it. That decryption window exists at every node in the chain. An attacker who accesses any of those systems during processing finds readable patient data regardless of how secure your own systems are.
Why did the Change Healthcare breach affect organizations that were not breached themselves?
Change Healthcare processes approximately 15 billion healthcare transactions annually. One in three US patient records passes through its systems at some point. When the breach occurred, the patient data of providers, health plans, and patients who had no direct security failure of their own was exposed because it flowed through Change Healthcare’s systems for processing. The breach at the clearinghouse became a breach event for every organization whose data it touched.
What is the patient trust liability from a healthcare data breach?
Patient trust is built on the expectation that health information shared in the context of care stays protected. A breach notification letter destroys that expectation. Patients cannot undo the disclosure of their diagnosis codes, prescription histories, Social Security numbers, or insurance records. The trust damage is permanent for many patients. Legal liability follows through class action litigation. Regulatory liability follows through OCR investigations. Reputational damage follows through coverage and patient attrition that does not appear on an incident response invoice.
How does sharing patient data securely change the payer/provider breach liability picture?
When patient data moves through a payer/provider chain encrypted and stays encrypted during processing at every node, a breach at any point in that chain yields ciphertext with no operational value. There is nothing to ransom. No notification obligation triggers. No class action plaintiff has damages to allege. The liability picture changes fundamentally because the breach event no longer produces a usable dataset. The attack succeeds at the access layer. It fails at the data layer.
Does encrypting data during payer/provider processing affect claims processing speed or SLAs?
No. Donoma Seshat operates at native speed with no latency penalty on encrypted transactions. Payer and provider workflows run as they always have. Claims process on schedule. Eligibility checks return results in real time. Prior authorization workflows move at operational speed. The encryption operates below the application layer. Authorized systems and users experience no change. What changes is what an attacker finds if they breach any system in the chain: ciphertext with no value.
What data is typically exposed in a payer/provider breach?
Payer and provider data flows carry some of the most sensitive personal information that exists: Social Security numbers, dates of birth, diagnosis codes, procedure codes, prescription histories, insurance member IDs, bank account information for payment processing, and clinical documentation submitted for prior authorization. Unlike a compromised password or credit card number, this data cannot be changed or cancelled. A patient whose diagnosis history and Social Security number have been exposed carries that liability permanently.
Additional Reading:
How to Share Sensitive Data Securely
Medtronic and the Healthcare Encryption In Use Gap
Protecting Patient Data During Processing: What HIPAA Won’t Require — But You Should
