Attachment_M.docx

Attachment M: Solution Overview & Components Sought The State seeks a unified, configurable Comprehensive Child Welfare Information System (CCWIS) solution delivering all functional and non‑functional capabilities identified in the Requirements Traceability Matrixes (RTMs), prioritizing configuration over customization so Minnesota can adapt quickly to policy changes, federal expectations, and local practice without incurring undue technical debt. The solution should present a coherent platform experience across functional areas, environments, and integrations. Additionally, the State is seeking documentation of the solution environments and deployment patterns suitable for statewide oversight.

Attachment M: Solution Overview & Components Sought is organized into the following eight sections:

· Section 1: Solution Overview and Architectural Principles describe the State’s expectations for a unified, configurable CCWIS architecture aligned to Minnesota’s state‑supervised, locally administered model. Responders are asked to provide proposed solution architecture, environments, integration approach, and cloud services supporting implementation and operations within Minnesota’s technology ecosystem.

· Section 2: Core Functional Areas (Minimum Scope) identifies the minimum child welfare functional areas the CCWIS solution should support. Responders are asked to demonstrate how their solution enables increased statewide standardization while supporting locally administered practice through configuration, using the Investigation and Assessment functional area as an illustrative example.

· Section 3: Interoperability and Data Exchanges define expectations for data exchanges with State, County, Tribal, and partner systems; Responders should provide a preliminary interface catalog.

· Section 4: Document Generation and Records Management outlines requirements for document creation, management, retention, and exchange; Responders should describe how these capabilities are supported in their solution.

· Section 5: Portals and Self‑Service describes expectations for role‑based portals for families, providers, and legal partners; Responders should describe available portals and key capabilities.

· Section 6: Innovation Expectations defines how innovation is expected to be introduced and validated over time; Responders should describe their innovation approach and supporting evidence.

· Section 7: Responsible Use of Artificial Intelligence (AI) Features outlines expectations for optional, governed, and advisory AI capabilities; Responders should identify proposed AI‑assisted features and applicable safeguards.

· Section 8: System Administration, Security, and Data Management describes expectations for system administration, security, accessibility, and data stewardship; Responders should provide a high‑level domain model and data quality overview.

Responders: To avoid duplication, do not submit the following in Attachment M: Solution Overview & Components Sought: Project plans, schedules, staffing, sample PM artifacts, testing strategies or evidence, UAT plans, training programs or materials, Sustainability Support, Warranty, SLAs, incident, continuity, disaster recovery, vulnerability, or policy level security plans. Those items will be evaluated in Attachment K: Project Management and Implementation Methodology and Attachment L: Testing, Training, & Support.

Section 1: Solution Overview and Architectural Principles Architecture should align to Minnesota’s state‑supervised, locally administered model. State program divisions set policy, standards, funding parameters, and oversight, while local jurisdictions deliver intake, investigation/assessment, ongoing casework, placement, permanency, licensing and prevention. Therefore, the platform should support statewide data standards and reporting while enabling local flexibility in roles, workflows, and forms—without fragmenting statewide data or weakening policy. The solution should respect Tribal sovereignty, provide configurable access boundaries and sharing protocols aligned with Tribal law and agreements.

The platform should be cloud‑oriented, designed for availability, performance, and accessibility. It should support distinct environments (development, quality assurance, User Acceptance Testing (UAT), training, production), monitoring/alerting, and disciplined configuration promotion. It should provide auditable traceability from requirement to configuration to test and release, meeting Minnesota’s expectations for deliverable evidence and oversight.

The solution should enable robust evidence of federal compliance (e.g., CCWIS modularity, interoperability, and data quality planning, plus federal reporting) and be designed from inception to support federal reviews and self‑assessments.

Section 1 Response:

Provide a clear and comprehensive overview of the proposed technical solution, including descriptions of the key data architecture and application architecture. Summarize the environments required to support the project approach (e.g., Test, Training, Production) and describe the product’s data‑integration (API) architecture. Outline the cloud‑hosted services and administrative tools that will support ongoing management of the product and its underlying infrastructure. Address integration needs with existing agency systems and applications and identify any specialized tools or services required for data conversion, training, or other implementation‑related activities.

Section 2: Core Functional Areas (Minimum Scope) At a minimum, the CCWIS solution should deliver end‑to‑end capabilities across the following areas. These areas should be supported through configuration of assessments, forms, rules, and workflows to reflect Minnesota’s practice frameworks, including Whole Family Approach Framework, while accommodating local and Tribal variation under statewide standards. Requirements for the functional areas are detailed in Attachment G: Functional Requirements Traceability Matrix (RTM).

Intake captures referrals; support screening, triage, and prioritization; route to investigation or alternative response pathways.

Assessment/Investigations documents safety planning; and provide configurable assessment instruments (e.g., decision points and scoring) that can differ by jurisdiction without eroding statewide data integrity.

Ongoing case management manages plans, services, contacts, visits, tasks, approvals, and supervisory reviews. Support flexible caseload patterns (specialists and generalists) and cross program coordination consistent with Minnesota’s Whole Family Approach framework.

Placement and permanency support removal, search/matching, placement events, trial home visits, permanency planning (reunification, guardianship, adoption), and documentation of placement preferences and active‑efforts for Indian Child Welfare Act/ Minnesota Indian Family Preservation Act/ Minnesota African America Family Preservation and Child Welfare Disproportionality Act.

Prevention Services support community-based prevention activities that may occur prior to or independent of formal child welfare system involvement, including basic case management for Community Resource Centers, tracking of county and provider-delivered prevention supports, and generation of data required for fiscal reconciliation, while ensuring that prevention data is logically separated from child welfare case data and access is controlled based on program and role.

Provider and licensing enable caregiver/provider recruitment, applications, background studies, home studies, approvals/renewals, payments, and capacity management.

Indian Child Welfare Act/ Minnesota Indian Family Preservation Act/ Minnesota African America Family Preservation and Child Welfare Disproportionality Act provide configurable capabilities to verify affiliation, determine jurisdiction, notice appropriate parties, document active efforts, and record placement preferences and case collaboration, with configurable data‑sharing and visibility controls that respect data sovereignty.

Title IV‑E eligibility and fiscal support initial and periodic redeterminations, eligibility logic, and fiscal processes that align with Minnesota practices; support accurate claiming and reconciliation in an environment that includes county accounting, State financial systems, and Medicaid interfaces.

Reporting and analytics produce federal submissions and State dashboards/analytics; support local reporting needs through ad-hoc report building; embed data‑quality controls and lineage to ensure confidence in oversight and public transparency, consistent with CCWIS expectations and Minnesota’s practice ecosystem.

Section 2 Response Instructions Using the Assessment/Investigations functional area as an example, describe how the solution supports both statewide standardization and locally administered practice. Responders should reference and incorporate relevant information from Section 2, Attachment E: Minnesota’s Child Welfare Ecosystem, and Attachment G: Functional Requirements Traceability Matrix (RTM). The response should clearly indicate where configuration is used to achieve flexibility and consistency and should avoid reliance on custom code. The recommended response length is four (4) pages.

Section 3: Interoperability and Data Exchanges The CCWIS solution should support uni-directional and bi-directional data exchanges to reduce duplicate data entry and improve the timeliness and quality of decision making. As showcased within Attachment F: Technology Landscape MNIT has created a robust data architecture to support the State’s enterprise architectural needs. Utilizing existing architecture where feasible, the solution should enable integration across State and local jurisdictions, and with external partner systems, using exchange patterns appropriate to the nature and frequency of the data being shared.

Responders should describe how interfaces are designed, implemented, tested, and monitored. This includes providing an interface catalog, operational runbooks, and a testing approach that together support reliable, secure data exchange across State owned and third-party systems, including county systems where appropriate.

At a minimum, interfaces should support statewide client and identity services, court data exchanges, Medicaid eligibility and claims coordination, licensing and background study systems, State accounting and payments, statewide data repositories or warehouses, AICWIT case management solutions, county based Electronic Document Management Systems, and county accounting and reporting systems. The interface catalog should specify the purpose of each interface, direction of data flow, exchange patterns, payload standards, frequency, error handling, fallback procedures, and operational monitoring.

Minnesota expects an application programming interface (API) first approach, including defined versioning and deprecation practices and security controls aligned with State privacy and security requirements. These practices are intended to support modularity, durability, and long-term maintainability of system integrations.

Section 3 Response Instructions Submit a preliminary interface catalog that aligns with Attachment F: Technology Landscape and this section of Attachment M. For each interface, describe its purpose, direction of data flow, exchange pattern, payload standard, and the partner system or category of systems involved.

The response should also describe the Responder’s approach to versioning and deprecation, error handling, and the operational metadata which would be available to support State oversight. The recommended response length is three (3) pages. Do not include test plans or SLAs in this section.

Section 4: Document Generation and Records Management The CCWIS solution should generate and manage both structured and unstructured artifacts associated with people, providers, and cases. Capabilities should include template‑driven document generation; prefill fields from case data; versioning and redlining; and e‑signature; produced in accessible, non‑proprietary formats. Retrieval of documents and case history should be supported by date and document type filters and keyword search capabilities across content. Generated artifacts should be indexed to the proper record and enforce retention rules, audit trails, and chain‑of‑custody appropriate to child welfare and court contexts.

Minnesota’s current ecosystem includes widespread county use of a variety of EDMS platforms, localized templates, and significant volumes of attachments in SSIS. The future CCWIS should support State-required templates; support the collection of documentation through APIs established with local EDMS solutions to import high value documentation; ensure field staff can complete and access document templates on mobile devices; and provide secure exchanges. The solution should support export of data and documents in non‑proprietary formats, preserving continuity during system transitions.

Section 4 Response Instructions Describe how autofill of client, provider, and case data, along with versioning, redlining, e-signature, mobile use, and secure document exchange are handled in relation to templated documents. Within this response, confirm the approach taken to indexing to people, providers, and cases, retention controls, and export in non-proprietary formats to preserve portability across agencies and over time. Responder should provide two (2) document template examples and a description of the solution’s rendering and packaging flow Separate from the template examples; the response has a recommended five (5) page limit.

Section 5: Portals and Self Service The CCWIS solution should provide role appropriate, mobile responsive portals to extend access beyond frontline staff and supervisors. Portals might include prevention services, caregivers/providers, and individuals who report suspected abuse and neglect, with authentication and privacy controls appropriate to the sensitivity of child welfare data.

Portal capabilities should include secure messaging, tasking, appointment scheduling, document exchange, intake/referrals where appropriate, status visibility (e.g., licensing steps, placement or payment status), and configurable notices, all designed to reduce duplicate entry and improve timeliness.

Portal design should reflect Minnesota’s practice ecosystem, recognizing the diversity of interested parties, the Whole Family Approach framework, and the need to tailor views and workflows to role and jurisdiction, while enforcing statewide standards for identity, accessibility, auditability, and data quality.

Section 5 Response Instructions Describe the portals the Responder would provide, including role-based views, secure messaging, scheduling, document exchange, referral intake where appropriate, status visibility for licensing and payments, and configurable notices. Explain how portal capabilities will be tailored to Minnesota’s state supervised, locally administered model and Tribal considerations, while maintaining identity, accessibility, and auditability expectations. Do not include help desk or training content here.

Provide one portal storyboard, for example caregivers/providers, showing end-to-end tasks such as document exchange and status checks. The response has a recommended five (5) page limit.

Section 6: Innovation Expectations Minnesota fosters an environment in which innovation is encouraged, intentional, and sustainable not episodic or bolt on. The Responder should use iterative product demonstrations so improvements can be adopted in a controlled manner without disrupting statewide standards, reporting integrity, or federal alignment. The State invites Responders to collaborate with subcontractors or partners, as appropriate, to present a solution intentionally composed to deliver the strongest overall outcomes, while maintaining clear, single‑point accountability for performance, integration, and delivery with the Responder.

Innovation is anticipated in four practical dimensions.

· User experience and mobility, modern responsive UX that decreases administrative burden and supports field-based work across devices.

· Interoperability patterns and API first exchanges that lower partner integration friction over time.

· Data quality and analytics, embedded validation, and lineage that strengthen oversight and federal reporting and improves fraud prevention while enabling timely, actionable insights.

· Operational practices, tooling, and automation across environments, testing, monitoring, and release to increase throughput while preserving auditability.

Innovation should be evidence producing. Each innovative practice or capability should yield clear artifacts which are maintained in the project library and traceable to the WBS and RTMs.

The state views legacy system modernization as a program integrity imperative. The State encourages responders to present options to reimagine how its modernized technology supports county and tribal frontline workers and state oversight functions in prevention of fraud pre-payment. Solutions that bring together data and validations to level-up fraud prevention and program integrity through technology and process change are of keen interest to the state.

Section 6 Response Instructions Identify the innovations the Responder proposes to bring to Minnesota, and the evidence which will be provided to show value. Within this response, the Responder could include innovative functionality deployed in other statewide modernization project The response has a recommended two (2) page limit.

Section 7: Responsible Use of AI Features Minnesota welcomes responsible use of AI to reduce administrative burden, improve access to information, and support consistency, provided AI supports, but does not replace professional judgment. All AI capabilities should be optional, configurable, explainable, and governed by State-approved policies. Human review, audit trail, and override should be available at all times.

AI features should comply with State privacy, security, accessibility, and Tribal data protection requirements. AI should not make stand-alone determinations related to safety, risk, eligibility, placement, or permanency. All AI outputs are advisory only and should be clearly labeled within the user experience.

AI enabled capabilities may include, but are not limited to, the following high-level uses:

· AI assisted documentation and summarization

· AI assisted data quality and consistency checks

· AI enhanced search, retrieval, and navigation

· AI assisted workflow guidance aligned to approved rules

· AI supported training, help, and user assistance

· AI supported analytics using approved, de-identified data only

· State controlled governance, transparency, and auditability Training data pathways and model behavior should be transparent to the State. The successful vendor should document inputs, outputs, safeguards against bias, data retention, and opt out controls by feature. Any AI enabled help, for example in product guidance or learning recommendations, should meet accessibility requirements and should be integrated into the release cycle and training artifacts so staff understand how to use it safely and effectively.

Section 7 Response Instructions Describe the AI assisted features the Responder proposes, for example documentation and summarization, data quality checks, enhanced search, workflow guidance, product help, and analytics on approved de-identified data. Confirm AI is advisory, configurable, and aligned to State privacy, accessibility, and Tribal data protections. Provide a preliminary AI feature inventory with guardrails and the evidence the solution will produce. The response has a recommended three (3) page limit. Do not include enterprise security programs in this section.

Section 8: System Administration, Security, and Data Management The CCWIS solution should provide administrative consoles for role and permission management, feature tools, configuration promotion, and environment controls that are suitable for statewide operations with local variation. Minnesota requires an environment strategy for development, quality assurance, UAT, training, and production. The strategy should include scripted deployments, audit trails, and separation of duties. Monitoring and alerting will cover application, API, batch, interface, and infrastructure health with dashboards and exportable logs.

Given Minnesota’s state supervised, locally administered model, the solution architecture must support enforcement of statewide standards while enabling configurable variation at the county or local agency level, including differences in roles, approval workflows, and user interface views. These capabilities must be implemented within a single, shared data architecture that maintains data consistency and integrity and avoids logical or physical data silos. Access models should be flexible enough to enforce distinct Tribal data boundaries when required by law or agreement.

The solution should enforce least privilege access, provide complete logging and audit, should support vulnerability management with remediation timelines, and should maintain tested backup and restore, continuity, and disaster recovery capabilities. Security monitoring will include intrusion and anomaly detection, log correlation, and event escalation with reporting timelines aligned to State policy.

Data management capabilities should be designed to support consistent, accurate, and auditable statewide reporting and analytics. The solution should include clear data models, standardized definitions, lineage tracking, and stewardship mechanisms that enable transparency and support federal reporting requirements.

Section 8 Response Instructions Responders should describe the solution’s approach to system administration, security, and data management as implemented within the product. The response should focus on product capabilities, configurations, and controls rather than project execution plans or operational procedures.

At a minimum, the response should include:

· A summary of system administration capabilities, including role and permission management, configuration and promotion controls, environment management, logging, and audit support appropriate for statewide operations with local variation

· A summary of security capabilities embedded in the solution, including access controls, audit logging, monitoring and alerting support, and alignment to least privilege principles

· A high-level domain model illustrating core entity groups and relationships, such as person, family, case, placement, provider, payment, and claim, sufficient to demonstrate support for federal reporting and statewide analytics

· A concise narrative describing how the solution supports data quality management and data lineage, including validation controls, traceability, and stewardship features within the product Responders should avoid detailed project plans, test evidence, traceability matrices, or operational procedures in this section. Those materials are addressed in other attachments. The response has a recommended four (4) page limit.

Policy Template 1

CCWIS RFP: Attachment M 1 image4.png image5.svg image2.png image3.svg