Hey there, We’re Shivang & Tania. Each week, we write in plain English (and some sass) about how health insurance works, why claims get denied, and how patients and healthcare teams can get paid or reimbursed. If you’re new here, we recommend you start with RCM 101: How Healthcare Gets Paid, Eventually, Maybe

When a provider hits submit, the claim usually doesn't go straight to the insurer. It goes to a clearinghouse first, a sorting-and-inspection hub that checks the claim's data and routes it to the right payer. If something's malformed, the clearinghouse bounces it back before the insurer ever sees it. That's a rejection, and it's a data problem you fix and resend. A denial is different. A denial means the payer received the claim, ran it through its rulebook, and decided not to pay. One never got read. The other got judged. Treat them the same and you'll spend a week appealing a claim nobody at BHC has ever laid eyes on.

In this issue, we cover:

Sage has Biscuit's claim open in front of her, and it's a small monument to how much had to go right to get here.

Weeks ago, Dr. Singh, the poodle in the white coat, ordered Biscuit a hereditary cancer gene panel, because his maternal aunt had ovarian cancer at 46. Since then, this whole series has been the story of that one test earning its way onto a claim: proving it was medically necessary, getting the prior auth cleared, and then, last issue, watching Sage translate the visit into a wall of codes that finally agree with each other.

That's the claim on her screen now. Built, clean, every code in its place. There's exactly one thing left to do with it, and it's the one thing nobody ever explains. Sage has to send it somewhere.

Most people would guess she sends it to BHC. Most people would be wrong.

Here's the picture most people carry around: the doctor's office finishes your visit, types up a bill, and sends it to your insurance company, the way you'd email an invoice to a client. One sender, one recipient, done.

That's almost never how it works.

A clearinghouse is an intermediary that sits between providers and payers. It takes in claims from the provider side, checks and standardizes the data, and routes each claim to the correct insurer. Under HIPAA, the federal rule that standardized all this, a clearinghouse is defined by exactly that job: it takes health information in one entity's format and processes it into the standard format the receiving entity can read, and back again.

Picture an airport. You don't walk onto the plane straight from the curb. You go through a checkpoint first, where your bag gets scanned, and then you get routed to the right gate for the right destination. The clearinghouse is that checkpoint and that routing desk for claims. Sage hands over the claim, it gets inspected, and if it passes, it gets pointed at BHC's gate. If it fails the scan, it never reaches the gate at all. It comes right back to Sage.

Fair question. Adding a stop in the middle sounds like the kind of thing that makes healthcare slower, not faster. In this case the middle stop is what keeps the whole thing from collapsing.

Think about the wiring problem. There are hundreds of thousands of providers in the U.S. and hundreds of payers, and every one of them runs different software with its own quirks and requirements. Without something in the middle, every provider would need to build and maintain a separate technical connection to every insurer it bills. That's a tangle nobody wants to own. A clearinghouse collapses it.

To be clear, nothing forces a provider down this road. A practice can key claims straight into a payer's web portal, or wire up a direct connection to one big insurer it bills all the time, and skip the middleman entirely. Do that for every payer on your list, though, and you're back to maintaining a hundred separate connections by hand. So for most billing teams, the clearinghouse is the version of this that lets them sleep, and it's where the clear majority of electronic claims actually go.

You want to know how load-bearing these hubs are? On February 21, 2024, one of the largest, Change Healthcare, got hit by ransomware and went dark. It processed something like $2 trillion in claims a year, a big share of every medical claim in the country. When it went down, claims stopped. Per the American Hospital Association, 94% of hospitals reported financial disruption, and providers went weeks unable to get claims to payers at all. The clearinghouse most patients have never heard of turned out to be a place a huge fraction of the nation's claims quietly passed through every day. When it stopped, you could say the quiet part out loud: for a while, a lot of insurers genuinely never saw their members' claims.

To understand why a claim gets bounced at the checkpoint, you have to know what the claim actually is when it leaves Sage's system. It's tempting to imagine a nicely formatted bill, the kind of PDF you'd recognize. It isn't that.

The claim is structured electronic data. The standard format for a healthcare claim is called an 837. That's the shorthand for the standardized electronic transaction providers use to send claim information to payers, and HIPAA requires everyone to use the same one so a computer on the other end can read it instantly.

The gap between how Biscuit thinks about his care and how the 837 represents it is the whole reason claims break. Biscuit thinks: “I had a blood test.” The 837 doesn't have a field for that sentence. It has fields for the subscriber's member ID and date of birth, the provider's identifiers, the date of service, the diagnosis code, the procedure code, any modifiers, the charge, the place of service, and a stack of other required data elements. Every one of those has a required format. A test, to the system, is fifty little facts in fifty little boxes, and each box has rules about what's allowed inside It.

Here's what the checkpoint is actually doing while it holds your claim. It's scrubbing it.

Claim scrubbing is an automated pass over the claim that looks for problems before the claim moves on. The clearinghouse checks whether the required fields are present, whether the data is formatted correctly, whether the member and subscriber information is filled in, whether the provider identifiers look valid, whether the codes are shaped right, and whether the claim points at a payer it can actually reach. Some clearinghouses also apply payer-specific edits, small checks tuned to what a particular insurer is known to reject.

One thing the clearinghouse is not doing: deciding whether BHC will pay. It isn't judging medical necessity. It isn't reading Dr. Singh's notes or checking Biscuit's coverage. That comes later, and it has its own name.

The clearinghouse checks the shape of the claim. The payer judges the substance. Two different stops, asking two different questions.

So back to that REJECTED on Sage's screen. Here's what happened.

Biscuit changed insurance plans in January, and his new member ID has an extra character his old one didn't. The number Sage pulled forward was one digit short. Everything else on the claim was perfect. The codes agreed and the auth was on file. But a subscriber identifier that doesn't match the required format is exactly the kind of thing the checkpoint is built to catch, and it caught it. The claim couldn't be validated and routed, so it bounced. It never reached BHC.

Sage fixes it in about ninety seconds. She corrects the member ID, confirms it against Biscuit's new card, and resubmits. This time it passes.

Now sit with what just happened, because it's the lesson. Nothing about Biscuit's health changed. The test was just as necessary as it was five minutes ago. Dr. Singh's reasoning didn't change. The auth didn't change. BHC didn't decide anything, because BHC was never involved. The only thing wrong was one field, and the only thing that fixed it was correcting that field. The claim didn't get judged and found wanting. It got stopped at the door for having a typo on its ticket.

This is the distinction the whole issue is built around, so let's put the two side by side and be exact.

A rejection happens at the front end, before adjudication. The claim was malformed or incomplete, so it couldn't be accepted for processing. In plain English, the answer is “we can't process this yet.” The insurer, in most cases, never truly received it. There's nothing to argue, because no decision was made. You fix the data and resubmit. That's Biscuit's short member ID.

A denial happens after the payer has the claim in hand and runs it through adjudication. The insurer received it, reviewed it, and decided not to pay all or part of it as submitted. In plain English: “we processed this, and we're not paying it the way you sent it.” A denial comes with a reason, and depending on that reason, the next step might be a correction, medical records, a coding review, an authorization check, or a formal appeal.

Two claims that both read as unpaid on your screen, and the work each one needs has almost nothing in common. A rejection wants a corrected field and another send. A denial wants you to read the reason BHC gave and decide whether it's worth challenging. The terminology isn't perfectly uniform across every payer and system, and some vendors blur the line, but the operational difference is real and it matters.

Get this backwards and you lose. Treat a rejection like a denial and you'll open an appeal, gather records, and argue medical necessity for a claim BHC never received, while the clock runs. Treat a denial like a rejection and you'll keep resubmitting the same claim into the same wall, wondering why nothing changes.

Reasonable next question: if the claim bounced somewhere out in the middle, how does Sage even find out? She didn't watch it travel. She just saw one word.

Electronic claim workflows send answers back, in stages. Two of those answers are worth knowing by the plain-English job each one does.

The first check answers “did the batch even parse?” When Sage's software sends a file of claims, an acknowledgment called a 999 comes back saying whether the format was readable at all, or whether it was so malformed the whole batch got kicked.

The second answers the question Sage actually cares about: was my specific claim accepted or rejected? That's a claim acknowledgment, often called a 277CA, and it reports, claim by claim, which ones passed the front-end checks and which ones bounced and why. When a claim is accepted, that acknowledgment usually carries a claim number, the receipt that says “this one is really in.”

You can forget the numbers 999 and 277CA by tomorrow. Keep the one habit they add up to. Hitting submit is not the finish line. Somewhere in Sage's billing system there's a screen that shows these acknowledgments, and until she's seen an accept, she hasn't actually sent anything. Submitted and received are two different states, and only one of them counts.

Sage's corrected claim clears the checkpoint. It gets routed to BHC. And now, for the first time in this whole story, Biscuit's insurer is actually holding the claim.

Enter Otis, the French bulldog in the tan blazer, the payer's reviewer. He's the one who decides whether BHC pays. Everything we've covered in past issues starts here, at the moment of arrival: is Biscuit eligible, does his plan cover this test, was it authorized, do the notes support medical necessity, do the coding rules hold, is the lab in network, and what's Biscuit's share. That's adjudication, and we walked that hallway back in What Actually Happens to a medical claim?

Here's the part people miss. Clearing the clearinghouse felt like a win, and it was, but it's a narrow one. Acceptance means the claim successfully arrived and is well-formed enough to be judged. It does not mean BHC will pay a cent. All the clearinghouse said was “this is a real, readable claim, and it's addressed correctly.” Whether it gets paid is Otis's call, and it's a separate event entirely.

For provider, billing, and RCM teams, this is the difference between fixing a problem in ninety seconds and chasing it for a month.

You can't solve a failed claim until you know where it failed. A clearinghouse rejection and a payer denial live at different stops, they come back through different channels, and they call for opposite work. A rejection should never trigger a medical-necessity appeal, because there's no decision to appeal. A denial should never be met with a quiet resubmit, because the claim already arrived and got judged. When a team lumps both into one “didn't get paid” pile, it does the wrong work on half of them and burns days it can't get back.

Mostly you can't see the clearinghouse itself, and that's the honest answer. It almost never shows up by name on anything a patient gets. Your EOB won't mention it. Your bill won't either.

You can check the thing that actually matters, though, which is whether your insurer ever received the claim at all. Log into your insurance company's member portal and look at your claims list. If the visit is there with a claim number next to it, your insurer got it. It cleared whatever checkpoint stood in the way, and a decision was either made or is coming. If the visit is nowhere in the portal and the office swears it was submitted weeks ago, that's your signal the claim may have bounced before it ever arrived, and somebody needs to go find out why.

Sage has a sharper view than any patient does. Her clearinghouse gives her a status trail for every claim she sends: accepted at the clearinghouse, then accepted or rejected by the payer. The moment the payer's own claim number comes back to her, she knows the claim is really in BHC's hands, and not sitting in a rejection queue over a single wrong digit.

For patients, you don't need to run a billing department. You just need one better question. When someone tells you “insurance denied your claim,” a fair thing to ask is: was it actually denied by the insurer, or was it rejected before it got there? Those are different situations with different fixes, and knowing which one you're in tells you whether there's anything to appeal, or whether the office just needs to correct a field and resend. In case of an issue, ask three quick questions before you panic or pay anything:

We stayed on the road from submit to arrival on purpose. We didn't open up the full EDI machinery, the envelope segments, the TA1, or every acknowledgment transaction. We didn't cover the answer coming back with the money on it, the 835 or ERA, or how payments get posted. We skipped EOBs (Issue 17 has them), the deep mechanics of how Otis adjudicates, direct provider-to-payer connections that skip a third-party clearinghouse, clearinghouse pricing and contracts, and the full zoo of rejection reasons. Several of those are their own issue. Reply and tell me which one you want next.

Sage corrected one digit, and a claim that looked dead was alive again in under two minutes. Biscuit never knew any of it happened, which is honestly how it should be. But the thing worth carrying out of this issue is the thing he got wrong on the couch: clicking submit does not mean your insurer received your claim. Before BHC can decide whether to pay, the claim first has to actually reach BHC. There's a checkpoint in between, and plenty of claims quietly die there, at a stop that isn't printed anywhere on your insurance card.

That's it for this issue. Hit reply. I read everything.

At Converus, the reason we care about this line is simple: rejections and denials trace back to rules that live in different places, and teams lose real money treating one like the other. We keep those reimbursement rules in one current, readable place so the claim is right before it ever hits the checkpoint. See converus.ai.

A note on the workflow: The rejection-versus-denial distinction and the acknowledgment steps described here are the common electronic-billing workflow, and the clearinghouse definition is a legal one under HIPAA. Using a clearinghouse is common practice, not a legal requirement. Not every claim in the U.S. travels through a third-party clearinghouse; some providers submit directly through a payer's web portal or a direct connection, and terminology varies by payer and vendor. Biscuit's specific rejection (a member-ID format mismatch) is illustrative of a front-end rejection, not a statement of any real payer's edits. Always work from your own clearinghouse's and payers' current documentation.

Disclaimer: The content published by preimbursed (the "Newsletter") is provided for general informational and educational purposes only and reflects the opinions and commentary of the author. It does not constitute, and should not be relied upon as, medical, legal, financial, tax, insurance, or other professional advice. No physician-patient, attorney-client, fiduciary, or other professional relationship is created by reading the Newsletter or by corresponding with the author. The Newsletter is not a substitute for individualized advice from a qualified professional. Before making any healthcare, coverage, insurance, financial, or legal decision, you should consult your own physician, attorney, benefits administrator, or other licensed advisor and review your specific plan documents, policies, and applicable law. The author is not responsible for any action taken or not taken in reliance on the content herein, and you assume full responsibility for your use of the information provided. Information in the Newsletter is believed to be accurate as of the date of publication and is drawn from the sources cited. Laws, regulations, coverage rules, corporate ownership, market data, and other facts change frequently and may have changed since publication. Certain statements describe pending, recently enacted, or phased-in legal and regulatory changes whose scope, interpretation, and effective dates may shift. The author makes no representation or warranty, express or implied, regarding the accuracy, completeness, timeliness, or reliability of any content, and disclaims all liability for any errors or omissions to the fullest extent permitted by law. References to any company, organization, product, government program, or individual are made solely for purposes of news reporting, commentary, analysis, and criticism, and do not imply any endorsement, sponsorship, affiliation, or partnership. All trademarks, service marks, and trade names are the property of their respective owners and are used only for identification and descriptive purposes. Where a named party disputes a characterization or finding, the Newsletter notes that dispute. Statements concerning identified companies reflect cited reporting and the author's opinion and analysis of matters of public concern. Certain characters, organizations, and scenarios in the Newsletter, including but not limited to Biscuit, Dr. Singh, and composite payer and provider names, are fictional and used for illustration. Any resemblance to actual persons or entities is coincidental.

Disclosure: The authors are the co-founders of Converus.ai, a company that organizes payer policy information for healthcare providers, and therefore has a commercial interest in the subject matter discussed. References to Converus.ai are made only where relevant and are not paid placements. To the fullest extent permitted by applicable law, the author and preimbursed disclaim all warranties and shall not be liable for any direct, indirect, incidental, consequential, or other damages arising out of or in connection with your use of, or reliance on, the Newsletter.