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.