RCM and Healthcare Automation Glossary | CercaLabs

Insights › Glossary

Glossary

The vocabulary, in plain language

Twelve terms that come up in every automation conversation and have almost no straight explanation online. Written for someone who has to make a decision, not for someone studying for a certification.

Denial vs. rejection CARC RARC Prior authorization Clean claim rate Remittance advice Timely filing BAA Safe harbor de-identification Expert determination Limited data set Attended vs. unattended

Group one

Revenue Cycle

Denial vs. rejection

The distinction that wastes the most time

A rejection never entered adjudication. It failed a format, eligibility or data check on the way in, and can usually be corrected and resubmitted. A denial was adjudicated and refused, which means it needs an appeal rather than a correction.

Treating them the same is one of the most common sources of wasted effort in a billing operation. Rejections are a data problem you fix upstream; denials are a policy argument you have to make with evidence. Any workflow that routes both into one queue is guaranteeing that the cheap fixes wait behind the expensive ones.

CARC

Claim Adjustment Reason Code

The standardized code a payor uses on a remittance to say why the amount paid differs from the amount billed. It is the primary signal for what happened to a claim and whether anything can be done about it.

In practice a short list of codes accounts for most of the recoverable dollars in any given organization, and which codes those are varies by payor mix and service line, which is why generic industry benchmarks are close to useless for triage. Score against your own outcomes instead.

RARC

Remittance Advice Remark Code

A supplementary code that qualifies a CARC. It carries the specific detail the reason code leaves out.

The pair matters more than either code alone. The same reason code with two different remark codes can mean “send the documentation” or “this is never payable,” and a triage rule built on the reason code alone will route both identically. When we classify denials on ingest, we classify on the pair.

Prior authorization

Also pre-auth, precert

A payor’s requirement that a service be approved before it is delivered, or it will not be covered. Straightforward as a definition, and almost entirely non-standard in practice.

What varies between payors: which services require it, what documentation counts as sufficient, how the request must be submitted, how long a decision takes, how long an approval remains valid, and whether a retroactive request is entertained at all. That variation, not the concept, is why the work is expensive, and why it responds so well to automation. What we automate.

Clean claim rate

First-pass yield

The share of claims that are accepted and adjudicated on first submission, with no correction, resubmission or appeal.

The most useful single number for judging whether automation will pay off, because every point of improvement removes downstream work rather than speeding it up. Be careful comparing it across organizations, definitions differ on whether rejections count, and a favourable definition can move the figure several points without anything changing.

Remittance advice

Electronic or paper

The statement a payor sends explaining what it paid, what it did not, and why. It is the raw material for all denial work.

The electronic version is structured and parseable. The paper version is not, and most organizations still receive both, which is why “we will automate denials once the data is clean” is a plan that never starts. Normalizing both into one denial record is part of the work, not a prerequisite for it.

Timely filing limit

The clock you cannot argue with

The window in which a claim or an appeal must reach the payor. Miss it and the money is gone regardless of the merits.

This is why a bad automated appeal is worse than no appeal: submitting boilerplate that gets refused can consume the window that a properly documented appeal needed. It is also the strongest argument for triage automation, since the cost of a slow queue is not delay but forfeiture.

Group two

Patient Data & Privacy

These four come up whenever a security review meets an automation project. They are worth knowing precisely, because the difference between them is often the difference between a project that clears review and one that does not.

BAA

Business associate agreement

The contract that makes a vendor legally accountable for protected health information it handles on your behalf. Without one in place, a vendor should not be touching PHI at all.

Worth understanding: a BAA is a property of the arrangement, not of the software. The same tool can be usable under one agreement and unusable under another, which is why asking “is this product compliant?” rarely produces a useful answer. Ask who has signed what. Our positions.

Safe harbor de-identification

The eighteen identifiers

One of two recognized routes to de-identifying health data: remove a specified list of eighteen categories of identifier (names, dates more precise than a year, geographic detail below state level, record numbers and the rest), and the data is no longer treated as PHI.

It is a checklist, which makes it predictable and reviewable, and also blunt: stripping all dates can destroy the clinical meaning a workflow needed. The engineering problem is removing identifiers while preserving the sense of the record. How we do that in production.

Expert determination

The other de-identification route

Instead of a checklist, a qualified expert assesses and documents that the risk of re-identification is very small, allowing you to retain data elements safe harbor would require you to strip.

More flexible and more expensive. It is the right route when the analysis genuinely needs precise dates or geography, and the wrong one when someone is reaching for it to avoid the discipline of the checklist. If a vendor proposes it, ask who the expert is and to see the determination.

Limited data set

The middle ground

Data with direct identifiers removed but some elements retained, typically dates and limited geography. It is still protected health information, and it still requires an agreement governing its use.

The common mistake is treating a limited data set as though it were de-identified. It is not, and the obligations that come with it are real. Where a workflow can run on a genuinely de-identified set instead, that is usually the cheaper path through review.

Attended vs. unattended automation

Who is in the chair

Attended automation runs inside a person’s session, using their credentials, while they are working. Unattended runs on its own schedule under its own service account.

Unattended scales better. Attended clears security review faster, because it introduces no new credential and no new data path, which is why we usually start there and move workflows to unattended once they have earned trust. That sequencing is a compliance decision as much as a technical one.

Missing something?

Ask And We Will Add It

If a term you deal with weekly is not here, it probably belongs here. Tell us which one and we will write it up, and if it is blocking a decision you are making now, thirty minutes is faster than waiting for the entry.

Book a teardown