A few weks ago, I published a blog article on the status of "ancient" claims processing systems at CMS - here.
By chance, I ran across a Q1 2026 Request for Information from CMS, discussing large-scale renewal of the creaky claims processing system. Find the RFI webpage here:
https://sam.gov/workspace/contract/opp/521fdf2c4dac48e48e0dbd5eb83a8df6/view
Where we read:
The Center for Medicare & Medicaid Services (CMS) seeks information regarding large scale claims processing and adjudication vendors to accomplish our objectives of improving beneficiary experience, reducing provider burden, and improving administrative efficiency in Original Medicare. CMS seeks responses to questions listed in this RFI. CMS may use information collected through this RFI notice in its evaluation of claims adjudication systems.
Here's an AI summary of several of the key RFI documents.
CMS is floating a very ambitious “ClaimsCore” procurement to replace the core Medicare Fee-for-Service claims-processing backbone: FISS, MCS, DME/VMS, and the Common Working File.
In plain English, CMS wants to move Original Medicare claims adjudication off old COBOL/mainframe shared systems and onto a modern COTS/SaaS-style configurable platform with real-time adjudication, APIs, better fraud prevention, faster policy changes, and better transparency for providers and beneficiaries.
This is not a small modernization project. It is essentially a proposed replacement of the operating system of Medicare FFS claims processing, covering roughly 1.2 billion claims annually and hundreds of billions in payment flow. The vision includes sub-second adjudication, real-time claims status, HIPAA X12 plus FHIR/REST APIs, configuration-driven edits and payment rules, fraud/risk scoring before payment, automated reprocessing, improved MAC workflows, and beneficiary-facing cost/claim clarity.
The procurement is being handled as a staged acquisition. The SAM.gov notice was originally an RFI / sources-sought notice, not yet a binding award commitment, and CMS supplied draft RFP materials for industry feedback. The draft solicitation then frames it as a commercial-products/services acquisition, unrestricted, NAICS 541512, firm-fixed-price, with a base Proof of Concept from Sept. 1, 2026 to Nov. 30, 2026, followed by up to seven option years through Nov. 30, 2033.
On “how deep does it get”: very deep technically and operationally, but still framed at an objectives/procurement level rather than as a final implementation blueprint.
The SOO (Statement of Objectives) goes far beyond buzzwords. It lists concrete legacy-system pain points: slow 7–12 month policy-change cycles, batch processing, siloed regional data, opaque COBOL business logic, VSAM/flat-file data, limited real-time analytics, retroactive reprocessing bottlenecks, security/resilience concerns, MAC workarounds, and lack of auditable policy logic. It also gets into cost drivers such as integration with systems like PECOS and HIGLAS, migration of decades of historical data, conversion of COBOL business logic, large-scale regression testing, parallel runs, APIs, security, Section 508, QASP, contractor personnel, demos, retrospectives, cloud/security requirements, and transition-in/out.
But the “Instructions to Offerors” show CMS is initially forcing vendors to stay concise. Phase 1 corporate experience is limited to five pages, focused on mission-relevant experience. The process then down-selects vendors before Phase 2, where PWS/QASP, past performance, price, COI, Section 508, and compliance are evaluated. CMS expects perhaps two to four awards, and technical/non-price factors are significantly more important than price.
Bottom line: this is CMS testing the market for a once-in-a-generation replacement of Medicare FFS claims infrastructure. It is not just “modernize claims software”; it implies rethinking claims adjudication, policy implementation, MAC operations, provider transparency, fraud prevention, data access, and beneficiary communication. The documents are detailed enough to reveal the architecture of CMS’s ambitions and pain points, but not yet detailed enough to prove how CMS will actually migrate, govern, validate, or politically survive replacement of the shared systems.
