Billing & RCM

Where claims come from

A claim is born when a clinician signs off — which means most billing problems are really documentation problems, upstream.

6 min · Billing & RCM, Administrators · lesson v1

This is a short lesson with one idea in it: you do not make claims here. They arrive, already formed, from something a clinician did.

The moment a claim is born

At sign-off a clinician ticks five confirmations and attests to codes. The card they are looking at says what happens next:

Clinician attests codes. On Sign & Finalize the system will capture charges, generate a correct X12 837P (professional claim format), and submit via clearinghouse abstraction to the patient's payer (Medicare or commercial).

Press it and the visit produces ✓ Billed & submitted with a claim number, status, total and a View 837P EDI preview expander.

That claim then appears in your Revenue Cycle list. Nobody in billing typed anything.

What that means for your queue

  1. Every field on a claim traces to something upstream:

    On the claimCame from
    The CPT and ICD codesWhat the clinician attested at sign-off
    The E/M levelThe clinician's choice between two levels, defaulting low
    The documentation supporting itThe signed note
    Coverage and payerRegistration and the eligibility check at the desk
    The provider NPIAdmin → Providers

    Screenshot pending capture

So a recurring denial is a recurring upstream behaviour. Three worth knowing:

  • Codes not supported by the note. The system defaults to the lower E/M level precisely to avoid this; a clinician raising the level without the documentation produces exactly this denial.
  • Coverage wrong at registration. The member ID typed at a kiosk and never checked against the card is the classic. The desk lesson on eligibility covers it.
  • No eligibility verification. When the real-time check was unavailable, the claim is assembled anyway with a warning saying so. Those claims are more likely to come back.

What is honestly simulated

Some of this pipeline is real and some is scaffolding, and you should know which:

  • The 837P format is genuinely generated and previewable
  • The clearinghouse is an abstraction — the sign-off message says (mock CH) in a demo, and a real deployment routes via a clearinghouse to the payer's EDI gateway
  • Eligibility is real when the practice is on a production Availity plan with a signed BAA; otherwise the sandbox returns active coverage for anything

What usually goes wrong

Looking for a claim-entry screen. There isn't one, by design.

Treating every denial as a one-off. Count them by cause before you rework the next one.

Assuming the codes were checked. They were attested by a clinician, which is a legal statement, not a validation.

Quoting coverage from a sandbox eligibility result. Read the banner.

Check yourself

No score, no account — just make sure you can answer these before you move on.

  1. Why is there no "create a claim" button anywhere in billing?

    Show the answer

    Because claims are not created in billing. They are generated at clinician sign-off from the codes the clinician attested plus the encounter's demographics, coverage and NPI. The empty claims list says it: Finalize billing on an encounter to create one.

  2. You keep seeing denials for the same code. Where is the fix?

    Show the answer

    Almost certainly upstream. The code came from an attestation at sign-off, the documentation supporting it from the note, and the coverage from registration. Reworking each denial treats the symptom; the fix is a conversation with whoever is producing them.

  3. What does it mean when a claim was assembled without a successful eligibility check?

    Show the answer

    Exactly what the warning says — the real-time check was unavailable and the claim went out without payer verification. It is a flag that this claim is more likely to come back, not a fault in the claim itself.