Attachment 1 - ClaimsCore Statement of Objectives.pdf

Confidential, Iterative, Pre-Decisional

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

Statement of Objectives (SOO) – ClaimsCore Program

Vision Objectives Benefits for Medicare Beneficiaries

Context

Statement of Need Challenges with MCS, FISS, DME, and CWF Opportunities

Approach Assumptions Cost Drivers Requirements Professional Services

Governance, Engagement & Communication Collaboration Tools Reporting

Challenge-Based Acquisition

Proof of Concept Scope MAC Related Scope Fraud Prevention System Deliverables Dependencies and Integrations POC Assessment Metrics Integrated Master Plan & Schedule (IMPS)

Production Implementation MAC Onboarding Financial Disbursement and HIGLAS Integration Tier 2-4 Integrations Other Key Responsibilities

Quality Control and Assurance

Timeline

Conclusion

Appendix A: Security Requirements

Appendix B: QASP

Appendix C: Features and Functionality

Appendix D: Tier 1 Systems List

Appendix E: General CMS & Related Technical Standards

Appendix F: MAC Statements of Work

Appendix G: Specialty Workloads

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 reduces administrative burden and sets improvement of the beneficiary experience as the program’s guiding objective. CMS intends to procure a Software as a Services (SaaS) Commercially- Available-Off-The-Shelf (COTS) product and complimentary configuration and integration services that will provide CMS with near real-time adjudication and claims status, policy agility, industry leading enterprise 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, near real-time platform while maintaining uninterrupted Medicare Fee-for-Service operations during transition. Such a replacement will significantly improve the way Original Medicare does intake, eligibility and coverage checks, edit/rules execution, payment determination, EOB/EOP generation, adjustments and reprocessing, reporting, and audit/traceability, analytics etc.

2. Beneficiary Transparency and Timeliness: Enable near real-time adjudication and claims status, faster explanations of benefits, and better visibility into beneficiary responsibility.

3. Reduce Provider Burden: Reduce provider burden through increased transparency and consistency, increased automation, 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 development 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 near 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. Consolidated Development and Operations: A single unified system for all Original Medicare claims processing, instead of four separate bespoke systems that are further split into separate regions, will lead to more consistent and efficient policy implementation, and to improved analytics and observability of business operations.

10. 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.

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

Benefits for Medicare Beneficiaries

The current COBOL systems limit CMS’ ability to deploy industry standard tools that improve the beneficiary experience. ClaimsCore will deliver improvements to the Original Medicare experience and provide the underlying platform that can enable follow on technology investments. As ClaimsCore deploys, beneficiaries will see faster claims resolution and stronger fraud protection. 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 digital access to claims and explanations. Over time, ClaimsCore will reduce confusion and surprise billing and creates the foundation for a Medicare experience that more quickly adapts to the needs of Medicare beneficiaries and our nation.

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, Office of Information Technology (OIT), and Office of the Administrator (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, and reduced administrative burden while other CMS offices will use the platform for program integrity, payments, and policy implementation and evaluation.

Statement of Need

Challenges with MCS, FISS, DME, and CWF

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 more consistently prevent and detect fraud and abuse both large and small 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. Near 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 near 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 near 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 Original Medicare 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 replaces Original Medicare’s core systems with 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 and other improvements across CMS, MAC, Beneficiary, and Provider stakeholders.

CMS-Centric Anticipated Outcomes

Improved ability to prevent improper payments. Integrating claim level CPI risk scoring enables prepay intervention in real-time subject to applicable policy authority. CPI projects this capability may enable 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 to 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.

Single Pane of Glass. One source of truth for Original Medicare’s claims processing operations, in a user-friendly and modern UI/system, will reduce the need for custom data flows to support downstream agency operations.

Improved Zero-Trust–aligned security and resilience. Deployment 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, partly enabled by eliminating batch window constraints, is expected to result in more consistent operational performance, minimized downtime, and to allow 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

Reduced provider administrative burden in Medicare billing processes.

Lowered 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 will be adjudicated in near real-time with clear outcomes and claims status which reduce provider follow up, 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. Near 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 report multiple unexpected variations MAC to MAC. ClaimsCore will introduce improved consistency in interstate experience with CMS systems reducing provider burden and frustration while still respecting local coverage determinations.

Approach

Assumptions

1. Software Vendor: CMS intends to procure a SaaS based COTS platform, through a competitive process, to be configured and extended by the vendor in collaboration with CMS, MACs, and/or supporting contractors.

2. Professional Services: CMS envisions its primary role as policy development and oversight and expects to contract for operational services either as part of the software offering in a traditional SaaS model or with a software vendor and systems integrator team depending on the relationship of the services component to the software vendor.

3. Scale assumptions: ~1.2 billion claims per year (for sizing) and ~33.6 million beneficiaries in Original Medicare. CMS prefers a single scalable instance of vendor software supporting all beneficiaries; however, load may be distributed across an instance per MAC or MAC region if analytics, editing, and real-time program integrity have real-time cross-region awareness.

4. Stakeholder engagement: The contractor(s) are expected to coordinate closely with CMS, MACs, and Providers in workgroups, demos, requirements gathering and validation, training, and communications facilitated by the vendor and contractors in partnership with CMS.

5. Incremental delivery: Phased deployments including incremental run-out based roll outs including focused workstreams with defined scope, resources and timelines. Vendor as well as independent validation of outputs compared against legacy systems running in parallel will provide objective evidence of parity and reduce risk.

6. Warranty and Service Level Agreements: Contractor(s) must 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, Pricers, Fee Schedules, Coding, Beneficiary Eligibility, etc.); HIPAA X12, FHIR, REST APIs with complex mapping and maintenance.

4. Data migration & history: Decades of VSAM and flat-file data, messy provider and beneficiary data, and the extraction, cleaning, and transformation needed to make this data usable.

5. Business Logic migration: Extensive COBOL code logic with little documentation needs to be analyzed and the relevant logic imported into to the new system. CMS is undertaking experimental efforts to extract and provide business logic and edits to awardees, but Contractor(s) are ultimately responsible for fully and correctly migrating business logic, in order to achieve parity with the outcomes of the existing systems.

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

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

8. Stakeholder engagement & training: Stakeholders include CMS, MACs, providers, and clearinghouses. Each will require collaboration, training, documentation, and change management.

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

Requirements

The following list represents a consolidated list of requirements focused largely on technical and operational items that are high priorities for CMS. In addition, further requirements are set forth in the sections that follow (e.g. Proof of Concept Scope, Production Implementation).

1. System Performance & Operational Efficiency: CMS requires a system that adjudicates claims accurately in near real-time, is easy to configure, is extensible, supports CMS/MAC strategic objectives, people, process, policy, and technology, and improves operational efficiencies. A target of 99.9% uptime, horizontal scalability, and zero/minimal downtime releases are required. Additional objectives are listed in the POC Metrics and QASP.

2. Architecture & standards: The solution must align with CMS enterprise architecture and standards including but not limited to those set forth in Appendix E: General CMS & Related Technical Standards. Contractors should plan to work with CMS Enterprise Architects to ensure they aren’t duplicating existing functionality or creating unnecessary duplicate tooling and are leveraging existing tools where appropriate. CMS anticipates each vendors’ solution may be unique in the way a shared responsibility matrix is completed, however, as a general principle, vendors should expect to operate, configure, manage, and control their own systems with CMS providing oversight, requirements, and guidance.

3. SaaS Deployment Models: CMS is interested in receiving proposals from vendors offering either a fully managed Software as a Service (SaaS) deployment hosted in a vendor-owned cloud or a vendor-managed SaaS deployment hosted within a CMS cloud infrastructure, which will be furnished by the Government. Contractors may choose to provide information for one or both deployment models if either can be supported and how each may affect cost, timeline, information security requirements, and other relevant differences. Note there are material additional FISMA Moderate ATO and FedRAMP related requirements when deploying in a vendor cloud environment which may not apply to CMS cloud infrastructure.

See Requirement 4: Security and Privacy for more information on the required Authority to Operate for each of these models.

4. Security & privacy: Vendor must satisfy all CMS cybersecurity requirements including security frameworks, compliance, oversight, incident reporting, personnel security, and data handling. See Appendix A: Security Requirements for additional details. Key security priorities include:

4.1. ClaimsCore will be considered a FISMA Moderate system, and/or FEDRAMP SaaS will be required for all solutions. Vendors will be required to implement the controls listed in the CMS Acceptable Risk Safeguards (ARS) at the Moderate baseline at a minimum (353 controls). Controls can be found at https://www.cms.gov/files/document/acceptable-risk-safeguards-v51.xlsx

4.1.1. For solutions deployed in a vendor-owned cloud environment or as self-hosted SaaS in a datacenter, CMS will support the vendor in procuring an ATO and sponsor a FEDRAMP certification, if needed. The vendor will be required to produce all necessary documentation and auditing required to prove compliance for all controls.

4.1.2. For solutions deployed in the CMS Hybrid Cloud, CMS anticipates leveraging its existing FISMA Moderate ATO environment for control inheritance. Use of the CMS cloud allows vendors to fully inherit 83 controls and partially inherit another 236 controls.

4.2. 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 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. All audit requirements must be satisfied within established timeframes with complete documentation maintained per federal records management requirements and CMS policy directives. See https://security.cms.gov for security and privacy policy and standards in place for CMS information systems.

4.3. Vendors should propose their information security framework, secure development lifecycle (SDL) practices, threat modeling, and security testing, and risk-based vulnerability management in the PWS and provide a copy of their shared responsibility matrix including all relevant parties.

4.4. 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 and non-public data may not leave

CONUS.

4.5. Vendors should plan to submit documentation on existing certifications, controls, and compliance frameworks that have been achieved and implemented such as HITRUST R2, SOC II Type II, FEDRAMP, ISO/IEC 27001, NIST CSF, etc. Certification boundaries for specific software or systems should be clearly stated.

4.6. Vendors should plan to use CMS Identity Management (OKTA) for authentication (not authorization) to their platforms. All users accessing the product, CMS data, CMS information, or CMS information systems under this contract must complete the required Vetting and Credentialing (V&C) process prior to being granted any form of logical or physical access.

Vendors should plan to, at contract award, submit to the Contracting Officer (CO) and/or Contracting Officer’s Representative (COR) a complete roster of all relevant personnel.

Each individual on the roster will receive an invitation from the CMS ICT website to register an account and begin the V&C process. Failure to submit a roster on contract award or of employees to fill out the registration in a timely manner will materially delay the start of work. Details on registration can be found here https://www.cms.gov/About- CMS/Contracting-With- CMS/ContractingGeneralInformation/Downloads/PolicyandGuidance/EFI-New-User- Guide-v28.pdf

5. 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.

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

5.2. Custom code and technical artifacts. Contractors should use configuration of their systems where possible over custom code to avoid breaking upgrade paths and introducing additional testing burden. 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.

5.3. Rules, edits, and configurations. Vendor will supply on request vendor-neutral representations (e.g., spreadsheets/CSV/JSON/YAML, prose rulebooks, diagrams, API/interface specs) which shall be delivered with unlimited rights so they can be published, competed, or re-implemented without restriction. 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, etc.), but not for commercial resale. Contractor shall also provide timely, complete non-proprietary exports sufficient to reconstitute equivalent behavior on another platform.

5.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.

5.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, provided the license permits operation by CMS, MACs, and CMS-directed support contractors, supports non-prod, DR, and performance testing use, does not impede data/config export or portability drills, and includes reasonable termination assistance/step-in to protect continuity. CMS claims no ownership to vendor proprietary code, trade secrets, etc. and expects to acquire only those rights customarily provided for commercial computer software.

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

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. One or more data use agreements (DUA) will be required.

8. Audit & transparency: The proposed solution must support full edit and rule explanation trace, decision logs, audit logs, and change history to meet CMS transparency objectives.

9. CMS & MAC Operations: The Contractor should expect to support CMS and MAC workloads, operations, business processes, policies, systems, 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.

10. Specialty Workloads: CMS and MACs support certain specialty workloads and processes outside of the standard MAC jurisdictions. They include but are not limited to claims processing for Railroad Board beneficiaries, the Mass Immunizer program, limited Indian Health Services support, Qualified Chain Provider/Out of Jurisdiction Provider support, Histocompatibility Labs, and the electronic Medicare Equivalent Remittance (eMRA) workload for the Veteran's Health Administration. Additional workloads that may or may not require claims processing can be found in Appendix G: Specialty Workloads

11. Historical Data: The solution must support use cases for the administration of historical data including importing or retrieving historical data from external archive sources and subsequently analyze, report on, reprocess, and/or make mass adjustments. Additionally, the ClaimsCore system must synchronize its own unique claims history with that of the legacy system on an ongoing basis during the transition to full production for all MAC jurisdictions.

12. No disruption: Incremental delivery and parallel operations to maintain current processing throughout migration. The CMS proposed cut over strategy is described in more detail in "MAC Onboarding".

13. Export and Transition: CMS values and is prioritizing its ability to transition to a new provider of claims adjudication software for any reason. Accordingly, CMS requires:

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

13.2. Escrow/termination assistance: updated runbooks, custom code, config snapshots, and data-model documentation, training, and all other relevant assets placed in escrow; termination assistance CLIN with defined SLAs.

13.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, change of control, or failure. Step-in and independent operation must be technically enabled through Government controlled tenant administrative accounts and Government controlled enterprise IdP. CMS shall be able to administer access/roles, system configuration, and audit logs, and execute data/configuration export without contractor assistance during dispute, termination, shutdown or change of control.

13.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.

Professional Services

CMS will require professional services to configure, implement, integrate, secure, operate, validate, and transition to the selected COTS platform within the CMS and MAC environments while ensuring continuity of operations for all stakeholders including certain provider users. The contractor’s professional services are expected to include the services listed below and may include others as additional needs are discovered.

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 (IMPS); work breakdown structure (WBS) 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); Responsible, Accountable, Consulted, and Informed (RACI) matrices; environment/cutover runbooks; defect and change logs; test and validation strategies (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.

2. Integrate with upstream and downstream 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. Interfaces must be based on industry standards and avoid proprietary protocols or formats and include clear, comprehensive documentation. 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.

3. Extract and document business rules. Elicit, extract, normalize, and document legacy rules/edits and hard coded business logic in a vendor neutral format (e.g., spreadsheets/JSON/YAML + prose rulebook), establish traceability to policy, and provide explainability for adjudication outcomes. CMS has undertaken significant efforts to extract this information prior to the start of the Proof of Concept, but additional work is likely to be needed.

4. Plan and execute data migration. Design and perform ETL (history and in-flight), mapping, data quality controls, reconciliation, and lineage documentation appropriate to the adjudication strategy employed by the vendor system.

5. Support dual run testing and validation. Stand up parity/variance harnesses, test oracles, and dashboards to measure adjudication outcomes relative to the legacy system. Vendors should meet success metrics (e.g., outcome match rate and dollar variance thresholds), provide root cause analysis for differences, and drive remediation to closure.

6. 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, and demo/sandbox environments

7. Change management and stakeholder communications. Coordinate with MACs and affected CMS components to minimize operational impact. Contractors should plan to conduct discovery, document CMSMAC processes and job roles that will be impacted by replacing the Shared Systems and CWF. Contractors should coordinate CMS/MAC communications and training (webinars, notices, team meetings), publish and execute cutover playbooks and manage issue communications during dual run. Once the vendor solution has been moved into a production capacity, vendors should expect to work though CMS change control processes.

8. Operations readiness and cutover. Contractor should manage a run out based migration on a MAC by MAC or region by region basis, deliver runbooks, SRE/on call procedures, performance tuning, DR playbooks, and acceptance criteria for go live. In addition, the contractor should ensure all upstream and downstream integrations are certified and functioning properly.

9. Performance, cost, and reliability engineering. Ensure the system meets SLOs for latency, throughput, and uptime. Provide instrument dashboards, right-size cloud resources and optimize consumption per CMS guidelines.

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

11. Reporting and analytics enablement. Understand CMS/MAC reporting needs and implement required reports/exports using product capabilities. Expose and support implementations accessing APIs and documented schemas to support CMS and MAC analytics.

12. Portability drills and exit readiness. Perform end to end export and rebuild exercises to a clean CMS tenant or export depending on the deployment architecture (data + configurations + rules + integration assets), fix gaps, and deliver reports. Ensure artifacts are provided in documented, machine readable, vendor neutral formats.

13. Post-go-live stabilization and optimization (hypercare). For each cutover (by MAC, region, 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 ongoing role-based training and knowledge transfer to CMS/MAC operations. Publish live dashboards and a post implementation report to the COR.

14. 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.

Governance, Engagement & Communication

CMS plans to establish a tiered governance model that is highly responsive to day to day needs of implementers, MACs, and other stakeholders. CMS has identified key risks, long lead activities required to implement a new claims administration system, and other potential points of friction, however we are also planning for a significant number of unknown variables and challenges that require a responsive group of decision makers and operators to drive issues to resolution. CMS plans to proceed iteratively, this structure is subject to change based on current needs.

1. Executive governance board: CMS leadership and key stakeholders set enterprise direction, approve cross-MAC sequencing decisions, approve policy and process change, and resolve escalations and tradeoffs that require leadership input.

2. CMS Workgroup: An empowered group of CMS stakeholders working with vendors will provide direction, oversight, manage change, and recommend sequencing based on MAC resources, readiness, operational risk, and statutory/regulatory timelines.

3. MAC and CMS SME Workgroups: When vendors or contractors have questions regarding policy, process or technology SME workgroups will be available to help answer questions and guide any regulatory, policy, or operational change that may need to be proposed.

4. Tiger teams: Time-boxed tiger teams are formed as needed to drive issue-specific execution to closure (for example, integrations, operational readiness, and validation), and to rapidly surface decisions and impacts to the CMS workgroup and governance board.

Collaboration Tools

ClaimsCore contractors must engage with relevant CMS workgroups, offices, MACs, and partners through regular demos, open documentation, targeted training, standups, and efficient asynchronous updates (email, slack, Jira, etc.). Educational materials and hands on sandboxes should be provided to help build consensus on process especially where policy changes may be needed.

The tools referenced below are the CMS managed instances and will be furnished by CMS for the Contractor’s use where relevant.

Slack:

o Primary communication method o Shared channels for cross-team topics

Confluence: All documentation will be stored here, including roadmaps, decision log, assumptions, meeting agendas and notes, research artifacts, team contact information, tech specs, etc.

JIRA: Teams will utilize JIRA dashboard and reporting capabilities.

GitHub: Single, open-source code repository. Contractors should expect to commit custom code developed for the government in a government owned GitHub. Where relevant, GitHub pull requests should be linked to JIRA user stories to connect the change to the requirements addressed.

Reporting

The Contractor should maintain clear government visibility into program cost, schedule, progress, technical issues, performance, and risk, including periodic reporting. The Contractor should deliver meaningful reporting and analytics that provide the Contracting Officer’s Representative (COR) and Product Manager(s) with up-to-date and comprehensive information regarding technical and management performance. Whenever possible, the Contractor should reference and/or populate all status reporting with live data, from live dashboards, when available and practicable. Live data dashboards should be sourced from the Agile tools under this contract, or other resources as directed by the COR.

Monthly Status Reports will be reviewed with the Contracting Officer (CO), COR and the Contractor’s Program Management team. The Contractor should report the status of the following:

Status of and progress towards all items on the Integrated Master Plan & Schedule (IMPS)

Accomplishments

Deliverables (including data delivered to CMS)

Risks

Self-assessment of performance against metrics from QASP

Management information including financials (invoices submitted or approved, estimate at completion, etc.) and other productivity data (e.g., velocity, burn down chart, burn up chart, etc.)

Personnel roster (including the job title, labor category, vacancies, and name of the prime or subcontractor employing the person/position)

Project Status Dashboard should be periodically reviewed with the COR, Product Owner and the Contractor’s Project and Operational Management teams. It should also provide an overview of all projects and operations with a focus on outstanding issues and risks.

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.

CMS encourages bidders to propose the best Proof of Concept solution possible at the lowest possible cost. 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 confidence 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.).

Proof of Concept Scope

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 Part A, Part B and DME claims in near real-time, deliver outputs consistent with legacy results, and provide transparent explanations for any variances. Success will be evaluated based on clear, measurable metrics defined in the POC Metrics table and QASP including accuracy, throughput, interoperability, and stakeholder satisfaction. CMS anticipates that only one solution will advance to production.

MAC Related Scope

Only MCS, FISS, DME, and CWF are in scope for this replacement. No MAC owned and operated systems are expected to be modernized during this implementation at this time but may be considered in future procurement actions. CMS expects the ClaimsCore solution to support the full scope of MAC operational responsibilities that are currently enabled by MCS, FISS, DME, and CWF, while maintaining uninterrupted Original Medicare operations during transition. To limit scope and reduce risk, CMS prefers contractors support integrations with existing MAC tools and systems rather than replacements, though in certain exceptional circumstances a replacement could be considered.