One File Replaces the Daily Drip: Inside the New ESRDD

Starting August 2026, MARx will produce a brand-new monthly file: the ESRD Status Detail Data File (ESRDD). It's a complete, month-by-month picture of every dialysis and transplant period for your members — built, in CMS's own words, so plans can reconcile plan payments.

No rules changed. No policy shifted. This is a tool, not a mandate. But if you've ever tried to prove CMS paid you correctly for an ESRD member, you'll understand why it matters.

Reference: CMS memo, "Announcement of the MARx Software Release," July 10, 2026 — Shruti Rajan, Acting Director, Medicare Plan Payment Group, and Shauntia Bell, Acting Director, Enterprise Systems Solutions Group

The quick map: 1 new file · lands August 21, 2026 · monthly thereafter · 48-month lookback · full replacement each time

First — why ESRD is worth caring about

ESRD is End Stage Renal Disease: kidney failure. Members on dialysis, or who've received a kidney transplant.

These members are among the most expensive people a plan covers, and CMS pays substantially more for them. Which means the stakes on getting their status right are high — and historically, verifying that status against what CMS actually paid you has been genuinely painful.

Until now, ESRD status data arrived scattered across Daily Transaction Reply Reports (DTRRs) — daily drips of transactions you had to stitch together yourself. If your reconciliation depended on catching every one of those daily messages and assembling them correctly, any gap in your ingestion became a gap in your revenue picture.

The ESRDD fixes that. It contains all the ESRD data plans receive on the DTRR — but consolidated, monthly, in one place.

What the new file actually is

A comprehensive monthly source of ESRD dialysis and transplant data, delivered through MARx.

Here's what a business or operations reader needs to know:

When it arrives. The first ESRDD file goes out August 21, 2026. After that it's monthly, distributed with the rest of your monthly reports around the 20th of the month.

What's in it. All ESRD periods that overlap with plan enrollment — meaning it's scoped to your members, and it distinguishes dialysis periods from transplant periods, each with a start and end date.

How far back it looks. Each monthly file covers the current calendar month plus the 48 months prior — a rolling four-year window. So a file dated August 2026 reaches back to August 2022.

It's a full replacement, not a delta. This is the detail that matters most for your ingestion design. Every month you get the complete picture again, not just what changed. Don't build an append-only pipeline. Each file supersedes the last.

That last point is easy to miss and expensive to get wrong. If your team treats each monthly file as incremental and appends it to what came before, you'll end up with duplicated ESRD periods and a corrupted reconciliation baseline.

What to actually do with it

This part is our read, not a CMS instruction. The memo is purely informational — it tells you the file exists and describes its layout. It never tells you how to use it.

But the purpose statement gives the game away: this file exists so plans can reconcile plan payments. Here's what that means in practice.

Compare the file against what CMS actually paid you. You now have an authoritative monthly statement of who was in dialysis or transplant status, and for exactly which date ranges. Line that up against your payment records and the gaps become visible:

• Members you believed were ESRD, but CMS doesn't show as ESRD → you may have been expecting payment you won't receive. Better to find out now than at reconciliation.

• Members CMS shows as ESRD, but your systems missed → potential underpayment, or a data-capture gap worth investigating.

• Date-range mismatches — your records say dialysis started in March, CMS says May → a payment-period discrepancy sitting in plain sight.

Use the 48-month window for retrospective work. The rolling four-year lookback isn't decoration. It means you can audit historical ESRD status without hunting through years of archived DTRRs. That's a meaningful reduction in effort for any retrospective payment review.

The bottom line for operations: the daily-drip problem is solved. If ESRD reconciliation has been a manual, error-prone process at your organization, this file is the input that makes it systematic.

For the systems team: the full layout

Everything above is what a manager needs. What follows is what a developer needs. If you're not building the ingestion, you can stop here — you haven't missed anything.

File basics

• System: MARx Data File

• Frequency: Monthly

• Record length: 80 characters, fixed-width

File naming conventions

The name varies by transmission method:

• Gentran Mailbox / TIBCO MFT Internet Server: P.Rxxxxx.ESRDD.Dyymm01.Thhmmsst

• Connect: Direct (Mainframe): zzzzzzzz.Rxxxxx.ESRDD.Dyymm01.Thhmmsst

• Connect: Direct (Non-Mainframe): [directory]Rxxxxx.ESRDD.Dyymm01.Thhmmsst

The four record types

The file uses a header → beneficiary → detail → trailer structure. Record Type is always the first character.

Record Type 1 — File Header (one per file)

• Position 1: Record Type = 1

• Positions 2–6: Contract Number (5) — contract identification

• Positions 7–10: Start Year (4) — earliest year associated with the data

• Positions 11–14: End Year (4) — latest year associated with the data

• Positions 15–22: File Generation Date (8) — CCYYMMDD

• Positions 23–30: Current Calendar Month (8) — CCYYMMDD. This is the anchor for the 48-month window: the report covers this month plus the 48 months prior.

• Positions 31–80: Filler (50) — spaces

Record Type 2 — Beneficiary Identification Record

• Position 1: Record Type = 2

• Positions 2–6: Contract Number (5)

• Positions 7–18: Beneficiary ID (12)

• Positions 19–30: Last Name (12)

• Positions 31–37: First Name (7)

• Position 38: Middle Initial (1)

• Positions 39–46: DOB (8) — CCYYMMDD

• Position 47: Sex (1) — 0 or blank = Unknown, 1 = Male, 2 = Female

• Positions 48–80: Filler (33) — spaces

Record Type 3 — Beneficiary Detail Record (one or more per beneficiary — this is where the ESRD periods live)

• Position 1: Record Type = 3

• Positions 2–6: Contract Number (5)

• Positions 7–18: Beneficiary ID (12)

• Positions 19–21: Plan Benefit Package Number (3) — the beneficiary's PBP ID, spaces if none

• Positions 22–24: Segment Number (3) — spaces if none

• Position 25: ESRD (Dialysis/Transplant) (1) — D = Dialysis, T = Transplant. This single character is the heart of the file.

• Positions 26–33: Start Date (8) — earliest date associated with the data, CCYYMMDD

• Positions 34–41: End Date (8) — latest date associated with the data, CCYYMMDD

• Positions 42–55: Record Add Timestamp (14) — CCYYMMDDHHMMSS

• Positions 56–69: Record Update Timestamp (14) — CCYYMMDDHHMMSS

• Positions 70–80: Filler (11) — spaces

Record Type 4 — File Trailer (one per file)

• Position 1: Record Type = 4

• Positions 2–6: Contract Number (5)

• Positions 7–13: Record Count (7) — count of Type 1, 2, 3, and 4 records. Left-padded with zeroes.

• Positions 14–20: Beneficiary Record Count (7) — count of Type 2 records only. Left-padded with zeroes.

• Positions 21–80: Filler (60) — spaces

Two things to build for

The add/update timestamps on Record Type 3 are your change-detection mechanism. Because the file is a full monthly replacement, you can't diff by absence — but you can use the Record Add and Record Update timestamps to identify what moved since last month.

Validate against both trailer counts. The trailer gives you two independent checks: total records (all four types) and beneficiary records (Type 2 only). Use both. A file that passes one and fails the other tells you something specific about where ingestion broke.

Where to send questions

CMS points all issues on this release to a single place:

• MAPD Help Desk → 1-800-927-8069 or mapdhelp@cms.hhs.gov

Also note: these updates will be reflected in the August 2026 Plan Communications User Guide (PCUG). That's your authoritative reference once it publishes.

The bottom line

The ESRDD is a small release with a real payoff. One new monthly file, arriving August 21, 2026, that consolidates ESRD dialysis and transplant data into a single authoritative source — replacing the job of stitching it together from daily DTRR transactions.

Two things to get right:

1. Build for full replacement, not append. Each monthly file supersedes the last. Getting this wrong duplicates records and corrupts your baseline.

2. Use it for what it's for. Line the file up against what CMS actually paid you. The discrepancies are the point.

No policy changed here. But for anyone who has fought to reconcile ESRD payments, CMS just removed a significant source of friction.