Question Response- final.xlsx
XLSX spreadsheet 53 KB Posted
- Attached to
- DA10--Payment Integrity Validation and Oversight Tool (PIVOT) (VA-26-00015670) RFI LoopBack
- Solicitation number
- 36C10B26Q0121
About this file
This file is a Question and Answer (Q&A) document compiled from vendor inquiries regarding RFI 36C10B26Q0121 for the Payment Integrity Validation and Oversight Tool (PIVOT), a Department of Veterans Affairs Technology Acquisition Center (TACO) requirement.
The RFI seeks a Software-as-a-Service (SaaS) solution for payment integrity validation and oversight of VA Community Care claims, with responses due February 6, 2026, at 12:00 PM ET. Vendors must submit an Intent to Participate by January 23, 2026, at 12:00 PM ET to Felica.Griffin@va.gov with subject line "36C10B26Q0121." RFI submissions require three separate documents: a 2-page technical functionality description, a 2-page response narrative (company information and demo attendees list), and an unlimited PowerPoint presentation—all due February 6, 2026. The ROM (Rough Order of Magnitude) must include SaaS subscription pricing and implementation/professional services costs for the full period of performance, with pricing units at vendor discretion. Virtual Technical Demonstrations (VTD) will follow, with up to 10 participants per vendor permitted. The solution must process approximately 82 million claims annually at near real-time speeds (~8 transactions/second, 2-second response time per transaction), support 100 concurrent users with scalability, and include a Rules Engine with CMS compliance rules (NCCI, MUE, MPPR), pattern recognition/anomaly detection, AI/ML capabilities targeting 95% accuracy, real-time claims ingestion and routing, duplicate detection, and comprehensive dashboards with no-code customization. The system must achieve FedRAMP High authorization and integrate with existing VA systems; however, specific integration details and system architecture documentation will be provided at contract award. An MVP must be production-ready within 120 days of award, delivering core functionality including industry-standard rules and operational dashboards, with additional VA-specific rules and ML capabilities delivered post-MVP. The solution should support retroactive claims analysis with a VA-defined lookback window, continuous improvement through quarterly model retraining, and measurable KPIs including 3:1 ROI over 12 months and 85% recoupment realization. VA expects unlimited rights to VA-specific rule logic and configurations (not vendor's proprietary platform IP), with proprietary restrictions to be disclosed at proposal submission. The anticipated contract period is 12 months with four 12-month option periods (60 months maximum), though an RFP has not yet been issued. No set-aside determination has been made at this stage.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 36C10B26Q0121 0003.docx | DOCX document | |
| 36C10B26Q0121 0002.docx | DOCX document |
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
Responses_Final
| Question | PBI Response |
| Will the VA entertain a solution that specifically addresses home-based care at this stage in the demonstration process or will the VA only accept demonstration proposals that address all aspects of the community care network? | No, VA expects vendors to demonstrate their ability to deliver the PIVOT solution as described in the PWS. Solutions should not be limited to home-based care. For details, see PWS Section 3.0 and RFI Demonstration Content Requirements. |
| Does the VA have a vision for the PIVOT tool to provide a real-time claims editing solution embedded in the claims processing workflow (pre-adjudication) that identifies smaller policy aberrations/violations and pends the claim before payment? Or does VA desire the PIVOT Tool to provide a real-time Fraud, Waste and Abuse Pattern review that pends claims for further investigation due to FWA suspicious behavior? | PIVOT operates within VA’s Community Care claims workflow to support near real-time rule execution during ingestion. As noted in Sections 5.2.1, rules may be flagged for “No Pay” denial after Rules Engine outputs; and as noted in section 5.2.2, claims are routed for post-payment review based on risk and confidence scoring. |
| Can VA elaborate on the level of customizations desired in the reporting and dashboard functionality for PIVOT? | The level of customization should be demonstrated as part of the Virtual Technical Demonstration. Vendors should demonstrate their solutions no-code dashboard and reporting customization, dynamic filtering, drill-down, and export capabilities, as outlined under “Demonstration Content Requirements – Reporting and Dashboard Functionalities” in the RFI. |
| Could you please confirm that the submission on January 23, 2026, is merely an indication of our intent to participate in the demonstration and that we are not required to provide the names of the participants at this stage? | Yes—Intent to Participate is due Jan 23, 2026 at 12 PM ET. The RFI states “Vendor intent to participate in the solution demos should be submitted by January 23, 2026 at 12 PM. The list of VTD participants (up to 10)” to be included with the RFI response submission (i.e., the full submission due Feb 6). |
| Please verify that the technical submission due on February 6, 2026, should be comprised of four pages: two pages containing company information and the list of demo attendees, including the ROM for SaaS, and two additional pages detailing the technical requirements. Additionally, confirm that this can be submitted as a single document. Also, we would appreciate confirmation that the PowerPoint presentation, which is not subject to a page limit, is due on the same date, February 6, 2026, but should be submitted as a separate file. | The submission must include: |
- Two pages for the RFI narrative (company information and required responses).
- Two pages for the technical functionality description.
- A PowerPoint presentation (no slide limit) submitted as a separate file.
These items cannot be combined into a single document. Each must be submitted as separate attachments. All are due February 6, 2026, at 12:00 PM Eastern Time
| Would the VA consider granting a one-week extension for the February 6, 2026 deadline, moving it to February 13, 2026? | All submissions remain due February 6, 2026, at 12:00 PM Eastern Time as stated in the RFI. Deadlines are firm. |
| Is there a required format (margins, font size, required information) for the 2-page technical document submission due February 6, 2026? |
Could you please clarify whether we should submit the comments regarding the sufficient detail on the PWS with the January 23 submission or the February 6 submission?
a. Does the question/response fall within the 2-page technical submission page limitation? There are no specified requirements for margins, font size, or layout in the RFI. Only the page limit applies. Comments on whether the PWS provides sufficient detail must be included with the February 6, 2026 submission, not the January 23 intent notice. Yes, your response to the “sufficient detail” question falls within the 2-page narrative limit, which is separate from the 2-page technical functionality description.
All submissions are due February 6, 2026, at 12:00 PM Eastern Time
| For pricing purposes regarding the ROM request, how many covered lives/beneficiaries will be covered by the PIVOT solution? | The Government cannot provide this information at this time. |
| I am trying to determine whether this opportunity is set-aside for 8(a). We have a perfect solution but are not an 8(a) firm. The initial solicitation seemed to call out 8(a) but I don't see it mentioned in the modification. We are an SBA-certified WOSB. | This RFI is for informational purposes only and a decision on set-a- sides have not been made at this time. |
| We noticed today the revised RFI question deadline changed from the January 23 to January 16. We will be submitting our questions first thing on Tuesday AM – we sincerely apologize for missing the notification on date change. |
Also, may we have clarity on deliverable dates:
Jan 23 Intent to Participate
| Feb 6 Power point Presentation for demo day Two Page Technical Document ROM List of participants | The RFI states “Vendor intent to participate in the solution demos should be submitted by January 23, 2026 at 12 PM. The list of VTD participants (up to 10) to be included with the RFI response submission" (i.e., the full submission due Feb 6). | |
| For the presentation deck being requested, is this deck for use in conjunction with the demo? Or is the presentation deck intended for some other purpose? | The presentation deck is intended for use during the Virtual Technical Demonstration (VTD) in conjunction with the live demo. | |
| Can the Government please clarify the scope and level of detail required for the requested Rough Order of Magnitude (ROM) pricing for the SaaS solution, including whether the ROM should cover only the base period or the full period of performance? | The ROM should include pricing for the full period of performance, not just the base year. VA requires a breakout of labor category hours by deliverable for the full period of performance, as outlined in the PWS. | |
| Where should the notice of intent be submitted. | The notice of intent must be submitted by email to: |
Recipient: Felica Griffin (Contract Specialist) Email: Felica.Griffin@va.gov Subject line: Include “36C10B26Q0121” Deadline: January 23, 2026, at 12:00 PM Eastern Time File size limit: Email attachments must not exceed 5 MB Marking: If your information is business sensitive, mark your response as “Proprietary Information”
| As relates to RFI PWS 5.5, Minimum Viable Product (MVP) Scope and Delivery: | ||
| a. | Please specify which requirements must be included in the MVP within 120 days? | |
| b. | For Pattern Recognition and Anomaly detection, will the VA consider delivery after MVP? This capability is not available within 120 days due to volume, model training, and testing timeline of "production data". | |
| c. | For Human-in-the-Loop feedback, will the VA consider this as post MVP activity since it will likely result in on demand customization of the code, modeling, and user interface? | |
| d. | For Rules Engine, will the VA provide the VA payment requirements for the vendor to build the business logic for MVP? | |
| e. | Should MVP only include industry-standard operations, i.e. CMS payment requirements? | VA will review MVP requirements and make any necessary clarifications or updates prior to release of the RFP. VA expects the Rules Engine to be populated with industry-standard rules for MVP, and any critical VA rules will be communicated to the Vendor. |
| Although the contract type is unspecified within the RFI PWS, PWS 4.3, Travel, suggests a Firm Fixed Price (FFP) order. For offerors to provide an accurate FFP for unknown tools and features that could be at varying prices, precise details must be defined within the PWS. Otherwise, Offerors will need to account for unknown risk within their FFP. | ||
| a. | Will the Government provide a revised PWS to specify these requirements? | |
| b. | If not, given that the requirement is for additional tools and features that cannot be identified at this time, and thus cannot be priced by an Offeror accordingly, will the Government consider adding an NTE optional task(s) within PWS 5.11 for these unknown requirements? | VA will make any necessary clarifications or updates prior to release of the RFP. |
| Is there a required format (margins, font size, required information) for the 2-page technical document submission due February 6, 2026? | See response to Q8. | |
| Please clarify whether we should submit the comments regarding the sufficient detail on the PWS with the January 23 submission or the February 6 submission? | ||
| a. Does the question/response fall within the 2-page technical submission page limitation? | Comments on PWS detail should be included with the January 23 submission for questions and feedback. The 2-page limit applies only to the technical functionality description due February 6 and does not include PWS comments. | |
| Is the technical functionality description (limited to two pages) separate and distinct from the capability statement (limited to two pages) requested, or is the reference just one document for submission? | Yes | |
| Where the questions from the first RFI (Nov25)responded to? Or are the questions being rolled into the solutions demo? | ||
| Did you have a lot of interest from the prior RFI? | VA reviewed all responses from previous RFI submissions and made relevant updates to the PWS. | |
| Can the Government clarify if by "separate" it intends for industry to provide the ROM as its own separate document? | The ROM shall be included in the two (2) page technical document. | |
| Can the Government provide the anticipated project timeline for production deployment of the solution? | See PWS Sections 5.5 and 4.1. | |
| Can the Government clarify what system is the VA currently using to support Payment Integrity Validation processes? | The complete list of integrated systems, including documented APIs, will be provided at the time of award. See PWS Section 5.4. | |
| As indicated in the RFI document, this is version 3.0. Can the Government explain how RFI 3.0 factors in responses from the previous RFIs? | VA reviewed all responses from previous RFI submissions and made relevant updates to the PWS. | |
| Can the Government provide the anticipated timeline for the Virtual Technical Demonstration? | Refer to the VTD section as well as the highlighted information on page 10 of Amendment 0001. | |
| Can the Government provide the anticipated start date of the project/contract award? | The Government cannot provide this information at this time. | |
| Can the Government provide the anticipated release date of the RFX solicitation? | The Government cannot provide this information at this time. | |
| Can the Government provide the anticipated solicitation method for this requirement? | The Government cannot provide this information at this time. | |
| The RFI states: "Provide a separate Rough Order of Magnitude (ROM) cost estimate for the SaaS product in accordance with PWS." Can the Government clarify what is being requested for the ROM cost estimate? Is the Government requesting the cost estimate just for the SaaS product, or inclusive of all other items included in the PWS (i.e., Optional Tasks, Travel, Maintenance, etc.)? | Vendor's ROM should include all requirements included within the PWS. | |
| Should the Government’s responses to vendor questions result in material changes to the RFI requirements or VTD expectations, will VA consider extending the deadline for vendors to submit their intent to participate in the VTD (and, if applicable, the associated submission deadlines) to ensure vendors have adequate time to incorporate the revised requirements? | Current deadlines remain firm unless a modification is issued through a SAM.gov. | |
| The Government expresses interest in a SaaS-based PIVOT solution. Given the unique structure of VA claims/payment data and the variety of VA system interfaces that must be integrated, we anticipate custom integrations will be necessary to meet the PWS objectives. Will VA consider solutions that deliver PIVOT as a SaaS while leveraging existing VA PaaS / low-code / automation investments (e.g., Appian, Pega, UiPath, Microsoft Power Platform, or similar) for workflow, integration, and automation, rather than requiring a “pure COTS” product with only out-of-the-box connectors? | Efficiency is measured by reduced manual review, expansion of monitoring capabilities, and faster identification of improper payments; VA expects measurable cycle-time reduction and ROI gains as stated in the PWS. | |
| Section: ROM cost estimate request. For the ROM SaaS cost estimate, should pricing be provided as subscription only, or include implementation/professional services, and what pricing units do you prefer (per-user, per-claim, per-million-claims, per-environment)? | Provide SaaS subscription ROM and implementation/pro services ROM. Pricing units at vendor discretion (per‑user/claim/volume/env); include assumptions & PWS mapping. | |
| Section: Cover - SaaS based Solution. Please confirm whether VA prefers a single integrated prime that provides both the SaaS platform and professional services, or whether VA anticipates separating SaaS licensing from integration/ops support. | VA has no stated preference. Propose either integrated prime (SaaS+services) or a split model. Vendors should propose their best approach to meet the Government requirements. | |
| Section: VTD Rules. The VTD disallows communication with individuals outside the virtual team. Will VA allow (a) read-only observer SMEs off-camera, or (b) break-glass technical support if Microsoft Teams connectivity issues occur? | Off-camera observers are not allowed; break-glass tech support for connectivity may be permitted if disclosed on roster and TAC contracting staff notified during the session. | |
| Section: Cover - VTD Dataset Statement. VA will not provide a dataset for the VTD. Will VA accept synthetic/de-identified representative claims data and should vendors align scenarios to any specific VA Community Care claim archetypes (e.g., high-dollar inpatient, pharmacy, OPPS) | Yes. Use synthetic/de‑identified data. Align scenarios to representative VA Community Care claim types (e.g., 837P/I/D, OPPS, inpatient, pharmacy) as appropriate. | |
| Section: Cover - Sec. 6. Please confirm whether the “2-page technical functionality description” is in addition to the 2-page response narrative, or whether there is a single combined 2-page limit (the notices appear to describe limits differently). | Three separate limits: |
1st - 2 pages technical functionality description;
2nd - 2 pages response narrative.
3rd - PowerPoint has no slide limit.
| Section: Cover Problem Statement. The solution must support 100 concurrent users. Please provide the expected total user population, user role mix, and any forecasted growth (e.g., year 1 vs year 3). | Baseline 100 concurrent plus scalable with optional tasks. Roles: Auditor/Analyst/Supervisor/Admin. Growth and precise user counts will be refined at award; propose scalability in your approach. See PWS Sections 3.0 and 5.2. |
| Please specify the claims/invoices volume (daily/monthly), peak ingestion windows, and whether “real-time processing” means sub-minute streaming vs near-real-time batch. | Est. 82M/yr; near real‑time ingest and routing; target approximately 8 transactions/sec. Peak windows and streaming/batch specifics will be defined at award. See PWS Section 5.2.1. |
| Section: PWS Performance Metrics Table. The PWS says “response time ≤ 2 seconds per transaction.” Please define what constitutes a transaction (API call? UI query? rule execution? claim ingest?) and the measurement conditions (payload sizes, concurrency, environments). | In the context of the PWS Performance Metrics Table, a “transaction” covers API/UI queries & rule execution returning results. Measurement conditions (payloads, concurrency, environments) will be set in the test plan/UAT. See PWS Section 6.4. |
| Section: PWS System Architecture & Integration. VA will provide a list of systems requiring integration “at time of award and during project initiation.” Will VA share (even at RFI stage) a representative list of likely systems and integration patterns (API vs file vs message bus)? | VA will not provide a representative list of systems or integration patterns during the RFI stage. See PWS Section 5.4. |
| Section: PWS System Architecture & Integration. The PWS calls for standards-based integration including HL7/FHIR, but this is a payment integrity tool centered on claims formats like 837/835. Which integrations truly require HL7/FHIR vs claims/financial interfaces? | Claims/financial (X12 837/835) are primary. HL7/FHIR used where clinical/eligibility/referral systems require it. See PWS Sections 5.2.1 and 5.4. |
| Section: PWS Pattern Recognition Engine. The PWS states flagged claims must be transmitted for payment “without delay” unless directed otherwise. What is the operational mechanism for VA to issue “directed otherwise” instructions (per rule? per provider? emergency stop), and what is the required latency/authorization path? | Final determination will be made collaboratively after contract award and through Governance process. See PWS Sections 5.2.2, 5.2.3 and 5.2.4. |
| Section: PWS MVP Rules Engine. Please define how VA wants to operationalize Pay and Report vs No Pay thresholds (who sets thresholds, approval workflow, and where denial metadata must be recorded/consumed downstream). | VA sets/approves thresholds via governance. No Pay: sends denial metadata downstream. Pay & Report: pay, then route flags to workload module. Changes follow tiered approvals. See PWS Sections 5.2.2 and 5.2.4. |
| Section: PWS MVP Rules. For “rules configurable without custom code changes,” what is VA’s interpretation of custom code (e.g., configuration + SQL allowed? DSL scripts? low-code rule definitions?) | VA expects rule thresholds and criteria to be configurable without requiring extensive development cycles, custom coding, or long sprints. Configuration should be achievable through standard system tools (e.g., UI-based settings or low-code options) rather than rewriting core logic. See PWS Sections 5.2.2 and 5.5. |
| Section: PWS Pattern Recognition Engine. The PWS requires “Additional patterns may be incorporated… at no additional cost to VA.” Please clarify what constitutes an “additional pattern” (new model type? new feature engineering? new data source?) and how many per quarter/year VA anticipates. | VA will consider revising or clarifying in the RFP. |
| Section: PWS Performance Metrics Table. The PWS requires AI/ML accuracy ≥ 95%. Please define the metric (precision, recall, F1), the labeled ground truth source, and whether this is a contractual AQL vs a target KPI. | VA will consider revising or clarifying in the RFP. KPIs and AQL targets will be defined at kickoff and documented in the QASP. See PWS Section 6.4. |
| Section: PWS Performance Metrics Table. The PWS includes ROI ≥ 3:1 over 12 months and Recoupment Realization ≥ 85%. Please clarify whether these are intended as enforceable performance requirements, and what baselines/attribution model VA will use. | Intended as QASP KPIs/AQLs. Baselines & attribution defined at initiation; measured via audit/recoupment tracking & financial analysis. See PWS Sections 6.4 and 5.2.5. |
| Section: PWS Business Rules/Logic. The PWS requires exporting rule logic and grants VA “unlimited rights” to store/reuse/modify rule logic, with proprietary restrictions disclosed at proposal submission. Please define what VA considers “rule logic” vs vendor platform IP (e.g., model code, feature engineering pipelines, proprietary detection algorithms). | VA considers “rule logic” to include all elements necessary to understand and replicate compliance determinations, such as formulas, thresholds, mappings, criteria, calculations, version history, and associated metadata. These must be exportable in VA-approved formats and provided with unlimited rights as stated in PWS Sections 5.2.2 and 5.2.2.1. Proprietary platform components—such as underlying model code, feature engineering pipelines, or proprietary detection algorithms—remain vendor intellectual property, provided any restrictions are disclosed at proposal submission. |
| The PWS requires the system be FedRAMP High and discusses scenarios where the solution is FedRAMP authorized but not VA authorized. Please clarify the expected ATO pathway, who owns which artifacts, and whether VA will accept inheritance from an existing FedRAMP package. | See PWS Section 5.10. |
| Section: PWS FICAM. For PIV/FICAM, please confirm whether VA will provide an identity provider for SAML-based federation, and whether contractors can use assertion-based auth rather than direct PIV auth during early non-prod phases. | The Government cannot provide this information at this time. |
| Section: PWS Remote Access Methods. For remote access, VA indicates AVD/CAG are the only approved methods, with restrictions on copying/printing/saving. Please confirm the expected operating model for contractor support (e.g., can we run admin/ops from our SOC using approved methods) and whether VA will provide test accounts early. | Admin/ops can be accessed by AVD/CAG using approved methods; copying/printing/saving is restricted. |
| Section: PWS US Jurisdiction. The PWS indicates all contractor/subcontractor personnel working with VA information must be located within US jurisdiction “to the maximum extent feasible.” Please confirm whether offshore development is allowed if it is performed against synthetic data only and with no access to VA systems. | See PWS Addendum B and VAAR 852.204‑71(d) |
| Would VA be open to evaluating vendors on demonstrable cycle-time reduction and analyst workload reduction during MVP, in addition to pure detection metrics? | The VTD should focus on showcasing how the solution meets core functional requirements outlined in the PWS and RFI, including data ingestion, rules engine, pattern recognition, and reporting capabilities. Vendors may highlight additional performance benefits such as cycle-time reduction or analyst workload improvements if they believe these demonstrate alignment with VA’s objectives. See RFI “Demonstration Content Requirements” for guidance. |
| Section: PWS Agile Monthly Cadence. Would VA accept a delivery approach that treats the Rules Engine + ML as continuously improving products (e.g., CD4ML / MLOps) with frequent releases, rather than locking down models/rules at initial go-live? | Yes. VA supports continuous improvement. Per PWS Section 5.2.2, Rules/ML must follow sandbox→test→pre‑prod→prod governance with transparency/audit. |
| Where does VA warehouse the community care data? | VA data resides in Authoritative Data Sources (ADS) and VA systems (eligibility, referral, provider, financial). Contractor accesses via VA-approved APIs. See PWS Sections 6.1.9 and 5.2.1. |
| How often does the CMS and VA policies or TPA terms change? | CMS/VA policies update periodically; system must support continuous updates and retroactive reprocessing. Frequency Varies. See PWS Sections 5.2.2 and 5.2.1. |
| Can we do the demo as a standalone product? Does it need to integrate with the existing VA system? | Demo may be standalone; integration with VA systems is not required for VTD. Show core capabilities per PWS; use synthetic data. |
| Will the Government please confirm the following deadlines for submission on RFI #3 are accurate? Intent to participate in demonstration due January 23, 2026? List of demonstration attendees, 2 page technical Functionality description, 2-page RFI response, PowerPoint slides to be used during the presentation due February 6, 2026? | Confirmed. |
| Is the VA open to having a solution deployed within the VA Enterprise Cloud? Or is it required for the solution to be hosted within a vendor cloud that VA staff can be given access to? | VA requires SaaS solution meeting. See PWS Sections 3.0, 5.4, 5.5, 5.10 and 6.1. |
| We acknowledge that the PWS requirement is for a FedRAMP High solution. However, is the VA open to having a solution that would progress from FedRAMP moderate to high during the period of performance? | VA will consider revising or clarifying in the RFP. |
| For the ROM SaaS cost estimate, should pricing be provided as subscription only, or include implementation/professional services, and what pricing units do you prefer (per-user, per-claim, per-million-claims, per-environment)? | Provide SaaS subscription ROM and implementation/pro services ROM. Pricing units at vendor discretion (per‑user/claim/volume/env); include assumptions and PWS mapping. |
| Were the questions from the first RFI (Nov 2025) actually responded to? Or are the questions being rolled into the solutions demo? Was there a lot of interest from the prior RFI? | VA reviewed all responses from previous RFI submissions and made relevant updates to the PWS. |
| Please provide additional details regarding Power Point submission due on February 6, 2026. Assume PP is presentation of Demo artifacts | Refer to the information outlined in Section 5 in Amendment 0001. |
| To what extent will the Pivot tool need to accommodate the full extent of CMS reimbursement policies including various MAC policies and operational guidelines. Also, does VA expect to incorporate Medicare Managed Care Manuals, PDB manuals and other similar Medicare manuals? Also, how shall TPAs pricing and operational policies be accommodated in PIVOT? Also, how does VA anticipated alignment with Tricare payment policies and networks? | See PWS Sections 5.2.2 and 5.2.2.1. |
| How will VA measure and manage provider network abrasion? | The Government cannot provide this information at this time. |
| How does VA anticipate handling post adjudication, post payment improper payments and FWA analysis (claims paid prior to PIVOT PoP)? Will PIVOT also be required to look back and analyze historical payments? If yes, what is the anticipated look back period? | Yes, PIVOT shall support retroactive analysis. Lookback window is VA‑defined and may vary by policy/program. Final determination will be made collaboratively after contract award. See PWS Section 5.2.2. |
| How does VA expect to establish threshold tolerances for provider abrasion? Assuming significant reduction in go forward or claw back of historical improper payments. | Final determination will be made collaboratively after contract award and through Governance process. See PWS Sections 5.2.2 and 5.2.4. |
| What are the current state performance metrics in identification by type and historical collection of identified improper payment by type – FY 24, FY25 | The Government cannot provide this information at this time. |
| Operational efficiency: How is this currently measured? And what are the expectations for improvement? | Efficiency is measured by reduced manual review, expansion of monitoring capabilities, and faster identification of improper payments; VA expects measurable cycle-time reduction and ROI gains as stated in the PWS. |
| Accurate and Timely: What are the FY 25 performance metrics for claims accuracy and days to paid by claim type (professional, non-professional, dental, RX) | The Government cannot provide this information at this time. |
| What are the performance metrics for Improper Payments by the various Acts and programs? | The Government cannot provide this information at this time. |
| Can you please expand on “developing cost containment strategies? Does this include rate setting, provide exclusion, UM? | Example strategies include identifying high dollar payment rates. Vendors should propose their best approach to meet the Government requirements. See PWS Sections 5.2.2 and 5.2.3. |
| Does PIVOT anticipate developing metrics and analysis on quality-of-care delivery? If yes, how does this align with direct care metrics? | The Government cannot provide this information at this time. |
| To provide accurate and comprehensive feedback to this PWS, we respectfully request a review of this document. (executability of document) | VA will provide at the time of award. It is not required for the RFI response or demonstration. See PWS Section 2.1 for applicable document listings. |
| To provide accurate and comprehensive feedback to this PWS, we respectfully request a review of this document. (executability of document) | Clinical determinations and indications can be reviewed at https://www.va.gov/COMMUNITYCARE/providers/info-CDI.asp. |
| To provide accurate and comprehensive feedback to this PWS, we respectfully request a review of this document. (executability of document) | VA will provide at the time of award. It is not required for the RFI response or demonstration. See PWS Section 2.1 for applicable document listings. |
| To provide accurate and comprehensive feedback to this PWS, we respectfully request a review of this document. (executability of document) | VA will provide at the time of award. It is not required for the RFI response or demonstration. See PWS Section 2.1 for applicable document listings. |
| How does PIVOT interface with VA Fraud Special Investigation services? | Any outputs or findings generated within PIVOT may be shared across VA for further review and action as appropriate. |
| How does VA currently define waste and abuse? | VA provides additional details on Waste, and Abuse on its official Community Care website. Please refer to: https://www.va.gov/COMMUNITYCARE/about-us/FWA.asp for more information. |
| How does VA anticipate FEDRAMP compliance of VA specified tuning of Improper Payment and FWA models? Assume the fine tuning of authorized models inside FEDRAMP service will not require a separate FedRAMP submission for each tuned model. | The Government cannot provide this information at this time. |
| “The Contractor shall provide documentation demonstrating compliance with FedRAMP High and VA-specific security directives, at the time of proposal.” – How should this be submitted? (as current submission request is for 2-page technical description, 2-page submission team details, and an unlimited PowerPoint presentation) | Compliance documentation for FedRAMP and VA-specific security directives is required at the time of proposal, not for the RFI or demo submission. |
| To ensure seamless integration, we request a complete list of integrated systems with documented APIs and workflow schemas. | The complete list of integrated systems, including documented APIs, will be provided at the time of award. See PWS Section 5.4. |
| Does post-adjudication imply post-adjudication but pre-payment? We respectively request a data flow schema and required processing cycle times | Post‑adjudicated = after TPA adjudication. PIVOT checks at/near real‑time, passes through without delay. Targets: ≤2s/txn, ingest ≤24h, ~8 txn/sec. Schema would be apart of implementation. See PWS Sections 5.2.1 and 6.4. |
| Define real-time execution? Assume this implies rules-based models not AI/ML analysis? | Real‑time covers rules at ingest and may include near real‑time AI/ML scoring. Both are supported; exact split set during implementation. See PWS Sections 5.2.2 and 5.2.3. |
| Define existing attributes and guidelines for processing FWA events? | VA will consider revising or clarifying in the RFP. See PWS Section 5.2.3. |
| How do data aggregation and normalization interact with new developments in VA provider directories and similar development activities? | PIVOT normalizes provider data per ADS and integrates with VA provider directories. Specific interfaces finalized at award |
| What type of VA staff will confirm findings? Certified coders, VA nurses, VA Physicians, program staff? How will accommodation be made for difference of opinions between VA and contractor regarding model tuning? | The roles listed in the PWS include a variety of professionals and differences will be resolved through the governance process. See PWS Sections 5.8.1, 5.2.3, and 5.2.2. |
| Given the idiosyncrasies and integration points for this mission critical capability, we encourage VA to consider POP of 36 months with two 12-month option periods. | The anticipated PoP is 12 months, with four 12‑month options (for a maximum of 60 months). VA appreciates the recommendation and any decisions regarding period of performance will be reflected, as appropriate, in the final RFP. |
| Please clarify expected number of program related meeting. Please provide specific range to assist in effective pricing. | "The total estimated number of trips in support of the program related meetings for this effort is equal to or greater than 2 trips per calendar year. Anticipated locations include the following, estimated at 2 or more days in duration" Final determination will be made collaboratively after contract award. See PWS Section 4.3. |
| Please provide brief job specifications for VA auditors, analysts? This will assist in developing robust training and various tools for these positions. | Further details will be provided and collaboratively elaborated after contract award and during implementation. |
| Please provide number of claims by medical, dental and Rx. Also please provide average number of claim lines for these four categories. | PWS Section 5.2 sets approximately 82M/yr baseline. Breakdown by 837P/I/D/NCPDP and avg lines will be provided at contract award and during implementation. |
| Is the intent to replace existing VA data ingestion system such as DAS. Also, assume this new data service will be required to integrate with TPAs (post adjudication). What is the intent of processing/storing historical transaction history for resolving duplicates or establishment of System of Record status? | The intent is to Integrate, not replace. PIVOT passes through with flags, keeps audit/history and detects duplicates; SoR remains in VA claims and/or financial systems. |
| Please define “original claim”, as we assume this data is sourced from TPAs and already preprocessed. | VA will consider revising or clarifying in the RFP. |
| Please provide details on VA systems required to integrate post processing. (such as CCRS) | The Government cannot provide this information at this time. |
| Please provide background on VA staff that will specifically oversee and serve as SME for this critical function. | The Government cannot provide this information at this time. |
| What are the current service levels of the existing system data standardization normalization/ingestion? | The Government cannot provide this information at this time. |
| Please provide technical schema of existing system. | The Government cannot provide this information at this time. |
| Based on the PWS, it appears that the VA is looking for pre-adjudication (“real-time”) review of claims, in additional to post-payment payment integrity. Is the VA intending to replace its current claims adjudication system, or is the PIVOT solution intended to work in conjunction with the existing claims adjudication system? | PIVOT is intended to work alongside and in conjunction with existing adjudication/reimbursement systems. It does not replace VA claims adjudication/reimbursement. See PWS Sections 5.2.1 and 5.2.3. |
| Please identify which VA function will provide guidance on modifying normalization/editing rules? | See PWS Section 5.2.2. |
| Based on the requirement of retro-active processing, how far back is the adjustment look back period? Two years or undefined? | Lookback window is VA‑defined and may vary by policy/program. Final determination will be made collaboratively after contract award. See PWS Section 5.2.2. |
| Frequency and cost of inclusion of additional ML/AI patterns and metrics will be to define given the accelerated innovation cycle of new AI techniques (i.e. neuromorphic) | The Government cannot provide an answer to the question as written. |
| Incremental / real-time training of models will likely be quite expensive, from a compute perspective, with minimal-to-no upside, compared with ongoing quality review and retrain as needed. Recommend not requiring real-time retraining of models, best private sector practice for production models is quarterly model retraining. | VA requires continuous improvement, but retraining cadence will be finalized at award. Quarterly retraining aligned with best practice is acceptable if it meets KPIs. See PWS Section 5.2.3. |
| For robust processing, we recommend using industry standard clinical protocols, all payor national data sets to detect community of care standards which aids in establishing under/over utilization of care. Would VA entertain the use of these third-party assets? | Yes, VA will consider third-party assets if compliant with VA policy, privacy, and integrated per PWS. Vendors should propose their best approach to meet the Government requirements. See PWS Section 5.2.3. |
| Please define “recoupment” -does this represent submission to CCRs and subsequent offset by FSC? | Recoupment refers to the recovery of improper payments via VA financial workflows. PIVOT tracks and reports status'/notices issued by VA systems. See PWS Section 5.2.2. |
| Assuming VA signs off on deployment of models/rules, how does this behavior reflect in the numerator of this calculation? | The Government cannot provide an answer to the question as written. |
| Data quality—what is VA’s proposed reconciliation and finalization of the authoritative statement of data error? | Contractor resolves ingest errors and logs remediation; VA confirms authoritative resolution via ADS and governance review. Vendors should propose their best approach to meet the Government requirements. See PWS Section 5.2.1. |
| False Positive – What is the process for defining a “false positive”- provider report, overturn, appeal? | See PWS Sections 5.2.2, 5.2.3, 5.2.4 and Addendum B10. |
| AI/ML accuracy – please expand upon approach (target/labeling, Confusion Matrix, Dollar Weighted, Policy tuning, general accuracy calibration. ) | The Government cannot comment on specific approaches at this time. Vendors should propose their best approach to meet the Government requirements. |
| PWS states PIVOT shall ingest 82M claims annually. What is the current breakdown by claim type (837P, 837I, 837D, NCPDP)? What is the anticipated growth rate over the 5-year PoP? | Breakdown by type and growth projections will be provided at award/implementation. Vendors should design for 82M/yr baseline and scalable growth over PoP. See PWS Section 5.2.1. |
| Data Normalization: Section 5.2.1 requires normalization across multiple adjudication systems and EDI types. How many distinct TPA adjudication platforms are currently in use? What are their specific data format variations that require normalization? | VA will provide the vendor with detailed program specific EDI companion guides upon award. See PWS Section 5.2.1 for additional information related to the types of EDI transactions that PIVOT must support. |
| Section 5.2.2 requires VA approval for all rule changes. What is the anticipated approval workflow timeline? What volume of rule changes does VA expect monthly during steady-state operations? | Timeline and monthly volume will be defined at award/implementation. Contractor shall have a multi-tier agile cadence with governance checkpoints. See PWS Section 5.2.2. |
| Rule Conflict Resolution: PWS mentions 'conflict detection and resolution' between rules. When conflicts occur between VA-specific rules and CMS edits, what is the adjudication hierarchy? Who has final authority to resolve policy conflicts? | "Apply critical rules first based on VA‑defined hierarchies (e.g., VA > CMS > industry)… No rule may be added, changed, or removed without prior VA approval." See PWS Section 5.2.2. |
| PWS lists many PPS systems including ‘PPS exempt providers.' What percentage of VA Community Care volume falls into state-specific or PPS-exempt categories requiring custom pricing logic? | Not specified for RFI. Vendors must support PPS‑exempt facility pricing. Additional details may be provided at award. See PWS Section 5.2.2. |
| PWS requires risk and confidence scores but allows VA to 'configure thresholds.' What is VA's risk tolerance for false positives? Is there a target precision/recall balance (e.g., 95% precision, 85% recall)?" Additionally, can you clarify the AI/ML Accuracy requirements. I see them at 90% (pg 58) and 95% (page 56). | VA will consider revising or clarifying in the RFP. |
| Who is responsible for remediating data quality issues originating in TPA systems or upstream VA systems? | Contractor resolves ingest/normalization errors (≥98% in 3 business days), logs/revalidates, and coordinates with upstream system owners for source defects. See PWS Section 5.2.1. |
| Does PIVOT generate and issue recoupment notices to providers/TPAs, or does it only flag claims for manual recoupment processing by VA staff? | PIVOT flags and tracks recoupments (incl. FMS reconciliation), sending denial metadata downstream. Formal notices are issued via VA financial/TPA processes. See PWS Sections 5.2.2 and 5.2.4. |
| Cost Savings Definition for ≥3:1 ROI: How should “cost savings” be calculated for the ≥3:1 ROI requirement? Does this include: (a) Only actual recoupments collected? (b) Cost avoidance from future improper payments prevented? (c) Administrative cost reductions from automation? Our current system will result in all the above. | ROI may include actual recoupments, cost avoidance, and efficiency gains from automation. See PWS Sections 5.2.5 and 6.4. |
| Is PIVOT the authoritative system of record for payment integrity findings, recoupment tracking, and appeals, or does another VA system (e.g., VistA, CPRS, Financial Management System) serve as system of record with PIVOT as a decisioning/flagging tool only? | PIVOT is an oversight tool. Financial SoR remains with VA financial/claims systems. PIVOT tracks findings/recoupments with full audit trails. |
| What is considered timely response: “The Contractor shall ensure that the system is designed and configured for high throughput performance, capable of processing all incoming claims and invoices at, or near real time without introducing delays that impact downstream payment workflows.” | At or near real‑time ingest and routing; target approximately 8 transactions/sec. no holding that delays payment flow or causes delays. Peak windows and streaming/batch specifics will be defined at award. See PWS Section 5.2.1. |
| If files are submitted in batch, what is considered appropriate turnaround time? | Batch data ingest, latency is ≤24h ingest and prompt forwarding at or near real‑time to downstream systems to avoid backlogs or delays in processing. See PWS Sections 6.4 & 5.2.1. |
| Does PIVOT need to monitor the recovery process for Pay and Chase claims? | Yes. PIVOT must track and report recoupments, and present progress/status via dashboards/reports. |
| The current requirement states that the PIVOT solution must be FedRAMP authorized. However, our market research indicates that there are currently no full scope fraud detection or improper payment platforms that are within FedRAMP authorization in the marketplace. The FedRAMP marketplace primarily contains base infrastructure platforms (e.g., case management systems, cloud services) rather than specialized fraud analytics solutions. Additionally, any solution will need to update security artifacts to meet VA's specific integration and data handling requirements. Typically any proposed fraud, waste, abuse solution is built off a FEDRAMP infrastructure base platform to accelerate post award authorization. Would VA consider accepting solutions that are hosted on FedRAMP High authorized infrastructure (e.g., AWS, Azure Government) and commit to achieving FedRAMP authorization during the performance period, rather than requiring FedRAMP authorization prior to award? | VA will consider revising or clarifying in the RFP. |
| Section 5.10.1 states 'The Contractor shall provide confirmation of their FedRAMP System Security Plan (SSP)...within 5 calendar days of contract award.' If the contractor is pursuing FedRAMP authorization as part of contract performance, what documentation would VA accept in lieu of a completed FedRAMP-authorized SSP at the 5-day mark? | VA will consider revising or clarifying in the RFP. |
| Would VA consider a phased approach where the contractor operates in non-production test environment with synthetic data during FedRAMP authorization process, then transitions to production with live VA data upon receiving FedRAMP High and VA ATO? | VA may allow non-production synthetic data until FedRAMP High and VA ATO achieved. |
| Can VA clarify the distinction between the MVP requirements (Section 5.5) and a Proof of Concept? Specifically, does VA expect the MVP to be a fully production-ready system capable of processing live VA claims at full scale (82M annually), or a demonstration environment showing core capabilities? | The MVP, as defined in PWS, is not a proof of concept. VA expects a production-ready solution capable of operating within VA’s claims workflow and meeting core functional requirements. While full-scale processing of 82M claims is not required at MVP, the system must demonstrate scalability, reliability, and readiness for integration into full production. |
| Section 5.5 outlines MVP requirements including 'fully operational rules engine' and 'operational dashboards usable by VA payment integrity staff on day one.' Can VA clarify the expected timeline from contract award to MVP delivery and production go-live? | Additional information related to timeline for production go live with be clarified in the RFP. |
| The MVP requirements appear to describe a production-ready system rather than an MVP. Can VA confirm whether the MVP must be capable of processing live VA production claims at full scale (82M claims annually), or if the MVP can be scoped for a subset of claims/programs with full-scale deployment in later phases? | The MVP, as defined in the PWS, is not a proof of concept. VA expects a production-ready solution capable of operating within VA’s claims workflow and meeting core functional requirements. While full-scale processing of 82M claims is not required at MVP, the system must demonstrate scalability, reliability, and readiness for integration into full production. |
| Section 5.5 states the MVP must include 'a comprehensive set of active rules...sufficient to demonstrate full payment integrity functionality' including CMS NCCI, MUE, MPPR edits; Fee Schedule and Pricing Validation; Duplicate Claim Detection; Referral/Authorization Mismatch Validation. Can VA provide guidance on the minimum number of rules and rule types expected in the MVP rules library at go-live? | For the MVP, the rules library must include all listed rule types (CMS NCCI, MUE, MPPR, Fee Schedule, Duplicate Detection, Referral/Authorization). No minimum count, but coverage must demonstrate full payment integrity per PWS. |
| For MVP development and testing, will VA provide: (a) Historical claims data for testing and validation, (b) Test environments for downstream system integration, (c) Access to VA eligibility, referral/authorization, and provider systems for integration testing? If not, should contractors plan to use synthetic/de-identified data and mock integration points during MVP development? | Currently, VA has no plans to provide historical claims data or direct system access for MVP development. Per the PWS, the vendor shall use synthetic/de-identified data and mock integration points. |
| Does VA expect the MVP to process and analyze historical claims data retroactively (e.g., claims from prior years), or should the MVP only process prospective claims from the go-live date forward? | MVP focuses on prospective claims; retroactive analysis may be phased in per VA direction. |
| Section 5.2.2.1 states 'VA shall have unlimited rights to access, review, store, reuse, replicate, and modify all rule logic and calculations.' Can VA clarify the scope of 'unlimited rights' as it applies to: (a) Pre-existing proprietary AI/ML algorithms and methodologies, (b) Existing technology configured for VA but not developed specifically for VA, (c) New rules and VA-specific customizations developed under this contract? | Unlimited rights apply to VA-specific rules, logic, and outputs; not vendor’s pre-existing proprietary algorithms. |
As indicated in PWS Section 5.2.2.1, the vendor shall disclose any proprietary restrictions at proposal submission.
Please confirm that a vendor's existing engine and rules framework is not subject to unlimited data rights and are limited to only specific rules and configurations that are customized for VA. Yes, VA rights apply to VA-specific configurations and outputs, not vendor’s underlying platform.
As indicated in PWS Section 5.2.2.1, the vendor shall disclose any proprietary restrictions at proposal submission.
| Section 5.9.1 states 'All data processed, stored, transmitted, or generated by the Contractor...including business rules, pricing logic, machine learning models...shall be the sole property of VA.' For a SaaS/hosted model where vendors provide a commercial platform service to VA, would VA accept a licensing approach where VA has unlimited rights to USE the system and VA-specific configurations, but the vendor retains ownership of the underlying platform technology? | As indicated in PWS Section 5.2.2.1, the vendor shall disclose any proprietary restrictions at proposal submission. |
| Section 5.2.2.1 requires delivery of 'detailed specifications, calculations for Contractor-derived and VA-specific custom business logic.' Must vendors disclose their underlying proprietary algorithmic methodologies and training techniques, or only the specific implementations and outputs generated for VA? | As indicated in PWS Section 5.2.2.1, the vendor shall disclose any proprietary restrictions at proposal submission. |
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 .