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.