A previous blog entry provided a book chapter, written by Chat GPT, on Medicare claims processing software ("Is it really still in COBOL?")
Here is a second book chapter, by Claude Opus 4.8, which was given the earlier Chat GPT book chapter and asked to start again, and push it further in a new draft.
Offered as an example of current AI-managed writing products; not verified.
###
 |
| Version 2, this time by Claude Opus 4.8 |
Below as blog; see also as 9-page PDF.
###
CHAPTER by CLAUDE OPUS 4.8
The Machinery Beneath the Program
COBOL, the MACs, and the Common Working File
Every so often a senior official remarks, with a mixture of alarm and wonder, that Medicare still runs on COBOL. The remark is essentially true. It is also the least interesting thing one can say about how Medicare pays a claim.
1. The COBOL Question, Answered
Plainly
The observation
recurs on a reliable schedule, usually from someone newly responsible for the
program and freshly horrified by its plumbing. In early 2026 the administrator
of the Department of Government Efficiency told a value-based payment audience
that Medicare’s claims system traces to 1970s COBOL, cannot process in real
time, and does not play well with artificial intelligence or modern analytics.
A decade earlier the same sentiment surfaced in budget hearings; a decade
before that, in inspector-general reports. The phrasing changes, the
astonishment does not.
So let us
dispose of the headline first. Yes: the core fee-for-service claims engines are
written largely in COBOL and run on IBM mainframes under z/OS. The language
dates to 1959, not the 1970s, and the architecture accreted over roughly three
decades rather than springing from a single design, but the soundbite is
directionally correct. What it conceals is more useful than what it reveals.
The interesting questions are not about a programming language. They are about
why a confederation of private contractors, a handful of shared software
systems, and one quietly indispensable national database called the Common
Working File together manage to adjudicate something on the order of a billion
claims a year, worth well over $800 billion, for roughly sixty-five million
people, almost always correctly, and almost always overnight.
This chapter
takes the machinery apart. It describes who actually touches a claim, how much
discretion each party really has, what the Common Working File does that
nothing else can, and why “replace the COBOL” is a sentence that means far more
than it says.
2. Medicare Is Not a Computer. It Is
a Confederation.
The durable
misconception is that Medicare lives inside one enormous federal computer in
Baltimore that receives a claim, consults a rulebook, and writes a check. The
reality is a federated arrangement assembled in the program’s first decades and
never fully centralized since.
The Centers for
Medicare & Medicaid Services sets national policy: coverage rules, payment
formulas, the contents of the fee schedules, and the operating instructions
that bind everyone downstream. CMS does not, however, sit at the keyboard
adjudicating your hospital stay. That work is performed by private regional
contractors, the Medicare Administrative Contractors, or MACs, who won their
jurisdictions through competitive procurement and who process claims for
defined parts of the country and defined categories of service — A/B MACs for
hospital and physician claims, DME MACs for durable medical equipment, and Home
Health and Hospice MACs for those benefits.
The MACs, in
turn, do not run software of their own invention. They operate a small number
of CMS-owned standard platforms, the shared systems, maintained by separate
contractors and tested centrally before any change reaches production. Behind
all of them sits the Common Working File, the national layer that knows things
no single MAC can know on its own. The structure is best read as four tiers,
each with a distinct job:
|
Tier |
What it actually does |
|
CMS |
Sets national coverage and payment policy; owns
the fee schedules, the manuals, and the change-request stream that everyone
downstream must implement. |
|
MACs |
Receive, edit, price, and pay claims for an
assigned region and benefit type; issue local coverage policy and conduct
medical review within national limits. |
|
Shared systems |
The CMS-owned software (FISS, MCS, VMS) the
MACs actually run; one codebase per claim type, maintained centrally so a
rule changes once, not fifty times. |
|
Common Working File |
The national database of entitlement,
utilization, and benefit accounting against which every claim is checked
before it is paid; Medicare’s institutional memory. |
When an official says “Medicare runs on
COBOL,” this whole apparatus is what they have inadvertently described — not a
building in Maryland, but a coordinated, contractor-operated ecosystem with
deep federal roots.
3. Three Engines and Their Keepers
Almost every
fee-for-service Medicare claim flows through one of three claims-processing
shared systems, distinguished by who is billing:
•
FISS (the Fiscal Intermediary Shared System)
handles institutional claims — hospitals, skilled nursing facilities, home
health, and hospice — covering both the Part A inpatient world and the
institutional Part B outpatient world.
•
MCS (the Multi-Carrier System) handles
professional Part B claims from physicians and other practitioners.
•
VMS (the ViPS Medicare System) handles durable
medical equipment, prosthetics, orthotics, and supplies for the DME MACs.
The point of
having three shared systems rather than fifty contractor-specific ones is
consistency. When CMS changes a payment rule, the change is coded once into the
relevant shared system, regression-tested by a single testing contractor, and
pushed to every MAC that runs it on a synchronized quarterly release calendar.
A MAC in Florida and a MAC in Oregon therefore apply the same arithmetic to the
same code, which is the whole reason national payment policy is enforceable at
all.
These engines
are unmistakably of the mainframe era and not embarrassed about it. The DME
system, to take one documented example, is written in COBOL under IBM’s
Language Environment, stores its data in VSAM files, communicates through CICS,
reserves Assembler for the lowest-level utilities, and runs to several thousand
source modules with thousands of shared copybooks. As recently as 2020 CMS was
managing a phased upgrade of these systems to Enterprise COBOL 6.2 for z/OS —
which is the tell. This is not abandoned code mouldering on a tape. It is
living code, under active maintenance, compiled against current toolchains, and
changed on a fixed cadence. “Legacy” here does not mean neglected. It means
load-bearing.
4. The Journey of a Claim
To see where
each party fits, follow a single claim from submission to payment.
It begins as an
electronic transaction — an X12 837 — transmitted by the provider, usually
through a clearinghouse, to the appropriate MAC. The MAC’s front end translates
and validates the file, returning acknowledgments that confirm the claim was
structurally intelligible before anyone tries to pay it. A claim that fails
here never becomes a claim; it bounces.
Inside the
shared system, the real adjudication runs as a sequence of gates. The claim is
checked for basic validity and provider standing. Eligibility is confirmed —
increasingly by reference to the Common Working File rather than to local
copies, since CMS has been deliberately moving the authoritative eligibility
determination out of the individual engines and into the national one. The
claim is then priced against the applicable fee schedule or prospective-payment
methodology: a physician service through the fee-schedule logic, an inpatient
stay through the MS-DRG grouper and inpatient pricer, a hospital outpatient
service through the Outpatient Code Editor and the OPPS pricer, a laboratory
test through the Clinical Laboratory Fee Schedule.
Coverage and
coding edits run alongside pricing. National and local coverage determinations
are enforced; the National Correct Coding Initiative applies its
procedure-to-procedure edits and its Medically Unlikely Edits to catch
implausible combinations and quantities; frequency limits and bundling rules
fire. For molecular diagnostics, certain MACs layer on the MolDX program’s
requirement for a DEX Z-code identifying the specific assay — a
contractor-administered edit grafted onto the shared engine, and a useful
reminder that the edit set a given claim meets is partly national and partly
local.
Only then does
the claim go to the Common Working File for the national check. The CWF
compares it against the beneficiary’s nationwide record, applies utilization
and consistency edits, and returns a reply: accept, reject, or
accept-with-information. If the CWF approves, the MAC finalizes payment,
generates the electronic remittance advice (the 835) to the provider and the
notice to the beneficiary, and posts the financial transaction to the
government’s accounting system. Most of this happens in overnight batch cycles,
which is precisely the property modernizers find frustrating — and precisely
the property that has made it reliable for forty years.
5. How Much Latitude Does a MAC
Really Have?
Because the
MACs are private companies competing for the work, it is tempting to imagine
them as semi-autonomous payers improvising local rules. They are not, and the
boundaries of their discretion are worth stating precisely, because the answer
drives a great deal of real-world strategy.
Where a MAC has
genuine latitude is in the space CMS has left open. The clearest example is
local coverage. Where no national coverage determination governs a service, a
MAC may issue a Local Coverage Determination defining when the service is
reasonable and necessary in its jurisdiction — which is why a test can be
covered in one MAC’s territory and contested in another’s, and why so much
diagnostics strategy is really MAC strategy. A MAC also exercises judgment in
medical review: which claims to audit, which to subject to prepayment
documentation requirements, and how to apply clinical criteria at the margin.
Where CMS has delegated price-setting for a new code through gap-fill, the MAC
proposes the local price. And in operational programs such as MolDX, a MAC
builds and runs edits that other MACs may not impose at all.
Where a MAC has
essentially no latitude is everywhere CMS has already spoken. A MAC cannot
override a National Coverage Determination, cannot rewrite a statutory payment
formula, cannot ignore a national fee schedule, and cannot decline to run an
edit the shared system enforces. The operating instructions arrive as
transmittals and change requests against the Internet-Only Manuals — most
consequentially the Claims Processing Manual — and compliance is not optional.
The shared-system architecture is itself a discipline: a MAC cannot quietly
deviate from national logic because it does not possess its own logic to
deviate with. It runs CMS’s code.
The accurate
mental model, then, is bounded autonomy. The MACs are the program’s discretion
at the edges — coverage where national policy is silent, medical review where
judgment is unavoidable — riding on rails that CMS lays down and the shared
systems enforce. Understanding exactly where the rails end and the discretion
begins is most of what separates sophisticated Medicare strategy from wishful
thinking.
6. The Common Working File:
Medicare’s Institutional Memory
Of all the
components, the Common Working File is the least visible and the most quietly
essential, and it exists because of a problem that is easy to underestimate.
In Medicare’s
early decades, claims were handled by numerous regional carriers and fiscal
intermediaries, each of which could see only the slice of a beneficiary’s care
that happened to land in its own territory. A patient hospitalized in one
state, rehabilitated in a second, and sent home with services from a third
generated three separate, partial records that never met. The consequences were
predictable: duplicate payments nobody caught, utilization limits breached
because no one held the running total, deductibles accounted inconsistently,
and fraud that was invisible regionally but obvious nationally — if only
someone had been looking nationally.
The Common
Working File was built to be that someone. Phased in at the end of the 1980s
and operating nationally by the early 1990s, distributed across a set of
regional host sites that have since been consolidated, the CWF became the
single place where a beneficiary’s entitlement and accumulated activity are
reconciled across the entire program. It does not sit passively behind the
claims engines; it participates in adjudication. It confirms eligibility on a
national basis — Part A versus Part B, hospice election, Medicare Advantage
enrollment, and whether another payer is primary under the Medicare Secondary
Payer rules. It detects duplicates against the nationwide record. It maintains
the cumulative accounting on which benefits like skilled-nursing days, hospice
periods, and home-health episodes depend, since those are properties of a
history rather than of any single claim. And it coordinates the timing
relationships among admissions, transfers, and post-acute care that no
individual contractor could referee alone.
The effect of
all this was to convert Medicare from a loose federation of regional payers
into something that behaves like one national insurer. The CWF is the
synchronization layer that makes the confederation cohere. It is also, not
incidentally, the component whose loss would be least survivable — which is why
no one is in a hurry to replace it.
7. Why “Legacy” Is the Right Word,
and Not an Insult
Return now to
the COBOL complaint, because it can finally be answered well. COBOL survives in
Medicare for the same reason it survived in banking, payroll, and Social
Security: it was built for exactly this — high-volume, record-oriented
transaction processing that must be correct, consistent, and resilient at
enormous scale. Mainframes running COBOL did that job superbly, and they still
do.
But the
language is a red herring. The thing that is genuinely hard to replace is not
the syntax; it is the meaning encoded in it. A modern Medicare claim does not
merely get checked for arithmetic and paid. It must satisfy a dense,
interlocking body of operational law — a partial inventory of which gives the
flavor:
•
DRG and prospective-payment methodologies;
•
physician fee schedule calculations;
•
the clinical laboratory fee schedule;
•
bundling and correct-coding edits;
•
Medicare Secondary Payer coordination;
•
hospice election and benefit-period status;
•
end-stage renal disease coordination;
•
sequestration and other statutory payment adjustments;
•
frequency and medically-unlikely limits; and
•
home-health episode and post-acute timing rules.
Each of these is not a feature someone chose;
it is a rule Congress, a court, or a regulation imposed, and the code is where
that rule actually lives. The shared systems are, in effect, sixty years of
statute compiled into executable form. Replacing them is therefore not like
replacing a word processor. It is like translating a body of law from one
language to another without changing a single outcome — while the law continues
to be amended quarterly and the payments never stop. That is why the prudent posture
has always been gradual migration rather than a forklift replacement: a bad day
in claims processing is a national event.
8. Modernization Without a Forklift
None of this
means CMS has stood still. The active vehicle is the Medicare Payment System
Modernization initiative, a multi-year effort underway since the late 2010s to
move fee-for-service processing toward cloud-based, API-driven architecture
without interrupting the flow of payments. Its method is deliberately
incremental. Rather than rewrite the mainframe and hope, the program has
wrapped the legacy systems in modern interfaces — exposing the mainframe’s data
through APIs so that CMS staff and MACs are no longer captive to overnight
batch windows and green screens — and has begun extracting discrete pieces into
standalone services. The pricing logic is a good example: the downloadable
COBOL “pricers” that providers once ran locally are being reimplemented as
web-based, continuously updated services, which both modernizes the technology
and shortens the time it takes a policy change to reach production. The
expansion of Medicare dental coverage, notably, was built on a new cloud-native
dental claims system rather than bolted onto the old engines — a sign of where
the architecture is heading when it gets to start clean.
The standard
analogy is air traffic control: infrastructure that looks antique to outsiders
yet keeps running because reliability matters more than novelty, and because
the cost of a botched cutover is measured in catastrophe rather than
inconvenience. The analogy is fair as far as it goes, but it undersells the
specific difficulty here. Air traffic control modernization replaces hardware
and protocols. Medicare modernization must also preserve the semantic content —
the embedded policy — perfectly, because a translation error does not merely
slow a payment; it pays the wrong amount to the wrong party under the wrong
rule, at the scale of a billion transactions.
The critique
voiced by the program’s newest stewards — that the system cannot operate in
real time and was not designed for AI-era analytics — is genuinely correct, and
the desire for real-time adjudication and richer analytic access is reasonable.
The tension is that the very properties the modernizers find limiting (batch
processing, conservative change control, mainframe determinism) are inseparable
from the properties that have kept the system trustworthy. The hard work of the
next decade is not deciding whether to modernize. It is sequencing the
migration so that the encoded law survives the move intact.
9. Conclusion
The persistence
of COBOL and mainframes inside Medicare is not evidence of governmental
backwardness. It is evidence of the durability of an architecture built for
reliability and scale, and of the seriousness with which its operators treat
the consequences of failure. The Common Working File makes the point vividly:
almost no one outside the program has heard of it, yet it is the system that
lets a federation of regional contractors function as a single national
insurer, reconciling eligibility, utilization, and payment integrity across the
country, every night, without fanfare.
As CMS
modernizes, the central challenge will not be writing new code; capable
engineers can do that. The challenge is preserving the operational memory — the
decades of statute, court rulings, and regulation compiled into these systems —
while moving it onto architecture fit for the next half-century of healthcare
administration. Read correctly, then, Medicare’s technological history is not a
story about an obsolete programming language. It is a story about how
administrative law accumulates, hardens into infrastructure, and resists — for
good reasons and bad — being rebuilt. The COBOL is just the part you can see.
Notes and
Sources
The architectural
details (the FISS / MCS / VMS shared systems, the single testing contractor,
the COBOL-on-z/OS environment) and the modernization program described above
are drawn from public CMS contracting and guidance documents and from
contractor accounts of the Medicare Payment System Modernization effort. A few
primary references, with full URLs for pasting:
https://www.navapbc.com/case-studies/modernizing-payment-systems-medicare
https://www.bellese.io/newsroom/releases/cms-mpsm-extension-announcement/
https://www.hfma.org/technology/medicare-claims-processing-modernization-cms/
https://planetoit.cms.gov/articles/qa-medicare-system-payment-modernization
