> This page is for Revenue Guard.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://revenue-docs.creliohealth.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://revenue-docs.creliohealth.com/_mcp/server.

# How Revenue Guard works

Revenue Guard classifies incoming lab orders against payer-specific rules before your downstream billing workflows begin. The goal is to catch coding, coverage, and documentation problems early — while an order can still be corrected — instead of after a claim is denied.

## The pipeline

#### Rules are built from payer policies

You add payers and upload their policy documents. Revenue Guard extracts candidate rules from each document as **draft rules**. After review, drafts are promoted to **active rules** that participate in validation. Rules can also be authored manually.

#### An order is submitted

Your system submits an order through the public API (or an order arrives via a connected source). The order carries patient, insurance, and ordered-test details, plus the payer IDs to evaluate against.

#### The order is validated

Revenue Guard evaluates the order against the active rules for its payers. Validation runs asynchronously, moving through `queued` → `running` → `completed` (or `failed`).

#### A result is produced

The order receives an overall verdict, a confidence score, and a set of findings. Each finding names the rule that triggered, why it triggered, and a suggested fix.

#### Your team and systems react

Results appear in the dashboard for review, and can be delivered to your systems over webhooks.

## Core objects

#### [Payers](/payers)

The insurers you bill. Each payer owns policy documents and the rules extracted from them.

#### [Rules](/rules-engine)

The logic an order is checked against. Rules move from draft to active and are versioned over time.

#### [Orders](/orders-validation)

A submitted lab order and its validation history, verdicts, and findings.

## Verdicts and confidence

Each validated order carries an overall verdict and a confidence score:

* **ok** — no rule concerns detected.
* **warning** — a rule flagged a potential issue worth reviewing.
* **critical** — a rule flagged a high-risk issue likely to cause a denial.

Confidence reflects how certain the model is in the classification. Both values are visible in the dashboard and in the `validation.completed` webhook payload.

## Where things run

Order intake and payer lookup are served by the public API. Validation, rule extraction, and the feedback learning loop run asynchronously in the background, which is why order submission returns immediately with a `202` while the result is produced shortly after. Subscribe to [webhooks](/webhooks) to be notified the moment validation completes.