DHHS - RFP 260000002210 - Bidder Questions - Version 2.xlsx
XLSX spreadsheet 33 KB Posted
- Solicitation number
- RFP 171 260000002210 3
- Issued by
- Michigan
About this file
This document is a bidder questions and answers response file for the Michigan Department of Health and Human Services (DHHS) Request for Proposal (RFP) 260000002210 for a Client Consent Income Verification Service. The RFP seeks a contractor to provide a 24/7 secure, automated web-based portal enabling clients to access real-time or near real-time income and employment verification services compatible with the State's technology environment. The service must integrate with MI Bridges, Bridges, and MiLogin systems to retrieve payroll and employment data from authoritative sources including payroll systems, payroll processors, employer APIs, and unemployment/disability benefits data. The contract term consists of three base years plus three one-year renewal options, totaling six years. The State anticipates verification volumes based on current use of similar non-consent-based services, with transaction volume details referenced in Schedule A, Section 11. The solution must support both nightly API processes and real-time on-demand lookups, with a two-second response time requirement for system responses. Integration will be performed by the State or State-designated integrator using the contractor's API documentation, sandbox/test environment, and technical support, with the contractor required to collaborate on technical working sessions, testing, defect triage, and production cutover.
The State prefers flat fixed-rate pricing with potential volume-based tiered discounts but remains open to alternative transactional or tiered pricing models, requesting pricing per 100,000 individuals for non-license-based models. Bidders may propose commercially reasonable exceptions to the Service Level Agreement terms, though such proposals are not preferential to the State's standard terms. The State does not expect the contractor to retain verification reports for the full contract term; instead, shorter-term retention in the contractor's portal will support tracking and troubleshooting with longer-term retention occurring within the State's Electronic Case File. The contractor must support SAML 2.0, OpenID Connect federated identity protocols, and MiLogin integration. Support services require a toll-free number available Monday through Friday, 8:00 a.m. to 8:00 p.m. EST, with emergency contacts available outside scheduled hours, and tiered service level agreements governing resolution times based on error criticality. A 20 percent Goods and Services Locally Disadvantaged Business Enterprise subcontracting requirement applies, measured by contract dollar value. The State requires the selected contractor to provide the client-facing consent workflow for initial requests with subsequent requests processed under the same consent.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| DHHS - RFP 260000002210 - Bidder Questions - Version 1.xlsx | XLSX spreadsheet | |
| DHHS - RFP 260000002210 - Client Consent Income Verification Service Version 2.0.docx | DOCX document | |
| DHHS - RFP 260000002210 - Client Consent Income Verification Service.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
SOM Responses (V1)
| Q # | Document and Section | Page # | Bidder Question | SOM Response | Answers in GRAY were already answered in Version 1 of this document. |
| 1 | Schedule A, Section 11 - Integration; Section 7 - Access Control and Authentication | 80-86 | Please confirm whether integration into Bridges, MI Bridges, and MiLogin may be performed by the State or a State-designated integrator using the Contractor’s API documentation, sandbox/test environment, and technical support. | Integration will be performed by the State or State-designated person using the documents and support. | |
| 2 | Schedule A, Sections 22 and 24 - Meetings / Project Management | 93-95 | If the State or a State-designated integrator performs the State-system integration, please clarify the Contractor’s expected role in technical working sessions, testing support, defect triage, and production cutover. | Contractor must collaborate with and provide support services for successful completion of technical working sessions, testing support, defect triage, and production cutover. | |
| 3 | Summary of Objectives - Client Consent; Schedule A Attachment 1 - Client Consent | 2, 100 | Please clarify whether client consent must be captured in the Contractor solution, in MI Bridges, or through a jointly integrated workflow. | The consent must be captured either a jointly integrated workflow or via the contractor solution. | |
| 4 | Schedule A Attachment 1 - Client Consent; Schedule A, Section 3.1 - Nightly API Process | 76, 100 | Please clarify whether consent retention, revocation or opt-out, consent audit fields, and recurring/nightly verification consent requirements are fixed requirements or may be addressed through the Contractor’s standard consent management process and mutually agreed implementation approach. | Consent retention details will be dependant and finalized with Legal guidance based on the selected service. | |
| 5 | Schedule D - Service Level Agreement; Proposal Instructions - Evaluation Process | 8-9, 119-124 | Please confirm whether bidders may propose commercially reasonable exceptions or alternative terms to Schedule D - Service Level Agreement in accordance with the Proposal Instructions, and how such exceptions will be considered during evaluation or negotiation. | While it is permissable to propose exceptions or redline the State's terms & conditions, it is not preferrential. | |
| 6 | Summary of Objectives - Historical Data Access; Schedule A Attachment 1 - Historical Data Access | 3, 102 | Please confirm whether the 72-month historical data requirement applies only where such data is available from authoritative sources, or whether the State requires detailed pay-period records for the full 72-month period for every income source. | The State does not require retention of detailed pay-period records for the full 72 month period. | |
| 7 | Schedule A, Section 3.1 - Scope; Schedule A Attachment 1 - Comprehensive Income and Employment Verification | 76, 102 | For 1099, gig, self-employment, or other income where direct payroll data is unavailable, will the State accept alternate verification pathways such as consumer-permissioned verification, document verification, tax verification, or research verification? Please also clarify which outputs must be adverse-actionable versus informational or investigative only. | Not at this time. | |
| 8 | Schedule A Attachment 1 - Verification Report | 103 | For verification reports, are all listed report fields, including net income, hours, and deductions, mandatory for every income source, or may unavailable fields be marked as not available when not provided by the authoritative source? | Unavailable fields may be marked as not available when not provided by the authoritative source. | |
| 9 | Schedule A, Sections 8 and 23 - Data Retention / Reports | 81, 94 | Please clarify whether the State expects the Contractor-hosted portal to retain verification reports and related data for the full contract term, or whether the State may satisfy retention requirements by downloading/exporting reports into State systems. | The State does not expect the contractor to retain verification reports for the full contract term. A short term will be identified to ensure tracking and troubleshooting with longer term retention occurring within the State owned Electronic Case File. | |
| 10 | Schedule A, Background and Scope; Schedule A Attachment 1 - Comprehensive Income Verification | 75-76, 102 | Because this solicitation supports multiple benefit programs, please clarify whether the State will accept different report or data-source configurations by program type when certain data sources are restricted to specific program use cases. | The State requires a consistent report format regardless of program. | |
| 11 | Schedule A, Section 3.1 - Nightly API Process; Schedule B - Pricing | 76, 105-107 | For high-volume or recurring eligibility processes, will the State accept secure batch or SFTP output where appropriate, or must all nightly verification requests and outputs be exchanged through real-time APIs? | Real-time API's | |
| 12 | Business Specifications - Identity Matching Requirements | 3, 102 | In addition to SSN, please confirm whether the State can provide full name and full address as inquiry inputs for matching, or identify any alternate lawful identifiers the State expects bidders to support when SSN, full name, or address is unavailable. | The State can provide the additional detail for matching when made available from the resident. | |
| 13 | Schedule A, Section 3.1 - Fraud or Overpayment Language | 76 | Please clarify whether fraud and overpayment language requires fraud indicators, document fraud screening, or program integrity analytics, or whether it is intended as a business outcome of improved income verification. | it is intended as a business outcome of improved income verification. | |
| 14 | Schedule A, Section 9 - IT Environment; Schedule E - Data Security Requirements | 82, 124-126 | Does the State require a specific government cloud, such as Azure Government or AWS GovCloud, or may the Contractor use any U.S.-based cloud/hosting environment that meets Schedule E requirements? | State hosted cloud environments (Azure, AWS, Google) or State internal on prem | |
| 15 | Schedule E - Data Security Requirements | 124-126 | Will the State accept SOC 2 Type II reporting with NIST 800-53 control mapping in lieu of FedRAMP authorization where FedRAMP is not applicable to the proposed SaaS service? | Yes. | |
| 16 | Proposal Instructions, Evaluation Process - Proof of Concept / Oral Presentation | 8-9 | If the State elects to conduct an oral presentation, demonstration, or proof-of-concept meeting, please confirm whether bidders will be expected to process live State/client data, State-provided test data, or vendor-provided/sample data. | The vendor will be requested to include vendor-provided/sample data in all demos. | |
| 17 | Proposal Instructions / Contract Award; Software Terms and Conditions | 5-9, 68 | Please confirm whether the State intends to award a new standalone contract from this RFP, or whether an existing State of Michigan/DTMB contract may be used if it already covers the proposed services. | The state intends to award a new, standalone contract for this service. | |
| 18 | Software Terms and Conditions - Subcontractors; Schedule A, Disclosure of Subcontractors | 34-35, 90-91 | May a bidder propose a subcontractor or verification-data provider for the income and employment verification component while a prime contractor manages State integration, implementation, and contract administration? | The State is requesting a service not project management. | |
| 19 | Proposal Instructions | Page 1 | Does the state define a client consent income verification service as a service that also requires employer consent for access to payroll records? | It is expected the selected vendor will be the responsible party to navigate employer terms of use. | |
| 20 | Proposal Instructions | Page 1 | Client consent covers the client, however, employers (companies, payroll providers, federal agencies and state agencies) typically have HR system Terms of Use prohibiting the sharing of credentials with third parties. |
| Which state or federal policies will be leveraged to override the terms of use policies protecting the client and HR systems hosting the client data? | It is expected the selected vendor will be the responsible party to navigate employer terms of use. | ||||
| 21 | Proposal Instructions | Page 1 | How has the state addressed client and employer privacy concerns associated with a client consented solution without abiding by the employer’s terms of use policies? | It is expected the selected vendor will be the responsible party to navigate employer terms of use. | |
| 22 | Objective #1 | Page 2 | How does the State define compatible in the following: |
| “Provide 24/7 availability of a secure, automated web-based portal where clients can access an Income and Employment Verification Service that retrieves real-time or near real-time payroll and employment data compatible with the State’s technology environment and policies.” | Compatiable means - ensuring that MI Bridges / Bridges can ingest the data that is provided by the selected bidder. | ||||
| 23 | Objective #2 | Page 2 | In the Direct Employer Data Retrieval objective, does “authoritative” require employer approved (consented) access to data sources? | It is expected the selected vendor will be the responsible party to navigate employer terms of use. | |
| 24 | Objective #2 | Page 2 | How will the State require verification of employer consent to direct employer data retrieval? | It is expected the selected vendor will be the responsible party to navigate employer terms of use. | |
| 25 | Objective #4 | Page 2 | Does the State’s definition of response time require confirmation of returned or un-returnable income data? | Yes. | |
| 26 | RFP Schedule B | Page 95 | The RFP Schedule B seeks pricing for a “Software as a Subscription (SaaS) License Model Fee.” and requests the annual cost to include a term-based license, to cover the estimated number and type of users identified. However, if a Bidder offers alternative licensing and pricing models it may separately provide that option under Schedule B as well. |
Can the State please clarify whether a Bidder who does not offer ‘software’ in the traditional sense, nor sell services on a ‘license’ basis, but can otherwise fulfill the requirements of the RFP is permitted to respond and submit its alternative pricing models accordingly? If so, what is the estimated number of individuals submitted for verification a bidder may expect? The State is open to other pricing models other than "license" pricing models.
For tiered pricing, please provide pricing per 100,000 individuals.
| 27 | RFP #3.1 A; RFP Schedules A and B | Pg. 69; 72-73; and 95 | The RFP States: The State defines a single verification or transaction result as the complete set of available income records for each client. Schedule A Section 6 outlines user capacity and user type but does not discuss anticipated transaction volumes nor an estimated number of individuals submitted for verification. Schedule B refers to licensing fees and alternative pricing options but refers to anticipated volumes back to the SOW (Schedule A). | Please see Section 11 - Integrations (page 78) for the transaction volumes. |
| 28 | Can the state please clarify whether, for a bidder who offers a non-license based alternative pricing model, the definition of ‘verification’ and ‘transaction’ may be modified to account for the number of income records returned for an individual client (i.e. applicant) on a given search. For example, in a search that has returnable records, each record returned for an individual client submitted would be a separate ‘transaction’; a ‘verification’ would be the one report returning all available transactions for that individual client; and then there would be no separate charge for number of licenses/user accounts. | DHHS accepts those definitions. | ||
| 29 | RFP #3.1 A; RFP Schedules A and B | Pg. 69; 72-73; and 95 | The RFP States: The State defines a single verification or transaction result as the complete set of available income records for each client. Schedule A Section 6 outlines user capacity and user type but does not discuss anticipated transaction volumes nor an estimated number of individuals submitted for verification. Schedule B refers to licensing fees and alternative pricing options but refers to anticipated volumes back to the SOW (Schedule A). |
| Alternatively, if these two definitions cannot be revised overall, can a distinction between what is a ‘verification’ and what is a ‘transaction’ be provided? | Definitions in #28 are acceptable. | |||
| 30 | RFP #3.1 A; RFP Schedules A and B | Pg. 69; 72-73; and 95 | The RFP States: The State defines a single verification or transaction result as the complete set of available income records for each client. Schedule A Section 6 outlines user capacity and user type but does not discuss anticipated transaction volumes nor an estimated number of individuals submitted for verification. Schedule B refers to licensing fees and alternative pricing options but refers to anticipated volumes back to the SOW (Schedule A). |
| If modifications or distinctions are possible, and using the above examples, would the State seek pricing on a per transaction basis or per verification basis? | We are not seeking pricing based on that model but are open to it if proposed. | |||
| 31 | RFP #3.1 A | Pg. 69 | The RFP States: The State defines a single verification or transaction result as the complete set of available income records for each client. |
| Can the State please clarify what it means by defining a single verification/transaction as the “complete set of available income records for each client.”? For example, does this simply mean the available records for each client submitted for a search within the established search parameters; or is this intended to reflect a ‘purchase all’ requirement to capture any and all records that may be available for each client submitted, regardless of recency or other search parameters? | It is intended to reflect a ‘purchase all’ requirement to capture any and all records that may be available for each client submitted, regardless of recency or other search parameters | ||||
| 32 | RFP #3.1C | Page 69 | Does real time pertain to speed of returned results (confirmed delivery of employment & income records or confirmed non-existence of employment & income records)? | Yes. | |
| 33 | Schedule B - Pricing | Page 95 | What is the state’s preferred pricing model? Is any particular model required as part of a bid? | Preferred flat fixed rate, and with potential discounts for higher volumns (tier based) | |
| 34 | Schedule B - Pricing | Page 95 | How is cost evaluation performed among bids that include vastly different technical capabilities? Ie are capabilities weighted in the cost scoring? | The State of Michigan awards contracts to the bidder who provides the solution with the best value to the State. Pricing is one variable considered for which Bidder/System provides the best value to the State, and the capabilities of the system are taken into consideration while pricing is evaluated. | |
| 35 | Schedule B + Table A –Software as a Subscription (SaaS) License Model Fee | Page 95 | What are the state’s expectations for minimum returned rates (defined as: inquiry made by state divided by data returned) as it pertains to pricing? | Off the cuff; 30% of requested fields? | |
| 36 | Schedule A – Statement of Work, §11 Integration | 81-82 | Section 11 “Integration” in Schedule A – Statement of Work references integration with the MI Bridges portal and backend Eligibility System. Can the State clarify which party (State, incumbent systems integrator, or Offeror) will be responsible for building and testing the API/ESB connections between the awarded income verification solution and MI Bridges/Bridges, and what level of support from the current Bridges maintenance and operations contractor Offerors should assume during implementation? | SOM will be consuming the prospective Bidder's API. SOM team will lead Bidder's team in facilitating integrations with Bridges. | |
| 37 | Schedule A – Statement of Work, §3.1(B) | 72 | Section 3.1(B) lists payroll systems, payroll processors, employer APIs, unemployment/disability benefits data, and tax records as required data sources. Does the Contractor need to directly integrate unemployment/disability and tax record sources, or is that data expected to come from elsewhere in the State's system, with the Contractor's scope limited to payroll-sourced income verification? | The with the Contractor's scope will be limited to payroll-sourced income verification for this Statement of Work. | |
| 38 | Schedule A – Statement of Work, §3.1(A) | 72 | Section 3.1(A) requires a single comprehensive verification result usable across multiple programs (SNAP, TANF, Medicaid, etc.). Does the State expect one API response format serving all programs simultaneously, or are program-specific requests with tailored data elements acceptable? | SOM is expecting a singular returned set of data, regardless of what program we're sending the request for. | |
| 39 | Schedule A – Statement of Work, §3.1(C) | 72 | Section 3.1(C) requires verification requests to be generated and returned via a nightly API process. Is this the exclusive mechanism for generating and returning verification requests, or can real-time/on-demand lookups supplement it for caseworker and/or client-initiated ad hoc inquiries? | The Scope descibes both use-cases. 3.1(c) summarizes information regarding the real-time requests and the API requests. | |
| 40 | Schedule A – Attachment 1 – Business Specification Worksheet, Item 11.0 | 97-98 | Business Specification item 11.0 lists employer Tax ID and employer phone/fax number as required verification report fields. Are these required only when available from the underlying data source, or must they be populated for every verification regardless of source availability? | This is required when available. | |
| 41 | Schedule A – Statement of Work, Disclosure of GDBE | 86-87 | Regarding the GDBE subcontracting requirement: is the 20% threshold measured by contract dollar value, deliverable count, or scope of work? | This is based off the contract dollar value. | |
| 42 | Schedule A – Statement of Work (Term); Schedule B – Pricing, §7 Additional Pricing Terms | 72; 99-101 | Schedule A states the contract term as 3 Base Years with 3, 1-Year Options (6 years total), and the pricing table (Schedule B) has 6 rows matching that term. However, Schedule B's Additional Pricing Terms section references a fee increase cap “for any years 6–10,” implying a 10-year term. Can the State please confirm which governs: a 6-year total term, or a longer term with additional option years not otherwise described? | The reference/implecation of a 10-year term was a typo, and the State confirms a 6 year (3 base + 3 1-year options) contract term. | |
| 43 | Schedule A – Statement of Work, §3.1(A) | 72 | Section 3.1(A) states that the system must generate “one comprehensive verification or transaction result per client that can be utilized across multiple programs.” Please clarify the intended scope of “multiple programs”: is this limited to programs administered within MDHHS (SNAP, Medicaid, TANF, CDC, etc.), or does it extend to programs administered by outside agencies that may rely on MI Bridges data, such as WIC? | This is limited to programs administrered within MDHHS. | |
| 44 | Schedule E – Data Security Requirements, §5.11; Business Specification Worksheet, Item 3 | 76 | Schedule E, Section 5.11 requires SSO support via SAML, OIDC, or a comparable State-approved mechanism, but does not specify a required SAML version. Please confirm whether SAML 2.0 specifically is required. | Confirming that it is SAML 2.0. | |
| 45 | Schedule A – Statement of Work, §7 Access Control and Authentication | 85–86 | Section 11 (Integration) lists “Bridges” (Item 11a) and “MI Bridges” (Item 11b) as separate current technologies requiring separate integration responses. Please clarify whether these refer to the same system, or whether they are architecturally distinct systems requiring separate integration approaches. | They are architecturally distinct systems requiring separate integration approaches. | |
| 46 | Schedule A – Statement of Work, §21 State Resources | 87-88 | Section 21 (State Resources) identifies State Contract Administrator and Program Manager roles but does not identify a technical resource or system integrator responsible for architecture/integration mapping with Bridges/MI Bridges. Please clarify whether the State's existing system integrator will support technical architecture mapping during implementation, or whether the Contractor is expected to independently perform this mapping. | Selected contractor will work in collaboration with EPMO Integration Manager. | |
| 47 | Schedule A – Attachment 1 – Business Specification Worksheet, Item 5.0 | 95-96 | Requirement 5.0 of Schedule A – Attachment 1 – Business Specification Worksheet details minimum user session inactivity timeout requirements. Can the State confirm whether “user” refers to public citizens or State MDHHS employees? | In this instance user refers to public citizens. | |
| 48 | Schedule B – Pricing, §4 Implementation Fees | 99-101 | Schedule B (Pricing) allows for costs related to configuration and customization. If certain configurations are not cost-effective or otherwise practical, can the State decide to exclude these additional services and fees? If so, will that be decided prior to contract award? | Yes - the State can decide to exclude the additional services and fees. |
Yes - that would be decided prior to contract award, during negotations. Please ensure any optional services and fees are clearly identified, for evaluation purposes. "
| 49 | Schedule A – Statement of Work, §11 Integration | 81-82 | Has the State decided how the Client Consent Income Verification solution will integrate with MI Bridges and the broader eligibility workflow — either as an embedded solution within a State-owned application, or via an email/SMS sent by the Contractor to the client? | The State is asking for the availability of both options outlined here. |
| 50 | Schedule A – Statement of Work, §23 Project Control & Reports | 90 | Schedule A – Statement of Work, Section 23 (Project Control & Reports), Report Format and Delivery Requirements: what are the current State-approved secure, encrypted platforms (e.g., SharePoint, Box, Google Drive, etc.)? | SharePoint, Jira, ADO |
| 51 | Schedule C – Insurance Requirements, Limits of Coverage & Specific Endorsements | 102-105 | Schedule C – Insurance Requirements, Limits of Coverage & Specific Endorsements: the Privacy and Security Liability (Cyber Liability) insurance requirement lists $5,000,000 Employee Theft Per Loss. Is that limit intended for the Crime (Fidelity) insurance section? If so, what is the required minimum limit for Privacy and Security Liability (Cyber Liability) insurance? | The reference to Employee Theft Per Loss was in error for the Cyber Liability section. It should read Per Occurrence/Aggregate at the same dollar value. This has been corrected in the attached version 2.0 of the RFP (among a couple other changes). |
| 52 | Schedule A – Attachment 1 – Business Specification Worksheet - Item 12.0 | 98 | The RFP requires a tool-free number with access 8:00 a.m. – 8:00 p.m. EST (excluding federal holidays). Does this apply Monday-Friday only or seven days per week? | M-F; with emergency contacts available outside of scheduled hours. |
| 53 | Schedule A – Attachment 1 – Business Specification Worksheet - Item 12.0 | 98 | The RFP requirement states that support issues must be resolved within 60 minutes but also states that if resolution exceeds 8 hours, an estimated completion time must be provided. Can the State clarify how these frames apply to one another? For example, if a support issue must be resolved in 60 minutes, how would it then be unresolved after 8 hours? | If resolution is not resolved within 60 minutes and it is estimated that it will take longer than 8 hours to resolve, the selected contractor must provide a estimation for when it will be resolved. |
| 54 | Schedule A – Attachment 1 – Business Specification Worksheet - Item 12.0 | 98 | Can the State clarify how “resolution of support issues” is defined? | Please see Definitions section of Schedule D for more information on this definition. |
| 55 | Schedule B - Pricing | 2 | Section 2. Support Service Fees states, “Bidder must provide a breakdown of how Support Fees were calculated.” However there is no section in the associated table to provide a description of the breakdown. How should this information be documented in the Pricing template? | Bidders should add any required tables or charts, or modify the existing table to document and show a breakdown of how those fees are calculated. |
It is okay to modify Schedule B as needed to clearly document your pricing.
| 56 | Software Terms and Conditions | ||
| Section 45. Extended Purchasing Program Fees and Reporting | 60 | Will contractors have the ability to negotiate separate pricing based on MiDEAL specific volume projections if MiDeal organizations take advantage of the extended purchasing program? | No, you are not able to negotiate separate pricing for MiDEAL members. The pricing listed in the contract is the pricing that will be extended . Please ensure whatever pricing model you use for your bid would be able to be able to be appropriately extended to those potential customers, if applicable. |
| 57 | Schedule A-Statement of Work | ||
| Section 3.1 Scope | 72 | The state requires the following: “Income and Employment Verification Service requests will be generated through a nightly API process, and corresponding verification reports must be returned in same manner.” |
| Can the state define what will be provided to vendor in order to complete the nightly API process and return the desired verification reports? | The same detail and data that is provided in the on-demand API will be used as needed for the nightly API process. | |
| 58 | Schedule A-Statement of Work | |
| Section 7. Access Control and Authentication | 76 | In regards to OIDC/SAML integration, the state is requiring the following: “To support federation with the SOM MILogin solution, the Contractor’s solution must support SAML, OpenID Connect (ODIC) federated identity protocols.” |
| Does the state use a COTS ICAM solution today, and if so who is the provider? | MiLogin is the State's enterprise ICAM platform used by citizens, businesses, employees, and contractors for single sign-on (SSO), authentication, and multi-factor authentication (MFA). | ||
| 59 | Schedule A - Statement of Work | ||
| Section 11. Integration | 81 | Can you provide details regarding how verification volume projections were calculated? | Verification volumes were projected based on current use of similar non-consent based services. |
| 60 | Schedule A - Statement of Work | ||
| Section 11. Integration | 81 | Were potential fluctuations based on future state and federal policy requirements considered in volume projections? | To the extent possible. |
| 61 | Schedule A-Statement of Work | ||
| Section 11. Integration | 81 | Does the state foresee other implementation options beyond system integration? | Yes, including the possibility of text/email links. |
| 62 | Schedule A-Statement of Work | ||
| Section 14. Training Services | 82 | Can you please clarify the expected scale and cadence of the training scope? Specifically, what is the estimated number of personnel to be trained, what is the preferred mix of on-site vs. virtual delivery, and will there be a requirement for recurring annual refresher training post-go-live? | Initial training of a small # of subject matter experts < 20. Virtual delivery is preferred with no annual training required. |
| 63 | Schedule A-Statement of Work, Attachment 1 Business Specification Worksheet - Section 12.0 |
& Schedule D - Service Level Agreement - Section 3.5 97 and 110-112 Schedule D (Section 3.5) lists a tiered SLA response matrix allowing up to 4 hours to resolve Critical errors, 2 business days for High errors, and 10 business days for Medium errors, which differs from 60 minute response time stated earlier in RFP.
| Does the State intend for all technical support issues to be resolved within 60 minutes, or will the tiered Response and Resolution Time Service Table in Schedule D govern the contract? | In the case of inconsitencies between Bu, Schedule D would govern the contract. Version 2.0 of the RFP that has been uploaded to SIGMA has removed the conflicting language. | ||
| 64 | Schedule B - Pricing | ||
| Section 1. Licensing and Usage Fee | 98 | Will the State allow transactional/tiered volume pricing in Table A, or is the State strictly seeking a flat annual enterprise license regardless of transaction volume? | The State will allow transactional / tiered pricing. |
| 65 | Software Terms and Conditions | ||
| Section 24. Artificial Intelligence (24.1 Model Cards; 24.2 Third-Party Artificial Intelligence Models) | 53 | For third-party foundation models accessed as a managed cloud service (e.g., a hosted LLM), the provider does not disclose architecture, training methodology, or training data to integrators. |
| Will the State accept the provider's published model documentation to satisfy 24.1(a)(i) and (iii), plus the Contractor's own intended-use, evaluation metrics, and benchmarks for (ii) and (iv)? | The State has no concerns with this. | ||||
| 66 | Cover Page/Summary of Objectives | 1, 2 | Can the State clarify whether this solution may also be used to support future Medicaid Community Engagement / Work Requirements verification, reporting, or compliance workflows? | Yes; those are good examples of potential future enhancements for additional verification sources. | |
| 67 | Summary of Objectives: Direct Employer Data Retrieval | 2 | Can the State clarify whether consent-based bank income data may be used as a supplemental source when direct payroll/employer data is unavailable? | The State is not interested in integration with bank data at this time. | |
| 68 | Summary of Objectives:Comprehensive Income and Employment Verification | 3 | For 1099, self-employment, and gig income, what data sources will the State consider acceptable for verification? | The State is only interested in employer or payment data directly from gig sources at this time. | |
| 69 | Summary of Objectives: Client Consent Requirements | 2 | Does the State expect the selected contractor to provide the client-facing consent workflow, or will consent be captured through MI Bridges and passed to the contractor? | The selected contractor is to provide the client-facing consent workflow for intial request; subsequesnt requests processed under same consent. | |
| 70 | Summary of Objectives: Performance Requirements | 2 | Does the two-second response time requirement apply to all verification requests, including third-party payroll/source lookups, or only to the contractor’s system/API response once data is available? | The intent of two-second response time requirement is for the solution response to request; not necessarily to fulfil request. | |
| 71 | Schedule A – Attachment 1, Business Specification Worksheet, 1.0 Client Consent | 111 | Can the State clarify the required duration and renewal rules for client consent, including whether consent must be renewed for each verification request, may cover multiple programs or repeated verifications, and how long consent records must remain valid and retained for audit purposes? | Multiple options are being considered. It is expected the selected vendor could support a range of durations. | |
| 72 | Schedule A – Purpose/Challenge Statement | 84 | Can the State clarify whether bidders may propose optional future-state capabilities, such as configurable eligibility workflows, caseworker dashboards, audit reporting, alerts, or expanded verification modules, as part of the Solution’s extensibility roadmap? | The State preferes to limit the scope to the published need at this time. | |
| 73 | Schedule A – Purpose/Challenge Statement | 84 | Can the State clarify whether future enhancements may include additional verification domains beyond income and employment, such as identity, household composition, assets, or other eligibility-related data sources? | Yes; those are good examples of potential future enhancements for additional verification sources. |
File details come from the government source that posted it. Updated .