Understanding Model Runs in RASS: A Complete Training Guide

Introduction

In Medicare Advantage and Part D, risk scores directly drive plan payments. These scores aren’t automatic — they are calculated through a series of scheduled and ad hoc processes inside CMS’s Risk Adjustment Suite of Systems (RASS).

These processes are called model runs.
Understanding how model runs work, and how their outputs (like the MMR and MOR) connect to payments and risk transparency, is essential for finance, operations, and compliance teams within Medicare Advantage Organizations (MAOs) and Prescription Drug Plans (PDPs).

What Is a Model Run?

A model run is the process by which CMS calculates risk scores using diagnosis and enrollment data within RASS.

Each model run includes the following steps:

  1. Extracting diagnosis data from:
    - EDPS (Encounter Data Processing System)
    - RAPS (Risk Adjustment Processing System for PACE)
    - FFS/IDR (Fee-for-Service / Integrated Data Repository)

  2. Extracting demographic and enrollment data such as age, sex, Medicaid eligibility, disability, and institutional status from:
    - BIC (Beneficiary Information on the Cloud)
    - MDS (Minimum Data Set)

  3. Applying the CMS-HCC model (V28 or blended version) to calculate the risk scores.

  4. Producing outputs, including:
    - MOF (Model Output File): Raw file containing demographics, HCCs, and interaction factors.
    - RAF (Risk Adjustment Factor): Final risk score after normalization and coding adjustments.
    - MORE (Model Output Report for MAOs): Summary of member-level demographics and diagnostic components.

These scores are transmitted to MARx, which applies them for Medicare Advantage and Part D payments.

The Six Types of Model Runs

CMS performs six distinct model runs each year, each with unique timing, purpose, and impact on plan payments.

1. Initial Model Run

  • Timing: September of the data collection year

  • Data window: July of the prior year → June of the data collection year

  • Purpose: Produces risk scores that determine payments for the first six months of the payment year.

2. Midyear Model Run

  • Timing: March of the payment year

  • Data window: January – December of the data collection year

  • Purpose: Produces risk scores for the second half of the payment year.

3. Interim Final Model Run

  • Timing: February following the payment year (or as needed)

  • Purpose: Provides early reconciliation for the entire payment year.

4. Final Model Run

  • Timing: August following the payment year (after interim final, if applicable)

  • Purpose: Produces final reconciled payments for the full year.

5. Cleanup Model Run

  • Timing: Ad hoc, post-final

  • Purpose: Corrects data or applies updated CMS business rules.

6. Overpayment Model Run

  • Timing: Ad hoc, as triggered by diagnosis deletions

  • Purpose: Adjusts payments by removing unsupported diagnoses and recouping overpayments.

Timeline Example

A typical model run sequence follows this flow:

  • Initial Run: July (prior year) → June (data collection year) → Payments for first half of payment year

  • Midyear Run: January – December (data collection year) → Payments for second half

  • Interim Final Run: Post-payment year → Early reconciliation

  • Final Run: Post-payment year (August) → Final reconciliation

  • Cleanup/Overpayment Runs: Ad hoc adjustments as required

Key CMS Reports in RASS: MMR and MOR

After each model run, CMS produces a set of output files and reports that bridge clinical validation, financial reconciliation, and audit transparency.
Two of the most important files MAOs receive are the MMR (Monthly Membership Report) and the MOR (Model Output Report).

RASS Output Flow:
EDPS/RAPS → RASS Model Run → MOF → MORE → MARx → MMR (Payments) + MOR (HCC Validation)

MMR (Monthly Membership Report)

Your Financial Blueprint from CMS

The MMR Detail File is the official CMS record that outlines monthly capitation payments, risk score logic, and adjustment activity for every beneficiary in a Medicare Advantage or Part D plan.

Purpose

  • Tracks all capitated payments, retroactive adjustments, and risk factor updates.

  • Enables MAOs to validate CMS payments and ensure that demographic and clinical data align with their internal systems.

Key Details

  • Format: Fixed-width, 495-character record layout

  • Delivery: Monthly

  • Content: 91 fields grouped into demographics, risk adjustment, payments, and adjustments

Essential Fields to Monitor

  • Contract/PBP/Segment IDs: Identify plan and region

  • RAF Fields (24–25, 46, 72–85): Risk factors used in calculation

  • ARC (Adjustment Reason Code): Explains why payment amounts changed

  • Cleanup ID: Tracks CMS-wide retroactive adjustments

ARC Codes — The Audit Trail

ARC codes explain every change in CMS payments.
Key ones to monitor:

  • 01: Death Notification (retro termination)

  • 07: Retroactive Hospice

  • 25: Part C RAF Reconciliation

  • 36: Part D Rate Change

  • 94: Cleanup-Related Adjustment

If your plan sees payment fluctuations — check ARC first. It’s your audit trail.

Strategic Uses

  • Revenue Validation: Confirm that RAFs and demographics align with expected CMS payments.

  • Compliance Readiness: Maintain documentation for all payment adjustments.

  • Risk Optimization: Identify coding gaps when default risk factors are used.

V28 Model Considerations

The CMS-HCC V28 model introduced major changes (2,200+ ICD code removals).
Plans must monitor:

  • ARC 25/26/37/41 increases tied to recalibrated RAFs.

  • Default risk factor codes triggered by missing or partial risk data.

Bottom Line:
The MMR is your financial control center. It reveals how CMS’s model outputs turn into real dollars — and how to reconcile every adjustment.

MOR (Model Output Report)

Your Diagnostic Window into CMS’s Risk Engine

The MOR is CMS’s official feedback file showing which of your submitted diagnoses actually became paying HCCs after hierarchy and filtering.

Purpose

  • Provides transparency into which diagnoses triggered HCCs.

  • Validates that your submissions were accepted and applied correctly.

  • Serves as your primary audit defense document during RADV or reconciliation.

Types of MOR Files

  • MOR Report (HCCMODR):

    • Human-readable

    • Ideal for smaller plans or manual validation

  • MOR Data File (HCCMODD):

    • Fixed-width, 200-byte (Part C) or 168-byte (Part D)

    • Designed for automation and dashboard integration

MOR Lifecycle

  • Monthly MORs: Reflect live model runs (Jan–Jun and Jul–Dec).

  • Final MOR: Released after the final model run — used for appeals and audit reconciliation.

From Diagnosis to Payment: The HCC Journey

  1. Submit: Member has diagnosis E11.9

  2. Map: CMS maps to CC 19

  3. Group: CC 19 → HCC 19 (Diabetes)

  4. Filter: CMS applies hierarchy (drops lower-level codes)

  5. Pay: HCC 19 triggers on MOR = payment earned

Common Reasons for Exclusion

  • Non-specific ICD-10 codes not mapping to a payment HCC

  • Hierarchy overrides by more severe conditions

  • Late or improperly formatted submissions

  • Invalid encounter structure

Strategic Uses

  • Coding Accuracy: Identify diagnoses that didn’t trigger payments.

  • Revenue Assurance: Cross-check with MMR to ensure payment alignment.

  • Provider Education: Use MOR data to guide documentation improvements.

  • Audit Preparation: MOR = CMS’s proof of record for every payment-impacting diagnosis.

Bottom Line:
The MOR is your clinical mirror — it tells you exactly how CMS interpreted your diagnoses and which ones drove revenue.

Why Model Runs, MMR, and MOR Matter for Plans

  • Revenue Forecasting: Model runs and MMR trends reveal payment cycles.

  • Compliance Tracking: ARC and MOR exclusions show documentation gaps.

  • Audit Defense: MORE and MOR link diagnoses → HCCs → payments.

  • Operational Accuracy: MMR ensures payments align with member data; MOR ensures diagnoses align with payments.

  • Financial Planning: Joint use of MMR and MOR provides full-cycle visibility into risk adjustment operations.

Knowledge Check (Training Style)

1. Which model run determines payments for the first half of a payment year?
A. Initial Run.

2. What is the purpose of the MOR?
A. To show which diagnoses triggered paying HCCs.

3. What file should you review to find the reason behind a payment change?
A. MMR — Check the ARC (Adjustment Reason Code).

4. When does CMS typically run the Final Model Run?
A. August following the payment year.

5. What is the relationship between MMR and MOR?
A. MMR shows payment adjustments; MOR shows which diagnoses drove them.

Practical Takeaways

  • Always validate MMR and MOR files together — they complete the payment picture.

  • Monitor ARC codes and default risk factors monthly.

  • Use MOR insights to drive provider training and coding specificity.

  • Track CMS model run schedules to anticipate payment adjustments.

  • Maintain audit-ready documentation across RASS, MARx, and MMR/MOR.

Appendix: Detailed Notes from Training

  • Model Run Inputs: EDRA (encounter/chart), RAPS (PACE), FFS/IDR, BIC, MDS.

  • Outputs: MOF → MORE → MARx → MMR/MOR.

  • Overpayment Logic: Triggered by deletes; reconciled in Cleanup runs.

  • Operational Tip: Late submissions only apply in the next model run — track all cutoff dates.

  • Audit Tip: MORE + MOR + MMR = complete CMS validation trail for plan payments.

Conclusion

Model runs, MMR, and MOR form the backbone of CMS’s risk adjustment ecosystem.
Together, they connect clinical documentation → diagnosis coding → risk scoring → payment flow.

By mastering this cycle, Medicare Advantage plans can ensure payment accuracy, compliance integrity, and operational excellence — from diagnosis to dollar.