Skip to main content
A clearinghouse is an intermediary that receives claims from providers, validates and translates them into the format each payer expects, routes them to the right payer, and returns acknowledgments and remittances.

​
Why they exist

In principle, HIPAA standardized healthcare transactions: everyone uses X12 837 for claims, 835 for remittances, 270/271 for eligibility. In practice, “we support the standard” still yields payer-by-payer variation. Each payer has its own companion guide specifying how it interprets optional fields, which situational elements it requires, what identifiers it expects, and how it wants files delivered. Each payer has its own connection method, its own submitter enrollment process, its own edits, and its own quirks. A practice contracting with fifteen payers would otherwise need fifteen connections, fifteen enrollment processes, fifteen sets of format rules, and fifteen monitoring endpoints. A clearinghouse replaces them with one connection.

​
What a clearinghouse actually does

Enrollment support is the most underrated criterion. The claim-transmission function is close to commoditized. The part that costs a new group months is getting EDI, ERA, and EFT enrolled across every payer, and clearinghouses differ enormously in how well they handle it. Weight it heavily when choosing.

​
Payer IDs

Each payer has an identifier the clearinghouse uses for routing. Payer IDs are clearinghouse-specific — the same payer can have different IDs at different clearinghouses, and separate IDs for professional versus institutional claims. This is why switching clearinghouses requires remapping every payer in your system, and why a claim can reject as “payer not found” when the ID was fine at your previous vendor. Every clearinghouse publishes a payer list; treat it as the canonical source. See Payer enrollment and submission links.

​
Batch-era vs API-era

Two generations coexist: Batch/legacy. Built on SFTP file drops and scheduled processing. You upload a batch of claims, wait, and download responses. Portal-first, with an API added later, if at all. This describes most incumbent clearinghouses. API-first. Built around real-time REST/JSON endpoints, with X12 available for compatibility. Eligibility returns synchronously; claims and remittances are retrievable programmatically; everything the portal does is available to code. The distinction matters if you intend to build anything, such as automated eligibility at scheduling, denial analytics, per-entity dashboards across a multi-PC group. With a batch-era vendor, that work means screen-scraping or manual export. With an API-first vendor, it is an integration.

​
Do you get to choose?

Often you do not. Many EHRs embed a clearinghouse and make it difficult or impossible to use another. Ask before you sign the EHR contract, not after. Confirming that an EHR permits your choice of clearinghouse, and getting that in writing, is far easier than changing clearinghouses later, which means remapping every payer, re-enrolling EDI and ERA across your whole payer list, and running parallel for a period.

​
The 2024 clearinghouse outage

On February 21, 2024, one of the largest clearinghouses in the country discovered it had been compromised by ransomware. Attackers had accessed its systems from February 17, reportedly through a Citrix remote access service that lacked multi-factor authentication. The company took its systems offline.1 The incident showed the risk of routing a large share of claims through one vendor. The clearinghouse processed a very large share of US medical claims, serving hundreds of thousands of physicians, tens of thousands of pharmacies, and thousands of hospitals and labs. An American Hospital Association survey of nearly 1,000 hospitals in March 2024 found 74% reporting direct patient care impact, including delays in authorizations for medically necessary care.2 Practices could not submit claims, could not receive remittances, and in many cases could not verify eligibility. Cash flow stopped for weeks. The parent company ultimately confirmed a $22 million ransom payment, and the data of an estimated 100 million individuals was affected.3 What it revealed:
  1. Concentration risk is real and it is systemic. A single vendor’s outage stopped revenue for a meaningful fraction of American healthcare.
  2. Most practices had no contingency. No secondary clearinghouse, no paper fallback, no cash reserve sized for a multi-week revenue interruption.
  3. Basic security practice mattered. The reported entry point was a remote access service without MFA.
What to do about it:
  • Hold cash reserves sized to survive several weeks with no collections. This is the single most effective mitigation.
  • Know your fallback before you need it: which payers accept direct submission or portal entry, and whether a secondary clearinghouse could be stood up.
  • Ask vendors about incident history and security posture during selection, and read their SOC 2 report.
  • Keep your data portable. If your claim and remittance data is only inside a vendor’s portal, you cannot move.

​
Sources

  1. HIPAA Journal, Change Healthcare Responding to Cyberattack; Congressional Research Service, The Change Healthcare Cyberattack.
  2. American Hospital Association, Change Healthcare Cyberattack Underscores Urgent Need to Strengthen Cyber Preparedness.
  3. IBM, Change Healthcare discloses USD 22M ransomware payment.
Last modified on September 3, 2026

Related topics

Clearinghouse vs RCM vs EHR (vs biller)EDI and X12, gentlyThe life of a claimSet up EDI, ERA, and EFT with each payer