RADV Audit Readiness: The Bronze Provenance Standard CMS Actually Expects

CMS's Risk Adjustment Data Validation (RADV) audit process has become significantly more rigorous over the past three years. The stakes are high: RADV findings can result in repayment demands running into the millions, and errors in audit documentation can invalidate HCCs that would otherwise stand.

A 97.3/100 RADV readiness score — the benchmark we've achieved in production — is not the result of last-minute audit preparation. It's the output of a specific data architecture designed from the ground up with audit-defensibility in mind.

What CMS Auditors Actually Check

RADV auditors review a sample of submitted HCC codes and trace each one back through three layers:

Layer 1: The Face-to-Face Encounter Every submitted HCC requires documentation of a face-to-face encounter with an eligible provider during the measurement year. For telehealth encounters, this means:

• •Place of Service Code 02 (telehealth provided other than in patient's home) or 10 (telehealth provided in patient's home)
• •Modifier 95 or GT on the claim
• •Interactive audio-video — audio-only does NOT qualify for risk adjustment

Layer 2: MEAT Documentation The clinical documentation must demonstrate that the condition is being:

• •Monitored — tracking signs and symptoms
• •Evaluated — ordering tests, interpreting results
• •Assessing or Addressing — the diagnosis appears in the assessment section
• •Treating — medications, procedures, or other interventions

A historical mention of a condition ("patient has a history of Type 2 diabetes") is not sufficient. The record must show active management during the measurement year.

Layer 3: The Source Record Link The auditor must be able to trace the submitted HCC code from the CMS submission file backward through:

• •The specific claim or encounter that originated the code
• •The clinical documentation that supports the encounter
• •The coding decision that mapped the clinical documentation to the ICD-10 code

Any gap in this chain — a submitted HCC that can't be traced to a source record — is an audit finding.

The Bronze Provenance Pattern

The bronze layer in a medallion data architecture serves a specific purpose for RADV: it preserves the immutable, original source record with a content hash.

Here's what this means in practice:

When a FHIR R4 document, HL7 v2 message, or C-CDA XML arrives at the ingestion layer, it is written to bronze storage with:

• •content_sha256: A SHA-256 hash of the original payload
• •bronze_path: The exact file path or API endpoint it came from
• •batch_id: The ingestion batch identifier
• •received_at: The timestamp of receipt

This bronze record is immutable — it cannot be modified after creation. Every downstream transformation (Silver canonicalization, Gold analytics) carries a reference to the originating bronze record.

When a RADV auditor asks for proof that HCC 85 (Congestive Heart Failure) was documented and submitted for patient XYZ, the response is:

1. •Here is the submitted claim with the ICD-10 code I50.9
2. •Here is the Silver condition record (with bronze_path reference)
3. •Here is the original C-CDA document (with content_sha256 verification)
4. •Here is the MEAT evidence score showing the condition was actively managed
5. •Here is the face-to-face encounter record with the appropriate provider type

The SHA-256 hash proves the original document has not been modified since receipt. This is the standard CMS expects — and it's what separates organizations that pass RADV from those that scramble.

The Pre-Submission Compliance Filter

RADV audit findings are expensive not just because of repayment, but because of the operational cost of responding to them. The better strategy is to catch non-compliant HCCs before submission.

A pre-submission compliance filter evaluates every candidate HCC against:

• •Face-to-face encounter presence: Is there a qualifying encounter within the measurement year?
• •Provider type eligibility: Was the rendering provider an eligible type (physician, NP, PA, CNS)?
• •Telehealth qualification: If telehealth, does the claim have the correct POS code and modifier?
• •MEAT documentation: Is there at least one of the four MEAT criteria present in the clinical notes?
• •HCC hierarchy compliance: Is this HCC being suppressed by a more severe condition in the same hierarchy group?
• •Specificity: Is the ICD-10 code sufficiently specific, or is a more specific code available and documented?

HCCs that fail these checks are flagged as non-compliant before the submission file is generated. The submitter can review them, add supporting documentation, correct the code, or consciously exclude them — with full documentation of the decision.

This filter produced 0 P0 compliance findings and 84 specificity alerts in the most recent audit cycle. The specificity alerts are informational — they flag cases where a more specific ICD-10 code exists — not blocking errors.

The Recapture Tracking Architecture

RADV compliance also includes the proactive side: identifying HCCs from prior years that weren't submitted but should have been.

The recapture engine runs quarterly and:

1. •Pulls all HCC codes that appeared in historical clinical records but were not submitted in the prior year's payment data
2. •Scores each against the current MEAT documentation standard
3. •Estimates the annual revenue value of recapturing each HCC
4. •Creates a tracking row with the patient, HCC, measurement year, estimated value, and current status

In a recent production cycle, this identified 248 trackable recapture opportunities across 90 patients representing $1,046,408 in estimated annual value — all with bronze provenance to support the recapture submission.

The SFTP Delivery Pipeline

The final step of RADV-ready submission is the delivery mechanism. CMS accepts RAPS and EDS files via SFTP — and the delivery pipeline itself needs audit controls.

A production SFTP delivery pipeline must:

• •Validate the submission file against the pre-submission compliance filter before delivery
• •Require a manual approval gate (not just an automated threshold check)
• •Log the submission event with timestamp, file hash, and approver identity
• •Retain the submitted file in immutable storage for the RADV lookback period

A double-gate pattern — automated compliance pass rate check + manual Airflow variable approval — prevents accidental submission of files that failed validation thresholds.

Practical Steps for RADV Readiness

If you're evaluating your RADV posture today:

1. •

   Audit your bronze layer. Does every submitted HCC trace back to a source record with a content hash? If not, you have a provenance gap.

2. •

   Score your MEAT documentation. Run your clinical notes through an evidence extraction engine. What percentage of your submitted HCCs have explicit MEAT evidence? Below 80% is a red flag.

3. •

   Check your face-to-face encounter completeness. For every submitted HCC, is there a qualifying encounter in the same measurement year? Missing encounters are the most common RADV finding.

4. •

   Validate your telehealth claims. If you're relying on telehealth encounters for risk adjustment, verify that POS 02/10 and modifier 95/GT are on the claims — not just in the clinical notes.

5. •

   Run a pre-submission filter. Before your next submission, run every candidate HCC through an automated compliance check and resolve any flags.

---

AssureLogix achieved a 97.3/100 RADV readiness score with 0 blocking compliance findings across 101 patients in production. Every submitted HCC has bronze provenance, MEAT evidence scoring, and a face-to-face encounter link. Book a compliance review to assess your organization's RADV posture.