Attachment_F.docx

Attachment F: Technology Landscape This document is for informational purposes only.

Attachment F: Technology Landscape provides a comprehensive overview of the technology landscape supporting Minnesota’s child welfare and related social services programs, with a primary focus on the Social Services Information System (SSIS) and its surrounding ecosystem. This attachment describes the functional modules, technical architecture, data structures, interfaces, governance, and operational realities that shape how SSIS is used today by state agencies, counties, and Tribal Nations. It also situates SSIS within the broader statewide and local technology landscape, highlighting the interdependencies, constraints, and complexities that must be considered as Minnesota plans for and transitions the child welfare program areas to a modern Comprehensive Child Welfare Information System (CCWIS). The intent of this attachment is to provide sufficient detail to understand the current state, identify modernization challenges and opportunities, and propose solutions that align with Minnesota’s program, policy, and technology objectives.

Section 1: Social Services Information System

SSIS has been operational since 1999 and is a fully custom solution built using Delphi and Oracle technologies. SSIS functions as the primary case management system for child welfare work across Minnesota’s 87 counties and three American Indian Child Welfare Initiative Tribes (AICWIT). It is also used by staff within three state agencies, Department of Children, Youth, and Families (DCYF), Department of Human Services (DHS), and Minnesota Department of Health (MDH), who conduct permanency, oversight, fiscal, and maltreatment investigation activities for programs under state jurisdiction.

Although SSIS is described as a modularized system, it is not organized by program area. Instead, its modules reflect functional capabilities that were introduced incrementally over time as new needs emerged. The sections below describe each of the major functional components of SSIS.

SSIS Worker & Fiscal SSIS Worker & Fiscal supports all child welfare program areas as well as other social services program areas, from intake to case management, as well as an array of supporting fiscal functionality. Data in SSIS is organized by overarching case number, as well as by “workgroup” number. A workgroup represents a distinct programmatic engagement under a broader case. Social services programs, and corresponding workgroups names, supported by current SSIS are detailed below:

These program areas are supervised at the state-level by both DHS and DCYF, with Child Services being split between the two agencies. Phase one of the CCWIS project scope includes migrating the data for all of Child Welfare, Children’s Mental Health, Child Foster Care Licensing, and Developmental Disabilities cases involving a child. These components are highly inter-related today and will need to continue to interface seamlessly for the best end-user experience, as well as to meet State and Federal statute.

The “SSIS Worker & Fiscal” module supports functionality of the continuum of services: Intake/Screening, Investigations/Assessment, Case Management, and Permanency provided at the local level. SSIS Worker & Fiscal also contains an array of administrative and fiscal functionality, including standard administrative functionality like adding users, assigning staff to cases, and purging data, along with Minnesota specific functionality supporting the capture and reporting of staff time and Minnesota specific fiscal reporting and reconciliation. SSIS interfaces with local agency accounting and payments systems, which is detailed further in the Architecture and Interfaces section below.

SSIS State Permanency & Fiscal The SSIS State Permanency and Fiscal module was released in 2008 to support state-level staff responsible for permanency-related workflows and administration of statewide Adoption and Kinship Assistance programs. Unlike the SSIS Worker & Fiscal module, which supports child welfare casework, the State Permanency & Fiscal module provides specialized tools used exclusively by DCYF to manage permanency programs and statewide child welfare financial responsibilities. This module compiles Title IV-E claims from all local agencies statewide to support the state’s federal reimbursement. It also provides essential functionality for Minnesota’s Northstar Care Fiscal Reconciliation process, which establishes a fiscal partnership between the State and local jurisdictions. Northstar Care for Children is Minnesota’s statewide program that provides consistent medical and financial support to children in foster care and to eligible children who achieve permanency through adoption, Tribal customary adoption, or transfer of permanent legal custody to a relative or Tribal equivalent. Through this process, the State aligns non-federal funding contributions from all agencies across all children in Northstar foster care and those who have achieved permanency through Northstar adoption assistance and Northstar kinship assistance.

This module supports key permanency processes such as:

• Management of adoption and kinship permanency records

• Northstar Adoption Assistance and Northstar Kinship Assistance eligibility determination

• Creation, approval, and maintenance of permanency benefit agreements

• Post-adoption finalization case administration and ongoing benefit management

• State-level fiscal activities related to permanency programs (e.g., adjustments required for federal adoption assistance claiming) Although the module includes fiscal components tied to permanency programs, it does not contain Title IV-E eligibility determination, redetermination, or primary claiming functionality. This functionality is contained within SSIS Worker & Fiscal modules and are completed in partnership with local jurisdictions. Instead, the State Permanency & Fiscal module provides permanency-specific data and agreement outcomes that feed into statewide claiming processes managed elsewhere in SSIS.

Additional Fiscal Functionality Counties begin the reimbursement process at the county level, where staff document services, time, and payments tied to the children, families, and providers they support. For health care claiming, county workers rely heavily on SSIS to automate Medicaid claims for Targeted Case Management and Waivered Services. SSIS uses staff qualifications and eligible service entries on time records to generate claims, which are then submitted from SSIS through MN-ITS to Medicaid Management Information System (MMIS). This interface occurs through an SSIS account managed by a MNIT Business Analyst, and it requires MNIT to maintain MNIT passwords that must be changed every 90 days, or even more frequently, creating a continual operational strain on maintenance teams.

Behind the scenes, DHS Health Care Administration (HCA) and the Financial Operations Division (FOD) issue health care claim payments through Statewide Integrated Financial Tools (SWIFT). Both MN‑ITS and SSIS must maintain and manage Healthcare Common Procedure Coding System (HCPCS) and modifiers, claim edit codes, denial reasons, adjustment codes, reason remark codes, and rate information. After HCA pays a claim, the remittance advice is delivered to counties via the MNITs mailbox, listing the total reimbursement amounts. Counties also resubmit claims, void claims, and navigate claim takebacks through MN‑ITS and MMIS. When HCA processes takebacks directly in MMIS, these adjustments do not interface back to SSIS, leaving fiscal workers confused as the two systems fall out of sync. For guidance, workers must reference program policy pages housed on PartnerLink, maintained by HCA within MMIS. MMIS requires program areas to maintain policy and rules online but does not supply end user documentation for health care claiming, placing additional reliance on counties to interpret requirements accurately.

Beyond claiming, counties manage collections for overpayments across multiple programs. Using their collections systems, they record MAXIS (Eligibility data exchange), SSIS, MMIS, and MN Electronic Child Care Information System (MEC2) overpayments by program and party, collect receipts from clients or vendors, track receipt amounts by funding source within county accounting systems, and report back to the state by program area. Fiscal staff also produce letters to individuals with outstanding balances and pursue tax refund offsets through the Minnesota Department of Revenue’s Revenue Recapture system. Locator tools like LexisNexis may be used to find addresses for required notices.

All documentation associated with payments, claims, and collections, whether invoices from foster parents or tax‑related information from Revenue Recapture, must be stored securely in local Electronic Data Management Solutions (EDMS) or locked paper files. Counties maintain bank accounts for all payments, including special accounts and different software such as the Social Welfare Fund system where the agency serves as the Social Security representative payee for children in custody. Other agencies have contracted this service out and do not track funds for adult clients when the local agency is the guardian. Social Security imposes its own annual reporting rules for these payee accounts. Counties must also comply with the Minnesota County Financial and Accounting Reporting Standards (COFARS) established by the Office of the State Auditor (OSA), date‑stamp incoming invoices, pay them within 30 days per Minnesota Statute 16a.124, and undergo an annual financial audit conducted either by the state auditor or a CPA firm as required by Minnesota Statute 6.481.

Grants and allocations introduce another layer of complexity. Each grant or allocation has its own rules determined by the program policy area, and payments are issued by FOD. Counties may pay expenditures directly through their accounting system or some choose to pay through SSIS when payments are tied to client data. Other counties now issue nearly all payments through SSIS, regardless of client specificity. Quarterly, expenditures for Social Services Expenditure and Grant Reconciliation (SEAGR) are totaled using staff time by service and SSIS payments, forming the basis for calculating average staff cost per hour. This SEAGR report requires manual entry of at least 145 totals drawn from the county accounting system, along with adjustments. Tribal Nations cannot use this report but are eligible to receive grant reimbursement as well. Counties submit SEAGR either through SSIS or via Excel spreadsheet emailed to FOD. FOD then manually reconciles this information against each reimbursement type using the County Reporting System.

FOD also delivers grant data to program accountants using the Enterprise Grants Management System, which supports payment issuance; these payments are sent through SWIFT. Payments for Title IV-E and Northstar claims from SSIS DHS flow through Integrated Web Payment system (IWP) and then through SWIFT to counties and Tribal Nations. FOD within DCYF is moving toward IGX, a new grants management system that includes contract and application management, but the future location for allocation reconciliation and payment processing remains unknown.

Throughout this ecosystem, the County Reporting System continues to provide a cumbersome, inefficient experience for FOD staff, placing an undue burden on program policy teams who must reconcile participant data manually. From the county viewpoint up through state-level processes, the reimbursement structure remains highly complex, dependent on multiple systems that require alignment, timely maintenance, and extensive human effort to ensure accuracy and compliance.

SSIS Office of Inspector General (OIG) – Licensing & Investigations The SSIS OIG – Licensing & Investigations module supports the Minnesota DHS OIG and DCYF OIG in conducting investigations and managing licensing-related actions for DHS‑licensed provider types. This includes investigations of alleged maltreatment, licensing violations, program integrity concerns, and compliance issues in settings regulated by DHS (e.g., 245D/HCBS providers, family childcare — prior to the 2025 transition to DCYF — and other human services programs). The module provides structure for documenting intake information, investigation steps, evidence review, and final determinations, as well as capturing licensing actions resulting from those determinations.

The module integrates investigation and licensing workflows, allowing OIG staff to track assignments, timelines, interviews, and investigative activities within SSIS. It supports documenting maltreatment determinations, correction orders, conditional licenses, fines, and other licensing actions that follow from an investigation. These outcomes are used to support statutory reporting, public licensing action publication, and coordination with provider licensing systems.

Because OIG investigations frequently originate from statewide intake pathways, the module consumes report information entered through applications such as the Minnesota Adult Abuse Reporting Center (MAARC) and aligns that data with SSIS’s statewide client index and provider references. The module also interacts with external OIG applications such as NETStudy 2.0, ELMS, Filenet, Salesforce, ELICI, and Licensing Information Lookup, ensuring that background study results, licensing statuses, and public investigation documents remain consistent across systems.

The SSIS OIG – Licensing & Investigations module is built on shared SSIS architecture, relying on the same security model, statewide person index, and underlying Delphi components used across SSIS Worker & Fiscal, State Permanency, and MDH Investigations. As a result, it depends on shared data structures and cannot be modernized independently without coordinated changes to the broader SSIS environment. Any future system must support integrated investigative workflows, licensing action tracking, and cross system data consistency with OIG’s external applications.

SSIS Minnesota Department of Health (MDH) Investigations The SSIS MDH Investigations module supports the MDH, specifically the Office of Health Facility Complaints (OHFC), in managing maltreatment investigations that occur in MDH-licensed health care facilities. These investigations involve allegations of abuse, neglect, financial exploitation, rights violations and quality‑of‑care concerns in settings such as hospitals, nursing homes, assisted living facilities, and home care providers.

The module supports MDH’s full investigation workflow. This includes consuming report information that originates either through MAARC for vulnerable adult cases or through direct OHFC complaints for minors. SSIS provides the structure to document triage, assignment, investigative actions, evidence collection, and required notifications. It also supports capturing final maltreatment determinations and any associated enforcement actions, such as correction orders or federal deficiency citations, and ensures these outcomes can be used in MDH’s regulatory and public‑reporting processes.

Because MDH investigations intersect with statewide maltreatment reporting, the module relies on SSIS’s shared client index, repository, and security model to maintain consistent person and facility information across programs. The module also interacts with county and DHS programs when MDH findings are relevant to other casework. While focused on MDH-specific responsibilities, the module depends heavily on shared SSIS data structures, identity management, and legacy Delphi components, and therefore cannot be modernized independently without coordinated changes to the broader SSIS technical environment.

Supporting Applications in SSIS Ecosystem:

A variety of supporting applications exist in the SSIS ecosystem to perform specific functions, as well as a variety of interfaces with other state human services main frame systems and local county solutions. A detailed tabled of these interfaces is included in the Architecture and Interfaces section below.

Section 2: SSIS Architecture, Interfaces, and Development Lifecycle:

SSIS Technical Architecture The SSIS application is implemented as a client/server solution with a graphical user interface (GUI) developed using the Embarcadero Delphi development framework. The application relies on an Oracle relational database management system (RDBMS) for data storage. Core business rules and validation logic are distributed across the Delphi application layer and Oracle PL/SQL packages, procedures, and functions.

The SSIS application and associated Oracle database currently operate within an on premises environment but are in the process of migrating to the Microsoft Azure cloud. This effort includes re-platforming application servers, migrating databases to cloud‑hosted Oracle services or alternative Azure-native offerings, and modernizing supporting infrastructure components. The target date for completing the Azure migration is April 2026.

Data Architecture Conceptual Model The SSIS conceptual model, representing the business entities, was completed at the onset of the development of SSIS as a State Automated Child Welfare Information System (SACWIS) and later continued as Minnesota’s transitional CCWIS. The current system is configured primarily to be Person-centric, while also being adaptable to Family-centric or Case-centric options to provide maximum flexibility for evolving program requirements to better represent the reality of the multiple associations that individuals may experience.

For the new CCWIS solution, the conceptual model will focus on strengthening data quality across counties and tribal agencies, supporting more consistent and accurate data by using clearer data definitions, standardized relationships, and improved alignment between Person, Family, and Case-level information. This will reduce duplication, prevent conflicting records, and make it easier for users to enter information correctly.

Logical Model The SSIS logical model (see diagram below) was developed early in the SACWIS lifecycle and has continued as a transitional CCWIS, which also includes changes that have been made to SSIS (e.g., fiscal additions).

Physical Model The physical model for SSIS continues to evolve with each new set of functionalities built for the system. The model is highly normalized to provide the most accurate representation of complex data, reduce redundancy, and increase efficiency. The physical data model, as an Entity-Relationship Diagram, is updated annually with each fourth quarter release and posted online, to show the most current representation of the entities and their attributes, as well as their associations.

Security Minnesota has a long history of guarding data privacy, supported by both federal regulations and state statutes. There are strong penalties, ranging from disciplinary action to criminal fines and confinement, which may be applied depending on the nature and severity of a violation. Data systems planned and used by DCYF are required to implement rigorous user identification and access methodologies. SSIS uses role-based security to control who has access to the application and to control the data and functions each authorized user can access.

Each user has a unique User ID, set up by a system administrator, after approval by supervisory staff. Strong passwords are required and must be changed every 30 days to maintain access. Each user must have at least one role assigned to access the system such as:

• Case aide

• Social worker

• Child protection worker

• Supervisor

• Fiscal worker

Roles are assigned to staff based on their work duties, set up by a system administrator, and require supervisory approval. Each role has a set of authorizations, including create, edit, or view authorizations associated with various modules within the system. Firewalls are in place to help isolate the system from unauthorized electronic access.

All users are required to successfully complete data privacy and security online courses prior to receiving access and are required to successfully complete annual refresher training. In addition, each user must sign a privacy oath stating that they will use the system only for necessary business purposes.

Data Management Database centralization was completed in June 2020, moving data storage from within each local agency’s database in a local agency server to virtual servers in St. Paul, MN. On a nightly basis, data from the centralized agency-based servers is sent to a multi-agency statewide SSIS repository to allow for statewide analyses of social services data. Non-confidential data from the SSIS repository are then pulled into the enterprise data warehouse to allow for cross-system/cross-program analysis.

MNIT maintains a data dictionary (a list of all the database fields and their definitions in plain English), in addition to the type of data and field size for every table and field combination within the SSIS database. The data dictionary is updated quarterly following each release, and is posted online.

As the State plans for a new CCWIS, DCYF and MNIT formed a dedicated team to review and evaluate the SSIS technical data architecture and to identify options for improving data collection, data quality, and data sharing.

Data Interfaces SSIS supports a wide variety of both internal and external interfaces. SSIS exchanges data with other state-owned mainframe solutions, as well as a variety of state data repositories used for reporting purposes. For local agency data needs, agencies have permission to access their own data in their corresponding database schema. An ODBC connection setup using the OpenLink application is used to access the data from the agency.

SWNDX

Historically when SSIS was first developed, each county had separated databases, physically maintained with on-premise servers. SWNDX makes certain information available, among and between, the counties. While each county maintains its own separate database, SWNDX enables the sharing of data between counties in two ways. One way is by storing data in the SWNDX database. The second way is by providing a mechanism for information stored in a particular county database, to be visible to workers in other counties. The Expanded Statewide Search is an example of the second mechanism.

Data is entered into SWNDX in two ways. County workers may add new clients to SWNDX, or additional information about existing clients, by using the SSIS Worker application. Information also enters SWNDX via programmatic data import operations from a departmental data warehouse (EIS), or more directly from MAXIS (Eligibility data interchange). This imported information originates from the MAXIS and PRISM systems.

SWNDX also allows other state systems to access SSIS data without having to access each individual county. Currently, the MAXIS Eligibility data interchange is the only example of this. Later this year, Licensing will also access information stored on SWNDX.

SSIS Supporting Applications/Interface Table

Section 3: Existing SSIS Maintenance, Operations, and Support Ongoing operations for SSIS involve making modifications to the software for several purposes:

• Defect correction

• Functional enhancement

• Performance or other non-functional improvement

• Extension to a new set of users or new area of operation

Maintenance and operations tasks, depending on exact definition, currently account for 60% – 80% of work completed in SSIS. Unlike larger projects that are managed through the Gateway (detailed in the governance section below) or as a demonstration “product,” new SSIS maintenance and operations requests are managed within the SSIS Input Group. Each request is entered on the division’s SharePoint site and prioritized within the division and across business areas by the Input Group.

New Enhancement Requests are entered into the SSIS SGG SharePoint Site. They are reviewed, researched, and prioritized by the SSIS Business Operations team. Requests that are planned to move forward are further evaluated by the SSIS Bus Ops team in conjunction with MNIT Business Analysts. Once requirements are fully developed, the enhancement is reviewed by the Input Group where resources are assigned, and a release date is set.

SSIS Business Operations is a team of subject matter experts, including a supervisor and six SMEs (two fiscal, two child welfare, and two data integrity), who serve as the primary liaison between SSIS users, policy partners, and MNIT. These SMEs provide program, policy, fiscal, and data expertise throughout the development lifecycle, working closely with MNIT Business Analysts to clarify business needs, validate requirements, and identify impacts on workflows and user experience. They participate in requirement and design discussions, review proposed solutions, and ensure that enhancements reflect statutory requirements, policy intent, and real‑world practice. Their involvement helps maintain accuracy, usability, and program alignment as enhancements move through the SSIS process.

SSIS is on a pre-determined quarterly release cycle. All enhancements and corrections to the code base are prioritized and scheduled for a specific release. SSIS development is supported in house by a MNIT-HSDS team, including:

· A team of thirteen business analysts gather requirements for any changes to the SSIS application.

· A team of eleven developers maintain the enhancements and corrections to the SSIS application.

A team of nine quality assurance staff perform testing of any changes to the SSIS application prior to scheduled release.

Section 4: Technology and Data Governance DCYF has a governance structure for IT project work related to any of the statewide human services IT systems including SSIS. The DCYF Strategic Governance Committee consists of executive leadership who set strategy for the agency. Since SSIS is a shared system with DHS, there is also a shared strategic governance structure. A joint Executive Steering Committee oversees System Governance Groups, including a cross-agency governance group that prioritizes work that needs to be done in SSIS. Membership includes business and IT leadership, staff from affected policy/business areas, local social service agency representatives, and representatives from associated systems.

Large projects, including SSIS projects, are managed through the MNIT Services Gateway and overseen by the various teams within the larger governance structure. Project requests are submitted by a business area, with the request serving as an initial project proposal for consideration by MNIT management. The information in the request is used to estimate the effort it would take to accomplish the proposed project, identify IT resources, and provide a project portfolio review. Each proposal is scored using a standard prioritization score sheet, that prioritized within the specific business area, then prioritized across all project requests from all business areas of DCYF. DCYF in conjunction with MNIT is implementing a new model that shifts from a project management approach to a product approach. This enables more stable IT resources for each product and helps adhere to Agile methodologies of software development.

A CCWIS Steering Committee has been operationalized in addition to this existing technology governance structure in order to have regular touch points with leadership across interested parties for influence and input on decision making during the planning project. Along with Vision and Strategic levels of governance, the CCWIS Steering Committee provides guidance, feedback, and direction to the Tactical CCWIS Core Team who is responsible for moving work forward within those guardrails.

Section 5: Statewide Technology Landscape:

The state maintains many other large case management and data information systems across DCYF and DHS, detailed below and on the DHS public website. Efforts towards modernizing these systems are further detailed on the DHS website, as well as on DCYF’s IT Modernization Page. The state encourages vendors to propose solutions that leverage as much existing technology as feasible and practicable, rather than introducing additional complexity into the DCYF landscape.

The diagram below illustrates the current and proposed SSIS technology landscape, showing how SSIS, CCWIS modules, data ingestion and Lakehouse components, interfaces, and downstream systems integrate to support statewide child welfare operations, reporting, and data exchange with counties and external partners.

The table below outlines the primary data and integration architecture layers, associated tools, and key usage constraints within the statewide technology landscape.

Section 6: Local Agency Technology Landscape Minnesota’s locally administered context introduces complexity to the technology landscape as well. Amidst various state efforts to modernize statewide systems, local agencies have stepped in to fill the gaps and provide solutions to their workforce and constituents tailored to the needs and constraints of their county or tribe. Local agencies have procured, configured, or developed local solutions for many purposes, but some of the most common include:

· Analytics and Reporting

· Lobby Management

· Automated Workflows

· Electronic Document Management Portal Functionality or web forms for the public or specific purposes (e.g. Foster Care Licensing, reporting maltreatment, Post-Permanency supports requests)

· Accounting, Payments, and Fiscal Management As aforementioned, SSIS interfaces with all county fiscal systems. Data from SSIS is ingested into local solutions via the processes articulated above in Section 2, Data Interfaces. The systems below are of particular impact to the CCWIS modernization project and detailed below.

Accounting, Payments and Fiscal Most counties rely on TriMin Government Solutions’ Integrated Financial Services (IFS) platform as their primary human services accounting system. Counties that use IFS participate in the IFS User Group, and the system itself is owned and governed by the Joint IFS Committee (JIC), which is made up of representatives from that user group. A subset of counties have opted to build their own custom payment‑issuing solutions, maintained by internal IT teams, while still adhering to the COFARS established by the OSA. Other counties have implemented broader Enterprise Resource Planning (ERP) systems—such as Workday or Tyler Technologies—to integrate HR, payroll, and fiscal operations across the countywide enterprise.

Counties that use IFS or other county fiscal systems to issue checks and electronic funds transfers (EFTs) commonly supplement the system with reporting and analytics tools to support revenue analysis, budgeting, and trend identification. Frequently used solutions include Tableau, Power BI, Crystal Reports, and ODBC based connections to the SSIS SQL database and repository. For audit purposes, most counties have adopted Electronic Document Management Systems (EDMS) to store fiscal documentation, though some still maintain physical files.

Counties connect their accounting systems directly to SSIS to support two critical interfaces: vendor import and payment processing. Vendor import allows county staff to create new vendors within their accounting systems, which then flow into SSIS as imported vendors with limited edit capabilities. This functionality is used across all program areas, but it is foundational to Title IV-E and Northstar Care claims for prevention services and out-of-home placement. For these program areas, counties historically entered payments as Payment Requests, which interfaced with their accounting system and then returned warrant numbers, warrant dates, and total warrant amounts to SSIS. These warrant details, representing the check or EFT issued, are required for both audits and federal IV-E compliance.

As operational needs evolved, agencies also began using Posted Payments, which does not interface directly with accounting systems. Instead, agencies manually enter payment information into SSIS after the payment has already been processed. While resource-intensive, this option allows payments to be converted into Title IV-E or Northstar claims and included in the Social Services Expenditure and Grant Reconciliation (SEAGR) state report. When the AICWITs were added to SSIS as Title IV-E participants, Posted Payments were the only available payment method, resulting in no system integration with The Tribal Nation fiscal systems and creating a manual, unsustainable workload.

The provider import process allows agencies to create their own vendor records, enabling placement provider information and addresses to be recorded within out-of-home placement episodes for AFCARS reporting and the CB-496 Title IV-E financial report. However, this decentralized structure has created significant challenges in statewide data analysis. Vendors are often duplicated across agencies—and sometimes within a single agency—and there is no consistent statewide vendor identifier to support cross-agency data alignment. At the same time, the state separately maintains contracts and rates for Title IV‑E-approved facilities and treatment centers in a standalone vendor file, adding further complexity to the current environment.

For phase one of the SSIS Modernization project, the state’s vision is to tackle components of this complex functionality set required for CCWIS and position the new system as much as possible as the data collection tool, while continuing to leverage data exchanges and SSIS functionality as needed to maintain operations. Currently additional planning is underway to fully re-imagine the future of fiscal functionality long-term to streamline cross-agency processes.

A detailed breakdown of Fiscal systems used across the counties is below:

Counties using Integrated Financial System (IFS)

Counties using IFS

Counties using other financial systems:

Foster Care Licensing Portal Minnesota’s child foster care licensing processes remain decentralized, with no statewide recruitment system for child foster care, resulting in varying approaches and capacity across agencies. Local agencies and private child-placing agencies are responsible for recruiting prospective providers, completing licensing activities, and submitting all required documentation to DCYF’s Office of Inspector General, Family Systems Licensing Division, for license issuance. Counties are able to document their child foster care licensing provider-support activities in SSIS; however, this functionality is not uniformly adopted statewide, leading to inconsistencies in how licensing work is tracked, supported, and reported. Formal licensing activities continue to be a mixture of paper and electronic documentation in multiple systems.

Minnesota DCYF contracts with Foster Adopt Minnesota (FAM) through the Public Private Permanency Collaboration (PPPC) and Permanency Support Services (PSS) initiatives to expand access to foster care, adoption, and permanency supports by reducing placement disruptions and providing a continuum of services for children, youth, and families. These initiatives enable FAM to coordinate private child‑placing agencies that deliver licensing, home studies, placement, and permanency services. Several local jurisdictions and private agencies—including the 12 agencies of Becker, Beltrami, Crow Wing, Lake of the Woods, MN Prairie County Alliance, Hennepin, Washington, Scott, St. Louis, Winona, Dakota, and Leech Lake—have also received support for implementing Binti in their foster care workflows. The primary functionality delivered for these agencies is for managing and organizing child foster care licensing process, allowing agencies and applicants to complete forms, upload documents, track tasks, and communicate in one place. However, Binti is not integrated with state systems, resulting in ongoing duplication of data entry and further variation in licensing practices.

The state supports multiple systems used to administer licensing; state staff who review child foster care applications and licensing recommendations must also navigate several different platforms, including the Electronic Licensing Management System (ELMS) adding complexity to the overall child foster care licensing processes. Manual and duplicative data entry occurs at both local agencies and the state level, as information must often be entered into multiple, unconnected systems to complete licensing and provider‑support tasks.

The vision for CCWIS is to streamline the care provider licensing workflow currently spread across multiple state and local systems to decrease duplicative data entry and reduce administrative burden for providers, county, and state users.

Document and Forms Management Within SSIS, as of early 2026, approximately 1.26 million documents have been stored as attachments and indexed by person or workgroup record. Year over year, it is estimated that local jurisdictions create approximately 100,000 documents in SSIS across all child and adult program types, with varying degrees of use across agencies. Additionally, the SSIS Document Template Editor enables local jurisdictions the opportunity to create forms, including the configuration of county specific forms (called Document Templates), which are indexable by person or workgroup record. To date, more than 3,800 templates have been created and exist within SSIS, as configured by local jurisdictions – however only 690 of these templates were actually utilized over the past calendar year Although these functions exist within SSIS, local jurisdictions have implemented standalone Electronic Document Management Systems (EDMS) to support local practices, providing more robust functionality than the document management functions provided within SSIS. From robust mobile-friendly functionality including the capturing, uploading and retrieving of documents to elevated electronic forms functionality that enables users to collect electronic signatures, route work through pre-configured workflows, and collaborate with clients, local EDMS solutions are an integral part of day to day operations when administering child welfare services.

Currently, while there are no interfaces between SSIS and county EDMS solutions for migrating forms or completed documents, the successful Responder should appropriately plan for interfaces to be established between the new CCWIS solution and local EDMS solutions. Based upon guidance received from the Administration for Children and Families (ACF) in March 2026, EDMS solutions can remain a part of the statewide technology landscape within Minnesota, supporting the statewide standardization of practice enabled by the new CCWIS solution. Through planning and collaboration, the State will identify those forms and documents that must be utilized within the CCWIS solution, enabling local jurisdictions to align with statewide practice, while continuing to use their local EDMS solutions for local practice and service delivery needs.

A full inventory of county EDMS was completed 2026, however this inventory changes often, and the solution used in one area of human services is not necessarily the same used by all. In Social Services, the counties are primarily served by four vendor provided solutions (NCT Caseworks, Hyland OnBase, Northwoods Traverse, and ICS AppEnhancer), while Hennepin County maintains a homegrown solution referred to as ECF. A detailed breakdown of EDMS solutions used across the counties is below:

NCT

CaseWorks

X

Benton

X

Carver

X

Cass

X

Chippewa

X

Chisago

X

Clearwater

X

Crow Wing

X

Dakota

X

X

Hennepin

X (ECF)

Hubbard

X

Kanabec

SS use - X

Lac qui Parle

X

Lake of the Woods

X

Le Sueur

X

McLeod

X

Mille Lacs

X

X

Pine

X

Ramsey

X

Renville

X

Scott

X

Sibley

X

X

Todd

X

Wadena

X

X

Wright

X

Yellow Medicine

X

Policy Template 1

CCWIS RFP: Attachment F 1 image4.png image5.svg image6.png image7.png image8.png image9.png image10.png image11.png image12.png image13.png image2.png image3.svg