RFP 26-86378 Community Supports IT Systems Attachment K – Statement of Work (SOW) Addendum 1

Contents

Glossary

1.0 Background

1.1 Purpose

1.2 Community Supports Programs Overview

1.3 Systems Overview

2.0 Maintenance and Operations (M&O) Services Responsibilities

2.1 General Systems Support

2.2 Help Desk Support

2.3 Incident and Problem Management

2.4 Access Management

2.5 Application Management

2.6 Maintenance and Operations Plan

2.7 M&O Following Individual System Component Consolidation & Sunset

3.0 System DDI and Enhancement Services (General Responsibilities)

3.1 System Enhancement Services Responsibilities

3.2 Training

4.0 Reporting

4.1 Weekly Community Supports IT Systems M&O Status Report

4.2 Weekly Enhancements & Consolidation Report

4.3 Monthly Service Level Agreement (SLA) Report

4.4 Quarterly Performance Report

4.5 Annual Summary Reports

4.6 Federal Reporting

4.7 Reporting to interRAI Organization

4.8 Community Supports IT Systems Incident Reporting and Tracking

4.9 Staff Utilization Report

4.10 Ad Hoc Reporting

5.0 Meetings

5.1 Transition Specific Meetings

5.2 Monthly Status Meeting

5.3 Quarterly Performance Meeting

5.4 System Priorities Meetings

5.5 Ad Hoc Meetings

6.0 Staffing

6.1 Contractor Staff Working Location

6.2 Vital Positions

6.3 Non-Vital Positions

6.4 Supporting Staff

6.5 Contractor Staff Replacement

6.6 Staffing Plan

6.7 Staff Compliance

7.0 Project Management and Administrative Duties

7.1 Coordination with State Entities, Vendors, and Partners

7.2 Location and Offices

7.3 Project Management and Documentation

7.4 Change Review Board

7.5 Accessibility Requirements

7.6 IV&V Engagement Language

8.0 Transition and Turnover

8.1 Initial Transition

8.2 End of Contract Turnover

9.0 Payments and Invoicing

10.0 Service Level Agreements (SLAs) and Open Incidents

10.1 Service Levels Overview

10.2 Maintenance and Operations Service Levels

10.3 System Enhancements Service Levels

10.4 Corrective Action and Performance-Based Withholds

Glossary

Acronym Term

AAA Area Agencies on Aging

ADRC Aged and Disabled Resource Center

BBA Better Bureau on Aging

BC Business Continuity

BDS Bureau of Disabilities Services

CaMSS Care Management for Social Services

CHOICE

Community and Home Options to Institutional Care for the Elderly and Disabled

CIH Waiver Community Integration and Habilitation Waiver

CIO Chief Information Officer

CMO Case Management Organizations

COOP Continuity of Operation Plan

DART Developmental Disabilities Automated Resource Tool

DDARS Division of Disability, Aging and Rehabilitative Services

DDI Design, Development, and Implementation

EDW Enterprise Data Warehouse

EY Early Years

FSSA Family and Social Services Administration

FS Waiver Family Supports Waiver

H&W Waiver Health and Wellness Waiver

HC Home Care

HCBS Home and Community Based Services

I/DD Individuals with Intellectual and Developmental Disabilities

ICF/IID

Intermediate Care Facility for Individuals with Intellectual Disabilities/Development Disabilities

IFUR Incident and Follow-up Reporting

IMP Integrated Management Portal

IOT Indiana Office of Technology

IST Individual Support Team

LOE Level of Effort

M&O Maintenance and Operations

MFP Money Follows the Person

NFLOC Nursing Facility Level of Care

OAA Older Americans Act

OMPP Office of Medicaid Policy and Planning

PEDS-HC Child and Youth Pediatric Home Care

PIP PathWays Incident Processing

QA Quality Assurance

RAI Resident Assessment Instrument

SDLC Software Development Life Cycle

SGL Supervised Group Living

SLA Service Level Agreement

TBI Traumatic Brain Injury

UAT User Acceptance Testing

1.0 Background

The Indiana Family and Social Services Administration (FSSA), in partnership with various entities, operates IT systems in support of a variety of community-based supports and services programs, including both Medicaid Waiver and non-Medicaid/non-Waiver programs, described in greater detail in Section 1.3 below. This suite of Community Supports IT Systems currently includes the Developmental Disabilities Automated Resource Tool (DART), Division of

Disability, Aging, and Rehabilitative Services (DDARS) Provider Site, Incident and Follow-up

Reporting (IFUR), interRAI toolset(s) system, Bureau of Disabilities Services (BDS) Portal, BDS

Gateway, Integrated Management Portal (IMP), and PathWays Incident Processing (PIP). FSSA is currently engaged in a multi-year effort to consolidate these system components and functions to the greatest extent possible to promote alignment across program operations, improve user experience, increase efficiency and transparency while maintaining integrity and oversight, and improve data collection and traceability. This includes transitioning Community

Supports IT Systems operations and enhancements under a single vendor through this RFP process. The services the Community Supports IT Systems support are administered by

FSSA’s Division of Disability, Aging and Rehabilitative Services (DDARS) in partnership with the

Office of Medicaid Policy and Planning (OMPP).

1.1 Purpose

The purpose of this solicitation is to identify a Contractor to support the ongoing operation and performance of current Community Supports IT Systems while furthering FSSA’s IT system consolidation efforts according to the State’s timeline and priorities. To facilitate consolidation efforts, the State prefers a Contractor with experience providing IT support for the types of systems and programs described below (Section 1.2 and 1.3). In particular, the

State strongly prefers vendors with demonstrated experience with IT systems development and maintenance for State-level health and social services programs, Medicaid, and Home and Community-Based Services (HCBS). Respondents must detail their experience in

Attachment F - Section 1. At a high level, the Contractor will support Maintenance and

Operations (M&O) and Enhancement services for the full suite of Community Supports IT

Systems including as legacy and ancillary Community Supports IT Systems components are consolidated.

1.2 Community Supports Programs Overview

The suite of Community Supports IT Systems supports the delivery of crucial services for

Indiana residents on numerous Medicaid Waiver and non-Medicaid and non-Waiver programs.

1.2.1 Medicaid Waivers

The components of Community Supports IT Systems outlined in this Statement of

Work are used to support the delivery of FSSA’s HCBS waivers. These waivers, administered by OMPP and BDS with authority from the Centers for Medicare and

Medicaid Services (CMS), support older adults, children, and individuals with disabilities on Medicaid. The Medicaid waiver programs that are supported by the suite of IT systems include:

a. Indiana PathWays for Aging (PathWays) Waiver - serves individuals who are

60 or older who meet Medicaid and Nursing Facility Level of Care (NFLOC) eligibility requirements. Individuals receiving services through the PathWays

Waiver are enrolled in the PathWays managed care program. The PathWays

Waiver is administered by OMPP. PathWays Waiver slots are limited, and the

State manages new invitations for individuals seeking waiver placement through a Waiting List.

b. Health and Wellness (H&W) Waiver - serves individuals who are 59 and under who meet Medicaid and NFLOC eligibility requirements. The H&W

Waiver is administered by BDS. H&W Waiver slots are limited, and the State manages new invitations for individuals seeking waiver placement through a

Waiting List.

c. Traumatic Brain Injury (TBI) Waiver - serves Medicaid-eligible individuals with a traumatic brain injury by providing services based on their needs and the needs of their families. To be enrolled in the TBI Waiver, individuals must either meet NFLOC if the brain injury occurred at 22 years of age or older or meet the Intermediate Care Facility for Individuals with Intellectual

Disabilities/Development Disabilities (ICF/IID) level of care if the brain injury occurred before 22 years of age. The TBI Waiver is administered by BDS.

d. Family Supports (FS) Waiver - provides limited, non-residential supports to

Medicaid-eligible individuals with developmental disabilities who live with their families or in other settings with informal supports. To be enrolled in the FS

Waiver, individuals must meet ICF/IID level of care, have an intellectual disability diagnosed prior to the age of 22, and reside in or be transitioning to an HCBS-compliant setting (non-institutionalized). The FS Waiver is administered by BDS.

e. Community Integration and Habilitation (CIH) Waiver - serves Medicaid-eligible individuals with intellectual and developmental disabilities diagnosed prior to the age of 22 who reside in, or are transitioning, to an HCBS-compliant setting (non-institutionalized). To be enrolled in the CIH Waiver, individuals must meet ICF/IID level of care. The CIH Waiver is administered by BDS.

1.2.2 Non-Waiver Programs

The Community Supports IT Systems outlined in this SOW are also used to support delivery of both non-Waiver programs and non-Medicaid Waiver services. These programs are defined as programs supporting older adults and individuals with disabilities that are not funded by a Medicaid waiver. Rather, these “non-waiver” programs may provide either Medicaid State Plan services or be funded through alternative, non-Medicaid sources, such as the Social Services Block Grant (SSBG).

As a note, the BDS Portal is undergoing a transition of duties and will begin supporting non-waiver IT services in February 2026. Non-waiver programs supported by the suite of Community Supports IT Systems include:

a. Aging and Disability Resource Center (ADRC): ADRCs help older adults, people with disabilities, and their families access long-term services and supports (LTSS) by providing information, guidance, and assistance with navigating public and private programs for individuals of all income levels including pre-waiver activities and No Wrong Door.

b. Community and Home Options to Institutional Care for the Elderly and

Disabled (CHOICE): The CHOICE program, which is State-funded and administered through Area Agencies on Aging (AAA), provides services for aging individuals. CHOICE offers HCBS to individuals who are at least

60 years of age or have a disability. There are no income limits for the

CHOICE program; however, there is a cost-sharing formula, and applicants with higher incomes may be asked to pay for a portion of their services. CHOICE funds may not be used if other funding such as

Medicare or Medicaid is available to meet the individual’s needs. The delivery of CHOICE is supported by interRAI and the Resident

Assessment Instrument (RAI).

c. Intermediate Care Facility for the Individuals with Intellectual Disabilities

(ICF/IID) Program: The ICF/IID program provides individuals with intellectual disabilities institutional based services, inclusive of Supervised

Group Living (SGL), that offer care and rehabilitation services. Facilities are licensed by BDS and certified through the Indiana Department of

Health. The delivery of ICF/IID services is supported by the DART system.

d. Money Follows the Person (MFP): MFP is a funding source that assists individuals in returning from a qualifying institution to their community. It is funded through a grant from CMS and State funds. Individuals funded by

MFP are receiving the same services as Medicaid Waiver recipients and ultimately transition from the MFP funding source to a Medicaid waiver.

The delivery of MFP is supported by Assessment Pro, IMP, DART system and BDS Portal depending on the individual’s ultimate waiver enrollment.

e. Older Americans Act programs (e.g. Title III B, Title III C1, Title III C2, Title III D, Title III E): The Older Americans Act (OAA) provides community-based support to individuals over the age of 60 and family caregivers. Examples of services offered by OAA include attendant care, case management, respite, and transportation. The delivery of OAA programs is supported by interRAI and the RAI.

f. State Funded Services: State funded services provide a limited number of services to individuals with I/DD in Nursing Facilities and community-based settings who are not eligible for Medicaid or HCBS.

g. Social Services Block Grants (SSBG): SSBG support low-income older adults and individuals with disabilities. SSBG has income guidelines, and individuals must have a documented need to receive services. SSBG may not be used when other funding such as Medicaid or Medicare is available to support the individual’s need.

1.3 Systems Overview

In collaboration with the State, the following systems are managed across two vendors. The functions and purpose of each system included in the suite of Community Supports IT

Systems are defined below. Unless otherwise noted, IOT will host all systems, and there is no anticipated change in hosting structure. IOT will be responsible for infrastructure management, infrastructure monitoring, network access management, business continuity, and disaster recovery for the suite of Community Supports IT Systems, with any requested assistance from the Contractor. The Contractor shall be responsible for the requirements listed in Section 2.0 - Maintenance and Operations and Section 3.0 - System DDI and

Enhancements, which broadly include solution maintenance, access management, defect and incident management, integration and interfaces, service desk, and software deployment. For more technical information for each system, including sizing and interfaces, please see Attachment L - Bidders’ Library.

1.3.1 Bureau of Disabilities Services (BDS) Portal

The BDS Portal is a recent solution that captures Waiver and non-Waiver functionality for case managers and waiver service providers via a web-based system. All significant functions in support of CIH and FS waiver participants are completed in the BDS Portal.

This includes service planning, waiver management, provider referrals, provider management, case management, documentation, and pre-waiver activities among others. ICF/IID Providers for the CIH and FS Waivers maintain provider profiles in the

BDS Portal and have the ability to add and deactivate services/counties, update profiles, request and deactivate privileges, and facilitate referrals. A round of enhancements in

July 2025 incorporated functionality for the H&W and TBI Waivers into existing BDS technology systems, so the BDS Portal currently supports all of DDARS’s active HCBS

Waivers. Additionally, there is functionality in the BDS Portal that supports both

PathWays and MFP. The BDS Portal continues to be updated over time through ongoing, planned releases.

1.3.2 Bureau of Disabilities Services (BDS) Gateway

In early 2021, BDS launched the BDS Gateway as an online avenue for individuals with disabilities and their families to apply for BDS I/DD (Individuals with Intellectual and

Developmental Disabilities) supports and services. In January 2025, the BDS Gateway was enhanced to allow individuals applying for BDS I/DD supports and services to have the ability to set up an Access Indiana account, save their application prior to submission and return to it later, as well as manage documents after submission of the application.

1.3.3 Developmental Disabilities Automated Resource Tool (DART)

The primary components of DART include a mortality review module, interfaces with

IFUR, SGL functionality, provider billing, and ICF/ID. These systems support both

Medicaid Waiver and non-Waiver programs, such as SGL, ICF/ID, and MFP.

1.3.4 Division of Disability, Aging, and Rehabilitative Services (DDARS) Provider

Site

FSSA’s DDARS Provider Site has web tools that are utilized by both individuals and providers. The site allows for individual lookups and offers a portal for providers to submit claims for State-funded services and billing information. The DDARS Provider

Site includes multiple web tools and components, including a Document Library, Resource Determination Tool, and an archival Level of Care Screening Instrument, although end users may access those tools via the Portal for a more streamlined experience.

1.3.5 Incident and Follow-up Reporting (IFUR)

IFUR is the front-end website for OMPP PathWays and DDARS and interfaces with

DART and PIP. IFUR is used for all Medicaid Waiver and non-Waiver programs for BDS, OMPP, and the Bureau for Better Aging (BBA).

1.3.6 interRAI Tool Functionality

The interRAI organization is a collaborative network of researchers and practitioners that develop assessment instruments, which establish assessment protocols, case-mix algorithms, and quality indicators for persons who are disabled or medically complex.

Each assessment provides information to inform clinical decision-making and care planning. The RAI stands for Resident Assessment Instrument.

The State of Indiana requires the use of specific interRAI assessments to establish functional eligibility and support care planning for individuals seeking both waiver and non-waiver programs supported by BDS, BBA, and OMPP. Qualified entities, such as

AAAs and case managers, access interRAI toolsets through the suite of Community

Supports IT Systems that the Contractor will support. In order to continue to offer interRAI tools as part of system functionality, the Contractor will be responsible for becoming a Registered Publisher for the interRAI organization and working with DDARS to implement and support the functioning of such proprietary assessment tools. As each interRAI tool is updated, the Contractor will be responsible for supporting system updates to maintain user access and ensure overall compliance with interRAI organization requirements. DDARS currently utilizes the following assessments from interRAI:

a. Home Care (HC) v9.1.2 – evaluates the needs, strengths, and preferences of persons in home and community care settings. It facilitates referrals and focuses on the person’s functioning and quality of life. The HC can be used to assess persons with chronic needs for care as well as those with post-acute care needs.

b. Child and Youth Pediatric Home Care (PEDS-HC) v9.2.0 – evaluates children with special health care challenges. It assesses the care needs of children and youth (ages 4 to 20 years) who are seeking or receiving LTSS.

c. Early Years (EY) v10.0 – evaluates young children with developmental and mental health concerns to support comprehensive care planning, outcome measurement, quality indicators, and case mix classification to estimate relative resource intensity.

d. Intellectual Disabilities (ID) – assesses the needs, strengths, and preferences of persons with intellectual or developmental disabilities. It is intended to be used with adults of all ages in community, residential, and institutional settings.

e. Child and Youth Mental Health and Developmental Disability (ChYMH-DD) – is for children and youth with intellectual or developmental disabilities in community and mental health care settings. The Adolescent Supplement is completed for youth 12+ years of age.

1.3.7 Integrated Management Portal (IMP)

IMP’s primary function enables BDS and OMPP staff to add individuals to a Waiting List for the PathWays Waiver and H&W Waiver. A BDS or OMPP staff person has the ability to generate an Invitation Letter and automatically update the Waiting List to let clients know they have been invited to join their appropriate waiver. Invitations are given one of four priorities provided by FSSA. IMP updates individual records on the Waiting List based upon their date of birth. If a person will turn 60 in a given month, the IMP will move their record from the H&W Waiting List to the PathWays Waiting List on the 1st of that month. Please note, the IMP may require enhancements in the future as part of this scope of services to manage additional Waiting Lists for other Waivers, if introduced.

1.3.8 PathWays Incident Processing (PIP)

PIP is the incident reporting system for the PathWays Waiver. The system is built on

Microsoft .net-Core v.6.0 and is utilized by OMPP to process incidents for its HCBS waiver program. PathWays incidents are entered into IFUR (front-end incident reporting for DDARS BDS, BBA, and PathWays waiver) and processed through PIP. PIP may be consolidated in the future, in which case the Contractor shall remain responsible for its functionality as part of M&O for the respective system, depending on future State decisions.

1.3.9 Systems Overview

The table below outlines the technical infrastructure for each system.

System Backend UI

DART SQL Server, IOT / on-premise virtual

Visual Basic 6

DART-IR SQL Server, IOT / on-premise virtual

.Net Framework 4.8

DDRS

Provider site

SQL Server, IOT / on-premise virtual

.Net Framework 4.7

IFUR SQL Server, IOT / on-premise virtual

.Net 6.0

IMP SQL Server, IOT / on-premise virtual

.Net 6.0

PIP SQL Server, IOT / on-premise virtual

.Net 6.0 interRAI – Non-

Waiver (BBA)

SQL Server, Azure .Net 10.0.6, Angular

20.3.25 interRAI – ICF/IID

(BDS)

SQL Server, IOT / on-premise virtual

.Net 9.0.2, Angular 18.2.0

BDS Portal SQL Server / on-premise virtual

.Net 4.8

BDS Gateway SQL Server / on-premise virtual

.Net 8

1.3.10 Anticipated Enhancements

BDS currently oversees four separate HCBS Waivers and has been making a series of updates to support better alignment across the waiver programs. Instead of redesigning the current waivers, BDS plans to create entirely new waivers that more effectively serve clients across all disabilities and levels of care. This ambitious Waiver Reset will be completed in 2027 and will give BDS the opportunity to clear the slate and create a system that provides the best and most appropriate support for people with disabilities in

Indiana.

The suite of Community Supports IT Systems is part of the Waiver Reset work, and the

Contractor shall be responsible for making system enhancements based on Waiver

Reset policy changes, at the direction of the State. More broadly, the Contractor will be responsible for systems enhancements throughout the life of the Contract that improve functionality, usability, and data integrity. Key priorities for current system functionality and future enhancements include:

a. Reporting and analytics: Generate flexible, configurable, and easily accessible reporting tools

b. Training and knowledge transfer: Support training for systems and technical components

c. Data quality and integration: Ensure clean, validated data that can interface and transfer across State and vendor systems

d. Access and security management: Implement strong user controls and permission management

e. Audit and compliance: Maintain a detailed audit log to track system changes

f. User support and guidance: Incorporate on-screen help features and establish mechanisms for responsive user support

1.3.11 System Consolidation Background

BDS’ Systems Consolidation Project aims to establish a singular enterprise solution for data to be used by BDS Central/District Staff, Case Management Organizations

(“CMOs”), and Providers. BDS began system consolidation efforts in 2019 with the following objectives:

a. Reduce the number of case management systems in use by BDS

b. Continue to emphasize and systematically improve the Individual Support

Team’s (IST’s) ability to facilitate person-centered planning and support

c. Increase transparency amongst all IST members

d. Include and increase automation (for efficiency) when and where possible

(while maintaining appropriate integrity and oversight by BDS)

e. Improve data collection

f. Increase tracking and traceability of requests while processing through certain workflows

The Community Supports IT Systems Contractor will support further consolidation of legacy systems into the BDS Portal and Gateway. Systems with further consolidation needs include DART, IFUR, IMP, and PIP. The Care Management for Social Services

(CaMSS) consolidation into the BDS Portal will be complete prior to the beginning of the

Community Supports IT Systems contract.

2.0 Maintenance and Operations (M&O) Services Responsibilities

The Contractor shall provide M&O services for the following suite of Community Supports IT

Systems which includes DART, DDARS Provider Site, IMP, IFUR, interRAI tools, BDS Portal, BDS Gateway, and PIP through the contract term (except where explicitly denoted otherwise or in the case that a system is fully consolidated into BDS Portal or BDS Gateway). As a part of the

M&O responsibilities, the Contractor shall provide the services described in Section 2.1 through

2.6.

2.1 General Systems Support

As part of general systems support for the suite of Community Supports IT Systems, the

Contractor shall be responsible for the following activities and services:

a. Develop, execute, and manage processes and procedures required to provide technical and functional support for the Community Supports IT Systems

b. Address all questions and reported problems related to the technical and functional operation of the systems

c. Perform defect resolution of all defects discovered and prioritized by the defined processes

d. Support any requests from IOT to assist with resolving issues affecting the network or servers utilized for business and program functions, as applicable

e. Make routine maintenance changes in the ordinary course of the Contractor’s provision of services defined within the scope of this contract (e.g., changes to operating procedures, schedules, equipment configurations) at no additional cost to the State, including updating system documentation to reflect the latest changes on a monthly basis

f. Keep system requirements and user stories updated to reflect the latest changes as part of enhancement execution

g. Conduct continuous monitoring and analysis of system performance to determine if actions are required to meet or improve on Service Level Agreements (SLAs)

h. Provide sufficient resource availability: User support will be requested via the State’s

JIRA web portal, which is provided and maintained by FSSA

i. A qualified technician shall respond within the timeframes listed in Section

10.1 (Service Level Overviews) based upon the request’s function type and priority code.

ii. Qualified incident support from 8:00 AM to 5:00 PM Eastern Time, Monday through Friday. Support shall adhere to the timeframes listed in

Section 10.1 (Service Level Overviews) based upon the request’s function type and priority code. Note: All incidents will be reported via the web portal.

i. Implement hot fixes, updates, and changes mandated by the State, IOT, or the software manufacturer to hardware and software

j. Interface with IOT for assistance and provide information to IOT as needed

k. Provide disaster recovery and business continuity support for the Community

Supports IT Systems in coordination with the State. Please see the IOT Policy for

Continuity of Operation Plan (COOP)/Business Continuity (BC) at this link for more information: https://www.in.gov/iot/files/Continuity-of-Operation-Plan-

Business-Continuity.pdf

l. Provide ad hoc reporting as requested by the State

m. Provide standard, recurring data requests and reports, such as slot counts

n. Prevent data loss and inaccuracies

o. Report data loss and accuracy problems

p. Comply with State and Federal security requirements

q. Report system security concerns, including notification in the event of discovery of Security Incidents in alignment with Contract Clause 12 (Attachment B)

r. Report missed requirements

s. Integrate with all applicable State of Indiana systems as required to maintain business

t. The State has robust and comprehensive data transmission standards operating enterprise-wide. IOT established and maintains these standards, which support

IOT’s data exchange and API-led strategies. The Contractor’s solution must support the State’s standard API and file transfer methods to facilitate secure data transmission. The State’s standardized data transmission technologies are

MuleSoft API Management and GoAnywhere Managed File Transfer (MFT). See https://www.in.gov/iot/policies-procedures-and-standards/applications-standards/

u. Maintenance and support for all applicable databases

v. Conduct scheduled task maintenance and code stabilization

w. Implement system modifications/changes that are less than 80 hours of development time. Please note that standard SDLC (Section 3.1.6) applies to modifications (under 80 hours) made as part of M&O.

https://www.in.gov/iot/files/Continuity-of-Operation-Plan-Business-Continuity.pdf https://www.in.gov/iot/files/Continuity-of-Operation-Plan-Business-Continuity.pdf https://www.in.gov/iot/policies-procedures-and-standards/applications-standards/

2.2 Help Desk Support

The Help Desk utilizes a three-tier approach for support, troubleshooting, fielding questions, and product fixes. The State will be responsible for performing Tier 1 functions for all system components. In some instances, State staff may also perform Tier 2 functions; however, the

Contractor shall be responsible for handling Tier 2 and Tier 3 unless otherwise indicated by the State. In all cases, the Contractor must coordinate with State staff to ensure all tickets assigned to the Contractor are addressed. As assigned, the Contractor will be responsible for providing the end user with the status of their ticket on a regular basis until it is closed.

The Contractor is responsible for addressing all data changes, system defects, or enhancements assigned to them resulting from a help desk ticket according to a schedule agreed upon by the State. The help desk functions are covered by the Community Supports

IT Systems M&O monthly fees.

2.2.1 Tier 1 Support Services (FSSA)

The State shall be responsible for staffing a team to serve as the first point of contact for reporting and resolution, which will include initial logging of incidents into JIRA and initial triage. Tier 1 is responsible for diagnosis, resolution, and escalation of all incidents as needed. The State Tier 1 team will coordinate activities and communication between Tier 2/3 support and end users. Specific State Tier 1 responsibilities include the following:

a. Initial reception and recording of the user or tester reported incidents

(ticket)

b. Logging and categorization of the incident with regards to priority and effect on the system

c. Oversight of user rights within the system

d. Resolution of issues that result from the need for training

e. Determination of which incidents need to be transferred to Tier 2 or 3

f. Transfer to Tier 2 or Tier 3 support for Contractor triage and resolution

2.2.2 Tier 2 & 3 Support Services (Contractor)

The Contractor shall be responsible for staffing a team to address Tier 2 & 3 inquiries, including when assigned to the Contractor by the State, which must include a named Technical Lead and a named dedicated Project Manager as defined in Section 6.2. The Contractor’s staffing approach must ensure adequate support for each division, including whether multiple resources are needed for specific roles. Any policy-related inquiries shall be directed to the relevant business unit. The Contractor shall not respond to any policy related questions.

The Contractor will be responsible for the following:

a. Provide a single point of contact for escalation

b. Maintain a knowledge base, which may include FAQs and/or call scripts, for Tier 1 support to conduct initial ticket resolution and determination

c. Modify solution as described in Section 2.0 (Maintenance and Operations

(M&O) Services Responsibilities)

d. Administer weekly incident releases (bugs) and feature releases to all environments

e. Coordinate the application of hot fixes to the suite of Community

Supports IT Systems and all environments in coordination with IOT

f. Test all configuration changes and hot fixes

g. Conduct architectural review of all configuration changes to business rules and integrations that are performed by Tier 1 or Tier 2 teams.

h. Ensure impacts on other system components are considered during the defect resolution processes

i. Support independent assessment of the system for CMS certification as needed

j. Coordinate with third party vendors as needed

k. Open and facilitate service tickets on behalf of FSSA with third party vendors

l. Support IOT with items that relate to system performance and uptime

m. Support interfaces with other FSSA systems

The above responsibilities include providing the State with architectural and design resources to address inquiries when assigned to the Contractor by the State.

2.2.3 interRAI Tool Support

The Contractor will provide help desk support (Tier 2 and Tier 3) for interRAI toolsets’ system functionality, implement errata changes to the tools’ functionality as requested and approved by the State, assist in troubleshooting issues with the interaction between interRAI and the Community Supports IT Systems, maintain the interRAI in accordance with the requirements of the interRAI vendor (see Section

1.3.6), and work with the State to provide interRAI data as needed to interRAI organization, Enterprise Data Warehouse (EDW), and relevant stakeholders.

2.2.4 Consolidation - Data Assistance

The Contractor shall provide additional assistance to State help desk staff, as needed, to support data exchange as legacy systems are integrated into BDS Portal and Gateway as part of the State's System Consolidation Plan. See Section 3.1.7 for other requirements around Data Migration.

2.3 Incident and Problem Management

The Contractor will lead the Incident and Problem Management processes for the reported or proactively identified Community Supports IT Systems application-related incidents until a definitive root cause is identified. As a part of the Incident and Problem Management responsibilities for the Community Supports IT Systems, the Contractor shall:

a. Perform tasks in a manner consistent with minimizing and avoiding problems

b. Monitor events and system performance with the goal of taking proactive actions to avoid problems

c. Prioritize and communicate tasks associated with incidents and service requests

d. Notify the State of unplanned system downtime immediately upon, and at most within

1 hour of confirmation. If the downtime is anticipated beforehand, the Contractor shall notify the State at least 72 hours prior to the planned downtime

e. Maintain system uptime described in Section 10.2.1 (Maintenance and Operations

Services Service Levels – System Uptime)

f. Notify the Chief Information Officer, or designees, of system performance or functionality issues (excluding those that result in system downtime) within one (1) business day of occurrence. The Contractor shall describe the issue, what is being done to remedy the issue, and when the issue is expected to be fixed

g. Meet with the State when requested about any specific incident while resolution is being reached to share information or expedite resolution.

2.3.1 Issue and Incident Resolution Plan

The Contractor shall develop an Issue Resolution Plan for State approval after the commencement of this Contract at a schedule agreed upon by the State. This plan will provide a standard process that will be used to identify, track, and resolve issues which may arise between Contractor and State in the performance of duties under the Contract. The plan will also include a section on risk management covering how risks will be mitigated to avoid issues from occurring. Such plan shall include:

a. Any troubleshooting tools and techniques that will diagnose issues with networks, services, equipment, software, and data.

b. Standard processes for handling system defects and issues, in alignment with the broader SDLC practices. Processes must cover the Contractor’s proposed approach to identifying and triaging issues, conducting root cause analysis, addressing issues, conducting testing, coordinating production deployment, and closing out issues.

c. The approach and metrics to measure the success of issue resolution efforts.

d. FSSA should approve all issue resolution plans and procedures prior to implementation.

2.3.2 Priority Codes for Incident and Problem Management

The table below provides a description of five priority codes. The priority code for each incident will be assigned by the State but may be adjusted based on discussions with the Contractor. “Defect” and “bug” may be used interchangeably.

The Contractor shall be responsible for resolving defects/bugs based on their assigned Priority Levels. Priority codes 1, 2, and 3 are generally considered system defects. Priority code 4 is generally considered bug fixes. Priority code 5 is considered minor or cosmetic fixes. Please note, these priority codes also apply to defects identified during testing of system enhancements prior to implementation.

2.3.3 Incident Phases

Based on the above priority codes, the Contractor will be responsible for resolving issues according to the established incident phases defined below. The State and

Contractor will track the timeliness of the four (4) incident phases as part of ongoing performance management. See Section 10.2 for required response times by priority code and incident phase.

2.4 Access Management

The Contractor shall develop an Access Management Plan for State approval after the commencement of the Contract at a schedule agreed upon by the State that describes the

Contractor’s approach and methodology for access management including all processes, Priority Code

(JIRA System) Definition

1 - Resolve

Immediately

This is reserved specifically for production defects when there is a critical issue that brings the system down.

2 - Give High

Attention

When multiple interconnected critical business functions or solution components do not work as required or are blocked by a single issue.

3 - Major When a critical business function or solution component does not work as required.

4 - Normal When there is restricted functional capability, but processing can continue.

5 - Low When there are minor or cosmetic issues.

Incident Phase Definition

Initial Response

Time taken from when the incident is originally reported by

FSSA Help Desk to when the Contractor acknowledges the incident by updating status in the State’s designated ticket tracking system.

Estimation

Response

Time taken from when the incident is originally reported by

FSSA Help Desk to when the Contractor logs the estimated response time into the State’s designated ticket tracking system.

Incident/Action

Updates

Frequency of status updates logged into the State’s designated ticket tracking system if there is an update to the incident.

Incident/Action

Resolution

Completion

Time taken from when the incident is originally reported by

FSSA Help desk to when the Contractor resolves the incident.

Resolution is defined as ready for testing for Average and Minor

Incidents. System downtime, Critical, and Major incidents will be considered resolved once the system and/or functionality is operating as intended again. The Contractor shall not be held responsible for timeliness of resolution completion when a delay is solely attributable to the State or its vendors.

resources, and responsibilities for each system within the suite of Community Supports IT

Systems. At a minimum, the Contractor must be able to assist in the definition of user roles and security configurations, specifically the creation of new roles and monitoring of user access rights in relation to internal requirements. The Contractor shall provide knowledge and resources to enable designated State staff to directly manage user roles and accounts for applicable systems.

The Contractor must support interfacing, as needed, with other State access management systems, such as Access Indiana. At the time of this RFP, only BDS Gateway interfaces with

Access Indiana.

The proposed solution is expected to integrate with Access Indiana, the State’s single sign-on authentication mechanism and Identity Provider, where feasible and upon the State’s direction. See https://www.in.gov/inwp/applications/authentication/ for benefits of standard authentication, integration strategy, and process. The Contractor shall plan, design, and implement such integration where applicable and identify any constraints or timelines required to enable this integration.

2.5 Application Management

The Contractor shall plan and execute tasks required to ensure the Community

Supports IT Systems stay relevant and usable without any interruptions or degraded services. This includes resolution of functional issues, application of hot fixes, and planning/execution of enhancements and upgrades. The Contractor shall make all product releases and upgrades, such as predeveloped software packages, available to the State at no additional cost. At least annually, the Contractor shall communicate to the State any available information on the product roadmap, planned upgrades and enhancements and seek State input where practical. Federally mandated changes shall be included in the releases and upgrades as part of support and maintenance and shall be covered by the standard M&O fees. If significant changes

(defined as changes requiring eighty (80) or more hours of work) are required as a result of federal mandates, these changes will be considered enhancements and billed using the

Enhancements Hours Pool.

2.6 Maintenance and Operations Plan

The Contractor shall develop a Maintenance and Operations (M&O) Plan that describes the

Contractor’s approach and methodology for M&O, including all processes, resources, any and all updates and required applications/tools following Contract commencement at a schedule agreed upon by the State. The M&O Plan must address ongoing operations services, including all processes, resources, and any required applications or tools. The

M&O Plan must address all tasks identified in Section 2 (Community Supports IT Systems -

Maintenance and Operations Services Responsibilities) necessary to operate the required suite of Community Supports IT Systems in accordance with any applicable federal and

State policy requirements.

https://www.in.gov/inwp/applications/authentication/

The M&O Plan shall describe and provide the type, roles, and number of staff associated with all M&O activities and provide a description of responsibilities for Vital, non

Vital and supporting staff assigned during the M&O period. The plan shall also describe the approach to reporting on all M&O activities, in alignment with Section 4.0 - Reporting.

2.7 M&O Following Individual System Component Consolidation & Sunset

The suite of Community Supports IT Systems includes several legacy and ancillary systems that the State intends to consolidate over time into the BDS Portal and Gateway systems.

The Contractor shall be responsible for M&O for all Community Supports IT Systems and components following the Initial Transition Period until such time as systems or their components are consolidated, and the State has agreed in writing the component is considered sunset. Consolidation work will be governed by the enhancements process (see

Section 3).

In the event of system consolidation, the Contractor shall remain responsible for any functionality and components that have been consolidated into another Community

Supports IT Systems for which the Contractor provides M&O. The State is interested in understanding what efficiencies and cost savings the Contractor anticipates in the delivery of M&O across the suite of Community Supports IT Systems as individual, legacy system components are consolidated into more modern systems. The exact timing and order for system consolidation work is yet to be determined; however, the State has identified the following potential consolidation scenarios, for which Respondents should provide information on any anticipated efficiencies, such as reduced FTE needs, as part of their

Technical Proposal (see Attachment F):

a. Scenario 1 - DART consolidation into BDS Portal and Gateway

b. Scenario 2 - DDARS Provider Site consolidation into BDS Portal and Gateway

c. Scenario 3 - IMP consolidation into BDS Portal and Gateway

The State recognizes that the above scenarios do not represent all possible consolidation approaches, including partial consolidation of some functionality into BDS Portal and

Gateway. The State and Contractor shall revisit these scenarios, estimated efficiencies, and cost savings during the Contract Term as the need arises.

In Attachment D - Cost Proposal, Respondents must indicate cost savings as a percentage impact that they anticipate each scenario would independently have on overall monthly

M&O fees. Cost saving percentages should be reflective of overall changes that a consolidation scenario has on M&O activities, including both the sunset of legacy system(s)

(e.g., reduction in effort) and any expansion of functionality to the integrated system (e.g., increase in effort). Please note, the savings information captured in Attachment D - Cost

Proposal shall not be used for evaluation purposes.

3.0 System DDI and Enhancement Services (General Responsibilities)

3.1 System Enhancement Services Responsibilities

The Contractor shall provide enhancements to Community Supports IT Systems as determined necessary by the FSSA Change Review Board using funds from the applicable portion of the Enhancement budget. The Contractor will be expected to provide detailed reports on the use of enhancement hours and funds, including YTD tracking of approved enhancement expenditures for each division against the Enhancement Pool. Enhancements are defined as changes requiring 80 or more hours of development work. Enhancements are system changes that exceed routine maintenance and operations and are necessary to introduce new functionality, modify existing workflows, or support new State initiatives.

Enhancements may include new modules, feature additions, significant code updates, substantial system modifications, or the consolidation of components of one system into another (e.g., IFUR into BDS Portal). Changes or updates to Community Supports IT

Systems that require fewer than 80 hours of work will be handled as part of regular

Maintenance and Operations, in alignment with the requirements of Section 2.0, using funds from the M&O budget. The FSSA Change Review Board shall be responsible for collecting and prioritizing enhancement requests. The FSSA Application Manager shall communicate enhancement requests to the Contractor and work with the Contractor in prioritizing and planning using a service portfolio management strategy.

At the time of this RFP, not all details have been analyzed and approved by the State.

Please see Section 1.3.9 for anticipated enhancements and system consolidation plans. If major changes are needed; these changes will be addressed if and when functionality and/or use of the Community Supports IT Systems is expanded or identified. The State will determine if an amendment is needed or if additional needs can be met using hours from an alternate category. Any costs for additional functionality will be delineated with hourly rates that do not exceed the contractual hourly rates in alignment with Section 9.0

Payments and Invoicing.

Customizations require written approval in alignment with the Enhancements approval process as described in 3.1.4, 3.1.5, and 7.4 below and must include a configuration‑first analysis, functional specification, technical design, impact analysis (maintenance, upgrade compatibility, security, performance, accessibility, TCO), test plan, rollback plan, schedule impact, and itemized pricing. Approved customizations must meet State security standards and be upgrade compatible or provide a documented migration path. The State receives source code, developer/user documentation, and a perpetual royalty‑free license for any custom code. The Contractor will consider approved customizations for incorporation into the core solution going forward. As a part of the System Enhancement Services responsibilities, the Contractor shall provide the following services:

3.1.1 Technical Guidance for Modifications Implemented by State Staff

FSSA reserves the right to complete select minor modifications within the

Community Supports IT Systems as staffing levels allow. In instances where this option is exercised, the Contractor shall be involved in the enhancement planning and technical guidance. All work performed by FSSA will follow the agreed upon

SDLC processes. The Contractor will not be held to the SLAs and warranty for items completed by non-Contractor resources, such as State staff and/or its vendors’ staff.

3.1.2 Implementation of System Enhancements

The Contractor shall provide design, development, and implementation services for system enhancements not being implemented by State staff. Please see Section

1.3.9 for the currently anticipated enhancements. Additional enhancements may be identified by the State, including those that may arise from help desk incidents or as a result of direction by legislation and/or other authorities, such as policy changes and rate changes. As the enhancements’ rollout schedule may change over time, the

Contractor shall work with FSSA on a regular basis to plan enhancements and be flexible about adjusting plans based on changes to enhancements’ timing and scope.

System enhancements shall be billed using the contractual hourly rate in alignment with Section 9.0 - Payments and Invoicing. Documentation shall be provided with the

Contractor’s invoice accounting for the hours being invoiced for all Community

Supports IT Systems enhancements. If services are to be provided in exchange for fixed or not-to-exceed compensation, the Contractor is solely responsible for any costs in excess of the specified compensation.

3.1.3 Enhancements Hours Pool

The Contractor shall provide a capped Enhancements Hours Pool each year. At the time of this procurement, the State estimates the Enhancement Hours Pool to be

52,200 hours. The State reserves the right to adjust the number of hours in the

Enhancement Hours Pool throughout the course of the Contract to meet the State’s needs.

Enhancement Pool hours include project management, requirements gathering and validation, design, development, testing, and implementation needed for enhancements. The State is not required to use up the hours and dollars allocated for the Enhancements Hours Pool for each year.