EDGE Server Outbound Reports: How to Read What Comes Back 

Submitting files to the EDGE server is the visible part of ACA risk adjustment operations. The less visible part — and where most of the analytical value lives — is what comes back. 

The EDGE server generates a cascade of outbound reports that tell you what was accepted, what failed, what risk score was assigned to each enrollee, and ultimately what RA transfer payment flows to or from your plan. But not all outbound reports come from the same document, and not all of them are meant for the same audience. Understanding the full picture requires knowing which report comes from where and when to act on it. 

Two Documents, Two Phases 

Outbound reports come from two entirely separate ICDs — a distinction that trips up a lot of teams: 

Phase 1 reports from the Inbound ICD are triggered by your file submission. They tell you what the EDGE server did with your data during ingest. 

Phase 2 reports from the Outbound ICD are triggered by CMS-issued remote commands after data has been accepted and processed. They tell you what the RA model calculated from that data. 

Think of Phase 1 as the quality gate and Phase 2 as the payment engine. You can't get meaningful Phase 2 output if Phase 1 is full of errors. 

The Linking Key: fileIdentifier 

Before getting into individual reports, one concept underpins all of them. 

The 12-character fileIdentifier you assign in every inbound file header is echoed back in every outbound report generated from that submission. It is your master reconciliation anchor — the thread that connects your submission to its processing results. 

You submit:     fileIdentifier = "202401150001" 
EDGE returns:   submittedFileIdentifier = "202401150001" 

If you assign meaningful file IDs — for example, embedding the submission date and a sequence number — you can trace any error report, any risk score, and any RA transfer calculation back to the exact file that produced it. This is the foundation of a clean EDGE audit trail. 

Phase 1: File Processing Reports 

These nine reports are generated immediately after your inbound file is processed. Five go to both the issuer and CMS; four go to the issuer only. 

ESFAR is Always Step One 

The ESFAR is the first report to check after any submission. It covers all four inbound file types and tells you whether the file was accepted or rejected at the file header level. If the file failed at the header, it never reached claims-level validation — there is nothing in ESDMCE or ESDPCE to look at yet. Fix the header error and resubmit. 

The summary reports (ESSEFE, ESSMFE, ESSPFE, ESSSFE) give CMS a high-level view of your data quality. The detail reports (ESDEE, ESDMCE, ESDPCE, ESDSFE) are where your operations team works — they provide record-level rejection detail, including the specific data element that failed and the error reason code. 

Detail reports reference the same recordIdentifier values from your inbound file. Because record IDs are sequential across the entire file, every error in the detail report maps back to a precise record in your submission with no ambiguity. 

Phase 2: RA/RI Calculation Reports 

These reports are generated when CMS executes RA/RI calculation commands. They are the output of the HHS-HCC risk scoring model applied to your accepted data. 

The Reports That Drive RA Analytics 

RACSD — RA Claim Selection Detail (Issuer Only) The most operationally important RA report. It shows exactly which claims and supplemental records were included in or excluded from RA scoring, with specific reason codes for every exclusion. It has nine data categories including Calendar Year, Plan, Bill Type, Service Code, Reason Code, Pharmacy Claim, Unlinked Supplemental, Medical Claim, and Supplemental Claim. 

The Unlinked Supplemental category deserves particular attention — it identifies ESSFS records that could not be linked to an accepted ESMCS claim. Those supplemental records scored nothing despite being submitted. 

RARSD — RA Risk Score Detail (Issuer Only) Individual enrollee-level risk scores. For each enrollee it shows payment HCCs assigned and their coefficients, payment RXCs from pharmacy data, diagnosis codes contributing to each HCC, NDC codes contributing to each RXC, and HCCs dropped by hierarchy suppression. This is the primary source for member-level opportunity gap analysis. 

RACSS — RA Claim Selection Summary (Issuer + CMS) Plan-level rollup of RACSD. CMS uses this for program monitoring. 

RARSS — RA Risk Score Summary (Issuer + CMS) Plan and rating area level risk score summary. Contains HCC distributions, RXC distributions, CSR factors, dropped HCC counts, and interaction group details. 

RATEE — RA Transfer Elements Extract (Issuer + CMS) The specific inputs to the RA transfer payment formula — plan average risk scores, metal tier factors, geographic factors, and member months. Use this to verify and reconcile your expected RA transfer amount. 

RAUF — RA User Fee (Issuer + CMS) The user fee applied based on plan enrollment and premium data. 

The four Frequency by Data Element reports (FDEEAF, FDEPAF, FDEMAF, FDESAF) are underused. They show distributions of key data elements across your accepted files — enrollment maintenance type code counts, NDC code frequency, diagnosis code qualifier distributions. These surface systematic data quality patterns that claim-level error reports can never show. 

RADV Audit Reports (Issuer + CMS — Special Category) 

The four RADV extract reports (RADVDE, RADVEE, RADVMCE, RADVSE) are a special exception to the general rule that detail reports stay issuer-only. These contain enrollee-level data specifically provided to CMS for Risk Adjustment Data Validation audits. 

High Cost Risk Pool 

HCRPSR / HCRPDE — The High Cost Risk Pool is a separate payment mechanism for enrollees with extremely high claims costs. These two reports identify qualifying enrollees and calculate HCRP payment amounts, independent of standard RA transfer payments. 

Recipient Rules Matter 

The ICD is explicit about who receives what: 

Detail reports stay with the issuer. CMS sees only summarized, aggregated data. The enrollee-level, claim-level detail lives on your EDGE server and is visible only to you — which is by design. The distributed EDGE model was built specifically to ensure issuer proprietary data and protected health information do not flow to HHS. 

The Full Lifecycle 

Submit ESES + ESMCS + ESPCS + ESSFS 
        ↓ 
ESFAR  — Did the file load? 
ESDMCE / ESDPCE / ESDEE / ESDSFE  — Which records failed? 
        ↓ 
[Fix and resubmit] 
        ↓ 
CMS runs RA calculation command 
        ↓ 
RACSD  — Which claims scored for RA? 
RARSD  — What is each enrollee's risk score? 
RARSS  — What is the plan-level score? 
RATEE  — What are my transfer payment inputs? 

Each stage builds on the previous. A clean inbound submission leads to clean claim selection, which leads to accurate risk scores, which leads to defensible transfer payment calculations. The outbound reports are not a checklist to file away — they are the feedback loop that makes the entire system auditable. 

The Bottom Line 

The EDGE server tells you exactly what it did with your data. Phase 1 reports tell you what was accepted and what failed during ingest. Phase 2 reports tell you how that accepted data translated into risk scores and transfer payments. The fileIdentifier connects the two. Used together, these reports give you full traceability from the raw XML you submitted to the dollar amount on your RA transfer statement. 

ACA EDGE Server Submissions Explained: The Four Files That Drive Risk Adjustment 

Every ACA health plan's risk score, risk adjustment transfer payment, and regulatory standing depend on one thing: clean, timely, and complete data submitted to the EDGE server. 

The EDGE server is how ACA issuers transmit enrollment, claims, and supplemental diagnosis information to CMS for validation and use in Risk Adjustment (RA) and Reinsurance (RI) calculations. Understanding its structure — the four inbound file types, their validation rules, and how they connect — is the foundation of any serious ACA data operation. 

What Is the EDGE Server? 

The EDGE server is an issuer-owned infrastructure running HHS-developed software. Each issuer owns and operates its own instance — either hosted on AWS or on-premise — or contracts a third-party entity to operate it on their behalf. Issuers submit four types of XML data files for processing, and the EDGE server validates, stores, and scores that data for RA/RI calculations. 

CMS uses this data to calculate risk scores for each enrollee, execute RA transfer payments between issuers, support Risk Adjustment Data Validation (RADV) audits, and produce outbound reports for issuer review and CMS oversight. 

Issuers offering non-grandfathered individual or small group market ACA plans are required to use the EDGE server — whether on or off the marketplace. Grandfathered plans, self-funded ERISA plans, and Medicare Advantage plans are out of scope. 

The Three Execution Zones 

Every submission is tagged to one of three zones: 

The Test zone exists precisely so issuers can resolve verification errors before committing to a production run — use it. 

The Four Inbound Files 

ESES  →  Who is enrolled and when 
ESPCS →  What drugs they filled 
ESMCS →  What medical care they received 
ESSFS →  Additional diagnoses not captured in claims 

1. EDGE Server Enrollment Submission (ESES) — File Type: E 

The ESES is the foundational file. Every other file references the masked enrollee IDs established here. It carries enrollee demographics (date of birth, gender), enrollment periods (coverage start and end dates, plan ID), premium amounts, rating area, and subscriber/dependent relationships. 

A few rules that catch teams off guard: ESES is a full replacement file — subsequent submissions must include all enrollment activity for the data collection period, not just new records. Duplicate enrollee records (same masked ID within an issuer) are rejected outright. Submissions are required at least quarterly, with monthly strongly recommended. 

File Header → Enrollment Issuer → Enrollee → Enrollment Period 

2. EDGE Server Pharmacy Claims Submission (ESPCS) — File Type: P 

The ESPCS carries adjudicated pharmacy claims — the data used to map NDC codes to RXC drug risk categories in the HHS-HCC model. Key fields include the National Drug Code (NDC), fill date, paid date, plan paid amount, dispensing provider ID, fill number (0 = original; 1–999 = refill), and a Void/Replace indicator. 

Unlike ESES, ESPCS is incremental — subsequent submissions contain only new claims since the last submission. Sending a full replacement file will generate duplicate rejects, not a clean refresh. 

File Header → Pharmacy Issuer → Insurance Plan → Pharmacy Claim 

3. EDGE Server Medical Claims Submission (ESMCS) — File Type: M 

The ESMCS is the most complex of the four files. It carries the diagnosis codes that drive HCC risk scoring and covers both professional (CMS-1500) and institutional (UB-04) claims. Up to 99 ICD-10 diagnosis codes per claim header, form type (Institutional or Professional) that drives requirements for bill type, discharge status, and place of service, service codes (CPT/HCPCS), and billing/rendering provider IDs with NPI check digit validation. 

ESMCS is also incremental — subsequent submissions should contain only new, adjusted, or voided claims. Each claim header must include at least one claim line, and every claim line failure rejects the entire associated claim. 

File Header → Medical Issuer → Insurance Plan → Medical Claim Header → Medical Claim Line 

ESMCS is the only file with five structural levels. That extra depth is where most complex rejection scenarios originate. 

4. EDGE Server Supplemental Diagnosis File Submission (ESSFS) — File Type: S 

The ESSFS is the supplemental pipeline — it captures diagnosis codes documented in medical records or electronic data that were never billed on a claim or were missed during claims submission. Each record carries up to 99 ICD-10 diagnosis codes, an Add/Delete/Void indicator (not Void/Replace like the claims files), a source code of MR (medical record) or EDI (electronic data interchange), an original claim ID that must reference an accepted ESMCS claim, and the date of service range supporting the diagnosis. 

The ESSFS is incremental. Critically, every supplemental detail record must reference an accepted ESMCS claim — if the supporting claim was never submitted or was rejected, the supplemental record has nothing to link to and will score nothing. 

File Header → Supplemental Diagnosis Issuer → Insurance Plan → Supplemental Diagnosis Detail 

What All Four Files Have in Common 

Despite their differences, all four files share the same five-field header: 

The fileIdentifier matters more than most teams realize. Every outbound report echoes it back — it is the thread that connects your submission to every acceptance report, every rejection, and every risk score the EDGE server produces for that file. 

All four files also share the same sequential record ID rule: every record carries a recordIdentifier integer that must be exactly 1 greater than the preceding record, regardless of record type. The counter never resets between categories. This gives CMS a precise pointer to any failing record — "Record 147 failed" is unambiguous across the entire file. 

The Four Verification Checks 

Every data element in every file is subject to up to four sequential checks: 

1. Required Check — Did you fill in the field? Fields are Required, Situational (needed under specific conditions), or Not Required. The classic situational example: subscriberIndicator and subscriberIdentifier are mutually dependent — exactly one must be populated depending on whether the enrollee is the subscriber. 

2. Face Validity — Is the value in the right format? A coverage date submitted as 04/01/2025 fails face validity even if the date is valid — only 2025-04-01 passes. 

3. Referential Check — Does this value exist in a reference table? A Plan ID absent from the HIOS plan registry or an NDC code not in the FDA database fails here. 

4. Logical Check — Does the value make sense in context? Coverage start date must be ≤ coverage end date. If gender code = U (newborns only), enrollment start date must be within 90 days of date of birth. 

One rule unique to ESSFS: fields that fail the Required or Face Validity check will not proceed to Referential and Logical checks. The other three file types always run all applicable checks. 

The Rejection Cascade 

A failure at any level ripples down to all subordinate records. 

For all four file types: 

• File header failure → entire file rejected 

• Issuer-level failure → all records for that issuer rejected 

For Pharmacy, Medical, and Supplemental files additionally: 

• Plan-level failure → all records for that plan rejected 

• All plan records fail → entire issuer rejected even if issuer header passed 

For Enrollment (ESES) specifically: 

• Enrollee-level failure → all enrollment periods for that enrollee rejected 

• All enrollees fail → issuer record rejected 

• Enrollment period failure → that enrollment record rejected 

• All enrollment periods fail → enrollee record rejected 

For Medical (ESMCS) specifically: 

• Claim header failure → all claim lines for that claim rejected 

• Claim line failure → the entire claim (header + all lines) rejected 

• All claim headers fail for a plan → plan record rejected 

A single bad issuer-level field can silently wipe out an entire file's worth of records. This cascade is why ESFAR — the File Accept-Reject Report — is always the first outbound report to check. 

The Bottom Line 

The EDGE server scores what it accepts. Four files, each with its own structure, its own assumptions, and its own failure modes — but a shared header, a shared sequential ID rule, and shared verification logic that applies consistently across all of them. Getting these basics right is the prerequisite for everything downstream: risk scores, RA transfers, and RADV audit readiness. 

Understanding the MAO-004 Report: A 2025 Guide for Medicare Advantage Organizations

Introduction 

The MAO-004 Report is a foundational document for Medicare Advantage Organizations (MAOs) involved in risk adjustment and encounter data submissions. Issued monthly by CMS, this report provides critical feedback on diagnosis codes submitted via the Encounter Data Processing System (EDPS), identifying which are deemed eligible for risk adjustment. 

Since its launch in Payment Year (PY) 2015, and updated in August 2017 to include only EDRs accepted through EDPS, the MAO-004 has served as an essential tool for auditing, compliance monitoring, and payment validation. 

Purpose and Relevance 

The MAO-004 is more than a routine file—it is CMS’s mechanism to communicate which diagnoses tied to submitted encounters and chart reviews qualify for risk score calculation. For teams managing risk adjustment, understanding and acting on this data is essential for compliance and maximizing revenue integrity. 

Structure of the MAO-004 File 

The file format is 500-byte fixed length and consists of three main record types: 

1. Header Record – Contains metadata, such as Contract ID, report date, submission phase, and version. 

2. Detail Record – The core of the report, capturing diagnosis-level data and its eligibility status. 

3. Trailer Record – Summarizes the number of records and ensures report completeness. 

Accessing the MAO-004 Report 

CMS delivers the report through two methods: 

1. EFT Mailbox (Electronic File Transfer) 

• File Name Example: R.ZZZZZZ.MAO004FY.Dyymmdd.Thhmmss 

• Frequency: Monthly 

• Format: Fixed length, 500 bytes 

2. MARx User Interface 

• Navigate to “Reports” → Select “Monthly” 

• Choose the appropriate date range 

• Select “Risk Adjustment Eligible Diagnosis Report” 

• Enter Contract ID and run the search 

Detail Record Breakdown 

Each detail record corresponds to a single diagnosis entry and contains key fields such as: 

1. Record Type
   Always “1” — indicates a detail record.

2. Beneficiary ID
   This is either the Health Insurance Claim Number (HICN) or the Medicare Beneficiary Identifier (MBI).

3. Encounter ICN
   Refers to the Internal Control Number assigned to each encounter.

4. Diagnosis Codes
   The submitted ICD-10 codes that CMS will evaluate for risk adjustment eligibility.

5. Add/Delete Flag
   Indicates whether the diagnosis was:

   • “A” for Added

   • “D” for Deleted

   • Blank/Space for previously reported

6. Allowed/Disallowed Flag
   Indicates whether the diagnosis was considered for risk adjustment:

   • Blank means Allowed

   • “D” means Disallowed

7. Reason Codes
   Explains the reason behind a disallowed diagnosis:

   • “H” for CPT/HCPCS mismatch

   • “T” for Type of Bill issue

   • “D” for late submission

   • “Q” for quarterly CPT/HCPCS update

   • “N” for not applicable

Common Flags: 

• A: Allowed 

• D: Disallowed 

• N: Not applicable 

Reason Codes: 

• H: Invalid due to CPT/HCPCS logic 

• T: Invalid due to incorrect Type of Bill 

• D: Denied due to late submission 

• Q: Newly accepted due to quarterly code update 

Trailer Record Overview 

The trailer acts as a final checkpoint: 

• Confirms the number of records processed 

• Validates data completeness and alignment with the submission batch 

• Includes the MAO’s Contract ID and record count 

Why the MAO-004 Report Matters 

For Medicare Advantage Organizations, MAO-004 reports offer: 

• Audit Preparedness – Ensures diagnosis codes were accepted and used by CMS 

• Revenue Assurance – Confirms codes are contributing to risk scores 

• Error Identification – Flags denied records with reasons to guide corrections 

• Data Integrity – Reinforces alignment with CMS submission standards 

Best Practices for Using MAO-004 Reports 

• Review Phase and Version in the header to confirm the file layout 

• Analyze reason codes to identify high-priority corrections 

• Use both EFT and MARx access points for redundancy and historical comparisons 

• Validate trailer record counts to ensure no data truncation or loss 

Frequently Asked Questions 

Q: How frequently are MAO-004 reports generated? 
A: Monthly via CMS’s EFT mailbox and MARx user portal. 

Q: What’s the difference between Phase and Version? 
A: Phase refers to the release stage (e.g., Phase 4), and Version indicates the layout version (e.g., Version 0). 

Q: What does the Add/Delete flag indicate? 
A: It shows whether a diagnosis is new, deleted, or unchanged in the system. 

Q: Which codes most commonly lead to diagnosis disallowance? 
A: Codes “H” (CPT/HCPCS issues), “T” (Type of Bill), and “D” (late submission). 

Conclusion 

The MAO-004 report is a critical compliance and operational asset in the Medicare Advantage risk adjustment lifecycle. By properly interpreting this report, MAOs can drive greater accuracy in revenue, ensure audit readiness, and uphold CMS’s standards for data integrity. 

Whether you are a coder, analyst, or compliance lead, mastering the MAO-004 gives you powerful insights to guide smarter decisions and strategic improvements. 

Need help interpreting your MAO-004 reports or streamlining encounter data workflows? 
Let our team at Health Data Max assist. 
book a demo 

Mastering the CMS MMR File: Your Complete Guide to Medicare Advantage Payments, Risk Adjustment, and Financial Accuracy

The definitive resource for coders, compliance analysts, and MA operations teams

Introduction: Why the MMR Is Your Monthly Financial Playbook

If you're working in Medicare Advantage or Part D, the Monthly Membership Report (MMR) Detail File isn't just another CMS data dump—it's your financial DNA from CMS. Every line item reveals what was paid, why it changed, and what risk model was applied to your beneficiaries.

For Medicare Advantage Organizations (MAOs), this file represents one of the most critical—yet often underutilized—tools for revenue validation, compliance tracking, and risk adjustment accuracy. Think of it as the pulse of your plan's payments, containing the entire reasoning behind every dollar CMS sends your way.

What Is the MMR Detail File?

The Monthly Membership Report (MMR) Detail File is the official CMS data file used to track monthly capitation payments, adjustments, and risk scores for Medicare Advantage and Part D beneficiaries. Each row in the file reflects a payment event—whether it's an original capitation, a retroactive adjustment, or a cleanup record—associated with a beneficiary enrolled in your MA plan.

Key Technical Specifications:

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

• Frequency: Monthly delivery to MA plans

• Structure: Every variable has a specific character position

• Usage: MA Plans, Part D Plans, Compliance Audits, RAS Submissions

Comprehensive Breakdown: The 91 Fields Inside Your MMR

The MMR is organized into logical sections that paint a complete picture of your beneficiary payments and risk adjustments:

Beneficiary Demographics & Contract Information

• Contract Number (positions 1–5): Your CMS-assigned plan contract (e.g., H1234)

• Plan Benefit Package (PBP) ID (6–8): Specific product under the contract

• Segment ID (9–10): Identifies the plan segment if the plan is regional

• Beneficiary ID (20–31): May include either HICN or the new Medicare Beneficiary Identifier (MBI)

• Member Details: Name, Gender, DOB, State & County Code

• Status Indicators: Hospice, ESRD, Medicaid, Institutional, Dual-Status

• OREC (Original Reason for Entitlement Code): Distinguishes beneficiaries by entitlement type—age-in, disability, or ESRD

Risk Adjustment & Payment Logic

• RAF A/B (Fields 24–25): Core risk adjustment factors

• Part C Risk Adjustment Factors (positions 72–85): Values for community, institutional, ESRD, or new enrollee categories

• Risk Adjustment Factor Type Code (Field 46): Specifies which risk model was applied

• RAAG – Risk Adjustment Age Group (Field 40): Age-based risk categorization

• Default Risk Factor Code (Field 71/87): Applied when CMS uses default RAF due to insufficient risk data

Payment Components & Financial Details

• Monthly Capitated Payments (positions 96–123): Separate values for Part A and B

• Monthly Part A, B, D amounts: Base payment calculations

• Rebate fields (Part C/D): Plan-specific rebate amounts

• Low-Income & Medicaid Add-On Fields (Fields 20, 66, 67, 68): Additional subsidies and wraparound payments

• MTM Add-on, LIS Premium Subsidy, Reinsurance, Direct Subsidy: Supplemental payment components

County-Level Payment Rates (Fields 88–90)

CMS uses county-level benchmarks to calculate payments:

• Field 88 – Part A Rate: Monthly Part A state/county payment or adjustment rate

• Field 89 – Part B Rate: Monthly Part B state/county payment or adjustment rate

• Field 90 – Part D Rate: Monthly Part D payment or adjustment rate

These fields show the base amounts before risk adjustments—crucial for reconciling rate changes or benchmarking CMS payments.

Adjustments & Reconciliation Tracking

• ARC – Adjustment Reason Code (Field 28): The "receipt" behind every payment change

• Cleanup ID (Field 91/positions 486–495): Tracks systemic CMS cleanup events or batch adjustments

• Transaction Type Code: Indicates if the row is original or a correction

• Start and End Dates (Fields 29–30): Payment period coverage

Deep Dive: ARC Codes - Your Audit Trail for Payment Changes

Adjustment Reason Codes (ARC) are found in multiple CMS files and represent the "why" behind every payment modification CMS makes.

Where You'll Find ARC Codes:

• MMR Detail Report (Field 28)

• MMR Summary Report (Field 4)

• PPR/IPPR Capitated Payment Files (Field 4)

Complete ARC Code Categories

Range Reason 00 Standard prospective payments 01–22 Retroactive enrollment & eligibility 23–27 Risk adjustment changes 28–37 Premium/rebate adjustments 38–46 Segment ID or eligibility corrections 50–66 Merge, incarceration, lawful status 90–94 System-driven CMS cleanup events

Critical ARC Codes to Monitor

• 01 – Death Notification: Retroactive termination adjustments

• 07 – Retroactive Hospice: Member moved to hospice care

• 10 – Retroactive Medicaid: Dual eligibility status change

• 25 – Part C RAF Reconciliation: Risk score adjustments

• 36 – Part D Rate Change: Premium or rate modifications

• 44 – Correction of Previously Failed Payment: System error corrections

• 65 – Incarceration Status Confirmed: Eligibility suspension

• 94 – Cleanup-Related Adjustment: Batch system corrections

Pro Tip: If payment amounts shift unexpectedly, check ARC first. It's your complete audit trail and the key to understanding revenue fluctuations.

Critical Focus: Part D Default Risk Factor Evolution

Field 87 (Default Risk Factor Code) identifies default RAF logic when a beneficiary has insufficient Medicare entitlement or RAS data—and it's undergoing significant changes.

Historical Logic (January 2011–December 2024):

• 0 = Not ESRD, Not Low Income, Not Originally Disabled

• 5 = ESRD, Low Income, Not Originally Disabled

• 7 = ESRD, Low Income, Originally Disabled

• (Additional combinations for Low Income, ESRD, and disability flags)

NEW: Starting January 2025:

• A = Not ESRD, Not Low Income, Not Originally Disabled, MAPD

• F = ESRD, Low Income, Originally Disabled, MAPD

• P = ESRD, Low Income, Originally Disabled, PDP

• N = Not ESRD, Low Income, Not Originally Disabled, PDP

• (Full classification system includes more combinations)

This evolution helps CMS calculate RAF more precisely when claims data is missing or eligibility is partial, particularly distinguishing between MAPD and PDP enrollees.

Strategic Applications: Making Your MMR File Actionable

Understanding the MMR file layout gives MA plans significant operational advantages across multiple departments:

1. Revenue Validation & Financial Reconciliation

• Compare CMS payments with internal projections based on RAF, demographics, and enrollment history

• Validate that risk scores align with documented conditions and HCC mappings

• Track month-over-month payment changes and identify revenue trends

2. Identify Revenue Leakage Opportunities

Monitor for these red flags:

• Records flagged with default risk factors: Potential missed coding opportunities

• ARC codes pointing to deletions: Reductions in past payments requiring investigation

• Retroactive termination adjustments: Revenue clawbacks due to eligibility changes

• Incorrect segment ID assignments: Payment miscategorizations

3. Compliance & Audit Readiness

• CMS, OIG, and internal compliance teams audit based on these payment events

• The MMR provides the complete transactional trail needed to reconcile discrepancies

• Track Cleanup IDs for large-scale CMS retroactions (overpayment recovery or OIG audits)

• Document the rationale behind every risk score and payment adjustment

4. Risk Adjustment Optimization

• Link risk scores and payments to actual diagnoses documented in claims or EMRs

• Uncover coding gaps or documentation errors impacting revenue

• Monitor RAF changes with Fields 24–26, 46, and 87 to identify diagnosis, plan status, or demographic impacts

• Cross-reference date fields (29–30) to ensure payment periods match ARC context

V28 Model Impact: New Challenges for MMR Analysis

CMS's V28 model has eliminated 2,200+ ICD-10 codes from HCC mapping, creating new MMR monitoring requirements:

What to Expect:

• More RAF recalibrations as codes move from vague to specific (E11.69 → E11.22 or E11.319)

• Increased frequency of ARC 25, 26, 37, and 41 as RAF updates ripple through the system

• Greater importance of documentation accuracy and coding specificity

• More default risk factor applications during transition periods

This makes your MMR analysis more critical than ever for identifying coding opportunities and revenue optimization.

Expert Tips for Analysts & Coders

Monthly Monitoring Best Practices:

1. Always Monitor ARC Codes (Field 28): They provide the "why" for retroactive payments, flags, and cleanups

2. Track Cleanup IDs (Field 91): Identify systemic adjustments or RAS audit overpayments

3. Monitor RAF Changes: Use Fields 24–26, 46, 87 to spot diagnosis, plan status, or demographic impacts

4. Validate Date Ranges: Ensure payment start/end dates (Fields 29–30) match ARC context

5. Cross-Reference Member Data: Match MBI/HICN and segment IDs with internal systems

Technical Implementation:

• Use ETL scripts or SQL loaders to parse the fixed-width format into readable tables

• Export MMR data into Excel or Power BI for dashboard creation and trend analysis

• Create automated alerts for unusual ARC patterns or significant RAF changes

• Build reconciliation reports linking MMR data to internal risk adjustment and enrollment systems

Advanced Analytics Applications:

• ARC trend analysis by plan segment or time period

• RAF monitoring dashboards tracking risk score evolution

• Revenue leakage identification through payment variance analysis

• Compliance reporting for audit preparation and regulatory submissions

Conclusion: Know Your MMR, Own Your Financial Accuracy

The MMR Detail File isn't just another CMS data file—it's the financial blueprint that drives how much your plan gets paid, when, and why. Whether you're in Finance, Risk Adjustment, Compliance, or Operations, mastering this file structure is essential for maintaining accuracy, avoiding revenue leakage, and staying audit-ready.

By understanding its 91 fields, tracking ARC and RAF changes, and leveraging the diagnostic logic tied to payment adjustments, you'll boost your team's confidence, compliance, and financial performance. In the evolving landscape of Medicare Advantage—particularly with V28 model changes—your MMR expertise becomes a competitive advantage that directly impacts your bottom line.

The MMR is your monthly playbook for payment accuracy. Make it count.

Bonus Resources

• CMS MARx User Guide: Official CMS documentation for MMR file specifications

• AHIMA Risk Adjustment Coding & Reporting: Professional coding guidance and best practices

• CMS Medicare Advantage Rate Announcements: Annual updates on payment methodology and risk adjustment changes

Understanding the Model Output Report (MOR): The Complete Guide to Medicare Advantage Risk Adjustment Transparency

Your definitive resource for MOR analysis, validation, and optimization

Quick Start: What You Need to Know

The MOR is CMS's only official feedback on your risk scores. Master it, and you master Medicare Advantage payments.

The Big Picture

• What it is: CMS's report showing which diagnoses became paying HCCs

• Why it matters: Direct impact on your revenue and compliance

• When you get it: Monthly (Jan-June) + Final reconciliation

• Who gets what: MA plans get Part C, PDP gets Part D, MA-PD gets both

The MOR Transformation Story

Before MOR Analysis: The Audit Nightmare

• 100s of hours spent on manual chart reviews

• Low compliance with CMS requirements

• Low STAR ratings due to missed opportunities

• Revenue leakage from unidentified coding gaps

After MOR Mastery: The Success Story

• Saves 100s of hours with automated insights

• High accuracy in risk score validation

• Achieves ⭐⭐⭐⭐⭐ ratings through precision

• Drives measurable revenue impact

What Is the MOR? (The 60-Second Explanation)

Think of the MOR as CMS's receipt for your risk adjustment submissions.

Your Submission: "Member John has diabetes (E11.9)"
     ↓
CMS Processing: Filters, validates, applies hierarchy
     ↓
MOR Result: "HCC 19 - Diabetes triggered for John"

Bottom Line: The MOR shows which of your submitted diagnoses actually became paying HCCs.

Two File Types: Pick Your Weapon

For Human Review: MOR Report (HCCMODR)

Perfect for:

• Small to medium plans

• Manual validation

• Spot-checking specific members

What you see:

• Member names and demographics

• Plain English HCC descriptions

• Easy-to-read format

For Automation: MOR Data File (HCCMODD)

Perfect for:

• Large plans with tech resources

• Automated processing

• System integration

What you get:

• Binary flags (1 = HCC triggered, 0 = not triggered)

• Fixed-width format for databases

• 200-byte records (Part C), 168-180 bytes (Part D)

MOR Timeline: When and What You Get

The CMS Risk Model Schedule

Initial Model Run:

• Timing: Occurs early in the year

• Purpose: Forms the basis for January through June payments

• MOR Impact: Creates the monthly MORs you receive from January to June

Mid-Year Model Run:

• Timing: Happens mid-cycle during the year

• Purpose: Updates risk scores and drives July through December payments

• MOR Impact: Generates the monthly MORs you receive from July to December

Final Model Run:

• Timing: Takes place at year-end

• Purpose: Produces definitive scores used for final reconciliation process

• MOR Impact: Creates the Final MOR, which serves as the definitive source for all appeals and final validation

Monthly vs. Final MOR

Monthly MORs (Jan-June):

• Real-time feedback on current payments

• Use for ongoing validation

• Course-correct during the year

Final MOR:

• The definitive truth for appeals

• Use for final reconciliation

• Your audit defense document

Plan-Specific Distribution

MA Plans (Medicare Advantage Only):

• Receive: Part C MOR only

• Focus: Medical HCCs and risk adjustment for medical services

• Why it matters: Allows concentration on medical condition coding and documentation without prescription drug complexity

PDP Plans (Prescription Drug Plans Only):

• Receive: Part D MOR only

• Focus: Prescription drug models and medication-related risk factors

• Why it matters: Enables targeted analysis of drug utilization patterns and pharmacy-based risk adjustment

MA-PD Plans (Medicare Advantage with Prescription Drug Coverage):

• Receive: Both Part C and Part D MORs

• Focus: Complete risk picture covering both medical and prescription drug components

• Why it matters: Provides comprehensive view of member risk across all covered services, essential for integrated care management and complete revenue optimization

From Diagnosis to Payment: The HCC Journey

The 5-Step Process

1. SUBMIT → You send diagnosis E11.9 (Type 2 diabetes)
2. MAP → CMS maps E11.9 to Condition Category 19
3. GROUP → CC 19 becomes HCC 19 (Diabetes)  
4. FILTER → CMS applies hierarchy rules
5. PAY → HCC 19 appears on MOR = Payment triggered

Why Diagnoses Get Excluded from MOR

Common Reasons Your Diagnosis Didn't Make It:

No Payment HCC Issue:

• Problem: Your diagnosis uses non-specific codes that don't map to paying HCCs

• Example: Using broad, unspecified diagnostic codes instead of detailed ones

• Solution: Use more specific ICD-10 codes that map to actual payment categories

Hierarchy Override Problem:

• Problem: A mild condition gets excluded when a more severe condition exists in the same hierarchy

• Example: Documenting mild diabetes complications when severe complications are also present

• Solution: Always document and submit the most severe condition in each hierarchy to maximize payment

Timing Issues:

• Problem: Diagnoses submitted outside the acceptable service date windows

• Example: Late submissions that miss CMS processing deadlines

• Solution: Ensure all encounters are submitted within the required service date windows

Data Quality Problems:

• Problem: Encounter data contains formatting errors or incorrect structure

• Example: Improper file formatting, missing required fields, or invalid code formats

• Solution: Implement robust validation processes for encounter data before submission to ensure proper formatting and completeness

Accessing Your MOR Files

Download Options

• MARx UI: Web-based, user-friendly

• EFT Mailbox: Automated delivery (Gentran, TIBCO, Connect:Direct)

• CMS Enterprise Portal: For historical files

File Naming Convention

P.R[CONTRACT].HCCMODR.D[YYMM]01.T[TIMESTAMP]

Example: P.RH1234.HCCMODR.D2501.T143022

• H1234 = Your contract

• 25 = Year 2025

• 01 = January

Strategic Applications: Make Your MOR Work

Revenue Optimization

Coding Gap Analysis

MOR Shows: Member has HCC 18 (Diabetes) 
Your Records: Also shows diabetic complications
Opportunity: Submit complication codes for higher HCC

Provider Feedback Loop

• Show providers their HCC capture rates

• Demonstrate documentation impact on payments

• Target training based on MOR results

Compliance & Audit Defense

Validation Checklist

• Internal risk scores match MOR results

• All expected HCCs appear on MOR

• No unexpected exclusions

• Proper hierarchy application

Audit Preparation

• MOR = Your official CMS documentation

• Links diagnoses to payments

• Supports appeals and corrections

Operational Excellence

For Small Plans

• Manual MOR review process

• Focus on high-value members

• Target obvious gaps first

For Large Plans

• Automated MOR processing

• Dashboard development

• Advanced analytics and trending

Full Risk (FR) Concept Simplified

Member Categories

Continuing Enrollees:

• Definition: Members who have maintained 12 or more months of continuous Medicare Part A and Part B coverage

• Risk Scoring: Receive full HCC hierarchy application with complete risk adjustment calculations

• Impact: CMS has sufficient historical data to apply comprehensive risk scoring methodology

New Enrollees:

• Definition: Members with less than 12 months of continuous Medicare Part A and Part B coverage

• Risk Scoring: Receive modified scoring approach with limited historical data integration

• Impact: CMS applies adjusted risk calculation methods due to insufficient claims history for full risk assessment

Strategic Tip: Plans get separate scores for each group and can choose which to use for payment strategies.

MOR vs. MAO-004: Know the Difference

Quick Comparison

MAO-004 File:

• Purpose: Comprehensive record of all accepted diagnoses

• Content: Everything CMS received and accepted from your submissions, regardless of payment impact

• Scope: Includes all diagnoses that passed CMS validation, even those that don't generate revenue

MOR File:

• Purpose: Payment-focused report showing only revenue-generating conditions

• Content: Only diagnoses that became paying HCCs after hierarchy application and filtering

• Scope: Filtered subset of MAO-004 that directly impacts your risk adjustment payments

Key Point: A diagnosis can be in MAO-004 but missing from MOR due to hierarchy rules or non-payment status.

Advanced Use Cases

Trending and Analytics

• Track HCC capture rates over time

• Identify seasonal patterns

• Monitor provider performance

Targeted Interventions

• Focus on members with gap opportunities

• Prioritize high-RAF potential diagnoses

• Optimize coding resources

Financial Planning

• Project revenue based on MOR patterns

• Budget for risk adjustment operations

• Forecast payment reconciliations

Your MOR Action Plan

Month 1: Foundation

• Set up MOR file access

• Choose report vs. data file format

• Create basic validation process

Month 2: Analysis

• Compare MOR to internal projections

• Identify top 10 coding gaps

• Build provider feedback reports

Month 3: Optimization

• Implement systematic gap analysis

• Create MOR dashboard

• Train providers on documentation impact

The Bottom Line

The MOR is your direct line to CMS's risk adjustment brain.

Every successful Medicare Advantage plan uses their MOR to:

• Validate payments before surprises

• Find revenue hiding in plain sight

• Build bulletproof audit defenses

• Optimize their entire risk adjustment machine

Ready to transform your MOR analysis? The data is waiting in your next monthly file.

At HealthDataMax, we help MAOs automate, decode, and act on MOR data—turning compliance requirements into revenue opportunities. Ready to see it live? Book a demo today.

Quick Reference

Key File Types: Report (human-readable) vs. Data (automated) Access Methods: MARx UI, EFT Mailbox, CMS Portal
Timing: Monthly (real-time) vs. Final (definitive) Applications: Validation, optimization, audit defense

Understanding the CMS MAO-002 Encounter Data Processing Status Report

The MAO-002 Encounter Data Processing Status Report is a foundational document provided by CMS to help Medicare Advantage Organizations (MAOs) understand the acceptance or rejection status of submitted encounter data. With growing emphasis on data accuracy and risk adjustment transparency, this report plays a pivotal role in compliance, reimbursement, and encounter data tracking. 

What Is the MAO-002 Report? 

The MAO-002 is a processing status report generated after a file passes all front-end validations and is processed through the Encounter Data Processing System (EDPS). It provides: 

• Disposition statuses: Accepted or Rejected 

• Error codes for all records and lines 

• Risk Adjustment (RA) assessment for diagnosis codes in EDRs and CRRs 

Beginning in May 2022, the MAO-002 also began including preliminary RA assessments such as Allowed, Disallowed, or Not Applicable. 

How the Header Line ('000') Works 

The '000' line in the MAO-002 identifies the encounter-level status: 

• If rejected, the entire encounter is rejected — even if line-level records are valid. 

• If accepted and at least one other line (001, 002, etc.) is accepted, the encounter is accepted overall. 

• If all lines are rejected, the header is also rejected (without error codes). 

Rejected Lines vs. Accepted with Errors 

• Rejected lines come with specific error codes and descriptions. 

• Accepted lines may also have informational error codes, prompting further review. 

MAOs are encouraged to carefully review Accepted lines with errors as they may affect data quality or payment. 

Preliminary Risk Adjustment (RA) Assessment 

The MAO-002 provides a preliminary assessment of each record’s diagnosis code RA eligibility. It may be used to track risk-adjustable diagnoses prior to monthly MAO-004 reporting. 

When discrepancies exist between MAO-002 and MAO-004, MAO-004 is considered the authoritative source. 

RA Flag Definitions: 

• Blank: RA status not applied 

• PA (Preliminary Allowable): EDR/CCR is potentially risk adjustable 

• PD (Preliminary Disallowable): Not eligible for risk adjustment 

• PN (Preliminary Not Applicable): Encounter not applicable for RA 

• FR (Final Reject): Rejected by EDPS on MAO-002 

MAO-002 Report Layout Summary 

Header Record Fields: 

• Record Type, Report ID ("MAO-002"), Report/Transaction Dates 

• Report Description: "Encounter Data Processing Status Report" 

• Submission Interchange Number, File Type (TEST or PROD) 

Detail Record Fields: 

• MA Contract ID 

• Plan Encounter ID (Claim Control Number) 

• Encounter ICN 

• Preliminary RA flag: PA, PD, PN, FR, Blank 

• Reason codes (PH = CPT/HCPCS not allowable, PT = Type of Bill not allowable) 

• Encounter Line Number, Encounter Status (Accepted/Rejected) 

• Error Code and Description 

Trailer Record Fields: 

• Totals for: processing errors, lines accepted/rejected/submitted 

• Totals for: records accepted/rejected/submitted 

All fields are clearly labeled with fixed-length formatting, making the report both machine-readable and suitable for human review. 

Final Thoughts: Why the MAO-002 Matters 

The MAO-002 is more than a status report; it is a strategic compliance tool. It enables: 

• Accurate encounter data validation 

• RA eligibility tracking 

• Targeted resubmission of rejected encounters 

• Comparison with MAO-004 data for audit readiness 

By understanding and using MAO-002 reports effectively, MAOs can minimize revenue leakage, maintain audit readiness, and ensure CMS-compliant submissions. 

 Demystifying Risk Adjustment: Why It Matters in Medicare Advantage

In the world of Medicare Advantage (MA), where healthcare outcomes and financial models intersect, Risk Adjustment plays a pivotal role in ensuring fairness, transparency, and sustainability. But what exactly is risk adjustment, and why does it matter to providers, payers, and patients alike? 

Let’s break it down. 

What is Risk Adjustment? 

Unlike traditional Fee-for-Service (FFS) Medicare, where providers are paid based on services rendered, MAOs receive monthly capitation payments per member, adjusted for each enrollee’s predicted healthcare costs (risk score), regardless of the actual services used.

However, some members require more care than others. That’s where Risk Adjustment comes in. 

Risk Adjustment is CMS’s method of modifying payments to MAOs based on the predicted healthcare costs of their enrollees. 

If a member is expected to incur higher medical costs (based on age, gender, and diagnoses), the MAO gets a higher payment. This helps prevent plans from "cherry-picking" healthier members and encourages better care for complex patients. 

Where Does Risk Adjustment Data Come From? 

There have been two main data sources: 

1. RAPS (Risk Adjustment Processing System) was used since 2004, where MAOs submitted only select risk-relevant diagnoses. Starting with payment year 2022, CMS transitioned fully to the Encounter Data System (EDS), which requires submission of all medical encounters, providing a more comprehensive data set for risk adjustment.

2. Encounter Data Processing System (EDPS) – Introduced in 2012, this is a more complete data submission method where MAOs submit all medical encounters (like FFS claims), not just risk-relevant ones. 

Key difference: 

RAPS submitted a filtered set of risk-relevant diagnoses chosen by MAOs, while EDS submissions include the full spectrum of encounters, allowing CMS to identify risk conditions more comprehensively

This shift moves responsibility for identifying risk adjustment diagnoses from the MAOs to CMS, helping ensure more transparency and consistency. 

How Does the Process Work? 

It’s a collaborative cycle: 

1. Providers treat patients and generate medical records. 

2. MAOs collect and review this data. 

3. They submit encounters to CMS through EDPS. 

4. CMS checks for errors and either accepts or returns files. 

5. MAOs correct errors (if any) and resubmit for final approval. 

It’s a cycle of validation — ensuring only accurate and complete data contributes to payment decisions.

Who Uses This Data — and Why? 

Users 

• Medicare Advantage Organizations (MAOs) 

 Licensed entities (often insurers) contracted by CMS to deliver Medicare Advantage benefits. 

• Centers for Medicare & Medicaid Services (CMS) 

 Uses encounter data to calculate accurate payments and ensure proper use of federal funds. 

Stakeholders 

• Medicare Beneficiaries 

 While they don’t directly interact with risk scores or claims data, their medical care and diagnoses directly influence MAO payments — and thus access to care. 

Accurate risk adjustment means better funding for plans serving high-risk populations, and fewer incentives to avoid enrolling complex patients. 

Why It Matters 

With the shift toward value-based care, CMS is continuously refining how risk adjustment works. MAOs must adapt by improving coding accuracy, data quality, and submission compliance. Providers, coders, and IT systems all play a role in this ecosystem. 

At its core, risk adjustment is about fairness — ensuring health plans are paid accurately to serve every patient, from the healthiest to the most complex. 

Final Thoughts 

As CMS continues to evolve payment models, organizations that embrace the power of data, quality coding, and collaborative workflows will thrive. 

At Health Data Max, we help healthcare organizations optimize risk adjustment through advanced tools, education, and technology. From encounter validation to AI-powered audit platforms, we make compliance easier and more impactful. 

Have questions about improving your risk adjustment process? Reach out — we’re here to help.