rfp # 34501-13219: eligibility and benefits …...tdhs feasibility study – business process...

TDHS Feasibility Study – Business Process Analysis Report

RFP # 34501-13219: Eligibility and Benefits Management System

Appendix 4 (Excerpts from 2017 Business Process Analysis)

Note: This Business Process Analysis (BPA) Report was developed based on the feasibility study that included the workflows and use cases depicting the desired TDHS model of practice. Workflows and use cases specific to Child Support and Child Care program areas are not applicable for this scope of services and have been removed from this file.

P a g e | 3


Enterprise System Modernization Feasibility Study

Business Process Analysis (RFP Section — A.8 Business Analysis Approach and Requirements Definition)

Table of Contents ............................................................................................................ 3

Table of Figures .............................................................................................................. 6

2.0 Workflow Notations ................................................................................................. 9

2.1 Use Case Overview ............................................................................................... 10

2.1.1 Use Case Goals .......................................................................................... 10

2.1.2 Sections of a Use Case ............................................................................... 10

3.0 Workflow and Use Case Overview ....................................................................... 11

3.1 Workflow Organization and Listing ...................................................................... 11

3.2 Use Case Organization and Listing ..................................................................... 13

3.2.1 Use Case Actors ......................................................................................... 36

4.0 Workflows and Use Cases ................................................................................... 39

4.1 Family Assistance .................................................................................................. 39

4.1.1 Overview Workflow O1: Family Assistance Intake and Eligibility Determination ............................................................................................. 39

4.1.2 Overview Workflow O2: Family Assistance Ongoing Benefits Management 40

4.1.3 Workflow WF01: Complete Self-Service Pre-Screening .............................. 41

4.1.4 Workflow WF02: Apply for Programs / Benefits Online ................................ 41

4.1.5 Workflow WF03: Apply for Programs / Benefits In-Person or By Paper ....... 42

P a g e | 4


4.1.6 Workflow WF04: Process Application .......................................................... 43

4.1.7 Workflow WF05: Conduct Eligibility Interview .............................................. 44

4.1.8 Workflow WF06: Process Eligibility ............................................................. 45

4.1.9 Workflow WF07: Complete Eligibility Determination .................................... 46

4.1.10 Workflow WF08: Issue Benefits................................................................... 47

4.1.11 Workflow WF09: Conduct Medical Evaluation of Incapacity ........................ 48

4.1.12 Workflow WF10: Submit Self-Reported Change .......................................... 49

4.1.13 Workflow WF11: Process Customer Change .............................................. 50

4.1.14 Workflow WF12: Conduct Redetermination ................................................. 51

4.1.15 Workflow WF13: Complete Redetermination Online .................................... 52

4.1.16 Workflow WF14: Complete Redetermination In-Person or By Paper ........... 53

4.1.17 Use Case 01: Complete Self-Service Pre-Screening ................................... 54

4.1.18 Use Case 02: Apply for Programs ............................................................... 57

4.1.19 Use Case 03: Process Application .............................................................. 64

4.1.20 Use Case 04: Conduct Eligibility Interview .................................................. 68

4.1.21 Use Case 05: Process Eligibility .................................................................. 72

4.1.22 Use Case 06: Complete Eligibility Determination ......................................... 75

4.1.23 Use Case 07: Issue Benefits ....................................................................... 79

4.1.24 Use Case 08: Conduct Medical / Mental Health Evaluation of Incapacity .... 82

4.1.25 Use Case 09: Submit Self-Reported Change .............................................. 86

4.1.26 Use Case 10: Process Customer Change ................................................... 89

4.1.27 Use Case 11: Complete Redetermination Application ................................. 93

4.4.26 Appeals & Hearings .................................................................................. 97

4.5.1 Overview Workflow O6: Appeals & Hearings and Program Integrity ............ 97

4.5.2 Workflow WF35: File Appeal Request ......................................................... 98

4.5.3 Workflow WF36: Conduct Hearing .............................................................. 99

4.5.4 Workflow WF37: Issue Appeal Decision / Order ........................................ 100

4.5.5 Use Case 32: File Appeal Request ........................................................... 190

4.5.6 Use Case 33: Conduct Hearing ................................................................. 196

4.5.7 Use Case 34: Issue Appeal Decision / Order ............................................ 201

4.6 Program Integrity ................................................................................................. 208

4.6.1 Workflow WF38: Program Integrity – Referral Identification ....................... 208

4.6.2 Workflow WF39: Program Integrity – Establish Recovery .......................... 209

4.6.3 Workflow WF40: Program Integrity – Benefit Recovery ............................. 210

4.6.4 Use Case 35: Program Integrity – Referral Identification ........................... 211

4.6.5 Use Case 36: Program Integrity – Establish Recovery .............................. 216

4.6.6 Use Case 37: Program Integrity – Benefit Recovery .................................. 221

4.7 Shared Capabilities ............................................................................................. 224

4.7.1 Overview Workflow O7: Shared Capabilities ............................................. 224

4.7.2 Workflow WF41: Schedule an Appointment .............................................. 225

P a g e | 5


4.7.3 Workflow WF42: Process Customer Communication ................................ 226

4.7.4 Workflow WF43: Process Paper Documentation ....................................... 227

4.7.5 Workflow WF44: Manage Referral ............................................................ 228

4.7.6 Workflow WF45: Search & Lookup Customer ........................................... 229

4.7.7 Workflow WF46: View Alerts ..................................................................... 230

4.7.8 Workflow WF47: Send and Receive Secure Messages ............................. 231

4.7.9 Workflow WF48: Contact TDHS Service Center ........................................ 232

4.7.10 Workflow WF49: Manage Caseloads ........................................................ 233

4.7.11 Workflow WF50: Access and View Standard & Dashboard Reports .......... 234

4.7.12 Workflow WF51: Create Ad Hoc Queries and Reports .............................. 235

4.7.13 Use Case 38: Schedule an Appointment ................................................... 236

4.7.14 Use Case 39: Receive Customer Communication ..................................... 240

4.7.15 Use Case 40: Process Paper Documentation ........................................... 242

4.7.16 Use Case 41: Manage Referral ................................................................. 245

4.7.17 Use Case 42: Customer Search & Lookup ................................................ 254

4.7.18 Use Case 43: View Alerts ......................................................................... 257

4.7.19 Use Case 44: Send and Receive Secure Messages ................................. 260

4.7.20 Use Case 45: Contact TDHS Service Center ............................................ 263

4.7.21 Use Case 46: Manage Case Load ............................................................ 268

4.7.22 Use Case 47: Access and View Dashboards ............................................ 271

4.7.23 Use Case 48: Access and View Standard or Parameter-Based Reports ... 275

4.7.24 Use Case 49: Create Ad Hoc Queries and Reports ................................... 277

5.0 Additional Requirements.................................................................................... 279

P a g e | 6


Table of Figures

Figure 5: Workflow Notations ................................................................................................................. 24

Figure 6: Overview Workflow O1: Family Assistance Intake and Eligibility Determination .......... 38

Figure 7. Overview Workflow O2: Family Assistance Ongoing Benefits Management ................ 39

Figure 8. Workflow WF01: Complete Self-Service Pre-Screening ................................................... 40

Figure 9. Workflow WF02: Apply for Programs / Benefits Online ..................................................... 41

Figure 10. Workflow WF03: Apply for Programs / Benefits In-Person or By Paper ....................... 42

Figure 11. Workflow WF04: Process Application ................................................................................ 43

Figure 12. Workflow WF05: Conduct Eligibility Interview .................................................................. 44

Figure 13. Workflow WF06: Process Eligibility .................................................................................... 45

Figure 14. Workflow WF07: Complete Eligibility Determination ....................................................... 46

Figure 15. Workflow WF08: Issue Benefits .......................................................................................... 47

Figure 16. Workflow WF09: Conduct Medical Evaluation of Incapacity .......................................... 48

Figure 17. Workflow WF10: Submit Self-Reported Change .............................................................. 49

Figure 18. Workflow WF11: Process Customer Change ................................................................... 50

Figure 19. Workflow WF12: Conduct Redetermination...................................................................... 51

Figure 20. Workflow WF13: Complete Redetermination Online ....................................................... 52

Figure 21. Workflow WF14: Complete Redetermination In-Person or By Paper ........................... 53

Figure 45. Overview Workflow O6: Appeals & Hearings and Program Integrity .......................... 186

Figure 46. Workflow WF35: File Appeal Request ............................................................................. 187

Figure 47. Workflow WF36: Conduct Hearing ................................................................................... 188

Figure 48. Workflow WF37: Issue Appeal Decision / Order ............................................................ 189

Figure 49. Workflow WF38: Program Integrity – Referral Identification ........................................ 208

Figure 50. Workflow WF39: Program Integrity – Establish Recovery ............................................ 209

Figure 51. Workflow WF40: Program Integrity – Benefit Recovery ............................................... 210

Figure 52. Overview Workflow O7: Shared Capabilities .................................................................. 224

Figure 53. Workflow WF41: Schedule an Appointment ................................................................... 225

Figure 54. Workflow WF42: Process Customer Communication ................................................... 226

Figure 55. Workflow WF43: Process Paper Documentation ........................................................... 227

Figure 56. Workflow WF44: Manage Referral ................................................................................... 228

Figure 57. Workflow WF45: Search & Lookup Customer ................................................................ 229

Figure 58. Workflow WF46: View Alerts ............................................................................................. 230

Figure 59. Workflow WF47: Send and Receive Secure Messages ............................................... 231

P a g e | 7


Figure 60. Workflow WF48: Contact TDHS Service Center ............................................................ 232

Figure 61. Workflow WF49: Manage Caseloads .............................................................................. 233

Figure 62. Workflow WF50: Access and View Standard & Dashboard Reports .......................... 234

Figure 63. Workflow WF51: Create Ad Hoc Queries and Reports................................................. 235

P a g e | 8


[Pages from report have been removed for the purposes of this RFP Appendix.]

P a g e | 9


2.0 Workflow Notations

A standard notation is used to document the Process Flows. Refer to the figure below for a summary of the notation and a description of how each notation is used.

Figure 5: Workflow Notations

Start/End: The Workflow Starts or Terminates

Overview Connector: The Overview Workflow Connects to another

Overview Workflow

Workflow Connector: The Workflow Connects to another workflow

Process/Activity: This square indicates a step in the Business Process

Yes

This line shows the flow of activities through the workflow

This line is a decision indicator

This line shows optional or alternative flow of activities through the workflow

Decision Point: This is an activity written as a ‘Yes’ or ‘No’ question that

controls the business / service delivery workflow

Parallel Mode: The Activities Between these Parallel Lines

Occur Concurrently

This represents a system external to the ESM

Color Coding for High-Level Process Areas

Manual Process

Supported by Solution

Set

Start

Decision Point

End

WORKFLOW CONNECTOR

OVERVIEW

CONNECTOR

Process/Activity

P a g e | 10


2.1 Use Case Overview

A “use case” provides vendors and end-users with an overview of the desired functionality by describing what the system is expected to do in supporting specific processes for the programs in scope

Each use case follows the actions of at least one “actor”

A “trigger” causes an actor to interact with the system until a process is completed (example triggers may include the submission of an application, or the receipt of a request)

A use case represents the complete course of events for a business process (e.g., review an application, etc.)

A use case illustrates what the system is expected to do - not provide a particular design or how the system will technically complete an activity

2.1.1 Use Case Goals

The goals of a use case are to:

Capture the functionality the new system will provide, in an easy to comprehend format

Provide context to the Functional Requirements

Define the Functional Requirements for a new system using simple narrative language

Provide a demonstration script for vendors to show how their product will meet the business needs

2.1.2 Sections of a Use Case

Each Use Case contains the following information:

Use Case Title

Actor(s) – Person interacting with the System

Purpose / Objective(s) – Background information and “to-be” goals

Trigger(s) – What initiates or provokes the first step

Pre-Condition(s) – What will be in place before

Post-Condition(s) – What will be in place after

Use Case Flow – The process steps listed

Alternative Flow(s) –Variable steps

Additional Requirements – Requirements not captured in the main or alternative flows NOTE: Additional Requirements for all use cases are consolidated and provided in section 5.0 Additional Requirements

Associated Use Case(s) – Use cases before and after, or that directly or indirectly relate to the use case

Interfaces – What entities / systems will information be shared with or obtained from

P a g e | 11


3.0 Workflow and Use Case Overview

The Workflows and Use Cases are aligned with the components depicted in the functional conceptual view below, by programs or shared capabilities, as follows:

Programs:

Family Assistance

Child Support Services

Child Care Services

Other TDHS Programs –

— Child Care Licensing

— Appeals and Hearing

— Program Integrity

Shared Capabilities across Programs

3.1 Workflow Organization and Listing

The following table lists all the Workflows in this document grouped by program area or shared capability across programs.

Workflow # Workflow Name

Family Assistance

Workflow 01 Complete Self-Service Pre-Screening

Workflow 02 Apply for Programs/Benefits Online

Workflow 03 Apply for Programs/Benefits In Person or By Paper Application

Workflow 04 Process Application

Workflow 05 Conduct Eligibility Interview

Workflow 06 Process Eligibility

Workflow 07 Complete Eligibility Determination

Workflow 08 Issue Benefits

Workflow 09 Conduct Medical Evaluation of Incapacity

Workflow 10 Submit Self-Reported Change

Workflow 11 Process Customer Change

Workflow 12 Conduct Redetermination

Workflow 13 Complete Redetermination Application Online

Workflow 14 Complete Redetermination In Person or By Paper

P a g e | 12


Appeals & Hearings

Workflow 35 File Appeal Request

Workflow 36 Conduct Hearing

Workflow 37 Issue Appeal Decision / Order

Program Integrity

Workflow 38 Program Integrity – Referral Identification

Workflow 39 Program Integrity – Establish Recovery

Workflow 40 Program Integrity – Benefit Recovery

Shared Capabilities

Workflow 41 Schedule an Appointment

Workflow 42 Process Customer Communication

Workflow 43 Process Paper Document

Workflow 44 Manage Referral

Workflow 45 Search/Lookup Customer

Workflow 46 View Alerts

Workflow 47 Send and Receive Secure Messages

P a g e | 13


Workflow 48 Contact TDHS Service Center

Workflow 49 Manage Caseloads

Workflow 50 Access and View Standard & Dashboard Reports

Workflow 51 Create Ad Hoc Queries and Reports

3.2 Use Case Organization and Listing

The following table lists all of the detailed use cases in this document, the Program Area or Shared Capability of each use case, the Actors for each use case and a brief description of the complete course of events for the business process captured by the use case.

Use Case # Use Case Name Actors Description

Family Assistance

Use Case 01

Complete Self- Service Pre- Screening

Applicant This use case describes how Applicants complete a short, anonymous, online questionnaire based on primary determinants of TDHS program eligibility and receive a preliminary, non-binding feedback on their eligibility.

Use Case 02

Apply for Programs

Applicant

Eligibility Worker

This use case describes the process for Applicants to apply for TDHS programs, allowing the Applicant to apply, simultaneously or individually, for Families First, SNAP and / or Child Care Services programs.

Use Case 03

Process Application

Applicant

Eligibility Worker

This use case captures the process by which TDHS integrity eligibility applications are processed.

Use Case 04

Conduct Eligibility Interview

Eligibility Worker

Applicant

This use case describes the process by which the Eligibility Worker conducts an eligibility interview for TDHS programs.

Use Case 05

Process Eligibility Applicant

Eligibility Worker

This use case describes the process by which the System performs a series of eligibility checks on the application, defined by program-specific rules, to determine the Applicant’s eligibility. Depending on the outcome of these checks, the Eligibility Worker takes appropriate follow-up actions to process eligibility.

Use Case 06

Complete Eligibility Determination

Customer

Eligibility Worker

Customer Representative

This use case captures program-specific final review processes and procedures required for completing an eligibility determination.

Use Case 07

Issue Benefits Eligibility Worker This use case captures the process for issuing benefits to a new Customer or a change in benefits for a current Customer.

Use Case 08

Conduct Medical / Mental Health


This use case supports the determination of medical or mental health incapacity of a Customer, or a disabled in-home relative

P a g e | 31



Evaluation of Customer of the Customer, for whom the Customer

Incapacity Medical provides care.

Evaluation Unit (MEU) Worker

Use Case 09

Submit Self- Reported Change

Customer

Eligibility Worker

This use case describes the process by which a Customer submits a change to their case file information.

Use Case 10

Process Customer Change

TDHS Worker

Customer

In this use case, an Eligibility Worker verifies any changes are valid, re- determines eligibility, re-calculates the benefits amount based on specific events, and alerts the Customer and other parties (as appropriate) of the change.

Use Case 11

Complete Redetermination Application

Customer

Eligibility Worker

This use case captures the process by which a Customer’s eligibility for TDHS programs is redetermined, according to program-specific policies.


Appeals & Hearings

Use Case 32

File Appeal Request

Appellant

Program Integrity Specialist

Hearing Officer

Commissioner's Designee

Conciliation Attorney

Appeals Conciliation Unit Worker (FA appeals)

Appeals Processing Unit Worker

Appeals Administrative Processing Unit Worker

The purpose of this use case is to capture how the System tracks information and actions related to filing an appeal for a fair hearing, and how TDHS Appeals and Hearings Staff process the appeal request.

Note – TDHS policy provides significant appeal rights to the Customer for most case actions. All notices and communications with Customers must contain the policy specifying appeal rights and the process by which to file an appeal. These rights are not individually specified for each action in this document

P a g e | 32


Use Case 33

Conduct Hearing Appellant


Appeals Case Prep Program Coordinator

Appeals Case Prep Unit Attorney

Appeals

Administrative Processing Unit Worker

Appeals Conciliation Unit Worker

Commissioner’s Designee

Hearing Officer

TDHS Program Worker

n Program Integrity Specialist

The purpose of this use case is to capture how the System tracks information and actions related to scheduling and conducting a fair hearing or administrative desk review of an appeal.

P a g e | 33



Use Case 34

Issue Appeal Decision / Order

Appellant



Appeals Implementation Unit Worker


Hearing Officer

TDHS Program Worker

The purpose of this use case is to capture how the System tracks information and actions related to:

Issuance of Initial and Final Orders related to the Appeal

Actions taken by Appeals Implementation Unit Worker per the order

Petitions for Reconsideration or Appeal of Initial or Final Order

P a g e | 34



Program Integrity

Use Case Program Integrity Customer The purpose of this use case is to enable 35 – Referral

Identification

Program Integrity

Specialist

Investigator

TDHS Worker

any person to submit a referral for a possible overpayment, program violation and / or benefit tracking via multiple channels (e.g., phone, hardcopy, e-mail, TDHS Enterprise Portal)

Use Case Program Integrity Customer The purpose of this use case is to 36 – Establish

Recovery Program Integrity

Specialist

TDHS Program Worker

establish the mechanisms necessary to recover overpayment(s) made to a Customer. In certain cases, a Customer will receive benefits in an amount greater than what is allowed for by TDHS

program policy

Use Case Program Integrity Customer The purpose of this use case is to 37 – Benefit

Recovery Program Integrity

Specialist

Program Integrity Fiscal Services Worker

document the process to track the recovery of overpayment claims made to a Customer via multiple collection methods – recoupment, repayment plans, tax offset or other methods per the State

Shared Capabilities

Use Case 38

Schedule an Appointment

Customer

Service Provider

TDHS Worker

This use case documents the process for a Customer or a Service Provider to schedule an appointment for a variety of reasons

Use Case 39

Receive Customer Communication

Customer

TDHS Worker

This use case documents the process for a Customer to contact TDHS from a number of communication channels

Use Case Process Paper TDHS This use case documents the process by 40 Documentation Documentation which TDHS receives and processes

Processing paper documentation

Worker Customer

Service Provider

Use Case 41

Manage Referral TDHS Worker

Service Provider

This use case describes the process by which TDHS creates referrals to internal (State) departments or programs, or external service providers, requesting benefit, services or information, on behalf of the Customer

Use Case 42

Customer Search & Lookup

TDHS Worker

Customer

This use case captures the process to identify and / or validate a Customer’s relationship with TDHS programs, and / or to view information about the Customer in the System

Use Case 43

View Alerts TDHS Worker

Customer

Service Provider

This use case describes the process by which the System creates alerts for System users, and how System users access and view these alerts.

P a g e | 35



Use Case 44

Send and Receive Secure Messages

TDHS Worker

Customer

Service Provider

This use case describes the process by which System users send or receive secure messages to / from other System users or groups of users

Use Case 45

Contact TDHS Service Center

TDHS Service

Center Worker

TDHS Worker

System User or Caller, which may include

Customer

Service Provider

Public users (users without a system account)

This use case describes the process by which TDHS Service Center Workers provide customer service to TDHS Customers

Use Case

46

Manage Case

Load TDHS Worker

TDHS Supervisor

This use case captures the process related to the provision of services or benefits to a TDHS customer are distributed among TDHS Workers

Use Case 47

Access and View Dashboards

Customer

TDHS Worker

Service Provider

This use case describes the process by which a System user accesses a reporting “dashboard” in the System

Use Case Access and View TDHS Worker This use case describes the process by 48 Standard or

Parameter-Based Reports

Customer

Service Provider

which a System user accesses standard or parameter-based reports in the System

Use Case

49

Create Ad Hoc Queries and Reports

TDHS Business

Analyst

This use case describes the process by which a TDHS Business Analyst creates ad hoc queries or reports in the System

P a g e | 36


3.2.1 Use Case Actors

Actors are users of the System. An individual person may perform the actions of one or more actors in a given use case. For example, a person might perform the role of an Applicant while submitting an online integrated eligibility application, yet play the role of an Eligibility Worker if that person is both a TDHS staff person and a customer of TDHS programs.

Actor Name Description


Appeals and Hearings Division staff responsible for providing administrative support to the appeals process


Appeals and Hearings Division staff responsible for preparing TDHS' case (as a witness for the Department) for Fair Hearing (for Family Assistance, ADH, Child Support appeals)


Appeals and Hearings Division staff attorney responsible for representing TDHS in Fair Hearings, Administrative Disqualification Hearings or Tennessee Chancery Court


Appeals and Hearings Division staff responsible for managing the conciliation of an appeal, gathering data for the appeal (as required), and managing the Continuation of Benefits (CoB) for a Customer through the appeal process


Appeals and Hearings Division staff responsible for implementing any actions per the issuance of orders on the appeal

Appellant Individual who is dissatisfied with an administrative action of TDHS in regard to the furnishing or denial of assistance and who, as a result, is requesting a Fair Hearing before the State Office

Applicant A person who wishes to apply for TDHS programs, and thus receive benefits or services for themselves and / or their family. Applications may include information about the Applicant and other household members

Authorized Child Care Professional

An individual who meets one of the criteria defined by the State of Tennessee to provide Child care services without a license

Authorized Representative

A person who has the ability and access rights to assist a TDHS Customer (e.g., a parent, child, ward or other individual unable to represent himself) apply for benefits, make changes to their account, etc.

P a g e | 37




Impartial person authorized by the Commissioner to review appeals of initial orders and to enter final orders pursuant to T.C.A. § 4-5-315, or to review petitions for a stay or reconsideration of final orders. A Commissioner’s Designee may also be a Hearing Officer who is an impartial official of the Department of Human Services or the Department of State Administrative Procedures Division who is designated by the Commissioner to conduct contested case administrative hearing proceedings.

Customer A person applying for or enrolled in a TDHS program in order to receive benefits or services


TDHS Family Assistance staff person responsible for meeting with a Customer in the development of their Personal Responsibility Plan

Documentation Processing Worker

TDHS staff person responsible for scanning and recording of paper documents received

Eligibility Worker TDHS staff person responsible for processing the eligibility application or eligibility redetermination application, conducting the eligibility interview, and coordinating additional steps after the interview. Eligibility Workers may work within a single TDHS program, such as Child Care, or more than one, such as SNAP and TANF

Hearing Officer Impartial official of the Department of Human Services designated by the Commissioner to conduct a Fair Hearing. The staff member so designated will have had no personal stake or involvement in the case. A Hearing Officer will not have been directly involved in the initial determination of the action that is being contested, and will not have been the immediate supervisor of the caseworker who took the action.

Medical Evaluation Unit Reviewer

TDHS staff person responsible for processing disability documentation and medical records, and approving or denying Customer exemptions to program work requirements, due to medical incapacity

Primary Residential Parent (PRP)

The person with whom the Child resides more than 50% of the time


TDHS Program Integrity staff member responsible for managing program integrity referrals related to administrative errors, overpayments, etc.

Service Provider A person or organization external to TDHS that provides services to Customers

Program Integrity Special Investigator

TDHS Program Integrity staff member responsible for adjudicating and conducting investigations into suspected intentional program violations involving

(TDHS) Supervisor TDHS staff supervisor

P a g e | 38



TDHS Business Analyst TDHS staff responsible for analyzing TDHS business needs, and assisting in the development of technology solutions to meet these business needs

TDHS Field Office Worker

TDHS staff person at a TDHS field office

TDHS Office of General Counsel Worker

TDHS Office of the General Counsel staff person. The Office of General Counsel provides legal advice to DHS programs, legal representation in judicial and administrative litigation affecting the department, prepares departmental rules, and prepares legislation for and analysis of legislation affecting the Department

TDHS Program Worker TDHS program (e.g., Family Assistance, Child Care Services, Child Support Services) staff person

TDHS Service Center Worker

TDHS Service Center staff person responsible for processing Customer communications received via phone or mail at a TDHS Service Center.

TDHS Worker General term for any TDHS staff person, including state office, field / county office, Child Support, Finance and Administration and service center workers

P a g e | 39


4.0 Workflows and Use Cases

4.1 Family Assistance

4.1.1 Overview Workflow O1: Family Assistance Intake and Eligibility Determination

Figure 6: Overview Workflow O1: Family Assistance Intake and Eligibility Determination

Start

P a g e | 40


4.1.2 Overview Workflow O2: Family Assistance Ongoing Benefits Management

Figure 7. Overview Workflow O2: Family Assistance Ongoing Benefits Management

P a g e | 41


4.1.3 Workflow WF01: Complete Self-Service Pre-Screening

Figure 8. Workflow WF01: Complete Self-Service Pre-Screening

P a g e | 41


4.1.4 Workflow WF02: Apply for Programs / Benefits Online

Figure 9. Workflow WF02: Apply for Programs / Benefits Online

P a g e | 42


4.1.5 Workflow WF03: Apply for Programs / Benefits In-Person or By Paper

Figure 10. Workflow WF03: Apply for Programs / Benefits In-Person or By Paper

P a g e | 43


4.1.6 Workflow WF04: Process Application

Figure 11. Workflow WF04: Process Application

P a g e | 44


4.1.7 Workflow WF05: Conduct Eligibility Interview

Figure 12. Workflow WF05: Conduct Eligibility Interview

P a g e | 45


4.1.8 Workflow WF06: Process Eligibility

Figure 13. Workflow WF06: Process Eligibility

P a g e | 46


4.1.9 Workflow WF07: Complete Eligibility Determination

Figure 14. Workflow WF07: Complete Eligibility Determination

P a g e | 47


4.1.10 Workflow WF08: Issue Benefits

Figure 15. Workflow WF08: Issue Benefits

P a g e | 48


4.1.11 Workflow WF09: Conduct Medical Evaluation of Incapacity

Figure 16. Workflow WF09: Conduct Medical Evaluation of Incapacity

P a g e | 49


4.1.12 Workflow WF10: Submit Self-Reported Change

Figure 17. Workflow WF10: Submit Self-Reported Change

P a g e | 50


4.1.13 Workflow WF11: Process Customer Change

Figure 18. Workflow WF11: Process Customer Change

P a g e | 51


4.1.14 Workflow WF12: Conduct Redetermination

Figure 19. Workflow WF12: Conduct Redetermination

P a g e | 52


4.1.15 Workflow WF13: Complete Redetermination Online

Figure 20. Workflow WF13: Complete Redetermination Online

P a g e | 53


4.1.16 Workflow WF14: Complete Redetermination In-Person or By Paper

Figure 21. Workflow WF14: Complete Redetermination In-Person or By Paper

P a g e | 54


4.1.17 Use Case 01: Complete Self-Service Pre-Screening

Use Case ID / Title Use Case 01: Complete Self-Service Pre-Screening

Actor(s) Applicant

Background / Objectives

The purpose of this use case is to provide the Applicant with preliminary, non-binding feedback on their eligibility for TDHS programs, including SNAP, Families First, Child Care and Child Support, by allowing the Applicant to fill out a short, online questionnaire based on primary determinants of TDHS program eligibility.

Note: This pre-screening tool does not guarantee the Applicant’s eligibility for TDHS programs. It is provided to inform the Applicant on whether filling out an eligibility application will likely result in TDHS program eligibility, based on information provided by the Applicant.

Primary ESM Imperatives Addressed:

Self-Service

The System will significantly enhance Customer empowerment and reduce the need for face-to-face interactions

Usability

The System will support optimal data collection, so as to not burden users with lengthy or unnecessary data entry

Trigger Events(s) The Applicant chooses to receive guidance on their potential eligibility for TDHS programs

Pre-Condition(s) The Applicant has access to the pre-screening tool through the TDHS Enterprise Portal (no log in required)

The Applicant has the required information to complete the pre-screening process

Post-Condition(s) The Applicant has received guidance on their potential eligibility for TDHS programs in scope

4.1.17.1 Use Case 01: Main Flow

1. The Applicant accesses the TDHS Enterprise Portal and selects the pre-screening eligibility tool

2. The System displays basic information about the programs to which the Applicant may be pre-screened, including:

Technical eligibility requirements

Financial eligibility requirements

Benefit type

3. The System presents the list of programs for which the Applicant may be pre-screened and the Applicant selects any programs for which they wish to opt-out (do not wish to be pre-screened)

4. The System displays a step-by-step questionnaire which collects data required to issue potential eligibility determination. Data elements may include, but are not limited to, the following:

Demographic information for each individual household member, including:

— First name

P a g e | 55


— Age / Date of birth

— citizenship

— Disability / Health status

— Pregnancy status

— Education / training enrollment status

— Income (earned and unearned, prior to garnishments and bankruptcies)

— Assets

» Total value greater than a minimum amount per TDHS policy (yes / no)

» Total value of assets, including but not limited to automobiles, recreational

vehicles, property, cash, investments, etc.

— Expenses

» Medical

» Child care

» Child support

» Living arrangement

» Other recurring expenses

Household information

— Address / county (Residency)

— Familial relationships of individual household members (e.g., parent, child, caregiver, etc.)

— Household expenses

— Purchase and prepare information

5. After the Applicant has entered information, the System provides the Applicant with the option to review the data and make any final changes

6. The Applicant submits their request for pre-screening

7. The System processes the entered information and displays information on any / all programs for which the Applicant may qualify. The Applicant’s qualification is based on the data provided and the programs selected for pre-screening

a. The System displays the preliminary, non-binding feedback on the determination and limitations of this determination (i.e., that the guidance does not guarantee eligibility)

b. If the Applicant does not appear to qualify, the System provides information regarding potential actions the Applicant may take, such as seeking assistance from supplemental resources, including but not limited to:

» Continuing to complete an official TDHS eligibility application for benefits and

services

P a g e | 56


» Other State programs that may benefit the Applicant based on the information

provided

» 211 directory information to inform citizens of local and non-State programs

that may assist the Applicant

» Any other resources of which TDHS chooses to advise the Applicant

8. The System provides the Applicant with the option to complete an integrated eligibility application (see Use Case 02: Apply for Programs / Benefits Online)

a. If the Applicant elects to apply in the same session, the System provides the Applicant with the option to pre-populate the integrated eligibility application with information provided in the pre-screening process

4.1.17.2 Associated Use Cases

Use Case 02: Apply for Programs

4.1.17.3 Interface(s)

None

P a g e | 57


4.1.18 Use Case 02: Apply for Programs

Use Case ID / Title Use Case 02: Apply for Programs

Actor(s) Applicant

Eligibility Worker


One of the System’s key objectives is to allow the Applicant to apply for a range of TDHS program benefits and services, without the need to apply for each program individually. This use case meets this objective, with the use of an “integrated eligibility application,” allowing the Applicant to apply, simultaneously or individually, for Families First, SNAP and / or Child Care Services programs.

The Applicant is able to apply online and submit required additional documentation along with the application. Most of the eligibility determination process can be accomplished online, through step-by-step instructions and questions the Applicant can complete from any computer with internet access, 24x7.

If assistance is needed (e.g., additional information requested by the Applicant), the Applicant may obtain assistance online, or in-person, at a local TDHS field office or a TDHS Service Center.


Self-Service

The System will allow the Applicant to submit a single application for multiple TDHS programs

Customer-centric Operations

The System will allow Eligibility Workers to track applications from submission through to eligibility determination

Process Standardization

The System will guide the application through a standard review process for determining eligibility

Eliminate Distributed Paper Handling

The System will provide for a paper-free application process

Universal Case Load

The System will allow any Eligibility Worker, with appropriate access rights in the System, to review and take action on an application

Trigger Events(s) The Applicant goes to the TDHS Enterprise Portal and selects the option to apply for TDHS program benefits or services

or

The Applicant receives and completes a paper version of the integrated eligibility application

or

The Applicant completes the TDHS self-service pre-screening tool and chooses to apply for TDHS programs or services after completing the pre-screening

Pre-Condition(s) The Applicant has access to the TDHS Enterprise Portal or

The Applicant has access to a print version of the integrated eligibility application

P a g e | 58


Use Case ID / Title Use Case 02: Apply for Programs

Post-Condition(s) The Applicant has submitted an integrated eligibility application, the System has performed an initial check to ensure it contains minimum required information, and TDHS has accepted the application

The System has notified the Applicant of successful submission and acceptance of the application, and provided the Applicant with the timeframe for TDHS to process the application, via the Applicant’s preferred communication channel

The System has time-stamped the application, and started the timer for application processing, per TDHS policy

If the Applicant has chosen to delete an application, the System has deleted the application information completely


1. The Applicant accesses the TDHS Enterprise Portal

a. If the Applicant has already created a user account, the Applicant enters their credentials and logs in to the Portal

b. If the Applicant has not previously created a user account, the Applicant creates a new user account and logs in to the Portal

2. The Applicant selects the option to complete an integrated eligibility application

3. The System checks to see whether an existing, un-submitted integrated eligibility application is saved for the Applicant

a. If there is an existing, un-submitted application on file for the Applicant

i. The System provides the Applicant with the ability to continue the previously saved application (available for a time period, per TDHS policy) and display all information previously entered for confirmation if there is an existing, un- submitted application on file for the Applicant

ii. The System provides the Applicant with the ability to modify any previously saved information

b. If there is not an existing, un-submitted integrated eligibility application for the Applicant, the System provides the Applicant with the ability to create and submit a new application

i. The System checks to see if the Applicant used the pre-screening eligibility tool (for more information on this too, see Use Case 01: Complete Self- Service Pre-Screening)

(1) If the System finds that the Applicant used the pre-screening eligibility tool, the System populates the application with known Applicant information, including but not limited to:

(a) Name

(b) Address

4. The System displays the TDHS programs for which the Applicant may apply. These programs include:

Supplemental Nutritional Assistance Program (SNAP)

P a g e | 59


Families First (Temporary Assistance for Needy Families)

Child Care Services

5. The System displays instructions for completing the integrated eligibility application, and provides links to additional application information, as appropriate

6. By default, the System pre-selects all TDHS programs for the integrated eligibility application, but allows the Applicant to de-select any / all of the TDHS programs

7. Based on the program(s) the Applicant selected, the System displays a step-by-step questionnaire for collecting application information. The questionnaire uses program- specific business rules to collect the minimum information required to accept the application, and provides the Applicant with the ability to provide additional information that will help with application processing. Information to be collected may include, but is not limited to:

Demographic information for each individual household member, including:

— First name

— Age / Date of birth

— citizenship

— Disability / Health status

— Pregnancy status

— Education / training enrollment status

— Income (earned and unearned, (prior to garnishments and bankruptcies))

— Assets

» Total value greater than a minimum amount per TDHS policy (yes / no)

» Total value of assets, including but not limited to automobiles, recreational

vehicles, property, cash, investments, etc.

— Expenses

» Medical

» Child care

» Child support

» Living arrangement

» Other recurring expenses

Household information

— Address / county (Residency)

— Familial relationships of individual household members (e.g., parent, Child, caregiver, etc.)

— Household expenses

— Purchase and prepare information

P a g e | 60


8. The Applicant enters application information

a. If the program rules require the Applicant to provide additional documentation for the application, the System provides the Applicant with the ability to upload the document(s) and attach to the application. See Use Case 02: Alternative Flow B – Attaching Documents to the Application

b. If the Applicant requires assistance in completing the application, the System provides the Applicant with the ability to:

i. Access context sensitive help (e.g., knowledge repository, procedure documentation etc.)

ii. Contact a TDHS Worker who can assist the Applicant in completing the application. See Use Case 39: Receive Customer Communication

9. The System allows the Applicant to save any entered information prior to submitting the application. If the Applicant chooses to save the application, the System saves un- submitted information and informs the Applicant that the information will be saved for up to a specified time period (per TDHS policy). When the Applicant saves the application:

a. The System informs the Applicant that the application information entered has been saved, including a date and time stamp of when the information was saved. The System also informs the Applicant that the saved application will remain available for a specified time period (per TDHS policy), and after that will be deleted

b. The System provides the Applicant with the ability to download a printable, Portable Document Format (PDF) version of the unsaved application

c. If the Applicant does not submit the application within the specified time period after being saved:

i. After a specified time period, if the application is not submitted, the System deletes the application

10. The System provides the Applicant with the ability to delete the application, including any saved applications, prior to submission. If the Applicant deletes the application

a. The System deletes all application information provided by the Applicant

b. The System displays confirmation of application deletion

c. If the Applicant is currently participating in a TDHS program, the System alerts the Applicant that the deletion of the application will not affect current TDHS program eligibility

11. The System provides the Applicant with the ability to submit the application. If the Applicant chooses to submit the application, the System checks to see if the Applicant has provided the minimum required information, in order for TDHS to accept the application

a. If the application contains the minimum required information to accept the application (per TDHS policy):

i. The System alerts the Applicant if a pending application has already been received or if the Applicant is already receiving benefits for the selected program and it is not time for renewal

ii. The System confirms that the Applicant has provided sufficient information for TDHS to accept the application

P a g e | 61


iii. The System displays the information the Applicant entered on the application, and provides the Applicant with the ability to download a printable, PDF version of the submitted application

iv. The System provides the Applicant with the ability to sign the application electronically

v. In the System, the Applicant electronically signs the application

vi. The System alerts the Applicant that the application has been successfully accepted

vii. The System records the date and time stamp of when the application was accepted

viii. The System starts the timer for application processing, per TDHS program policy

ix. The System provides the Applicant with the timeframe by when TDHS will process the application

x. The System alerts the Applicant of TDHS’ acceptance of the application, including the following:

» Information on next steps in the application process, including a date by when

TDHS will process the application (per TDHS program policy)

» Link to view the submitted application in the System

» Information on contacting TDHS

» Information on the appeals process

» Other information, per TDHS policy

xi. Proceed to processing the application. See Use Case 03: Process Application

b. If the application does not contain the minimum required information:

i. The System alerts the Applicant of any outstanding required information needed for TDHS to accept the application

ii. The System provides the Applicant with the ability to update the application

4.1.18.2 Use Case 02: Alternative Flow A – Apply for TDHS program(s) via Paper

Version of Application

1. The Applicant obtains a paper version of the integrated eligibility application by:

Downloading and printing a PDF version of the application

Visiting an office and obtaining a paper copy of the application

Contacting TDHS requesting a copy of the application, and receiving it via mail

2. The Applicant completes the paper version of the application

3. The Applicant provides the paper version of the application to TDHS by:

Mailing / faxing the application to the TDHS Service Center or a local TDHS office.

Dropping-off a version of the application at a local TDHS office

P a g e | 62


4. TDHS receives and processes the paper application. See Use Case 40: Process Paper Documentation

5. The System reviews the application for minimum required information sufficiency to accept the application, per program-specific rules

a. If the application contains the minimum required information:

i. The System accepts the application

ii. The System records the date and time stamp of when the application was accepted

iii. The System starts the timer against which the application will be processed by TDHS, per TDHS policy

iv. The System alerts the Applicant of successful submission and TDHS’ acceptance of the application, including:

» Information on next steps in the application process, including a date by when

TDHS will process the application

» Link to view the submitted application in the System (and to create user

account, if required)

» Information on contacting TDHS

» Information on the appeals process

» Other information, per TDHS policy

b. If the application does not contain the minimum required information:

i. The System marks the application as received, but not accepted

ii. The System identifies any missing information required for acceptance

iii. The System alerts the Applicant of unsuccessful acceptance of the application, via the Applicant’s preferred communication channel (if known / available). This notification includes:

» Notice of receipt of the application, but unsuccessful acceptance of the

application

» List of outstanding information needed for TDHS to accept the application

» Link to the submitted application in the system

» Instructions for completing the application

» Date by when the information needs to be provided, after which the

application will be deleted, per TDHS policy

4.1.18.3 Use Case 02: Alternative Flow B – Attaching Documents to the

Application

1. Within the application / questionnaire, the Applicant selects the option to upload documents

P a g e | 63


12. On the Applicant’s local computer, the Applicant accesses the electronic version of the required documents

13. The Applicant uploads the documents

14. The Applicant categorizes each of the uploaded documents

15. The Applicant enters any optional, additional information describing the document

16. The System associates all attachments with the application and alerts the Applicant the document(s) has been saved to the application

17. The System creates an itemized list of documents that have been provided. The itemized list is available for printing and serves as a receipt


Use Case 03: Process Application

Use Case 32: File Appeal Request

Use Case 39: Receive Customer Communication

Use Case 38: Schedule an Appointment

Use Case 40: Process Paper Documentation


None

P a g e | 64


4.1.19 Use Case 03: Process Application

Use Case ID / Title Use Case 03: Process Application

Actor(s) Applicant

Eligibility Worker


The purpose of this use case is to capture the process by which the application is processed. The System reviews the application to ensure it has all information needed in order to proceed with:

An eligibility interview (if required)

Technical, means and program eligibility checks


Self-Service

The System will allow the Applicant to update a submitted application with any additional required information for eligibility processing


The System will allow Eligibility Workers to track applications from submission through to eligibility determination





Universal Case Load


Interoperability and Investment Protection

The System will support interfaces with other internal and external data sources required for eligibility checks

Trigger Events(s) Applicant has submitted an integrated eligibility application

TDHS has accepted the integrated eligibility application

Pre-Condition(s) There is a valid application to be processed

Post-Condition(s) The System has verified initially provided application information with any applicable, available external data sources, and flagged any discrepancy for Eligibility Worker review

The Applicant has scheduled an eligibility interview (if required)

Using program-specific rules, the System has assigned an application priority status (e.g., expedited status)

If an application lacks information sufficient for eligibility determination processing, and the Applicant has not provided this information in an allowable timeframe (per TDHS policy), the application has been denied, and the Applicant alerted of application denial


1. Upon receipt of a valid application, the System verifies application information, based on applicable, available data sources. The data sources may include, but are not limited to:

Tennessee Department of Health

P a g e | 65


Tennessee Department of Corrections

Tennessee Department of Safety & Homeland Security

Federal Data Hub

Revenue / Wage Match

US Census Bureau

US Postal Service

Electronic Disqualified Recipient System (eDRS)

National Directory of New Hires (NDNH)

a. If the results of these searches return information different than what is provided by the Applicant on the application

i. The System flags the discrepancy for review

ii. The System alerts an Eligibility Worker and / or a Child Care Services Worker

18. The System uses program specific rules to check the application for:

Whether an eligibility interview is required

Whether the application contains sufficient information for eligibility determination processing

Whether other program-specific rules for application prioritization or routing apply

Whether a drug screening will be completed

a. If an eligibility interview is required

i. The System alerts the Applicant that an interview is needed, and provides instructions for scheduling the interview if an eligibility interview is required. See Use Case 38: Schedule an Appointment

ii. The TDHS Worker conducts the eligibility interview. See Use Case 04: Conduct Eligibility Interview

b. If an eligibility interview is not required, the System checks the application to determine if it:

— Contains sufficient information for eligibility determination processing; or

— Requires verification of discrepancies between information entered by Applicant and information provided by external sources via interface (as applicable)

i. If the application contains sufficient information to process the application

(1) The System flags the application as ready for eligibility determination processing. See Use Case 05: Process Eligibility

(2) The System checks to see if the application should be prioritized for review

(a) If the application should be prioritized for review

(i). The System flags the application for prioritized review

(ii). The System alerts a TDHS Worker to review the application

P a g e | 66


ii. If the application does not provide sufficient information for eligibility determination processing

(1) The System flags the application as missing information required for eligibility determination processing

(2) The System alerts the Applicant and sends written notification of the outstanding information, including:

(a) Instructions on how to provide the outstanding information, and seek assistance from TDHS staff

(b) Allowable timeframe for when the Applicant will provide the outstanding information, in order have application processed for eligibility, per TDHS policy

(c) If the Applicant updates the application within the allowable timeframe:

(i). In the System, the Applicant updates application information or uploads additional documentation (see Use Case 02: Alternative Flow B – Attaching Documents to the Application)

(ii). The Applicant saves the updated application

(iii). The System checks again for information sufficiency

I. If the application contains sufficient information to process the application, the System flags the application as ready for eligibility determination processing. See Use Case 05: Process Eligibility

II. The System checks to see if the application should be prioritized for review

III. If the application should be prioritized for review

A. The System flags the application for prioritized review

B. The System alerts a TDHS Worker to review the application

(d) If the Applicant does not update the application within the allowable timeframe:

(i). The System flags the application as denied

(ii). The System alerts the Applicant of application denial, including:

I. Reason for denial

II. Applicable State / Federal rule reference

III. Information on application submission

IV. Link to application in the System

V. Information on appealing the denial

VI. Instructions for re-applying

P a g e | 67


(iii). The System saves all application information, per TDHS record retention policy



Use Case 04: Conduct Eligibility Interview

Use Case 05: Process Eligibility





Tennessee Department of Health

Tennessee Department of Corrections

Tennessee Department of Safety & Homeland Security

Federal Data Hub


US Census Bureau n

US Postal Service n

eDRS

NDNH

P a g e | 68


4.1.20 Use Case 04: Conduct Eligibility Interview

Use Case ID / Title Use Case 04: Conduct Eligibility Interview

Actor(s) Eligibility Worker

Applicant


The purpose of the eligibility interview is to provide:

The Applicant with basic information on the TDHS programs, benefits and services

The Applicant with information on the application process and allow the Applicant to ask any questions regarding TDHS programs, benefits or services, or about the application process

An Eligibility Worker with the opportunity to review the application with the Applicant, and update the application if / as needed

An Eligibility Worker an opportunity to review the application before eligibility determination processing

TDHS with the ability to obtain the Applicant’s consent to comply with TDHS program requirements



The System will allow Eligibility Workers to track applications from submission to eligibility determination

Customer-centric Information

The System will allow Eligibility Workers to document all actions taken when determining eligibility, including the eligibility interview





Universal Case Load



The System will support interfaces to Employment and Training vendors and other external data sources for verifying eligibility information

Trigger Events(s) The Applicant has scheduled an eligibility interview, and the date and time of the appointment has arrived

Pre-Condition(s) The Eligibility Worker has logged into the System

The Applicant has submitted an application, and it has been accepted by TDHS

The Applicant has scheduled an eligibility interview

The Applicant has indicated their preferred method of conducting the eligibility interview (phone, in-person, individual vs group, etc.)

The Applicant has indicated if they require an interpreter, and specified the language

Post-Condition(s) The eligibility interview has been conducted

P a g e | 69


Use Case ID / Title Use Case 04: Conduct Eligibility Interview

The Applicant has consented to comply with TDHS program requirements, and the application is flagged for eligibility determination processing

If the Applicant has not consented to comply with TDHS program requirements, the application has been denied, and the System has alerted the Applicant of the application denial

If the Applicant has not participated in an eligibility interview within the allowable time frame, the application has been denied, and the System has alerted the Applicant of the application denial


1. At the date and time of the scheduled eligibility interview

a. In the System, the Eligibility Worker searches for the Applicant’s integrated eligibility application, and reviews the application

b. If the Applicant has chosen to conduct the interview on the telephone, the Eligibility Worker contacts the Applicant at the telephone number provided when the appointment was scheduled, and documents if contact was made

c. If the Applicant is present for the eligibility interview, the Eligibility Worker documents that the Applicant is present for the eligibility interview

d. If the Applicant is not available for the eligibility interview, either in person or via telephone

iii. In the System, the Eligibility Worker documents that the Applicant missed the appointment

iv. The System alerts the Applicant of the missed appointment, and provides instructions for rescheduling the eligibility interview within the allowable timeframe, per TDHS policy. See Use Case 38: Schedule an Appointment

v. If the Applicant does not reschedule an eligibility interview within the allowable timeframe, per TDHS policy

(1) The System marks the application as denied

(2) The System alerts the Applicant of application denial and sends notification

(3) The System saves all application information, per TDHS record retention policy

19. The Eligibility Worker reviews the application with the Applicant and asks additional questions, per program-specific policies and procedures

a. If applicable, the Eligibility Worker updates the application information while preserving the application data submitted by the Applicant

i. If, upon review of the information, the Eligibility Worker believes that the Applicant may be eligible for additional benefits or services and the Applicant would like to apply for the additional program(s)

(1) In the System the Eligibility Worker indicates the additional program(s) for which eligibility should be determined

P a g e | 70


ii. The System identifies any additional information which will need to be provided by the Customer, based on the additional program rules

b. If applicable, the Eligibility Worker verifies any information with external sources

c. If additional documentation is required for processing eligibility

i. If the Applicant is present for the interview and able to provide the documents at the time of the eligibility interview

(1) The Eligibility Worker scans the documents. See Use Case 40: Process Paper Documentation

ii. If the Applicant is present for the interview remotely (e.g., phone, video- conference, etc.), and the Applicant possesses an electronic version of the document, in the System, the Applicant attaches the document to the application. See Use Case 02: Alternative Flow B – Attaching Documents to the Application

iii. If the Applicant does not possess the document at the time of the eligibility interview

(1) The Eligibility Worker flags the outstanding information in the application

(2) The System alerts the Applicant of the outstanding information, provides instructions for the Applicant to provide the outstanding information, and the allowable timeframe for TDHS to receive the information, per TDHS policy

20. When the Eligibility Worker has concluded reviewing the application and gathering any additional information from the Applicant, the Eligibility Worker asks the Applicant if the Applicant agrees to comply with program-specific requirements

a. If the Applicant agrees to comply with program-specific requirements

i. In the System, the Eligibility Worker documents the Applicant’s compliance

ii. The Eligibility Worker marks the application as ready for eligibility determination processing. Proceed to Use Case 05: Process Eligibility

b. If the Applicant does not agree to comply with program-specific requirements

i. In the System, the Eligibility Worker documents the Applicant’s non- compliance

ii. The Eligibility Worker marks the application as denied

iii. The System alerts the Applicant and send a notification of a denial of application

4.1.20.2 Use Case 04: Alternative Flow A – Additional Customer Contact When an

Interview is Not Required

1. When program requirements do not include that an eligibility interview be held (e.g. for child care services), the System identifies if the application is missing information that will be received prior to determining eligibility

2. If information is missing, the System alerts the Eligibility Worker that the Applicant will be contacted to provide additional information

P a g e | 71


3. In the System, the Eligibility Worker contacts the Applicant and records the date, time and method of the contact and any additional narrative needed to document contact with customer

4. Processing continues from step 2 of the Main Flow




Use Case 05: Process Eligibility





Employment & Training Vendors

P a g e | 72


4.1.21 Use Case 05: Process Eligibility

Use Case ID / Title Use Case 05: Process Eligibility

Actor(s) Applicant

Eligibility Worker


In this use case, the System performs a series of eligibility checks on the application, defined by program-specific rules, to determine the Applicant’s eligibility. Depending on the outcome of these checks, the Eligibility Worker takes appropriate follow-up actions, including:

Flagging the application as ready for final eligibility determination

Gathering additional information / documentation from the Applicant, and re-running eligibility checks

Denying the application

This use case also applies to Customers at the time of their eligibility redetermination or, for SNAP Customers, at the time of Simplified Reporting.





The System will allow Eligibility Workers to document all actions taken when determining eligibility





Universal Case Load


Change-Ready Systems

The System will provide TDHS with the ability to update program- specific eligibility check rules as needed

Trigger Events(s) An application is complete and available to be processed

Pre-Condition(s) Eligibility Worker is logged in to the System

The application has sufficient information required for eligibility determination processing

The System has the latest program eligibility rules

Post-Condition(s) Application passes eligibility checks, and is flagged for final eligibility determination

Application fails eligibility checks, and the System has notified the Applicant of application denial


1. The System runs program-specific technical eligibility requirements checks such as demographic information and non-cooperation

P a g e | 73


a. The System documents and displays the results of the technical eligibility check

b. The System notifies the Eligibility Worker of technical eligibility results, (e.g. good cause), to relevant program areas (e.g. Child Support) per TDHS policy

c. If the application does not pass technical eligibility check, proceed to Step 5

2. If the program requires means testing, the System runs the means test

a. The System documents and displays the results of the means test

b. If the application meets means testing requirements for eligibility, the System flags the application for additional program-specific eligibility rules testing (as applicable)

c. If the System determines the application requires additional / updated information for means re-testing, the System alerts and sends notification to the Applicant

d. If the application does not pass means testing, proceed to Step 5

3. If the application requires additional program-specific eligibility rules testing

a. The System runs the program-specific eligibility rules test

b. The System documents and displays the results of the program-specific eligibility rules test

c. If the application meets program-specific eligibility rules requirements, the System flags the application for final review. See Use Case 06: Complete Eligibility Determination

d. If the System determines the application requires additional / updated information for program-specific eligibility rules test re-processing the System alerts the Applicant

e. If the application does not pass program-specific eligibility rules testing, proceed to Step 5

4. If / where appropriate, the Eligibility Worker override eligibility testing results, per TDHS policy

5. If the application failed any of the eligibility tests, and the results were not overridden

a. The System marks the application as denied

b. The System alerts and sends notification to the Applicant of the application denial

c. The System saves the application, and the results of all eligibility testing, per TDHS record retention policy



Use Case 06: Complete Eligibility Determination

Use Case 11: Complete Redetermination Application



Use Case 40: Process Paper Document

Use Case 42: Customer Search & Lookup

P a g e | 74



None

P a g e | 75


4.1.22 Use Case 06: Complete Eligibility Determination

Use Case ID / Title Use Case 06: Complete Eligibility Determination

Actor(s) Customer

Eligibility Worker



This use case captures program-specific final review processes and procedures required for completing an eligibility determination.





The System will allow Eligibility Workers to document all actions taken when determining eligibility





Universal Case Load



The System will support interfaces to Employment &Training and Employment and Case Management Services (ECMS) vendors to facilitate the eligibility determination process

Trigger Events(s) The System has completed technical, means-testing and program- specific eligibility rules testing, and determined the Applicant eligible

Pre-Condition(s) Eligibility Worker is logged in to the System

Post-Condition(s) Final program-specific eligibility determination(s) have been made on the application

TDHS has all information needed to determine / calculate and issue benefits


1. If the eligibility determination is being performed as a result of a Customer change, the System determines whether the eligibility redetermination should result in a change to the eligibility period, per TDHS policy

a. If the eligibility results in a change to the eligibility period, the System updates the eligibility period

2. If the eligibility determination is for SNAP

a. The Eligibility Worker determines if the Customer is seeking Employment & Training (E&T) services

P a g e | 76


i. If the Customer requests Employment & Training (E&T) services, the Eligibility Worker issues a referral to the appropriate E&T vendor (see Use Case 41: Manage Referral)

b. The processing proceeds to Use Case 07: Issue Benefits

3. If the eligibility determination is for Families First

a. The System determines whether the Customer requires drug screening

i. If the Customer requires drug screening

(1) The System alerts the Customer that the Customer must submit a drug screening questionnaire, including instructions for completing the drug screening questionnaire

(2) If the Customer fails to complete the questionnaire within a specified time period:

(a) The System marks the application as denied

(b) The System alerts and sends notification to the Customer of application denial

ii. The Customer accesses the TDHS Enterprise Portal and completes the drug screening questionnaire

iii. If the Customer answers yes to any of the drug screening questions, the System flags the Customer as requiring drug tested

(1) The Eligibility Worker creates a referral for the Customer to receive drug testing, at a facility local to the Customer (see Use Case 41: Manage Referral)

(a) If the Customer does not complete the drug test within a specified time period:

(i). The System marks the application as denied

(ii). The System alerts the Customer of application denial

(2) The drug testing facility sends a notification to TDHS, verifying completion of drug test, based on contract requirements for testing facilities. See Use Case 40: Process Paper Documentation

(3) The System alerts the Eligibility Worker that drug testing is complete

(4) The Eligibility Worker reviews the testing results and documents the test outcome, per TDHS policy (e.g., “positive” or “negative”)

(a) If the Customer’s drug test is positive:

(i). The System alerts the Customer that they must complete a substance abuse assessment, conducted by a qualified substance abuse professional, within a specified time period, per TDHS policy

(ii). If the Customer participates in a substance abuse assessment

I. The substance abuse professional sends a notification to TDHS verifying the Customer has completed the

P a g e | 77


substance abuse assessment, and agreed to comply with any applicable rehabilitation actions

II. In the System, the Eligibility Worker confirms that the drug assessment is complete

(iii). If the Customer does not complete an assessment within a specified time period, the System alerts an Eligibility Worker for appropriate follow-up actions

b. The System alerts the Customer of the need to schedule the Families First orientation interview

c. In the System, the Customer or Eligibility Worker schedules the Families First orientation interview. See Use Case 38: Schedule an Appointment

d. The System calculates expected benefits and alerts the Eligibility Worker of the Customer’s expected benefit amount

e. A Customer Representative conducts the Families First orientation interview

f. In the System, the Customer Representative documents whether the Customer is declaring an incapacity

i. If the Applicant is declaring an incapacity, see Use Case 08: Conduct Medical / Mental Health Evaluation of Incapacity

ii. When the medical evaluation of incapacity is complete, the Customer Representative documents the result in the System

g. In the System, the Customer Representative documents the Customer’s Personal Responsibility Plan (FF-PRP)

i. The Customer is referred to Child Support services and includes in the referral:

(1) Information about a 'good cause claim', if applicable

(2) All available ARP information (see Use Case 19: Accept Child Support Referral)

ii. If, as part of the FF-PRP, the Customer requires a program referral, in the System, the Customer Representative requests the referral. See Use Case 41: Manage Referral

iii. If, as part of the FF-PRP, the Customer elects to receive Child Care (to facilitate the completion of work activities in their personal responsibility plan), the Customer Representative documents this in the System. See Use Case 17: Issue Child Care Certificate

iv. If, as part of the FF-PRP, the Customer plans to participate in work and / or educational activity, the Customer Representative sends a referral to ECMS vendors for work and / or educational activity participation See Use Case 41: Manage Referral

h. In the System, the Customer Representative determines or documents any other exemptions for which the Customer may qualify

i. In the System, the Customer Representative documents if the Customer has elected to participate in benefit diversion

P a g e | 78


j. The processing proceeds to Use Case 07: Issue Benefits

4. If the eligibility determination is for Child Care Services:

a. The System checks to see if the Customer is / will receive other TDHS program benefits, and displays any restrictions on potential Child Care service payments, per TDHS policy

b. The processing proceeds to Use Case 17: Issue Child Care Certificate


Use Case 07: Issue Benefits

Use Case 08: Conduct Medical / Mental Health Evaluation of Incapacity

Use Case 10: Process Customer Change

Use Case 17: Issue Child Care Certificate

Use Case 19: Accept Child Support Referral



Use Case 41: Manage Referral


ECMS vendors

P a g e | 79


4.1.23 Use Case 07: Issue Benefits

Use Case ID / Title Use Case 07: Issue Benefits

Actor(s) Eligibility Worker


The purpose of this use case is to capture the process for issuing benefits to a new Customer or a change in benefits for a current Customer. This use case is applicable to a number of circumstances, including:

An Applicant has applied and been determined eligible for TDHS program benefits NOTE: In this use case, the Applicant is referred to as a “Customer” because the Applicant is now eligible to receive benefits

A Customer has experienced a change of circumstances, triggering a redetermination of eligibility and a potential change in benefits

TDHS’ Program Integrity Division has identified a benefit discrepancy for a Customer, and created a referral, triggering a potential change in benefits for the Customer

Using TDHS and program-specific rules, the System enables Eligibility Workers to calculate benefit amounts and then authorize and issue benefits.



The System will allow TDHS Workers to issue / adjust benefits for an individual Customer


The System will allow Eligibility Workers to document information related to a Customer’s benefits in a consistent, central location


The System will guide TDHS Workers through a standard process of issuing / adjusting benefits


The System will provide for a paper-free process for issuing benefits

Universal Case Load

The System will allow any TDHS Worker, with appropriate access rights in the System, to perform actions related to the issuing of benefits


The System will support interfaces to electronic benefit transfer (EBT) vendors for issuing benefits to Customers

Business Process Outsourcing (BPO)

The System will provide information to EBT vendors for issuing benefits to Customers

Trigger Events(s) The System has completed an eligibility determination

TDHS Worker has flagged a Customer’s case file for benefit adjustment

Pre-Condition(s) TDHS Worker is logged into the System

The System has stored information on whether the Customer’s benefits are subject to benefit recoupment, penalties for TDHS program violations, or any other factors impacting benefits

P a g e | 80


Use Case ID / Title Use Case 07: Issue Benefits

TDHS Worker has obtained information from any external sources (e.g., court orders) impacting benefits (e.g., bankruptcy)

Post-Condition(s) The System calculates Customer’s benefits

Benefits to the Customer are authorized

Benefits to the Customer are issued


1. The System determines if the Customer’s benefits are subject to benefit recoupment. If the Customer’s benefits are subject to benefit recoupment

a. The System determines the recoupment amount (see Use Case 36: Program Integrity – Establish Recovery)

b. The System deducts the recoupment amount from benefit amount

2. An Eligibility Worker determines if the Customer’s benefits are subject to any court ordered penalties (e.g., bankruptcy) or other sanctions. If the benefits are subject to penalties:

a. In the System, the Eligibility Worker documents the amount of any penalties

b. The System deducts the penalty amount from the benefit amount

3. An Eligibility Worker determines if the Customer’s benefits are eligible for incentives or supplements. If so:

a. In the System, the Eligibility Worker documents the amount of any supplement

b. The System adds the supplement amount to the benefit amount

4. The System calculates and displays the Customer’s expected (if new Customer) or current benefit amount (if existing Customer)

5. Once all calculations have been completed to determine actual benefit to be distributed, the System authorizes the benefit

6. The System determines if the Customer is eligible for expedited benefits. If the Customer is eligible for expedited benefits, the System sends the expedited payment amount information to the EBT vendor

7. If the benefit is for a TDHS Customer that has never received an EBT card, or the Customer requests a new card, the System

a. Alerts the EBT vendor of a newly authorized Customer or an existing authorized Customer who needs a new card

b. Provides the EBT vendor with applicable Customer information, as needed to provide the Customer with an EBT card

8. For each benefit issuance, the System sends the current benefit payment information to the EBT vendor



Use Case 37: Program Integrity - Benefit Recovery

P a g e | 81



EBT vendor

P a g e | 82


4.1.24 Use Case 08: Conduct Medical / Mental Health Evaluation of Incapacity

Use Case ID / Title Use Case 08: Conduct Medical / Mental Health Evaluation of Incapacity

Actor(s) Customer Representative

Customer

Medical Evaluation Unit (MEU) Worker


This use case supports the determination of medical or mental health incapacity of a Customer, or a disabled in-home relative of the Customer, for whom the Customer provides care. Medical or mental health incapacity is determined for a Customer to be exempt from work requirements associated with program benefits such as Families First.

In this use case, a TDHS Worker (either an Eligibility Worker or Customer Representative) works with TDHS Medical Evaluation Unit (MEU) staff to coordinate medical or mental health incapacity determinations with a qualified clinical provider.


Responsiveness

The System will increase the ability of MEU staff to focus on Customer-centric tasks


The System will provide a centralized location for storing information related to a Customer's medical or mental health incapacity evaluation / determination


The System will decrease the need for paper documentation related to a Customer's medical or mental health incapacity evaluation / determination

The System will decrease the occurrence of missing documents

Trigger Events(s) The Customer has requested an exemption from work requirements due to a medical incapacity

or

The incapacity approval period is ending and needs to be redetermined

Pre-Condition(s) The Customer will have applied for, or be receiving benefits and services, from a program for which a medical incapacity exemption will be determined

Post-Condition(s) The Customer’s medical incapacity has been determined and documented


1. The Customer Representative documents that a Customer requests an exemption to program work requirements, based on a medical or mental health incapacity

a. The incapacity may be for the Customer or the Customer may demonstrate a critical need for care of an in-home disabled relative. In the System, the Customer Representative documents the type of exemption being requested

2. The System determines if the exemption can be confirmed based on information within the Customer’s record, including but not limited to:

Retirement, Survivors and Disability Insurance (RSDI) or Supplemental Security Income (SSI) based on his / her incapacity;

P a g e | 83


Veterans Affairs (VA) benefits based on his / her 100% incapacity;

Black Lung (a common name from any lung disease that develops from inhaling coal dust) benefits based on his / her own condition

Pregnancy within 30 days of expected due date

Short term exemptions less than 30 days

3. If the System cannot confirm the exemption validity based on the information available, in the System, the Customer completes the medical / mental health incapacity exemption request forms required to initiate the incapacity review, per TDHS policy. This includes, but is not limited to:

Medical Evaluation Unit (MEU) checklist

Diagnosis information

Health Insurance Portability and Accountability Act (HIPAA) authorization form

Consent for medical record request(s)

4. In the System, the Customer electronically signs the forms

5. The System records the date and time stamp of when the incapacity exemption request was submitted

6. The System starts the timer for MEU processing, per TDHS policy

7. The System alerts the Customer of TDHS’ acceptance of the incapacity determination request, including:

Information on next steps in the MEU review process

Link to view the submitted forms in the System

Information on contacting TDHS

Information on the appeals process

Other information, per TDHS policy

8. A Medical Evaluation Unit Worker reviews the forms

9. The System sends medical information request forms to the clinical providers identified by the Customer. The System records the date and times the forms were sent

10. If / when TDHS receives back medical information request forms from the Customer’s clinical providers

a. A Medical Evaluation Unit Worker scans the forms received and attaches them to the Customer’s case file. See Use Case 40: Process Paper Documentation

b. The Medical Evaluation Unit Worker enters any additional information regarding the forms, as applicable, per TDHS policy

11. At specified time intervals (e.g., 21 days and 30 days) after the incapacity exemption forms were submitted, per TDHS policy, the System checks to see if any medical information request forms have been received by TDHS

a. For each clinical provider who has not submitted TDHS a medical information request form, the System sends a reminder to the clinical provider

P a g e | 84


12. The System monitors TDHS’ receipt of medical information requests for the Customer. If / when all medical information request forms have been received for a Customer’s incapacity exemption request

a. The System alerts a Medical Evaluation Unit Worker to review the incapacity exemption request

i. The Medical Evaluation Unit Worker reviews any / all information received from clinical providers and makes an incapacity decision (approving or denying the exemption request)

ii. In the System, the Medical Evaluation Unit Worker documents their decision on whether a medical incapacity exists

(1) If a medical incapacity exists, the System alerts and sends notification to the Customer and alerts the Customer Representative of the approval of an exemption, including the dates on which the exemption is valid

(2) If no medical incapacity exists, the System alerts and sends notification to the Customer and alerts the Customer Representative of the denial of the exemption request, including the Customer’s appeal rights and any other applicable information, per TDHS policy

13. At a specified time per (e.g., 40 days) after the incapacity exemption forms are submitted, per TDHS policy, the System checks if any medical information request forms have been received

a. If no medical information request forms have been received

i. The System marks the exemption request as denied

ii. The System alerts and sends notification to the Customer and alerts the Customer Representative of the exemption request denial, including the Customer’s appeal rights and any other applicable information, per TDHS policy

b. If at least one medical information request form was received, the System alerts a Medical Evaluation Worker to review the incapacity exemption request

i. The Medical Evaluation Unit Worker reviews any / all information received from clinical providers and makes an incapacity decision (approving or denying the exemption request)

ii. In the System, the Medical Evaluation Unit Worker documents their decision on whether a medical incapacity exists

(1) If a medical incapacity exists, the System alerts the Customer and the Customer Representative of the approval of an exemption and the dates on which the exemption is valid

(2) If no medical incapacity exists, the System alerts the Customer and the Customer Representative of the denial of the exemption request, including the Customer’s appeal rights and any other applicable information, per TDHS policy



P a g e | 85




None

P a g e | 86


4.1.25 Use Case 09: Submit Self-Reported Change

Use Case ID / Title Use Case 09: Submit Self-Reported Change

Actor(s) Customer

Eligibility Worker


The purpose of this use case is to allow the Customer to submit a change to their information. Customers are required to submit changes to their information within a certain time frame after the change has occurred, per TDHS policy. The change may affect the benefit amount or may render the Customer ineligible. Information changes may include but are not limited to the following:

Change in household composition

Change in income

Change in expenses

Relocation, particularly to another state

If the change is not reported within a time frame mandated by program policy, TDHS may be entitled to recover the Customer’s benefits and collect an overpayment.


Self-Service


Usability



The System will improve Customers' and TDHS Workers' ability to keep Customer information accurate and current

Trigger Events(s) The Customer has experienced a change in circumstance (i.e., household composition, income, expenses, relocation, etc.) and wishes to report this to TDHS

Pre-Condition(s) The Customer is receiving benefits from at least one program

Post-Condition(s) The Customer has reported a change to their information

The System has notified the Customer that the reported change has been received


1. The Customer accesses the TDHS Enterprise Portal and selects the option to report a change

a. If the Customer has previously created an account, the Customer uses the previously created credentials and logs into the System

b. If the Customer does not have an account, the System prompts the Customer to create an account and links the credentials to the Customer’s information

2. The System displays the Customer’s information and prompts the Customer to indicate the information that requires an update. Information that may be changed includes but is not limited to:

Contact information (e.g., address, email, phone)

P a g e | 87


Change of income or expense

Household composition change

Incapacity status change

Pregnancy

School attendance

Change of assets / resources

Preferred method of contact (mail / email / telephone)

3. The Customer enters the new or updated information

4. The System determines whether additional documentation is required for the change to be considered submitted,

a. If additional documentation is required, the System displays the option to attach electronic documentation (see Use Case 09: Alternative Flow A – Attaching Documents when Submitting a Change)

b. If the information is only available in hard copy and the Customer does not have the ability to scan or take a picture of the document, the System provides mailing and drop-off locations

5. The System displays a summary of collected information and allows the Customer to make final changes

6. The Customer submits the form

7. The System alerts the Customer to confirm receipt of the change, and includes a link to the Customer’s updated information

8. The System alerts the Eligibility Worker that a Customer has submitted a change

4.1.25.2 Use Case 09: Alternative Flow A – Attaching Documents when

Submitting a Change

1. The Customer selects the option to upload documents

2. The Customer locates the electronic version of the required documents

3. The Customer uploads the documents

4. The Customer selects the type of document they have uploaded

5. The Customer enters any additional information required, including free form text comments

6. The System associates all attachments with the Customer record and application

7. The System provides confirmation after saving the additional information successfully

4.1.25.3 Use Case 09: Alternative Flow B – TDHS Worker Reports Customer

Change on Behalf of Customer

1. The Customer contacts TDHS with a change, via one of the following:

Telephone / Email (see Use Case 39: Receive Customer Communication)

Mail / Fax (see Use Case 40: Process Paper Documentation)

P a g e | 88


In-person at a TDHS field office

2. In the System, an Eligibility Worker, with appropriate access rights in the System, accesses the Customer’s case file and indicates that the Customer is self-reporting a change

3. The Eligibility Worker enters the updated information and saves the updates

4. The System determines whether additional documentation is required for the change to be considered submitted

a. If no additional documentation is required, the System alerts the Customer of the successful change, including, but not limited to, the following:

— TDHS’ receipt of the Customer change information

— Summary of the change

b. If additional documentation is required, the System alerts the Customer of the need for additional documentation, including, but not limited to the following:

— TDHS’ receipt of the Customer change information, and a summary of the change

— Summary of the additional documentation needed to process the change

— Timeframe for when TDHS needs to receive the additional documentation, if / as appropriate, per TDHS policy

— Instructions to the Customer on how to submit the additional documentation






None

P a g e | 89


4.1.26 Use Case 10: Process Customer Change

Use Case ID / Title Use Case 10: Process Customer Change

Actor(s) TDHS Worker

Child Support Worker

Eligibility Worker

Customer


Throughout the course of service delivery, there are many events that may change a Customer’s program eligibility or benefits amount. These events vary from changes in the Customer’s household composition or income level to inactivity for a prolonged time period. When these changes occur, the case is added to the queue of cases which require attention by an Eligibility Worker.

In this use case, an Eligibility Worker verifies any changes are valid, re- determines eligibility, re-calculates the benefits amount based on specific events, and alerts the Customer and other parties (as appropriate) of the change.


Self-Service


Usability



The System will improve TDHS' ability to respond to changes in Customer information

Data Access

The System will improve TDHS Workers' ability to access changes in Customer information


The System will improve Customers' and TDHS Workers' ability to keep Customer information accurate and current


The system will support interfaces to various external data sources for identifying changes to Customer information

Trigger Events(s) A Customer change has been identified by the System

Pre-Condition(s) The Customer has reported a change (see Use Case 09: Submit Self- Reported Change)

or

An external agency has reported a change (e.g., the System has determined the Customer’s salary has significantly changed as part of the Welfare-to-Work or Employment & Training ongoing case management)

or

TDHS has documented a change during an audit, appeal, or investigation

or

An automated match has resulted in a change to Customer’s information

P a g e | 90


Use Case ID / Title Use Case 10: Process Customer Change

or

The passage of time has created a possible change (e.g., critical milestone achieved)

Post-Condition(s) The Customer’s information is updated

The System has determined if the Customer’s eligibility and benefits amount will be re-determined

The Customer has been alerted of the change


1. The System identifies that a change in information has occurred. Changes may result from:

A Customer self-reports a change (see Use Case 09: Submit Self-Reported Change)

A time-driven event occurs which requires review (e.g., a Child in a household turns 18)

An automated match provides new information about a Customer

A Service Provider submits a participation / compliance report about a Customer

2. The System determines if a change requires additional verification by TDHS

a. If the change requires additional verification by TDHS

i. The System alerts the Customer, requesting they contact TDHS in order to discuss the change, by a specific date, per TDHS policy

ii. Upon contact by Customer, the TDHS Worker reviews the Customer’s case file, and any available information about the change, including but not limited to:

» The Customer for whom the change has been made

» The data source for the change

» Documentation submitted in support of the change

» The original information value, and the changed information value

» The date on which the change became effective, if applicable

iii. Upon verification, the TDHS Worker captures any ancillary information (e.g., effective date)

iv. The TDHS Worker updates the change “verified”

3. The System determines, based on program rules, whether the Customer’s eligibility will be rerun. If so, see Use Case 05: Process Eligibility

4. The System determines if the change requires an alert to the Customer, per TDHS policy. This change alert may include, but is not limited to:

Summary of change

Original information value and new information value

Date on which the change became effective, if applicable

P a g e | 91


Program specific eligibility redetermination results, if applicable

Overpayment information, if any, including directions to contact TDHS to resolve the overpayment (see Use Case 35: Program Integrity - Referral Identification)

Customer’s appeals and fair hearing rights

4.1.26.2 Use Case 10: Alternative Flow A – Processing Inactive Customers

1. The System receives information from the EBT vendor that the Customer has been inactive for a specified time period

2. The System alerts the Customer indicating the status has been changed to inactive. This alert includes information such as, but not limited to:

Program name

Inactivity / expiration date

Reason for status change

Program contact information

Instructions to reinstate benefits (if / as possible, TDHS program policy)

3. If the Customer remains inactive after a time period determined by TDHS, specific to each program:

a. The funds are expunged

b. The System detects any overpayments (see Use Case 37: Program Integrity - Benefit Recovery)

4.1.26.3 Use Case 10: Alternative Flow B – Notice of Non-Cooperation

1. The Child Support Worker documents in the System that the PRP is not cooperating with Child Support, as well as all supporting examples of non-cooperation (see Use Case 21)

2. If the PRP is currently receiving Families First benefits or services, the System alerts the PRP and the Eligibility Worker of the requirement of cooperation with Child Support and the specific Child Support services with which the PRP must comply in order to resume compliance with program rules

3. The Eligibility Worker contacts the PRP and documents in the System all communication attempts and contact details about the finding of non-cooperation

4. If the Child Support Work or Eligibility Worker determine that the PRP does not comply with the required actions for Child Support, the Child Support Work or Eligibility Worker document the non-cooperation in the System, as well as the specific action with which the PRP did not comply

5. Upon determination of continued non-cooperation, the Eligibility Worker updates the case to reflect continued non-cooperation initiates a redetermination of eligibility (see Use Case 05: Process Eligibility)


Use Case 09: Submit Self-Reported Change

Use Case 11: Complete Redetermination Application

P a g e | 92



Use Case 37: Program Integrity – Benefit Recovery


Department of Safety and Homeland Security

DMV

Federal Data Hub


Census Bureau

eDRS

NDNH

Dept. of Corrections (e.g., TOMIS Report)

Dept. of Education

Dept. of Health (e.g., immunization (TENNIS))

ECMS Vendors

EBT Vendor System

P a g e | 93


4.1.27 Use Case 11: Complete Redetermination Application

Use Case ID / Title Use Case 11: Complete Redetermination Application

Actor(s) Customer

Eligibility Worker


A Customer’s eligibility for TDHS programs and services will be periodically redetermined / recertified, according to program-specific policies.

At specified periods before a Customer’s eligibility needs redetermined, TDHS alerts the Customer, providing notice of the need to redetermine eligibility, and instructions for doing so.

In this use case:

The System alerts the Customer of the need to complete an eligibility redetermination application, and instructions for doing so

The Customer completes the eligibility redetermination application online and is issued a preliminary redetermination

The process documented in this Use Case also applies to the Simplified Reporting (SR) process, for qualifying SNAP beneficiaries, per FNS / TDHS policy.


Self-Service

The System will allow the Customer to submit an eligibility redetermination application / SR form for TDHS programs


The System will improve TDHS' ability to process Customer eligibility redeterminations




The System will provide for a paper-free eligibility redetermination process

Universal Case Load

The System will allow any Eligibility Worker, with appropriate access rights in the System, to review and take action on a redetermination application

Trigger Events(s) The Customer will complete an eligibility redetermination application / SR form

Pre-Condition(s) The Customer has logged into the System

The Customer is receiving benefits from at least one TDHS program

The System has determined that eligibility redetermination is due

Post-Condition(s) The Customer has submitted their eligibility redetermination application

/ SR form


1. One month prior to a Customer’s eligibility expiration, the System will perform a data verification match with automated interfaces including, but not limited to: Beneficiary & Earnings Data Exchange (BENDEX), State Data eXchange (SDX), and State Verification of Employment System (SVES)

P a g e | 94


2. At a specified time interval before a Customer’s eligibility needs to be redetermined (per TDHS policy) the System checks to see if the Customer has submitted an eligibility redetermination application / SR form

a. If the Customer has not submitted an application / SR form, the System alerts the Customer of the need to complete eligibility redetermination application / SR form. Included in this alert is:

i. Summary information on the Customer’s current benefits

ii. Information on when the Customer’s benefits need redetermined

iii. Instructions on completing an eligibility redetermination application / SR form, including a link to the eligibility redetermination application in the System

iv. Information on obtaining assistance from TDHS in completing the application / SR form

3. When the Customer chooses to submit an eligibility redetermination application / SR form, the Customer accesses the TDHS Enterprise Portal, logs in, and selects the eligibility redetermination application / SR form

4. If the Customer does not submit the redetermination form or SR form in a timely manner (per TDHS policy)

a. If the redetermination is for SNAP, the System closes the case

c. If the redetermination is for Families First (TANF) the System will close the Families First case

5. If the application has been received but there are outstanding verifications:

a. If the application was received by the 15th of the month, the application can be acted on the last working day of the month, per TDHS policy

b. If the application was received after the 15th of the month, the application will not be processed for thirty (30) days or until all verifications have been received, per TDHS policy

6. If only the verification documents are received:

a. The System issues a notice informing the Customer that the verification documents were received, but that a completed and signed application must still be submitted

b. If the application is not returned within ten (10) days, the System closes the case, per TDHS policy

7. The System checks to see whether an existing un-submitted eligibility redetermination application or SR form is saved for the Customer.

a. If there is an existing un-submitted application / SR form on file for the Customer

i. The System provides the Customer with the ability to continue the previously saved application / SR form

ii. The System displays all information previously entered

iii. The System provides the Customer with the ability to modify any previously saved information

P a g e | 95


b. If there is not an existing un-submitted eligibility redetermination application / SR form for the Customer, the System provides the Customer with the ability to create and submit a new application / SR form

i. The System pre-populates the application / SR form with information from the Customer’s case file

ii. The Customer makes changes to the pre-populated application / SR form, as necessary

(1) If the application / SR form requires the Customer to provide additional documentation, the System provides the Customer with the ability to upload the document(s) and attach to the application / SR form. See Use Case 02: Alternative Flow B – Attaching Documents to the Application

(2) If the Customer requires assistance in completing the application / SR form, the System provides the Customer with the ability to:

(a) Access context sensitive help (e.g., knowledge repository, procedure documentation etc.)

(b) Contact an Eligibility Worker through chat or phone who can assist the Customer in completing the application / SR form. See Use Case 39: Receive Customer Communication

8. The Customer saves any entered information, but does not submit the application / SR form. If / when the Customer saves the application / SR form:

a. The System alerts the Customer that the information entered has been saved, including a date and time stamp of when the information was saved.

b. The System provides the Customer with the ability to download a printable, PDF version of the unsaved application / SR form

9. If the Customer chooses to delete the application / SR form

a. The System deletes the application / SR form entirely

b. The System alerts the Customer that the application / SR form has been deleted

10. The System displays the information the Customer entered onto the application / SR form, and provides the Customer with the ability to download a printable, PDF version of the submitted application / SR form

11. The Customer electronically signs the application / SR form

12. The System alerts the Customer that the application / SR form has been successfully accepted

13. The System records the date and time stamp of when the application / SR form was accepted

14. The System starts the timer for application / SR form processing, per TDHS policy

15. The System provides the Customer with the timeframe by when TDHS will process the application / SR form, per TDHS policy

16. The System alerts the Customer of TDHS’ acceptance of the application / SR form. This alert includes:

P a g e | 96


Information on next steps in the redetermination process, including a date by when TDHS will process the application / SR form

Link to view the submitted application / SR form in the System

Information on contacting TDHS

Information on the appeals process

Other information, per TDHS policy

17. The System processes the redetermination application / SR following the process in Use Case 03: Process Application

4.1.27.2 Use Case 11: Alternative Flow A – Complete Redetermination Application / SR form on Paper

1. The Customer obtains a paper version of the eligibility redetermination application / SR form by:

Downloading and printing a PDF version of the application / SR form

Visiting an office and obtaining a paper copy of the application / SR form

Contacting TDHS requesting a copy of the application / SR form, and receiving it via mail

2. The Customer completes the paper version of the application / SR form

3. The Customer provides the paper version of the application / SR form to TDHS by:

Mailing / faxing the application / SR form to the TDHS Service Center or a local TDHS office

Dropping-off a version of the application / SR form at a local TDHS office

4. TDHS receives and processes the paper application / SR form. See Use Case 40: Process Paper Documentation

5. The System alerts the Customer of TDHS’ receipt of the application / SR form

6. Processing continues from Step 10 of the Main Flow








None

P a g e | 97


4.4.26 Appeals & Hearings

4.5.1 Overview Workflow O6: Appeals & Hearings and Program Integrity

Figure 45. Overview Workflow O6: Appeals & Hearings and Program Integrity

P a g e | 98


4.5.2 Workflow WF35: File Appeal Request

Figure 46. Workflow WF35: File Appeal Request

P a g e | 99


4.5.3 Workflow WF36: Conduct Hearing

Figure 47. Workflow WF36: Conduct Hearing

P a g e | 100


4.5.4 Workflow WF37: Issue Appeal Decision / Order

Figure 48. Workflow WF37: Issue Appeal Decision / Order

P a g e | 190


4.5.5 Use Case 32: File Appeal Request

Use Case ID / Title Use Case 32: File Appeal Request

Actor(s) Appellant


Hearing Officer

Commissioner's Designee

Conciliation Attorney

Appeals Conciliation Unit Worker (FA appeals)

Appeals Processing Unit Worker



The purpose of this use case is to capture how the System tracks information and actions related to filing an appeal for a fair hearing, and how Appeals and Hearings Staff process the appeal request.

In the cases of Suspected Intentional Program Violations (SIPV), a Program Integrity Specialist may also submit an appeal for Administrative Disqualification Hearing (ADH). Alternative Flow C (“File Appeal Request for Administrative Disqualification Hearing”) captures this use case.

Appellants may choose to receive a Continuation of Benefits (COB), while their appeal is being processed. Alternative Flow D (“The Appellant Requests a Continuation of Benefits (COB)”) captures this use case.


Self-Service

The System will significantly enhance the ability for an Appellant to submit appeal requests via electronic means

Responsiveness

The System will minimize the time required to gather, process and share information necessary to process appeals


The System will enhance TDHS' ability to link appeals to the Customers case file


The System will enhance TDHS' ability to standardize the process for filing and processing an appeal request


The System will support interfaces to TDHS' case management system

Trigger Events(s) Appellant chooses to file an appeal for a Fair Hearing

or

Program Integrity Specialist identifies a Suspected Intentional Program Violation (SIPV), and chooses to pursue an ADH

Pre-Condition(s) Appellant has access to the TDHS Enterprise Portal (if entering through the Portal), in order to access the appeal request form

Program Integrity Specialist has access to TDHS Enterprise Portal (if initiated by the Program Integrity Specialist)

Post-Condition(s) Appeal request is documented

Appeal request is conciliated, if appropriate

Appeal is routed to Appeal Administrative Processing Unit for scheduling

P a g e | 191



1. The Appellant accesses the TDHS Enterprise Portal and selects the option to submit an appeal request

2. The Appellant enters the required information to request an appeal

a. The System provides guidance to the Appellant about the fields required for submission and processing, which may include, but are not limited to:

— Action being appealed

— Program area

— Reason for appeal

— Whether the Appellant wishes to request continuation of benefits (see Use Case 32: Alternative Flow D – The Appellant Requests Continuation of Benefits) (if available)

— Whether the Appellant requests a fair hearing (if available)

— Whether the Appellant requests the hearing be conducted in person (default is telephonic)

— Whether the Appellant will have legal representation at the time of the fair hearing. If yes, the contact information of the Appellant’s counsel

3. The Appellant reviews the information and chooses to submit the request

4. The System alerts the Appeals Administrative Processing Unit that there is a new request for review

5. The Appeals Administrative Processing Unit Worker reviews the submitted request to determine if the information provided is sufficient for appeal processing to continue

a. If the Appeals Administrative Processing Unit Worker determines the information sufficient, the Appeals Administrative Processing Unit Worker updates the request status as accepted

b. If the Appeals Administrative Processing Unit Worker determines that the information is insufficient to proceed (e.g. unable to determine the specific adverse action being appealed) the Appeals Administrative Processing Unit Worker attempts to contact the Appellant and document the additional information necessary

i. If Appeals Administrative Processing Unit Worker is able to collect the required information

(1) The Appeals Administrative Processing Unit Worker updates the System with the information

(2) The Appeals Administrative Processing Unit Worker updates the request status as accepted

ii. If the Appeals Administrative Processing Unit Worker is unable to contact the Appellant, or if the Appellant is unable to provide information sufficient to process the appeal request

(1) The System alerts the Appeals Conciliation Attorney (FA appeals) or the Commissioner’s Designee (non-FA appeals) to determine if the appeal request can be accepted or denied

P a g e | 192


(a) In the System, the Appeals Conciliation Attorney or Commissioner’s Designee marks the appeal as accepted or denied

(b) If denied, the System alerts the Appellant that the request has been denied

6. The System determines if, based on TDHS policy, the appeal request meets timeliness requirements

a. If the System determines the appeal request does not meet timeliness filing requirements, the System alerts the Conciliation Attorney (FA appeals) or the Commissioner’s Designee (non-FA appeals) to determine if the appeal request can be accepted or denied

i. In the System, the Conciliation Attorney or Commissioner’s Designee marks the appeal as accepted or denied

ii. If denied, the System issues a notice to the Appellant that the request has been denied

7. An Appeals Conciliation Unit Worker (FA appeals) or Appeals Processing Unit Worker (non-FA appeals) screens the appeal request for fair hear-ability

a. If the Appeals Conciliation Unit Worker or Appeals Processing Worker determines the appeal request is acceptable for fair hearing

i. The Appeals Conciliation Unit Worker or Appeals Processing Unit Worker documents the decision in the System

ii. If the appeal is related to the SNAP program, the System issues an electronic appeal acknowledgement notice to the Appellant

b. If the Appeals Conciliation Unit Worker or Appeals Processing Unit Worker questions whether the appeal is acceptable for fair hear-ability

i. In the System, the Appeals Conciliation Unit Worker or Appeals Processing Unit Worker flags the appeal as requiring review for acceptability for fair hearing

ii. The System routes the appeal to the Conciliation Attorney (FA appeals) or Commissioner’s Designee (non-FA appeals) for acceptability for fair hearing review

iii. The Conciliation Attorney or Commissioner’s Designee review the appeal for acceptability for fair hearing

(1) If the Conciliation Attorney or Commissioner’s Designee finds the appeal acceptable for fair hearing

(a) The Conciliation Attorney or Commissioner’s Designee documents the decision in the System

(b) If the appeal is related to the SNAP program, the System issues an appeal acknowledgement notice to the Appellant

(2) If the Conciliation Attorney or Commissioner’s Designee finds the appeal unacceptable for fair hearing

(a) In the System, the Conciliation Attorney or Commissioner’s Designee marks the appeal as accepted or denied

P a g e | 193


(b) If denied, the System issues a notice to the Appellant that the request has been denied

8. For TDHS programs identified by the State, the System alerts the Appeals Conciliation Unit Worker to initiate conciliation. Attempts at conciliation may continue until the fair hearing or administrative desk review has occurred

a. If the appeal can be conciliated

i. In the System, the Appeals Conciliation Unit Worker documents the conciliation results and any actions required of the TDHS program Worker

ii. The System alerts the Appellant of the conciliation results

iii. If, as part of the conciliation, the Appellant wishes to withdraw the appeal

(1) The Appeal Conciliation Unit Worker withdraws the appeal on behalf of the Appellant. See Use Case 33: Alternative Flow B – Appellant Withdraws Appeal

iv. The System alerts the appropriate TDHS program Worker of the required action

v. In the System, a TDHS program Worker takes the appropriate follow-up action

b. If the appeal cannot be conciliated the System flags the appeal as requiring fair hearing or administrative desk review, and alerts the appeal request to the Appeals Administrative Processing Unit for scheduling

4.5.5.2 Use Case 32: Alternative Flow A – Process Appeal Request (Not Filed via

Enterprise Portal)

1. TDHS Worker receives an appeal request

a. If the request is received using a paper version of the appeal request form (via mail, email, fax or in-person)

i. In the System, the TDHS Worker documents the appeal request (see Use Case 40: Process Paper Documentation)

ii. Upon entry in the System processing continues with Step 4 in Main Flow

b. If the request is received not using the paper version of the appeal request form (e.g., phone), the TDHS Worker receiving the requests documents it in the System (see Use Case 39: Receive Customer Communication)

c. Upon entry in the System processing continues with Step 4 in Main Flow

4.5.5.3 Use Case 32: Alternative Flow B – Appellant Responds to Appeal

Request Denial

1. Appellant responds to an appeal request denial notification

a. If the Appellant responds via mail, in the System, the TDHS Worker documents the appeal request (see Use Case 40: Process Paper Documentation)

b. If the Appellant responds via phone, email, or fax, in the System the TDHS Worker receiving the response documents this in the System (see Use Case 39: Process Customer Communication)

P a g e | 194


2. The System routes the appeal denial response to the Conciliation Attorney (FA Appeals) or Commissioner’s Designee (non-FA appeals) to review the appeal denial response for evidence of good cause

3. The Conciliation Attorney (FA Appeals) or Commissioner’s Designee (non-FA appeals) review the appeal denial response for evidence of good cause

a. If the Conciliation Attorney (FA Appeals) or Commissioner’s Designee (non-FA appeals) find good cause

i. In the System, they mark the appeal request as granted for good cause

ii. If the appeal is related to the SNAP program, the System issues an appeal acknowledgement notice to the Appellant

iii. Proceed with Step 8 in the main flow

b. If the Conciliation Attorney (FA Appeals) or Commissioner’s Designee (non-FA appeals) do not find evidence of good cause

i. In the System, they mark the appeal denial response as denied

ii. The System alerts of the Appellant of the denial.

4.5.5.4 Use Case 32: Alternative Flow C – File Appeal Request for Administrative Disqualification Hearing (ADH)

1. Program Integrity Specialist identifies a Suspected Intentional Program Violation (SIPV), (see Use Case 35: Program Integrity – Referral Identification)

2. In the System, the Program Integrity Specialist submits an Administrative Disqualification Hearing referral, providing the required information about the Customer and the SIPV

3. The System alerts the Appeals Administrative Processing Unit Worker to review the ADH request and documents additional information received from the TDHS program Integrity Staff as needed. The Appeals Administrative Processing Unit Worker may also review information from the investigation case management system

4.5.5.5 Use Case 32: Alternative Flow D – Appellant Requests Continuation of Benefits (COB)

1. The System alerts the Appeals Conciliation Worker if the Appellant elected to receive a Continuation of Benefits (COB)

a. If an Appeals Conciliation Unit Worker determines the Appellant is eligible to receive a COB pending appeal, in the System, the Appeals Conciliation Unit Worker documents approval of the COB on their eligibility case, and the applicable dates

b. If an Appeals Conciliation Unit Worker determines the Appellant should not receive a COB pending Appeal, the Appeals Conciliation Unit Worker documents the denial of COB in the system

4.5.5.6 Use Case 32: Alternative Flow E – Conciliation Performed by TDHS Program Worker

1. In the System, the TDHS Worker documents any conciliation results and any actions required of the TDHS Program Worker

P a g e | 195


2. The System alerts the Conciliation Unit Worker of conciliation activity

3. Proceed with Step 8 in the main flow


Use Case 35: Program Integrity – Referral Identification

Use Case 33: Conduct Hearing




Investigation case management system

P a g e | 196


4.5.6 Use Case 33: Conduct Hearing

Use Case ID / Title Use Case 33: Conduct Hearing

Actor(s) Appellant







Hearing Officer

TDHS Program Worker



The purpose of this use case is to capture how the System tracks information and actions related to scheduling and conducting a fair hearing or administrative desk review of an appeal.

This use case captures the process whereby the appeal is scheduled, and a fair hearing or “administrative review (“desk review”) conducted.

Alternative Flows A (“Appellant Requests Continuance”) and B (“Appellant Withdraws Appeal”) cover optional scenarios for the appeal.

Alternative Flow C (“Conduct Administrative Disqualification Hearing”) captures the process for scheduling and conducting ADHs, where Hearing Officers review TDHS appeals related to Suspected Intentional Program Violations (SIPV). This alternative flow includes both ADH appeals, as well as situations when an ADH and a fair hearing are combined.


Self-Service

The System will significantly enhance the ability for an appellant to request a continuance, or withdraw an appeal

Responsiveness



The System will enhance TDHS' ability to standardize processes related to conducting a hearing per an appeal request

Universal Case Load

The System will support the collaboration of activities related to an appeal


The System will enhance TDHS' ability to coordinate activities related to an appeal

Trigger Events(s) An appeal request has been accepted in the System

Pre-Condition(s) Appellant has filed an appeal request with TDHS Appeals and Hearings and the appeal request was not withdrawn

or

Program Integrity Specialist have filed an ADH request

Post-Condition(s) Hearing Officer conducts Fair Hearing or Desk Review per the appeal

P a g e | 197



1. The System determines whether the appeal should be conducted by desk review or a fair hearing, based on:

Whether the Appellant requested a fair hearing

TDHS program policy

State policy

a. If the System determines the appeal should be conducted by a desk review

i. The System creates and sends a desk review acknowledgement notification to the Appellant and to the TDHS Program Worker (and all relevant parties) providing information on the deadline for submittal of documentation for the Hearing Officer to review

ii. The Appellant and the Case Prep Attorney (in coordination with TDHS Program staff) submits documentation supporting their position (see Use Case 40: Process Paper Documentation)

iii. The Appeals Case Prep Unit Attorney prepares materials related to the appeal, and in the System, attaches these items to the appeal

iv. At a specified time, defined by TDHS policy, the System alerts the Hearing Officer assigned to conduct the desk review of the appeal

b. If the System determines the Appeal should receive a fair hearing:

i. In the System, the Appeals Administrative Processing Unit Worker schedules the fair hearing, according to program-specific scheduling requirements (see Use Case 38: Schedule an Appointment)

ii. The System creates a Notice of Hearing and sends to all parties to the Appeal

iii. For designated TDHS programs, the Appeals Case Prep Unit Program Coordinator or Appeals Case Unit Attorney gathers all documentation / information related to the appeal and creates an evidence packet to be exhibited at the fair hearing and saves the documentation in the System as appropriate

iv. If additional formal meetings or documents are provided, record of the conversation and the participants is documented in the System

2. The Hearing Officer presides over the hearing, or reviews the Appeals materials for desk review

a. If Hearing Officer conducts a hearing, any additional exhibited evidence or legal documentation provided at time of hearing is recorded in the System

3. Upon completion of the hearing, the Hearing Officer deliberates the appeal. When the Hearing Officer concludes deliberation:

a. In the System, the Hearing Officer marks the appeal as awaiting initial order

b. If the Hearing Officer deems it appropriate to keep the record open (e.g., in event of additional evidence to be provided), the Hearing Officer marks the record as open and provides the date after which the record will close

P a g e | 198


4.5.6.2 Use Case 33: Alternative Flow A – Party to the Appeal Requests Continuance

1. A party to the appeal ( Appellant or TDHS) files a request for continuance by

Paper

Telephone

TDHS Enterprise Portal

2. The System alerts the Hearing Officer of a request for continuance

3. The Hearing Officer reviews the continuance request for information sufficiency, and compliance with TDHS policy

a. If more information is needed, the appropriate TDHS Worker contacts the party requesting the continuance, requesting additional information

4. The Hearing Officer reviews the continuance request and approves or denies the request

a. If the Hearing Officer approves the continuance request, issuing an Order of Continuance

i. The System marks the continuance request as approved

ii. If the Appellant is the party requesting the continuance, the System extends the timeframe for the scheduling of the Desk Review or Hearing, per program- specific policies

iii. The System alerts all parties of the Order of Continuance

iv. The System alerts the Appeals Administrative Processing Unit Worker to reschedule

b. If the Hearing Officer denies the continuance request

i. The System marks the continuance request as denied

ii. The System alerts all parties of the continuance request denial

4.5.6.3 Use Case 33: Alternative Flow B – Appellant Withdraws Appeal

1. The Appellant contacts TDHS to withdraw the appeal via:

Written correspondence to TDHS. See Use Case 40: Process Paper Documentation


a. If the Appellant is withdrawing the appeal request via the TDHS Enterprise Portal, the Appellant logs in to the Portal, and selects the option to file an appeal withdrawal

b. The Appellant provides information regarding the appeal withdrawal, and electronically signs the appeal withdrawal request

2. The System checks to see whether a hearing has been scheduled for the appeal. If the date and time stamp of the submission is within a specified number of business days (defined by State) of a scheduled hearing, the System alerts the Appellant that a Hearing Officer will review the withdrawal request before the hearing is withdrawn

P a g e | 199


3. The System alerts an Appeals Administrative Processing Unit Worker of a submitted withdrawal request

4. The Appeals Administrative Processing Unit Worker reviews the withdrawal request for information sufficiency, and compliance with program appeal request withdrawal policies.

a. If the withdrawal request meets program rules

i. The System routes the withdrawal request to the Hearing Officer or Commissioner’s Designee for review

ii. The Hearing Officer reviews the withdrawal request and approves or denies the request

(1) If the Hearing Officer approves the withdrawal request

(a) The System creates an Agreed Order of Withdrawal (AOW), and alerts the Commissioner’s Designee to review the AOW

(b) The Commissioner’s Designee reviews and approves or denies the AOW

(i). If the Commissioner’s Designee approves the AOW

I. The System alerts all parties to the appeal of the successful appeal request withdrawal

II. If a Fair Hearing has been scheduled for the appeal

A. The System removes the case from the docket / schedule

B. The System alerts all parties of the successful appeal request withdrawal

b. If the withdrawal request is denied, the System alerts the Appellant that the appeal withdrawal request has been denied

4.5.6.4 Use Case 33: Alternative Flow C – Conduct Administrative Disqualification Hearing

1. In the System, the Appeals Administrative Processing Unit Worker schedules the ADH based on program rules

2. In the System, the Appeals Case Prep Unit works with Program Integrity Staff to create an evidence packet for the ADH, and documents this information in the System

3. A specified number of days before the scheduled ADH (defined by Tennessee State law), the System alerts the Customer (respondent) of the ADH. The information in this notice includes, but is not limited to, the following:

The date, time, and place of the hearing

The charge(s) against the household member

A summary of the evidence, and how and where the evidence can be examined

A warning that, if the household fails to appear at the hearing, the decision will be based solely on information provided by TDHS

P a g e | 200


A warning of possible penalties if there is a determination of intentional program violation

A listing of the household member's rights, including right to waive the ADH, and information on the process to waive

A statement that the hearing does not preclude the State or Federal Government from prosecuting the household member of intentional program violation in a civil or criminal court action nor from collecting the over-issuance (note – not current State practice)

Information on how the Customer (respondent) may obtain free legal advice

4. In the System, the Appeals Administrative Processing Unit documents all information on attempts to issue the advance notice of ADH to the Customer (respondent). This includes:

Names and addresses used for correspondence

Method of correspondence (e.g., certified mail)

FedEx tracking number of each attempt, if appropriate

Number of correspondence attempts made

If someone receives the notice, information on formal acceptance of correspondence (e.g., name and date of signature)

5. If the Customer (respondent) contacts TDHS requesting postponement of the ADH, see Alternative Flow A – Appellant Requests Continuance NOTE: TDHS policy requirements and policies for ADH continuance requests may vary from appeals, though the process is the same.

6. If the Customer (respondent) contacts TDHS waiving their right to an ADH

a. The receiving TDHS Program Worker documents in the System that the Waiver has been received and the System alerts Program Integrity Unit staff that it has been received

b. The Program Integrity Specialist reviews the waiver and marks the ADH as waived in the System

c. The System removes the ADH from the docket



Use Case 34: Issue Appeal Decision / Order




None

P a g e | 201


4.5.7 Use Case 34: Issue Appeal Decision / Order

Use Case ID / Title Use Case 34: Issue Appeal Decision / Order

Actor(s) Appellant





Hearing Officer

TDHS Program Worker


The purpose of this use case is to capture how the System tracks information and actions related to:

Issuance of Initial and Final Orders related to the Appeal

Actions taken by Appeals Implementation Unit Worker per the order

Petitions for Reconsideration or Appeal of Initial or Final Order


Self-Service

The System will significantly enhance the ability for any Appellant to submit appeal requests via electronic means

Responsiveness


Universal Case Load

The System will support the collaboration of activities related to an appeal


q The System will enhance TDHS' ability to standardize processes related to issuing decisions or orders

Trigger Events(s) The Hearing Officer marks appeal as “hearing held and awaiting initial order” in System

Pre-Condition(s)

or

Hearing Officer has completed Administrative Desk Review of Appeal

Hearing Officer has conducted Fair Hearing of Appeal

Post-Condition(s) Final Order is issued (or the Initial Order becomes Final) and all Petitions for Reconsideration or Appeal resolved


1. In the System, the Hearing Officer drafts an Initial Order, including but not limited to:

The decision

The required actions and due dates

The participants

How it was conducted (telephone or in person)

Appealed action

Findings

P a g e | 202


When it was heard

When the order was entered

Evidence submitted

a. If the Appellant did not appear at the hearing, the Hearing Officer drafts a default order

2. The System alerts the Hearing Officer Supervisor that there is a new order for review

3. The Hearing Officer Supervisor conducts a legal review of the order

a. If the Hearing Officer Supervisor approves the Initial Order, in the System the Hearing Officer Supervisor enters and issues the Initial Order

b. If the Hearing Officer Supervisor does not approve the Initial Order, the Hearing Officer Supervisor routes the order back to the Hearing Officer if necessary for further action

4. The System alerts all parties of Initial Order issuance. Included in the notice of Initial Order are timelines for Petitions for Reconsideration and Appeal of Initial Order and reconsideration of the Final Order, as specified by policy

5. The Appeals Administrative Processing Unit prints a hard copy of the Initial Order, and mails it to the Appellant

6. The System documents when the Initial Order was mailed to the Appellant, in order to begin the determination of timeliness of petitions

7. If any party to the Appeal chooses to Petition for Reconsideration of the Initial Order (in writing – cannot be by phone)

a. The Petition for Reconsideration of Initial Order is documented in the System

b. The System determines if petition complies with timeliness filing requirements

i. If Petition for Reconsideration of Initial Order complies with filing requirements

(1) The System alerts the Hearing Officer of the acceptance of a Petition

(2) The System issues a receipt to all parties

(3) Hearing Officer reviews Petition for Reconsideration of Initial Order and responds with:

(a) Granting of Petition

(i). In the System, the Hearing Officer modifies the Initial Order

(ii). The System alerts all parties to the Appeal of the modified

Initial Order

(iii). The Appeals Administrative Processing Unit Worker prints a hard copy of the modified Initial Order, and mails it to the Appellant

(b) Reconvening of the Hearing

(i). In the System, the Hearing Officer enters an Order for Reconvening of the Hearing

P a g e | 203


(ii). The System alerts the Appeals Administrative Processing Unit Worker of the need to schedule a reconvening of the Hearing

(iii). The Appeals Administrative Processing Unit Worker schedules the hearing

(iv). The System notifies the Appellant of the hearing

(c) Denial of Petition

(i). In the System, the Hearing Officer enters a Denial of Petition for Reconsideration of Initial Order

(ii). The System alerts all parties to the Appeal of the Denial of Petition for Reconsideration of Initial Order

ii. If the petition does not comply with filing requirements the System alerts all parties that the petition was not accepted

8. If any party to the Appeal chooses to submit a Petition for Appeal of Initial Order

a. The party submits a Petition for Appeal of Initial Order

b. The System determines if a Petition for Reconsideration of Initial Order has been filed

i. If Hearing Officer has not reviewed the Petition for Reconsideration of Initial Order, the System updates the status of the Petition for Appeal of Initial Order as on hold, pending Petition for Reconsideration of Initial Order review by the Hearing Officer

ii. If Hearing Officer has reviewed the Petition for Reconsideration of Initial Order, and either reconvened the Hearing or granted the Petition for Reconsideration of Initial Order

(1) The System updates the status of the Petition for Appeal of Initial Order as moot

(2) The System alerts all parties of the Appeal that the Petition for Appeal of Initial Order has been deemed moot, given the reconvening of the Fair Hearing or the granting of the Petition for Reconsideration of Initial Order

c. The System determines if the petition complies with timeliness filing requirements

i. If petition complies with filing requirements:

(1) The System alerts the Commissioner’s Designee of the Appeal of Initial Order

(2) Issues a receipt with deadline for filing additional briefs

(3) Parties file briefs (see Use Case 40: Process Paper Documentation)

(4) The Commissioner’s Designee reviews Petition for Appeal of Initial Order and responds with:

(a) Granting of Petition with Order to Vacate and Remand the Initial Order

(i). In the System, the Commissioner’s Designee vacates and remands the Initial Order

P a g e | 204


(ii). The System alerts all parties to the Appeal of Order to Vacate and Remand the Initial Order

(iii). Appeals Administrative Processing Unit Worker prints a hard copy of the Order to Vacate and Remand Initial Order, and mails to all parties

(iv). The System alerts the Appeal to the Hearing Officer for further action (Step 1 of Main Flow)

(b) Granting of Petition with Order to Reconvene the Hearing

(i). In the System, the Commissioner’s Designee enters an Order for Reconvening of the Hearing

(ii). The System alerts the Appeals Administrative Processing Unit Worker of the need to schedule a reconvening of the hearing

(iii). An Appeals Administrative Processing Unit Worker schedules the hearing (see Use Case 33: Conduct Hearing)

(c) Deny the Petition for Appeal of Initial Order

(i). In the System, the Commissioner’s Designee enters a Denial of Petition for Appeal of Initial Order

(ii). The Order becomes Final

(iii). The System alerts all parties of the Final Order

ii. If petition does not comply with filing requirements, the System alerts the Appellant that the petition was not accepted

iii. If TDHS takes no action on the petition within a specified number of days (per TDHS policy), the System issues a notice informing the Appellant that the petition was denied

iv.

9. The System marks the Initial Order as the Final Order if:

A specified number of days (defined in Tennessee state law) have elapsed following Initial Order and neither a Petition for Reconsideration of Initial Order nor a Petition for Appeal of Initial Order has been filed by any party to the appeal

The Petition for Reconsideration of Initial Order has been denied, with no Petition for Appeal of Initial Order filed after a specified number of days (defined in Tennessee state law)

Petition for Appeal of Initial Order denied

Appeal was related to a TDHS program, where Initial Order is considered final, with no petition rights, per TDHS policy.

10. If the Appellant chooses to Petition for Reconsideration of the Final Order

a. The Appellant submits a Petition for Reconsideration of Final Order

b. The System determines if petition complies with timeliness filing requirements

i. If Petition for Reconsideration of Final Order complies with filing requirements:

P a g e | 205


(1) The System alerts the Commissioner’s Designee of the Petition for Reconsideration of Final Order

(2) The Commissioner’s Designee reviews the Petition for Reconsideration of Final Order and responds with:

(a) Granting of Petition

(i). In the System, the Commissioner’s Designee issues a Final Order

(ii). The System alerts all parties to the Final Order

(iii). An Appeals Administrative Processing Unit Worker prints a hard copy of modified Final Order, and mails to the Appellant

(iv). If the modified Final Order finds in favor of the Appellant, an Appeals Implementation Unit Worker initiates any required action, in coordination with TDHS program

(b) Vacate and remand

(i). In the System, the Commissioner’s Designee vacates and remands the Final Order

(ii). The System alerts all parties to the Appeal of Order to Vacate and Remand the Final Order

(iii). Appeals Administrative Processing Unit Worker prints a hard copy of the Order to Vacate and Remand Final Order, and mails to all parties

(iv). The System routes the Appeal to the Hearing Officer for further action (Step 1 of Main Flow)

(c) Reconvening of the Hearing

(i). In the System, the Commissioner’s Designee enters an Order for Reconvening of the Hearing

(ii). The System alerts an Appeals Administrative Processing Unit Worker of the need to schedule a reconvening of the Hearing

(iii). An Appeals Administrative Processing Unit Worker schedules the Hearing

(d) Denial of Petition

(i). In the System, the Commissioner’s Designee enters a Denial of Petition for Reconsideration of Final Order

(ii). The System alerts all parties to the Appeal of the Order

ii. If petition does not comply with filing requirements the System alerts the Appellant the petition was not accepted

iii. If TDHS takes no action on the petition within a specified number of days (per TDHS policy), the System issues a notice informing the Appellant that the petition was denied

11. If the Appellant chooses to Petition for Judicial Review of the Final Order

P a g e | 206


a. The Appellant files a Petition for Review in a Chancery Court of Tennessee (i.e., the Chancery Court with jurisdiction of the appeal, per State and TDHS policy)

b. The Appellant serves the Tennessee Attorney General, who informs TDHS General Counsel

c. Upon notification by the General Counsel, in the System, the Appeals Administrative Processing Unit marks the appeal as under Petition for Judicial Review

i. The System will provide a means to create a record for Judicial Review

d. If a hearing is scheduled by the Chancery Court, the Appeals Administrative Processing Unit Worker prepares legal documents (e.g., transcript of hearing, copy of administrative record) and it is reviewed by Appeals Case Prep Unit Attorney

e. When the Chancery Court has issued an order

i. In the System, the Appeals Administrative Processing Unit Worker documents the decision / order

ii. The Appeals Administrative Processing Unit Worker alerts the Appeals Implementation Unit to take the appropriate follow-up actions

12. If / when either no petitions have been filed, or any / all petitions have been denied or resulted in no modification of the Initial or Final Order:

a. If the Customer elected to receive a Continuation of Benefits during the appeal process, the System determines whether there is a benefit discrepancy (overpayment) for the Customer, calculates the amount of the benefit discrepancy, and alerts TDHS program Integrity staff. See Use Case 36: Program Integrity – Establish Recovery

b. The System alerts the Appeals Implementation Unit Worker to review and take the appropriate follow-up actions, in coordination with TDHS program Staff

c. In the System, the Appeals Implementation Unit Worker documents any follow-up actions

d. If there are no follow-up actions, the System marks the appeal as closed

e. When all follow-up actions are complete, the Appeals Implementation Unit Worker marks the appeal as closed in the System

i. The System alerts the Appeals Implementation Unit Worker if the actions are not completed within a timeframe determined by the order




Use Case 33: Conduct Hearing

Use Case 13: Process Provider License Application

Use Case 28: Modify Child Support Case

Use Case 36: Program Integrity – Establish Recovery

P a g e | 207



None

P a g e | 208


4.6 Program Integrity

4.6.1 Workflow WF38: Program Integrity – Referral Identification

Figure 49. Workflow WF38: Program Integrity – Referral Identification

P a g e | 209


4.6.2 Workflow WF39: Program Integrity – Establish Recovery

Figure 50. Workflow WF39: Program Integrity – Establish Recovery

P a g e | 210


4.6.3 Workflow WF40: Program Integrity – Benefit Recovery

Figure 51. Workflow WF40: Program Integrity – Benefit Recovery

P a g e | 211


4.6.4 Use Case 35: Program Integrity – Referral Identification

Use Case ID / Title Use Case 35: Program Integrity – Referral Identification

Actor(s) Customer


Program Integrity Special Investigator

TDHS Worker


The purpose of this use case is to enable any person to submit a referral for a possible overpayment, program violation and / or benefit tracking via multiple channels (e.g., phone, hardcopy, e-mail, TDHS Enterprise Portal). Once received, the referral is logged and triaged to the appropriate team for investigation and possible resolution.

In cases where USDA has identified a referral, e.g., those involving a SNAP

retailer, Alternative Flow A captures the process for handling such referrals.


Self-Service

The System will significantly enhance the ability for any person to submit Program Integrity referrals via electronic means

Responsiveness

The System will minimize the time required to gather, process and share information necessary to process, triage and investigate and resolve Program Integrity referrals

Data Access

The System will enhance TDHS Workers access to Customer information per a Program Integrity referral


The System will enhance TDHS' ability to standardize processes related to identifying and processing Program Integrity referrals


The System will support interfaces to internal and external sources and the exchange of information related to a Program Integrity referral

Trigger Events(s) The Program Integrity Specialist receives a referral regarding a Customer or a worker, or a provider.

Pre-Condition(s) None

Post-Condition(s) The referral is logged, triaged (to an external Agency, to TDHS Investigation team) and investigated

If the referral is confirmed to be a benefit discrepancy not resulting from a Suspected Intentional Program Violation (SIPV), a claim is created for the benefit discrepancy, and an assessment is made to determine the type of recovery

If the referral is confirmed to be a benefit discrepancy resulting from a SIPV, the referral is sent to the TDHS Appeals and Hearings Division for resolution


1. A person submits a referral for a possible overpayment, program violation and / or benefit tracking using any channel, including but not limited to:

Phone

P a g e | 212


Hardcopy

E-mail

SMS (text)


2. The System captures all available referral information as follows:

If TDHS receives a hardcopy of the referral, at a TDHS facility via mail or in person, a TDHS Worker enters the information in the System (see Use Case 40: Process Paper Documentation)

If TDHS receives a referral via phone, a TDHS Worker enters the referral information in the System (see Use Case 39: Receive Customer Communication)

If TDHS receives a referral via e-mail or SMS, a Program Integrity Specialist enters the information in the System (see Use Case 39: Receive Customer Communication)

If TDHS receives a referral from USDA, see Use Case 35: Alternative Flow A – Referral Involving a Retailer

3. Upon referral information being documented in the System, for each person(s) or organization(s) associated with the referral, the System checks to see if the person(s) or organization(s) are known to the System

a. If the person or organization is not found in the System

i. The System alerts a Program Integrity Specialist to review the referral any available information

ii. The Program Integrity Specialist reviews the referral to determine if it should be closed due to insufficient information.

iii. The Program Integrity Specialist determines if the referral should be transferred to a different department / agency

(1) If the referral involves a different Tennessee State department / agency, the Program Integrity Specialist documents the transfer and alerts the appropriate department / agency

(2) If the referral involves a TDHS Worker, the Program Integrity Specialist documents the transfer of the referral to Tennessee Department of Human Resources (HR) and alerts HR

b. If the person or organization is found in the System

i. The System assigns the referral to a Program Integrity Specialist and sends the referral information to the investigation case management system

ii. The Program Integrity Specialist confirms the referral should be associated with an existing Customer / Service Provider’s case file

iii. If the referral is associated with a Service Provider, the System alerts the appropriate TDHS program that a referral has been received for a Service Provider, and documents that the referral has been transferred

iv. If an active investigation is already underway for the same Customer, the System alerts the appropriate Program Integrity Specialist and sends the new referral information to the investigation case management system

P a g e | 213


v. If this is a new investigation for the Customer, the System alerts a Program Integrity Specialist to conduct an investigation

4. The Program Integrity Specialist conducts the investigation of the referral and confirms whether a benefit discrepancy exists

5. If no benefit discrepancy is found

a. In the System, the Program Integrity Specialist updates the investigation results

b. The Program Integrity Specialist closes the referral

6. If a benefit discrepancy is found

a. In the System, the Program Integrity Specialist documents any additional information, as appropriate

b. The Program Integrity Specialist documents the reason for the benefit discrepancy, including:

» Inadvertent Customer error

» Inadvertent household error

» Administrative error (caused by TDHS)

» Suspected Intentional Program Violation (SIPV)

c. The System calculates the benefit discrepancy amount

d. If the benefit discrepancy is not a result of a SIPV

i. The Program Integrity Specialist creates a claim for the referral

ii. The Program Integrity Specialist confirms the benefit discrepancy amount

iii. If / as needed, the Program Integrity Specialist updates the Customer’s case file with relevant referral information. See Use Case 10: Process Customer Change

iv. The Program Integrity Specialist determines how to proceed with benefit recovery. See Use Case 36: Program Integrity – Establish Recovery

e. If the benefit discrepancy is a Suspected Intentional Program Violation (SIPV)

i. The System assigns the referral to a Special Investigator

ii. The Special Investigator confirms the referral meets the criteria of a SIPV, confirms the benefit discrepancy amount, and any other referral / case details, etc.

iii. If the Special Investigator determines the referral does not meet SIPV criteria

(1) The Special Investigator re-classifies the referral as a non-SIPV referral

(2) The System alerts the Program Integrity Specialist to review the referral and take the appropriate follow-up action

iv. If the Special Investigator determines the referral meets SIPV criteria, the Special Investigator determines if the SIPV referral should proceed for processing to:

P a g e | 214


» TDHS Appeals and Hearings (for an ADH) or an Administrative

Disqualification Waiver (ADW)

» A court with jurisdiction over the case

(1) If Appeals and Hearings, see Use Case 32: File Appeal Request

(2) If court:

(a) In the System, the Special Investigator marks that SIPV is being reviewed / heard in court.

(b) The Special Investigator creates an evidence packet for the District Attorney, of relevant case information

(c) When the court renders a decision, the Special Investigator documents the outcome in the System and takes the appropriate follow-up action. See Use Case 36: Program Integrity – Establish Recovery

4.6.4.2 Use Case 35: Alternative Flow A - Referral Involving a Retail

Establishment

1. USDA alerts TDHS of a retail establishments identified for fraud or abuse, via regularly provided report

2. A Program Integrity Specialist reviews the USDA report, and creates a referral for retail establishments identified in the USDA report, as appropriate

3. The Program Integrity Specialist conducts an investigation as appropriate, in an attempt to identify any / all Customers that are affiliated with the retail establishment and the referral

4. In the System, the Program Integrity Specialist creates a referral for any / all Customers party to the original referral from USDA

5. Proceed with Step 4 above in the Main Flow

4.6.4.3 Use Case 35: Alternative Flow B - Potential Discrepancy Identified By

Change of Customer Information

1. When a potential discrepancy is identified by the System or the TDHS Worker during the processing of a Customer change (see Use Case 10: Process Customer Change), the System creates a referral for the Customer, including all information about the change and benefit change.

2. Proceed with Step 4 above in the Main Flow







P a g e | 215




Investigation case management system

USDA program integrity interface

P a g e | 216


4.6.5 Use Case 36: Program Integrity – Establish Recovery

Use Case ID / Title Use Case 36: Program Integrity – Establish Recovery

Actor(s) Customer


TDHS Program Worker


The purpose of this use case is to establish the mechanisms necessary to recover overpayment(s) made to a Customer. In certain cases, a Customer will receive benefits in an amount greater than what is allowed for by TDHS program policy. This can occur when a Customer does not report a change in circumstance within a timeframe specified by the program policy or during recertification or SR.

Overpayments can be collected by the flowing methods:

Recoupment where a portion of the Customer’s future benefits are withheld over a designated timeframe

Repayment (installment) plans, where the Customer makes direct payments to the State

Tax offset where overpayments are deducted from Federal tax refunds

Other methods per the State

The Program Integrity Specialist defines the overpayment collection method and records it in the System.

When a Customer receives benefits in an amount less than what it is allowed for by TDHS program policy, the TDHS Program Worker processes the underpayment and establish a reimbursement method.



The System will provide Customers with different methods to return funds to TDHS


The System will reduce the time required to gather, process and share information necessary for analysts to determine leading causes of overpayments


The System will support TDHS' ability to standardize processes related to establishing recovery per a Program Integrity related claim

Trigger Events(s) The System has identified an overpayment and has added the case to the queue of cases that require attention from the Program Integrity Specialist

Pre-Condition(s) The Program Integrity Specialist has logged into the System

A benefit discrepancy has been identified

Post-Condition(s) A recovery method has been established or updated


1. The Program Integrity Specialist reviews the claim and the results of an investigation (see Use Case 35: Program Integrity – Referral Identification). The information displayed by the System for each claim may include, but is not limited to, the following:

Type of benefit discrepancy (overpayment)

P a g e | 217


— Inadvertent Customer Error

— Inadvertent household error

— Administrative Error

— Intentional program violation

Total overpayment amount across all programs for which a Customer is receiving benefits

Overpayment amount for each program for which a Customer is receiving benefits

Number of days outstanding, if any

Number of days until the Customer’s redetermination

Reason for the overpayment identified by the Investigator

Duration of inactivity on the overpayment, if any

Current collection method, if any

2. The Program Integrity Specialist determines how to proceed. Options may include, but are not limited to:

Writing off the funds

Collecting the funds – Options to collect the overpayment amount may include but are not limited to:

— Recovering funds by recouping benefits issued to the Customer

— Creating a repayment plan for the Customer, and confirming with the Customer

3. If the Program Integrity Specialist chooses to write off the overpayment amount

a. In the System, the Program Integrity Specialist indicates a reason to write off the funds

b. The Program Integrity Specialist closes the claim

4. If the Program Integrity Specialist chooses to collect the overpayment amount

a. For Customers scheduled to receive benefits for subsequent months

i. In the System, the Program Integrity Specialist creates a recoupment plan, by calculating a certain percentage of the Customer’s benefits to withhold, until the overpayment balance is reduced to zero

ii. The System updates the Customer record with the amount and duration of the recoupment and allocates the recoupment of the appropriate funds

iii. The System issues a notification to the Customer (also called the “Notice of Adverse Action”). This notice may include, but is not limited to, the following information:

» Summary information related to the claim

» Information regarding the recoupment of future benefits

» Instructions for optionally repaying the overpayment amount through means

other than the benefit recoupment plan

P a g e | 218


» Rights and instructions to appeal the claim

b. For Customers whose benefits have expired or are set to expire before the overpayment amount can be recouped

i. In the System, the Program Integrity Specialist creates a repayment plan, by calculating a payment amount and the number of payments required to resolve the overpayment (including recoupment of current benefits, as applicable)

ii. The System creates and sends a demand letter to Customer. The information in this notice includes, but is not limited to:


» Recoupment information, if applicable

» Summary of repayment plan

» Delinquency date (date by which the benefit discrepancy will be repaid, or a

recovery plan established, or the discrepancy amount is considered delinquent)

» Instructions to submit a payment, per repayment plan, including the date by

which payments will be received

» Instructions for contacting TDHS to discuss the repayment plan


iii. At regular intervals, determined by TDHS, the System alerts the Customer of claim recovery status. Each of these notices may include, but is not limited to, the following information:


» Recoupment information, if applicable

» Summary of repayment plan

» Delinquency date (date by which the benefit discrepancy will be repaid, or a

recovery plan established, or the discrepancy amount is considered delinquent)

» Instructions to submit a payment, per repayment plan, including the date by

which payments will be received

» Instructions for contacting TDHS to discuss the repayment plan


iv. If at the time of the delinquency date, the Customer has not repaid the overpayment amount, or agreed to a repayment plan

(1) The System creates and sends a demand letter to the Customer. This notice may include, but is not limited to, the following:

Summary information related to the claim

P a g e | 219


Summary of the additional recovery methods TDHS is pursuing

Instructions to submit a payment

Instructions for contacting TDHS to discuss the repayment

Rights and instructions to appeal the claim

(2) The System alerts the Program Integrity Specialist of the need to identify additional recovery methods (e.g., initiating a collection from the head of the household or any adult Customer who was a member of the household in which the over issuance occurred), per TDHS policy. See Use Case 37: Program Integrity – Benefit Recovery

4.6.5.2 Use Case 36: Alternative Flow A — Underpayment

1. The System identifies claims with underpayments based on the results of referral investigates (see Use Case 35: Program Integrity – Referral Identification).

2. The TDHS Program Worker reviews the claims, including the following for each:

Total underpayment amount across all programs, and for each Program, for which a Customer is receiving benefits.

The rules in effect at the time of the underpayment is applied q

Underpayment amount for each issuance period is calculated q

Reason for the underpayment

3. The TDHS Program Worker selects a claim with an underpayment to process

4. The TDHS Program Worker determines the reimbursement method

5. The System issues the reimbursement to the Customer along with a notification that describes the underpayment

6. The TDHS Program Worker closes the claim

4.6.5.3 Use Case 36: Alternative Flow B – Appellant Receiving COB Loses Appeal

1. If the Appellant loses the appeal, when the final order is entered into the System

a. The System calculates the benefit discrepancy amount (the amount the Customer owes from the COB while pending appeal) and alerts TDHS program Integrity staff. See Use Case 36: Program Integrity – Establish Recovery

b. The System alerts the Appellant a notice of the claim

2. Proceed with Step 1 in the main flow.



Use Case 34: Issue Appeal Decision / Order

Use Case 35: Program Integrity – Referral Identification

Use Case 37: Program Integrity – Benefit Recovery

P a g e | 220



None

P a g e | 221


4.6.6 Use Case 37: Program Integrity – Benefit Recovery

Use Case ID / Title Use Case 37: Program Integrity – Benefit Recovery

Actor(s) Customer


Program Integrity Fiscal Services Worker


The purpose of this use case is to document the process to track the recovery of overpayment claims made to a Customer via multiple collection methods – recoupment, repayment plans, tax offset or other methods per the State.



The System will provide Customers with a seamless method to receive underpayments


The System will reduce the time required to gather, process and share information necessary for analysts to determine leading causes of overpayments


The System will support TDHS' ability to standardize processes related to establishing recovery per a Program Integrity related claim


The System will support interfaces to internal and external sources and the exchange of information related to a Program Integrity referral

Trigger Events(s) The System has established a recovery method for an overpayment claim and has added the case to the queue of cases that require attention from the Program Integrity Specialist

Pre-Condition(s) The Program Integrity Specialist has logged into the System

A recovery method has been established or updated

Post-Condition(s) If recovery method for overpayment claim is recoupment, repayment is tracked until Customer pays in full and referral case is closed

If recovery method for overpayment claim is repayment plan or one- time direct payment method, repayment is tracked until Customer pays in full and referral is closed

If recovery method for overpayment claim is repayment plan or one- time direct payment method, and payment is delinquent, the Program Integrity Specialist, attempts to proceed with actions (e.g., tax offset, re-allocation of underpayment, expungement of benefits) or determines write-off amount


1. For each overpayment claim being repaid via benefit recoupment

a. For each payment received via the recoupment of benefits

i. The System credits the amount of the benefit recoupment against the claim

ii. The System recalculates the outstanding claim amount

P a g e | 222


iii. If the full amount is recovered prior to the benefit end-date the System issues a notification to the Customer that the claim has been closed

b. If the full amount is not recovered prior to the benefit end date

i. The System alerts the Program Integrity Specialist to review the claim and the Customer’s record

ii. The System alerts the Customer, informing the Customer that their benefits are scheduled to end before the claim is paid

iii. The Program Integrity Specialist reviews the information and establishes and alternate payment plan (see the Use Case 36: Program Integrity – Establish Recovery)

2. For each overpayment claim being repaid via repayment plan

a. TDHS receives the payment via mail. See Use Case 39: Receive Customer Communication

b. A TDHS Worker alerts a TDHS Fiscal Services Worker to review and process the payment

c. A TDHS Fiscal Services Worker deposits the payment amount in a TDHS account, per TDHS policy

d. The TDHS Fiscal Services Worker reviews the payment in an attempt to identify the Customer and claim to which the payment is associated

e. If / when the TDHS Worker identifies the Customer and claim to which the payment is associated:

i. In the System, the TDHS Worker applies the payment amount against the claim

ii. The System recalculates the outstanding amount

iii. The System displays the payment amount, and the remaining balance

iv. The System sends the Customer a receipt of the payment, and the remaining balance

f. If / when the full amount is repaid the System issues a notification to the Customer that the claim has been paid and that the claim is closed

g. If a payment is not paid in full, per the recovery plan

i. If no payment is received, at a specified time following the payment due date (e.g., 30 days), per TDHS policy, the System alerts the Customer of the payment delinquency and advising the Customer of delinquent payment processing, per TDHS policy

ii. If no payment is received, at a specified time following the payment due date (e.g., 60 days), per TDHS policy, the System alerts the Customer of the payment delinquency and advising the Customer of delinquent payment processing, per TDHS policy

iii. If no payment is received, at a specified time following the payment due date (e.g., 180 days), per TDHS policy

P a g e | 223


(1) The System alerts the Customer of the payment delinquency and advising the Customer of delinquent payment processing, per TDHS policy

(2) The System submits the delinquent debt to the US Bureau of Fiscal Service for collection and inclusion in the TOP and certifies that the debts qualifies for collection by offset (e.g., the reduction or withholding of a payment from a federal or state program)

(3) If / as money is recovered via TOP

(a) The System receives information on recovered funds via TOP and updates the claim accordingly

(b) The IRS sends TDHS the funds

(4) If / when the delinquent funds are fully recovered

(a) The System submits a notice to TOP that the delinquent debt has been fully recovered





Treasury Offset Program

State accounting system (Edison)

P a g e | 224


4.7 Shared Capabilities

4.7.1 Overview Workflow O7: Shared Capabilities

Figure 52. Overview Workflow O7: Shared Capabilities

P a g e | 225


4.7.2 Workflow WF41: Schedule an Appointment

Figure 53. Workflow WF41: Schedule an Appointment

P a g e | 226


4.7.3 Workflow WF42: Process Customer Communication

Figure 54. Workflow WF42: Process Customer Communication

P a g e | 227


4.7.4 Workflow WF43: Process Paper Documentation

Figure 55. Workflow WF43: Process Paper Documentation

P a g e | 228


4.7.5 Workflow WF44: Manage Referral

Figure 56. Workflow WF44: Manage Referral

P a g e | 229


4.7.6 Workflow WF45: Search & Lookup Customer

Figure 57. Workflow WF45: Search & Lookup Customer

P a g e | 230


4.7.7 Workflow WF46: View Alerts

Figure 58. Workflow WF46: View Alerts

P a g e | 231


4.7.8 Workflow WF47: Send and Receive Secure Messages

Figure 59. Workflow WF47: Send and Receive Secure Messages

P a g e | 232


4.7.9 Workflow WF48: Contact TDHS Service Center

Figure 60. Workflow WF48: Contact TDHS Service Center

P a g e | 233


4.7.10 Workflow WF49: Manage Caseloads

Figure 61. Workflow WF49: Manage Caseloads

P a g e | 234


4.7.11 Workflow WF50: Access and View Standard & Dashboard Reports

Figure 62. Workflow WF50: Access and View Standard & Dashboard Reports

P a g e | 235


4.7.12 Workflow WF51: Create Ad Hoc Queries and Reports

Figure 63. Workflow WF51: Create Ad Hoc Queries and Reports

P a g e | 236


4.7.13 Use Case 38: Schedule an Appointment

Use Case ID / Title Use Case 38: Schedule an Appointment

Actor(s) Customer

Service Provider

TDHS Worker


This use case documents the process for a Customer or a Service Provider to schedule an appointment for a variety of reasons which may include, but are not limited to:

Interviews

Development of a FF-PRP

Medical Incapacity verification appointment

Child Care eligibility discussion

Child Care licensing / authorized professional

Appeal hearing

Unspecified reason

The System will allow the Customer or Service Provider to schedule an appointment that can take place in person or over the phone. The System will allow the Customer / Service Provider to request a translator or other accommodation.

The process in the main flow is the same for TDHS Workers scheduling

appointments, including on behalf of a Customer or a Service Provider.

As alternative flows, this use case includes the process for cancelling / rescheduling and appointment, and System scheduled appointments.


Self-Service


Responsiveness

The System will minimize the time required to gather, process and share information necessary to schedule or reschedule an appointment


The System will enhance TDHS' ability to provide Customer- specific services in the scheduling and rescheduling of appointments

Universal Case Load

The System will enhance TDHS' ability to serve its Customers by providing accurate appointment availability information


The System will standardize the process for scheduling or rescheduling appointments

Trigger Events(s) The Customer, Service Provider, or TDHS Worker wishes to schedule an appointment

Pre-Condition(s) Schedule availability per appointment type

Post-Condition(s) The Customer or Service Provider has scheduled an appointment with an appropriate TDHS Worker (e.g., Eligibility Worker, Program Integrity Specialist)

The System has updated the appointment calendar

P a g e | 237


Use Case ID / Title Use Case 38: Schedule an Appointment

The System has generated a notification to the Customer / Service Provider with the appointment details


1. The Customer / Service Provider or TDHS Worker accesses the TDHS Enterprise Portal and selects the option to schedule an appointment

2. The System document who needs the appointment:

Customer

Service Provider

Authorized Representative on behalf of Customer

TDHS Worker

3. The System presents a list of appointment types and the Customer / Service Provider or TDHS Worker selects an appointment type including but not limited to:

Interviews

Development of a FF-PRP

Medical Incapacity verification appointment

Child Care eligibility discussion

Child Care licensing / authorized professional

Appeal hearing

Unspecified reason

4. The System recommends an appointment setting (e.g., phone / video vs. in-person), based on appointment type. For in-person appointments, the System displays a list of alternatives, based on the Customer / Service Provider’s address information and the appointment type, per TDHS policy, or the office address of the TDHS Worker

5. The Customer / Service Provider or TDHS Worker confirms appointment setting

In person, including location selection

Via telephone / video conference

6. If the appointment will be held by phone, the Customer / Service Provider or TDHS Worker confirms the contact phone number on file

a. If the phone number is not already in the System, the Customer / Service Provider or TDHS Worker enters the phone number

7. The Customer / Service Provider or TDHS Worker selects the appointment language required or requests translation services

8. The System presents the available time slots, based on

Options chosen for the appointment type and setting

TDHS resource availability

Program / policy timeframes, per TDHS policy

P a g e | 238


9. The Customer / Service Provider or TDHS Worker chooses an appointment date and time preference

10. The System schedules the appointment according to the Customer’s / Service Provider or TDHS Worker’s preference, and updates the availability of TDHS resources,

a. If the appointment requires multiple TDHS resources, the System ensures this requirement is documented

11. Upon scheduling an appointment, the System alerts the Customer / Service Provider or TDHS Worker of the appointment, as applicable. This alert includes, but may not be limited to:

Date

Time

Setting (phone / video, location)

4.7.13.2 Use Case 38: Alternative Flow A – Rescheduling or Cancelling an

Appointment

1. The Customer / Service Provider or TDHS Worker accesses the TDHS Enterprise Portal and selects the option to cancel or reschedule an existing appointment

2. The System displays the appointment(s) for which the Customer / Service Provider or TDHS Worker is scheduled, and the Customer / Service Provider or TDHS Worker selects the appointment to be changed

3. The Customer / Service Provider or TDHS Worker indicates in the System if the appointment is to be cancelled or rescheduled

a. If the Customer / Service Provider or TDHS Worker is cancelling the appointment, the System removes the appointment

b. If the Customer is rescheduling the appointment, the System removes the original appointment and processing continues from Step 3 of the Main Flow

4.7.13.3 Use Case 38: Alternative Flow B – System Schedules an Appointment

1. The System determines that an appointment needs to be scheduled, per Customer / Service Provider case file disposition and TDHS policy

2. Per appointment type, the System determines the TDHS resources needed, setting and date / time requirements

3. The System schedules the appointment and updates the availability of TDHS resources

4. The System creates a notification to the Customer / Service Provider. The notification includes, but is not limited to the following appointment information:

Date

Time

Setting (phone / video, location)


Use Case 45: Customer Search and Lookup

P a g e | 239



None

P a g e | 240


4.7.14 Use Case 39: Receive Customer Communication

Use Case ID / Title Use Case 39: Receive Customer Communication

Actor(s) Customer

TDHS Worker


This use case documents the process for a Customer to contact TDHS from a number of channels, including but not limited to telephone, email, fax, and other communication channels identified by TDHS.

Customers seeking information or to make a change on their case information for Families First, SNAP, Child Care, and Child Support programs are encouraged to contact the TDHS Service Center or SDU. Customers may also contact a field office or other organization within TDHS


Self-Service



The System will enhance TDHS' ability to provide Customer- specific support when receiving Customer communications


The System will enhance TDHS' ability to store Customer information per Customer communications


The System will decrease the need for paper when storing Customer information

Responsiveness

The System will enhance TDHS' ability to be responsive to Customer communications

Trigger Events(s) The Customer contacts TDHS

Pre-Condition(s) None

Post-Condition(s) The Caller’s information has been documented


1. The Customer contacts TDHS via one of many available channels including, but not limited to:

Telephone call (including calls received by Tennessee’s Public Information Legislative Office, which are routed to TDHS)

Email

Fax

Other communication channels, as identified by TDHS

2. The TDHS Worker categorizes the nature of the contact, and records the contact in the System. The category include but are not limited to:

Customer inquiry – Members of the public inquiring about program rules and application process

P a g e | 241


Case status – Customers seeking information about an existing case

Customer change – Customer contacting TDHS to update information on their case file

Customer issue / complaint

Fraud & abuse referral (Program Integrity)

3. Based on the type of contact selected, the TDHS Worker documents information regarding the contact, including but not limited to:

Primary language of the Customer

Customer name

Reason for the call (e.g., information requested)

a. If the contact is an inquiry, the TDHS Worker responds to the Customer’s inquiry and enters the resolution, as applicable

b. If the contact involves a Customer inquiring about the Customer’s case, the TDHS Worker verifies the Customer’s identity (per TDHS policy) and responds to the Customer’s inquiry

c. If the contact involves a Customer seeking to update information, the TDHS Worker verifies the Customer’s identity (per TDHS policy) and in the System records the updated information (see Use Case 09: Submit Self-Reported Change)

4. If the TDHS Worker cannot address the Customer’s issue, the TDHS Worker documents information related to the contact, and recommends appropriate follow-up action

a. The TDHS Worker provides the Customer with the contact information of the person or organization where the issue can be addressed


None


None

P a g e | 242


4.7.15 Use Case 40: Process Paper Documentation

Use Case ID / Title Use Case 40: Process Paper Documentation

Actor(s) TDHS Documentation Processing Worker

Customer

Service Provider


When a Customer or Service Provider provides paper documents to TDHS, they may either drop-off the required documents at a TDHS field office, or mail the documents to a TDHS Service Center. Once the documents are scanned, they are attached to the appropriate electronic case file.


Responsiveness

The System will increase effectiveness and efficiency of TDHS Workers at TDHS facilities, enabling them to focus on Customer- centric tasks

cannot complete the self-service application by themselves


The System will decrease the occurrence of missing documents

The System will decrease the use of paper when storing Customer information

Centralization of Mail

The System will support the centralization of TDHS mail services

Trigger Events(s) Documents have been received

Pre-Condition(s) The Customer or Service Provider has sent to, or dropped off documents at, a TDHS field office or Service Center

Post-Condition(s) The new documents have been scanned and attached to the appropriate case file

The System has reviewed the Customer’s case and identified required actions that may result from the submittal of the document

The System issues a confirmation to the Customer that the document(s) has been received

Hard copies of the documents received have been filed appropriately their physical location recorded in the System, and scheduled for retention per TDHS document retention policy


1. The TDHS Documentation Processing Worker retrieves the provided documents

a. If the sender has provided original official documents (e.g., driver’s license or passport), the Documentation Processing Worker makes a copy of the document and prepares the original document to be returned to the sender

2. The TDHS Documentation Processing Worker scans the documents

3. The TDHS Documentation Processing Worker looks up the Customer or Service Provider to see if the sender already has a Customer or Service Provider record

a. If the sender is already in the System, the Documentation Processing Worker selects the Customer for whom they will be processing documentation

b. If the sender is not in the System or cannot be identified, see Use Case 40: Alternative Flow A

P a g e | 243


4. The TDHS Documentation Processing Worker categorizes the documents provided

a. If the document has a TDHS bar code, the System reads the barcode and identifies the document type

b. If the document does not have a TDHS bar code, the TDHS Documentation Processing Worker indicates the document type

c. For each document, the System allows the TDHS Documentation Processing Worker to enter additional information or comments in a free text box

5. The TDHS Documentation Processing Worker validates the scanned image against the paper documents to verify the electronic copy is acceptable quality

a. If the scanned images are not of acceptable quality, the TDHS Documentation Processing Worker deletes the file and repeats step 2

b. If the System recognizes that a blank document has been submitted, the System deletes the image and prompts the TDHS Documentation Processing Worker to repeat step 2

6. The System performs Optical Character Recognition (OCR) on the scanned document (as possible) and stores information as possible / appropriate

7. The System associates all attachments with the Customer record and with the appropriate program-specific application or redetermination

8. The System reviews the Customer’s case and identifies any actions that may result from the submittal of the document. Actions may include, but are not limited to, the following:

Review of application

Approval of payment

Recalculation of benefit amount

9. The System alerts the Customer of receipt of the document and next steps the Customer must take, as appropriate

a. If all information has been received for the program specific application or for a change in circumstance submission, the System flags the application for review by a TDHS Worker and indicates the documents have been received

10. The TDHS Documentation Processing Worker files the documents (non-originals only)

a. In the System, the TDHS Documentation Processing Worker document’s physical location

b. The System begins the timer indicating when the documents should be destroyed, per TDHS record retention policy

4.7.15.2 Use Case 40: Alternative Flow A – Documents Received Cannot Be Associated with a Case

1. The Documentation Processing Worker scans the documents

2. The Documentation Processing Worker attempts to associate the document to a case file by a variety of means, which may include, but are not limited to:

q Phonetic searches in the System

P a g e | 244


q Contacting the Sender to obtain more identifying information

3. If the document still cannot be associated to a case file, the Documentation Processing Worker enters available identifying information into the System (e.g., document type)

4. The System time stamps the entry and saves the document in the repository of documents that were unable to be associated with a case file

5. If additional identifying information is associated with the document in the future, the System associates the documents with a case file




Use Case 08: Conduct Medical Evaluation of Incapacity



Use Case 23: Calculate Child Support



None

P a g e | 245


4.7.16 Use Case 41: Manage Referral

Use Case ID/Title Use Case 41: Manage Referral

Actor(s) n TDHS Worker

n Service Provider

Background/Objectives A TDHS Worker, in collaboration and coordination with the Customer (or Applicant, in all references to the Customer throughout the use case), may decide that it is in the best interest of the Customer to pursue benefits, services or information provided by:

n Another TDHS Program or Division

n A different Tennessee State Department

n An external Service Provider

To do this, the TDHS Worker generates a “referral.” A referral is information about the Customer, including pertinent details about the Customer’s need for specific benefits, services or information, sent to another TDHS Program or Division, Tennessee Department, or external service provider.

The goal of the referral is to:

n Communicate the Customer’s need for the benefit, service or information

n Authorize the recipient to provide the benefit, service or information to the Customer

n In some cases, secure acknowledgment that the recipient has received the referral; and in other cases, secure the recipient’s acceptance or denial of the referral

Referrals serve many purposes and can range from offering supplemental services (e.g., providing TDHS sponsored child care for a Customer), to aiding in the process of receiving TDHS benefits or services (e.g., scheduling an interview or eligibility assessment), as well as enrolling in another Tennessee state program (e.g., Foster Care under the Tennessee Department of Child Services).

The System enables the management of referrals by providing TDHS Workers with ability to:

n Look up types of benefits and services available to the Customer

n Look up external service providers

n Generate the referral

n Transmit the referral

In this use case, the referral recipient may be an “internal” service provider (e.g., TDHS’ Division of Rehabilitation Services), another Tennessee state agency (e.g., Tennessee Department of Child Services) or an “external” service provider (e.g., a licensed child care provider). For external services providers, there may be the need for TDHS to secure the Customer’s consent, in order for information to be shared with the Service Provider, per TDHS policy and state and federal law.

At any point, a TDHS Workers may choose to view the status of a referral. The System provides TDHS Workers with access to referrals status, based on their privileges in the System. Alternative Use Case B covers such a situation.

TDHS Workers may also choose to update a sent referral, either by modifying it, or withdrawing it. In these cases, the System notifies the recipient service provider or program of the updated referral, and requests acknowledgement of the referral update.

P a g e | 246


Use Case ID/Title Use Case 41: Manage Referral

NOTE: This use case does not cover Program Integrity referrals. These referrals are addressed in Use Case 19: Program Integrity – Referral Identification



The System will enable TDHS Workers to create and manage referrals for Customers


The System will standardize how referrals are created and managed across TDHS programs

Data Access

The System will provide TDHS Workers with access to information relating to any Customer referral, as well as to responses from Service Providers and information on the provision of services, per the referral, as applicable

Customer-centric Service Management and Reporting

The System will provide for the management of the entire referral process, and capture metadata about referrals and their management, for reporting purposes

Responsiveness

The System will increase TDHS’ ability to create and manage the referral process, enhancing the Departments responsiveness to Customer needs

Eliminate Paper

The System will provide a means to electronically send, receive and manage referrals, as well as receive information from Service Providers per the referral

Universal Case Load

The System will support universal case load by providing any TDHS Worker with the appropriate privileges access to a Customer’s referral

Trigger Events(s) In the course of providing services, the TDHS Worker identifies a need to refer the Customer to another TDHS Program or Division, another Tennessee State Department or an external service provider

The System identifies the need for a referral based on new information entered or identified by the system (e.g., through data matching)

Pre-Condition(s) The Customer’s case file is in the System

The Service Provider or program is in the master provider index in the System

Post-Condition(s) The System generates a referral to the Service Provider or program


1. In the System, a TDHS Worker documents the need for a referral for a Customer.

a. If appropriate per TDHS policy, the TDHS Worker obtains the Customer’s approval for the referral, and documents this in the System

i. If the Customer denies the referral, the TDHS Worker documents this in the System

P a g e | 247


2. The TDHS Worker accesses the System, searches for the customer (see Use Case 42: Customer Search & Lookup) and selects the create referral option

3. The System provides a set of guided questions for the TDHS Worker to create a referral in a structured format

a. The System pre-populates editable fields in the referral with information of the referring party (TDHS Worker) based on the profile of the user logged into the System. This information may include, but is not limited to, the following:

— Date and time of the referral

— First and Last Name of referring party

— Title of referring party

— TDHS Program or Department of referring party

— Contact information (email, phone, etc.) of referring party

b. The System pre-populates editable fields in the referral with information of the Customer being referred. This information will applicable for the type of referral being created and may include, but is not limited to, the following:

— First and Last Name

— Date of Birth

— Language (include American Sign Language [ASL])

— Mobility/Disability

— Customer residential address

— Social Security Number

— Customer restrictions/preferences (as indicated in the Customer profile):

» Availability

» Best time to contact

— Customer identifier (in System)

4. The TDHS Worker selects a program/service for which the Customer is being referred from a list of available services types. Service types may include, but are not limited to:

Internal (TDHS)

— Child Care

— Child Support

— Family Assistance (Families First/SNAP)

— Vocational Rehabilitation

External

— Child Care

— Drug Testing

— Employment and Training (E&T)

P a g e | 248


— Employment Case Management Services (ECMS)

— Medical/Mental Health Evaluation for Incapacity

— Other

a. If the referral is to a Service Provider, the TDHS Worker searches for a Service Provider using any combination of filters that may include, but are not limited to, the following:

— Service Provider name

— Service Provider address

— Accepting new referrals

— Proximity to the Customer’s residential address

— Proximity to public transportation

— Languages spoken

— Disability access

— Priority service (e.g., children, abused women, medical needs, special conditions / chronic diseases, etc.)

b. The System displays a list of Service Providers who meet the criteria, and information on each service provider

c. The TDHS Worker selects one or more Service Providers from the list

5. The TDHS Worker documents additional information about the referral. Configurable referral elements may include, but are not limited to, the following:

Referral reason

— Program benefits or services information

— Program eligibility assessment

— Medical evaluation for eligibility

— Service information or delivery

— FF-PRP

— Employment/Training

— Welfare to Work

— Customer re-location

Referral type

— Mandatory – Referrals for services required of the Customer for participation in TDHS programs

— Voluntary – Referrals for services or information optional to the Customer

Referral urgency

— Standard

P a g e | 249


— Immediate / Urgent

Referral notes (free text)

Referral attachments

6. The TDHS Worker selects if a referral return receipt is required, and if so, what type, from the following:

Acknowledgement of referral (date for response optional)

Acceptance / Denial of referral (date for response optional)

Request for service event notifications

7. The System determines whether the referral requires TDHS to obtain the informed consent of the Customer in order for TDHS to share the Customer’s information with the Service Provider, based on TDHS policy (e.g., if the referral is to a Service Provider external to TDHS).

a. If the referral requires the Customer’s informed consent, the System displays an informed consent form that the Customer reviews and electronically signs for the referral

8. At any point in the process, the TDHS Worker can save the referral. The System stores any information entered in the referral, but does not send the referral until it is ready for submission

9. The TDHS Worker submits the referral

10. The System alerts the referral recipient (Service Provider(s)), appropriate TDHS Worker (e.g., Eligibility Worker) and Customer, via their preferred communication channel, indicating a referral was created

a. If the referral recipient is not a system user, the System options include, but are not limited to:

i. Entering an email address and emailing the referral to the Service Provider

ii. Emailing the referral to the Customer for Customer follow-up

iii. Mailing (if centralized mailing is available)

iv. Printing (for other mailing services, or for Customer follow-up)

b. If the updated referral requires acknowledgement or acceptance/denial, see Alternative Flow B: Acknowledge, Accept / Deny Referral

4.7.16.2 Use Case 41: Alternative Flow B – Acknowledge, Accept / Deny Referral

1. If the referral requires recipient acknowledgment, the referral recipient selects the acknowledge referral option on the TDHS Enterprise Portal

2. The referral recipient is provided a list of referrals which require acknowledgement and selects the referral from the list

a. The System provides a structured template for the recipient service provider or program to provide acknowledgement of the referral. The System uses known information based on the user’s profile to pre-populate this acknowledgement with editable text. This may include, but is not limited to, the following:

— Date and time of the acknowledgement

P a g e | 250


— First and Last name of referral recipient

— Organizational name of referral recipient

— TDHS Program or Division name (internal referrals only)

— Contact information of referral recipient (email, phone, etc.)

b. The recipient Service Provider or program enter optional notes (free text) associated with the acknowledgement

c. The recipient Service Provider or program submits the referral acknowledgement

d. The System sends the referral acknowledgement to the TDHS Worker who created the referral

3. If the referral requires acceptance or denial of the referral, the referral recipient accepts or denies the referral, as appropriate

a. The System provides a structured template for the referral recipient to accept or deny the referral. The System uses known information based on the user’s profile to pre-populate this acceptance or denial notification with editable text. This may include, but is not limited to the following:

— Date and time of the acceptance

— First and Last name of referral recipient

— Organizational name of referral recipient

— TDHS Program or Division name (internal referrals only)

b. If the referral recipient is denying the referral, the System requires the referral recipient to enter a reason for the denial, based on a list of denial reasons determined by TDHS

c. The recipient Service Provider or program enters notes (free text) associated with the acceptance or denial

d. The recipient Service Provider or program submits the referral acceptance or denial

e. The System sends the referral acceptance or denial to the TDHS Worker who created the referral

4. If the referral includes a request for information regarding services provided to the Customer, the Service Provider sends this information (see Use Case 44: Send and Receive Secure Messages). Information sent regarding referrals may include, but is not limited to:

q Date service(s) provided

q “Sub” referrals (to other orgs providing services, e.g., transportation services)

q Information/data on customer progress related to referral

4.7.16.3 Use Case 41: Alternative Flow C – Modify or Withdraw Referral

1. If the TDHS Worker needs to modify or withdraw a referral:

a. The TDHS Worker selects update referral

P a g e | 251


b. The TDHS Worker modifies the referral, or elects to withdraw the referral, as appropriate

c. The TDHS Worker saves the referral update

i. If the referral has been sent, the System alerts the referral recipient (Service Provider(s)), appropriate TDHS Worker (e.g., Eligibility Worker) and Customer, via their preferred communication channel, indicating the referral was updated

ii. If the updated referral requires acknowledgement or acceptance/denial, see Alternative Flow B: Acknowledge, Accept/Deny Referral

4.7.16.4 Use Case 41: Alternative Flow D – Generate Automated Referral

1. If, during import of data, a data matching processes, a process step, or other trigger, the System identifies the need for a referral based on configurable business rules:

a. The System populates the referral with as much information as possible based on information in the System or through another source (if provided)

b. The System creates the referral and sends it to the configured Service Provider or TDHS program or other Tennessee State agencies through the configured method

c. If the System determines that it cannot complete the referral with the information provided

i. The System saves the draft of the referral

ii. The System alerts the appropriate TDHS Worker and prompts them to start at the Main Flow, step 3.

4.7.16.5 Use Case 41: Alternative Flow E – View List of Referrals

1. If the TDHS Worker needs to view the list of referrals generated or received

a. In the TDHS Enterprise Portal, the TDHS Worker accesses a list of referrals, based on search criteria including but not limited to:

— Customer name

— Service/program requested

b. For each referral, the System displays summary information related to the referral, which may include, but is not limited to:

— Date and time of the referral

— Referring party name/program

— Customer name

— Service/program requested

— Referral urgency

— Referral status

c. The referral recipient selects a referral and reviews the referral, which may contain, but is not limited to:

— Referral reason

P a g e | 252


— Referral type

» Mandatory – Referrals for services required of the Customer for participation

in TDHS programs

» Voluntary – Referrals for services or information optional to the Customer

— Referral urgency

» Standard

» Immediate/Urgent

— Referral notes

— Referral attachments

— Referral return receipt requested

— Referral status

» Unsaved/Saved

» Unsent/Sent

» Pending acknowledgment

» Acknowledged

» Accepted (optional)

» Denied (optional)

» Service provider or program has made initial contact with Customer (optional)

» Appointment with Customer is scheduled (optional)

» Initial appointment with Customer completed (optional)



Use Case 25: Monitor and Enforce Obligations

Use Case 26: Establish Punitive Measures

Use Case 28: Modify Child Support Case

Use Case 31: Accept Child Support Referral


Use Case 44: Send and Receive Secure Messages


Department of Labor

Department of Children Services

TennCare

P a g e | 253


Department of Education

Department of Safety & Homeland Security

Department of Health

Department of Mental Health & Substance Abuse Services

THDA

Local & State Fire Department

P a g e | 254


4.7.17 Use Case 42: Customer Search & Lookup

Use Case ID/Title Use Case 42: Customer Search & Lookup


Customer

Note: Throughout this use case, the use of the term “Customer” includes Applicants and other individuals.

Background/Objectives This use case captures the process to identify and / or validate a Customer’s relationship with TDHS programs, and / or to view information about the Customer in the System. This function will be used whenever a TDHS Worker has a need to perform actions on behalf of a Customer in the System, and the Customer’s case file is not already active in the user’s screen.

In this use case, the TDHS Worker searches for a Customer in the System. The amount of Customer information viewable by the TDHS Worker is dependent on the TDHS Worker’s access rights in the System, per TDHS policy.

The ESM will contain a Master Customer Index (otherwise known as a master person index) that is a database that is used across the enterprise to maintain consistent, accurate and current demographic and essential data on the Customers served and managed within its various departments.

Additionally, this use case addresses the ability to search and lookup a family unit. For the purposes of the ESM, a family unit may consist of, at a minimum, one ARP, a caretaker, and at least one dependent (child). The ESM will be able to connect individuals to this family unit, as appropriate.


Data Access

The System will provide any TDHS Worker, with appropriate access rights, access to Customer information


The System will manage all relevant information pertaining to a Customer and the provision of program benefits or services to the Customer

Eliminate Paper

The System will provide electronic storage of the Customer’s case file, and an electronic means for managing all communications related to the Customer’s case file

Universal Case Load

The System will provide any TDHS Worker, with the appropriate privileges, access to the Customer’s case file

Trigger Events(s) TDHS Worker has a reason to identify whether a Customer, Applicant or other person has a person record within the System

TDHS Worker has reason to view a Customer’s information in the System

Pre-Condition(s) TDHS Worker has appropriate rights to access the System and perform the search function

P a g e | 255


Use Case ID/Title Use Case 42: Customer Search & Lookup

Post-Condition(s) The System displays Customer search results for use by the TDHS Worker or the System

If the System is able to uniquely identify the Customer, the TDHS Worker is able to navigate to more detailed Customer case file information or select and retrieve person information to populate other screens

If the System finds multiple matches for the Customer, the TDHS Worker is able to flag duplicate records for review


1. In the TDHS Enterprise Portal, a TDHS Worker selects the Customer search function. The TDHS worker selects one or more criteria and executes the search. Search criteria may include, but is not limited to:

Program name and program identifier

Program Status by program (e.g. active / inactive)

First name

Middle initial

Last name

Alias(es)

Date of birth

Age

Gender

Social security number (including partial number)

Address, including partials:

— ZIP code

— County

Birth name

Alien registration number

Customer ID (unique identifier for customer in System)

2. If the TDHS Worker wishes to search with less search criteria (so as to broaden the search) without removing the entered content in the text box, the TDHS Worker may deactivate individual search criteria and rerun the search

3. If the TDHS Worker wishes to constrain the search, the TDHS Worker selects to limit results to exact matches

4. The TDHS Worker executes the search

5. The System searches the Master Customer Index for records that match the search parameters

6. The System displays the Customers that exactly or best match the search parameter(s), depending on the searching method

P a g e | 256


a. If no matches are found, the System displays that there were no Customers matching the criteria

b. If the matches are not definitive (e.g. there is conflicting data), the System displays the matched and unmatched elements for inspection by the TDHS Worker

c. If multiple matches are found, the System allows the TDHS Worker to revise the entered search parameters starting at step 1

d. If multiple matches are found that correctly identify the Customer, the System allows the TDHS Worker to flag duplicative accounts for review and remediation

7. The System allows the TDHS Worker to sort and filter the results based on the displayed field

8. Once the System has identified the Customer, the TDHS Worker selects the matching record

9. The System displays Customer information based on the TDHS Workers access rights in the System


Use Case 41: Manage Referral


None

P a g e | 257


4.7.18 Use Case 43: View Alerts

Use Case ID/Title Use Case 43: View Alerts

Actor(s) System User, including:

TDHS Worker

Customer

Service Provider

Background/Objectives The System provides the ability to generate alerts for System users. Alerts are messages displayed for many possible reasons, including, but not limited to:

Announcements to all or specific groups of users

Changes to Customer information

Workflow tasks requiring review or action

Notifications of referrals

Secure messages shared between TDHS Workers regarding a Customer’s record

Alerts may be generated by the System, or by a user (e.g., as a reminder for a future action that needs to be taken on behalf of a Customer).

Alerts differ from tasks, but may be associated with a task that requires the attention of a user. For example, if the System determines that a user must complete a step of the application process prior to further System processing, it may send an alert to the user responsible for that task to complete that task, and clear the alert once the task has been successfully completed.

Alerts have various levels of importance and urgency, and therefore are displayed and interacted with in various ways in the System. This includes capabilities such as:

One or more screens dedicated to alerts that display the various levels of importance / urgency that can be filtered, sorted and acted on from that screen

Areas on the user’s workspace that display less intrusive alerts

Screen pop-ups or other more intrusive alerts that require action by the user to continue for high importance or urgent issues

Other channels for communication, such as automated secure messages or emails

The System’s usage of alerts is highly configurable and allows for system- wide alert management, supervisor control and configuration of alerts for their teams, and user-level management of alerts to modify subscriptions to alerts, all within parameters defined by TDHS. Additionally, the System allows for different priority and urgency categories of alerts, and distinguishes between mandatory and optional alerts.

Alerts, and reports on alerts, will be accessible to users and their supervisors so that TDHS can ensure that alerts are being acted on timely.


Self-Service

The System will provide alerts for Customer’s, with information on how the Customer can take action relating to their case in the System


P a g e | 258


Use Case ID/Title Use Case 43: View Alerts

The System will provide the ability to generate alerts pertaining to Customer specific issues or actions


The System will provide the ability to manage and report on actions taken per alerts related to a Customer’s case


The System will provide the ability to generate alerts pertaining to Customer-specific issues or actions

Responsiveness

The System will provide the ability to alert System users of required actions or communications, increasing TDHS’ ability to be responsive to its Customers


The System will provide the ability to issue alerts, replacing the need for paper communications, where appropriate

Universal Case Load

The System will provide the ability to issue alerts pertaining to actions or communications related to a Customer’s case file, enabling TDHS Workers to share responsibility for managing a Customer’s case

Trigger Events(s) TDHS Worker, Customer or Service Provider logs in to the System where there are alerts to be viewed

The System, or another user, generates an alert based on a System user’s action while the user is logged into the System

Pre-Condition(s) The TDHS Worker, Customer or Service Provider has logged into, or is

logging into, the System

Post-Condition(s) The TDHS Worker, Customer or Service Provider has viewed the alert or notification


1. The System User (TDHS Worker, Customer or Service Provider) logs in to the System

2. The System displays alerts based on the user’s profile, access right(s) and case load or queue responsibilities. Alerts may include, but are not limited to:

Customer information changes

Appointment notices or reminders

Referral notices

Renewal notices

Appeals notices

Benefit recovery notices

Informed Consent expiration

Redetermination or eligibility notices

New secure messages received (e.g., from Service Providers or other programs)

Other alerts per TDHS policy

P a g e | 259


3. The System User may sort or filter alerts by the displayed alert fields including, but not limited to:

Urgency / importance / priority

Date created

Associated queue

Assigned worker (if by a supervisor)

Overdue items

4. The System User may dismiss one or multiple alerts without reading the detailed content, if the alert is configured to allow this (and this will be noted in the audit trail)

5. The System User selects an alert to view

6. The System displays the detailed content of the alert

a. The System may create alerts which require additional action by a System User and will provide a short-cut / link to the appropriate task

7. The System saves a timestamp of when the System User views the alert

8. If / as appropriate, the System User dismisses the alert


Use Case 44: Send and Receive Secure Messages


None

P a g e | 260


4.7.19 Use Case 44: Send and Receive Secure Messages

Use Case ID/Title Use Case 44: Send and Receive Secure Messages

Actor(s) Any System user, including:

TDHS Worker

Customer

Service Provider

Background/Objectives System users may have need to communicate with other users in the System, in a secure manner The System enables this type of communication in the form of secure messaging. Secure messaging complies with applicable legal, regulatory and TDHS policy requirements. Additionally, secure messaging provides a preferable alternative to phone, paper or email communication, as the messages are linked to the Customer’s record, can be audited, and indexed for searching and reporting purposes.

Secure messages can be sent from one System user to:

One or more other specific System users

Groups of System users

All System users

For example, a TDHS Worker may send a secure message to:

Another TDHS Worker, while collaborating on the provision of services for a Customer

A Customer, in order to inform the Customer of an action requiring the Customer’s attention

A (external) Service Provider, while coordinating services for a Customer. NOTE: Though these users are external to TDHS, they are System users, and will send and receive secure messages within the System.

Secure messages are accessible from within the Customer record, or from an “inbox” associated with the user’s account in the System.


Customer-Centric Operations

The System will provide for secure messaging, closely tied to a Customer’s case file, allowing TDHS to enhance operations and communications around Customer needs


The System will enable TDHS to enhance Customer service by improving communications related to Customer needs, and providing the ability to report on these communications


The System will provide for secure messaging, closely tied to a Customer’s case file, providing TDHS workers collaborating on Customer services with quick, easy access to Customer information


The System will reduce the need for paper communications, both internal to TDHS and externally with service providers

Universal Case Load

The System will enhance TDHS’ efforts in universal case load management by providing secure communications to all those collaborating in Customer services

P a g e | 261


Use Case ID/Title Use Case 44: Send and Receive Secure Messages

Trigger Events(s) A TDHS Worker, Customer or Service Provider has need to communicate with one or more other System users

Pre-Condition(s) A TDHS Worker has accessed a Customer’s case file or

A System user has accessed her / his secure message inbox

Post-Condition(s) The recipient System user (TDHS Worker, Customer or Service Provider)

receives the secure message in the System


1. In the Enterprise portal, a System User accesses their list of secure messages, or a TDHS Worker (with appropriate access rights) accesses a Customer’s case record and selects the secure messaging option

2. The System displays a secure message form for the System User to enter a secure message

a. In the “from” area of the secure message, the System pre-populates the information regarding the sender

b. In the “to” area of the secure message

i. The System displays a list of System user groups (e.g., all Families First staff, a specific field office’s staff, etc.) or individual System users, to whom the message may be sent

ii. The System user filters / searches the list for the appropriate group(s) or individual(s) to whom they need to send a secure message

iii. The System user selects one, several or all listed recipient groups or individuals

c. The System provides the option for the System User to associate the message to one or more Customer records (see Use Case 42: Customer Search & Lookup)

d. In the “subject” area of the secure message, the TDHS Worker enters text describing the reason for the secure message or selects from a list of common secure message reasons, as defined by TDHS

e. In the “body” area of the secure message, the TDHS Worker enters text

f. Optionally, the TDHS Worker attaches electronic files to the secure message

3. The TDHS Worker sends the message

4. The System notifies the recipient(s) of the secure message, and provides a link to the secure message in the System

5. The recipient accesses the Enterprise portal and views the message. The System saves a timestamp of when the message was viewed

4.7.19.2 Use Case 44: Alternative Flow A – Reply to Secure Message

1. If the TDHS Worker chooses to reply to the secure message:

a. The System displays a secure message form for the TDHS Worker to enter a secure message

P a g e | 262


i. In the “from” area of the secure message, the System pre-populates the information regarding the sender

ii. In the “to” area of the secure message the System allows the TDHS Worker to add recipients to the secure message thread, as described in the Main Flow; ability to make changes / additions to the recipient list in a reply will be a configurable option

iii. The System notes the Customer or Customers record(s) the secure message is associated with (field not editable in reply)

iv. In the “subject” area of the secure message, the System displays the subject (field not editable in reply)

v. In the “body” area of the secure message, the TDHS Worker enters text that appends the original body text

vi. Optionally, the TDHS Worker attaches electronic files to the secure message

b. The TDHS Worker sends the message

c. The System notifies the recipient(s) of the secure message, and provides a link to the secure message in the System

d. The recipient accesses the Enterprise portal and views the message. The System saves a timestamp of when the message was viewed




None

P a g e | 263


4.7.20 Use Case 45: Contact TDHS Service Center

Use Case ID/Title Use Case 45: Contact TDHS Support Center

Actor(s) TDHS Service Center Worker

TDHS Worker

System User or Caller, which may include

Customer

Service Provider

Public users (users without a system account)

Background/Objectives This use case describes the process by which TDHS Service Center Workers provide customer service to TDHS Customers. The main flow of the use case covers the processing of customer communications via instant messaging (“chat”). Alternative flows cover the processing of customer communications including, but not limited to:

Phone (with the assistance of an integrated voice response [IVR] system)

Online chat

Email

Mail / fax (see Use Case 18: Process Paper Documentation)



The System will provide TDHS with the ability to manage and report on Customer support activities


The System will provide TDHS Service Center Workers with a view of Customer’s case file, based on their access rights in the System, in order to triage customer questions or issues


The System will enable TDHS to best leverage the standardized customer support processes and procedures envisioned in the ESM Model of Practice

Responsiveness

The System will enhance TDHS’ ability to serve its Customers by enabling TDHS Service Center Workers to triage customer needs or route customer issues / questions to the appropriate TDHS staff more quickly


The System will decrease the need for paper communications between TDHS Service Center staff and Customers, Service Providers and TDHS program staff

Universal Case Load

The System will provide TDHS Service Center Workers with the ability to triage customer issues or questions

Centralization of Mail

The System will support having all paper documentation sent to TDHS centralized, scanned then uploaded to the System and associated with a Customer case file or Service Provider’s record

Trigger Events(s) Customer contacts the TDHS Service Center

Pre-Condition(s) TDHS Service Worker is logged in to the System

Customer is logged into the System (optional)

P a g e | 264


Use Case ID/Title Use Case 45: Contact TDHS Support Center

Post-Condition(s) Customers need for contacting the TDHS Service Center has been met, and TDHS Worker is assigned or has completed any required follow-up action

The Customer's information has been documented or Customer has been referred to appropriate resource


1. The System User (Customer or Service Provider) logs in to the TDHS Enterprise Portal and selects the option to chat with a TDHS Service Center Worker

2. The System prompts the System User for information to assist in the routing of the chat. This may include, but is not limited to:

q Language preference

q Issue / question type, which may include, but is not limited to:

— Customer inquiry

— Case status

— Customer change

— Customer issue / complaint

— Fraud & abuse referral (Program Integrity)

a. If the user does not provide this information, the request is added to a queue to be routed to the next available TDHS Service Center Worker

3. Based on the System User’s stated language preference, the System uses the System User’s preferred language in all subsequent communications in this use case

4. The System responds to chat request and provides immediate responses in one or more of the following ways:

a. The System presents links to frequently asked questions, based on the keywords in the System User’s stated issue / question

b. The System provides a structured, guided, “wizard”-like flow of questions that identifies system resources (e.g. links or documents) that may assist the System User

5. The System asks the System User if the automated responses resolved their issue or answered their question

6. The System User indicates whether their issue is resolved or question answered

a. If resolved, the System closes the chat session and saves the session

7. If issue is not resolved, the System routes the chat to the appropriate TDHS Service Queue, based on reason for the request

8. The System reports the System User’s position in the queue and/or approximate wait time to the System User

9. When available, a TDHS Service Center Worker enters into a chat session with the System User

P a g e | 265


10. The System populates the TDHS Service Center’s screen with the System User’s case file, along with relevant information collected by the System

11. For certain issues / questions the TDHS Service Center Worker follows a predefined script to capture relevant information and further clarify the issue and identify a solution

a. The System provides information from the knowledge base that is relevant to the specific problem area and the known solutions

i. This includes frequently asked questions and any known issues

ii. This allows searching by key words

12. The TDHS Service Center Worker responds to the System User’s inquiry and tries to resolve their issue

a. If the TDHS Service Center Worker resolves the issue, the TDHS Service Center enters the resolution and the communication is added to the case file

b. If the TDHS Service Center Worker cannot resolve the System User’s issue but a TDHS Worker is available that can assist the System User

i. The TDHS Service Center Worker transfers or escalates the chat session to an appropriate TDHS Worker or to the appropriate queue

ii. The System displays the position in the queue and/or approximate wait time for the System User

iii. When available, the appropriate TDHS Worker enters into a chat session with the System User

iv. The System populates the TDHS Worker’s screen with the System User’s case file, along with relevant information collected by the System

c. If the TDHS Service Center Worker or TDHS Worker cannot resolve the System User’s issue and it requires additional follow-up

i. The System creates a task with the issue and chat session transcript and assigns it to the appropriate queue or TDHS Worker’s task list for further investigation ; the task is associated with the System User’s case file, if it exists

ii. The System creates an alert associated with the task, if appropriate

4.7.20.2 Use Case 45: Alternative Flow A – Process Incoming Call

1. The IVR system prompts the Caller for information to assist in the routing of the call. This may include, but is not limited to:

q Language preference

q Customer ID or Provider ID

q Reason for the call (e.g., information requested)

a. If the Caller cannot provide this information they are added to the queue to be routed to a TDHS Worker

2. If the question can be answered by the IVR, the IVR prompts the Caller for specific information:

P a g e | 266


a. If the IVR resolves the Caller’s issue, the call is saved in the caller’s case record (Customer or Provider as appropriate)

3. If the IVR System cannot resolve the Caller’s issue, the IVR System determines the queue for that type of issue

4. The Caller enters the phone queue

5. The System reports the wait time to the Caller and provides options for how to connect to the appropriate TDHS Service Center Worker

a. The Caller can choose to wait on hold

b. The Caller can choose to be called back when an appropriate TDHS Service Center Worker becomes available

6. The Caller is connected to the TDHS Service Center Worker

a. If the Caller is known to the System, the System populates the TDHS Service Center Worker’s screen with the Customer’s case file, along with relevant information collected by the IVR

b. If the Caller is not known to the System, the System prompts the TDHS Service Center Worker to enter in identifying information about the Caller

7. For certain issues / questions the TDHS Service Center Worker follows a predefined script to capture relevant information and further clarify the problem required and identify the solution

a. The System provides information from the knowledge base that is relevant to the specific problem area and the known solutions

i. This includes frequently asked questions and any known issues

ii. This allows searching by key words

8. The TDHS Service Center Worker responds to the Caller’s inquiry and tries to resolve their issue

9. The TDHS Service Center Worker enters the resolution of the call and the communication is added to the case file, if the caller is a Customer

10. If the TDHS Service Center Worker cannot resolve the Caller’s issue, the TDHS Service Center Worker escalates the call to an appropriate TDHS Worker and the call joins the queue

11. The TDHS Service Center Worker reports the wait time to the Caller and options for how to connect to the appropriate TDHS Worker

a. The Caller can choose to wait on hold

b. The Caller can choose to be called back when an appropriate Contact Center Expert becomes available

12. The Caller is connected to the TDHS Worker

a. The System populates the TDHS Worker’s screen with the Caller’s case file information, along with relevant information collected by the IVR or TDHS Service Center Worker

13. The Contact Center Expert responds to the Caller’s inquiry and tries to resolve their issue

P a g e | 267


14. If the call has been escalated to Contact Center Experts who cannot resolve the issue the issue is logged with the IT department or the program experts for further research

a. The issue is flagged in the Caller’s record (Customer or Provider as appropriate)

15. Once the root cause has been identified the Caller is contacted and the issue is closed

4.7.20.3 Use Case 45: Alternative Flow B – Process Incoming Email

1. An email is sent to the TDHS Service Center

a. The System generates a return email notification, notifying the sender that TDHS will process the email and respond within a specified time period, per TDHS policy

2. A TDHS Service Center Worker accesses a TDHS Service Center email queue, and opens the email

3. The TDHS Service Center Worker triages the email as appropriate

a. If the TDHS Service Center Worker is able to address the contents of the email

i. The TDHS Service Center Worker takes the appropriate actions in the System, per TDHS policy and procedures

ii. If the email contains an attachment that the TDHS Service Center Worker finds should be added to the System, the TDHS Service Center worker uploads the file to the System, and associates it with the appropriate Customer case file or Service Provider record

iii. The TDHS Service Center Worker replies to the email by either replying to the email or calling the Customer

iv. If by email, the TDHS Service Center Worker provides the appropriate content in response to the original email.

(1) If the question or issue pertains to a Customer or Service Provider’s record in the System, the TDHS Service Center Worker provides a link to the Enterprise portal in the response, along with instructions on how the Customer or Service Provider may access and view / change information.

b. If the TDHS Service Center Worker is unable to triage the issue or question

i. The TDHS Service Center Worker notifies the appropriate program or field office work queue, per TDHS policy and procedures. See Use Case 46: Manage Caseload


Use Case 46: Manage Caseload


None

P a g e | 268


4.7.21 Use Case 46: Manage Case Load

Use Case ID/Title Use Case 46: Manage Case Load


TDHS Supervisor

Background/Objectives In this context, “case load management” involves the assignment of tasks related to a Customer’s case file to the appropriate TDHS resources for completion. These tasks may occur anywhere during the full lifecycle of the Customer’s interactions with TDHS. This includes everything from the processing of a Customer’s application to the closure of the Customer’s case in the System. Common examples include, but are not limited to: steps taken by TDHS during the eligibility determination process, the issuance of referrals to Service Providers on behalf of the Customer, updating the Customer’s record, etc.

Case load management may also include tasks performed by TDHS staff in order to meet the Department’s legal, regulatory and policy mandates, such as actions performed by Program Integrity staff to address fraud and abuse, or Appeals & Hearings to ensure the fair and timely resolution of disputes between TDHS and its Customers.

An important element in this use case is the ability for TDHS to easily create and manage business rules around case load routing. This may involve

Determining which TDHS Workers have a current light case load, and distributing case tasks to these staff members

Routing case tasks to specific offices/groups by region

Routing potentially sensitive case tasks (e.g., case tasks related to Tennessee state employees) to specific groups for action

This use case uses three high-level patterns for caseload management:

Automatic Routing to Queue– Case tasks are automatically routed to queues based on a set of pre-defined rules. Case tasks from these queues are then assigned to individual TDHS Workers.

Automatic Routing to Worker – Case tasks are automatically routed to a specific TDHS Worker based on a set of pre-defined rules. These rules may be based on the TDHS Worker’s role, the Customers for whose case records the TDHS Worker has been assigned to manages, or other heuristics.

Manual Routing – Case tasks are initially triaged, then manually assigned to the appropriate queue or TDHS Worker.

In this use case, a case task is routed to the appropriate TDHS Worker or queue so a Worker may complete the required actions. The TDHS Worker has appropriate access rights(s) in the System to perform the action described.


Customer-Centric Operations

The System will enable the distribution of various tasks related to processing a Customer’s case file across TDHS staff

Data Access

The System will enable TDHS staff with the appropriate access rights the ability to access Customer information and data


The System will enable TDHS to manage and report on Customer support services

P a g e | 269


Use Case ID/Title Use Case 46: Manage Case Load


The System will enable TDHS staff, with the appropriate access rights, with the ability to access Customer information and data


The System will support the standardization of Customer case file management processes and procedures

Responsiveness

The System will enhance TDHS’ ability to provide timely support and assistance to its Customers


The System will decrease the need for paper communications between TDHS Service Center staff and customers, service providers and TDHS program staff

Universal Case Load

The System will provide TDHS Service Center Workers with the ability to triage customer issues or questions

Trigger Events(s) The System or a TDHS Worker identifies the need for work activity to facilitate the processing of a Customer’s case

Pre-Condition(s) Case task or work item needs action to be taken for processing

Post-Condition(s) The case is routed to the appropriate TDHS Worker or work queue


1. If automatic routing to a work queue is employed

a. The System routes the case task to the appropriate work queue, based on a set of pre-defined set of rules, per TDHS policy

b. The System prioritizes case tasks based on configured rules and assigns the highest priority task to the next available TDHS worker assigned to the queue

c. A TDHS Worker assigned to the work queue either

i. Takes ownership of the case task

ii. Assigns the case task to a specific TDHS Worker

iii. Dispositions the assigned task, and is prompted to note the reason for this

2. If automatic routing to a TDHS Worker is employed

i. The System routes the case task to the appropriate TDHS Worker, based on a set of pre-defined set of rules, per TDHS policy

ii. The TDHS Worker either

(1) Takes ownership of the case task

(2) Assigns the case task to a different TDHS Worker or work queue

3. If manual routing is employed

a. The System routes the case task to a central work queue

b. A TDHS Worker performs initial triage on the case, and resolves if appropriate

i. If unresolved, the TDHS Worker routes the case task to the appropriate queue

P a g e | 270


ii. A TDHS Worker assigned to the work queue either

(1) Takes ownership of the case task

(2) Assigns the case task to an appropriate TDHS Worker

4. The TDHS Worker to whom the case task is assigned completes the action required, as they are able

5. If additional actions are required, and the current TDHS Worker is unable to complete them, the System routes the case task to another TDHS Worker, TDHS Supervisor, or appropriate queue


All


None

P a g e | 271


4.7.22 Use Case 47: Access and View Dashboards

Use Case ID/Title Use Case 47: Access and View Dashboards

Actor(s) System user, including:

Customer

TDHS Worker

Service Provider

Background/Objectives The System provides the ability to access reporting “dashboards,” based on the System User’s access rights associated with their user profile.

The dashboards will provide users with an interactive “front-end” to a collection of scorecards, exception reports, and other parameter-based reports by population, program or other business needs. The dashboards will provide users with an easy way to view essential information related to program and service delivery categories, individual customers, customer populations, caseloads and other targeted areas to support decisions.

Content of the dashboard reports will vary based on:

User profile and access rights

Program and Service Delivery categories related to the User

Availability of business intelligence and analytics capability

Population and program-based dashboard reports can be accessed without selecting a specific customer record. Any information presented as such will be de-identified. Examples of information that users may want to access through a dashboard include:

Characteristics of a population with information such as:

Number of participants

Number and percentage of program participants by program type and service type

Percentage of participants enrolled in multiple programs / services

Distribution by Percentage of Federal Poverty Level (FPL), by income, by assets

Household size

Language distribution

Age distribution

Gender distribution

Race / ethnicity

Percentage with chronic illnesses by type such as diagnosis and disability type (e.g., intellectual disability, autism spectrum disorder/pervasive developmental disorder (PDD)

Population distribution in the State by geography (e.g. county) or zip code (full GIS abilities)

Housing situation (e.g. facility or community? Public or private?) by category of eligibility and by services used

Employment status

Risk profiles, including, but not limited to:

— Public safety

— Medical history

— Physical health

— Mental health

— Substance abuse

— Domestic violence

P a g e | 272



— Living arrangements

Defined program and service category process and outcome objectives

Performance indicators

Program and collaboration case load information

Worker Productivity

Number of cases by program, status (Pending / Active / Suspended / Terminated)

Number of cases pending or suspended by reason

Number of Applicants / Customers denied by reason

Number of Applicants identified eligible for Exchange-based coverage

Timeliness of eligibility determination

Delay by reason

Number dis-enrolled Customers by reason

Churn by time enrolled, time off

Aggregate view of alerts and notifications

Referrals received

New messages / shared notes

Defined case milestone and outcome objectives

Claims, denials and payments

Funding sources

Cost-sharing

Premiums due and paid

Benefits recovered

Types and related count of grievances received

System performance and quality assurance reports based on information available in the System and other sources

Data quality

System performance

Cost / efficiency

Fraud, waste and abuse detection and recovery

Level of utilization

Other outcome-based reports

Customer-centric dashboards provide information on how a specific customer relates to the overall characteristics of his or her population. To view Customer-centric dashboards, users must first access a customer record. The Customer-centric dashboards require consent. Examples of information that users may want to access through a dashboard may include, but are not limited to:

Customer’s age related to the average Customer population age and overall population age.

Customer’s program participation compared to customer population participation and overall population participation.

Customer’s income compared to customer population median income and overall population median income.

Customer’s health profile compared to Customer population profile and overall population profile.

P a g e | 273



Customer’s risk profile compared to customer population profile and overall population profile.

Customer’s health profile compared to health disparity

Customer’s transitioning and re-entering the community from institutions / facilities (e.g. nursing facilities) -

Cost information

Utilization of programs and services

Risk levels

NOTE: The intent of this use case is to describe the System functionality and types of reports accessible when viewing dashboards, not to provide a complete and detailed listing of the reports included, or their contents, etc.


Self-Service

The System will provide Customers and Service Providers with the ability to generate standard reports

Data Access

The System will provide TDHS staff with reports and data behind the reports


The System will enable TDHS staff to create, modify and run reports on multiple aspects of services provided to its customers


The System will enable TDHS staff to create, modify and report on customer data

Responsiveness

The System will enhance TDHS’ ability to make data-driven decisions in the provision of services to its Customers

Trigger Events(s) A System user has need to view program, population or customer dashboard reports

Pre-Condition(s) System user has appropriate access rights to view the report

Post-Condition(s) System displays dashboard reports


1. The System User accesses dashboard reports on the TDHS Enterprise Portal

2. The System User configures dashboard preferences and selects from a list of available reports, those to include in the dashboards, based on access rights, program role and reporting needs. The System displays a list of different types of reports available, categorized as applicable. Categories may include, but not are limited to:

Program-centric reports

Population-based reports

Geographic-based reports

Customer based reports

P a g e | 274


3. For each report added, the System User specifies one or more applicable report parameters, as appropriate. See Use Case 48: Access and View Parameter-Based Reports

4. The System user adds the report to the dashboard

5. The System displays the dashboard reports

a. If the System provides for an interactive visualization of dashboards, the user specifies any applicable parameters while viewing report output

b. If applicable for each report, the System provides the ability to export report data (e.g. to Microsoft Excel), or print the report (e.g., PDF format)


Use Case 48: Access and View Standard or Parameter-Based Reports


None

P a g e | 275


4.7.23 Use Case 48: Access and View Standard or Parameter-Based Reports

Use Case ID/Title Use Case 48: Access and View Standard Reports

Actor(s) System User, including;

TDHS Worker

Customer

Service Provider

Background/Objectives System users will have the ability to access reports in the System, based on access rights associated with their user profile.

Among the reports available will be a set of standard or parameter-driven reports, which users can view and export, but not customize beyond specifying a minimum number of parameters required to generate the report. These reports will have limited selectable data elements and fixed structure and layout.

The reporting capability include the ability to automatically generate and route a report (or a link to a report) through secure messaging, email, etc. This use case describes the process of selecting a report to view.

Examples of standard reports may include, but are not limited to:

New Families First enrollees in a program during a month, where the program and month are selectable

Providers licensed in a month, where the program and month are selectable

Outstanding overpayment claim amounts by program, where the program is selectable

Number of Customers, by program, by field office, where the program, field office and effective date are selectable

Families First eligibility and enrollment by county over a month, where the county and month are selectable

NOTE: The intent of this use case is to describe the basic System functionality related to accessing and viewing standard or parameter-driven reports, not to provide a complete and detailed list of reports or their contents.


Self-Service

The System will provide Customers and Service Providers with the ability to generate reports

Data Access

The System will provide TDHS staff with reports and data behind the reports

n Customer-centric Service Management and Reporting

q The System will enable TDHS staff to create, modify and run reports on multiple aspects of services provided to its Customers


The System will enable TDHS staff to create, modify and report on customer data

Responsiveness

The System will enhance TDHS’ ability to make data-driven decisions in the provision of services to its Customers

Trigger Events(s) A System user has need to view a standard report

P a g e | 276


Use Case ID/Title Use Case 48: Access and View Standard Reports

Pre-Condition(s) System user has appropriate access rights to view the report

Post-Condition(s) The report is viewed by the System user


1. The System displays a list of different types of pre-defined reports available to the user, based on the user’s profile and access rights

2. The System User selects a report from the list

3. The System User specifies one or more applicable report parameters. Parameters may include, but are not limited to:

Time period (e.g., last 30 days, previous month, previous quarter, customized date range, etc.)

Population characteristics (e.g., age range, gender, economic status, race, ethnicity, etc.)

Geography (e.g., zip code, region, county, etc.)

Program (TANF, SNAP, Child Care, Child Support)

Threshold-based and exception parameters (i.e., “hot spotting”)

Percent change

Ranking / prioritization

4. The System user selects the option to generate the report

5. The System displays the report on the screen, and provides the ability to export report data (e.g. to Microsoft Excel), or print the report (e.g., PDF format or to printer)


None


None

P a g e | 277


4.7.24 Use Case 49: Create Ad Hoc Queries and Reports

Use Case ID/Title Use Case 49: Create Ad Hoc Queries and Reports

Actor(s) TDHS Business Analyst

Background/Objectives The System provides querying and data access to those with the appropriate access rights, per TDHS policy. This capability to create additional ad hoc queries and reports, in response to needs that are not met by standard reports or dashboards, may require a wide range of data sources and statistical tools external to the System, as well as resource skills and an understanding of State and Federal data access policies. Such ad hoc queries may then be standardized and saved for use in standard and parameter-based reports, as well as dashboards, as possible / applicable.

In this use case, the user accesses data sources, creates queries and views a custom data output.


Self-Service

The System will provide Customers and Service Providers with the ability to generate reports

Data Access

The System will provide TDHS staff, with appropriate access rights, with reports and data behind the reports


The System will enable TDHS staff to create, modify and run reports on multiple aspects of services provided to Customers


The System will enable TDHS staff to create, modify and report on Customer data

Responsiveness

The System will enhance TDHS’ ability to make data-driven decisions in the provision of services or benefits to its Customers

Trigger Events(s) The TDHS Business Analyst has a new report / information required

Pre-Condition(s) The TDHS Business Analyst has access to the System

The TDHS Business Analyst has access to advanced query functionality in the System and needed data sources

The TDHS Business Analyst has appropriate need and approval to access the queried data sources

Post-Condition(s) The TDHS Business Analyst has created a new report in the System


1. In the TDHS Enterprise Portal, a TDHS Business Analyst views available data sources. Data sources may include, but are not limited to:

Data within the ESM Enterprise Integration Platform (EIP) assets, such as the master customer index, master provider index or other centralized data stores

Data within legacy systems that are connected to the System and may be queried from the system

Data from other external sources that may be imported for use in the query

P a g e | 278


2. The TDHS Business Analyst accesses tools within the System to create queries based on the data and as needed. Querying capabilities may include, but are not limited to: joins, unions, comparisons, filtering, conversions, arithmetic functions and other basic querying functions. The System may also provide a graphical user interface for the user to create these queries.

a. The system will provide ability to define parameters for random sampling of data, by person or case, for audit and QA review purposes

3. The System displays the data based on the queries in a selected reporting format

4. The System provides the ability to export the results of the query to various formats (e.g., Excel, csv, SAS, etc.)

5. The System enables the TDHS Business Analyst to modify or build on the initial query to further refine query results

6. If appropriate, the TDHS Business Analyst saves the query for future use

7. If appropriate, the TDHS Business Analyst shares the query with other users or user groups


None


None

P a g e | 279


5.0 Additional Requirements

These requirements are not captured in the main or alternative flows, but are functional requirements that may represent business requirements that cross multiple use cases or are relevant to four key areas of the business process:

1. Usability – These requirements describe key functionality that assists users in navigation or access

2. Security – These requirements describe security features and functions that must be present in the system

3. Performance – These requirements describe additional metrics or features which provide and support efficient operations

4. Regulatory – These requirements describe federal or state compliance requirements that are not otherwise represented in the use case

(KEY - U: Usability, S: Security, P: Performance, R: Regulatory)

(U) The System will allow the Applicant to restart the pre-screening, eligibility or child support application process at any time

(U) The System will allow the Applicant to erase any /all pre-screening, eligibility or child support application information at any time before submission

(U) The System will allow the Applicant to save and exit the pre-screening, eligibility or child support application process at any time before submission

(U) The System will allow TDHS staff to easily add, edit or delete all aspects of the pre- screening, eligibility or child support application questions and information including, but not limited to:

The list of State and non-State programs available

The criteria / questions being asked

The values or calculations for the criteria / questions

Information on other programs to be provided to Applicants

Information on additional resources available to Applicants

The order of questions

Other customizable attributes"

(U) The System will provide context-sensitive help (e.g., pop-up text when the user positions the mouse over a specific field)

(U) The System will provide TDHS support contact information to the user

(U) The pre-screening, eligibility and child support applications will be written in such a way that complies with Limited English Proficiency (LEP) requirements, per TDHS policy

(U) The pre-screening, eligibility and child support applications will be available in alternate languages (currently English, Spanish, Arabic, Somali), per TDHS policy

(U) The system will make use of dynamic scripting or intelligent information gathering when presenting applicable questions to applicants, based on information provided

(U) (R) The System will save the submitted version of the pre-screening, eligibility and child support applications, at the time the application was electronically signed and submitted

P a g e | 280


(U) The System will provide a user interface that is optimized for a “first time” user (emphasizing ease of use), rather than a “super user” (emphasizing rapid data entry)

(U) The System will offer a print-friendly view of all information presented on the TDHS Enterprise Portal

(U) The System will offer a print-friendly, PDF version of all applications, forms, official notices and other documents on the TDHS Enterprise Portal, as identified by TDHS

(U) The System will validate information entered by the user, by appropriate field type, including, but not limited to:

Required field completion

Field content types (e.g., names will not contain numbers)

Acceptable field values (e.g., no birth dates before 1/1/1900, zip code will have 5 characters, be valid for the State of Tennessee, etc.)"

(U) Where applicable, the System will provide access to a mapping tool with directions to TDHS field offices

(U) The System will track the status of applications through the entire eligibility process

(U) (S) The System will allow TDHS staff (those with appropriate access rights only) to add, edit, or delete application information on behalf of the Applicant

(R) The System will provide the ability to capture multiple addresses for each Customer and select different mailing address for notices, correspondence and other materials by type and / or by time period

(U) (R) The System will maintain a version history of changes made to any submitted application, and also save audit trail information for the submitted application, including the user who made the change, the date & time of the change, and the old and new value of fields on the application

(R) The System will allow an Applicant to schedule an eligibility interview the same day the application was submitted

(U) The System will allow the Eligibility Worker to indicate additional TDHS program(s) for which the Customer’s eligibility should be determined, after the Applicant has submitted an application

(U) The System will allow the Eligibility Worker to record any notes taken while conducting an eligibility interview

(R) The System will allow Eligibility Workers with the ability to record and save eligibility interviews conducted via telephone or web-conference

(U) (R) The System will allow TDHS Workers to add / modify / delete eligibility check rules as needed, per TDHS policy

(U) (R) The System will allow TDHS to prioritize eligibility rules run during eligibility testing

(U) (R) The System will allow TDHS to customize eligibility approval and denial notifications, per TDHS policy

(R) The System will allow TDHS Workers, with the appropriate access rights in the System, to override eligibility rules tests, per TDHS policy

P a g e | 281


(R) The System will allow TDHS staff to define eligibility determination rules for situations where an Applicant is enrolled in, or applying for, multiple TDHS programs

(U) The System will allow TDHS staff to define and update program-specific rules for calculating benefits, per TDHS policy

(R) The System will allow TDHS staff to amortize any recoupment or penalty benefit reductions, per TDHS policy

(R) If the System confirms that a Customer is deceased, the System will send a notice to the emergency contact in the Customer’s case file

(R) The System will allow the Eligibility Worker to override the deadline by which Customers must complete applications

(U) They System will provide a Child Care Specialist with the ability to document the child care provider home visit via a mobile device, including entering information regarding the visit, uploading pictures of the home environment, etc.

(R) The System will calculate and track Child Care Certificate costs for Customers participating in Families First Diversion Cash Assistance program, per TDHS policy and Families First guidelines

(U) The System will support a statewide rate table for the payment of child care services, easily modifiable by an authorized Child Care Billing Worker

(U) The System will provide the ability to document school holidays in order for child care providers to submit attendance on those days when authorized by the Child Care Certificate

(U) The System will provide the ability to process one or more child care provider payments simultaneously

(U) The System will provide the ability to print attendance reports

(U) The System will handle child care payments, when the child care provider has been ordered to pay civil penalties, per TDHS policy. This may include the ability to withhold a specified amount from the child care payment (including the ability to adjust at the child care provider’s discretion), and notification to the child care provider including itemized remittance information regarding any payment adjustments, etc.

(U) The System will generate monthly credit bureau reports about the status of child support obligations

(U) The System will support the documentation of repayment plans, including period payment amounts due and the date by which they will be received

(U) The System will only generate automated alerts to the Child Support Worker about cases for which punitive actions have not been initiated

(R) The System will issue a notice to the PRP on a monthly basis, detailing all payments received, and all adjustments, distributions and disbursements

(U) The System will allow the Appellant to save and exit, and then resume filling out an appeal request at any time before submission, based on defined time limits, per TDHS policy

(R) The System will allow the Appellant to submit an appeal request for a program / service, and concurrently re-apply for the program / service

P a g e | 282


(U) The System will provide Appeals and Hearings staff with the ability to view an Appellant's (program) case file via a link from the appeal request

(U) The System will be able to save all information associated with the case, and mark items officially submitted as evidence for the hearing

(U) The System will support program-specific case templates that Appeals and Hearings Worker can modify and use to create appeal-specific legal packets

(U) The System will support the ability to print any / all legal packet materials for Hearing Officer review

(S) (R) The System will support the ability to redact any confidential information provided to parties to the appeal

(U) The System will assign a unique identifier to every appeal request

(U) The System will provide the ability to add / change the Department attorney, witness(es) or representative(s) for all correspondence at any time, and have them receive appeal correspondence electronically

(U) The System will provide means for the Appellant to track the status of their appeal request including hearing dates, appeal status, relevant documents, etc.

(U) The System will provide means to upload and / or link hearing-related documentation to an appeals case

(R) When calculating benefit discrepancies, the System will not alter current benefits

(R) When calculating benefit discrepancies, the System will calculate the discrepancy amount as of the time the discrepancy occurred (not at the current benefit amount level)

(U) (R) The System will allow TDHS Program Workers and Program Integrity staff, with appropriate user rights, to add / edit / delete the business rules for calculating benefit discrepancies, per TDHS policy and Federal regulations

(U) (R) The System will allow TDHS Program Workers and Program Integrity staff, with appropriate access rights, to add / edit / delete the business rules for creating benefit recoupment and repayment plans, per TDHS policy and Federal regulations

(R) When recovering claim amounts via benefit recoupment, the System will adjust the recoupment amount, due to changes in the Customer’s benefits

(R) When recovering claim amounts via benefit recoupment, the System will identify Customer benefits qualifying for expungement (per TDHS policy), and apply those against any outstanding claims

(R) On a regular basis (e.g., monthly), per TDHS policy, for each Customer with an outstanding claim, the System will alert the Customer of the current claim amount, the next payment / recoupment amount and date, and other applicable information, per TDHS policy

(R) For any payments received by TDHS, the System will record the payment date as the date TDHS received the payment, and the date the payment was processed

(R) The System will alert a Program Integrity Specialist if / when a claim balance should be written-off

(U) The System will alert the Customer of the need to reschedule their appointment if TDHS resource availability changes

P a g e | 283


(R) If a Customer cancels or reschedules an appointment the System will provide the Customer with program scheduling requirements (e.g., allowable date time frames), per TDHS policy

(R) If a Customer cancels or reschedules an appointment the System will document the original appointment date and times, reason for change, and date and time of change

(U) The System will support the use of barcodes on all communications to Customers / Service Providers

(U) The System will support the use of OCR scanning and indexing of any documents uploaded in the System

(U) The System will support the use of document search

(U) The System will allow TDHS Workers to attach files to referrals

(U) The System will allow the printing of referrals

(U) The System will associate referrals to the Customer that was referred

(S) The System will allow TDHS Workers, with the appropriate access rights in the System, to delete an unsent referral. When a referral is deleted, the System erases all information related to the referral

(U) The System will allow TDHS Workers to send referrals to multiple (external) Service Providers

(U) The System will trigger automatic referrals based on defined business rules and populated with information contained in the System

(U) The System will maintain a master provider index of Service Providers. Information for each Service Provider may include, but is not limited to:

Contact information (multiple addresses)

Contracts held with TDHS

Certification(s)

(U) The System will have the ability for TDHS Workers and Service Providers (for their own information, and subject to review and approval by TDHS) to manage information regarding Service Providers

(U) The System will allow searches based on:

Partial text search

Wild card search

Phonetic search

Value ranges (e.g. dates, age, zip codes)

(U) The System will have the capability to configure search fields as optional or mandatory

(U) The System will store, and provide the ability to search on, multiple addresses for each Customer. Multiple addresses will include, but are not limited to:

Residential

Work

P a g e | 284


Mailing

Last known location

(S) The System will limit returned records to those for which the TDHS Worker has appropriate access rights

(R) The System will preserve all secure messages for audit purposes

(S) The System will display alerts based on the user’s profile, Customer consent and user access rights(s)

(U) The System will support the creation of alerts for task reminders

(U) The System will automatically transfer alerts associated with tasks, when the task is transferred to other TDHS workers or work queues

(U) The System will support "short-cuts" in alerts (e.g., hyperlinks) providing the user with the ability to quickly and easily access additional information related to the alert

(U) The System will offer print-friendly, PDF versions of alerts

(R) The System will record a timestamp of when a user views and / or dismisses an alert, and whether the detailed information of an alert was read

(R) For certain types of alerts, the System will prompt the user to indicate what action has been taken

(U) The System will provide users with the ability to subscribe or unsubscribe to alert types, per TDHS policy

(U) The System will provide users with the ability to customize or prioritize the way alerts are displayed in the System

(U) The System will allow the TDHS Worker and supervisors to view the age of alerts and notifications

(U) (R) The System will allow managers and supervisors to view pending / unread alerts for their team (or other groups of users), per TDHS policy

(U) The System will support multiple ways to deliver and view alerts, including, but not limited to, email, SMS, RSS and pop-ups

(U) (R) The System will provide the ability to configure and manage secure messaging groups, per TDHS policy

(S) (R) The System will enforce role-based access on secure messages so that sensitive or otherwise confidential information is limited to users with defined rights to it

(U) The System will support delivery and read receipts for secure messages

(U) The System will allow users to save drafts of secure messages before they are sent

(U) The System will provide users with the ability to print secure messages

(S) The System will perform security scans on all documents uploaded to the System

(U) The System will allow TDHS to build easily-updatable work queues to handle case load management

(U) The System will provide the ability for users to configure and save dashboard preferences

P a g e | 285


(S) (R) The System will provide the ability to suppress data sets with a sample size of zero, or when a sample size does not meet the threshold for de-identified / anonymous data

(U) The System will provide printer-friendly, PDF-versions of dashboard reports

(U) The System will maintain information on the source system for each data element contained on the dashboard

U) The System will support "short-cuts" in reports and dashboards (e.g., hyperlinks or clickable graphics) to additional, more detailed reports or other information, as applicable

(U) The System will support the use of graphics and (geographic) maps in the reports and dashboards

(U) The System will provide the ability to sort and filter report data

(U) The System will provide the ability to export report data in various formats (e.g., xls, csv, etc.)

(U) The System will provide the ability to export report data in a print-friendly, PDF format

(U) The System will provide the ability to share reports with other System users, or groups of users, per TDHS policy

(S) (R) The System will create an auditable list of users that access a given report, and an audit trail (timestamp) for when they access the report

(U) The System will support the archiving of reports

(U) The System will provide users with the estimated time required to run a report, if it exceeds a predefined time limit

(U) The System will provide users with the ability to schedule the automatic generation and delivery of reports (or links to reports) via a specified communication channel (e.g. email)

(P) The System will allow queuing of queries to limit interruption of other System processes

(P) (R) The System will prevent duplicate authorization of benefits for the same time period

(U) The System will allow benefit supplements to be processed when authorizing benefits