EDGE Server business rules, made operational.
Every enrollment, medical, pharmacy, and supplemental diagnosis file you send to the HHS-operated EDGE server is checked against hundreds of rules before a single record counts toward risk adjustment. Here's how that pipeline works — and how Health Data Max catches the rejects before CMS does.
Reference: CMS / CCIIO EDGE Server Business Rules (ESBR) and the EDGE Server Interface Control Documents (ICD)
Only accepted records get paid.
Issuers in states where HHS operates a risk adjustment program submit their data to an EDGE server, where it is verified level by level. Accepted records are the only records eligible for Risk Adjustment (RA) and High-Cost Risk Pool (HCRP) calculations — so a rejected claim isn't just an error to fix later, it's revenue and compliance risk sitting outside the model. CMS receives only aggregated, summarized results; the detailed accept/reject reporting comes back to you, and reconciling it is on you.
Different files, different submission logic.
The single most important operational distinction: enrollment is a full replacement each time, while all three claim files are incremental. Sending a claim file as a "full" resubmission gets those claims rejected as duplicates.
Enrollment
A complete replacement file inclusive of all enrollees — each submission fully supersedes the prior one. CMS recommends monthly submission.
- Subscriber vs. non-subscriber / dependent requirements
- Enrollment start/end dates and periods crossing calendar years
- Dual and overlapping coverage handling
- Premium amounts, partial-month premium, and disenrollment
- Enrollment Period Activity Indicators (EPAI) and mandated coverage
Medical claims
The most rule-dense file. Submitted incrementally; header-level and line-level checks both apply, and full-file resubmission triggers duplicate rejections.
- Claim header ↔ claim line dependencies
- Header and line duplicate checks (with modifier exceptions)
- Voiding and replacing previously submitted claims
- FFS vs. capitated and mixed-claim submission
- Overlapping inpatient stays, interim billing, cross-year claims
Pharmacy claims
Incremental submission with its own duplicate, void, and replace logic distinct from medical claims.
- Header, issuer, and plan-level rules specific to pharmacy
- Duplicate pharmacy claim detection
- Claim Processed Date Time rules
- Voiding and replacing pharmacy claims
- FFS and capitated claim submission
Supplemental diagnosis
Incremental add/delete records that adjust the diagnoses tied to previously accepted claims — a common source of quiet rejects.
- Acceptable sources, including diagnoses from health assessments and medical records
- Duplicate supplemental detail record checks
- Adding and deleting supplemental diagnosis codes
- Voiding supplemental diagnosis detail records
- Linkage back to the original accepted claim
The verification pipeline, start to finish.
File processing is designed to evaluate as many data elements as possible before rejecting anything. It moves top-down through the XML — and a failure at the header level stops the file before it's ever archived.
File type verification
Structure is checked first. Pass, and a Job ID is assigned; fail, and no Job ID is created — you get a System Error (SE) report.
→Header level
Pass and the file is archived and continues; fail any header check and the whole file is rejected and not archived.
→Issuer & plan levels
Issuer- and plan-level verifications confirm the submitting entity and plan references before record detail is evaluated.
→Detail levels
Enrollee, enrollment period, and claim header/line segments each get required, face-validity, referential, and logical edits.
→Outbound reports
An ESFAR report is produced for every file, plus detail and summary accept/reject reports with specific reject codes.
Four edits, applied in two stages.
Every data element on every file runs the same gauntlet. Understanding the order is the key to fixing rejects fast — because an element that fails the first stage never even reaches the second.
Required
Confirms a non-null value is present in the data tag. Elements are Required, Situational, or Not Required per the ICD.
Face validity
Confirms the value conforms to the specified data type and restrictions (format, length, allowed characters).
Referential
Confirms the value matches an entry in the common reference data table set — codes, plans, and identifiers must exist.
Logical
Confirms the value satisfies the defined business logic — the cross-field, date, and dependency rules that make up most of this document.
Where submissions actually break.
Across all four files, the same categories of business logic account for most rejections. These are the areas worth validating before you submit — not after the reports come back.
Duplicates
Header- and line-level duplicate checks, plus the specific modifier and two-claim exceptions that determine when otherwise-identical lines are allowed.
Voids & replacements
Each file has its own multi-step void and replace sequence. Doing them out of order — or as a full resubmission — creates duplicate and orphan rejects.
FFS vs. capitated
Fee-for-service, capitated, and mixed-claim submissions follow different rules — and misclassification changes how a claim is processed and selected.
Dates & cross-year
Claim Processed Date Time, overlapping inpatient stays, interim billing, and enrollment periods that cross calendar years all carry precise date logic.
Enrollment integrity
Subscriber and dependent requirements, dual and overlapping coverage, premium changes, disenrollment, and EPAI values.
Supplemental linkage
Supplemental diagnosis adds and deletes must tie to accepted claims from acceptable sources — health assessments and medical records included.
Validate and correct before the file leaves your hands.
Health Data Max gives your team a working interface for all four inbound files — applying the same required, face-validity, referential, and logical checks the EDGE server will, so issues surface while they're still cheap to fix.
See rejects before CMS does
Every enrollment, medical, pharmacy, and supplemental record is checked against EDGE business rules in a clear UI — before submission, not after the accept/reject reports come back.
Guided corrections in-line
When a record trips a rule — a duplicate, a broken header/line dependency, an out-of-order void — the platform explains what failed and how to fix it, mapped to the actual reject code.
One database, continuously in sync
Inbound submissions and outbound EDGE reports live in one place, so accepted vs. rejected records reconcile automatically and nothing paid-eligible slips outside the model.
See what your EDGE submissions are leaving behind.
We'll run a complimentary evaluation of your risk adjustment data and show you where records are rejecting — and what that's worth. One recent pilot surfaced close to 40% of unclaimed revenue.
Book a demo →