ClaimsCore RFP Questions and Responses.xlsx
XLSX spreadsheet 49 KB Posted
- Attached to
- ClaimsCore Combined Synopsis/Solicitation
- Solicitation number
- 75FCMC26R0022
About this file
This is a Questions and Responses document for the ClaimsCore RFP, containing 161 questions submitted by offerors and CMS's formal responses addressing clarifications on the solicitation requirements, Statement of Objectives, and evaluation processes.
Key clarifications provided include: the Proof of Concept (PoC) will process approximately 100 million historical production claims from February 2026 with dates of service in Calendar Year 2026, representing nationwide complexity across Part A, Part B, and DME; CMS will provide test claims, adjudication outcomes, and access to Tier 1 system data primarily through S3 buckets and flat files rather than APIs during the PoC; parity testing will measure final claim outcomes rather than intermediate rule execution logic; vendors must demonstrate support for local MAC-specific rule variations; the 6-month PoC (May 5, 2026 through November 4, 2026) will use isolated test data in a non-production environment with no cutover occurring during this phase; CMS will not provide full source code for legacy systems but will supply extracted business rules in Excel or web interface formats, with vendors ultimately responsible for rule discovery and implementation; integration with Tier 1 systems is required during PoC while Tier 2-4 systems are deferred to production; Phase 2 proposals require submission of a Small Business Subcontracting Plan; and the contract type remains Fixed Price (FFP) for services CLINs. Additional guidance addresses security compliance expectations (ATO-ready posture for PoC, full ATO for production), performance metrics (4 million claims per day baseline with 2x burst capability within 15 minutes, 99.9% uptime, subsecond adjudication excluding external system callout time), vendor shutdown and escrow requirements to be defined in production modifications, MAC onboarding sequencing (one MAC in year one, three MACs annually thereafter), and clarification that offerors may propose either vendor-owned or CMS-hosted cloud infrastructure deployment models.
View the file
Other files
Show all 19
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet1 Question Number SOO/RFQ Section and/or Page Number Question (for Offeror use) Response (for CMS use) Amended Document
| 1 | Solicitation, page 14 #11. | During the POC, will beneficiary data and associated claim history be aligned with the expected output so that offerors can accurately replicate the effects of Medicare benefit and beneficiary cost‑sharing rules? If so, what is the frequency to which updates will be provided? | Yes, best efforts will be made for across the board alignment of inputs and outputs especially those with a temporal component. We expect there may be some degree of variance in the data however that variance will be consistent across all participants. |
| 2 | SOO, Page 23 Section POC, Sub Section Dependencies & Integrations - Data sets and connectivity - “A claims test set along with the adjudicated claim and any available outputs such as the Electronic Remittance Advice” | Will CMS please provide an estimate of the number of claims and variety of claims that will be provided in the test data during the POC? | Offerors should assume a representative national complexity across Part A, Part B, and DME. We will supply POC Vendors with nationwide claims (defined as inbound 837i and 837p transactions) with dates of receipt in February 2026 which are for claims with dates of service in Calendar Year 2026 only. We do not have exact count of these claims yet, but estimate it will be approximately 100M claims. Additionally for the test data set CMS plans to also supply outcomes such as 835s, TA1, 999, and 277CAs for validation purposes. DDE and Paper Claims are not in scope for the PoC. |
| 3 | Proof of Concept Scope | Please confirm whether or not cross‑system claims synchronization between the replacement solution and legacy systems (FISS, MCS, DME) will be required. | Synchronization (e.g. claims adjudicated by the legacy system are sent to the PoC system and vis versa) will not be required during the proof of concept. Only in the production phase. CMS will work with offerors to define the technical details of how that synchronization will work. Real time lookups are unlikely to be feasible, however vendors are welcome to propose the approach and test feasibility. |
| 4 | Proof of Concept Scope | For purposes of dual-run alignment during the Proof of Concept and accompanying measurement Interval, will CMS define a specific claim subset, workload slice, or MAC jurisdiction as the primary evaluation baseline, or should offerors assume representative national complexity across Part A, Part B, and DME and at what volume? | Please see response to Question 2 |
| 5 | Appendix D | CMS lists CM/CMMI as one of the Tier 1 systems necessary for integration in the POC. Will CMS define a specific system, set of data, or Innovation Center model that must be included in the POC and evaluated against the POC metrics and QASP? | The CMS Center for Medicare and Medicaid Innovation (CMMI) team has already prepared and staged the majority of the alternative payment and care delivery models that are currently in production. These models will be accessible in our designated S3 bucket. |
By making these models readily available, we can efficiently pinpoint both provider alignment and beneficiary alignment-two essential data elements that legacy systems need when assessing and selecting a model. This method should reliably generate results that match those from previous vendor validation efforts. As a result, we’ll be able to accurately compare vendor outputs with established production outcomes, ensuring consistency and integrity in our evaluation process.
| 6 | SOO / Timeline / page 29 | |||
| & Solicitation / Page 2 | Will CMS please clarify if SOO timeline date is correct and update the document if needed? | |||
| SOO Excerpt: 2. Proof of Concept (Base Period, ending Jan 1 ‘27) | The date is misaligned and has been corrected in the document. Note some variability may be expected depending on actual award date and other factors. | See updated Section 10 of Attachment 1 - Amendment 1 ClaimsCore SOO. | ||
| 7 | Solicitation Page 2-3 | Given the large amount of discovery and resulting variance in the level of effort, would the government consider changing the services CLINS (0003, 0005, 0007, 0009, 0011, 0013, 0015) to be T&M and not FFP? | The government has considered the contract type for this requirement and has determined that FFP contract type remains the most appropriate contract type for this acquisition. We do not intend to change the contract type for services to T&M. | |
| 8 | Solicitation, pg. 33, 52.204-15 RFO | The solicitation includes 52.204-15 Service Contract Reporting Requirements for Indefinite-Delivery Contracts. | ||
| Given that this is not an IDIQ type contract, we recommend CMS remove this clause in the solicitation. | The clause has been removed from the RFP. | See Amended Solicitation document. | ||
| 9 | Solicitation, pg. 34, 52.219-9 RFO | The solicitation includes 52.219-9 Small Business Subcontracting Plan. | ||
| Given the solicitation does not include a small business subcontracting requirement, can CMS please confirm that submission of a Small Business Subcontracting Plan is not required? | The RFP has been updated to require submission with Phase 2 proposal. | See Page 2 of Amendment Attachment #3 - Instructions to Offerors. | ||
| 10 | Attachment 5, pg. 3, _x_ (24) 52.219-16, Liquidated Damages—Subcontracting Plan (Sep 2021) (15 U.S.C. 637(d)(4)(F)(i)). | The solicitation includes 52.219-16, Liquidated Damages—Subcontracting Plan. | ||
| Given the solicitation does not include a small business subcontracting requirement, we recommend CMS remove this clause in the solicitation. | See Response to Question #9. | |||
| 11 | Instructions, pg. 1, The contractor identified on the contract must be the CTA teammate expected to realize the most revenue under the contract, based on the data included in the cost/price volume. | RFP instructions state that: “The contractor identified on the contract must be the CTA teammate expected to realize the most revenue under the contract, based on the data included in the cost/price volume.” | ||
| Will CMS please confirm if Offerors are required to provide pricing detail separately for each subcontractor or vendor (also considered a subcontractor as defined in FAR 44.101 Definitions) in their cost/price volume, in order to allow CMS to determine subcontractor and/or vendor revenue amounts so that a determination can be made as to which has the most revenue under the contract? | The RFP has been updated to remove the sentence referenced in this question. | See Page 1 of Amendment Attachment #3 - Instructions to Offerors. | ||
| 12 | SOO/ Appendix D, page 59 | Pricers, Coding & Fee Schedules: Given the number of interfaces impacts the Oferror’s level of effort. Can CMS please confirm the number of interfaces. | For purposes of the PoC, interfaces to the Tier 1 systems (which may have 1 or more files or APIs per system) are expected. Production scoping is still underway, we are aware of at least 250 total file or API exchanges across dozens of systems and we expect that number to grow as we continue discovery with MAC facilitated exchanges of data. | |
| 13 | Proof of Concept Scope 20 | Please confirm contractors are processing actual production claims with all PHI and PII content versus historical and de-identified Medicare claim sets such as LDS files. | Data will be historical production data to ensure a true representative PoC. | |
| 14 | SUBMISSION REQUIREMENTS AND PROPOSAL DUE DATE - Page 2 | Could CMS kindly confirm that Phase Two proposals are not due on 3/13/26? Will offerors receive an invitation to submit proposals for Phase Two following evaluation of Phase One proposals? | CMS anticipates that Phase 2 proposals will be due two (2) weeks from the date Phase 1 Advisory down-select noticed are issued. Offerors invited to participate in Phase 2 will receive additional instructions and submission details via email. | |
| 15 | SOO Page 10 | The SOO mentions CMS is undertaking 'experimental efforts to extract and provide business logic'. What format will this logic be provided in, and what percentage of the total rules will be extracted prior to the PoC? | Efforts to extract business rules into rule catalogs include code and configurable edits across all MCS, FISS, DME and CWF for all MAC jurisdictions. Most efforts have resulted in very large excel files or comparable web interfaces. We expect to extract the majority of rules prior to the PoC or during the onboarding phase of the PoC however we remind offerors that offerors are ultimately responsible for the discovery and implementation of rules in their systems to achieve the highest possible parity with legacy systems. CMS is providing best efforts to extract business rules as an accelerator to offerors and will not consider gaps, limitations or incorrectness in the provided extraction as justification for inaccuracies in the offerors system. CMS can provide copies of the legacy systems code to offerors to develop their own views on the legacy system business rules. Extracted rules will be spot checked by CMS SMEs but not comprehensively validated. SMEs will be available to validate and explain rules on a case by case basis. | |
| 16 | SOO Page 26 | During the MAC 'split-history' run-out strategy, how will real-time beneficiary accumulators (deductibles, coinsurance) be synchronized between the Legacy System and ClaimsCore? | Please see response to Question 3 | |
| 17 | SOO Page 59 | Are the Tier 1 integration endpoints (e.g., PECOS, FPS, HIGLAS) modern REST/JSON APIs, or do they require legacy protocols (e.g., SOAP, flat-file over SFTP, batch bridges)? | CMS anticipates achieving accurate adjudication requires all Tier 1 data. Vendors should expect to pick up most data from S3 buckets as flat files in various formats appropriate to the source system for the PoC. APIs are generally not expected to be used during the PoC. All data supporting the PoC is expected to be live production data but used in PoC instances that are isolated from impacting performance of production systems. Load testing will be performed as part of the PoC and will require an inbound connection from an EDI Gateway. Further specification will be provided to awardees at onboarding. Production will have a much greater variation of file specs and transfer protocols. Vendors are expected to use historic claims and required Tier-1 data to generate the adjudicated outcomes. Data will be in our S3 bucket and most of it can be ingested bulk. | |
| 18 | SOO Page 3 | The SOO mentions reducing provider burden and improving beneficiary transparency. Will this system include a direct-to-provider or direct-to-beneficiary portal (e.g., Salesforce Experience Cloud), or will it strictly feed data to existing CMS portals? | The PoC will be limited to internal evaluation only. Production implementation is still in design in conjunction with the MAC partners. | |
| 19 | SOO Page 4 | What is the data quality of the historical VSAM and flat-file data, and who is responsible for the data cleansing (ETL) prior to ingestion into the new platform? | Currently contemplated access to historical data does not include a need to access VSAM files. CMS currently believes the data necessary to complete a migration exists in more accessible formats outside of the VSAMs. If the vendor believes access to VSAM data including copybooks, dictionaries, schemas, and other documentation and tooling is needed access can be provided. | |
| 20 | SOO Page 23 | For the Proof of Concept (PoC) phase, what specific subset of claims data (e.g.,a specific MAC, specific claim type like DME vs Part A) will be used to demonstrate parity? | Please see response to Question 2 | |
| 21 | SOO Page 4, "Context" | Can CMS provide detailed production claims volumes including average and peak daily volumes by claim type (Part A, Part B, DME) and MAC jurisdiction and historical growth rates over the past 5 years? | Please see response to Question 2 | |
| 22 | SOO Pages 4-5, "Statement of Need" | Can CMS provide historical data on policy change request frequency and complexity over the past 3 years along with the expected time to implement from request to production deployment? | Policy change frequency can be found in the CMS transmittals available here: cms.gov/medicare/regulations-guidance/transmittals. The historical timeframes are shown in each transmittal. CMS expects improvements from ClaimsCore to significantly reduce these timeframes. | |
| 23 | SOO Page 6, "Policy impact evaluation" | The SOO mentions there is currently no "model office" environment today to fully test policy changes. If the new ClaimsCore system includes a "model office" environment, will CMS provide a testing environment including key upstream and downstream CMS systems where contractors can validate impact of policy changes with historical data? | Yes, though this is not contemplated for the PoC. | |
| 24 | SOO Page 6, "Retroactive reprocessing" | Can you provide some examples of retroactive policy changes, along with affected claim volumes, that CMS has implemented in the past 5 years. | Examples of retroactive changes can be found in the CMS transmittals available here: cms.gov/medicare/regulations-guidance/transmittals. They are identified by cases where the Effective date is earlier than the Implementation date. | |
| 25 | SOO Page 6, "Data accessibility and reporting" | The SOO references "data stored in VSAM files and siloed, non-relational systems." Will CMS provide complete data dictionaries, copybooks, and schemas for VSAM files and other databases supporting the legacy systems, data extraction tools or utilities, and documented transformation logic currently used to extract data from VSAM? | Please see response to Question 19 | |
| 26 | SOO Page 10, "Business Logic migration" | Can CMS clarify the source of truth for the business rules and logic - legacy business rules extracted from existing applications or published CMS policy, regulation, and guidance? | The legal source of truth is published policy, regulation and guidance. Errors in code, business rules, or configured edits should be not be replicated in ClaimsCore and surfaced to SMEs to determine if corrections need to be made in the legacy systems. No new policy should need to be developed or approved to support the PoC. | |
| 27 | SOO Page 10, "Business Logic migration" | Can CMS clarify the governance process and timeline for resolving any conflicts discovered during the POC and production phases? | SMEs will provide same day guidance on implementation questions and will ensure edits and code effectuate reg/statute/policy rather than replicating errors in the legacy systems. | |
| 28 | SOO Page 10, "Business Logic migration" | Will CMS provide the architecture for all of the legacies application that are in scope for ClaimsCore? | Yes, to the extent such architecture is available. Further, questions may be posed to SMEs for additional discovery. | |
| 29 | SOO Page 16, Professional Services #5 "Support dual run testing and validation" | Will CMS provide standardized tools, test harnesses, or comparison frameworks for dual-run validation, or are contractors expected to develop their own variance analysis capabilities? If contractor-developed, how will CMS provide comparison data from the production systems and what type of unique identifiers will be there in the data to compare the results from the two systems? | CMS intends to develop an independent validation tool that will be used to measure the outcome parity between systems may become available for using during the deployment and implementation of the PoC prior to the measurement period but is not expected to have features beyond the static comparison of claims adjudicated on the legacy system and on a vendor system. Vendors are encouraged to use their own tools to conduct initial analysis and to identify edits that need to be adjusted to comply with published CMS policy. Test and validation data sets are expected to contain ~100M claims per data set. Outcomes will be provided for the test data set for vendors to iterate and exercise edits and logic in their systems. Outcomes will not be provided for the validation data set and will be evaluated by CMS to measure system accuracy. CMS expects deployment and testing to consume the majority of the 6 month PoC (Base Period) with a short period reserved for at the end for vendors to process the validation data set, provide outcomes to CMS, for CMS to conduct measurement, and other activities. Variance analysis will be assessed by SMEs on a case by case basis. | |
| 30 | RFP Page 33 | In regards to FAR 52.219-9 Small Business Subcontracting Plan, pursuant to FAR 19.704(d), will the Government confirm that a potential awardee's annual approved Corporate Plan satisfies the requirements or is the Government seeking an individual subcontracting plan? | Pursuant to FAR 19.704(d), a contractor with an approved Commercial (Corporate) Subcontracting Plan may use that plan to satisfy the requirements of FAR 52.219-9, provided the plan is current, approved by the contractor’s cognizant contracting officer, and compliant with applicable FAR requirements. | |
| 31 | SOO Pages 20, "Proof of Concept Scope" | Can CMS provide details about the inputs and outputs for the core claims processing for the proof of concept phase. | Please see response to Question 2 | |
| 32 | SOO Pages 21, "Deliverables" | Can CMS provide details about the directionality, inputs, outputs and an overview for each of the Tier 1 integrations that are part of the POC | Please see response to Question 17 | |
| 33 | SOO Pages 21, "Deliverables" | Can CMS confirm that we are required to integrate with the production environment of Tier 1 Systems or the non-production environment of Tier 1 Systems during POC? | Please see response to Question 17 | |
| 34 | SOO Page 20-21, "MAC Related Scope" | The SOO states "MACs, by design, have the authority to implement local coverage determinations, edits, and certain policies autonomously." Does this mean that the claims processing business rules and logic will need to include variations for each MAC? | During the POC, offerors will be asked to demonstrate the ability to support local variations for a single MAC. In the production phase, logic must support local variations for all MACs. | |
| 35 | Attachment 3 - Instructions, Section 2. Evaluation Factors for Award - Evaluation Process, Phase One (1), pages 4-5 | The instructions state: "This submission is limited to six pages in total length." The instructions add: "Proposals should include the following information as it pertains to the sources of experience cited in the narrative: 1. Client organization name and point of contact information; 2. Contract Number; 3. Period of Performance; 4. Explain whose experience is being proposed and the role of that firm in performance of the work envisioned under this solicitation." Will the government consider allowing the cited sources of experience information to be provided as a separate page to the narrative, outside of the six pages? This has been allowed on previous proposals and provides the appropriate and consistent space for all respondents to address the requirements in their narrative response. | The Government does not intend to revise the page limitation at this time. | |
| 36 | Attachment 1 - SOO, pages 11, 13 | The SOO describes two different SaaS models: One as a managed service in a FedRAMP-ed vendor hosted facility and another in CMS cloud infrastructure. Since a true SaaS model is subscription based but the product is owned by the vendor, can CMS clarify if the intent here is for the following: |
a) The vendor continues to own the product offering even when deployed in the CMS cloud environment and is not required to share any code for the core product with CMS (we understand that any custom code, test scripts, artifacts developed for CMS would belong to CMS).
| b) CMS expects the pricing to be a subscription model pricing (transaction costs + professional services) in the event of this being a managed service by the vendor. | Confirmed. | ||||
| 37 | Attachment 1 - SOO, pages 26, 27 | Since during the split-history period where both ClaimsCore and legacy are operational, ClaimsCore's performance will depend to some extent on the collaboration requirements with the legacy system maintainers. Can CMS confirm that the legacy contracts will be amended to include the new SLA/SLOs? | During the split-history period, these SLA/SLO targets will only apply for the portions of claims processing and other operations that the ClaimsCore solution is handling; all response time measurements will exclude any time taken by the shared systems. | ||
| 38 | Attachment 1 - SOO, Approach, Assumptions, 6, page 10 | The SOO states: "Contractor(s) must ensure appropriate system performance based on operational needs assessment and tied to payment penalties." Please clarify to which SLAs CMS will apply penalties. | CMS expects the details of payment penalties to be specified in a production contract modification post PoC. | ||
| 39 | Attachment 1 - SOO, Requirements, 13.2, page 15 | The SOO states: "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." Can CMS please specify the frequency, format, and artifacts that must be escrowed for each release? | CMS expects the details of escrow to be specified in a production contract modification post PoC. | ||
| 40 | Attachment 1, Page 22-23 | What test data, APIs, legacy system access, fee schedules, pricer logic, eligibility data, and provider enrollment data (e.g., PECOS) will CMS make available to POC awardees, and on what timeline relative to the May 5, 2026 POC start date? | Please see response to Question 17 | ||
| 41 | Attachment 1, Page 21-22 | What is the expected claims volume that awardees will be required to process during the 6-month POC? Will CMS provide a synthetic or real test dataset, and if so, approximately how many claims records will be included? | Please see response to Question 2 | ||
| 42 | Attachment 1, Page 23 | The SOO references POC Assessment Metrics (Section: POC Assessment Metrics) but specific numeric thresholds are not fully detailed in the public documents. Will CMS publish the specific pass/fail or scoring criteria for each POC metric prior to Phase 2 proposal submission so offerors can design their solutions accordingly? | CMS believes the current metrics are sufficiently well defined for the purposes of the PoC evaluation but is open to re-evaluation based on workgroup recommendations | ||
| 43 | SOO Page 59 Appendix D: Tier 1 Systems List | EDB/CME is listed as the repository for Medicare provider/supplier enrollment data. Isn't this the Enrollment Database / Common Medicare Environment which contains beneficiary information? | Your assessment is correct, thank you for identifying the error. Extracts from EDB/CME will be provided with daily updates. | See amended Attachment 1 - ClaimsCore SOO. | |
| 44 | SOO Page 21 Deliverable #2 and | ||||
| Page 22 Dependencies and Integrations | Integrating with Tier 1 systems is a vague requirement not well clarified in "Dependencies and Integration". Do these systems all have validated API's and/or standard interfaces that can be used to integrate with them? We're guessing these are the requirements for each system. Please correct/clarify as appropriate |
- EDI Gateway: Receive HIPAA compliant 837 claims, 270 eligibility verification, and 276 status inquiries. Return back 271 or 277 status responses
- EDB/CME: query database for beneficiary enrollment data. Possibly ingest bulk data depending on query speed.
- PECOS: query database for provider information. Possibly ingest bulk data depending on query speed.
- Pricers, Coding & Fee Schedules - calculate Medicare reimbursement
- FPS - send claim(s) to FPS and receive results back for fraud prevention
- CM/CMMI - unclear what integration would look like. Maybe submit certain claims here for alternative payment?
- PSF - unclear what integration would look like. Maybe periodically screen providers for fraud?
- MSP - send claims for coordination of benefits and possibly also receive a response back?
- HPMS - unclear what integration would look like
| - IDR - send data here for reporting? | Please see response to Question 17. In addition, please note that ClaimsCore will not be directly responsible for receiving, processing, or other handling of 270 inquiries; this will remain the responsibility of https://www.cms.gov/data-research/cms-information-technology/hipaa-eligibility-transaction-system. (ClaimsCore will of course have to integrate with and evaluate eligibility data as part of claims processing, however — it just won't have to handle 270 inquiries.) | Added new #4 #5 under deliverables. See Amended Attachment #1 ClaimsCore SOO. | |
| 45 | SOO Page 24 Pre-implementation planning | Does this 3 year timeline include the proof of concept phase? |
Is CMS more interested in moving as fast as possible to cutover to ClaimsCore or minimizing risk and disruption?
| Are there any hard deadlines that CMS must reach to be successful with the ClaimsCore migration (e.g. is CMS trying to get ClaimsCore migrated before the current administration leaves office)? | The 3 year timeline is for Production implementation and does not include PoC. CMS believes that timeline is reasonable given the market feedback it received during the market research phase and balances cost and risk appropriately. | |||
| 46 | RFP Page 2 Supplies or Services and Prices/Cost | The Proof of Concept is currently listed as going from May 5, 2026-November 4, 2026 (6 months). Is there any flexibility in this timeline? CMS has significantly expanded the scope of the proof of concept as compared to the sources sought notice. It now is requiring direct integration with 10 tier 1 systems. | No | |
| 47 | N/A | What is the current combined contract amount that is being spent annually that ClaimsCore is expected to replace? | CMS declines to answer. | |
| 48 | Attachment 5, FAR 52.219-9 Small Business Subcontracting Plan (Jan 2025), pg 2 | Please confirm whether Offerors should submit a Small Business Subcontracting Plan during Phase 2. | Yes. | |
| 49 | Attachment 5, FAR 52.219-9 Small Business Subcontracting Plan (Jan 2025), pg 2 | Would CMS provide target Small Business percentage guidance? | There are no prescribed target goals. Goals should be based on the requirements at FAR 52.219-8. | |
| 50 | Attachment 1, SOO, PoC Assessment Metrics, pg 24; Attachment 1, SOO, pg 21 | Page 24 states the metric, "Satisfies all CMS security and compliance requirements. Zero security incidents." Page 21 states, "Demonstrating security compliance and an ATO-ready posture appropriate to the PoC environment, including required controls, logging, access management, and vulnerability remediation practices." |
Please clarify which security/compliance requirements must be met for the PoC versus which are expected for production go‑live. For the Proof of Concept (PoC), CMS does not require a full Authority to Operate (ATO). Instead, vendors should demonstrate an ATO-ready security posture appropriate to the PoC environment. This includes implementing and documenting foundational security practices such as appropriate access controls, logging and monitoring, vulnerability management, and general adherence to Federal security best practices consistent with CMS expectations.
The PoC environment should be configured and operated in a manner that reflects how the solution would ultimately meet CMS security and compliance requirements in production, but formal authorization artifacts and a completed CMS ATO are not required for the PoC phase.
For production deployment, the solution must meet all applicable CMS security and compliance requirements and obtain the appropriate CMS authorization in accordance with CMS policies and procedures, including alignment with applicable Federal security standards and CMS security program requirements.
51 Attachment 1, SOO, PoC Assessment Metrics, pg 24 Page 24 states the objective, "sustain ≥4M claims/day and burst to 2× within 15 minutes without manual intervention."
| Please clarify whether the requirement to handle a 2× burst within 15 minutes without manual intervention is expected to be demonstrated as part of the PoC evaluation. | CMS does plan to conduct load testing during the PoC. | ||
| 52 | Attachment 3, Instructions to Offerors, 3. Basis of Estimate, pg 10 | “Offerors can choose to propose value added services under the services CLIN in each option period, at their discretion.” |
How would Offerors' value-added services impact the pricing evaluation?
| CMS does not believe it will impact the pricing evaluation. | ||
| 53 | Attachment 3, Instructions to Offerors, 3. Basis of Estimate, pg 10 | “Offerors can choose to propose value added services under the services CLIN in each option period, at their discretion.” |
| How should Offerors break out value added services pricing separately? | That is up to the discretion of the offerors. | ||
| 54 | Attachment 3, Instructions to Offerors, 3. Basis of Estimate, pgs 10-11 | “Proposed travel should be broken out into number of trips, number of travelers, and duration of trip for each destination. Details should be shown for all items, including commercial transportation, daily per diem rates, personal mileage, daily car rentals, etc. Travel costs will be reimbursed in accordance with the Federal Travel Regulation (FTR).” |
| Should travel expenses be included in the services CLINs, or estimated separately? | Include travel in the software or value added services CLINs - its up to the discretion of the offeror. | ||
| 55 | Attachment 1, SOO, pg 29 | Page 29 states, "Awardee(s) must deploy their solution, integrate with Tier 1 Systems, process a limited set of CMS data to validate baseline capabilities relative to the Evaluation Metrics, and demonstrate key functionality to CMS and MAC stakeholders before advancing to production implementation." |
Does the PoC require Offerors to perform bidirectional integration with the FPS system? For the POC, the CMS team will provide a copy of FPS data corresponding to the historical claims used for validation. This data will be stored in a S3 bucket. Vendors are required to pull data from the S3 bucket in a one direction only, consuming the relevant records for each respective date as needed.
A potential second phase of this data interaction is under consideration. In this phase, CMS may provide the required FPS edits to assess each vendor's ability to accurately replicate FPS output files for related historic claims. This phase is contingent upon the availability of the applicable edits within the POC timeframe.
| 56 | Attachment 3, Instructions to Offerors, b. Past Performance Instructions, pg 8 | For projects with commercial clients under an NDA, may the Offeror present past performance information without disclosing the client name? | Yes, the Past Performance Summary Table may exclude the name and POC of the client under these circumstances. Please indicate in the proposal where this is the case. The questionnaire is submitted by the reference directly to CMS, therefore the client can choose to disclose themselves to CMS. CMS confidence may be impacted where no client name or POC is offered and no PPQ is provided. | See Amended Attachment 3 -ClaimsCore Instructions to Offerors |
| 57 | Attachment 1, SOO, pg 29; Solicitation, pg 2 | In Attachment 1, on page 29, there is a reference to "Base Period, ending Jan 1 '27." In the Solicitation, on page 2, under the Supplies and Services table, Item "0001, Proof of Concept," the POP states an end date of "04 Nov 2026." |
| Please clarify the anticipated Base Period end date. | The Proof of concept/ Base period is scheduled to end on November 4, 2026. | ||
| 58 | Attachment 1, SOO, POC Assessment Metrics, pg 23 | "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 during which CMS and contractors will formally measure performance against the criteria in the table below." |
| Please confirm that the measurement interval begins at the end of the PoC period. | Please see response to Question 29 | ||||
| 59 | Attachment 6, Section 6 – Price Adjustment Process | Attachment 6 states that unit pricing is based on a “monthly price per unique beneficiary (PMPM)” and that the “estimated annual quantity reflects the projected average monthly beneficiary count multiplied by twelve.” However, the table shows 33,564,990 estimated monthly beneficiaries and 827,055,202 estimated annual beneficiaries, which does not align with the stated formula. Please clarify: (1) whether the annual quantity represents unique beneficiaries, beneficiary-months, or another utilization metric; and (2) how beneficiary counts are calculated for purposes of PMPM pricing and the True-Up process. | We agree that the math was not accurate and have updated attachment 6 accordingly. The number represents the average number of unique beneficiaries (members). CMS envisions a fixed, monthly rate applied to a member quantity that is the same for each month in a contract period. That quantity will be established in the contract at award and subject to prospective adjustment pursuant to the true up clause. Additionally, the clause has been revised to allow for claim-volume based metric for software pricing as an alternative to PMPM. | See Amended Attachment #6 - Beneficiary Quantities Claims and Unit Pricing | |
| 60 | SOO – Cost Drivers / Business Logic Migration | The SOO indicates CMS will provide rule and logic artifacts extracted from legacy systems but notes these artifacts may be incomplete. Will CMS provide the full COBOL/ALC/HLASM source code for MCS, FISS, DME, and CWF across all MAC jurisdictions, or only extracted rule artifacts for selected jurisdictions? | Please see response to Question 15 | ||
| 61 | SOO – Dependencies and Integrations / Tier 1 Systems | The SOO indicates CMS will provide interface documentation and connectivity for Tier-1 systems during the Proof of Concept. Will PoC participants receive sandbox access to live interface endpoints for Tier-1 systems (e.g., PECOS, HIGLAS, EDB/CME, FPS), or will connectivity be simulated using static data feeds and documentation only? | Please see response to Question 17 | ||
| 62 | SOO – Fraud Prevention System Integration | The SOO states that ClaimsCore solutions must integrate with the existing Fraud Prevention System (FPS). For PoC evaluation, should offerors assume FPS scoring must occur synchronously within the claim adjudication workflow, or will asynchronous or near-real-time risk scoring be acceptable? | Please see response to Question 55 | ||
| 63 | SOO – Historical Data / Data Migration | The SOO indicates that up to three years of historical claims data will be provided for PoC evaluation. For production implementation, does CMS anticipate full historical migration of claims data into ClaimsCore, or will historical data be accessed through external archives or federated queries? | It currently seems unlikely that external archives or APIs will be available or sufficiently resourced to accommodate near real time production adjudication. | ||
| 64 | SOO – Parallel Processing and Dual-Run Validation | The SOO describes parallel operations between legacy systems and ClaimsCore during transition. Will CMS provide detailed adjudication artifacts from legacy systems (e.g., ERA outputs, edit triggers, payment breakdowns) to enable automated parity validation during PoC and production dual-run periods? | Yes | ||
| 65 | SOO – MAC Onboarding / Split History Operations | The SOO describes a temporary “split-history” operating model during MAC onboarding where claims history may exist in both legacy systems and ClaimsCore. Does CMS expect ClaimsCore to maintain a synchronized operational cache of legacy claims history during this period, or will real-time lookups to legacy systems be acceptable? | Please see response to Question 3 | ||
| 66 | SOO – Integration Scope | The SOO references approximately 200 integrations across CMS and MAC systems. For PoC evaluation, beyond Tier-1 integrations, should offerors assume that Tier-2–4 systems will be stubbed or simulated until production implementation? | No consideration of Tier 2-4 systems is required for PoC. | ||
| 67 | Solicitation – Pricing Volume / CLIN Structure | The solicitation defines separate CLINs for software and services across option periods while Attachment 6 defines pricing on a PMPM basis tied to beneficiaries. Should offerors assume that PMPM pricing applies only to software CLINs while implementation and operational labor should be priced under the services CLINs? | Not necessarily. Offerors have discretion to specify what scope is included in the software CLIN, which may include operational labor. We provided offerors with latitude to propose all scope in the software CLIN, or alternatively to include some services in a separately priced line item. | ||
| 68 | SOO – Architecture and Deployment Model | The SOO indicates CMS prefers a single scalable instance supporting all beneficiaries but allows distributed deployments per MAC or MAC region if cross-region awareness is maintained. Are there any CMS policy or architectural constraints that would limit the use of logically segmented tenants within a single national deployment? | No. | ||
| 69 | SOO – Provider and Beneficiary Data | The SOO notes that the PoC may include beneficiary and provider datasets for up to ~33.6M beneficiaries and national provider enrollment data. Will the PoC dataset reflect the distribution of claim types, provider types, and utilization patterns observed in production Medicare claims, or will it represent a simplified subset of workloads? | Please see response to Question 2 | ||
| 70 | SOO – System Performance & Operational Efficiency | The SOO specifies targets such as ≥99.9% uptime and near real-time adjudication latency. Will CMS evaluate these metrics based solely on adjudication time within the vendor platform boundary, or will evaluation include end-to-end transaction time including upstream and downstream CMS systems? | Both will be considered, vendors will not be responsible for latency caused by non-vendor controlled systems. | ||
| 71 | SOO – Rule Transparency and Explainability | The SOO emphasizes rule transparency and explainability of adjudication outcomes. Should offerors assume that rule logic must be traceable from claim outcome back to CMS policy references (e.g., Internet-Only Manuals, NCD/LCD policies), or is explainability limited to system-level edit traces? | CMS requires parity with the legacy system behavior however we are interested in features and functionality that reduces operational burden or adds measurable value. | ||
| 72 | SOO – Edit and Rule Migration | The SOO states contractors must migrate legacy rules into configurable structures. Does CMS expect all legacy edits to be implemented using configurable rule engines, or will certain high-performance logic elements be acceptable as compiled code or service-based components? | CMS has a strong preference for configurable, auditable, transparent edits however in certain circumstances well documented compiled or service based components may be required to achieve required metrics. Use of these tools should be kept to a minimum, must not break upgrade paths, implement automated regression testing, rely on clearly versioned backwards compatible API contracts, be portable, documented, and auditable. | ||
| 73 | SOO – Policy Change Agility | The SOO describes implementing policy changes in hours or days rather than the current multi-month cycle. For evaluation purposes, does CMS expect offerors to demonstrate automated regression testing frameworks capable of validating rule changes against historical claim datasets? | CMS will evaluate all vendors on their ability to deliver this requirement in a way that minimizes the possibility of adverse impacts. | ||
| 74 | SOO – Data Accessibility and Reporting | The SOO identifies near real-time reporting and analytics as a key objective. Should offerors assume that ClaimsCore must support both operational dashboards for MAC staff and enterprise analytics data feeds for downstream CMS systems such as IDR and CCW? | Yes | ||
| 75 | SOO – MAC Operational Model | The SOO indicates MAC operational processes will remain in place but supported by the new ClaimsCore platform. Should offerors assume MAC staff will continue performing manual adjudication, adjustments, and appeals functions directly within ClaimsCore user interfaces? | During the production phase the vendor will engage with each MAC to determine MAC preferences for the implementation of ClaimsCore. It would be reasonable to expect in some cases MACs will require integration of existing tools into ClaimsCore and in others a migration to use ClaimsCore as their new UI. | ||
| 76 | SOO – Claims Intake Validation | The SOO indicates contractors should not assume inbound claims are fully validated prior to system ingestion. Should offerors implement full HIPAA SNIP validation levels (including semantic and balancing validations) within ClaimsCore before adjudication processing begins? | Yes | ||
| 77 | SOO – Parallel Processing Validation | The SOO describes comparison of adjudication outcomes between legacy and ClaimsCore systems. Will CMS provide standardized reconciliation tools or expected comparison schemas for identifying and explaining adjudication differences during PoC evaluation? | Please see response to Question 29 | ||
| 78 | SOO – Program Integrity Capabilities | The SOO emphasizes integration of fraud detection and payment integrity capabilities into adjudication workflows. Should offerors demonstrate native pre-payment analytics capabilities in addition to integration with CMS FPS? | Yes, where possible | ||
| 79 | SOO – Production Rollout Timeline | The SOO indicates the contractor will develop an Integrated Master Plan and Schedule (IMPS) targeting full production deployment. Does CMS have a target timeframe for completing migration of all MAC jurisdictions following PoC completion, or will the rollout schedule be determined by the contractor’s IMPS? | CMS has tentatively guided towards 1 full MAC implementation in the first year of production, and 3 MACs each year following. However, each vendor should plan to own and lead the implementation process and provide its own best estimates on what is reasonable given its own unique operating model. | ||
| 80 | Maxwell8 | The SOO emphasizes reducing provider administrative burden. Should offerors demonstrate provider-facing capabilities such as real-time claim status APIs and digital submission of documentation as part of the solution architecture? | Yes | ||
| 81 | SOO – Cloud Deployment Models | The SOO indicates vendors may propose SaaS solutions hosted either in vendor-owned cloud infrastructure or within CMS cloud environments. Will CMS evaluate these deployment models equivalently, or does CMS have a preferred long-term production hosting model? | CMS intends to evaluate all proposals based on the confidence level it has the vendor can deliver on stated objectives regardless of deployment model. CMS does not intend to modify the deployment model after the PoC phase. | ||
| 82 | SOO – Interoperability / Appendix D Tier-1 Systems | The SOO references interoperability with clearinghouses and identifies the CMS EDI Gateway as the primary entry point for electronic claims. Should offerors assume clearinghouse services will continue routing claims through the CMS EDI Gateway, or should ClaimsCore support direct claim submission from providers or clearinghouses? | For the PoC offerors should expect to receive claims though the current EDI Gateway. Other approaches can be considered during the production transition. | ||
| 83 | SOO – System Performance & Operational Efficiency / PoC Metrics | The SOO describes “near real-time adjudication” with latency targets for clean claims. Should offerors assume all claim types must be processed synchronously within these latency targets, or may asynchronous processing models be used for complex claims requiring additional validation or manual review? | During the PoC, offerors should pend claims at parity with legacy system behaviors. In production MACs have automated the manual review of certain pended claims with external RPA tools, in which case the offeror may support the implementation of rules and edits to support those cases. | ||
| 84 | SOO – Proof of Concept Scope | The SOO indicates the PoC will include adjudication of Part A, Part B, and DME claims. Will CMS provide additional information regarding the expected claim mix, complexity distribution, and approximate claim volumes processed during PoC evaluation? | Please see response to Question 2 | ||
| 85 | SOO – Dependencies and Integrations / Tier-1 Systems | For PoC evaluation, should offerors assume that full operational integrations with all Tier-1 systems (e.g., EDI Gateway, PECOS, HIGLAS, FPS, EDB/CME) are required, or may certain integrations be simulated where CMS provides representative data feeds? | Please see response to Question 17 | ||
| 86 | SOO – PoC Assessment Metrics | The SOO references a defined “Measurement Interval” for PoC performance evaluation. Will CMS provide additional guidance regarding the expected workload profile, duration, and claim throughput during the Measurement Interval? | Please see response to Question 29 | ||
| 87 | SOO – Business Logic Migration / Rule Extraction | The SOO states contractors must migrate legacy business logic and demonstrate parity with legacy adjudication outcomes. Should parity requirements apply strictly to final claim outcomes (e.g., pay/deny/payment amount), or must intermediate rule execution logic also match legacy system behavior? | CMS does not expect that the intermediate logic or order of execution will be the same between the legacy system and ClaimsCore systems except to the extent that execution order impacts outcomes. | ||
| 88 | SOO – CMS & MAC Operations | The SOO indicates MAC operational responsibilities will continue under the ClaimsCore platform. Should offerors assume MAC personnel will perform operational activities such as manual claim adjudication, adjustments, and appeals directly within ClaimsCore interfaces, or through existing MAC systems integrated with ClaimsCore? | Please see response to Question 75 | ||
| 89 | SOO – MAC Configuration Governance | MACs historically maintain jurisdiction-specific rules and coverage determinations. Should offerors assume that ClaimsCore must support MAC-specific rule configurations and governance processes allowing MACs to manage jurisdiction-specific policies independently within the platform? | Yes. | ||
| 90 | SOO – CMS & MAC Operations / User Access | The SOO references operational use of ClaimsCore by CMS and MAC personnel but does not provide estimates of the expected user population. Will CMS provide estimated numbers of users by organization (e.g., CMS staff, MAC staff, contractor staff) and by role type (e.g., claims examiners, customer service representatives, program integrity analysts, system administrators, auditors) in order to support system sizing, licensing assumptions, and access control design? | Given that each ClaimsCore offeror's system may require different mixes of personnel and effort, and also given the decentralized nature of Medicare's staffing, CMS will not be able to specifically list staff in this way. The offerors should expect that CMS and MAC personnel will be able to access ClaimsCore, and that typical roles (e.g., reporting, claims adjudication, rule configuration, accumulator maintenance, etc.) will be fulfilled. This number will be fully clarified during the POC as it becomes clear the levels of effort needed to execute these tasks. | ||
| 91 | SOO – System Performance & Operational Efficiency | In addition to the total user population, will CMS provide estimates of expected concurrent users and typical operational workflows (e.g., claim review, appeals processing, reporting) in order to support system capacity planning and user interface performance design? | Please see response to Question 90. | ||
| 92 | SOO - Dependencies and Integrations | The SOO indicates under Data Sets and Connectivity, that beneficiary data will be shared. However, in the Tier 1 list, there is no mention of a beneficiary data system. How will beneficiary information be shared -- both initially and then maintained over time? | Please see response to Question 43 | ||
| 93 | SOO - Appendix B - QASP | The SOO describes sub‑second adjudication as being measured within the vendor system boundary for clean claims. Can CMS confirm that this performance metric excludes any latency associated with call‑outs to CMS‑owned or third‑party Tier 1 integrated systems (e.g., PECOS, FWA/risk‑scoring services, eligibility/entitlement APIs)? In other words, is the sub‑second requirement intended to apply strictly to the internal adjudication processing performed within the vendor platform? | Please see response to Question 70 | ||
| 94 | SOO - Policy Change Agility | The SOO emphasizes the need for rapid, configuration‑based policy agility to support Medicare rule changes that historically require 7–12 months. Can CMS clarify what types of policy changes they expect the vendor’s platform to support through configuration (e.g., coverage rules, pricing logic, CCI edits, NCD/LCD changes, DME fee adjustments, FWA thresholds)? Additionally, does CMS expect the vendor to provide CMS staff with a rule‑authoring or configuration interface, or will rules be configured exclusively by the vendor’s team? | Offerors should expect guidance to be issued in a similar fashion as they are today. Those transmittals may be accessed here https://www.cms.gov/medicare/regulations-guidance/transmittals. Offerors should propose assuming that MAC staff would be able to edit/create rules for their jurisdictions, at a minimum. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .