TL;DR: eClinicalWorks denial management fails when it treats every denial as a one-off. Most repeat denials in eCW come from setup: a payer record, a provider profile, an encounter template or a claim edit that rebuilds the same error on every new visit. Sort three months of denials by reason code. Any code that leads the list every month points to a setting, not a claim.
The denial queue looked shorter last month. Then the same reason codes came back, attached to different patients and different dates of service, and the team started over. Most eClinicalWorks denial management runs this way, one claim at a time, and it can keep a biller busy for years without moving the denial rate at all. Practices that get out of the loop stop asking how to fix each denial and start asking which piece of their eClinicalWorks billing setup keeps producing it.
Repeat denials come back because the correction happens on the claim, and the claim is the last thing eCW builds. Every claim starts as stored setup. The patient's insurance record decides which payer and plan the claim maps to. Provider and facility records supply the rendering and billing identifiers. The fee schedule prices the line, the encounter template suggests the codes and modifiers your providers usually pick, and any claim edits running in eCW or your clearinghouse decide which claims stop before submission.
When a claim denies, a biller opens that one claim, corrects it and resubmits. It pays, the work queue shrinks and the day looks productive. The insurance record, the provider profile or the template that produced the error stays exactly as it was, so the next visit builds the same claim and the payer denies it for the same reason. Meanwhile, the setting that would end the cycle sits in a screen the biller rarely opens and often lacks the rights to change.
Timing makes it worse. MGMA has noted that new coding guidance each January brings a spike in denials, partly because payer systems have not caught up, and practice leaders also tie denials to registration errors after an EHR change. Its 2023 DataDive practice operations data put the single-specialty rate of claims denied on first submission at 8 percent. A share of every practice's number is denials its own setup keeps recreating, and no amount of claim-level rework touches that share.
The reason code tells you which part of the claim the payer rejected, and that points to the part of eCW that built it. This table maps the codes that recur most often to where they usually start and who owns the fix.
|
Reason code |
What the payer is saying |
Where it usually starts in eCW |
Who owns the fix
|
|---|---|---|---|
|
CO-16 with a remark code |
Information is missing or invalid |
The patient's registration or insurance record, or a provider profile field |
Front desk or billing setup |
|
CO-22 or CO-109 |
Another payer is primary, or this payer does not cover the claim |
An insurance record mapped to the wrong payer or plan, or coverage order never updated |
Front desk at check-in, billing for the mapping |
|
CO-27 |
Coverage ended before the date of service |
Eligibility not rechecked when the patient returned |
Front desk workflow |
|
CO-4 or CO-11 |
The modifier or diagnosis does not fit the procedure |
Encounter template defaults, or a claim edit that no longer matches payer policy |
Your coders for code choice, billing for the edit |
|
CO-97 |
The payer bundles the service into another one |
Claim edits not updated for current bundling rules |
Billing, with coders on the documentation |
|
CO-29 |
Timely filing has expired |
Claims held in a work queue or rejected at the clearinghouse and never resent |
Billing workflow |
|
Rendering provider remark codes, such as N290 |
The rendering provider's identifier is missing or invalid for this payer |
A provider profile that does not match enrollment, or an enrollment that never finished |
Billing setup, or credentialing |
Two rows on that list never close at the claim. A CO-27 ends at the front desk, and a rendering provider denial often ends in an enrollment problem, the pattern behind the M115 denial code as well.
Before anyone corrects a denial that has shown up before, run it through these five questions.
A denial that fails the first check deserves an hour of investigation, because that hour pays back on every future claim the same setting would have broken.
The difference between billing models shows up most clearly on the second occurrence of a denial, when someone has to decide whether to rework it or trace it.
|
In-house biller |
Offshore vendor |
HRG
|
|
|---|---|---|---|
|
Repeat denials |
Traced when someone has time to dig |
Claim corrected, setting left in place |
Worked by reason code and traced to the eCW setting behind it |
|
Access to eCW setup |
Full, between other duties |
Often limited to exports or a separate platform |
Inside your eCW instance and payer portals with the access you grant |
|
Denial response |
When the queue allows |
Batch cycles across time zones |
24 to 48 hours |
|
A/R reviews |
Whoever is available |
Summarized by an account manager |
Weekly and monthly, by the billers doing the work |
|
Team |
Your staff |
Offshore |
100 percent U.S.-based |
Test the first row with any billing team you already have or are considering.
We work directly inside your eClinicalWorks instance and payer portals, with no separate dashboards, no PDF reports and no offshore handoffs. Our U.S.-based billers respond to every denial within 24 to 48 hours and group what comes in by reason code. When a code repeats, they trace it to the payer record, provider profile, template or claim edit behind it and work with your team to correct it there. HRG configures clearinghouse connections and EHR encounter forms inside your existing eCW, so the fix lands where eCW builds the claim.
98 percent: HRG's first-pass claim acceptance track record, confirmed by our CFO.
Coding stays with you. HRG provides coding consultation as needed and does not perform coding, so when a pattern traces to code or modifier choice, our billers bring it to your coders with the denials that show it. The same billers run weekly and monthly A/R reviews with your team, which is where a recurring reason code gets a name and an owner. Practices commonly see denials fall 15 to 30 percent and A/R shrink by 15 to 25 days, and the approach draws on over 26 years of medical billing services run inside the systems practices already own.
If the same reason codes keep leading your eCW denial report, book a billing strategy call with Andy Garcia or call 913-937-2995. He will walk through your denial patterns using your own numbers.
A practice that sorts its denials by reason code usually finds that a handful of settings account for most of the rework. Andy can show you which ones on a short call, with your last three months of remits on the screen. No pitch, no pressure. Book a billing strategy call with Andy or call 913-937-2995.
It depends on the reason code. Missing or invalid information, such as a CO-16 with an MA130 remark, goes back as a corrected claim. Medical necessity and coverage decisions go through the payer's appeal process, and downcoding has its own path, laid out in our breakdown of the CO-186 denial code. HRG sorts each denial into the right path before working it.
Your practice controls who can edit payer, provider and template settings in eCW. HRG works with the access you grant, corrects what falls inside billing setup and flags anything that needs your administrator or your coders.
Claims built after the fix go out clean, so the pattern stops on new visits right away. Denials already in the queue still need working. HRG does not promise a timeline for your numbers, because they depend on what your current A/R holds.
Yes. Cardiology and podiatry each carry their own modifier, documentation and frequency rules, so the templates and edits behind their denials differ too. See how HRG runs eClinicalWorks billing for cardiology and eCW for podiatry.
A reason code that comes back every month is your eCW telling you which setting to open. Read it that way, and denial management stops being a queue and starts being a short list of fixes.