DHHS - RFP 260000002210 - Bidder Questions - Version 1.xlsx
XLSX spreadsheet 32 KB Posted
- Solicitation number
- RFP 171 260000002210 2
- Issued by
- Michigan
About this file
This document comprises bidder questions and state responses for the Michigan Department of Health and Human Services (DHHS) Request for Proposal (RFP) 260000002210 for a Client Consent Income Verification Service. The service will provide a 24/7 secure, automated web-based portal enabling clients to access real-time or near real-time payroll and employment data verification compatible with the State's MI Bridges and Bridges systems. The solution must support income and employment verification across multiple MDHHS programs including SNAP, TANF, and Medicaid, with verification requests generated through nightly API processes and real-time on-demand lookups. The contractor's scope is limited to payroll-sourced income verification, with integration responsibilities shared between the State and the contractor. The contract term is three base years plus three one-year renewal options, totaling six years.
The State defines pricing flexibility, preferring flat fixed-rate models with potential volume-based tiered discounts calculated per 100,000 individuals submitted for verification, while remaining open to alternative pricing models beyond traditional licensing structures. The State will conduct cost evaluation considering both price and system capabilities to determine best value. Key requirements include SOC 2 Type II reporting with NIST 800-53 control mapping, support for state-approved cloud environments (Azure, AWS, or Google), and a 20 percent Goods and Services Business Enterprise (GDBE) subcontracting threshold based on contract dollar value. The contractor must provide tool-free support Monday through Friday from 8:00 a.m. to 8:00 p.m. EST with emergency contact availability outside scheduled hours, tiered service level agreements for issue resolution ranging from four hours for critical errors to ten business days for medium errors, and initial training for fewer than 20 subject matter experts delivered virtually.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 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 |
| 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. | |
| 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. | ||
| 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. | ||
| 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. | ||
| 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? | ||
| 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? | ||
| 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.)? | ||
| 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? | ||
| 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? | ||
| 54 | Schedule A – Attachment 1 – Business Specification Worksheet - Item 12.0 | 98 | Can the State clarify how “resolution of support issues” is defined? | ||
| 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? |
| 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?
| 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?
| 59 | Schedule A - Statement of Work | ||
| Section 11. Integration | 81 | Can you provide details regarding how verification volume projections were calculated? | |
| 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?
| 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? |
| 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? | ||
| 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? | ||
| 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? | ||
| 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 .