Clean claim

Clean is a source-defined processing state

The CMS Uniform Glossary defines a claim as a request to a health insurer or plan for a benefit, including reimbursement for an expense. It also warns that glossary definitions can differ from plan terms and that the policy or plan governs when they conflict.

CMS's current Medicare billing course gives a narrower program example: a Medicare clean claim does not require a Medicare Administrative Contractor to suspend it for external prepayment investigation or development. That definition does not establish the rule for another payer.

For each route, record the controlling clean-claim source, the entity and products it covers, effective dates, version, required fields or attachments, response evidence, and update owner. State prompt-payment law, payer manuals, contracts, and program rules can use different definitions and consequences. Route legal interpretation to counsel.

Practice readiness and payer clean status differ

A practice can define an internal release-ready state. The payer controls any payer-assigned clean status. Keep both timestamps and owners rather than labeling an unsubmitted claim clean.

Completeness is contextual. A field can be populated and still conflict with the clinical record, authorization, enrollment, or payer rule. A blank field can also be valid when the applicable source says it is unused.

Clinical and billing work keeps separate authorship

The clinician records the care, clinical decisions, and any permitted correction within scope. A qualified coding or billing reviewer maps verified evidence to the current claim requirements. Operations confirms administrative sources and release gates. Software may surface omissions, inconsistent dates, expired evidence, and unresolved rules, then place the claim on hold.

Software should not invent clinical facts, rewrite a record, select a code from an authorization alone, or call a claim clean before payer evidence supports that state. Preserve the source record, submitted claim, acknowledgments, corrections, remittance, and deposit trail.

The CMS Administrative Simplification page explains that covered entities conducting electronic administrative transactions must follow adopted standards for formats and content. Those standards do not replace payer coverage, contract, authorization, or documentation rules.

Follow every claim through distinct stages

The CMS electronic billing overview describes electronic data interchange as transfer in a specified format and notes that a clearinghouse or billing service may sit between a provider and payer. Transmission proves that data left one party. It does not prove payer receipt, clean status, or adjudication.

Track at least these states:

1. source records reviewed and internally release-ready
2. transmitted through a named route
3. clearinghouse or intermediary result received
4. payer claim-level intake result received
5. payer clean, development, or other pre-adjudication state recorded when supplied
6. adjudicated, including payment and adjustment decisions
7. remittance matched to the submitted claim
8. funds deposited and reconciled when payment is due

CMS's electronic health care claims guidance describes front-end and claim-processing edits in Medicare. Other receivers can use different artifacts and sequences. A clearinghouse acceptance cannot stand in for a payer result.

After Medicare processes a claim, CMS says an ERA or standard paper remittance reports adjudication and adjustment information. A payment transfer is a separate financial event. A clean claim can still receive a coverage denial or adjustment because clean status answers a processing question rather than the final benefit or payment question.

A fictional queue shows the denominator at each stage

A fictional ABA practice reviews 20 claims whose internal release decision is due. Seventeen pass all current gates, so internal release yield is 17 of 20, or 85%. Three remain held with a reason, owner, next action, and age.

All 17 are transmitted. The clearinghouse's proprietary claim-level report marks 16 as forwarded and one as rejected, producing a clearinghouse forwarding yield of 16 of 17, or 94.1%. The practice does not derive this claim denominator from a transaction-set acknowledgment.

The payer accepts 15 of the 16 forwarded claims into adjudication and rejects one. Payer-intake yield is 15 of 16, or 93.8%, while original-queue-to-payer-intake yield is 15 of 20, or 75%.

At the defined maturity date, this fictional payer marks 13 of the 15 accepted claims clean and requests development on two. Payer clean rate is 13 of 15, or 86.7%. Later adjudication produces payment amounts on 10 and denial results on three of those 13. Clean status predicted neither coverage nor payment. Every held, rejected, developing, denied, and unpaid item stays visible in its own state.

Measure clean claims without hiding unresolved work

Useful measures include internal release-ready claims divided by claims due for review; payer-designated clean claims divided by accepted claims whose clean-status window has matured; development requests divided by mature accepted claims; and first-pass adjudication yield divided by mature submitted claims. Report local holds, intermediary rejects, payer-intake rejects, adjudicated denials, adjustments, remittances, and unreconciled payments separately.

For every measure, define the source, event, numerator, eligible denominator, response or maturity window, exclusions, payer, product, claim route, service-date range, and workflow version. Preserve counts beside percentages. Segment recurring defects by source field, clinical or administrative owner, payer rule, provider, site, code, authorization, attachment, clearinghouse, and correction path.