Good Luck, ClaimsCore

CMS just hired two contractors to do what no one has managed to do in thirty years. Here’s why that’s harder than the announcement suggests.

Grace Hopper was born in 1906. The COBOL mainframe she helped create is still processing Medicare claims. She died in 1992. The mainframe hasn’t.

Yesterday, the Centers for Medicare and Medicaid Services awarded nearly $2 billion to two contractors—Peraton and HealthEdge—to finally replace the COBOL core at the heart of Medicare’s fee-for-service claims processing. The program is called ClaimsCore. It will attempt to replace four legacy systems that together process 1.2 billion claims and $460 billion in annual payments. The target completion date is November 2033.

This effort deserves serious attention as a test of whether the federal government has learned anything from a thirty-year record of trying and failing to do exactly this.

What CMS Is Actually Trying to Do

The legacy systems ClaimsCore will replace—FISS, MCS, DME, and the Common Working File—were built in the 1970s on COBOL and IBM mainframes. They’re not just old, they’re architecturally incompatible with what modern program integrity requires.

The systems run on nightly batch processing, meaning claims are adjudicated in overnight cycles rather than in real time. Data is siloed across regional contractors called Medicare Administrative Contractors, with no unified national view. Fraud patterns that span multiple regions or provider types are invisible until after the money has moved. And policy changes that would take hours in a modern system take seven to twelve months in the current one, because the business logic is buried in brittle COBOL code that no one fully understands and almost no one can still read.

The CMS Statement of Objectives (SOO) for ClaimsCore lists fifteen distinct challenges with the legacy environment—from the inability to implement new payment models to the absence of real-time claims status for providers and beneficiaries. Among the most important: fraud prevention. The SOO calls for “pre-payment risk scoring,” “real-time anomaly detection,” and “cross-MAC data unification” to catch fraud before payments go out rather than years later, when the money is long gone.

That promise is what makes this procurement so vital. Medicare loses well over $100 billion annually to fraud—a figure driven in large part by the same architectural weaknesses ClaimsCore is meant to fix. Billing for services never rendered, DME equipment shipped to patients who never requested it, synthetic identities constructed to pass enrollment checks that were never designed to catch them. The current systems were not built to ask whether the entity submitting a claim is who it says it is. ClaimsCore, if it delivers what the SOO promises, would be a genuine leap forward in the government’s ability to protect that money.

But the question is whether it will deliver, and the government’s history with these kinds of efforts is littered with failure.

The History CMS Is Hoping to Escape

Way back in 1997, GAO reported that the Health Care Financing Administration—CMS’s predecessor—had planned to develop “one unified computer system to replace the existing system.” The project encountered problems from the beginning. HCFA terminated both the request for proposals and the software development contract. It had not even begun to test the feasibility of using commercial software to process Medicare claims until about a year after GAO first reported on its potential. The systems that were supposed to be replaced kept running.

That was nearly thirty years ago.

But the attempt didn’t stop there. CMS has been running various modernization initiatives under different names ever since. The Medicare Payment System Modernization program, launched in 2018, has focused on converting individual COBOL “pricers”—the tools that calculate reimbursement rates—to modern APIs hosted on AWS. It has only converted five pricer applications over several years. At that pace, the broader replacement project would take generations. The COBOL core itself has remained untouched.

This isn’t a CMS-specific failure. It is the defining pattern of government technology modernization. California spent more than twenty years and hundreds of millions of dollars trying to modernize its Employment Development Department’s unemployment system. The effort traced back to 2003 and was initially supposed to be finished by 2008. Deloitte was brought in as lead systems integrator in 2016, with hundreds of millions more in contracts to follow. The strategy was to modernize the front end first, and replace the COBOL payment core last, once the surrounding systems were stable and tested.

In practice, deferring the core replacement meant the most fragile part of the system was left doing the hardest work for the longest time. When COVID-19 arrived, the EDD was mid-transition—the worst possible condition to absorb a once-in-a-century shock. The COBOL payment engine couldn’t scale. The new components were not yet independent and fraud controls had been deprioritized throughout the redesign because the dominant goal, before the pandemic, was speed of payment. The rest is history—industrial-scale fraud flooded in through the gap. California’s losses from pandemic unemployment fraud ran into the billions.

Louisiana offers a shorter, starker version of the same story. In 2025, the state declared a public emergency because its motor vehicle system—a fifty-year-old COBOL mainframe—could no longer issue driver’s licenses. The system had been delivering just enough reliability to justify deferring replacement. When it failed, it failed completely, taking an essential public service offline for two months.

All these cases—and many more like them across government— share a set of structural forces that make replacing a mission-critical COBOL system one of the hardest things a government agency can attempt. The system cannot be turned off, the business logic exists only in undocumented code, requirements keep changing while the replacement is being built, and every incremental improvement to the old system makes the eventual replacement slightly harder and easier to postpone.

Why This Time Is Not Obviously Different

The ClaimsCore SOO is, in meaningful ways, better-designed than its predecessors. The most significant structural improvement is the challenge-based acquisition. Rather than selecting a single vendor on paper and handing them a billion-dollar contract to build something, CMS awarded both Peraton and HealthEdge contracts to run competitive proof-of-concept phases against real CMS data.

The headlines describe this as a $2 billion procurement, but the actual obligated amounts at award were $9.1 million for Peraton and $2.5 million for HealthEdge — roughly $11.6 million combined. The remaining ceiling value sits in unexercised options that only activate if CMS chooses to advance a vendor to production, and only one vendor will. The competition is just beginning.

That structure is smart. The traditional government IT procurement hands a contractor the keys after a proposal review, then spends years discovering what the proposal glossed over. Running two platforms in parallel against live claims data, measuring parity with the legacy system, and forcing vendors to demonstrate actual performance before the real money flows is a genuine departure from how these projects have historically been run. The data rights and vendor lock-in protections in the SOO are also unusually specific: quarterly portability drills, vendor-neutral rule exports, step-in rights if a vendor fails. These reflect hard-won institutional memory on CMS’s part, and they deserve applause.

But a better procurement design is not the same as a solved problem. The PoC phase will test whether either platform can adjudicate Medicare claims with 95% outcome alignment against systems that have been accumulating undocumented business logic for fifty years. That is a formidable bar and clearing it in a controlled PoC environment is a different challenge from sustaining it while processing $460 billion in live annual payments across a seven-year migration.

But the SOO also catalogs, with impressive precision, every reason this could fail.

Fifteen distinct challenge areas mean fifteen distinct points of failure. The SOO describes a system so brittle that policy changes take seven to twelve months, business logic is “opaque and scattered,” and there is no model office environment to test changes before they go live. Retroactive claim reprocessing takes months or years and the system cannot run real-time analytics because data is stored in VSAM files—a flat-file format from the 1970s—that are “siloed” and “non-relational.”

Each of these problems must be solved in a live environment, while the system continues to process $460 billion in annual payments without interruption. The SOO is explicit about this constraint: “incremental delivery and parallel operations to maintain current processing throughout migration.” That is the “can’t turn it off” problem in contractual language.

The SOO’s projected timeline runs to November 2033—seven and a half years from contract start. That is a long time in a threat environment that evolves in months. It is also, if history is a guide, an optimistic estimate. The IRS has been trying to retire its Individual Master File—written in Assembly language, which predates COBOL—for more than twenty years. It once promised the system would be retired by 2028. That timeline has slipped repeatedly and the system is still running.

There is also the SaaS assumption. ClaimsCore is built around a commercially available, off-the-shelf platform—configured and extended by the awardees rather than custom-built. The theory is that a mature commercial health plan claims platform should encode decades of industry best practice in ways that custom government software never could. HealthEdge’s HealthRules platform has real health plan customers today.

But a commercial health plan platforms has never processed Medicare fee-for-service claims at federal scale—1.2 billion annually, across every provider type, subject to every rule in the Medicare Internet-Only Manuals and every published CMS Change Request, administered through a network of regional contractors with their own local configurations. The IOMs cover everything: billing rules for every provider type, coverage determinations, claims processing instructions for the MACs, medical review policies, benefit integrity guidance. They run to thousands of pages across dozens of volumes. When Congress passes a new law or CMS issues a policy change, the operational translation of that change eventually lands in the IOMs as a Change Request — and every Change Request has to be coded into the claims processing systems.

The SOO’s features and functionality appendix includes dozens of highly specific Medicare requirements: Prospective Payment System processing, coordination of benefits with the CWF, NCCI edits, MUE edits, integration with iQIES patient assessments, Health Professional Shortage Area bonus calculations. Each of these is a configuration task, each with a potential source of parity errors during parallel run. The SOO requires 95 percent outcome alignment with the legacy systems, with 100 percent explainability of differences. Getting there will be the work of years.

The Fraud Promise Is the First Thing to Go

The SOO’s fraud prevention language is specific and ambitious. Pre-payment risk scoring, real-time anomaly detection, and cross-MAC data unification that allows analysts to see fraud patterns spanning multiple regions. And it calls for integration with CMS’s Fraud Prevention System. These are capabilities that the current architecture cannot deliver, and they would represent a genuine advance in Medicare’s ability to protect taxpayer funds. But they are also exactly the capabilities that have been promised—and deferred—in every prior modernization effort.

California’s EDD deprioritized fraud controls throughout its modernization because the dominant concern before the pandemic was access and speed. Fraud prevention required additional verification steps that slowed processing and attracted criticism when legitimate claimants experienced delays. The rational institutional choice was to defer the harder work.

The same dynamic plays out in federal programs across government with regularity. Emergency funding and operational continuity crowd out the investment in pre-payment controls, and fraud prevention analytics require data integration work that is expensive, slow, and invisible to program beneficiaries. The incentive structure rewards speed of delivery and discourages the friction that good fraud controls create. Without explicit leadership accountability for fraud outcomes—not just delivery milestones—the rational bureaucratic choice is to get the system running and treat the fraud controls as phase two.

Phase two, in government IT, has a way of becoming phase never.

The current systems process roughly $460 billion in annual Medicare fee-for-service payments through an architecture that was never designed to ask whether the entity submitting a claim is who it says it is. South Florida alone has produced Medicare fraud schemes measured in the hundreds of millions—billing for DME never delivered, genetic tests no patient requested, telemarketed procedures no doctor actually ordered. These schemes persist because the payment infrastructure makes them easy. The money moves before the review happens, and by the time it does, it is gone.

ClaimsCore could change that. A real-time claims adjudication platform with pre-payment risk scoring and cross-MAC analytics would put the government’s fraud defenses on a footing that the current systems cannot approach. The SOO describes exactly that system, and that is laudable; but whether the complexity of building it will once again force the fraud controls to the back of the implementation queue, delivered late or not at all, while the core payment infrastructure absorbs all available resources, is an open question.

What Watching Closely Looks Like

Taxpayers badly need this procurement to succeed. The COBOL systems running Medicare’s claims processing are a fraud subsidy, paid by taxpayers, extended indefinitely through deferred modernization. Replacing them with a real-time, analytically capable platform is a vital goal. The SOO’s competitive structure, data rights protections, and outcome-based metrics reflect real institutional learning.

But the announcement is not the achievement. Seven and a half years is a long time to sustain the political will, the technical focus, and the institutional prioritization that a project of this complexity demands. The pattern—ambitious scope, deferred core replacement, fraud controls subordinated to operational continuity, mid-transition collapse under stress—is well-documented and has defeated smarter plans than this one.

A few things are worth watching as ClaimsCore unfolds. First, whether the fraud prevention capabilities—the pre-payment risk scoring and cross-MAC analytics—are built early or deferred. If they appear in the last option period, that is California’s EDD all over again. Second, whether the proof-of-concept phase produces genuine parity evidence or optimistic variance reports that paper over gaps. Third, whether the 2033 timeline holds or begins to slip in the first two years—schedule pressure is usually where the hard trade-offs begin, and fraud controls are typically the first line item to absorb them.

The GAO estimates that the federal government loses up to $521 billion annually to fraud. Much of that money flows through systems that are structurally incapable of stopping it. CMS just committed $2 billion and seven years to change that for Medicare. Whether it succeeds will depend less on the procurement design — which is genuinely better than what came before — and more on whether the people running this program can sustain the discipline the design demands.

That means holding the PoC parity standards rather than papering over gaps to hit a milestone, and treating fraud prevention as a delivery requirement with the same contractual weight as uptime and latency, not something to be phased in once the hard work is done. And it means maintaining governance continuity across what will be at least two administrations and multiple CMS leadership cycles — the same instability that derailed California’s EDD effort and every other long-running modernization that lost its institutional memory mid-stream. And it means resisting the oldest temptation in government technology: declaring the announcement an achievement, the contract a solution, and the press release a delivery. The COBOL systems still running Medicare today survived thirty years of announcements exactly like this one.

The criminal networks targeting Medicare already know which systems can stop them and which ones cannot. ClaimsCore is a bet that the government can finally close that gap. Historically, those bets have not paid off. This one needs to.