Attachment 1 - ClaimsCore Statement of Objectives.docx

Statement of Objectives (SOO) – ClaimsCore Program Prepared by:

Centers for Medicare & Medicaid Services (CMS) The Center for Medicare (CM) The Digital Service at CMS (DSAC) United States DOGE Service (USDS)

Table of Contents

Product Vision The ClaimsCore program seeks to re-platform Medicare Fee for Service claims processing by replacing legacy “Shared Systems” including the Multi-Carrier System (MCS), Fiscal Intermediary Shared System (FISS) and Durable Medical Equipment Claims System (DME) as well as the Common Working File (CWF) with a flexible and interoperable platform that puts Medicare beneficiaries at the center of every decision. A Software as a Services (SaaS) Commercially-Available-Off-The-Shelf (COTS) product, configured and integrated by skilled teams, will deliver instant adjudication, policy agility, real time claims status, best in class tools, improved fraud prevention capabilities, and tighter integration across CMS, Medicare Administrative Contractor (MACs), providers, and partners.

Objectives

1. Replace Shared Systems and the Common Working File (CWF): Replace FISS, MCS, DME, and CWF with an enterprise class, real‑time platform while maintaining uninterrupted Medicare Fee‑for‑Service operations during transition. Such a replacement could transform the way FFS Medicare does intake, eligibility and coverage checks, edit/rules execution, payment determination, EOB/EOP generation, adjustments and reprocessing, reporting, and audit/traceability etc.

2. Beneficiary-first Experience: sub-second adjudication, faster explanations of benefits, and better visibility into patient responsibility.

3. Reduce Provider Burden: provider burden is reduced though increased transparency and consistency, shrinking administrative overhead, and improved revenue certainty.

4. Fraud, Waste and Abuse (FWA) reduction (i.e., Payment Integrity): speed and flexibility in designing and implementing pre-payment risk scoring and edits, improved payment accuracy, auditing, and anomaly detection to prevent improper payments and protect beneficiaries and taxpayers.

5. Policy Agility and Flexibility: configuration-driven rules to evaluate, back test, quantify impact, and implement new and alternative payment models without long code cycles.

6. Provider transparency & efficiency: comprehensive APIs and interfaces that provide real-time claims status, surface underlying data, allow MAC-operated systems to interact with claims, and reduce provider burden.

7. Risk Management of Platform Obsolescence: full retirement of COBOL mainframe systems and the Common Working File with real time, performant, scalable, maintainable, well-supported systems.

8. High Availability (HA) and Scale: Target 99.9% uptime with elastic scaling at current and future volumes, eliminating nightly downtimes and dark days.

9. Disaster Recovery (DR) and Business Continuity Plans (BCP): Provide mission-critical DR and BCP for the ClaimsCore solution with defined RTO/RPO objectives and regular failover/DR drills aligned to CMS enterprise continuity plans.

10. Interoperability: HIPAA X12, REST/FHIR APIs, and custom flat files integrate efficiently across CMS, MACs, clearinghouses, and provider systems.

Benefits for Medicare Beneficiaries ClaimsCore will deliver immediate improvements to the Medicare experience while enabling deeper transformation in the future. From day one, beneficiaries will see faster claims resolution, stronger fraud protection, and near-real-time explanations of benefits. As providers adopt new APIs, beneficiaries will gain clearer cost and coverage information at the point of care, including accurate out-of-pocket estimates and seamless digital access to claims and explanations. Over time, ClaimsCore will reduce confusion and surprise billing and creates the foundation for a Medicare experience that feels closer to retail - clear prices and faster checkout-speed resolution.

Context Current Environment: FISS, MCS, DME, and CWF process ~1.2 billion claims annually (≈$460B+). Hosted in CMS Virtual Data Centers, they run on COBOL, Assembler Language Code (ALC), and IBM mainframes. The current Shared Systems and the Common Working File (CWF) present significant challenges, including claims processing delays, code and policy audit challenges, outdated code bases that hinder policy changes, inflexible external systems integration, limited data transparency across contractor regions, an aging COBOL workforce, and expensive maintenance of mainframe environments. The Shared Systems and CWF’s siloed and centralized architecture constrain scalability and complicates integration with modern data standards, making real-time analytics and interoperability with external systems difficult. These issues collectively slow innovation, increase administrative burden, and limit CMS’s ability to implement new payment models efficiently.

Stakeholders: Within CMS, the ClaimsCore program is led by the Digital Services at CMS (DSAC) organization, sponsored by CM, OIT, and OA, and engages nearly all Medicare related offices, with MACs and providers as critical partners. Providers and beneficiaries will benefit from faster, more transparent claims, while other CMS offices will leverage the platform for program integrity, payments, and policy innovation.

Statement of Need Challenges with Legacy Systems

1. Policy change agility CMS needs the ability to respond to administrative priorities and ensure beneficiaries, providers, and policymakers experience timely, accurate policy execution. Current updates take 7-12 months or longer due to complex coordination between the 3 disparate shared systems and CWF, brittle legacy COBOL code, opaque configurations, and burdensome testing cycles that slow the entire change process.

2. Policy flexibility CMS needs to implement complex or nuanced payment and coverage policies without technical constraint to preserve legislative intent and enable modernized benefit design. The current systems are insufficient for CM's future policy needs.

3. Fraud prevention and payment integrity CMS needs to prevent and detect fraud and abuse before payment to protect taxpayer funds and reduce improper payments. Existing legacy architectures rely on nightly batch exchanges and siloed regional data, making rapid detection of bad actors and fraud patterns, real-time risk scoring, and pre-payment intervention challenging.

4. Real-time operations CMS needs to process and adjudicate claims in near real-time to accomplish CMS payment objectives, support provider revenue certainty, improve beneficiary clarity, and program integrity responsiveness. Nightly batch processing, system latency, and mainframe dependence inherently prevent real time adjudication, payment or feedback.

5. Program and model scalability CMS needs to enable new and alternative payment models to operate at national scale to foster innovation and policy testing across the healthcare system. However, current shared systems cannot accommodate modern value-based payment constructs like Innovation models or timely Accountable Care Organization (ACO) reporting, forcing these programs onto separate, duplicative platforms.

6. Data accessibility and reporting CMS needs to provide timely, comprehensive, and accurate reporting and analytics to inform decision-making and policy oversight. The current system is incapable of doing this because data is stored in VSAM files and siloed, non-relational systems that significantly delay and complicate data extraction, correlation, and retrospective analysis.

7. Stakeholder visibility CMS needs to provide beneficiaries, providers, and ACOs with up-to-date claim status and financial transparency to reduce administrative burden and support better clinical and financial decisions. Providers need to be able to upload documents needed to support claims, and beneficiaries need to be able to clearly understand what services were billed on their behalf. Current systems cannot surface real-time information or out-of-pocket responsibilities.

8. Beneficiary clarity and fraud awareness CMS needs to provide all beneficiaries, but especially those without supplemental coverage, with clear, timely information about their financial responsibility and claim activity in order to prevent financial confusion and enable early detection of potential fraud. Current systems notify beneficiaries only well after claims processing activities occur, which hinders the ability of the beneficiary and his/her representatives to recognize and understand fraud.

9. Cost efficiency and system rationalization CMS needs to consolidate disparate home-grown systems at CMS and the MACs to use taxpayer funds more efficiently and redirect savings toward innovation. At present, multiple auxiliary, stop-gap, and contractor-built tools are required to compensate for shared-system limitations, multiplying cost and complexity, and limiting the availability of funds to be used to innovate payment.

10. Policy impact evaluation CMS needs to quantify, test, back-test, and audit the impacts of policy changes before deployment to improve policy safety, better inform the approval process, and add accountability. In today’s legacy environment, the business logic and edits in legacy systems are opaque and scattered, and there is no “model office” environment made to fully test changes and ideas, making impact analysis slow, incomplete, and risky and clearly understand the effect of proposed changes can be challenging.

11. Retroactive reprocessing CMS needs to reprocess and reconcile claims rapidly when policy changes occur retroactively to minimize confusion, interest accrual, and financial risk for CMS and providers. In today’s legacy environment, the systems require cumbersome steps to identify and batch affected claims, and manual, multi-month or even multi-year reprocessing for held or adjusted claims, and are rate limited to 150% of daily claims volume.

12. Security and resilience CMS needs to strengthen cybersecurity and operational continuity across Medicare FFS systems to protect beneficiary data, payment integrity, and ensure uninterrupted claims operations. Aging mainframes, unsupported code bases, and limited monitoring capabilities leave the environment vulnerable to breaches, abuse, and downtime.

13. Contracting flexibility and innovation CMS needs to reduce reliance on the shared system maintainers and encourage competitive modernization to lower costs and access innovation from a broader technology ecosystem. Long-standing incumbency and proprietary dependencies constrain competition and inflate sustainment pricing.

14. Emergency responsiveness CMS needs to rapidly deploy system and policy updates during public-health or other emergencies to respond to emerging crises without compromising program integrity or existing non-affected operations. The current legacy systems require lengthy, high-risk change cycles that delay critical updates and heighten fraud exposure.

15. Transparency and auditability CMS needs to ensure that the operational logic, edits, and decision rules within its claims systems are fully transparent and auditable to improve oversight, trust, and accountability. Today’s legacy systems obscure business logic, making it difficult for users, auditors, and policymakers to trace decisions or validate outcomes.

Opportunities Re-platforming the shared systems ensures timely, accurate payments, reduces provider burden, prevents fraud, and creates long term savings. ClaimsCore transforms Medicare’s core systems into a sustainable, policy responsive platform. Further, ClaimsCore implements an underlying preference for Commercial supplies and services to avoid additional costs and schedule (See FAR 12.201).

As a result of project ClaimsCore we expect substantial financial, technical, operational, security, quality of life, and other improvements across CMS, MAC, Beneficiary, and Provider stakeholders.

CMS-Centric Anticipated Outcomes

· Significant uplift in additional annual fraud prevention. Integrating claim level CPI risk scoring enables prepay intervention in real time when paired with appropriate policy authority. The combination allows potential large, recurring reductions in immediate and downstream fraud prevention.

· Usability to support more efficient MAC staff training, streamline workflows and reduce manual processing activities that will decrease operational burden and strengthen long-term organization efficiency.

· Policy agility. Configuration driven rules could allow CMS implement and test policy changes in hours or days (contingent on process) rather than the current 7–9 month code cycles.

· Enterprise data access. Near real time reporting and standard APIs increase data visibility for internal stakeholders, providers, and ACOs.

· Improved Zero‑Trust–aligned security and resilience. Deployment in the CMS Cloud with 99.9% uptime targets, strong identity, and continuous monitoring improves cybersecurity posture.

· Mainframe risk retirement. Replacing 1970s mainframe/COBOL systems cuts obsolescence risk and dependency on scarce skill sets.

· Faster emergency responsiveness. Configuration-based changes allow rapid policy updates during public health events without waiting for lengthy code releases.

· Nationwide program integrity view. Realtime, cross-region analytics help MACs spot anomalies earlier and coordinate corrective action.

MAC-centric Anticipated Outcomes

· Usability to support more efficient MAC staff training, streamline workflows and reduce manual processing activities that will decrease operational burden and strengthen long-term organization efficiency.

· Enhanced data access by MACs to relevant data to increase efficiency in Medicare claim process and reduce delays in adjudication

· Coordinated, consistent policy rollout. A single national configuration engine deploys changes consistently across MACs while accommodating MAC and region specific configuration needs, reducing regional divergence and rework.

· Automating test cycles increases system reliability, accelerates release timelines, improves the quality of delivered functionality, reduces defects and operational risk, and decreases MAC manual testing efforts.

· Increased system availability—enabled by eliminating batch window constraints—ensures more consistent operational performance, minimizes downtime, and allows MACs to process work more reliably and without interruption.

· Less local middleware and robotic process automation (RPA, e.g. “screen scraping”). Unified APIs and workflows reduce MAC-built workarounds required by limitations in the shared systems today.

· Consolidating IT systems and rationalizing duplicative tools reduces MAC operations and maintenance efforts by streamlining technology footprints, automating manual workflows, and decreasing sustainment overhead resulting in more efficient operations, improved resource utilization, and greater long-term maintainability.

· Standardized edit taxonomy and governance. Configuration over code and transparent rule management reduce idiosyncratic regional behavior.

Beneficiary and Provider-centric Anticipated Outcomes

· Improved provider satisfaction with Medicare billing processes.

· Lower provider burden. Modern APIs, faster decisions, easily accessible documentation submission, and consistent edits reduce administrative waste that today contributes to sizable provider overhead.

· Reduced adjudication time. Claims that previously adjudicated in batches are now processed in under a second with clear outcomes and status, and real-time claim status updates reduce callbacks, days in accounts receivable, and rework costs while increasing provider confidence in their submissions.

· More predictable cash flow. Faster pay/deny decisions and stronger prepayment controls reduce post-pay recoupments and volatility.

· Fewer resubmissions. Immediate, precise edit feedback lower avoidable improperly submitted claims and resubmits.

· Accurate patient responsibility estimates. Real-time adjudication supports point of care cost clarity and fewer financial surprises for patients, especially the ~10% of beneficiaries without supplemental coverage.

· Faster retroactive corrections. Automated, high-volume reprocessing of retroactive policy changes reduces confusion, interest accrual, and manual fixes.

· Clearer appeals and medical review. A full rule/explanation trace per claim streamlines documentation for reconsideration and audit.

· Earlier fraud/identity issue detection. Real‑time cross‑checks and beneficiary visibility help surface suspect activity before it becomes a denial cycle.

· Consistency for multistate systems. Multistate health systems complain of variations MAC to MAC; the new system will introduce improved consistency in interstate experience with CMS systems reducing provider burden and frustration.

Approach Assumptions

1. Scale assumptions: ~1.2 billion claims per year (for sizing) and ~33.6 million beneficiaries in Original Medicare; final sizing validated during discovery. Load may be distributed across an instance per MAC or MAC region if analytics and real time FWA can still be performed across regions.

2. Vendor partnership: CMS is evaluating SaaS COTS platforms to be configured and extended by the vendor in collaboration with CMS, MACs, and supporting vendors.

3. Stakeholder engagement: MACs and CMS offices participate in workshops, demos, and requirements validation; training and communications are built in.

4. Team composition: flexible teams with Business Owners, Medicare SMEs, architects, integration teams, engineers, testers, security, data specialists, customer support staff, trainers, and customer engagement staff.

5. Incremental delivery: Phased deployments; incremental roll out including focused workstreams with defined scope, resources and timelines; validation against legacy systems running in parallel will build trust and reduce risk.

6. Warranty and Service Level Agreements: ensure appropriate system performance based on operational needs assessment and tied to payment penalties.

Cost Drivers

1. Beneficiaries & claim volume: As noted in the assumptions

2. Rule complexity & change frequency: Thousands of edits and frequent updates; extensive regression and validation required.

3. Integration points: Numerous external systems (e.g., PECOS for provider enrollment, HIGLAS for CMS general ledger, fee schedules, etc.); HIPAA X12, FHIR, REST APIs; complex mapping and maintenance.

4. Data migration & history: Decades of VSAM and flat-file data; extraction, cleaning, transformation, and preservation.

5. Business Logic migration: Extensive COBOL code logic with little documentation needs to be analyzed and relevant logic imported into to the new system.

6. Testing & validation: Large-scale regression, performance, and parallel runs; differences in outcomes must be explainable.

7. Availability & resilience: 99.9% uptime target; redundancy, DR, failover, monitoring, and surge capacity needed.

8. Stakeholder engagement & training: Stakeholders include CMS, MACs, providers, and clearinghouses; requires training, documentation, and change management.

9. Regulatory & compliance: HIPAA, FISMA Moderate, CMS ARS, Section 508; controls, audits, documentation, and certifications.

Professional Services CMS will require professional services to configure, implement, integrate, secure, operate, validate, and transition the selected COTS platform within the CMS, MAC, CMS Cloud and Medicare ecosystem. The contractor’s professional services shall include the below.

1. Product & Project management and integrated planning: In partnership with CMS and MACs, develop and continuously maintain a comprehensive, end-to-end implementation plan covering discovery through transition. At a minimum, include an Integrated Master Plan/Schedule (IMP/IMS); work breakdown structure with named work streams; a risk/issue/assumption/decision (RAID) register with mitigation owners; stakeholder engagement / user research & feedback / communications plan; compliance checklists (CMS ARS/FISMA, HIPAA, Section 508, TIC 3.0, CMS Cloud); Responsible, Accountable, Consulted, and Informed (RACI) matrices; environment/cutover runbooks; defect and change logs; test and validation strategy (including dual run parity metrics, performance/DR drills, and acceptance criteria); training and knowledge transfer materials; and measurable milestones used for inspection/acceptance and QASP reporting. Maintain these artifacts in CMS approved tools and align updates to the cadence set in Reporting, Testing & Validation, and General Expectations for Agile Teams.

2. Implement and configure in CMS Cloud. Deploy the platform entirely in the CMS Cloud (AWS), establish environments (dev/test/stage/prod), infrastructure as code, CI/CD pipelines, observability, tagging, backup/DR, and cost reporting consistent with the CMS Cloud Services and security requirements.

3. Integrate with dependent systems using open standards. Build, test, and certify required interfaces (e.g., HIPAA X12, REST/FHIR, events, batch bridges as needed) with CMS, MAC, provider, and partner systems; deliver vendor neutral interface specifications and stubs/mocks to enable third party integration without OEM coordination. The legacy Shared Systems and CWF have hundreds of individual interfaces (file exchanges, API calls, X12 transactions etc.) that enable critical business processes both as part of the claims adjudication process and downstream that must continue to function as expected. Examples include systems hosted by CMS and MACs such as HIGLAS, PECOS, BIC, Pricers/ Groupers, Customer Service Interfaces, Documentation and Reporting, Banking, Document Management, Printing Services, etc.

4. Extract and document business rules. Elicit, extract, normalize, and document legacy rules/edits in a vendor neutral format (e.g., spreadsheets/JSON/YAML + prose rulebook), establish traceability to policy, and provide explainability for adjudication outcomes.

5. Plan and execute data migration. Design and perform ETL (history and in‑flight), mapping, data quality controls, reconciliation, and lineage documentation; support “database import” with pass/fail criteria and defect triage until parity is achieved.

6. Support dual run testing and validation. Stand up parity/variance harnesses, test oracles, and dashboards; meet success metrics (e.g., outcome match rate and dollar variance thresholds), provide root cause analysis for differences, and drive remediation to closure.

7. Privacy, Security and Authority to Operate (ATO) support. Prepare and maintain A&A/ATO artifacts (e.g., SSP, SAP/SAR, POA&Ms), support SCA/ACT, vulnerability management, incident response, and continuous monitoring in accordance with CMS ARS, FISMA Moderate, HIPAA, and Zero Trust objectives.

8. Compliance with CMS lifecycle and standards. Follow CMS Target Life Cycle (TLC)/SDLC and related guidance; align to the “General Expectations for Agile Teams,” QASP measures, Section 508 requirements, and reporting cadence defined in this SOO.

9. Operate with an outcomes focused agile delivery model. Participate in standups, PI planning, demos, retros, and backlog refinement; maintain Jira/Confluence/GitHub work products and link pull requests to user stories; provide a named engagement lead and key SMEs.

10. Training and learning management. Provide role-based training for CMS and MAC staff; develop and maintain Learning Management System (LMS) curricula; produce job aids and quick reference guides; deliver train the trainer sessions, labs/simulations, and completion/competency tracking.

11. Change management and stakeholder communications. Coordinate with MACs and affected CMS components to minimize operational impact; conduct readiness and stakeholder mapping; deliver provider/MAC communications (webinars, notices, MLN style updates); publish and execute cutover playbooks and manage issue communications during dual run. Propose configuration first solutions; any extensions must preserve upgrade paths and be documented with unit/functional tests; avoid bespoke forks.

12. Operations readiness and cutover. Deliver runbooks, SRE/on call procedures, performance tuning, DR playbooks, and acceptance criteria for go live; participate in design/troubleshooting sessions with teams integrating to ClaimsCore.

13. Performance, cost, and reliability engineering. Meet SLOs for latency, throughput, and uptime; instrument dashboards; right size cloud resources and optimize consumption per CMS guidelines.

14. Accessibility and documentation. Maintain current system diagrams, interface catalogs, data dictionaries, runbooks, and user guides; ensure all deliverables (documents, training, dashboards) meet Section 508/WCAG conformance.

15. Reporting and analytics enablement. Understand CMS/MAC reporting needs and implement required reports/exports using product capabilities; expose APIs and documented schemas to support CMS and MAC analytics.

16. Portability drills and exit readiness. Quarterly, perform end to end export and rebuild exercises to a clean CMS tenant (data + configurations + rules + integration assets), fix gaps, and deliver reports; ensure artifacts are provided in documented, machine readable, vendor neutral formats.

17. Post-go-live stabilization and optimization (hypercare). For each cutover (by MAC and/or claim family), provide an initial hypercare period to stabilize operations; monitor and meet all QASP SLOs (uptime, latency, variance/defects); operate 24×7 incident, problem, and change management; complete one DR failover/failback exercise with after action report; tune performance and cloud consumption; continue dual run variance monitoring where applicable and drive root cause remediation; execute continuous monitoring obligations for ATO (SSP/SAP/SAR, POA&M updates, vulnerability remediation within CMS timelines); refresh runbooks and O&M procedures; deliver role based training and knowledge transfer to CMS/MAC operations; publish live dashboards and a postimplementation report to the COR aligning with the Reporting section.

18. Professional services availability. Provide scalable professional services capacity (including surge) throughout the life of the contract to support ongoing change requests, implementation, operations, variance remediation, security updates, and transition activities.

Constraints

1. Architecture & standards: align with CMS enterprise architecture; prefer configuration over custom code; modular, open interfaces. Solution must be fully deployable in the CMS Amazon Web Services Cloud.

2. Data Rights: To avoid vendor lock‑in while honoring commercial‑item norms, CMS requires the following rights framework for data, software, and technical artifacts generated under this effort:

2.1. CMS data and derived data (including logs/telemetry). CMS retains ownership and unlimited rights in all CMS data handled or produced under the contract, including derived data, logs, metrics, audit trails, claims data and claims history, data loaded from external CMS systems, and decision explanations. Contractor shall not assert any license over CMS data.

2.2. Custom code and technical artifacts first produced under this contract (non‑COTS). For any software, scripts, transforms, connectors, interface shims, test harnesses, schemas, specifications, runbooks, training, and documentation first produced under this contract and not constituting Commercial Computer Software, CMS receives unlimited rights; source form must be delivered. This implements the SOO’s intent to prevent lock‑in for integration assets.

2.3. Rules, configurations, mapping tables, edit taxonomies, and interface specifications.

2.3.1. Vendor‑neutral representations (e.g., spreadsheets/CSV/JSON/YAML, prose rulebooks, diagrams, API/interface specs) shall be delivered with unlimited rights so they can be published, competed, or re‑implemented without restriction.

2.3.2. Platform‑specific representations (e.g., exports in the product’s Domain Specific Language (DSL), proprietary rule/config bundles) shall be provided with perpetual, irrevocable, paid‑up, government‑purpose license rights allowing use, reproduction, modification, and disclosure within CMS, MACs, and CMS‑directed support contractors for any Government purpose (operations, validation, transition, recompete), but not for commercial resale. Contractor shall also provide timely, complete non‑proprietary exports sufficient to reconstitute equivalent behavior on another platform.

2.4. Adapters, connectors, and integration assets. Assets first produced under this contract shall be delivered in source form with unlimited rights. If an asset necessarily embeds contractor background IP, CMS shall receive government‑purpose license rights to the embedded portions and unlimited rights to all CMS‑specific logic, mappings, and interface specifications surrounding them. Contractor shall establish and maintain accessible repositories of interface specifications and supporting documentation in machine-readable format that enable third-party integration without original equipment manufacturer coordination.

2.5. COTS and contractor background IP. CMS does not seek ownership of the contractor’s proprietary platform or background IP. CMS will accept the standard commercial license to operate the platform in the CMS Cloud, provided the license:

2.5.1. permits operation by CMS, MACs, and CMS‑directed support contractors;

2.5.2. supports non‑prod, DR, and performance testing use

2.5.3. does not impede data/config export or portability drills; and

2.5.4. includes reasonable termination assistance/step‑in to protect continuity.

2.6. CMS claims no ownership to vendor proprietary code, trade secrets, etc. and expects to acquire only those rights customarily provided for commercial computer software.

3. Export and Transition:

3.1. Portability: Vendor must provide documented export formats & APIs and support no-fee bulk export during transition or step-in; quarterly portability dry-runs required.

3.2. Escrow/termination assistance: updated runbooks, config snapshots, and data-model documentation placed in escrow; termination assistance CLIN with defined SLAs.

3.3. Vendor Shutdown: CMS will receive transition assistance and step-in rights to continue operations on the contracted platform and will receive all configuration/data exports necessary to transition. Further, CMS must have the unrestricted rights to export, transition, or operate the system independently in the event of vendor termination, acquisition, or failure.

3.4. Standards: The solution must be built on open, standards-based architecture with full data portability. Proprietary components must not restrict interoperability or create undue switching costs.

4. Interoperability: The solution must support HIPAA X12 and comprehensive APIs (REST/FHIR, events); avoid creating new silos; support for CMS-0057-F.

5. Performance & availability: target 99.9% uptime, horizontal scalability, and low latency adjudication; zero/minimal downtime releases.

6. Security & privacy: Vendor must satisfy all CMS cybersecurity requirements including security frameworks, compliance, oversight, incident reporting, personnel security, data handling, and must be able to deploy their full solution within the CMS Cloud on Amazon Web Services (AWS). The CMS Cloud is a FISMA Moderate (Medium) environment. The vendor should expect employees with access to CMS systems, facilities or data will be subject to standard CMS vetting procedures, with additional screening for foreign nationals. All work must be performed in CONUS. No non-public data may leave CONUS.

7. Legal and HIPAA Requirements: The vendor shall comply with HIPAA, the HITECH Act, and all applicable federal privacy and security regulations (45 CFR Parts 160 and 164). The vendor shall protect all PHI and PII in accordance with CMS privacy and security policies, maintain a valid Business Associate Agreement (BAA), and ensure all data use and disclosure are authorized, logged, and limited to the minimum necessary. A data use agreement (DUA) is required.

8. No disruption: incremental delivery and parallel operations to maintain current processing throughout migration.

9. Audit & transparency: full rule/explanation trace, decision logs, audit logs, and change history to meet CMS transparency objectives. The vendor must ensure full compliance with all mandatory annual audits: Cybersecurity and Risk Assessment Program (CSRAP), System Census, CFO Audit, A-123 Management Controls Audit, HHS Appendix IX Financial Audit, and Major IT Business Case (MITBC) Financial Review. The vendor shall provide timely support for ad hoc audits including Office of Inspector General (OIG) audits and Office of Information Technology (OIT) data calls. The vendor is responsible for annual review and maintenance of Authorization to Operate (ATO) supporting documentation, security control assessments, and timely reauthorization submissions. The contractor shall maintain operational responsibility for their assigned CFACTS database instance in accordance with CMS standards. Performance Standard: All audit requirements must be satisfied within established timeframes with complete documentation maintained per federal records management requirements and CMS policy directives.

10. CMS & MAC Operations: The Contractor should expect to support CMS and MAC operations, business processes, policies, and other needs without expectation of policy change to accommodate the contractors existing suite of products. CMS may elect to adjust process, policy or other practices at its discretion based on capabilities offered by the proposed product suite.

Engagement & Communication ClaimsCore contractor must engage relevant CMS offices, MACs, providers, and partners through regular demos, open documentation, targeted training, and efficient asynchronous updates to reduce burden. Education materials and hands on sandboxes will help build consensus on policy and process changes.

Challenge-Based Acquisition ClaimsCore will be procured through a multi-phase challenge process. The objective is to create an environment where acquisition decisions are based on experimentation and demonstration of existing or emerging technology through a rapid and impactful assessment of commercial solutions and competing “prototypes” (i.e., limited implementations).

CMS contemplates multiple awards including a few contracts – perhaps as many as four or perhaps only one. Due to the operational cost and burden of a PoC, fewer awards are preferred. Accordingly, CMS has established an aggressive base-period (POC Phase) affordability objective of $1 per contract. Those vendors will begin work under a proof-of-concept (POC) phase where their solutions are tested against real CMS data and measured against CMS-established success criteria and metrics.

After the POC phase, CMS anticipates the down-select of contractors by not exercising option(s) for further work based on unilateral determination of CMS’ best interest. This approach ensures solutions are validated in practice, stakeholder trust is built incrementally, and only Contractors with proven capability at scale advance. Contractor solutions will be assessed against the success criteria, and CMS anticipates, but does not guarantee that a Contractor will be selected, via option exercise, for an eventual production implementation to replace the Shared Systems and Common Working File and integrate with associated systems and business processes (e.g., CMS change management, MAC business operations, etc.).

During the challenge, contractor solutions will be run in parallel with CMS’s legacy shared systems. This head-to-head approach ensures that performance, accuracy, and reliability can be directly measured against current operations. Contractors must demonstrate that their platforms can adjudicate claims in real time, deliver outputs consistent with legacy results, and provide transparent explanations for any variances. Success will be evaluated based on clear, measurable metrics including accuracy, throughput, interoperability, and stakeholder satisfaction. CMS anticipates that only one solution will advance to production.

For the POC, each contractor will be responsible for planning and driving the work needed to meet the challenge success criteria, including organizing working sessions and demos, arranging and documenting discovery with CMS and MAC stakeholders, managing their implementation schedules and milestones, coordinating dependencies and data needs, and running their own analysis, configuration, testing, and defect resolution activities within the PoC timeline. CMS will provide environments, data, and points of contact, but contractors are expected to proactively manage and coordinate all work necessary to demonstrate their solution’s capabilities.

What CMS will provide for the PoC(s):

· Rule and logic artifacts: Legacy business‑rule extracts (COBOL/ALC/HLASM code and configuration repositories), edit taxonomies, pricer/ grouper specifications, fee schedules, and reference documentation for at least one MAC jurisdiction.

· Data sets: Connectivity to data streams, external systems, and information sources. Adjudication outcomes from legacy, eligibility/benefit context, and test endpoints for priority external systems. This will include, but is not limited to:

· Beneficiary/member data for the ~33.6M Medicare beneficiaries.

· Provider data (enrollment, etc.) for all Medicare providers.

· Claims data for Medicare Part A and B claims, for at least one and possibly all MACs.

· Points of contact: CMS (and, as appropriate, MAC) personnel to work with for discovery, clarifications, data/interface questions, and issue resolution on a defined cadence during the PoC.

· Access to CMS Cloud: CMS-provisioned environments in the CMS AWS Cloud (e.g., PoC tenant, network access, external connectivity, and baseline tooling) suitable for deploying and operating the contractor’s configured solution during the PoC.

What PoC participants must deliver (expected outputs):

· Configured system in CMS Cloud meeting the throughput, latency, uptime and CMS security and compliance requirements metrics.

· Adjudication outputs for the provided claims with decision explanations; deviation and alignment reports with a difference taxonomy and root cause analysis.

· Evidence for each item in the POC Assessment Metrics table

· Updated price/TCO and commercial terms reflecting the PoC configuration and usage assumptions.

POC Assessment Metrics The table below sets out representative assessment criteria and measurable objectives for the POC. These objectives reflect CMS’s view of high-quality performance; however, proposals and eventual awardees will be evaluated relative to one another and to industry standards as evidenced in the submissions (CMS may calibrate thresholds based on the distribution of demonstrated capabilities). CMS may refine thresholds, weights, or add/remove criteria where in the Government’s best interest. Contractors will be assessed on their ability to meet or exceed these objectives, along with qualitative considerations such as risk, feasibility, and commercial terms. Pricing will be considered including total cost of ownership (TCO) among other factors in deciding as to which option(s) are in the best interest of CMS. CMS reserves the right to validate claimed results and require supporting evidence. During the PoC, contractors will configure their systems, gather requirements, and integrate with external systems before the start of the Measurement Interval. The Measurement Interval will be a defined window near the end of the Base Period (3-6 months) during which CMS and contractors will formally measure performance against the criteria in the table below.

Production Implementation The contractor in partnership with CMS and MAC personnel will execute an incremental Production Implementation to replace the legacy Shared Systems/CWF while maintaining continuity of Medicare Fee‑for‑Service operations. The contractor shall lead day‑to‑day delivery and coordinate with CMS, MACs, and partner systems to achieve the outcomes below.

· Maintain a single Integrated Master Plan & Schedule (IMPS); define acceptance criteria for every workstream; update status, risks, and dependencies on the agreed cadence and make artifacts available to CMS.

· Incremental onboarding of MACs and claim families Onboard in slices (claim family × MAC). Each cutover must meet published gates (e.g., variance thresholds, outcome alignment, interface certification, training readiness, etc.). Sustain metrics before expanding to additional slices/MACs.

· Meet or exceed the service levels and quality measures in the QASP (e.g., uptime/latency, dual‑run accuracy, DR/RTO/RPO, accessibility, security remediation timelines). Report performance via live dashboards and periodic summaries.

· Propose an IMPS‑based milestone structure with objective evidence for acceptance (e.g., dual‑run results, interface certifications, training completion, documentation delivered). Milestone payments are contingent on meeting the corresponding acceptance evidence.

· Plan and deliver interfaces by tier, starting with Tier‑1 systems required for validation and payment integrity. Provide test packs, certification evidence, and error‑budget reporting; expand to additional external systems per the IMPS.

· Migrate, interface with, or virtualize historical and in‑flight data required for operations; document mappings and lineage; execute reconciliation with defined tolerances and correct defects prior to cutover.

· Maintain parity with legacy change requests during transition. For any policy, rules/edits, pricers, reference tables, or interface updates promoted in the legacy shared systems, implement the corresponding change in ClaimsCore within the QASP policy‑agility cycle‑time target; synchronize release dates; document and obtain CMS approval for any intentional deltas.

· Training, communications, and change management Deliver role‑based training for CMS and MAC users, publish job aids and cutover playbooks, and execute stakeholder communications to minimize operational impact.

· Maintain continuous monitoring and ATO artifacts; meet vulnerability remediation timelines; implement business continuity and disaster recovery consistent with mission‑critical objectives; perform scheduled failover/failback drills.

· Provide runbooks, on‑call and incident/problem/change management; deliver a post‑go‑live hypercare period for each cutover with active monitoring, variance remediation, and after‑action reports.

· Perform periodic export‑and‑rebuild drills to a clean CMS tenant; provide vendor‑neutral exports of data, rules, configurations, and integration assets to preserve portability.

· Support CMS in retiring legacy components per the decommissioning plan as slices move to steady state.

Timeline This procurement will be conducted as a challenge-based acquisition with three phases. Feedback will be continuously provided throughout the phase. After each phase CMS will down-select vendors.

1. Request for Proposal (RFP) Acquisition using the evaluation criteria described in the solicitation.

2. Proof of Concept (3-6 months, Base Period): Anticipate not more than four participants; awardee(s) must install, integrate with essential external systems, and process a limited set of CMS data to validate baseline capabilities relative to the Evaluation Metrics before advancing to production implementation. Weekly progress updates to CMS are required.

3. Production implementation (Option Periods as described in the Solicitation): One vendor only. The selected awardee will complete installation, integrate with all relevant external systems, and process CMS claims data according to its rollout plan.

4. Transition to a follow-on Contract (Final Option Period unless sooner as directed by CMS): validate data submissions are complete and accurate; prove readiness to export & transition to a follow-on platform or contract; implement transition plan as required below.

Conclusion ClaimsCore is the first step toward a real time, efficient, retail like experience for Medicare beneficiaries at the point of care: clear coverage, real time costs, and faster resolution—while…