Medicare Wants a Three-Second Claim But Still Owes a Fourteen-Day Wallet: Inside the ClaimsCore Re-Platforming Draft, the MAP Bridge, and Why Sub-Second Adjudication Cannot Pay Providers Any Faster
🎧 Part I Podcast free on Spotify.
🎧 Part II Podcast episode for paid subscribers only. Also available on Spotify.
To listen to paid episodes in Apple or Spotify, link your Substack subscription via the show settings on those platforms (instructions inside the Substack app under Subscriptions → Podcast).
Abstract
The July 2026 Original Medicare blog says CMS wants to modernize claims processing toward real-time claims. That is a direction, not a build. Treat it as intent.
The concrete target lives in an earlier, less-hyped document: the ClaimsCore Request for Information and draft Statement of Objectives, with responses due January 8, 2026. It contemplates replacing FISS, MCS, the DME system, and the Common Working File with a commercial cloud platform. It is not an award, but it has since been followed by a competitive multi‑phase RFP with an initial schedule.
The estate CMS wants out of: roughly 1.2 billion claims a year, more than 460 billion dollars, about 33.6 million Original Medicare beneficiaries, COBOL and Assembler on mainframes, nightly batch, VSAM and flat-file history, and policy changes that can take 7 to 12 months to code.
There is already a live bridge, MAP, running in limited parallel with legacy processing, and even that small step needed continuity with CWF, IDR, NCH, CCW, and existing status transactions. Migration, not adjudication, is the actual hard part.
The punchline for anyone with working capital at stake: even a three-second yes hits a 13-day statutory payment floor and a 30-day clean-claim ceiling. Congress owns the floor, not CMS. Fast decision, same wallet.
Faster also means riskier. A machine-speed system magnifies the blast radius of stolen credentials and bad routing. The February 2024 Change Healthcare attack, which federal analyses and subsequent OCR reporting describe as affecting tens of thousands of providers and exposing data on approximately 192.7 million individuals across payers and providers, is the standing warning.
Table of Contents
The headline everyone gets wrong
What CMS actually said in July, and how to label it
The prehistory nobody reads: a 2025 listening session and a quiet bridge
The legacy estate: 1.2 billion claims and a lot of COBOL
What the ClaimsCore draft actually asks for
Migration is the whole ballgame
Five flavors of real time and one EDI state machine
The fourteen-day floor Congress still owns
Who eats the risk: clearinghouses and the Change Healthcare shadow
Speed is not modernization without parity
The headline everyone gets wrong
The easy version of this story is “CMS wants faster claims,” and that version is both true and useless. Everybody wants faster claims. The interesting version, the one that actually matters if you run a clearinghouse, a MAC, a revenue-cycle shop, or a fund with exposure to any of the above, is a three-part setup that pulls in different directions at once. CMS has a real, operating modernization bridge that handles a thin slice of volume today. It has a much bigger draft concept to rip out and replace the shared systems entirely. And it has a decades-old statutory payment clock that quietly guarantees sub-second adjudication cannot turn into sub-second cash without an act of Congress. Hold those three things in your head at the same time and the whole subject stops being a slogan and starts being an engineering and finance problem.
The reason people botch it is that the flashiest word, real-time, gets used to mean five or six different things that are not the same thing, and the difference between “the system decided instantly” and “the money moved instantly” is roughly the entire point. So this piece spends most of its time separating decision from cash, target from status, and ambition from the pile of legacy plumbing that ambition has to survive.
What CMS actually said in July, and how to label it
The July 2026 Original Medicare blog is the strategy layer, and it is careful. It says CMS intends to modernize claims processing to support real-time claims, new payment structures, and program integrity. That sentence is a compass heading. It is not a rule, a contract, a funded program, or a date. Nothing in it commits CMS to anything a provider or vendor can plan a budget around. The correct verb is “intends,” and the correct posture is to read it as the mission statement it is.
The blog matters mostly because it gives you permission to go read the actual target document, which is not from July at all and did not get a press release with balloons. That document is the ClaimsCore Sources Sought and RFI, with an attached draft Statement of Objectives, posted to the federal contracting system on January 8, 2026. This is where the concrete ambition lives. And the single most important label to slap on it is this: it is a draft acquisition artifact, a request for industry input, not an award, not a signed requirement, not a national timeline. Everything in it is a target CMS is floating, which is a very different animal from a commitment CMS has made. Say “contemplates” and “proposes,” never “will,” and never “has.”
The prehistory nobody reads: a 2025 listening session and a quiet bridge
Before ClaimsCore, there was a listening session, finalized July 30, 2025, on real-time claims processing and on ways to shore up Medicare’s EDI cybersecurity. That session set the table. It floated the early pilot concept, raised the premise of exchanging clinical data alongside claims, named the intermediary groups who would be affected, and gave CMS’s own account of the Change Healthcare disruption. If you want to understand why real-time and cybersecurity keep showing up in the same breath, this is the origin: the pilot idea and the breach post-mortem were literally in the same room.
Then there is the part almost nobody outside the plumbing knows about, which is that a bridge already exists and is running right now. Call it MAP, the newer processing platform that CMS has been standing up in limited parallel with the legacy professional‑claims and, by 2026, additional claim families as rollout expands. This is not a concept. It is live, at low volume, and the transmittals that operationalized it are worth knowing by name because they carry the actual lesson. One transmittal issued September 5, 2025 consolidated claim history between the legacy Multi-Carrier System and MAP so that status inquiries, the 276 and 277 exchange, would return consistent answers across both worlds for the first professional-claim slice. Another, issued December 31, 2025 with an implementation date of March 31, 2026, set up a daily snapshot file into the Integrated Data Repository and established limited parallel processing with downstream continuity.
Here is the tell buried in those two dry transmittals. Even a small, careful step onto the new platform required CMS to keep feeding legacy-format snapshots downstream and to preserve continuity with the Common Working File, the Integrated Data Repository, the National Claims History, the Chronic Conditions Warehouse, and the existing status transactions. The bridge could not just be a new front door. It had to keep every old room reachable. That is the first and loudest warning against anyone who describes a new adjudication engine as a clean swap. There are no clean swaps here. There is only migration with the lights kept on.
The legacy estate: 1.2 billion claims and a lot of COBOL
To understand why CMS is even entertaining a rip-and-replace, you have to look at the size and age of what it is replacing, and the ClaimsCore draft is refreshingly blunt about both. It sizes the current estate at roughly 1.2 billion claims a year and more than 460 billion dollars flowing through, using about 33.6 million Original Medicare beneficiaries as the sizing assumption. That is the volume a replacement has to eat without dropping a bite.
The technology underneath is exactly what you would fear and exactly what makes this hard. The draft describes COBOL and Assembler running on mainframes, nightly batch exchanges rather than continuous processing, and claim history sitting in VSAM and flat files, which are storage formats that predate most of the people who will be asked to migrate them. And it names the operational cost of all that age in the most concrete way possible: a policy change can take 7 to 12 months, or longer, to code and deploy. Sit with that number. When Medicare payment policy shifts, the system that pays the claims can need most of a year to catch up. That lag is not a bug someone forgot to fix. It is the accumulated weight of shared systems that have been patched, extended, and interwoven for decades, where touching one rule risks a dozen downstream behaviors nobody fully maps anymore.
So the case for re-platforming is not “new is shinier.” The case is that a nine-to-twelve-month change cycle on a 460-billion-dollar payment engine is a genuine liability, for agility, for program integrity, and for the ability to implement the very payment ideas the rest of this series is about. The AI-software payment taxonomy, the drug-price refunds, the ACO reporting, all of it eventually has to be executed by something, and that something currently speaks Assembler and runs overnight.
What the ClaimsCore draft actually asks for
The RFP target state reads like a modern platform wish list, and it is worth being precise about what is on it, because precision is what keeps you from overclaiming. ClaimsCore contemplates replacing FISS, the institutional Part A system, MCS, the professional Part B system, the DME claims system, and the Common Working File itself, folding them into a commercial cloud platform configured for Medicare and already expected to operate with more than two million active users and over 100,000 claims per day. On top of that, the draft seeks instant or sub-second adjudication, real-time status, configuration-driven policy so a rule change is a setting rather than a code release, prepayment program-integrity controls, open APIs, and interoperability across X12, REST and FHIR, and plain flat files for the systems that still need them.
The RFP also lays out proof‑of‑concept expectations, framed as challenges a vendor would have to meet, with measurable targets for things like sub‑second adjudication, fraud detection, and accuracy. And this is exactly where discipline earns its keep. Those metrics are comparative objectives in the competitive RFP and associated acquisition documents. They are not CMS performance results, they are not contractual service levels anyone has signed, and they are not a promised schedule. The three-second figure that people will inevitably quote is a target in a request for industry feedback, not a requirement CMS has adopted. Describe the proof of concept as proposed and challenge-based, never as awarded or achieved, and do not let a crisp number in a draft masquerade as a fact about a running system. Nobody has replaced Medicare’s shared systems. CMS has asked the market whether, and how, it might.
Migration is the whole ballgame
The adjudication speed is the part that makes headlines. The migration is the part that makes or breaks the project, and the draft, to its credit, basically admits this. A successful system, it says, would have to preserve hundreds of interfaces, migrate decades of claim history, extract legacy business rules into portable formats, explain the differences between old and new behavior, support parallel runs so the new engine can be checked against the old one, and avoid vendor lock-in so CMS is not trading one trap for another.
Read that list as a threat model rather than a feature list and it gets more honest. Hundreds of interfaces means hundreds of downstream systems, contractors, and data consumers who each assume the current formats and timing, and any one of them can break in a way that looks like a payment error. Decades of history means the new platform has to answer questions about claims adjudicated under rules that no longer exist, which is not a data-copy problem, it is a semantics problem. Extracting legacy rules into portable formats means somebody has to figure out what the COBOL actually does, including the parts that are load-bearing by accident, which is a genre of archaeology that has sunk many modernization efforts. Parallel runs mean you operate two systems at once for a while, which is more work and more cost, not less, during the transition. And the realistic rollout is family-by-family, MAC-by-MAC, slice-by-slice, exactly the way the MAP bridge started, precisely because a big-bang cutover on a 460-billion-dollar engine is how you end up on the front page.
The lesson the MAP transmittals already taught applies at full scale here. The hard part is not teaching a cloud platform to say yes or no quickly. The hard part is making sure that fast yes means the same thing everywhere it lands, in the status inquiry, in the remittance, in the data repository, in the accounting ledger, and in the historical record, for every claim type, under every rule vintage, without stranding a single downstream consumer. Speed is a demo. Semantic parity is the product.
Five flavors of real time and one EDI state machine
A lot of the confusion about real-time Medicare claims comes from the fact that current Medicare EDI already produces near-immediate responses, and people mistake those fast acknowledgments for fast payment. They are not the same, and the difference is a small state machine worth walking through, because it is the difference between “the system got my file” and “the money is in the account.”
When a claim goes in, the first thing back can be a TA1, which addresses interchange acceptance, basically whether the envelope was readable. Then a 999 addresses syntax and implementation, whether the claim was well-formed. Then a 277CA handles claim-level front-end acceptance and assigns a control number, which is the first point where the claim is a real, tracked thing in the system. Later, a 276 inquiry and its 277 response return claim status, telling you where the claim sits in processing. And finally an 835 carries the remittance and the adjustment detail, the document that explains what was paid and why. Several of those messages can come back fast, even today. Not one of them, on its own, proves that money has settled in a bank. A 277CA is not a payment. A 277 status of “processed” is not cash in hand. The 835 is the closest thing to the truth, and even it describes a payment rather than being the payment.
So when a document or a vendor says real-time, the useful reflex is to ask which of these it means. Real-time interchange acceptance, real-time syntax validation, real-time front-end acceptance, real-time status, real-time remittance, and real-time funds movement are six different claims, and only the last one touches your working capital. The ClaimsCore draft is mostly talking about the decision, the adjudication, being fast. That is genuinely valuable, because faster decisions mean faster certainty, faster explanations, faster exception handling, and fewer claims stuck in limbo. It is just not the same as faster money, and conflating the two is the single most common error in this whole subject.
The fourteen-day floor Congress still owns
Now the paradox that makes this installment fun, or infuriating, depending on your role. For clean electronic claims, the Medicare Claims Processing Manual and the Social Security Act impose a payment floor of 13 days, which makes the 14th day the earliest a routine electronic claim is ordinarily paid. Clean claims also face a payment ceiling of 30 days, after which interest starts accruing. Those clocks live in statute, in the parallel Part A and Part B provisions, which means they apply to institutional and professional claims alike and, crucially, they are not CMS’s to move by regulation.
Put the two facts side by side and the tension is almost comedic. CMS can, in principle, build a system that adjudicates a clean claim in under a second. It cannot, without Congress changing the underlying law, pay that clean claim any sooner than day 14 as a routine matter. The decision engine and the disbursement clock are governed by different masters. So sub-second adjudication delivers a real and worthwhile set of benefits, faster certainty about whether you will be paid, faster and clearer explanations when you will not, real-time status, and quicker handling of the weird edge cases, but it does not and cannot, by itself, produce immediate ordinary payment. A three-second claim still meets a fourteen-day wallet.
This is why the language matters so much and why sloppy phrasing here is genuinely misleading. The defensible terms are real-time adjudication and real-time payment determination. The term to avoid, unless a source specifically establishes that funds are moving instantly, is real-time payment, because it tells providers and investors something about cash that the underlying facts do not support. The most important sentence CMS could modernize is arguably not in any rule it controls. It is a payment floor written into the statute, and until that changes, the working-capital math for provider finance stays roughly where it has always been.
Who eats the risk: clearinghouses and the Change Healthcare shadow
There is a comforting intuition that a faster, more automated system means less operational risk for the intermediaries in the middle. The opposite is true, and it is not close. Machine-speed decisions magnify the consequences of everything that can go wrong upstream: stolen credentials, misrouted responses, replayed transactions, and compromised submitter authority all get worse when the system acts on them instantly and at scale. Speed is a force multiplier, and it multiplies the bad along with the good.
Which is why the existing EDI rulebook already leans hard on the intermediaries, and why it will lean harder as speed increases. The Medicare EDI requirements make clearinghouses hold their own credentials, act only for providers and transactions they are actually authorized to handle, keep that submitter authority transaction-specific rather than blanket, preserve minimum-necessary access to data, and route each response only back to the provider who initiated it. Every one of those controls is really an answer to a specific way the plumbing can be abused, and every one of them gets more load-bearing when the plumbing runs at machine speed.
The February 2024 Change Healthcare attack is the concrete reason none of this is abstract. CMS and other federal analyses now frame that event as affecting a very large share of U.S. providers, with data exposure estimates approaching 193 million individuals across providers, payers, and pharmacies, and it is the case study that put EDI cybersecurity in the same sentence as real-time claims in the first place. A single compromised node in a highly connected, fast-moving claims network is not a local outage. It is a systemic event. So the honest read for anyone in the intermediary business is that modernization raises the stakes on identity, authorization, availability, and reconciliation rather than lowering them. The faster the yes, the more it matters that the yes was asked by the right party, about the right claim, and delivered to the right place.
Speed is not modernization without parity
Strip away the slogan and the subject resolves into a fairly clear-eyed set of statements. CMS wants faster claims processing and has said so at the strategy level. The concrete target for that ambition is a draft acquisition concept, ClaimsCore, that contemplates replacing the shared systems with a cloud platform, and it is a target, not a done deal or a schedule. There is already a live, low-volume bridge, MAP, whose main lesson is that even a tiny step onto new rails required keeping every legacy connection intact. The estate being modernized is enormous and ancient, and the case for change is real, driven as much by a nine-to-twelve-month policy-change cycle as by raw speed. Migration, not adjudication, is the part that will actually determine success or failure. And the money, thanks to a statutory floor that CMS does not control, does not get faster just because the decision does.
The test to apply to every future claim about this, from CMS, from a vendor, or from a breathless analyst, is whether a fast decision stays explainable, authorized, reconcilable, and correctly posted everywhere downstream. A system that decides in three seconds but cannot answer a status inquiry consistently, or cannot reconcile against the ledger, or strands a downstream data consumer, has not modernized anything. It has just gotten quicker at creating problems. Speed without semantic parity is a demo, not a payment system, and the difference is exactly the thing worth watching as this moves from a January RFI toward whatever it eventually becomes
.