eClinicalWorks Denial Appeals: The Module Is Installed, the Routing Is Not

Most practices running eClinicalWorks do not have a denial tooling problem. The platform ships a denial management module that works denials from the electronic remittance advice, creates appeals and tracks follow-up dates. It is there, it is configured, and in a great many practices it is barely used.

What is usually missing is one step earlier and much less visible: routing. And the reason routing fails is that most workflows key on the wrong field in the remittance.

I work on the integration side, which means I spend more time reading remittance files than talking to billers, and this is the pattern that shows up in the data every time. If you want the wider context first, denial management covers the general discipline and the 13 steps of the revenue cycle are the plainer orientation.

CARC and RARC Do Different Jobs

Two code types arrive on a remittance and they are not interchangeable.

A Claim Adjustment Reason Code is the standardized financial reason for an adjustment or denial. It answers why the payment differs from what you billed, in the payer’s accounting terms.

A Remittance Advice Remark Code carries the narrative detail. It answers what specifically was wrong, and it frequently names the policy, coverage determination or documentation requirement the payer applied.

The CARC is the category. The RARC is the case.

That distinction matters more than it sounds, because the CARC alone is often not actionable. Take CO-16, one of the most common denials in circulation. It means the claim lacks information. That is true, unhelpful, and shared by an enormous range of unrelated problems.

Why Routing on the CARC Breaks the Queue

Here is the concrete version, and it is the clearest illustration I know of.

Two claims come back with the same CARC, CO-16. One carries a RARC indicating a missing rendering provider identifier. The other carries a RARC indicating incomplete or invalid information of a different kind.

Same CARC. Completely different problems. One is an enrollment or claim-header data issue that a billing operations person fixes in minutes and that will recur systematically until the underlying record is corrected. The other may require documentation, a coding review or clinical input.

Different cause, different team, different fix, different realistic turnaround.

Route on the CARC and both land in the same queue, assigned to the same person, with the same service level. The fast one waits behind the slow one. The systematic one gets fixed claim by claim instead of once at the source. And the queue as a whole moves at the speed of its hardest item.

That is not a staffing problem and it will not respond to more staff. It is a sorting problem, and the information needed to sort correctly arrived with the remittance and was discarded.

The RARC Is Also Your Appeal’s Evidence

A second reason to key on the RARC, and it changes what an appeal costs to produce.

RARCs frequently name the specific policy, coverage determination or documentation requirement the payer relied on. That is not just diagnostic information. It is the thing your appeal has to answer.

An appeal that argues generally about medical necessity is a letter. An appeal that identifies the exact determination cited, addresses its criteria point by point, and attaches the documentation those criteria call for is an argument. The second wins more often and takes less time to write, because the payer has already told you what they applied.

Which means the RARC does double duty: it is the routing key that sends the denial to the right team, and it is the outline of the response that team has to produce. Discarding it costs you twice.

Practically: appeal templates should be keyed to RARC rather than to CARC. A template per CARC is a generic letter. A template per RARC is a response to a specific determination with the required elements already structured.

Separating the Systematic from the One-Off

Once denials are grouped by RARC rather than by CARC, a distinction appears that was previously invisible, and it is the highest-value thing routing gives you.

Some RARC groups are systematic. They recur because a single upstream fact is wrong: a provider record, an enrollment detail, a chargemaster entry, a payer-specific rule that nobody encoded. Every claim in the group fails for the same reason, and each one gets corrected individually, forever, until somebody notices the pattern.

Others are genuinely case-by-case. Documentation varies, clinical circumstances vary, and each needs its own judgment.

Routing on the CARC hides the difference, because a systematic group and a scattered one look identical when they are mixed into a single queue with everything else sharing that adjustment code.

The test is concentration. Sort a RARC group by whatever upstream attribute might explain it: rendering provider, location, payer plan, service line, date range. If the denials cluster hard on one value, you have a systematic cause and the fix belongs at the source rather than in the queue. If they spread evenly, they are case work.

This is worth doing before any automation decision, because the two categories want different responses. A systematic group wants one correction upstream and a pre-submission edit so it stops recurring, which is claims processing configuration work. A case-by-case group wants better templates and faster handling. Automating the first is fixing a symptom at scale.

What an Aging Queue Turns Into

The consequence of poor routing is not primarily that denials get worked slowly. It is what happens at the end.

Denials that sit in an undifferentiated queue age. Aging denials eventually cross a payer’s timely filing limit, and at that point they stop being denials that are hard to work and become claims that cannot be recovered at all. There is generally no substantive appeal right against an untimely denial, which makes it the one failure in the revenue cycle with no route back. Days in AR and timely filing cover why that deadline behaves differently from every other one.

So the sequence runs: route badly, queue undifferentiated, small and systematic items buried behind complex ones, aging, deadline, permanent write-off.

And the write-off improves your days in accounts receivable, because the claim leaves receivables entirely. The metric gets better as the loss becomes final.

That is the real cost of routing on the wrong field, and it does not show up as a routing problem in any report. It shows up as write-offs, months later, attributed to something else.

What This Looks Like as a Build

The capability sits in three parts, and the first is smaller than people expect.

1. Parse the RARC, not just the CARC. Both arrive in the electronic remittance advice. Most posting logic captures the CARC because it drives the financial adjustment and treats the RARC as commentary. Capturing it as a structured, queryable field is the enabling change and it is not a large one.
2. Route on the pair. A worklist assignment derived from CARC plus RARC together, mapped to a team and a service level. This is a lookup table plus rules, maintained as data rather than encoded in someone’s habits.
3. Write the status back where the work happens. This is the part that determines whether any of it gets used. A routing decision that lives in a separate dashboard is a report. The same decision reflected in the work queue the biller already opens is a workflow. If a claim has been triaged, re-triaged or resolved, the queue the team actually looks at has to show that, or two people will work the same denial and nobody will trust the tool.

The engineering caution, from the side that has to do it: connecting to an EHR to read remittance data is well-trodden. Writing status back into a work queue reliably, in a way that survives the vendor’s next upgrade and does not collide with a human editing the same record, is the part that takes the time. eClinicalWorks specifics matter here in ways a generic integration plan will not anticipate, and our eClinicalWorks integration and eClinicalWorks FHIR capabilities pages cover the connectivity layer underneath. Anyone describing the write-back as routine has not shipped one.

Five Checks Before Your Next Denial Review

In the order I would run them.

1. Ask whether your remittance posting captures the RARC as a structured field, or only the CARC. If only the CARC, everything else on this list is blocked and this is the fix.
2. Pull your top five CARCs by volume and break each down by RARC. Expect at least one to split into several unrelated problems. That split is your routing map.
3. Check whether any of those RARC groups is systematic, meaning it recurs from a single upstream cause. Those get fixed once at the source rather than repeatedly at the claim.
4. Look at how long your oldest open denials have been sitting, and compare against your shortest payer filing limit. This is the check that finds money about to disappear.
5. Ask whether appeal templates are keyed to CARC or RARC. CARC-keyed templates produce generic letters; RARC-keyed templates respond to the determination the payer actually cited.

For the wider picture, how to improve revenue cycle management covers measurement discipline, insurance eligibility verification covers the upstream cause of a large share of what lands in these queues, and claims processing configuration is where pre-submission edits would prevent some of it arriving at all. If the conclusion is to hand the work over, outsourcing revenue cycle management covers where that line falls, though an outsourced team working an unrouted queue inherits the same sorting problem you have.