Vermont Health Services Enterprise Platform and Integrated Eligibility Business Process Analysis

Transcription

1 Vermont Health Services Enterprise Platform and Integrated Eligibility Business Process Analysis 1

2 2 Revision History Revision Date Author 1.0 August 27, 2012 Vermont 2.0 October 17, 2012 Vermont 3.0 November 5, 2012 Vermont

3 3 Table of Contents 1.0 Introduction Streamlining Health and Human Services (HHS) Initiative SOA HSE Platform Vision Purpose of the Business Process Analysis (BPA) Report Approach and Methodology Workflows List of Workflows Workflows Overview WF-0 High-Level Process Map Screening, Application and Determination (SAD) WF-1 Conduct Application and Enrollment - via Self- Service WF-2 Conduct Application and Enrollment - via Worker WF-3 Apply Eligibility Rules WF-4 Conduct Re-Determination WF-5 Manage Client Changes Integrated Eligibility Capabilities WF-6 Appeals WF-7 Grievances WF-8 Client Scheduling On Demand WF-9 Client Scheduling Appointment WF-10 Issue Benefits WF-11 Spenddown WF-12 Spenddown-Submit Expenses WF-13 Conduct Interview WF-14 Conduct Assessment WF-15 Complete Intake / Admission WF-16 Benefit Recovery WF-17 Benefit Recovery- Collect Over-Payment Shared Capabilities WF-18 Conduct Client Search and Lookup WF-19 View Alerts and Notifications WF-20 Render Client Services WF-21 Manage Referrals WF-22 Manage Caseload WF-23 Program Activity Assignment... 59

4 WF-24 Program Activity Time Tracking WF-25 Management Reporting (High-level) WF-26 Conduct Data Gathering WF-27 Conduct Data Profiling and Acquisition WF-28 Conduct Data Analysis, Research, and Evaluation WF-29 Conduct Evaluation and Develop Recommendations WF-30 Analysis Communication and Explanation Use Cases Use Case Overview Actors Use Case List Use Cases Screening, Application and Determination UC-1: Complete Self-Service Anonymous Screening UC-2: Complete Self-Service Integrated Application UC-3: Complete Self-Service Integrated Application on Behalf of Another UC-4: Complete Re-Determination of Eligibility UC-5: View Status of Application UC-6: Submit Additional Information for Application UC-7: Process Application UC-8: Update Client Changes UC-9: Setup Eligibility Rules Integrated Eligibility Capabilities UC-10: Schedule Interview / Assessment UC-11: Conduct Interview / Assessment (and record results) UC-12: Issue and Track Benefit UC-13: Determine Spenddown and Submit Expenses UC-14: Request Service UC-15: Appeal Decision UC-16: File Grievance UC-17: Recover Benefits UC-18: Recover Benefits Collect Over Payment Shared Capabilities UC-19: Create User Account UC-20: View Client Information (Client) UC-21: Search for Client

5 UC-22: View Client Information (Staff) UC-23: Record Client Consent (and changes, revocation) UC-24: View Alerts and Notifications UC-25: Search for and View Service Provider UC-26: Manage Caseload UC-27: Create Referral to Service / Program UC-28: Modify or Withdraw Referral UC-29: Acknowledge Referral UC-30: Accept or Deny Referral UC-31: View / Change Referral Status UC-32: Record Shared Case Note UC-33: Read Shared Case Note UC-34: Send Secure Message UC-35: Read Secure Message UC-36: Make Program Activity Assignment UC-37: Track Time for Activity Assignment UC-38: Access and View Dashboard UC-39: Access and View Standard Report UC-40: Access and View Parameter-Based Report UC-41: Create Ad Hoc Query And Report UC-42: Setup Alert and Notification Rules

6 6 1.0 Introduction 1.1 Streamlining Health and Human Services (HHS) Initiative The State of Vermont (Vermont) has enacted legislation (Act 48) to create the framework for Green Mountain Care and focuses on developing a unified health system by 2017 and providing guidance and recommendations for transitioning Vermont s current public and private health care system. In response to the legislation, Vermont has developed a Blueprint for Health that is the State of Vermont s program for integrating a system of health care for patients, improving the health of the overall population, and improving control over health care costs. The Blueprint resides in Agency of Human Services (AHS) and provides guidance for key technology standards. Related to this Blueprint, AHS has developed a vision for a person-centered Health Services Enterprise that identifies a number of key organizational capabilities which are enabled by information technologies. This vision is accompanied by an aggressive multi-year Health Services Enterprise Roadmap. The Roadmap focuses on: Leveraging the Oregon Transfer to the degree possible to meet Vermont s requirements Health and human services portfolio management Core system components and shared services Health Benefits Exchange (HBE) and Views business architecture and requirements, which includes the State s implementation of the Health Insurance Exchange (HIX) The Medicaid Management Information System (MMIS) Federal partnerships and requirements Shared data analytics and infrastructure This document focuses on the future capabilities of a Health Services Enterprise Platform and the Integrated Eligibility application, which will be built on top of the Platform. 1.2 SOA HSE Platform Vision To streamline Health and Human Services, Vermont is moving from a program-centric approach focused on discrete outputs to a person-centric approach focused on delivering services to achieve the desired outcomes. Achieving the Platform vision will mean adopting a different way of approaching the HHS organizational structure and the model of practice, modifying policies that constrain the ability to share data and introducing a new way to think about HHS Information Technology as well as other changes. The following diagram shows the evolving approach from the current state to the target state.

7 7 Figure 1: Vermont Health and Human Services (SOA HSE Platform) Vision When the future solution is fully implemented the following key capabilities will be in place: Integrated Eligibility and Ancillary Functionality 1. Screening, Application and Determination: Web-based, real-time eligibility determination through an integrated application that supports multiple programs (when possible) Leveraging a dynamic, rule-based rules engine that allows for update of eligibility rules without significant effort Renewing benefits at intervals specified by each program or upon client changes Supporting additional activities required after program enrollment such as assignment of a case worker, client signature on required forms or other items Note: Activities vary by program and some programs require activities such as signature of required forms pre-enrollment; all activities should be conducted as per program rules Managing changes or events affecting a client s eligibility to receive benefits that may result in immediate suspension, termination of benefits or require the client to go through the re-determination process 2. Intake and Admission: Collection, verification and processing of additional information needed prior to benefits issuance 3. Interviews/Assessments and Scheduling: Scheduling appointments for screenings/assessments and making a level of care determination or other recommendation based upon information collected during a interview/assessment

8 8 4. Benefits Issuance, Redemption and Management for programs other than Medicaid: Issuance of the correct benefit provided through the State of Vermont s continuum of health and human services along with the creation and delivery of a welcome package describing pertinent details. Tracking benefit usage and investigating as well as rectifying potential discrepancies in benefits issued 5. Appeals/Grievances: Supporting the activities required for an individual to place a request for the State to revisit an eligibility determination, re-determination or benefit management decision 6. Service Delivery: Supporting the activities required to provide Clients with the services for which they are approved 7. Additional Functionality: This Business Process Analysis (BPA) Report defines additional functionality to support areas such as caseload management and other program-specific needs Data Sharing Functionality 1. Client / Provider Look-Up and Query: The White Pages for Clients (Master Client Index) and Providers (Master Provider Index) summarizing a listing of unique Clients/Providers and demographic information; identification of program enrollment and current services for Clients as well as a Consent Registry that controls, based upon privacy and confidentiality rules, what information can be shared, when and with whom 2. Manage Referrals: Making referrals to Providers and tracking the referral from creation to acceptance/denial and ultimately closure; Setting up on-ongoing notifications regarding referral status as needed 3. Case Collaboration: Supporting outcome-focused case management through sharing of Client data between multiple parties; creation of a virtual Client record, supported by the Consent Registry, that spans Agencies/Programs for the duration of the collaboration Shared Analytics Functionality 1. Reporting and Business Intelligence: A combination of standard, parameter-driven and ad hoc reports as well as complex analytic tools supporting what if analysis, alerts/notifications and other capabilities Displaying alerts and notifications to a worker and/or Client Driven by population based analysis, alerts and notification providing timesensitive information to inform workers of recommendations, events or other important information Making or supporting program decisions using reporting and further decision support capabilities

9 9 1.3 Purpose of the Business Process Analysis (BPA) Report The purpose of the BPA is to present the business process functionality to be provided for Integrated Eligibility (IE) and the Health Services Enterprise Platform (HSEP) once the future solution is fully implemented. The BPA provides a comprehensive view of the State s functional requirements for the State s health and human services service-oriented architecture (SOA) enterprise and integrated eligibility (IE) solution. The analysis is comprised of workflows and use cases depicting the desired future state for Vermont s health and human services (HHS) delivery business processes and the technology alignment that will be required to achieve this future state. In conjunction with the functional requirements detailed in the BPA and the general system design and non-functional (technical, performance and implementation) requirements the State has defined, the BPA should be used to: Provide technology partners, internal or external, with a sufficient understanding of the scope and complexity required to design, build and implement the SOA enterprise for Vermont s HHS and the IE solution to allow accurate estimates of schedule and cost Provide Vermont users with a common language to articulate their understanding of the system capabilities Allow users to discuss what the system needs to do and not how it should do it (i.e. not providing constraints for a particular design) Some of the underlying assumptions made in this document include the following: Existing policies and eligibility category rules will be changed to enable this functionality Change management activities must parallel the design, development and implementation of the HHS SOA enterprise functionality and IE solution to address the impact of the redesign of Vermont s HHS on the State s organizational structure, model of practice, required staff roles, responsibilities and skills, and staff development The HHS SOA enterprise must support the full continuum of the State s HHS through a phased approach to the development of the identified functionality in the BPA Time critical functionality around the HHS SOA enterprise functionality and IE rules for Modified Adjusted Gross Income (MAGI) must be achieved for the Health Insurance Exchange (HIX) by October 2013 for pre-enrollment for those deemed eligible for the State s HIX coverage Time critical functionality around the HHS SOA enterprise functionality and IE rules for Medicaid and CHIP must be achieved by January 2014

10 Approach and Methodology The business process analysis was developed using a workshop-driven approach based upon The Life of the Case Methodology. The Life of the Case is a proven methodology for the development of process flows, scenarios, use cases and functional requirements for health Information Technology (IT) systems. The Life of the Case provides a view of how clients and partner organizations interact; ensuring use cases and requirements are focused on supporting the business processes. A process review and workshop approach was employed in order to quickly gather input from a diverse group of participants representing various stakeholder groups in the Agency for Human Services: The primary objectives of the first functional workshop were to: 1. Introduce the Life of the Case Methodology, the artifacts used in the Methodology and the integration of those artifacts. 2. Identify opportunities for data sharing. Data sharing opportunities were identified based on the information required to accomplish each process flow. 3. Define the process for reviewing strawman artifacts of the Methodology and the desired outcome of the review process. The primary objective of the second workshop was to review key feedback elements generated by the review cycle and address any outstanding questions. The information gathered and validated in the workshops was used to create this business process analysis document as well as functional and non-functional requirements matrices. Together, these artifacts provide a comprehensive view of the requirements needed to perform specific functions in the future state.

11 Workflows The 29 workflows that make up the Integrated Eligibility and Health Services Enterprise Platform solutions were based on workflows that have been documented for a number of other States that have embarked on the development of integrated eligibility solutions. This baseline was then augmented by considering the Blueprint provided by CMS, and the work that is under way in Oregon. Finally, and most importantly, they were modified to reflect input from key State of Vermont stakeholders regarding requirements and processes specific to the State of Vermont HHS environment. 3.1 List of Workflows ID Workflow Name Description WF-0 High Level Process The key activities occurring throughout the life of a case - from initial application and enrollment to re-determination pertinent to integrated eligibility and data sharing. WF-1 WF-2 Conduct Application and Enrollment - via Self-Service Conduct Application and Enrollment - via Worker The activities required for an individual to apply for benefits using a self-service Web portal. The individual creates an account for the self-service Web portal and completes the application online. The activities required for an eligibility worker to apply for benefits on behalf of an individual. WF-3 Apply Eligibility Rules The activities required for the System to apply eligibility rules in order to approve or deny an application for benefits. WF-4 Conduct Re-Determination The activities required to renew benefits at intervals specified by each program or upon client changes. In some cases, redetermination may be passive, requiring little or no action from the client. WF-5 Manage Client Changes The changes or events affecting a client's eligibility to receive benefits that may occur. The changes may result in immediate termination of benefits or require the client to go through the re-determination process. WF-6 Appeals The activities required for a client to appeal decisions or actions related to eligibility determination, re-determination, benefits management or other areas. WF-7 Grievances The activities required for a client to file a grievance about decisions or actions related to eligibility determination, redetermination, benefits management or other areas. WF-8 Client Scheduling On Demand WF-9 Client Scheduling Appointment The activities required to determine if an interview/assessment may be completed immediately. The activities required for a Client to schedule an appointment for an interview/assessment. WF-10 Issue Benefits The activities required to issue benefit(s) to a Client including a welcome package where applicable. WF-11 Spenddown The activities required for a Client to obtain Medicaid benefits when their countable income exceeds the threshold established by Medicaid.

12 12 ID Workflow Name Description WF-12 Spenddown-Submit Expenses The activities required for a Client to reduce their countable income by presenting evidence of expenses incurred for medical or other relevant expenses. WF-13 Conduct Interview The activities required for an eligibility worker to obtain additional information or validate information on the application. Interviews may be conducted over the phone or in person. WF-14 Conduct Assessment The activities required for a worker to make a level of care determination or other recommendation as part of the eligibility determination process or in the course of rendering services. WF-15 Complete Intake / Admission The additional activities required after program enrollment such as assignment of a case worker, client signature on required forms or other items. WF-22 Benefit Recovery The activities required to identify and investigate any discrepancies between the level of benefit a Client is receiving and should receive. WF-23 Benefit Recovery- Collect Over-Payment The activities required to collect an over payment from a Client. WF-18 WF-19 Conduct Client Search and Lookup View Alerts and Notifications The activities required to search for a client across all programs. The worker enters basic information about the client such as name or date of birth to begin the search. The activities required to display alerts and notifications to a worker. Driven by population based analysis, alerts and notification provide time-sensitive information to inform workers of recommendations, events or other important information. WF-20 Render Client Services The activities that occur during the course of delivery services to clients. Examples of activities include managing referrals, conducing assessments, and re-determination. WF-21 Manage Referrals The activities required to create a referral and manage the referral through the subsequent life cycle. The referral management process begins with the identification of the need for a referral which may occur during the application and enrollment process or rendering services process. WF-22 Manage Caseload The activities required to assign cases to individuals or queues for manual intervention to complete required activities. WF-23 WF-24 Program Activity Assignment Program Activity Time Tracking The activities required to make an activity assignment. Workers collaborate with the Client to understand not only their needs, but also their challenges. Additional resources are brought to bear to eliminate any hurdles to completing an assignment. Using assessment results and other information about the Client, an assignment is made. The activities required to track the hours worked and/or missed by the Client on a specific assignment. Providers who offer assignments use the self-service portal to view an aggregate list of all active assignments. For each, the Provider enters the

13 13 ID Workflow Name Description WF-25 Management Reporting (High-level) number of hours worked or missed and any associated comments. The activities required to make or support program decisions using shared analytics. WF-26 Conduct Data Gathering The activities required to define the problem requiring analysis, identify the data required for analysis and obtain the data. The problem definition activity is the cornerstone of all future activities within management reporting. WF-27 WF-28 WF-29 WF-30 Conduct Data Profiling and Acquisition Conduct Data Analysis, Research, and Evaluation Conduct Evaluation and Develop Recommendations Analysis Communication and Explanation The activities required to establish a data set for ongoing monitoring and analysis. For the targeted data set(s), a profile including intervals and mechanisms for analysis is defined. Updates to the profile are made based on results of the analysis. The activities required to determine the types of analysis required and review the data in order to identify insights related to the initial problem definition. Based on the problem definition, the analysis may be completed through mechanisms such as standard reports or more complex predictive analysis. The activities required to review the findings from the data analysis and propose a plan of action. The plan of action may include recommendations to take no action, monitor the problem or prescriptive steps to solve (or significantly improve) the problem identified in the data gathering process. The activities required to communicate the data analysis findings and selected plan of action to the target audience. Following the Deming Principle of Plan-Do-Act-Check, the final activity in this process is monitoring whether or not the desired outcomes were achieved and repeating steps as needed.

14 Workflows Overview WF-0 High-Level Process Map This process flow depicts key activities occurring throughout the life of a case from screening and initial application to re-determination. While there are additional steps across the Life of a Case, only those steps pertinent to integrated eligibility and data sharing are depicted on the diagram. Start Conduct Screening Conduct Interview / Assessment Determine Eligibility Appeals / Grievances Complete Intake Issue Benefits Redeem Benefits Manage Referrals Manage Client Changes Case Collaboration Redetermination End Client/Service Provider Search, Lookup and Query Scheduling Benefit Management Caseload Management Reporting and Business Intelligence

15 Screening, Application and Determination (SAD) WF-1 Conduct Application and Enrollment - via Self-Service This process flow depicts the activities required for application and enrollment via Self-Service. It begins with an optional screening step which predicts whether or not an individual (or household) will be eligible for benefits. The screening is completely anonymous; no identifiable information is required. If the individual chooses, he/she may complete an application for benefits. Information provided by the applicant is validated against State records in other agencies if the client has provided consent and the information is available. The application spans multiple programs some of which may share the same eligibility rules (e.g., percent of Federal Poverty Level), while others may have distinct eligibility rules (e.g., specific health condition). Additionally, some programs may require results from an interview or an assessment prior to eligibility determination. Once a determination of eligibility has been made, the individual receives a notification. This notification may be provided in real-time if the determination is completed quickly or it may be delayed pending interview/assessment results or other information. In some cases, notifications may be staggered allowing for immediate feedback where a determination can be made quickly. The following use cases capture the key functionality contained within the process flow: Complete Self-Service Anonymous Pre-screening Create User Account Complete Self-Service Integrated Application Complete Self-Service Integrated Application on Behalf of Another View Status of Application Submit Additional Information for Application View Client Information (Client)

16 16

17 WF-2 Conduct Application and Enrollment - via Worker This process flow depicts the steps required for an eligibility worker (representative of the State) to facilitate completion of an application on behalf of an individual. The worker begins by performing a search for the individual within the web portal. The worker will create an account for the individual to access the self-service web portal if they do not already have one. The worker asks the individual a series of questions in order to complete the application and indicates a specific program of interest or all programs covered by the application. Upon submission, the system applies the eligibility rules. If all of the required information is available, the worker receives immediate feedback on the eligibility determination. In some cases, additional information may be requested or an interview/assessment may be required which delays the eligibility determination. The following use cases capture the key functionality contained within the process flow: Create User Account Submit Additional Information for Application Process Application

18 18

19 WF-3 Apply Eligibility Rules This process flow depicts the steps required for the System to apply eligibility rules in order to approve or deny an application for benefits. Once all of the relevant information and any required assessments/screenings have been completed, the System determines eligibility. The eligibility determination may be for one or multiple programs depending on what the Client indicated on their application. The following use cases capture the key functionality contained within the process flow: Submit Additional Information for Application Setup Eligibility Rules

20 20

21 WF-4 Conduct Re-Determination This process flow depicts the steps required for a client to renew their benefits. At intervals specified by each program or upon client changes, eligibility must be assessed to determine whether or not the client may continue to receive benefits at the current level. The process flow begins with a notification to the client indicating re-determination is required. The client may decide to use their account to validate their information via the self service portal or request the assistance of an eligibility worker. In some cases, re-determination may be passive, requiring little or no action from the client. The following use cases capture the key functionality contained within the process flow: Complete Re-Determination of Eligibility

22 22

23 WF-5 Manage Client Changes This process flow depicts changes or events affecting a client s eligibility to receive benefits that may occur. The changes may result in immediate termination of benefits or require the client to go through the re-determination process. Some examples of the changes or events include client inactivity for a specified time period, client demographic information changes and household composition changes. The following use cases capture the key functionality contained within the process flow: Update Client Changes

24 24

25 Integrated Eligibility Capabilities WF-6 Appeals This process flow depicts the steps required for a client to appeal decisions or actions related to eligibility determination, re-determination, benefits management or other areas. An appeal can be requested by the Client for many different reasons such as a determination decision for either approval or denial of benefits. The process flow begins with the client requesting an Appeal Hearing date/time. Once a hearing has been conducted, the System is updated with the decision and notification is sent. The following use cases capture the key functionality contained within the process flow: Appeal Decision

26 26

27 WF-7 Grievances This process flow depicts the steps required for a client to issue a complaint. The client may decide to file a written or verbal grievance. Once the grievance is reviewed by the grievance entity, the System is updated and the notification with resolution is sent. A grievance review can be requested by the Client within a pre-determined timeframe. Once the grievance review has been conducted by a different party, the System is updated with the decision and notification is sent. The following use cases capture the key functionality contained within the process flow: File Grievance

28 28

29 WF-8 Client Scheduling On Demand This process flow depicts the steps required to determine if an interview/assessment may be completed immediately. For an interview/assessment to occur immediately the Client must be willing to participate in the session and the appropriate Worker must be available to conduct the interview/assessment. The following use cases capture the key functionality contained within the process flow: Schedule Interview/Assessment

30 30

31 WF-9 Client Scheduling Appointment This process flow depicts the steps required for a Client to schedule an appointment for an interview/assessment. For a Client to follow this process flow an event such as re-determination must have triggered the need for an interview/assessment; appointments cannot be requested at will. Once the need for an interview/assessment is identified, the Client may request an appointment via the self-service portal if the underlying resource calendar is available. The resource calendar contains the inventory of appointment times available. If a resource calendar is not available, the request will be routed to a Worker to determine an appropriate appointment time and follow up with the Client. The following use cases capture the key functionality contained within the process flow: Schedule Screening / Assessment Request Service

32 32

33 WF-10 Issue Benefits This process flow depicts the activities required to issue benefit(s) to a Client including a welcome package where applicable. Once benefits are issued, they are tracked to determine whether or not they are redeemed. For cash benefits, statuses such as voided and cancelled are also tracked. If there are any potential discrepancies between the benefits issued and the level of benefits a Client is truly eligible for, the benefits recovery process is triggered. The following use cases capture the key functionality contained within the process flow: Issue and Track Benefit Recover Benefit

34 34

35 WF-11 Spenddown This process flow depicts the steps required for a Client to obtain benefits when their countable income or resources exceed the threshold established by the Program. To qualify for the Program, the Client may attempt to reduce their countable income or resources through spenddown. Spenddown is the process of applying expenses incurred in order to reduce the countable income or resources until they meet or is below the threshold established by the Program. The dollar amount that must be reduced is referred to as the spenddown amount. On a basis captured by an accounting period that varies by program, Clients attempt to meet the spenddown amount. The Client may opt to carry over expenses to a future period if they will not meet the spenddown amount for the current period. Alternately, if the spenddown amount is exceeded or there is an ongoing expense, the excess or ongoing expense may be applied to future periods. Once the threshold is met through evidence of relevant expenses benefits are issued to the Client for the balance of the period. The following use cases capture the key functionality contained within the process flow: Make Spenddown Payment Issue and Track Benefits View Alerts / Notifications Appeal Decision

36 36

37 WF-12 Spenddown-Submit Expenses A Client may reduce their countable income by presenting evidence of expenses incurred for medical or other relevant expenses. Clients may upload evidence of these expenses through the self-service portal or send them to a Worker using an alternate method (e.g., fax, US Mail, drop off). A Worker will review the expenses and apply it towards the spenddown amount if it is an eligible expense. The following use cases capture the key functionality contained within the process flow: Determine Spenddown and Submit Expenses Make Spenddown Payment View Alerts / Notifications Issue and Track Benefits Appeal Decision

38 38

39 WF-13 Conduct Interview This process flow depicts the steps required to set up, prepare for, and conduct an interview. It begins with a notification to the client informing them of the need for an interview. In preparation for the interview appointment, the worker searches for and locates the client within the system. After conducting the interview, the relevant information is recorded within the system and notifications are sent to the appropriate individuals in accordance with the client s consent. Interviews may occur during the application and enrollment or rendering services processes. In application and enrollment, interviews are primarily used to obtain or validate information. The following use cases capture the key functionality contained within the process flow: Conduct Interview/Assessment

40 40

41 WF-14 Conduct Assessment This process flow depicts the steps required to set up, prepare for and conduct an assessment. It begins with a notification to the client informing them of the need for an assessment. In preparation for the assessment appointment, the worker searches for and locates the client within the system. After conducting the assessment, the relevant information is recorded within the system and notifications are sent to the appropriate individuals in accordance with the client s consent. Assessments may occur during the application and enrollment or rendering services processes. In application and enrollment, assessments are primarily used to obtain or validate information or make a level of care determination. The following use cases capture the key functionality contained within the process flow: Conduct Interview/Assessment

42 42

43 WF-15 Complete Intake / Admission This process flow depicts the additional activities that may be required upon enrollment into a program. It begins with the worker searching for the client in order to review and update admissions information. The worker may assign resources such as a case worker if needed, request signature on additional forms or collect other information. The following use cases capture the key functionality contained within the process flow: N/A

44 44

45 WF-16 Benefit Recovery This process flow depicts the identification and subsequent investigation into any discrepancies between the level of benefit a Client is receiving and should receive. If a discrepancy is confirmed, the amount and type (over or under payment) is determined. For Clients whose benefits are active, their benefit level is re-calculated to correct the discrepancy going forward. The State reimburses Clients if there was an under payment. For over payments, a process to collect the amount is triggered. The following use cases capture the key functionality contained within the process flow: Issue and Track Benefits Recover Benefits Recover Benefits Collect Over Payment View Alerts / Notifications Appeal Decision

46 46

47 WF-17 Benefit Recovery- Collect Over-Payment This process flow depicts the steps required to collect an over payment from a Client. The Client is notified of the over payment. Ultimately, a recovery method including, but not limited to recoupment or direct payment is specified. Payments are tracked until the Client s balance is zero. For Clients who miss payments or do not pay in full, additional recovery methods such as tax offsets may be pursued. The following use cases capture the key functionality contained within the process flow: Issue and Track Benefits Recover Benefits Recover Benefits Collect Over Payment View Alerts / Notifications Appeal Decision

48 48

49 Shared Capabilities WF-18 Conduct Client Search and Lookup This process flow depicts the activities required to search for a client across all programs. The worker enters basic information about the client such as name or date of birth to begin the search. If the search returns multiple results, the worker is able to further refine the results. To maintain data integrity, the worker notifies the system administrator of duplicate records. The following use cases capture the key functionality contained within the process flow: Search for Client View Client Information (Staff)

50 50

51 WF-19 View Alerts and Notifications This process flow depicts when alerts and notifications are displayed to a worker. Alerts and notifications are often driven by population-based analysis. For example, a worker may view an alert recommending a flu shot if the client is a senior citizen. Alerts and notification provide timesensitive information to inform workers of recommendations, events or other important information. The following use cases capture the key functionality contained within the process flow: View Alerts and Notifications Setup Alert and Notification Rules

52 52

53 WF-20 Render Client Services This process flow depicts activities that may occur as services are delivered to clients. During the enrollment period, a provider may identify a need to update client information, conduct assessments or make referrals to other providers. Changes to client information may lead to the re-determination process. Assessments may be conducted to determine changes to the level of care determination, check effectives of the service plan or other reasons. The client may be referred to other providers if a need is identified. The following use cases capture the key functionality contained within the process flow: Record Shared Case Note Read Shared Case Note Record Client Consent

54 54

55 WF-21 Manage Referrals This process flow depicts the activities required to create a referral and manage the referral through the subsequent life cycle. The referral management process begins with the identification of the need for a referral that may occur during the application and enrollment process or rendering services process. While creating a referral, the worker searches for the provider best able to deliver the desired service and meet the needs of the client. The primary statuses for referrals include: Acknowledged: indicates the provider has confirmed receipt Accepted: indicates the provider is willing to deliver the requested service Rejected: indicates the provider is unwilling to deliver the requested service Once the referral is accepted, the client appointment can be scheduled. After the appointment, the provider records selected information within the system. Notifications are sent to appropriate individuals regarding the appointment and its outcome. The following use cases capture the key functionality contained within the process flow: Modify Or Withdraw Referral Acknowledge Referral Accept Or Deny Referral View / Change Referral Status Search for and View Service Provider

56 56

57 WF-22 Manage Caseload This process flow depicts three high level patterns for caseload management. In this context, caseload management is the assignment of work to the appropriate resources for completion. The three patterns include: 1. Automatic Routing to Queue Cases are automatically routed to queues based on a set of pre-defined rules. Cases from the queues are assigned to individuals manually by a supervisor or the individuals themselves. 2. Automatic Routing to Worker Cases are automatically routed to a specific Worker based on a set of pre-defined rules. These rules may be based on a round robin, an individual s role, an individual s set of assigned Clients or other heuristic. 3. Manual Routing Cases are manually assigned to the appropriate queue or individual after a Worker triages the request to determine where it belongs. The following use cases capture the key functionality contained within the process flow: Manage Caseload Create Referral to Service / Program Send Secure Message Read Secure Message

58 58

59 WF-23 Program Activity Assignment This process flow depicts the activities required to make an activity assignment. Workers collaborate with the Client to understand not only their needs, but also their challenges. Additional resources are brought to bear to eliminate any hurdles to completing an assignment. Using assessment results and other information about the Client, an assignment is made. Depending on the benefit level, multiple assignments may be given to a Client in order to meet the number of hours required. Once the assignment is made, a notification is sent to both the Client and the Provider offering the assignment. The following use cases capture the key functionality contained within the process flow: Issue and Track Benefits Make Program Activity Assignment View Alerts / Notifications

60 60

61 WF-24 Program Activity Time Tracking This process flow depicts the activities required to track the hours worked and/or missed by the Client on a specific assignment. Providers who offer assignments use the self-service portal to view an aggregate list of all active assignments. For each, the Provider enters the number of hours worked or missed and any associated comments. Workers may report hours if a Provider fails to do so by the designated due date. If the Client has missed hours, they may provide Good Cause for missing the hours and work with the State to make up the hours. If the Client does not have Good Cause for missing hours, penalties apply up to and including revocation of assignments. The following use cases capture the key functionality contained within the process flow: Make Work Program Assignment Track Time for Work Program

62 62

63 WF-25 Management Reporting (High-level) This process flow depicts the activities required to make or support program decisions using shared analytics. The activities include: Data Gathering: The activities required to define the problem requiring analysis, identify the data required for analysis and obtain the data. The problem definition activity is the cornerstone of all future activities within management reporting. Data Profiling and Acquisition: The activities required to establish a data set for ongoing quality monitoring and analysis. For the targeted data set(s), intervals and mechanisms for analysis and statistical measures are defined. Changes to the use of these data sets are made based on results of the analysis. Data Analysis: The activities required to determine the types of analysis required and review the data in order to identify insights related to the initial problem definition. Based on the problem definition, the analysis may be completed through mechanisms such as standard reports or more complex predictive analysis. Evaluation and Recommendations: The activities required to review the findings from the data analysis and propose a plan of action. The plan of action may include recommendations to take no action, monitor the problem or prescriptive steps to solve (or significantly improve) the problem identified in the data gathering process. Communication and Education: The activities required to communicate the data analysis findings and selected plan of action to the target audience. Following the Deming Principle of Plan-Do-Act-Check, the final activity in this process is monitoring whether or not the desired outcomes were achieved and repeating steps as needed. The following use cases capture the key functionality contained within the process flow: Access And View Dashboard Access And View Standard Report Access And View Parameter-Based Report Create Ad Hoc Query And Report

64 64

65 WF-26 Conduct Data Gathering This process flow depicts the activities required to define the problem requiring analysis, identify the data required for analysis and obtain the data. The problem definition activity is the cornerstone of all future activities within management reporting. Oftentimes, this is an iterative process that is revisited as the results of the analysis are reviewed and refined. Following the problem definition, the analysts determine what data is required and the data source. The data sources may be internal or external. Once the data has been collected, it is stored in a temporary repository for analysis. The following use cases capture the key functionality contained within the process flow: Access And View Dashboard Access And View Standard Report Access And View Parameter-Based Report Create Ad Hoc Query And Report

66 66

67 WF-27 Conduct Data Profiling and Acquisition This process flow depicts the activities required to establish a data quality profile for targeted data sets through ongoing monitoring, statistical measurement and analysis. For the targeted data set(s), intervals and mechanisms for analysis and statistical measures are defined. These data set(s) may include information from various source systems. In some cases, the raw data in the source systems may need to be manipulated prior to analysis. If this is the case, data will be extracted from the source system, transformed based on logic to support the required profiling and loading into a data store for analysis. The following use cases capture the key functionality contained within the process flow: Access And View Dashboard Access And View Parameter-Based Report Create Ad Hoc Query And Report Access And View Standard Report

68 68

69 WF-28 Conduct Data Analysis, Research, and Evaluation This process flow depicts the activities required to determine the types of analysis required and review the data in order to identify insights related to the initial problem definition. Based on the problem definition, the analysis may be completed through mechanisms such as standard reports or more complex predictive analysis. The analysis may be iterative resulting in additional data gathering before moving on to the next step of evaluation and recommendation. The following use cases capture the key functionality contained within the process flow: Access And View Dashboard Access And View Standard Report Access And View Parameter-Based Report Create Ad Hoc Query And Report

70 70

71 WF-29 Conduct Evaluation and Develop Recommendations This process flow depicts the activities required to review the findings from the data analysis and propose a plan of action. Subject Matter Experts (SMEs) are involved in this part of the process to ensure the fidelity of the recommendations. The plan of action may include recommendations to take no action, monitor the problem or prescriptive steps to solve (or significantly improve) the problem identified in the data gathering process. The following use cases capture the key functionality contained within the process flow: Access And View Dashboard Access And View Standard Report Access And View Parameter-Based Report Create Ad Hoc Query And Report

72 72

73 WF-30 Analysis Communication and Explanation This process flow depicts the activities required to communicate the data analysis findings and selected plan of action to the target audience. The activities include identifying the target audience, determining the appropriate communication channels, preparing the data for publishing and developing educational material. Following the Deming Principle of Plan-Do-Act- Check, the final activity in this process is monitoring whether or not the desired outcomes were achieved and repeating steps as needed. The following use cases capture the key functionality contained within the process flow: Access And View Dashboard Access And View Standard Report Access And View Parameter-Based Report Create Ad Hoc Query And Report

74 74

75 Use Cases The 41 use cases that make up the Integrated Eligibility and Health Services Enterprise Platform solutions were based on use cases that have been documented for a number of other States that have embarked on the development of integrated eligibility solutions. This baseline was then augmented by considering the Blueprint provided by CMS, and the work that is under way in Oregon. Finally, and most importantly, they were modified to reflect input from key State of Vermont stakeholders regarding requirements and processes specific to the State of Vermont HHS environment. 4.1 Use Case Overview Use cases capture the requirements from a client and user perspective. The purpose of the use cases is to illustrate what the system is expected to do, not how it is expected to do it. Each use case contains the following information: Use Case Title Actor(s) Purpose / Objective(s) Trigger(s) Pre-Condition(s) Post-Condition(s) Use Case Flow Associated Use Case(s) Alternative Flow(s) Additional Requirements 4.2 Actors Actors are users of the system. An individual person may be different actors depending on the specific use case. For example, a person might perform the role of assessor while conducting an assessment and play the role of consent recorder when explaining and documenting client consent. A list of users and associated description is summarized below. Client The Client is a recipient of benefits or services from the State and/or contractor. o o o Assessee - The client or applicant receiving an assessment. Applicant The Applicant role can be fulfilled by a client, a caretaker of a client, a System User, or any person that would like to apply for benefits from the State of Vermont. Authorized Representative The Authorized Representative is a person who has the ability and rights to apply for benefits on behalf of another person such as a parent, child, ward or other individual unable to represent himself.

76 76 o Navigators are included as an Authorized Representative for eligibility determination activities. Public The Public is anyone that has access to the Internet that wishes to view information without an account. System User The System User is a State worker or contractor that has access to the System and the appropriate rights to perform the action described. o o o o o o o o o ADPC Worker (Application and Document Processing Center) The ADPC works with paper and electronic documents and indexes by case and document type Analyst - The Analyst is an employee or contractor that has access to the System and the appropriate rights to perform analyses above and beyond accessing standard and parameterized reports. This role will vary in rights and responsibilities based on the individual Analyst and the program(s) they are analyzing. Appeal Worker The Appeal Worker is a member of the Human Service Board or Fair Hearing Unit, as specified. He or she has the rights to perform the described actions for this System. Assessor The person who conducts the screening or assessment. This may be a provider, case worker, intake worker, or other role within the Vermont Agency of Human Services (AHS). Case Worker An authorized State or contractor employee who is the primary worker responsible for a Client s case, or contributes to the case as a provider Consent Recorder The Consent Recorder is an employee or contractor that has the ability to discuss and document consent on behalf of a client. This role may be fulfilled by providers, provider front office staff, case workers or other similar workers. Eligibility Worker The Eligibility Worker is an authorized State or contractor employee who may process an application, assist a client with applying, or apply for benefits on behalf of a client as part of their position. Program Administrator A worker responsible for management of a program with rights to change program rules when required by law, mandate or policy changes. A very limited number of individuals will have the ability to perform this role. Providers A Provider is any contractor who is providing services directly to a client. This may include a case manager or a similar person who is providing coordinating services. The Provider includes both State staff and communitybased providers that directly coordinate the application and receipt of benefits and basically serve as case managers for these benefits. o Receiving Party (recipient of a referral, secure message or shared case note) The Receiving Party is any worker, contractor, program or entity who may provide services directly to a client. This may include a case manager or a similar person who is providing coordinating services. o Referring Party (sender of a referral) The Referring Party is any worker or contractor who is providing services directly to a client and has the appropriate

77 77 o rights to make a referral. This may include a case manager or a similar person who is providing and/or coordinating services. Worker The Worker is an employee of a department and/or agency in Vermont or of a contracted entity who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this System, as well as any contractor. 4.3 Use Case List ID Use Case Name Actor(s) Description Screening, Application and Determination UC-1 Complete Self- Service Anonymous Screening Applicant In this use case, the Client fills out an anonymous screening eligibility form and receives guidance. UC-2 UC-3 UC-4 UC-5 Complete Self- Service Integrated Application Complete Self- Service Integrated Application on Behalf of Another Complete Re- Determination of Eligibility View Status of Application Applicant Authorized Representative, Applicant Applicant Applicant, Worker In this use case, the Client fills out a complete integrated eligibility application online and receives eligibility determination whenever possible. In this use case, the Authorized Representative fills out a complete integrated eligibility application online on behalf of an Applicant and receives eligibility determination. In this use case, the Applicant fills out a redetermination request form online and receives redetermination whenever possible. In this use case, an Applicant or Worker seeks information about the status of an open application. UC-6 UC-7 Submit Additional Information for Application Process Application Client, Eligibility Worker Eligibility Worker, Applicant In this use case, the Client or Eligibility Worker submits electronic or paper documents needed for eligibility determination. In this use case, the Eligibility Worker processes an application that requires his/her involvement. UC-8 Update Client Changes Client, Worker In this use case, the Worker updates the Client s eligibility based on specific events. UC-9 Setup Eligibility Rules Program Administrator In this use case, changes to laws, mandates or program policy prompts a Program Administrator to create, modify or remove a rule.

78 78 ID Use Case Name Actor(s) Description Integrated Eligibility Capabilities UC-10 Schedule Interview/Assess ment Client/Applicant, Authorized Representative, Worker UC-11 Conduct Interview / Assessment (and Record Results) Issue and Track Benefit Determine Spenddown and Submit Expenses Assessor, Assessee This use case demonstrates two ways the client can schedule an appointment. In this use case, the Client requests an appointment for an interview / assessment via the self-service Web portal or with the help of a Worker. The Worker has access to the Solution and the appropriate rights to perform the action described. In this use case, the Assessor conducts an interview or assessment to obtain information for eligibility determination, re-determination or service delivery. UC-11 Eligibility Worker, Applicant, In this use case, benefits are issued to a Client and Client benefit redemption/usage is tracked. UC-12 Eligibility Worker, Applicant In this use case, the Solution determines the spenddown amount and applies eligible expenses to offset the spenddown amount. UC-14 Request Service Client In this use case, the Client User requests services through the Solution. UC-15 Appeal Decision Client/Applicant, Appeal Worker, Worker In this use case, a Client appeals a decision through the Web portal and the appeal process is taken through final ruling. UC-16 File Grievance Client/Applicant, Worker In this use case, a Client files a grievance through the Web portal and the grievance process proceeds. UC-17 Recover Benefits Client, Worker In this use case, a Worker investigates a complaint or alert indicating a Client is receiving a higher or lower level of benefits than appropriate and takes corrective action. UC-18 Recover Benefits Collect Over Payment Client, Worker In this use case a Worker collaborates with a Client to collect and track over payments that were issued to the Client. Shared Capabilities UC-19 Create User Account Client In this use case, the Client sets up login credentials and establishes basic preferences. UC-20 View Client Information Client In this use case, the Client views his/her information in the Solution. (Client) UC-21 Search for Client Worker In this use case, the Worker searches for a Client in the Solution. UC-22 View Client Information Worker In this use case, the Worker views information available through the Solution. (Staff) UC-23 Record Client Consent Consent Recorder, Client In this use case, the Consent Recorder records client consent in the Solution. UC-24 View Alerts and Notifications Public, Client, Worker In this use case, the Public, Client or Worker receives alerts and notifications within a set of pre-defined parameters.

79 79 ID UC-25 UC-26 UC-27 UC-28 UC-29 UC-30 UC-31 UC-32 Use Case Name Search For and View Service Provider Manage Caseload Create Referral to Service/Program Modify Or Withdraw Referral Acknowledge Referral Accept Or Deny Referral View / Change Referral Status Record Shared Case Note Actor(s) Worker, Client, Public Client/Applicant, Worker Referring Party, Receiving Party Referring Party, Receiving Party Referring Party, Receiving Party Referring Party, Receiving Party Referring Party, Receiving Party Provider Description In this use case, the Worker searches for a service provider and views information about that provider. In this use case, a case is routed to the appropriate Worker or queue so a Worker may complete the required actions. The Worker has appropriate access rights to the Solution to perform the action described. In this use case, the Referring Party enters a referral in Solution. In this use case, the Referring Party modifies or withdraws a referral in the Solution. In this use case, the Receiving Party acknowledges the referral in Solution. In this use case, the Receiving Party accepts or denies the referral in Solution. In this use case, the Referring Party modifies or withdraws a referral in the Solution. In this use case, the Provider creates a case note in the Solution to be read by collaborating providers. UC-33 UC-34 UC-35 UC-36 UC-37 UC-38 UC-39 UC-40 UC-41 UC-42 Read Shared Case Note Send Secure Message Read Secure Message Make Program Activity Assignment Track Time for Activity Assignment Access And View Dashboard Access And View Standard Report Access And View Parameter- Based Report Create Ad Hoc Query And Report Setup Alert and Notification Rules Provider Provider Provider Client, Provider, Case Worker Client, Provider, Case Worker Worker, Public Worker, Public Worker, Public Analyst Program Administrator In this use case, the authorized Receiving Party reads case notes in Solution that were posted by Sending Service Provider. In this use case, the Provider sends a secure message. In this use case, the Provider receives and reads a secure message using Solution. In this use case, the Case Worker works with the Client to make a program activity assignment with a Provider In this use case the Provider or Case Workers enters activity time sheets for the Client In this use case, the Worker accesses and views a dashboard report in the Solution. In this use case, the Worker views a static standard report in the Solution. In this use case, the Worker views a Parameter-Based Report. In this use case, the Analyst creates an ad hoc report based on data sources available to the Solution. In this use case, the Program Administrator creates a new rule, changes an existing rule or inactivates an existing rule.

80 80

81 Use Cases Screening, Application and Determination UC-1: Complete Self-Service Anonymous Screening Actors Applicant The Applicant role can be fulfilled by a client, a caretaker of a client, a System User, or any person that would like to apply for benefits from the State of Vermont. Purpose and Objectives Applicants will have the ability to obtain preliminary feedback of their eligibility for State programs by filling out an anonymous, online form. The form walks the applicant through a stepby-step process asking a limited number of targeted questions that are the basis for eligibility. Branching logic is used to tailor the screening questions based on the programs the applicant is interested in or other factors. The form will not guarantee eligibility for an applicant; it will inform them whether filling out the entire integrated eligibility application would likely be successful and which programs they would most likely be eligible for. Using this tool, or not using this tool, will not affect the Applicant s ability eligibility or the ability to fill out a full eligibility application, but will populate information into the full application if requested by the Applicant. In this use case, the Applicant fills out an anonymous screening form and receives guidance. Trigger Events The Applicant would like to receive guidance on their expected eligibility for State programs or Exchange-based coverage Pre-Condition The Applicant has Internet access Post-Condition The Applicant receives guidance on their eligibility for State programs and Exchangebased coverage The Applicant is directed to the integrated eligibility online application form The Applicant decides not to proceed with completing the integrated eligibility online application form Use Case Flow 1. The Applicant navigates to the self-service Web portal and selects the anonymous Screening eligibility tool 2. The System displays a step-by-step form with branching logic requesting required and optional data elements

82 82 a. If completing this for the Applicant s self, the Applicant enters information about themselves b. If completing this for another person, the Applicant enters information about the other person c. Required / optional data elements include, but are not limited to: i. Type of assistance for which guidance is requested may be chosen by program or by service (including descriptions of the assistance), which could include: 1. All types of assistance (default) 2. Specific programs (such as Medicaid) 3. Programs categories or groups 4. Include sub-programs ii. Employment status iii. Income (entered or computed based on Applicant input) iv. Assets v. Expenses (for household, dependents, etc.) vi. Household composition (as detailed as needed) 1. Relationships of the household vii. Health status which may include at least: 1. Disabilities 2. Pregnancy viii. Dependents ix. Age / date of birth x. State of residency / zip code d. The system uses branching logic to determine which data elements the Applicant must complete. This is based on the Applicant s input to questions such as the type of assistance, income, health status, etc. 3. The Applicant enters the required and optional information requested and submits the form 4. The System generates preliminary guidance on Applicant eligibility based on pre-defined rules and presents the guidance to the Applicant a. If the System is able to determine whether the Applicant may be eligible for multiple programs or benefits, the System lists all such programs and benefits b. If the System is unable to determine whether the Applicant may be eligible for any programs or benefits, the System displays appropriate alternatives from Vermont resource directories such as or ADRC (Aging & Disabilities Resource Centers), including, but not limited to i. Programs may include the following categories:

83 83 1. Additional State programs not included in the Screening guidance 2. Other non-state programs ii. Other resources c. The System displays information about how the guidance was made and limitations of the guidance (e.g., the guidance is not a guarantee of eligibility) d. In all cases the System displays a link to the full integrated eligibility application, which includes eligibility for Exchange-managed coverage e. At any time, if the Client wishes to return to the beginning of the screening they will be able to change any entered information, but will not be required to re-enter information they have already entered 5. The System displays links to next steps a. If the System determined potential eligibility, the System offers to transfer information entered on the anonymous form to the full application b. The System offers a printable version of the information presented Association with Other Use Cases Complete Self-Service Integrated Application Complete Self-Service Integrated Application On Behalf Of Another Alternate Flows If the Applicant does not wish to complete the screening, he or she may go directly to completing the application Additional Requirements The System shall allow the Applicant to restart the process and enter a new set of information at any time The System shall allow the Applicant to erase all entered information at any time prior to final submission of the application The System shall allow the Applicant to exit the Screening process at any time before final submission without formal application to any program The System shall display options for coverage managed by the Exchange integrated into other programs offered by the State

84 UC-2: Complete Self-Service Integrated Application Actors Applicant The Applicant role can be fulfilled by a client that would like to apply for benefits from the State of Vermont. Purpose and Objectives One of the core capabilities of the integrated eligibility application is the ability to determine eligibility across a range of programs without the need to apply for each program individually. This can be accomplished through an online, step-by-step form with branching logic that the Applicant can complete from any computer with Internet access and minimal human assistance. Where human intervention is required for steps such as assessments or submitting additional information, Applicants are routed to an Eligibility Worker for assistance via various channels such as call or live chat with a call center representative, or Web link to various resources. (See Conduct Interview / Assessment and Submit Additional Information for Application use cases). In addition to providing information on the program eligibility, the System will allow the Applicant to explore additional services available through the Health Benefits Exchange. Authorized Representatives and Workers can also complete an application on behalf of Applicants that cannot, or do not want to, complete the application without assistance (see Complete Self-Service Integrated Application on Behalf of Another use case). For complex situations involving public safety issues, child welfare, domestic violence or other conditions, Applicants may be required to work with State or local resources. If the Solution identifies that the client is within one of these groups, the Solution shall instruct the Applicant to contact the appropriate channel. The application will only require enough information to make an eligibility determination and allow the Applicant to choose specific programs to apply for. It will guide the Applicant through the full menu of programs that they may be eligible for based on the information provided, including those managed by the Health Benefits Exchange, if applicable. Accounts in the System can recall the history of an Applicant so that Applicants are not required to enter information that they have entered in the past. The System recalls information, pre-populates information, notes where changes have occurred and allows the Applicant to update any information before proceeding. When the eligibility criteria for programs vary, an Applicant s eligibility for each program may occur independently. For example, the System may approve an application for Medicaid immediately, but require additional information before a determination is made on a Department of Disabilities, Aging and Independent Living (DAIL) program. For an Applicant, this may result in multiple notifications of eligibility for each program. In this use case, the Applicant fills out a complete integrated eligibility application online and receives eligibility determination whenever possible. Trigger Events The Applicant would like to apply for State programs Pre-Condition The Applicant has Internet access

85 85 Post-Condition The Applicant receives eligibility determination for State programs, including coverage managed by the Health Benefits Exchange The Applicant is enrolled in State programs The Applicant is directed to additional actions that cannot be completed in the integrated eligibility application and explanation and instructions are provided The Applicant is determined not eligible for benefits Use Case Flow 1. The Applicant navigates to the self-service Web portal and logs in a. If the Applicant has already created an account the Applicant enters their credentials to log in b. If the Applicant has already created an account but had forgotten their login credentials the System will display options to recover their credentials c. If the Applicant has not yet created an account the System allows the Applicant to create a new account (see Create Client Account use case) 2. The Applicant selects the Integrated Eligibility Application 3. The Applicant opts to start a new application and indicates that they are applying for themselves 4. If available, the System asks the Applicant if they would like to import information from information recorded in the system 5. The Applicant selects their choice and submits the form 6. The System displays a step-by-step form with branching logic requesting required and optional data elements about themselves a. Required / optional data elements include, but are not limited to: i. Demographics 1. Race 2. Ethnicity 3. Citizenship 4. Gender 5. Age / date of birth 6. Primary language ii. Address and state residency iii. Type of assistance requested (optional; defaults to All Programs ) 1. All programs 2. Specific programs

86 86 3. Specific categories or groups of programs 4. Include sub-programs iv. Programs currently enrolled v. Other creditable coverage vi. Financial information vii. Assets 1. Employment status a. The System embraces a methodology that will gather the employer s data to use in verifying employment data. 2. Income (entered or computed) 3. Expenses a. Housing / shelter expenses b. Dependents viii. Household Composition 1. Living arrangement a. Independent / self-sufficient b. Institution c. Group home d. Nursing home 2. Dependents (relationships and/or custody status) ix. Health status 1. Pregnancy 2. Disabilities 3. Physical and cognitive functional needs b. Information is pre-populated from previous applications if the Applicant has chosen this option c. The System displays a progress indicator based on expected information needs for the application 7. The Applicant enters the requested, required and optional information and submits the form a. If an Applicant is unable to complete the form, he / she may allow access to others (e.g. an eligibility worker to assist in completion of the form) b. If the Applicant chooses, they may save the incomplete draft form at any time 8. The System validates the information provided by the Applicant and calculates preliminary eligibility determination based on information entered a. The System will validate information based on at least:

87 87 i. Required field completion ii. Field content types (e.g. names must not contain numbers) iii. Acceptable values (e.g. no birth dates before 1/1/1900) iv. Values based on available real-time and stored data sources (e.g. IRS tax returns from the previous year, vital statistics queries, Bureau of Motor Vehicles, Social Security Administration, Federal Hub etc.) 1. Sources and validation rules will be determined by the eligibility workgroup grid b. If the System determines that documentation is required for determination the System displays capabilities to attach electronic documentation (where appropriate) or provides mailing and drop-off locations for the documents i. The System shall have a bulleted list of documentation requested and the current disposition of those documents c. If program eligibility rules determine that eligibility worker involvement is required (e.g. child custody or welfare, domestic violence, public safety, etc.), the System will save the application and notify the Applicant and Eligibility Worker that the Applicant may be required to work with State or local resources. If the System identifies that the client is within one of these groups, the Solution shall instruct the Applicant to contact the appropriate channel. i. Notification may or may not include a reason, as defined by policy d. If the System is unable to validate the information provided by the Applicant, the System displays required actions. These actions may include: i. Documentation needed, such as proof of identity ii. Processing and/or approval by an eligibility worker iii. An alert generated by the system to notify Coordination of Benefits (COB) that the information needs to be verified. 1. For example, once the Benefit Program Specialist (BPS) reviews the application that the beneficiary has entered and submitted into the system, if there is any other health insurance noted by the beneficiary, an alert would be sent to COB. If this is a review application then an alert should be generated if anything is changed in regards to other health insurance. e. If this application has been flagged prior to determination, the System will require approval by worker. f. The System generates a printed Verification Request Notice that will be sent to the Applicant via a communication channel of their choosing (defaulting to paper mail) i. Verification Requests will contain pre-populated information and will contain information, codes and marking that will minimize manual processing of printing, folding, stuffing, sending, scanning, indexing and processing ii. The system directs Verification Request Notices to eligibility workers prior to sending so that they may attach additional forms to the Request

88 88 1. Eligibility workers are able to fill in some fields and add free-form text. 2. Attachments are prepopulated other information (e.g. applicant's name, case number, etc.) 3. Attachments are printed with codes, information etc, to minimize manual processing and indexing 9. If possible, the System presents the determinations to the Applicant with options to accept or reject enrollment to programs a. If appropriate, both State public assistance programs / benefits and options managed by the Health Benefits Exchange are displayed as options b. If the System is able to determine that the Applicant is eligible for programs and no additional information is needed the System displays the determination i. If the program has elected to distribute a welcome packet or ID cards the System informs the Applicant that these will be mailed to the Applicant. c. If additional steps are required to complete eligibility determination the System displays these required actions. These actions may include: i. In-person interviews / assessments required ii. Documentation needed that has not been submitted yet iii. Approval by an eligibility worker or contractor d. If the Applicant is placed on a waitlist, the System notifies the Applicant of such and discusses the next steps and possible outcomes from being on the waitlist e. In all cases, the System displays appeal rights f. In all cases the System displays alternatives or supplemental resources to the included programs, including, but not limited to: i. Other State programs ii. Other non-state programs that can assist the Applicant g. The System offers a printable version of the information presented h. The System sends an to confirm receipt of the application with a link to the completed application i. If the Applicant chooses, they may save the incomplete draft form at any time 10. The Applicant selects the approved programs (and those pending approval) they wish to enroll in (or to continue the process) and submits the form Associations with Other Use Cases Complete Self-Service Anonymous Screening View Status of Application Submit Additional Information for Application Process Application

89 89 View Client Information View Alerts / Notifications Appeal Decision Alternate Flows If an Applicant requires help or chooses not to complete the application themselves, see the Complete Self-Service Integrated Application On Behalf Of Another use case If an application remains in "draft" state for a predefined time period, send a message to the Applicant using or SMS based on their preferred method of communication Additional Requirements The System shall allow the Applicant to restart the process and enter a new set of information at any time prior to final submission of the application The System shall allow the Applicant to delete all entered information and exit at any time prior to final submission of the application The System shall allow the Applicant to save the application and exit at any time before final submission without formal application to any program The System shall allow the Applicant to resume saved applications from the most advanced location of the application The System shall allow the Applicant to see a list of, and review, past applications The System shall allow the Applicant to give access to their draft or completed applications to an Authorized Representative The System shall allow eligibility workers to access draft or completed applications without consent as needed in accordance with their roles The System shall prevent creation of duplicate accounts The System shall notify the applicant of a specified period (from submission) to present documentation for the resolution of inconsistencies or erroneous information. The System shall archive or remove applications in draft, approved or denied status in accordance with record retention and other state policies The System shall allow the client to send results to his/her account or print them, The System shall exchange data with other systems to verify eligibility (or ineligibility) and determining if an exemption applies (e.g. incarceration, citizenship, validating identity, confirming enrollment in other programs) In all cases, the System shall maintain reason of eligibility determination such as: The reason that individuals determined eligible but not enrolled in the program and/or service The reason that individuals are disenrolled The reason that individual is ineligible

90 90 A historic view of eligibility segments with start and stop dates, program, category code, and reason for segment end. The System shall accept electronic signature and telephonic signature at the appropriate points in the application process such as recording consent and application submission (if electronic signature and telephonic signature is accepted under State of Vermont policy) The System shall provide a red flag alerting the Worker that there is a Domestic Violence flag on the case, alerting the Worker to provide specific instructions on using electronic accounts and provide necessary information to help them establish and safely use an electronic account The System shall identify if an application is coming from a rush status group and those applications shall always be treated as rush applications The System shall prioritize an online application from one of the designated groups automatically send the application to the front of the worker queue The System shall be able to conditionally approve enrollment in programs requiring initial premium payments, and conform to the State's premium collection rules The System shall recognize the payment of initial premiums (as well as on-line payment of subsequent payments due), and complete enrollment process accordingly The System shall allow intermediate eligibility determinations to be made during the application process to preclude entering additional information when the Client is known not to be eligible The System must permit applicants, representatives, and workers to designate multiple documentation recipients. The System will allow the Applicant, Authorized Representative, or Eligibility Worker to define document types to be sent to secondary recipients The System shall provide offline capabilities to enter application information that can be transferred to System The System shall allow intermediate eligibility determinations to be made during the application process to preclude entering additional information when the Client is known not to be eligible The System shall allow for consolidated notices, requests for verification, and both types for individuals and households The System shall reject identical applications submitted within a configurable time frame The System shall flag applications from the same Applicant / household for the same program that differ from previous applications within a configurable time frame for manual review The system shall, on budget notices, include an explanation of how eligibility/benefits were calculated for each household member (health care) or household (other programs)

91 UC-3: Complete Self-Service Integrated Application on Behalf of Another Actors The Authorized Representative is a person who has the ability and rights to apply for benefits on behalf of another person such as a parent, child, ward or other individual unable to represent himself. A navigator is included as an Authorized Representative for enrollment activities. An Authorized Representative may, be able to sign documents on behalf of the other person, or not, depending on the specific role and rights granted to that person. Applicant The Applicant role can be fulfilled by a client, a caretaker of a client, a System User, or any person that would like to apply for benefits from the State of Vermont. The person for whom the Authorized Representative is applying for benefits on behalf of. Eligibility Worker The Eligibility Worker is an authorized State or contractor employee who may process an application, assist a client with applying, or apply for benefits on behalf of a client as part of their position. Purpose and Objectives If an applicant is unable to, or chooses not to, complete a self-service integrated eligibility application, he / she may choose to have another person complete the application for them. This person may be a caretaker, parent, authorized representative or eligibility worker. The process is similar to the Complete Self-Service Integrated Application use case except that the System differentiates the roles of the caretaker and the applicant. In accordance with policy, where appropriate, the required documentation must be on file for a person to act as an Authorized Representative. In this use case, the Authorized Representative fills out a complete integrated eligibility application online on behalf of an Applicant and receives eligibility determination if possible for public assistance programs and Exchange options. Trigger Events The Authorized Representative has been asked to apply for State programs on behalf of an Applicant Pre-Condition The Authorized Representative has Internet access Post-Condition The Authorized Representative and/or the Applicant receives eligibility determination for State programs for the Applicant and Exchange options The Applicant is enrolled in State programs The Authorized Representative is directed to additional actions that cannot be completed in the integrated eligibility application and explanation and instructions are provided

92 92 The Authorized Representative is informed that the Applicant is determined ineligible for benefits Use Case Flow 1. The Authorized Representative navigates to the self-service Web portal and logs in a. If the Authorized Representative has already created a self-service Web portal account in the System the Authorized Representative enters their credentials to log in b. If the Authorized Representative has already created a self-service Web portal account in the System but had forgotten their login credentials the System will display options to recover their credentials c. If the Authorized Representative has not yet created a self-service Web portal account, the System allows the Authorized Representative to create a new account (see Create Client Account use case) 2. The Authorized Representative selects the integrated eligibility application tool 3. The Authorized Representative opts to start a new application and indicates that they are applying on behalf of another person a. If the Applicant has identified the Authorized Representative as such the System allows the Authorized Representative to select the Applicant from a list b. If the Applicant has not identified the Authorized Representative as such the System allows the Authorized Representative to associate their account with the Applicant s account i. A notification is sent to the Applicant if their contact information is known to the System 4. If available, the System asks the Authorized Representative if they would like to import information from previous applications 5. The Authorized Representative selects their choice and submits the form 6. The System displays a step-by-step form with branching logic requesting required and optional data elements about themselves a. Data elements include, but are not limited to: i. Authorized Representative s relationship to Applicant ii. Authorized Representative s contact information such as phone, , address iii. Applicant demographics 1. Race 2. Ethnicity 3. Citizenship 4. Gender 5. Age / date of birth

93 93 6. Primary language iv. Applicant address and state residency v. Type of assistance requested (optional; defaults to All Programs ) 1. All programs 2. Specific programs 3. Specific categories or groups of programs 4. Include sub-programs vi. Programs currently enrolled vii. Other creditable coverage viii. Applicant financial information 1. Employment status a. The System embraces a methodology that will gather the employer s data to use in verifying employment data. 2. Income (entered or computed) 3. Expenses ix. Applicant assets a. Housing / shelter expenses b. Dependents x. Applicant household composition 1. Living arrangement a. Independent / self-sufficient b. Institution c. Group Home d. Nursing Home e. Death (start and end date) 2. Dependents (relationships and/or custody status) xi. Applicant health status 1. Pregnancy 2. Disabilities 3. Physical and cognitive functional needs b. Information is pre-populated from information recorded in the system if the Authorized Representative has chosen this option c. The System displays a progress indicator based on expected information needs for the application 7. The Authorized Representative enters the requested required and optional information and submits the form

94 94 a. If the Authorized Representative chooses, they may save the incomplete draft form at any time 8. The System validates the information provided by the Authorized Representative and calculates preliminary eligibility determination based on information entered a. The System will validate information based on at least: i. Required field completion ii. Field content types (e.g. names must not contain numbers) iii. Acceptable values (e.g. no birth dates before 1/1/1900) iv. Values based on available real-time and stored data sources (e.g. IRS tax returns from the previous year, vital statistics queries, Bureau of Motor Vehicles, Social Security Administration, Federal Hub, etc.) 1. Sources and validation rules will be determined by the eligibility workgroup grid b. If program eligibility rules determine that eligibility worker involvement is required (e.g. child custody or welfare, domestic violence, public safety, etc.), the System will notify the applicant of such i. Notification may or may not include a reason, as defined by policy c. If the System is unable to validate the information provided by the Authorized Representative, the System displays required actions. These actions may include: i. Documentation request prior to determination (e.g. proof of identity submission) ii. Processing and/or approval by an eligibility worker d. If the System determines that additional information is needed to determine eligibility that can be entered on the online form, repeat steps If the System determines that documentation is required for determination the System displays capabilities to attach electronic documentation (where appropriate) or provides mailing and drop-off locations for the documents. The System presents the determinations to the Authorized Representative with options to accept or reject enrollment to programs on behalf of the Applicant a. If the System is able to determine that the Applicant is eligible for programs and no additional information is needed the System displays the determination i. Both State public assistance programs / benefits and options managed by the Exchange are displayed as options ii. If the program has elected to distribute a welcome packet or ID cards the System informs the Applicant that these will be mailed to the Applicant b. If additional steps are required to complete eligibility determination the System displays these required actions. i. These actions may include: 1. In-person interview / assessments required 2. Documentation needed that has not been submitted yet

95 95 a. The System shall generate a Verification Request Notice that will be sent to the Applicant via a communication channel of their choosing (defaulting to paper mail) i. Verification Requests will contain pre-populated information and will contain information, codes and marking that will minimize manual processing of printing, folding, stuffing, sending, scanning, indexing and processing ii. The system directs Verification Request Notices to eligibility workers prior to sending so that they may attach additional forms to the Request 3. Approval by an eligibility worker c. In all cases, the System displays Appeal Rights 1. Eligibility workers are able to fill in some fields and add free-form text. 2. Attachments are prepopulated other information (e.g. applicant's name, case number, etc.) 3. Attachments are printed with codes, information etc, to minimize manual processing and indexing d. In all cases the System displays alternatives or supplemental resources to the included programs, including, but not limited to: i. Other State programs ii. Other non-state programs that may assist the Applicant e. The System offers a printable version of the information presented f. If the Authorized Representative chooses, the System sends an to confirm receipt of the application with a link to the completed application g. If the Authorized Representative chooses, they may save the incomplete draft form at any time 10. The Authorized Representative selects the approved programs (and those pending approval) they wish to enroll in (or to continue the process) and submits the form Associations with Other Use Cases Complete Self-Service Anonymous Screening Complete Self-Service Integrated Application View Status of Application Submit Additional Information for Application Process Application View Client Information View Alerts / Notifications

96 96 Appeal Decision Alternate Flows If the Applicant chooses to complete the application themselves, see the Complete Self- Service Integrated Application use case If an application remains in "draft" state for a predefined time period, send a message to the Authorized Representative using or SMS based on their preferred method of communication Additional Requirements The System shall allow the Applicant, a Worker, or the Authorized Representative to deauthorize the Authorized Representative from viewing and acting on behalf of the Applicant, when the Authorized Representative is not a legal guardian, under specified conditions such as: At the request of either party At a specified date / time At changes in program / service status (e.g. when an Applicant is released from prison or when eligibility for a program ends) As a result of suspicious or fraudulent behavior The System shall notify both parties of authorization or de-authorization of an Authorized Representative to act on behalf of an Applicant The System shall allow the Authorized Representative to restart the process and enter a new set of information at any time before final submission The System shall allow the Authorized Representative to delete all entered information and exit prior to final submission of the application The System shall allow the Authorized Representative to save the application and exit at any time before final submission without formal application to any program The System shall allow the Authorized Representative to resume saved applications from the most advanced location of the application The System shall allow the Authorized Representative to see a list of, and review, past applications The System will only allow previous applications to be viewed and used to pre-populate new applications facilitated by Authorized Representatives when appropriate, as defined by Vermont policy The System shall allow eligibility workers to access draft or completed applications without consent as needed in accordance with their roles The System shall close draft applications after a predefined time period The System shall notify the applicant of a specified period (from submission) to present documentation for the resolution of inconsistencies or erroneous information

97 97 The System shall archive or remove applications in draft, approved or denied status in accordance with record retention and other state policies The System shall allow the client to send results to his/her account or print them The System shall provide a red flag alerting the Worker that there is a Domestic Violence flag on the case, alerting the Worker to provide specific instructions on using electronic accounts and provide necessary information to help them establish and safely use an electronic account In all cases, the System shall maintain reason of eligibility determination such as: The reason that individuals determined eligible but not enrolled in the program and/or service The reason that individuals are disenrolled The reason that individual is ineligible A historic view of eligibility segments with start and stop dates, program, category code, and reason for segment end. The System shall accept electronic signature and telephonic signature at the appropriate points in the application process such as recording consent and application submission (if electronic signature and telephonic signature is accepted under State of Vermont policy) The System must allow for multiple copies of notifications, to be mailed or transmitted to multiple individuals, in accordance with state rules. The system should, on budget notices, include an explanation of how eligibility/benefits were calculated for each household member. The System shall allow for consolidated notices, requests for verification, and both types for individuals and households The System must permit applicants, representatives, and workers to designate multiple documentation recipients. The System will allow the Applicant, Authorized Representative, or Eligibility Worker to define document types to be sent to secondary recipients The System shall provide offline capabilities to enter application information that can be transferred to System The System shall allow intermediate eligibility determinations to be made during the application process to preclude entering additional information when the Client is known not to be eligible The System shall reject identical applications submitted within a configurable time frame The System shall flag applications from the same Applicant / household for the same program that differ from previous applications within a configurable time frame for manual review

98 UC-4: Complete Re-Determination of Eligibility Actors Applicant The Applicant role can be fulfilled by a client, an authorized representative such as a caretaker of a client, a System User, or any person that can apply for redetermination on behalf of the client from the State of Vermont. Worker The Worker is an employee of a department and/or agency in Vermont or of a contracted entity who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this System, as well as any contractor. Purpose and Objectives Eligibility for programs and services must periodically be re-determined. For those programs that require client actions, the System can provide forms to allow the client to update information and submit their re-determination request. The re-determination process for Medicaid is different than the process that applies for QHPrelated benefits. In Medicaid, the system attempts to automatically re-determine eligibility based only on available information in the system and data matching. A review notice is only sent if there is incompatibility or an inability to verify. For QHP benefits, a review notice is sent near the end of the enrollment period. The system will attempt automatic re-determination if the individual does not respond to the review notice. In these cases, the system must attempt to re-determine eligibility based on available information. In this use case, the Applicant responds to a review notice, and fills out a re-determination request form online and receives re-determination whenever possible. Trigger Events The Applicant would like to be re-determined for State programs A Worker would like to enter information for a passive renewal A Worker would like to enter level of care re-determination results Pre-Condition The Applicant has Internet access Post-Condition The Applicant receives eligibility re-determination for State programs The Applicant is enrolled in State programs The Applicant is directed to additional actions that cannot be completed in the integrated eligibility application The Applicant does not qualify for benefits

99 99 Use Case Flow 1. The Applicant navigates to the self-service Web portal and logs in a. If the Applicant has already created a self-service Web portal account the Applicant enters their credentials to log in b. If the Applicant has already created a self-service Web portal account but had forgotten their login credentials the System will display options to recover their credentials c. If the Applicant has not yet created a self-service Web portal account the System allows the Client to create a new account (see Create Client Account use case) 2. The Applicant selects the Integrated Eligibility Application Tool 3. The Applicant opts to submit a re-determination request and indicates that they are applying for themselves 4. If available, the System asks the Applicant if they would like to import information from previous applications 5. The System asks the Applicant to validate information previously submitted as part of the application process and to confirm that there have been no changes. The System asks the Applicant to report any changes in any of the following a. Data elements include, but are not limited to: i. Demographics 1. Race 2. Ethnicity 3. Citizenship 4. Gender 5. Age / date of birth 6. Primary language ii. Address and state residency iii. Type of assistance requested (optional) 1. All programs 2. Specific programs 3. Specific categories or groups of programs 4. Include sub-programs iv. Programs currently enrolled v. Other creditable coverage vi. Financial information 1. Employment status

100 100 vii. Assets a. The System embraces a methodology that will gather the employer s data to use in verifying employment data. 2. Income (entered or computed) 3. Expenses a. Housing / shelter expenses b. Dependents viii. Household Composition 1. Living arrangement a. Independent / self-sufficient b. Institution c. Group Home d. Nursing Home 1. Dependents (relationships and/or custody status) ix. Health status 1. Pregnancy 2. Disabilities b. Information is pre-populated from information recorded in the system if the Applicant has chosen this option in accordance with 45 CFR (c) c. The System displays a progress indicator based on expected information needs for the application 6. The Applicant enters the requested required and optional information and submits the form a. If an Applicant is unable to complete the form, he / she may allow access to an Authorized Representative or work with an eligibility worker to assist in completion of the form b. If the Applicant chooses, they may save the incomplete draft form at any time 7. The System validates the information and calculates preliminary eligibility redetermination based on information entered a. The System will validate information based on at least: i. Required field completion ii. Field content types (e.g. names must not contain numbers) iii. Acceptable values (e.g. no birth dates before 1/1/1900) iv. Values based on available real-time and stored data sources (e.g. IRS tax returns from the previous year, vital statistics queries, Bureau of Motor Vehicles, Social Security Administration, Federal Hub etc.) 1. Validations will be coordinated with those that have already been completed for the Applicant

101 101 b. If the System determines that additional information is needed to re-determine eligibility that can be entered on the online form, repeat steps 6-8 c. If the System determines that documentation is required for re-determination the System displays capabilities to attach electronic documentation (where appropriate) or provides mailing and drop-off locations for the documents 8. The System presents the re-determinations to the Applicant with options to accept or reject enrollment to programs a. If the System is able to determine that the client is eligible for programs and no additional information is needed the System displays the determination i. If needed and if the program has elected to distribute a welcome packet or ID cards the System informs the Applicant that these will be mailed to the client b. If additional steps are required to complete eligibility re-determination the System displays these required actions. These actions may include: i. In-person interviews / assessments required ii. Documentation needed that has not been submitted yet 1. The System shall generate a Verification Request Notice that will be sent to the Applicant via a communication channel of their choosing (defaulting to paper mail) a. Verification Requests will contain pre-populated information and will contain information, codes and marking that will minimize manual processing of printing, folding, stuffing, sending, scanning, indexing and processing iii. Approval by an eligibility worker c. In all cases, the System displays appeal rights i. The system directs Verification Request Notices to eligibility workers prior to sending so that they may attach additional forms to the Request 1. Eligibility workers are able to fill in some fields and add free-form text. 2. Attachments are prepopulated other information (e.g. applicant's name, case number, etc.) 3. Attachments are printed with codes, information etc, to minimize manual processing and indexing d. In all cases the System displays alternatives or supplemental resources to the included programs, including, but not limited to: i. Other State programs that are not included in the determination ii. Other non-state programs that assist the Applicant e. The System offers a printable version of the information presented

102 102 f. The System sends an to confirm receipt of the re-determination application with a link to the updated application g. If the Applicant chooses, they may save the incomplete draft form at any time 9. The Applicant selects the re-determined programs (and those pending approval) they wish to enroll in (or to continue the process) and submits the form Associations with Other Use Cases View Status of Application Submit Additional Information for Application Process Application View Client Information View Alerts / Notifications Appeal Decision Alternate Flows Allow the Applicant or appropriate individual to update information for passive renewals e.g. Worker may indicate the Applicant s health status continues to meet eligibility criteria based on periodic assessments Allow the Applicant or appropriate individual to provide updated information regarding level of care for review by an eligibility worker Additional Requirements The System shall allow the Applicant to restart the process and enter a new set of information at any time prior to final submission of the re-determination application The System shall allow the Applicant to delete all entered information and exit at any time prior to final submission of the application The System shall allow the Applicant to save the application and exit at any time before final submission without a formal re-determination request to any program The System shall allow the Applicant to resume saved re-determination requests from the most advanced location of the re-determination request The System shall allow the Applicant to see a list of, and review, past applications and / or re-determination requests The System shall allow the Applicant to give access to their draft or completed redetermination request to an Authorized Representative with access to the System. The System shall allow eligibility workers to access draft or completed applications without consent as needed in accordance with their roles The System shall close draft applications after a predefined time period The System shall notify the applicant of a specified period (from submission) to present documentation for the resolution of inconsistencies or erroneous information

103 103 The System shall archive or remove applications in draft, approved or denied status in accordance with record retention and other state policies The System shall provide an alert to the Worker that there is known domestic violence related to the case, alerting the Worker to provide specific instructions on using electronic accounts and provide necessary information to help them establish and safely use an electronic account In all cases, the System shall maintain reason of eligibility determination such as: The reason that individuals determined eligible but not enrolled in the program and/or service The reason that individuals are disenrolled The reason that individual is ineligible A historic view of eligibility segments with start and stop dates, program, category code, and reason for segment end. The System shall accept electronic and telephonic signature at the appropriate points in the application process such as recording consent and application submission (if electronic and telephonic signature is accepted under State of Vermont policy) The System must permit applicants, representatives, and workers to designate multiple documentation recipients. The System will allow the Applicant, Authorized Representative, or Eligibility Worker to define document types to be sent to secondary recipients The System shall provide offline capabilities to enter application information that can be transferred to System The System shall allow intermediate eligibility determinations to be made during the application process to preclude entering additional information when the Client is known not to be eligible The system should, on budget notices, include an explanation of how eligibility/benefits were calculated for each household member. The System shall allow for consolidated notices, requests for verification, and both types for individuals and households The System shall reject identical applications submitted within a configurable time frame The System shall flag applications from the same Applicant / household for the same program that differ from previous applications within a configurable time frame for manual review

104 UC-5: View Status of Application Actors Applicant The Applicant is a client that wishes to apply for services for themselves and/or their family. The Applicant role can be fulfilled by a client, a caretaker of a client, a Worker, or any person that have the appropriate rights to access the Applicant s account. Worker The Worker is an employee of a department and/or agency in Vermont or of a contractor who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this Solution, as well as any contractor. The definition of Worker covers all State employees that have the rights to perform the described actions for this Solution, as well as any contractor. Purpose and Objectives When a client submits an application, optimally they will receive immediate notification of whether or not they are eligible. However, in some cases eligibility determination may not be available immediately due to additional required information, an interview / assessment requirement, system delays or worker approval, the client needs to be able to check the status of their application through the self-service portal or have a Worker check the status on their behalf. In this use case, the Applicant or Worker accesses the System to check the status of an application and the Worker has access to the Web portal and the appropriate rights to perform the action described. Trigger Events Applicant or Worker chooses to check the application status Pre-Condition The Applicant / Worker has Internet access The Applicant has submitted an application Post-Condition The Applicant is notified of the status of his / her application Use Case Flow 1. The Applicant or Worker logs into the System a. If the actor is a Worker, the Worker searches for and selects the relevant client record and views the list of open applications (see Search for Client use case and View Client Information use case)

105 105 b. If the actor is a Client, the System recognizes the Client s account and displays only information appropriate to that Client 2. The Applicant or Worker selects the application to view 3. The Applicant or Worker views the status for the application including: a. Information related to Appeals and Grievances b. Verification Request Notices outstanding 4. If the application status is approved, see View Client Information use case to see details regarding the benefits Associations with Other Use Cases Search for Client View Client Information Appeal Decision Alternative Flows None Additional Requirements None

106 UC-6: Submit Additional Information for Application Actors Applicant The Applicant role can be fulfilled by a client, an authorized representative (a caretaker of a client), a System User, or any person that would like to apply for benefits from the State of Vermont. The person for whom the Authorized Representative is applying for benefits on behalf of. Eligibility Worker The Eligibility Worker is an authorized State or contractor employee who may process an application, assist a client with applying, or apply for benefits on behalf of a client as part of their position. ADPC Worker (Application and Document Processing Center) The ADPC works with paper and electronic documents and indexes by case and document type. Purpose and Objectives One of the core components of the System is the ability to determine eligibility across a range of programs without the need to apply for each program individually. This can be accomplished through an online application that the Applicant can complete from any computer with Internet access. During the application process, the System may request additional information in order to make a determination of benefits eligibility based on programmatic rules or Worker input. This additional information may be submitted electronically via the self-service portal, , scanned fax or in hardcopy via an in-person visit, postal mail or fax. Examples of additional information may include a copy of the Client s most recent paycheck stub, bank statements cataloging assets and expenses, verification of a medical diagnosis, proof of citizenship, etc. In this use case, the Applicant or Eligibility Worker submits the additional information requested and the application is re-submitted for processing. Trigger Events The System requests additional information after processing an application The Eligibility Worker requests additional information after processing an application Pre-Condition The Applicant has an application in process The application requires additional information Post-Condition Applicant or Eligibility Worker enters the information in the system and the System continues to process the eligibility request

107 107 Use Case Flow 1. The Applicant locates the additional information requested in order to complete eligibility determination 2. The Applicant determines which method they will use to submit the additional information a. If the additional information is available in soft copy, it may be submitted via the Web portal. Go to step 3 b. If the additional information is only available in hard copy, it must be submitted via fax, postal mail or in-person. Go to step 4 3. The Applicant or Eligibility Worker logs on to the System and accesses the application a. The System presents a form for the Applicant to upload multiple attachments and/or enter the additional information or comments in a free text box b. The System associates all attachments with the client record and provides confirmation after saving the additional information successfully c. The System provides the Applicant with an opportunity to review and edit the application prior to submitting for processing d. Go to step 7 4. The Client or Eligibility Worker submits the additional information via fax, postal mail or in-person 5. The State receives the information a. If sent via a channel managed by the ADPC, the ADPC Worker receives the documents, scans the document (if necessary) i. The System enables the ADPC Worker to scan or process multiple documents and/or enter the additional information ii. The ADPC Worker searches for the Applicant in the System iii. The System associates all attachments with the Applicant/application iv. The System enables the ADPC Worker to perform additional actions to prepare the document for processing (e.g. identifies the document type), v. The System provides the ADPC Worker with an opportunity to review and edit the application prior to submitting for processing vi. The System notifies the appropriate Eligibility Worker that additional documents are ready for review for this application b. If sent or given to an Eligibility Worker, the Eligibility Worker accesses the System, searches for the Applicant record and selects the in-process application i. The System presents a form enabling the Eligibility Worker to upload multiple attachments and/or enter the additional information or comments ii. The System associates all attachments with the Applicant and provides confirmation after saving the additional information successfully iii. The System provides the Eligibility Worker with an opportunity to review and edit the application prior to submitting for processing

108 The Eligibility Worker submits the application for determination a. Go to Complete Self-Service Integrated Application or Complete Self- Service Integrated Application on Behalf of Another use cases, as appropriate, to complete the application process Associations with Other Use Cases Complete Self-Service Integrated Application Complete Self-Service Integrated Application on Behalf of Another Alternative Flows If additional information is not provided after a configurable amount of time, the application is closed by the System. The System sends a notification to the client detailing this change in status and the reason. Additional Requirements The System shall require that attachments uploaded to the Web portal be of an acceptable file type. File types will be determined by system design The System shall send notifications based on the preference indicated in Applicant profile The System shall enable delivery methods that may include , SMS, postal mail or others Due to the expense of postal mail, the System shall promote the use of electronic delivery methods where possible and appropriate The System shall allow an Eligibility to make electronic notes on documents associated with an application or case

109 UC-7: Process Application Actors Eligibility Worker The Eligibility Worker is an authorized State or contractor employee who may apply for benefits or process applications for a client as a course of business. Applicant The Applicant is a client that wishes to apply for services for themselves and/or their family. The person for whom the Authorized Representative is applying for benefits on behalf of. Purpose and Objectives Worker involvement is needed in the application process when documentation needs to be submitted and / or reviewed by the program, an assessment is needed, or for any other reason as determined by the State. In this use case, the Eligibility Worker processes an application that requires his/her involvement. Trigger Events The Eligibility Worker is notified by the System that an application needs Eligibility Worker involvement The Eligibility Worker receives documents that need to be associated with an open application An Applicant contacts an AHS office and requests help from Eligibility Worker Pre-Condition None Post-Condition The Eligibility Worker advances the process of the application Use Case Flow 1. The Eligibility Worker logs into the System 2. The System presents to the Eligibility Worker the application that is assigned for the user involvement based on caseload management routing (see Manage Caseload use case); a. Optionally, the Eligibility Worker receives a document that supports an application i. In this case, the Eligibility Worker scans the document and it is automatically associated with an application or case b. Optionally, the Eligibility Worker assists the Applicant that walks-in to the AHS office requesting help 3. The System displays actions required to process the application

110 The Eligibility Worker chooses an action necessary to process the application 5. The Eligibility Worker updates the application with information available to them 6. If the System determines that additional actions are still necessary repeat steps If this application has been flagged prior determination, the System will require approval by the Eligibility Worker. 8. Optionally, the Worker may exercise fiat to change a determination. A mandatory reason will be required with this change. 9. Optionally, the Worker may 'freeze' an eligibility determination to prevent automated System determination changes for an inputted period of time 10. Optionally, the Worker may put a case or application in 'hold' status for an inputted period of time 11. If no additional actions are necessary by the Eligibility Worker the System continues to process the application 12. See use case Complete Self-Service Integrated Application on Behalf of Another to obtain eligibility determination Associations with Other Use Cases Submit Additional Information for Application Manage Caseload Alternate Flows None Additional Requirements In all cases, the System shall maintain reason of eligibility determination such as: The reason that individuals determined eligible but not enrolled in the program and/or service The reason that individuals are disenrolled The reason that individual is ineligible A historic view of eligibility segments with start and stop dates, program, category code, and reason for segment end. The System shall allow staff to associate individual members by relationships into flexible groupings, by program. For instance, the System shall allow the application of state defined program rules that are easily modified to establish a "household". Thus, the System could define a "household" as broadly connected, not necessary members of the family living under the same roof The System shall enable a repository of financial institutions managed by the Eligibility Worker including fields such as bank name, address, phone number and key contacts

111 111 The System shall allow Eligibility Worker to search the financial institution repository by filters such as zip code, region and others from the client s application view The System shall enable, from the client s application view, generation of automated Verification Requests for selected financial institutions pre-populated with the client s information and appropriately marked for sending by the State s document processing center The System shall provide a method to easily add, update and archive financial institutions and associated information by the Eligibility Worker The System shall allow the Eligibility Worker to identify the source of any information they can see Optionally, the Worker may 'freeze' an eligibility determination for groups of clients of applicants to prevent automated System determination changes for an inputted period of time The System shall allow an Eligibility to make electronic notes on documents associated with an application or case

112 UC-8: Update Client Changes Actors Client The Client is a client or authorized representative of a client that is a recipient of benefits from the State and/or its contractors. Worker The Worker is an employee of a department and/or agency in Vermont or of a contractor who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this Solution, as well as any contractor. Purpose and Objectives Throughout the course of service delivery, there are many events that may change a client s eligibility for programs. These events vary from changes in the Client s household composition or income level to inactivity for a prolonged time period. When these events occur, the status of the eligibility must be updated in order to, among others: Provide clients with the right services Contain program costs Maintain the integrity of the program Prevent fraud and abuse In this use case, the Worker updates the Client s eligibility based on specific events. Trigger Events Client is inactive in a program for a specified number of days (e.g. Waiver enrollment is jeopardized after a period of inactivity). A Client s waiver status may be inactive while he receives institutional care in a hospital, nursing facility, correctional facility, etc. Assessment is required by a worker and a determination is then made regarding continued enrollment. Client becomes categorically ineligible Immediate termination with reason Transfer to or addition of another program / service Client demographic information changes Household composition changes Income changes Coverage funding expires or requires re-determination Other changes Pre-Condition The Client is enrolled in one or more programs

113 113 The Client has established an Web portal account Post-Condition The Client s eligibility is updated The Client is informed of next steps to continue receiving benefits Use Case Flow 1. If the Client is inactive for a specified time period, the System changes the status to inactive a. The system sends a notification to the Client indicating the status has been changed to inactive. The notification includes information such as, but not limited to: i. Program name ii. Inactivity / expiration date iii. Reason for status change iv. Program contact information v. Next steps to re-instate benefits (if possible) b. The Client logs into the system or contacts the Worker in accordance with the directions in the notification i. If the Client accesses the system with their login credentials: 1. The System prompts the Client to validate their contact information 2. The System changes the status to Active ii. If the Client contacts a Worker: 1. The Worker validates their contact information 2. The Worker changes the status to Active 2. If the Client becomes categorically ineligible (e.g. no longer meets age requirement) or there is a reason for the immediate termination of the benefits (e.g. program abuse), a Program Administrator changes the status to terminated with reason a. The Worker logs in and searches for the client record. See Search for Client use case for more details b. The Worker opens the client record, changes the status for the specified program to terminated with reason and enters an effective date for the status change c. The Worker saves the client record d. The System generates a notice of termination to the Client. The notification includes information such as, but not limited to: i. Program ii. Reason for status change

114 114 iii. Effective date of termination 3. If the Client wishes to transfer to another program, go to the Complete Application On Behalf Of Another use case 4. If the Client wishes to add another program / service, go to the Complete Self-Service Integrated Application or Complete Application On Behalf Of Another use case 5. If Client demographic information or household composition changes, the Client logs into the system or contacts a Worker to update their information a. If the Client accesses the System with their log in credentials: i. The Client locates their demographic and/or household composition information ii. The Client updates any information that has changed iii. The Client saves the updates b. If the Client contacts a Worker to update their information: i. The Worker logs in and searches for the client record. See Search for Client use case for more details ii. The Worker opens the client record and locates the Client s demographic and/or household composition information iii. The Worker updates any information that has changed iv. The Worker saves the updates c. The System determines if re-determination is required for any of the Client s programs or programs for other members of the Client s household i. If re-determination is required, if applicable, inform the Client and go to Re-determine Eligibility use case ii. If re-determination is not required, inform the Client that the changes have no impact on their status - benefits will continue 6. If coverage or funding expires or client requires re-determination, go to Re-determine Eligibility use case Associations with Other Use Cases Search For Client View Client Information Complete Self-Service Integrated Application Complete Application On Behalf Of Another Re-Determine Eligibility Alternative Flows None

115 115 Additional Requirements The System shall provide a mechanism to change the status for multiple clients at once The System shall allow staff to associate individual members by relationships into flexible groupings, by program. The System shall notify the relevant parties of the redetermination regardless of the outcome of the process Notifications shall be sent based on the preference indicated in the user profile. Methods may include , SMS, postal mail or others. Where possible, electronic delivery methods will be selected unless postal mail is required by law or the Client has elected postal mail as a preference. The System shall allow Worker to override System decisions in extenuating circumstances System must be programmed to prompt automatic redetermination in specified situations (e.g. critical age change; system alert that post partum period has lapsed; periodic data matching that reveals discrepancy or change, etc.) The System shall enable mass changes

116 UC-9: Setup Eligibility Rules Actors Program Administrator A worker responsible for management of the program with rights to change program rules when required by law, mandate or policy changes. A very limited number of individuals will have the ability to perform this role. Purpose and Objectives The logic for eligibility determination must be defined as a set of rules with right and wrong answers. When these rules are applied to a Client s application, the System can determine whether or not he or she is eligible without manual intervention. In this use case, changes to laws, mandates or program policy prompts the Program Administrator to create, modify or remove a rule. Trigger Events A Program Administrator has a legitimate reason to setup a new eligibility rule A Program Administrator has a legitimate reason to change or deactivate an existing eligibility rule Pre-Condition The new eligibility rule or the change to an existing rule has been defined and approved Post-Condition A new eligibility rule is created An existing eligibility rule is updated Use Case Flow 1. The Program Administrator logs into the System 2. For a new or edited eligibility rule, the System guides the Program Administrator through a step-by-step process to create or modify the rule a. The Program Administrator defines the target programs i. The System presents a list of programs with rules defined within the System ii. The Program Administrator searches and/or sorts the list until he or she finds the desired programs with rules to be changed iii. The Program Administrator selects the programs to be edited or updated 1. All, multiple or a single program may be selected b. The Program Administrator defines the criteria that clients must meet to be eligible.

117 117 i. The System presents a list of characteristics. The characteristics will be defined by law, mandate or policy and may include, but are not limited to: 1. Age 2. Income 3. Assets 4. Residency, citizenship, etc. 5. Household composition 6. Relationship to others in the house and their eligibility 7. Conditions (e.g. pre-existing conditions, disabilities) 8. Eligibility in other programs 9. Past program participation ii. The Program Administrator selects the desired characteristics iii. The Program Administrator defines the accepted values for each criterion. Accepted values may be defined as a range, set of values or other ways c. The Program Administrator defines any additional program requirements such as, but not limited to: i. Interviews ii. Assessments iii. Documentation (e.g. last paycheck or confirmation of medical condition) d. The Program Administrator defines the criteria for establishing a waitlist i. Criteria for establishing a program waitlist may include: 1. Number of Participants whose eligibility/redetermination expires 2. Number of Participants who are terminated for reasons such as moving out of service area (based on recent trends) e. The Program Administrator defines the sequence in which to apply the criteria f. The Program Administrator sets the status of the rule to inactive or active g. The Program Administrator saves the rule 3. To update an existing rule, the Program Administrator selects the rule requiring updates and makes the desired changes. See Step 2 for the components of a rule that may be updated 4. To test the rule, the Program Administrator may apply the rule to the existing population to determine the impacts of new rules or rule changes in a test environment Associations with Other Use Cases Complete Self-Service Integrated Application Complete Self-Service Integrated Application on Behalf of Another Re-determine Eligibility

118 118 Alternative Flows None Additional Requirements The System provides version control The System maintains an audit log of all changes The System provides the capability to roll back to prior version of rule The System shall allow updates to multiple rules simultaneously

119 Integrated Eligibility Capabilities UC-10: Schedule Interview / Assessment Actors Client The Client is a recipient of benefits or services from the State of Vermont and/or contractor o o Applicant The Applicant role can be fulfilled by a client, a caretaker of a client, a System User, or any person that would like to apply for benefits from the State of Vermont. Authorized Representative The Authorized Representative is a person who has the ability and rights to apply for benefits on behalf of another person such as a parent, child, ward or other individual unable to represent himself. A navigator is included as an Authorized Representative for enrollment activities. Worker The Worker is an employee of a department and/or agency in Vermont or of a contracted entity who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this System, as well as any contractor. Purpose and Objectives Often clients will be required to participate in an interview / assessment to determine level of care or for other reasons before an eligibility determination can be made. To schedule an appointment for the interview/assessment, the System will allow four different ways to schedule: 1. The program may have a regularly scheduled open slot that clients can come in and meet with Workers (e.g., Mondays from 1pm to 4pm) 2. The program may have regularly scheduled phone hours during which clients can call at their convenience to talk with Workers 3. The Worker will reach out to the client and schedule an appointment for the client 4. The Client may request an appointment time via the self-service portal and schedules the appointment 5. The Worker calls the client without a scheduled appointment After scheduling, Clients may re-schedule their appointment if allowed based on the program rules. This use case demonstrates two ways the client can schedule an appointment. In this use case, the Client requests an appointment for an interview / assessment via the self-service portal or with the help of a Worker. The Worker has access to the System and the appropriate rights to perform the action described. Trigger Events The Client is informed they need to schedule an interview / assessment.

120 120 Pre-Condition The Client has a self-service Web portal account The Client has applied for (or is currently receiving) benefits The Client does not respond to notice. Post-Condition The Client has an appointment date, time and location The Client is able to reschedule if the original time does not work Use Case Flow 1. The Client navigates to the self-service Web portal and selects the request an interview / assessment appointment option. Types of appointments available may include, but is not limited to: a. Intakes i. Face-to-face interview / assessment ii. Rescheduled face-to-face interview / assessment iii. Telephone interview / assessment iv. Rescheduled telephone interview / assessment v. System interview / assessment b. Reapplications / Re-determination i. Face-to-face reapplication ii. Rescheduled face-to-face reapplication iii. Telephone reapplication iv. Rescheduled telephone reapplication c. Assessments i. Face-to-face assessment ii. Rescheduled face-to-face assessment iii. Telephone assessment iv. Rescheduled telephone assessment 2. The System displays a form to gather additional information needed to schedule the appointment. The information may include, but is not limited to: a. Translator requirements (typically conducted in person) b. Preferred method (phone or in person) c. Preferred location (if in person) d. Preferred date/time

121 If the resource calendar is available, the System determines the next available appointment date/time based on the Client preferences 4. If the resource calendar is not available, the System routes the request to the appropriate queue or Worker for scheduling (see Manage Caseload use case) 5. The System presents the appointment details to the Client 6. The System sends a notification confirming the appointment to the Client. The notification may include, but is not limited to: a. Client s name b. Appointment date/time c. Location d. Reason for appointment (e.g. Eligibility determination for a program) e. Instructions (if needed on what to bring to appointment, etc) f. How to reschedule 7. For scheduled appointments, prior to the appointment, an additional reminder notification is sent to the Client. The reminder notification may include, but is not limited to the same content as the confirmation notification. 8. If the Client wishes to reschedule their appointment, the System shall determine whether or not they are able to reschedule. a. If they are able to reschedule, go to Step 1. b. If they are not able to reschedule, send the Client a notification. The notification may include, but is not limited to: i. Client s name ii. Reason for appointment request (e.g. Eligibility determination for a program) iii. Next steps to obtain an appointment iv. Appeal Rights Association with Other Use Cases Complete Self-Service Integrated Application Complete Self-Service Integrated Application On Behalf Of Another Re-determination Conduct Interview/Assessment Make Work Program Assignment Alternate Flows If the Client does not wish to use self-service to schedule the appointment, he or she may contact a Worker via a call center, at a State facility or other approved method to request an appointment time. If the appropriate resources are available, the interview /

122 122 assessment may be conducted immediately, otherwise they will schedule an appointment time. If the Worker contacts the Client to schedule an appointment, the interview / assessment may be conducted immediately provided the Client is willing and the appropriate resources are available, otherwise they will schedule an appointment time. If the Client misses the scheduled appointment, the System will send a notification with information on how to reschedule if allowed based on the program rules. Additional Requirements The System shall allow the Worker to override the system scheduling.

123 UC-11: Conduct Interview / Assessment (and record results) Actors Assessee The client or applicant receiving the assessment. Assessor The person who conducts the screening or assessment. This may be a provider, case worker, intake worker, or other role within the Vermont Agency of Human Services (AHS). Purpose and Objectives Interviews and assessments are used to obtain and/or validate information about an Assessee. The information collected can range from a work history check in an interview to a determination of the Assessee s physical or mental health or other capabilities. Workers typically perform interviews during the eligibility determination process while workers or providers may perform assessments during the eligibility determination process or in the course of service delivery. Assessments are typically more rigorous than interviews and may result in level of care determinations that become the foundation for the Assessee s service plan In this use case, the Assessor conducts an interview or assessment to obtain information for eligibility determination, re-determination or service delivery Trigger Events Interview required for eligibility determination Level of care assessment required to determine program placement, eligibility determination or re-determination Assessment required during service delivery Pre-Condition Referral completed if required Need for interview / assessment identified Assessee consent provided Post-Condition Interview / assessment conducted Client record updated with results Use Case Flow 1. Depending on program, the Assessee either: a. Receives a notification to contact the Assessor to schedule an assessment for eligibility or i. The notice may be:

124 Sent via , phone, postal mail, or delivered verbally while meeting with the Worker 2. If the notification is via or mail, the notification includes information such as, but not limited to: a. Assessing entity name b. Assessing entity contact information c. Program assessed for d. Reason for interview / assessment e. Information on how to schedule an appointment f. Deadline for assessment completion b. The Assessor will contact the Client after they have the application to make an appointment for the clinical assessment for level of care. 2. As appropriate, the Assessee makes an appointment with the Assessor to conduct the assessment or interview (such as DAIL or the DCF worker.) a. The Assessor records the appointment date / time in the System b. The System sends a confirmation of the appointment date, time and location 3. As appropriate, the Assessor logs into the System and searches for the client record. See Search for Client use case for more details 4. As appropriate, the Assessor reviews the client record in preparation for the appointment. See View Client Information use case for more details 5. The Assessee arrives for, calls in for, or is called for the appointment 6. The Assessor conducts the interview or assessment a. If an electronic interview / assessment tool is available, the Assessor records information within the tool as he or she conducts the interview / assessment b. If an electronic interview / assessment tool is not available, the Assessor conducts the interview / assessment using traditional methods such as paper based records 7. The Assessor records the results of the interview or assessment a. If an assessment tool outside of the System is used, the assessment results and associated information are transferred to the System upon completion. Go to step 8 b. The System presents a form to record the assessment / interview results. The form may need to be tailored to the program and the type of interview / assessment. The form includes information such as, but not limited to: i. Name of Assessor conducting interview / assessment ii. Date / time of interview assessment iii. Program iv. Reason for interview / assessment

125 125 v. Interview / assessment results (assessment level of care [e.g. protective, intermediate or skilled]) c. The System pre-populates information on the form based on the profile of the Assessor who is logged in d. The System saves the results as part of the Assessee s record 8. The System sends a notification with the interview / assessment results to other collaborating providers involved with the Assessee for which consent to share has been established and documented within the Consent Registry 9. If the interview / assessment was part of the eligibility determination process, go to the Process Application use case to complete determination Associations with Other Use Cases Search for Client View Client Information Complete self-service integrated application Complete application on behalf of another Alternative Flows If the Assessee does not attend the appointment, a reminder notification is sent to the Assessee with any implications associated with the missed appointment and requesting they contact the Assessor to reschedule Additional Requirements Notifications shall be sent based on the preference indicated in the user profile. Methods may include , SMS, postal mail or others. Where possible, electronic delivery methods will be selected over the more expensive postal mail delivery method providing the State is not legally mandated to send notifications via postal mail.

126 UC-12: Issue and Track Benefit Actors Eligibility Worker The Eligibility Worker is an authorized State or contractor employee who may process an application, assist a client with applying, or apply for benefits on behalf of a client as part of their position. Applicant The Applicant role can be fulfilled by a client, an authorized representative (a caretaker of a client), a System User, or any person that would like to apply for benefits from the State of Vermont. The person for whom the Authorized Representative is applying for benefits on behalf of. Client The Client is a recipient of benefits or services from the State of Vermont and/or its contractors. Purpose and Objectives Once a Client has enrolled for benefits, the benefit must be issued for redemption. The steps for benefits issuance vary depending on the type of benefit. Some benefits such as Medicaid require ID cards while cash benefits such as 3SquaresVT may be issued to debit cards. Upon issuance of the benefit, Clients may begin redeeming the benefit for the related goods or services. Usage or redemption of the benefit is tracked for both cash and non-cash based benefits. In this use case, benefits are issued to a Client and benefit redemption/usage is tracked. Trigger Events An Applicant has successfully completed all steps for benefits issuance Pre-Condition Application has been approved for one or more benefits Post-Condition Benefits are issued to the Applicant (now a Client) Use Case Flow 1. The System generates a welcome package with the relevant content for the Client 2. The System issues the benefit a. If an ID card based benefit, the System updates the effective date and end date for the benefit and generates (or sends a request to generate) the ID card b. If a cash benefit, the System updates the amount, frequency and payment method. The benefit is issued per schedule using the Client s preferred payment method in accordance with program rules (e.g. check, electronic transfer, debit card, etc)

127 127 c. If a service benefit, the System updates the service parameters and the System will include the specific services the Client is authorized to receive, including but not limited to, the amount of service approved (e.g. frequency, duration, location, rates, and days of service) and provides information to providers or contractors as needed d. If a non-standard benefit, the Worker issues the benefit per program rules i. For Long Term Care, notification includes start date, highest paid provider, and patient share. The notice must be sent to: 1. The Client, DAIL, Highest Paid Provider and Case manager. The Eligibility worker determines who to send the notice to from a distribution list. 3. The System tracks benefit redemption/usage a. If a cash benefit, the System tracks the status of the benefit. Status may include, but is not limited to: i. Redeemed ii. Cancelled iii. Voided b. For all other benefits, the System tracks whether the benefit status is active or inactive Association with Other Use Cases Complete Self-Service Integrated Application Complete Self-Service Integrated Application on Behalf of Another Re-determination Process Application Determine Spenddown Amount and Submit Expenses Make Spenddown Payment Alternate Flows None Additional Requirements The System shall allow a Worker, Client, or provider / contractor to adjust the amount of specific services provided (provided it does not exceed established limits) The System shall allow payment to third party payees, including amounts, addresses, etc. (e.g. vendor and rent payments).

128 UC-13: Determine Spenddown and Submit Expenses Actors Eligibility Worker The Eligibility Worker is an authorized State or contractor employee who may process an application, assist a client with applying, or apply for benefits on behalf of a client as part of their position. Applicant The Applicant role can be fulfilled by a client, a caretaker of a client, a System User, or any person that would like to apply for benefits from the State of Vermont. The person for whom the Authorized Representative is applying for benefits on behalf of. Purpose and Objectives As part of the Medicaid application process, a means test is conducted to determine whether or not an Applicant s period countable income is at or below the established threshold. If an Applicant s period countable income exceeds the threshold, the Spenddown amount i.e., the difference between their period countable income and the threshold is determined. Once the Spenddown amount is met for the period, Medicaid benefits are issued to the Applicant assuming they meet all other Medicaid eligibility criteria. The Spenddown amount may be met by submitting evidence for relevant expenses. In a given period, Applicants may opt to carry over any contributions toward the Spenddown amount to a future period. Alternately, when Applicants exceed the Spenddown amount, the excess is applied to future periods to offset the Spenddown amount. In this use case, the System determines the Spenddown amount and applies eligible expenses to offset the Spenddown amount. Trigger Events Applicant decides to pursue Spenddown to offset their countable income Pre-Condition Applicant meets all Medicaid eligibility criteria with the exception of the countable income threshold Post-Condition The Spenddown amount has been determined Applicable expenses have been applied to offset the Spenddown amount A notification is sent indicating whether or not the Spenddown has been met If Spenddown amount is reduced to zero, the benefit is ready for issuance If Spenddown amount for the period has not been met, Applicant carries over contributions toward Spenddown to the next period If Spenddown amount for the period is exceeded, excess is applied to future period(s)

129 129 Use Case Flow 1. At the time of application for benefits, the System determines the spenddown amount by calculating the difference between the Applicant s countable income and the Medicaid countable income threshold 2. The Applicant contacts an Eligibility Worker to complete the Spenddown process 3. The Eligibility Worker logs into the System 4. The Eligibility Worker searches for and views the Applicant s application 5. If consent is provided, the System may check additional sources for applicable expenses a. The System may check the System for Applicants who are currently (or have recently been) receiving benefits b. The System may check with the Credit Bureau(s) for unpaid expenses 6. The Applicant provides additional evidence of expenses that may be applied to offset the Spenddown amount if available (Note: See alternate flow for expenses identified after the initial interaction with the Eligibility Worker) a. The Applicant may upload soft copies of the evidence of expenses through the self-service portal (see Submit Additional Information use case) b. The Applicant may fax or drop off a hard copy of the evidence of expenses 7. The Eligibility Worker analyzes each expense and enters it into the System. For each expense, information collected may include but is not limited to: a. Date of expense b. Type of expense c. Dollar amount d. Whether the bill has been paid or not e. Status (Applied to Spenddown or not) 8. The System prompts the Eligibility Worker to ask for mileage during the current period for the expenses entered or identified by the System a. If the Applicant uploaded the expense via the self-service portal, the System will prompt the Applicant to provide information to calculate mileage expense b. The System calculates mileage expense by determining the distance between the Applicant s address and Provider location and multiplying by the agreed upon amount/mile c. The System applies the mileage expense to the Spenddown amount 9. If the Spenddown amount has not been met or exceeded: a. The Applicant may opt to carry over the current contributions to the spenddown amount to the next period b. A notification is sent to the Client indicating the Spenddown amount has not been met, the amount applied towards the spenddown and the revised spenddown amount

130 If the Applicant is over income and over resources, the System applies to logic to determine where to apply overages as configured for each program. a. The System supports doing an income and resource Spenddown at the same time. i. The resource spend down can include giving the money away for some programs. 11. If the Spenddown amount has been met, the System issues benefits (see Issue Benefit use case) a. The System determines if the change in the Applicant s countable income warrants changes to other benefits (see Update Client Changes use case) b. A notification is sent indicating the Spenddown amount has been met c. If the Spenddown amount has been exceeded, the System applies any excess toward future periods until the excess has been exhausted 12. The Applicant is provided with information on how to request an Appeal (see Manage Appeals use case) Association with Other Use Cases Complete Self-Service Integrated Application Complete Self-Service Integrated Application On Behalf Of Another Complete Re-Determination View Alerts / Notifications Make Spenddown Payment Submit Additional Information Alternate Flows If a recurring expense is identified, presumptive or ongoing issuance of Medicaid benefits may occur (Pending Policy) If additional expenses are identified or incurred after the initial interaction with the Eligibility Worker, the Spenddown amount is offset as these expenses are processed by Eligibility Workers. Go to Step 6 Additional Requirements The System shall prevent duplicate expenses by warning the Eligibility Worker of expenses with matching date, type and amounts The System will calculate and notify Eligibility Worker if bills were paid outside of the spenddown period

131 UC-14: Request Service Actors Client The Client is a client or authorized representative of a client that is a recipient of benefits from the State and/or its contractors. Purpose and Objectives At any time during the course of receiving services, clients may want to request additional services from their current providers or benefits. Clients will have the capability to request services through the Web portal. In cases where programs have their own Web portals for client access, clients will be routed to the program specific portal. In this use case, the Client requests services through the Web portal. Trigger Events The Client would like to request additional services Pre-Condition The Client record exists and the Client has created an self-service Web portal account Post-Condition The Client has requested service in the Web portal and the request has been routed to the program responsible for evaluating the request Use Case Flow 1. After logging in to his / her personal self-service Web portal account, the Client shall have the option to request services a. The System shall display all services / programs available to a Client, including, but not limited to: i. Medical services ii. Substance abuse iii. Mental health iv. Transpiration services v. Workforce development (job training) vi. Case coordination services vii. Food shelters / pantries

132 132 viii. Child care assistance and prevention services ix. Retention and contingency services 2. The Client selects a service from the list. The list options will need to be populated from available services within programs the client is signed up for. a. The System displays a summary of access criteria, contact information locations, and business hours b. The System provides a link to the program-specific website c. The System allows the Client to access a resource directory 3. The System displays a form with the required information to arrange services 4. The Client submits the form and is notified of its submission 5. If a case manager is assigned to the Client or the Client has consented to collaborative service delivery, the appropriate staff and providers are notified of the request (see Manage Caseload use case) Association with Other Use Cases Create User Account Manage Caseload Alternative Flows None Additional Requirements None

133 UC-15: Appeal Decision Actors Client The Client is a recipient of benefits or services from the State of Vermont and/or its contractors. Applicant The Applicant is a client that wishes to apply for services for themselves and/or their family. The person for whom the Authorized Representative is applying for benefits on behalf of. Appeal Worker The Appeal Worker is a member of the Fair Hearing Unit (FHU). He or she has the rights to perform the described actions for this System. Worker The Worker is an employee of a department and/or agency in Vermont or of a contracted entity who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this System, as well as any contractor. Purpose and Objectives By law, clients must be given an opportunity to appeal decisions impacting their benefits (e.g. eligibility determination or re-determination, or benefits/services provided) irrespective of whether the decision is in their favor; benefits were approved or not approved; or whether benefits were denied. A Client or Applicant can request at any time from the Human Services Board. Clients are given the option of whether to continue benefits after informing them of the potential consequences if the appeal is not successful. An appeal is a formal request... to review a decision regarding determinations made... that affects something for which the applicant or beneficiary believes they are entitled.... An appeal submission and the consideration of the appeal must follow specific steps, which must be clearly identified to the individual. [Excerpt source: PHPG DRAFT INVENTORY OF RELEVANT EXISTING VERMONT STATE APPEALS PROCESSES FOR INDIVIDUALS AND FOR SMALL EMPLOYERS dated July 16, Revised August 7, 2012]. This appeals process 1 was designed by the State of Vermont to meet the needs of the Fair Hearing rights of clients. In this use case, a Client appeals a decision through the Web portal and the appeal process is taken through final ruling. Trigger Events 1 See the Pacific Health Policy Group DRAFT INVENTORY OF RELEVANT EXISTING VERMONT STATE APPEALS PROCESSES FOR INDIVIDUALS AND FOR SMALL EMPLOYERS document for further appeals information.

134 134 The Client requests an appeal through the Web portal (this may also be done through other channels such as by mail, by telephone or in person but these are not covered in this use case) Pre-Condition The Client receives notification that their benefits or services are adversely impacted by an eligibility determination or another decision as documented by ESD Post-Condition A ruling is made on the appeal All parties are notified of the outcome Benefit are continued depending on Client s choice Recoupment of benefits is initiated if necessary Use Case Flow 1. The Client logs in to the Web portal and goes to the Appeals section a. The Client selects the option to request an appeal i. The System presents a form that allows the Client to enter and select information about requesting an appeal ii. The System produces a pre-populated appeals form containing relevant materials and supporting documentation regarding the appeal iii. The System allows the Client to choose whether to continue receiving benefits during the appeals process 2. The System determines whether or not the request is within the specified timeframe from the date of the decision (e.g. 90 days) a. If it is not within the timeframe, the System notes this on the appeal form for handling by the Health Services Board 3. The System notifies appropriate department / program and Worker of the request for appeal 4. The System adds a note to the Client case that the case is pursuing the appeals process, including the reason for the appeal and whether the client has chosen to continue benefits during the appeals process 5. A Policy and Technical Review is held with the Client and the outcome is documented in the System a. If this resolves the issue: i. The Appeals Worker updates the case ii. The System generates a Notice of Decision; go to end of process b. If this does not resolve the issue, the appeal process is continued

135 The System enables the Fair Hearing Unit (FHU) to complete a consolidated Human Services Board (HSB) Memo for all appealed programs 7. The System allows the Appeals Worker to assemble a file of relevant case documents (including the 113 form) and send the file to AOPS and AAG a. 113 form does not go to the HSB 8. The System generates a Memo that can be sent electronically to the HSB, or delivered in hard copy 9. The HSB sends the Notification informing the Client of the hearing date/time via a separate System 10. The System allows the Appeals Worker to enter the hearing scheduling information into the System 11. The System supports the Appeal Worker during the appeal process by allowing any System user with appropriate access to view information contained within the System 12. The System allows the Appeal Worker to enter the Proposed Order generated by the HSB hearing and supporting evidence into the System a. The Board meets on a monthly basis to consider those recommendations and the System allows the Board to review the appeal and the Board issues a ruling i. Parties to an appeal can attend the Board meetings and argue whether the Board should or should not adopt the hearing officers recommendations 13. The System notifies the FHU Appeals Workers that the Proposed Order is ready to review 14. The System allows the FHU Appeals Worker to review the Proposed Order a. If the FHU affirms the Proposed Order, the System generates a Notification of Decision and process ends b. If the FHU does not affirm the Proposed Order, continue 15. The System notifies the AOPS Appeals Workers that the Proposed Order is ready to review 16. The System allows the AOPS Appeals Worker to review the Proposed Order a. If the AOPS agrees with the Proposed Order, a Notification of Decision is sent; and process ends b. If the AOPS does not agree with the Proposed Order, continue 17. The System allows the AOPS Appeals Worker to review the Proposed Order with the AAG 18. The System supports the AAG arguing the AOPS position in front of the HSB a. The System allows the HSB to enter a Final Order and a Notification of Decision is generated 19. If the AAG seeks a reversal by the Secretary, the System allows the AHS Secretary to review the ruling for a specified number of days. a. If the Secretary does not review the appeal within a specified number of days the ruling is considered accepted

136 136 b. If the Secretary reviews appeal and accepts ruling the appeal is closed c. If the Secretary reviews appeal and changes the ruling, this ruling is updated d. In all cases notifications are sent to the Client and to the Worker 20. The System removes the indication in the Client case that the case is part of an appeals process 21. If recoupment is needed, a notification is sent to the appropriate department Associations with Other Use Cases Complete Self-Service Integrated Application Complete Self-Service Integrated Application On Behalf Of Another Complete Re-Determination View Status of Application Submit Additional Information for Application View Alerts / Notifications File Grievance Alternate Flows If the Client requests a hearing verbally to the Worker, the Worker enters the request for a fair hearing in the System. Additional Requirements The System shall send notifications of appeal to multiple, involved, appropriate parties.

137 UC-16: File Grievance Actors Client The Client is a recipient of benefits or services from the State of Vermont and/or its contractors. Applicant The Applicant is a client that wishes to apply for services for themselves and/or their family. The person for whom the Authorized Representative is applying for benefits on behalf of. Worker The Worker is an employee of a department and/or agency in Vermont or of a contractor who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this Solution, as well as any contractor. Purpose and Objectives The Agency for Human Services provides grievance processes for Medicaid Managed Care Entities through the Global Commitment to Health and the Department of Financial Regulation. The Health Benefits Exchange will also require grievance procedure 1 s. A grievance (complaint) is any expression of dissatisfaction about [AHS, its partners or contractors] made orally or in writing by an applicant or beneficiary, regardless of whether any remedial action can be taken. This can include concerns about the operations of the [AHS managed programs]. [Based on: PHPG DRAFT INVENTORY OF RELEVANT EXISTING VERMONT STATE APPEALS PROCESSES FOR INDIVIDUALS AND FOR SMALL EMPLOYERS dated July 16, Revised August 7, 2012] In this use case, a Client files a grievance through the Web portal and the grievance process proceeds. Trigger Events The Client files a grievance through the Web portal (this may also be done by other channels such as mail, by telephone or in person but these are not covered in this use case) Pre-Condition The Client has a reason to file a grievance 1 See the Pacific Health Policy Group DRAFT INVENTORY OF RELEVANT EXISTING VERMONT STATE APPEALS PROCESSES FOR INDIVIDUALS AND FOR SMALL EMPLOYERS document for further grievance information.

138 138 Post-Condition The Agency responds to the grievance through a structured process Use Case Flow 1. The Client logs in to the Web portal and selects the option to file a grievance 2. The System presents a form that allows the Client to enter information specific to the grievance 3. The Client submits grievance orally or in writing 4. Grieved entity sends notification of receipt of grievance within 5 days 5. The System allows the Client to enter whether they have spoken to their provider / primary point of contact regarding the matter previously 6. The System determines whether or not the request is within the specified timeframe from the date of the decision (e.g. 90 days) a. If it is within the timeframe, go to the next step b. If it is not within the timeframe, the System informs the Client or Worker that a hearing cannot be scheduled 7. The System notifies appropriate department / program and Worker of the filing 8. The System allows the Worker to acknowledge receipt of the filing and sends notification of receipt to the Client 9. The Worker reviews the grievance within 10 days of receipt a. If the Worker does not review the grievance within 10 days of receipt, a notification is sent to departmental / program administrator 10. The Worker enters information about the grievance into the System 11. The System send notifications including the information the Worker has entered and closes the grievance Associations with Other Use Cases Complete Self-Service Integrated Application Complete Self-Service Integrated Application On Behalf Of Another Complete Re-Determination View Status of Application Submit Additional Information for Application View Alerts / Notifications Appeal Decision Alternate Flows None

139 139 Additional Requirements None

140 UC-17: Recover Benefits Actors Client The Client is a recipient of benefits or services from the State of Vermont and/or its contractors. Worker The Worker is an employee of a department and/or agency in Vermont or of a contractor who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this Solution, as well as any contractor. Purpose and Objectives The State may receive complaints or alerts from different sources indicating a Client who is receiving more or less benefits than they should given their circumstances. These complaints may be anonymous or may be System generated. Every complaint or alert is logged within the System regardless of whether or not it can be associated with a specific client. For those complaints or alerts than can be associated with a Client, an investigation is conducted to determine if there is a discrepancy between the amount of benefits the Client should receive and the amount they actually receive. If a discrepancy is found, the amount of under/over payment is calculated and a method to reimburse the Client for under payment or recover the over payment is established. Additionally, the Client s benefit level is recalculated to prevent over payments in the future. In this use case, a Worker investigates a complaint or alert indicating a Client is receiving a higher or lower level of benefits than appropriate and takes corrective action. Trigger Events A Worker receives a complaint or alert indicating a Client has a discrepancy between the benefits issued and the benefits a Client should receive Pre-Condition The Client is receiving benefits (or was in the recent past) Post-Condition The complaint or alert is logged A discrepancy is found (or not); if found: The over payment amount and recovery method is established Benefits level is re-calculated Use Case Flow 1. The Worker receives a complaint or alert

141 The System logs the complaint and attempts to associate it with a Client a. If the System (or Worker) is NOT able to associate the complaint / alert with a Client, go to end b. If the System is able to associate the complaint / alert with a Client, the Worker performs some initial analysis to determine the priority of the complaint / alert 3. The Worker conducts an investigation to determine if there is a discrepancy between the amount of benefits the Client should receive and the amount the Client actually receives a. If a discrepancy is NOT found, update the System with the results of the investigation and go to end. b. Results may include, but are not limited to: i. Name of Worker conducting the investigation ii. Indication that no discrepancy was found iii. Supporting evidence c. If a discrepancy is found, go to next step 4. If the Client is currently receiving benefits, the Worker re-calculates the benefits level 5. The Worker updates the System with the following information: a. Name of Worker conducting the investigation b. Under/over payment amount c. Payment or recovery method d. New benefits level e. Effective date for the benefits change 6. The System sends a notification to the Client informing them of the discrepancy. The notification may include, but is not limited to: i. Under/over payment amount ii. New benefits level iii. Effective date for the benefits change iv. Course of action v. Appeal Rights 7. If an under payment, the System: a. Issues the payment to the Client b. Updates the payment status c. Closes the claim 8. If an over payment, see Recover Benefits Collect Over Payment use case Association with Other Use Cases Issue and Track Benefits

142 142 Recover Benefits Collect Over Payment View Alerts / Notifications Alternate Flows None Additional Requirements None

143 UC-18: Recover Benefits Collect Over Payment Actors Client The Client is a recipient of benefits or services from the State of Vermont and/or its contractors. Worker The Worker is an employee of a department and/or agency in Vermont or of a contractor who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this Solution, as well as any contractor. Purpose and Objectives When an investigation indicates a Client is receiving more benefits than they should be given for their circumstances, a recovery method and plan to collect the over payment is established. For Clients who are currently receiving benefits, the Recovery methods may include: (a) recoupment where the over payment is deducted from benefits received over a designated timeframe, (b) installment plans where Client s make direct payments to the State, (c) tax offset where over payments are deducted from Federal or State tax refunds or (d) other methods. Payments are tracked as they are made until the balance is paid in full. In this use case a Worker collaborates with a Client to collect and track over payments that were issued to the Client. Trigger Events A notification is sent to the Client informing them of the over payment Pre-Condition An over payment is identified Post-Condition A recovery method is established Payments made are tracked If payments are not made, further action is taken Use Case Flow 1. The Worker logs in to the System and searches for the Client record 2. Once the record is located, the Worker selects the Benefits Recovery option

144 The Worker indicates the recovery method. Recovery methods may include, but are not limited to: a. Recoupment b. Direct Payment Installments/One-time payment c. Tax offset 4. If the recovery method is recoupment, the System calculates the new benefit level a. If the full amount cannot be recovered prior to the benefits expiration date, go to prior step to establish a recovery method for the remaining balance b. The System updates the Client record with the new benefit level 5. If the recovery method is an installment plan, the System calculates the payment amount and time period automatically or based on input provided by the Worker 6. The System updates the Client record with the recovery method(s), payment and duration 7. The System is updated as the Client makes payments using the established recovery method. Payment information is tracked, including but not limited to: a. Payment due date b. Actual payment date c. Recovery method d. New balance due 8. For each installment payment made, the System sends a notification to the Client confirming payment 9. For each installment payment missed, the System sends a notification to the Client of the past due amount and actions that may be taken a. If payments are missed, the Worker may select a new recovery method (e.g., recoupment or tax offset) 10. When the balance due is zero, the System closes the claim and indicates the balance is paid in full Association with Other Use Cases Recover Benefits View Alerts / Notifications Alternate Flows None Additional Requirements None

145 Shared Capabilities UC-19: Create User Account Actors Client The Client is a client or authorized representative of a client that wishes to access services of the self-service Web portal beyond the publically available information and tools. Authorized Representative The Authorized Representative is a person who has the ability and rights to apply for benefits on behalf of another person such as a parent, child, ward or other individual unable to represent himself. A navigator is included as an Authorized Representative for enrollment activities. Worker The Worker is an employee of a department and/or agency in Vermont or of a contracted entity who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this System, as well as any contractor. Purpose and Objectives Clients must establish an account to apply for State programs, check on the application status, request re-determination of programs, send and receive messages from providers and other services provided by the System. This process will attempt to link the account with program accounts as appropriate. In this use case, the Client sets up login credentials and establishes basic preferences. Trigger Events The Client wants to use services available in the System Pre-Condition Client has access to the Internet Post-Condition An account has been set up and the Client has been notified that the account is active Use Case Flow 1. The Client navigates to the self-service Web portal and selects the Create New Account link 2. The System displays a step-by-step form with branching logic to capture the required and optional data elements for a new client account a. Data elements may include, but are not limited to:

146 146 i. First name ii. Last name iii. Account password iv. Social security number 1. The System assigns a temporary value if the person is applying for a SSN. v. Contact information a. The System supports three scenarios in which a temporary SSN is assigned: i. a person has already obtained one, ii. a person has applied for one or iii. a person has a recognized religious objection that precludes them from accessing an SSN vi. address (optional; other fields may be required if this is not given) vii. Program(s) identification (optional) viii. Primary phone number (optional) ix. Mobile phone (for SMS notifications) (optional) 3. The System indicates when the data in a field will be verified and specifies the method used to validate the data field a. The System validates the information provided by the Applicant i. The System will validate information based on at least: 1. Required field completion 2. Field content types (e.g. names must not contain numbers) 3. Acceptable values (e.g. no birth dates before 1/1/1900) 4. Values based on available real-time and stored data sources (e.g. vital statistics queries, Department of Motor Vehicles, Social Security Administration, etc.) 4. The Client enters the requested information and submits the form 5. The System generates an automated or SMS with a validation code for the account 6. The Client enters the validation code when requested to validate the account a. If the Client is unable to receive the code the System will generate a new code and send a new or SMS 7. The System provides additional one-time actions and initial setup: a. Account settings that can be updated include, at least: i. Preferred method of communication (e.g. , SMS, phone, etc.)

147 147 ii. Preferred delivery of communications (to whom communications are sent, including the Client, Authorized Representatives, and others) iii. Subscription to alerts and notifications (e.g. changes to client record, new messages, referral changes, etc.) iv. Notification types desired v. Authorized representative(s) (optional) b. The System will allow the Client to change his / her password at any time 8. (Optional) The System displays options to add, update or remove addresses or mobile phone numbers used to receive notifications 9. (Optional) The System displays options to add additional clients for which the Client is an authorized representative a. Additional clients for which the client can create linked accounts include, but are not limited to: i. Children ii. Parents/ Guardian iii. Other clients that have given the Client User permission to do so iv. Other clients for which the Client User has Power of Attorney 10. (Optional) The Client repeats steps 2 and 3 for each additional client to be created and linked to their account Associations with Other Use Cases View Status of Application Submit Additional Information for Application View Client Information View Alerts / Notifications Alternative Flows None Additional Requirements The System shall allow an existing Client to log into the System and skip directly to steps 7 or 8 The System shall limit the number of duplicative online accounts through validation of information entered and other proactive means. However, it should permit the certain types of accounts to have several cases under and legal representative to have aggregated account when the person is acting in different capacities. (e.g., Head of Household (HOH) for their own case and HOH in a child-only case.") The validation code for an account shall expire after a predefined time period

148 148 The System shall allow the Client, a Worker or the Authorized Representative to deauthorize the Authorized Representative from viewing and acting on behalf of the Client, when the Authorized Representative is not a legal guardian, under specified conditions such as: At the request of either party At a specified date / time At changes in program / service status (e.g. when an Applicant is released from prison or when eligibility for a program ends) As a result of suspicious or fraudulent behavior The System shall notify both parties of authorization or de-authorization of an Authorized Representative to act on behalf of an Applicant

149 UC-20: View Client Information (Client) Actors Client The Client is a recipient of benefits or services from the State and/or its contractors. This role may also be filled by an Authorized Representative that has been granted access to the Client s account. Purpose and Objectives At any time during the course of receiving services, a Client may want to view information related to his or her enrolled programs or services. This may include: Viewing the status of referrals Viewing programs enrolled Filling out additional eligibility determination applications and redeterminations Sending and reading secure messages to and from providers Accessing resource directories and reports Having access to a broader set of information will enable a client to improve his / her selfsufficiency, encourage collaboration with providers and ultimately result in better program outcomes. In this use case, the Client views his/her record in the System. Trigger Events The Client would like to view information in the system Pre-Condition The client record exists and the Client has created a Web portal account Post-Condition The Client has reviewed information available in the System Use Case Flow 1. The Client logs into his / her self-service Web portal account 2. The System presents a summary of information from their account, possibly including: a. Personal information b. Eligibility status c. List of programs / services enrolled d. Alerts and notifications e. Messages from providers

150 150 f. Resource directory g. Test results h. Referrals i. Documents associated to the case i. Documents viewable by the Client are configurable by at least 1. Document type 2. Program 3. Specific documents chosen by a worker for sharing 4. Client attributes (e.g.) 3. The Client reviews the information a. The System allows the Client to access more detailed information on any of the categories above, if available 4. At any time during this use case, the Client may do at least the following: a. Update preferences and personal information b. Send secure messages to a provider (see Send Secure Message use case) c. Read secure messages from a provider (see Read Secure Message use case) d. Request services from a provider (see Request Service use case) e. Apply for additional programs or services (see Complete Self-Service Anonymous Screening and Complete Self-Service Integrated Application use cases) f. View alerts and notifications (see View alerts / notifications use case) g. Review forms such as completed application(s) h. Review answers to common questions Associations with Other Use Cases Send Secure Message Read Secure Message Request Service Complete Self-Service Anonymous Screening Complete Self-Service Integrated Application Alternative Flows None Additional Requirements None

151 UC-21: Search for Client Actors Worker The Worker is an employee of a department and/or agency in Vermont or of a contracted entity who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this System, as well as any contractor. Purpose and Objectives Prior to, throughout and after interacting with a client, a Worker may want to access the System to view information on a client, validate existing information in their source system, or collaborate with another provider. The amount of information provided to the Worker will be dependent on the access rights and the level of consent that has been granted by the client. If the Worker has the appropriate rights, but there is no consent, only basic demographic information will be viewable without any program or service information. In addition, access rights and consent will restrict the ability of the Worker to see alerts, notifications or shared analytics specific to the client or the population the client is a part of. In this use case, the Worker searches for a client in the system. The Worker has access to the System and the appropriate rights to perform the action described. Trigger Events The Worker has a legitimate reason to view a client s information Pre-Condition The Worker has appropriate rights to access the System Post-Condition The Worker has uniquely identified a client within the system If a client is uniquely identified, the Worker is able to easily navigate to more detailed information (See View Client Information Use Case) The Worker is notified that there are multiple matches to the query but is unable to uniquely identify the client or The Worker is notified there are no clients that match the query parameters Use Case Flow 1. The Worker logs on to the Web portal and selects the Client Search function

152 The System displays a step-by-step form with sorting and filtering capabilities: a. Search criteria may include: i. Agency ii. Program name and program identifier iii. First name iv. Last name v. Date of birth vi. Age vii. Gender viii. Social security number ix. State ID (including drivers license) x. Residential address xi. ZIP Code xii. Birth name xiii. Alien registration number xiv. Provider name / ID (e.g. Primary physician or medical / health home) xv. Claim IDs b. Filters may include: i. Agency ii. Program iii. Service 3. The Worker enters some or all of the requested information into the System and submits the form a. Only one of the search criteria is required when worker uses social security number, UID, driver s license number, or alien registration number. 4. The System searches the Master Client Index for records that match the search parameters 5. The System displays clients that match the search parameter(s) a. If the matches are not definitive (e.g. conflicting data), the System will display the matched and unmatched elements for inspection by the Worker b. If multiple matches are found, the System shall allow the Worker to enter additional search parameters and repeat steps 3 and 4 with filtering intelligence and advanced search capabilities c. If a client cannot be uniquely identified, the System shall notify the Worker and provide the option to create a new client record in the System (see Create User Account use case)

153 153 d. If multiple matches are found that correctly identify the client, the System will allow the Worker to report the duplicative accounts for review and remediation by a System administrator 6. Once the System has identified the client, the Worker selects the matching record a. The System shall display client information based on the System right of the Worker and the consent (see View Client Information use case) Associations with Other Use Cases View Client Information (Staff) Update Client Changes Complete Self-Service Integrated Application Complete Self-Service Integrated Application on Behalf of Another Alternative Flows If the client is physically present, the Worker may identify the client in the System using alternative methods, such as: Biometric reader Barcode reader on client program or State ID card Swipe Card Client program ID card, Driver License, State ID card, etc. Other methods as approved by Vermont policies If a new Client record is created, the System must: ensure the new record is unique enforce a consistent process update the Master Client Index Additional Requirements The System shall allow searches based on: Partial text search Phonetic search Value ranges (e.g. dates, age, zip codes) The System shall have the capability to mark search fields as optional or mandatory

154 UC-22: View Client Information (Staff) Actors Worker The Worker is an employee of a department and/or agency in Vermont or of a contracted entity who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this System, as well as any contractor. Purpose and Objectives During the course of a session with a provider, when reviewing a referral or when a client contacts Vermont to request a service, apply for assistance or has any other inquiries, the Worker will access the Web portal to check if a client record already exists through the Search for Client use case and, if there is one, view information contained within the record. In this use case the Worker views information available through the system. Trigger Events Worker has a legitimate reason to view information about a client in the Web portal Pre-Condition The client record exists and has been accessed by the Worker Post-Condition Worker has reviewed client information Use Case Flow 1. The System displays whether there is a consent policy on file for the client that permits the current Worker to access this record. The applicant information is available for viewing in the record by eligibility workers as a condition of the application 2. The Worker reviews the information in the record displayed by the system a. The System displays any alerts and notifications specifically related to this client as well as information specific to the client s population and geography (see View Alerts and Notifications use case) b. If there is not a consent on file or if the consent(s) on file do not include the Worker, the view is limited to basic client information such as: i. First, middle and last name ii. Date of birth (or age) iii. Gender iv. Address

155 155 v. Phone number vi. Number of active cases vii. Number of inactive cases viii. Other family members within the household construct as defined by various programs 1. Listing of family members includes links to those client views c. If a consent is on file for the client with the Worker, the Worker may also be able to see: i. Active collaboration in the system (e.g. secure messages, case notes, etc. that have not expired) ii. Other workers that are collaborating on the case(s) iii. Active programs iv. Detailed information on types of programs (e.g. medical, immunization / public health, mental health) v. Detailed information from programs and services vi. Hearing case information (e.g. Status of beneficiary in the hearing process, subject of hearing, case worker/attorney assigned to the hearing, results of the hearing including if the case went to the supreme court or if there was a Secretary's reversal) vii. Case notes viii. Referral information 3. Optionally and if there is no consent in the Consent Registry for the client, the Worker may engage the client in the informed consent process to allow for additional viewing capabilities and coordination of service (see the Record Client Consent (and changes, revocation) use case) 4. Optionally, the Worker may refer the client for additional services (see Create Referral use case) 5. Optionally, the Worker may send a message to another provider (see Send Secure Message use case) 6. Optionally, and if the client has identified multiple providers that may collaborate on his / her behalf, the Worker may record shared case (see Record Shared Case Note use case) Associations with Other Use Cases Search for Client Create Referral Send Secure Message Read Secure Message

156 156 Read Shared Case Note Record Shared Case Note Record Client Consent (and changes, revocation) Alternative Flows None Additional Requirements All alerts and notifications will correspond with the access levels the Worker has in the System and consent the client has granted

157 UC-23: Record Client Consent (and changes, revocation) Actors Consent Recorder The Consent Recorder is an employee, or contractor or other authorized Worker that has the rights and ability to discuss and document consent on of a client. This role may be fulfilled by providers, provider front office staff, case workers or other similar workers. Client The Client is a recipient of multiple benefits or services that would benefit from the consensual sharing of information between multiple entities. Purpose and Objectives To allow an information query and/or to enhance cross program case collaboration, clients must give consent to providers in order to share confidential information and other personally sensitive information. The Web portal will have the capability to record consent to share information between two or more agencies. This will be recorded in Consent Registry. The System will have the capability to store elements of the informed consent for the purpose of managing user access rights to specific data elements. If the original consent is in hard copy, the original of the consent will be filed according to policy. Optionally, the original can be scanned into the system. A form in the system shall guide the user through the process of completing the consent form. In this use case, the Consent Recorder records client consent in the Web portal. This use case assumes that the client has an existing record in the System and that the search for a client yields a unique result. Trigger Events Worker secures informed consent and would like to record client consent in the system Pre-Condition Worker has appropriate rights to access the system and to record consent The Client has a Web portal record established The Worker has appropriately accessed the Client s record Client has agreed to give consent for the sharing of information between providers Post-Condition Client consent is recorded in the system Use Case Flow 1. The Worker selects the Record Client Consent option 2. The System displays a Client s Rights and Responsibilities Form for the Worker to record consent details in discrete fields; the form includes:

158 158 a. Worker and entity obtaining the consent from client (pre-populated from Worker information) b. Other providers and / or entities contained in the consent (e.g. agencies, departments, program, services or providers who can share information) to allow two-way sharing of information c. Type and focus of the information covered may include (granularity and parameters to be determined by Vermont policy) i. Types of information might be: 1. Benefit and eligibility information 2. Medical records 3. Assessments 4. Test results 5. Criminal case history 6. Claims and payments ii. Areas of sharing may include: 1. Behavioral health a. Mental health b. Substance abuse 2. Physical health 3. Public assistance programs 4. Public safety 5. Child welfare 6. Aging and independent services d. Purpose of the sharing of information; the System shall have a list of pre-defined purpose categories including, but not limited to: i. Congruency and coordination of care ii. Continuity of care iii. Establishing eligibility for public programs iv. Judicial appeals v. At the request of the individual vi. Court order vii. Payment for services viii. Other (with description) e. Expiration conditions of the consent, include, but are not limited to: i. Period of time from date consent is given ii. Specified end date

159 159 iii. Other conditions, including, but not limited to: 1. End of required collaborative service delivery 2. End of treatment 3. The Worker completes the Clients Rights and Responsibilities Form with all required fields and any optional fields a. The System shall provide the option to indicate if a third party is providing consent (conservatorship, parent, other authorized third party, etc.) 4. If desired by the client, the Worker will print or a copy of the consent Association with Other Use Cases Create Referral to Service / Program Acknowledge Referral Accept or Deny Referral Modify or Withdraw Referral Search for Client View Client Information (Staff) Read Secure Message Read Shared Case Note Alternative Flows None Additional Requirements The System shall allow electronic and telephonic client signatures for the consent The System shall ensure that all mandatory data fields have been completed The System shall have the capability to scan hard copy consent forms and attach to a client record The System shall allow eligibility workers to access draft or completed applications without consent as needed in accordance with their roles The System shall maintain an auditable record of all consents recorded, accessed and access attempts The System shall create notifications for providers when: Consent expiration date is approaching Client has deceased Resident has moved outside of the State temporarily or permanently The System shall allow Clients to revoke consent at any time

160 The System shall allow Clients to modify consent at any time 160

161 UC-24: View Alerts and Notifications Actors Worker The Worker is an employee of a department and/or agency in Vermont or of a contracted entity who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this System, as well as any contractor. Client The Client is a recipient of benefits or services from the State of Vermont and/or its contractors. Public The Public is anyone that has access to the Internet that wishes to view information without an account. Purpose and Objectives The Web portal will have the capability to generate alerts and notifications for the Worker, the Client and the Public. Through the Client s and Worker s use of the Web portal alerts / notifications may be triggered. For example, a Client may receive notifications as a result of the application process while a Worker may receive alerts while coordinating service for a Client. The Public may subscribe to any alerts / notifications that are available for general consumption. An example might be upcoming program events located in a specific zip code. The System will allow a user to modify subscriptions to alerts and notifications within parameters defined by System administrators. Additionally, the System will allow for different priority and urgency categories of alerts and notifications and will distinguish between mandatory and optional alerts and notifications. The Worker will not be able to unsubscribe from mandatory alerts and notifications as set by Vermont policy. Alerts and notifications are messages that are displayed to Workers to notify them of a potential condition(s) that could impact the client and / or Worker. Alerts are differentiated from notifications by the urgency and potential impact of their messages. In this use case, the Public, Client or Worker receives alerts and notifications within a set of predefined parameters. The Worker has access rights to System to perform the action described. Trigger Events Worker or Client logs into the System Worker views a specific client s information The System generates additional alerts / notifications while Worker is logged in An event which triggers an alert / notification Pre-Condition User has access rights to the System The Public subscribed to alerts / notifications

162 162 Post-Condition The Public has viewed the alert / notification The Worker has reviewed alerts and notifications in Web portal The Worker has elected to not read the alerts / notifications Use Case Flow 1. The Worker logs into the System 2. Each view of the System displays alerts and notifications in pre-defined places. Alerts / notifications displayed are dependent on the user profile, client consent and access rights a. Alerts / notifications will be prioritized by importance or severity b. If all alerts / notifications are not able to be presented on the screen, the System will provide a summary of the unviewed alerts / notifications and a link to a complete list c. Alert and notifications may include: i. Population-specific alerts / notifications: 1. Public health alerts / notifications 2. Public safety alerts / notifications 3. Natural disaster, severe weather and emergency alerts / notifications 4. Health statistics based on client profile meeting pre-determined thresholds ii. Client-specific alerts / notifications such as: 1. Appointment notifications 2. Referral notifications 3. Renewal notifications 4. Appeal notifications 5. Grievance notifications 6. Benefit recovery notifications 7. Public safety and justice alerts / notifications 8. Worker safety precautions related to client 9. Consent expiration 10. Re-determination or eligibility alerts / notifications of new messages received from other collaborating providers 11. Resources available to client based on locale 12. Other notifications that may require future integration to other systems to generate, such as

163 163 a. Medication recalls b. Duplicate therapy warnings c. Drug seeking behaviors 3. The Client or Worker selects an alert / notification from the list 4. The System displays the detailed content of the alert / notification a. The alert / notification may include hyperlinks or references that allow the Worker to access additional information b. The alert / notification includes a method to print the alert / notification in a clientconsumable format 5. The System saves a record that the Worker has viewed, dismissed or ignored the notification Associations with Other Use Cases Set up Alert and Notification Rules Alternative Flows If the Public has subscribed to an alert / notification, the alert / notification is delivered based on the method they selected (e.g. , SMS, RSS, etc) If the alert / notification is available on a website accessible to the Public, it may be viewed on the website Additional Requirements For certain client-specific alerts, the System shall prompt the Worker to indicate what action has been taken The System shall allow the managers, supervisors and the Worker to customize or prioritize alerts for themselves or their teams The System shall allow the Worker to view the age of alerts and notifications The System shall allow managers and supervisors to view pending / unread alerts / notifications of their team as defined by Vermont policy The System shall enable multiple ways to deliver alerts and notifications including , SMS, RSS, pop-ups and others The System shall support notifications and letters in multiple formats, to include mail, text, and automated voice messages The System shall allow the Public to subscribe to alerts / notifications The System shall support automated renewal notification The System shall be able to make outbound calls and/or send s to notify employers The System shall support an appeals process with notifications

164 UC-25: Search for and View Service Provider Actors Worker The Worker is an employee of a department and/or agency in Vermont or of a contracted entity who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this System, as well as any contractor. This role may also be fulfilled by: Client The Client is a recipient of benefits or services from the State and/or its contractors. This role may also be filled by an Authorized Representative that has been granted access to the Client s account. Public The Public is anyone that has access to the Internet that wishes to view information without an account. Purpose and Objectives Referring parties, clients and the public may wish to find a service provider that offers services meeting specific criteria including proximity to them, services offered, capacity to accept new clients and others. A service provider, in this context, could range the span of definitions to ensure that clients are able to find the assistance they are seeking. Service providers are envisioned to include at least individual providers (e.g. doctors), programs (e.g. after school programs) and service entities (e.g. hospitals and YMCAs). The System will manage information about service providers through the Master Provider Index as well as integration to other resources. Directories that have been identified for possible integration include: and Aging & Disabilities Resource Centers (ADRC) which uses the "REFER" database, and others. To the extent possible, any integration will be accomplished through national standards. A Worker may fulfill various roles and depending on the role, the information viewable and actions required will differ. Therefore, the Worker may see different information and have different actions required based on the access rights of that role. The public, for example, may only be able to see the address of the service provider and services offered while other providers may be able to see credentialing information and be able to message the service provider. In this use case, the Worker searches for a service provider in the System. Trigger Events The Worker would like to find information about a service provider known to the Master Provider Index or other integrated resource directories Pre-Condition The Worker has access to the Internet

165 165 If requesting detailed information about the service provider, the Worker has access rights to do so Post-Condition The Worker has identified a service provider known to the system or integrated system The Worker is able to view information about that service provider The Worker is informed that there are no service providers that match the query parameters Use Case Flow 1. The Worker navigates to the Provider Search page on the public-facing portal. a. If the Worker has an account and logs into the Web portal and navigates to the Provider Search page. 2. The System displays a step-by-step form with sorting and filtering capabilities: a. Search and filtering criteria may include: i. Program category / group ii. Program name iii. Agency / department iv. Provider name v. Affiliated service entity vi. Gender vii. Service zip code(s) viii. License(s) 1. search result by proximity to an entered address or zip code ix. Capacity (e.g. accepting new clients) x. Services provided (e.g. a service catalogue) xi. Population served (e.g. children, abused women, medical needs, special conditions/chronic diseases, etc.) xii. Proximity to public transportation xiii. Languages spoken xiv. Populations served xv. Priority service (this is based on urgency and preference of specific programs such as prenatal testing for a substance abuser who is pregnant) 3. The Worker enters some or all of the requested information into the System and submits the form.

166 The System searches the Master Provider Index and any integrated resource directories for records that match the search parameters. a. Integrated resource directories may include: i directories ii. Aging & Disabilities Resource Centers (ADRC) which uses the "REFER" database 5. The System displays the service entity(ies) that match the search parameter(s) a. If multiple matches are found, the System shall allow the Worker to enter additional search parameters and repeat steps 3 and 4 with filtering intelligence and advanced search capabilities b. If no service providers match the search parameter(s), the System notifies the Worker and displays suggestions based on entered criteria for broadening the search c. The System allows the Worker to print the list displayed 6. The Worker selects a single service provider and views additional details about the service provider a. Information displayed may include: i. Program category / group ii. Program name iii. Agency / department iv. Provider name v. Affiliated service entity vi. Gender vii. Service zip code(s) viii. License(s) ix. Capacity (i.e. accepting new clients) x. Services provided (e.g. an Agency-standardized service catalogue) xi. Population served (e.g. children, abused women, medical needs, special conditions/chronic diseases, etc.) xii. Proximity to public transportation xiii. Languages spoken xiv. Populations served xv. Priority service (this is based on urgency and preference of specific programs such as prenatal testing for a substance abuser who is pregnant) b. The System allows the Worker to print the listing displayed c. The System allows the Worker to map directions to one of the service addresses by various transportation methods

167 167 d. If allowed by Worker rights, the system allows the Worker to send a message to the service provider (see Send Secure Message use case) e. The System allows the Worker to return to the latest point of the search results after viewing the service provider profile 7. The Worker backs out of the Provider Search function Associations with Other Use Cases Send Secure Message Create Referral to Service / Program Alternative Flow If a Provider is not found, authorized Workers may create a new record for the Provider in the MPI Additional Requirements The System shall allow searches based on: Partial text search Phonetic search Value ranges

168 UC-26: Manage Caseload Actors Worker The Worker is an employee of a department and/or agency in Vermont or of a contracted entity who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this System, as well as any contractor. Client The Client is a recipient of benefits or services from the State of Vermont and/or its contractor. Applicant The Applicant is a client that wishes to apply for services for themselves and/or their family. The person for whom the Authorized Representative is applying for benefits on behalf of. Purpose and Objectives In this context, caseload management is the assignment of work to the appropriate resources for completion. Case is defined as a various stage of client record such as application, referral, and inquiry going through integrated eligibility process. Three high level patterns for caseload management are identified below. As the model of practice for Vermont evolves, some or all of these patterns may be in use to help direct work to the correct resources. The three patterns include: 1. Automatic Routing to Queue Cases are automatically routed to queues based on a set of pre-defined rules. Cases from the queues are assigned to individual Workers manually by a supervisor or the Workers themselves. 2. Automatic Routing to Worker Cases are automatically routed to a specific Worker based on a set of pre-defined rules. These rules may be based on a Worker s role, a Worker s set of assigned Clients or other heuristic. The majority of cases will be assigned to workers on task basis using pre-defined rules including but not limited to geography, program, skill set, and the maximum number of cases per worker. For certain program and cases, a case can be assigned to a single worker throughout the life of the case (e.g. Eligibility determination) 3. Manual Routing Cases are manually assigned to the appropriate queue or Worker after a Worker triages the request to determine where it belongs. In this use case, a case is routed to the appropriate Worker or queue so a Worker may complete the required actions. The Worker has appropriate access rights to the System to perform the action described. Trigger Events The System or a Worker identifies the need for manual intervention to complete the required activity

169 169 Pre-Condition The System, Client, Worker or other attempts to complete an activity Post-Condition The case is routed to the appropriate Worker or queue Use Case Flow 1. If Automatic Routing to Queue is employed, the System automatically routes the case to the correct queue based on a set of pre-defined rules. a. A Worker subsequently assigns the case to an appropriate Worker. 2. If Automatic Routing to Worker is employed, the System automatically routes the case to the correct Worker based on a set of pre-defined rules. 3. If Manual Routing is employed, the System automatically routes all cases to a central queue where a Worker performs initial triage and manually routes the case to the appropriate queue or Worker. 4. The Worker to whom the case is assigned completes the required action if they are able. Actions the Worker may take include, but are not limited to: a. Assist Applicant with application for benefits (see Complete Self-Service Integrated Application, Submit Additional Information for Application, Process Application, Determine Spenddown and Submit Expenses use cases) b. View/Update Client record (see Search for Client and View Client Information Staff use cases) c. Log/read shared case notes (see Record Shared Case Note and Read Shared Case Note use cases) d. Send/read secure message (see Send Secure Message and Read Secure Message use cases) e. Others 5. If additional actions are required and the current Worker is unable to complete, the case is re-routed. Go to step 1 Association with Other Use Cases Complete Self-Service Integrated Application Submit Additional Information for Application Process Application Determine Spenddown and Submit Expenses Search for Client View Client Information Record Shared Case Note Read Shared Case Note Send Secure Message Read Secure Message

170 170 Alternate Flows None Additional Requirements The System shall support a method to create individual case plans. The System will identify an Applicant / Client across multiple cases for benefits. The System shall support a method to assign service providers to case plans. The System shall support a method of voiding simultaneous updates of case data.

171 UC-27: Create Referral to Service / Program Actors Referring Party (sender of a referral) The Referring Party is any Worker or contractor provider who provides services directly to a client and has the appropriate rights to make a referral. This may include a case worker or a similar person who is providing and/or coordinating services. Receiving Party (recipient of a referral) The Receiving Party is any Worker, contractor, program or entity who may provide services directly to a client. This may include a case worker or a similar person who is providing and/or coordinating services. Purpose and Objectives The Referring Party, in collaboration and coordination with the client, may decide that it is in the best interest of the client to pursue services / programs. Referrals serve many purposes and can range from offering supplemental services or care (receiving services from people or entities) to aiding in the process of receiving services or care (scheduling an interview or assessment) as well as enrolling in a program. The System will enable the management and execution of referrals by providing the capability to look up service providers in Master Provider Index, record a referral and transmit it to a provider. Prior to making a referral the Referring Party will discuss the need for a referral with the client and will obtain consent, if needed (see Record Client Consent Use Case; Consent may not be required in all instances as determined by Vermont policy). The consent will allow execution of the referral, receipt of the referral by the Receiving Party and viewing of the client record in preparation for the appointment. The referral may contain the following content: Source of the referral (program, referring party, date and time of the referral) Client information (based on existing information in the System) Service / program requested (if referral is part of eligibility determination) Recipient of the referral (must be a provider who is in the System master provider index) Reason for the referral Type of client referral (e.g. mandated, voluntary) Type of provider referral (e.g. required, voluntary) Referral urgency (e.g. Standard or Immediate / Urgent ) Based upon the consent provided, the request for feedback may include: Acknowledgment of receipt of the referral by the Receiving Party Acceptance / denial of the referral by the Receiving Party Notification of client contact and appointment date Notification of client attendance at appointment In this use case, the Referring Party enters a referral in the System.

172 172 Trigger Events In the course of providing services, the Referring Party would like to refer the client to another service provider In the eligibility determination process, a referral is required in order to conduct an assessment for the client Pre-Condition The client has an active record in the System The client consent is recorded in the Consent Registry Agency and providers are participants of the System Post-Condition The referral is recorded in the System and sent to the Receiving Party Use Case Flow 1. The Referring Party logs into the System, searches for the client and initiates a referral a. The System displays a form for the Referring Party to initiate a referral b. The System pre-populates the form with information of the Referring Party based on the profile of the user logged into the Web portal, including the following: i. Date and time of the referral ii. First and Last Name iii. Title (e.g. RN, MD) iv. Organization v. Program vi. Contact information ( , phone, etc.) vii. Case manager name (if different from person entering referral) c. The System pre-populates the form with information of the client being referred, including: i. First and last name ii. Date of birth iii. Language iv. Mobility / disability (if important to referral) v. Client residential address vi. Contact information ( , phone, etc.) vii. Last four digits of Social Security Number or unique client identifier viii. Program

173 173 ix. Client restrictions / preferences (as indicated in the client profile): 1. Availability 2. Best time to contact 3. Preferred method to contact (phone, , text) 4. Communication restrictions (specify) 2. The Referring Party then selects a program / service to which the client is being referred to from a list 3. The Referring Party searches for and locates a Receiving Party or Parties based on client s preferences and services required a. The Referring Party searches for a Receiving Party using any combination of the following filters: i. Services provided (e.g. an Agency-standardized service catalogue) ii. Providers capacity (are they accepting new patients?) 1. Accepting new patients in specific service areas (practice scope and conditions e.g. court orders) iii. Proximity to the client s residential address iv. Proximity to public transportation v. Languages spoken vi. Disability access vii. Priority service (this is based on urgency and preference of specific programs such as prenatal testing for a substance abuser who is pregnant) viii. Population served (e.g. children, abused women, medical needs, special conditions/chronic diseases, etc.) b. The System displays a list of Receiving Parties who meet the criteria c. The System only displays qualified Receiving Parties based on Referring Party s criteria d. If the list of suggested providers is too long, the Referring Party may further refine the criteria e. If the Receiving Party is in the Master Provider Index, the System pre-populates the information for the Receiving Party f. If the Receiving Party is not in the Vermont Master Provider Index, the System allows the Referring Party to enter information about the Receiving Party i. Referrals sent outside the System will be tracked and recorded as comprehensively as possible g. If the Referring Party would like to send the referral to multiple providers the System provides the ability to select one/more/all of the listed Receiving Parties 4. The Referring Party discusses the available options with the client and selects a provider from the list

174 The Referring Party records additional information about the referral a. Configurable and changeable elements include at least: i. Client referral type: 1. Mandated: Referrals that are required as part of incarceration, parole or other State/Federal-required arrangements 2. Voluntary: Referrals that are optional for the client to accept or deny ii. Provider referral type: 1. Required: Referrals that a Receiving Party is required to accept due to contractual arrangements with the State a. Response requested is Acknowledgement 2. Optional: Referrals that a Receiving Party can accept/deny at their discretion a. Response options include Accept and Deny iii. Response notification requested (yes/no) iv. Referral condition: 1. New referral 2. Renewal 3. Change provider or location of service v. Reason for referral - may include, but are not limited to: 1. Assessment / initial evaluation for other services 2. Service delivery (such as the client's primary care provider) 3. Prior authorization requirement 4. Client relocation vi. Referral urgency: 1. Standard 2. Immediate / Urgent vii. Time in which response is required in viii. Notes ix. Attached documents b. Defaults for referral settings may be set based on user / referral types 6. The Referring Party reviews the referral information entered and, if requested, will print and/or a copy of the referral for the client 7. The System sends notifications to Receiving Party(ies), workers and clients indicating a referral was created, such as the client s primary care provider

175 175 Associations with Other Use Cases Record Client Consent Modify or Withdraw Referral Acknowledge Referral Accept Referral Change Referral Status Send Referral Notification View / Change Referral Status Conduct Screening or Assessment (if prior assessment or authorization is required) Alternative Flows If the Receiving Party is not known to the System, the Worker may send an or postal message with the referral information These referrals will be tracked as comprehensively as possible Additional Requirements The System shall maintain a referral history including issuance, changes, withdrawals, and acceptances / denials / acknowledgements The System shall track attributes of providers (e.g. Probation approved, public health approved) The System shall have the ability to link to Community Service Directories (including and Aging & Disabilities Resource Centers [ADRC] which uses the "REFER" database) The System shall use a widely used standard/taxonomy (e.g. AIRS) The System shall have the ability to store information about providers in a central repository. Information would include, but is not limited to: Contact information (multiple addresses) Contracts Certification Notifications shall be sent based on the preference indicated in the user profile. Methods may include , SMS, postal mail or others. Notifications will be sent electronically where possible understanding that the option for postal mail notifications may be required by policy and/or law, or may be the only option.

176 UC-28: Modify or Withdraw Referral Actors Referring Party (sender of a referral) The Referring Party is any State worker or contractor who is providing services directly to a client and has the appropriate rights to make a referral. This may include a case worker or a similar person who is providing and/or coordinating services. Receiving Party (recipient of a referral) The Receiving Party is any State worker, contractor, program or entity who may provide services directly to a client. This may include a case worker or a similar person who is providing and/or coordinating services. Purpose and Objectives The Referring Party may need to augment existing referrals with additional information or withdraw referrals that have not yet been acknowledged or accepted by the Receiving Party. Referrals serve many purposes and can range from offering supplemental services or care (receiving services from people or entities) to aiding in the process of receiving services or care (scheduling an interview or assessment) as well as enrolling in a program. In this use case, the Referring Party modifies or withdraws a referral in the System. Trigger Events Referring Party wants to modify or withdraw referral Pre-Condition A referral exists for the client Post-Condition The Referring Party has modified or withdrawn the referral Use Case Flow 1. The Referring Party accesses the System to view a list of recent referrals 2. The System displays a list of referrals a. For each referral, the System presents the following summary information: i. Date and time of the referral ii. Referring Party name / entity iii. Client name iv. Service / program requested v. Referral urgency: 1. Standard 2. Immediate / Urgent

177 177 vi. Referral status 3. The Referring Party selects a referral and reviews the referral containing the following: a. Date and time of the referral b. Referring Party information c. Client information d. Service / program requested e. Client referral type: i. Mandatory: Referrals that are required as part of incarceration, parole or other State/Federal-required arrangements ii. Voluntary: Referrals that are optional for the client to accept or deny f. Provider referral type: i. Required: Referrals that a Receiving Party is required to accept due to contractual arrangements with the State 1. Response requested is Acknowledgement ii. Optional: Referrals that a Receiving Party can accept/deny at their discretion 1. Response options include Accept and Deny g. Response notification requested (yes/no) h. Referral condition i. New referral ii. Renewal iii. Change provider or location of service i. Reason for referral - may include, but are not limited to: i. Assessment / initial evaluation for other services ii. Service delivery iii. Prior authorization requirement iv. Client relocation j. Referral urgency i. Standard ii. Immediate / Urgent k. Time in which response is required l. Referral status m. Referral age n. Notes o. Attached documents p. Referral history (log of changes to referral date / time, user, change made)

178 The Referring Party selects the desired referral from the list to review, augment or withdraw the referral 5. The Referring Party updates the referral a. The System allows the Referring Party to edit any information on the referral b. The System allows the Referring Party to withdraw a referral that has not yet been acknowledged by the Receiving Party c. The System allows the Referring Party to withdraw a referral that has not yet been accepted by the Receiving Party 6. If the referral has been withdrawn, the Referring Party may re-submit the referral to a Receiving Provider (see Create Referral to Service / Program use case for more details) a. If the Referring Party decides not to re-submit the referral to a new provider, the System shall prompt the provider to indicate a reason for the withdrawal. 7. The Referring Party confirms the modifications to the referral in the System and the System will update the referral a. The System tracks all modifications to the referral, including: i. Author of the change ii. Date and time of the change Associations with Other Use Cases Record Client Consent Create Referral to Service / Program Alternative Flows If the Receiving Party is not known to the System, the Receiving Party may send an or postal message with the modified / changed referral information. These referrals will be tracked as comprehensively as possible Additional Requirements The System shall maintain a referral history including issuance, changes, withdrawals, and acceptances / denials / acknowledgements The System shall allow a user to search, sort and filter referrals

179 UC-29: Acknowledge Referral Actors Referring Party (sender of a referral) The Referring Party is any State worker or contractor who is providing services directly to a client and has the appropriate rights to make a referral. This may include a case worker or a similar person who is providing and/or coordinating services. Receiving Party (recipient of a referral) The Receiving Party is any State worker, contractor, program or entity who may provide services directly to a client. This may include a case worker or a similar person who is providing and/or coordinating services. Purpose and Objectives Once a referral has been executed, the Receiving Party must acknowledge the receipt of the referral, if requested. The System allows the Referring Party to track status and receive notifications about a referral s receipt and acceptance by the Receiving Party. In this use case, the Receiving Party acknowledges the referral in the Web portal. Trigger Events Receiving Party has received a referral Pre-Condition The Referring Party has executed a referral in the System The Referring Party has requested a notification upon acknowledgement of the referral Post-Condition The Receiving Party has acknowledged receipt of the referral in the System The Referring Party has received a notification indicating the referral status Use Case Flow 1. Receiving Party logs into the Web portal to view a list of recent referrals 2. The System displays a list of recent referrals a. For each referral, the System presents the following summary information: i. Date and time of the referral ii. Referring Party name / entity iii. Client name iv. Service / program requested v. Referral urgency:

180 Standard 2. Immediate / Urgent vi. Referral status 3. The Receiving Party selects a referral and reviews the referral containing the following: a. Date and time of the referral b. Referring Party information c. Client information d. Service / program requested e. Client referral type: i. Mandated: Referrals that are required as part of incarceration, parole or other State/Federal-required arrangements ii. Voluntary: Referrals that are optional for the client to accept or deny f. Provider referral type: i. Required: Referrals that a Receiving Party is required to accept due to contractual arrangements with the State 1. Response requested is Acknowledgement ii. Optional: Referrals that a Receiving Party can accept/deny at their discretion 1. Response options include Accept and Deny iii. Response notification requested (yes/no) g. Referral condition i. New referral ii. Renewal iii. Change provider or location of service h. Reason for referral, may include but are not limited to: i. Assessment / initial evaluation for other services ii. Service delivery iii. Prior authorization requirement iv. Client relocation i. Referral urgency i. Standard ii. Immediate / Urgent j. Time in which response is required k. Referral status l. Referral age m. Notes

181 181 n. Attached documents o. Referral history including issuance, changes, withdrawals, and acceptances / denials / acknowledgements (the system will keep a log of changes to referral date / time, user, change made) 4. The Receiving Party chooses the desired referral and selects the Acknowledge Referral option a. The System provides a structured form for the Receiving Party to acknowledge the referral b. The System pre-populates the form with information of the Receiving Party based on the profile of the user logged into the Web portal, including the following: i. Date and time of the acknowledgement ii. First and Last name of the Receiving Party iii. Name of Receiving Organization iv. Contact information ( , phone, etc.) v. Program vi. Case manager name (if different from person making referral) c. The System allows the Receiving Party to enter free text notes to request additional information or otherwise communicate with the Referring Party d. The System allows the Receiving Party to attach files to the acknowledgment 5. The Receiving Party submits their acknowledgment a. The System allows the user to print the referral b. The System stores the referral acknowledgement c. The System sends a notification to the referring party and/or client indicating the referral was acknowledged Associations with Other Use Cases Record Client Consent Create Referral to Service / Program Modify or Withdraw Referral Accept Referral Change Referral Status Send Referral Notification View / Change Referral Status

182 182 Alternative Flows If the Receiving Party prefers to directly accept the referral without going through the acknowledgment step, then the provider will invoke the Accept Referral use case If the Referring Party has not indicated a desire to receive a notification, the System shall store the acknowledgment of the referral without notifying the Referring Party. The Referring Party may look up the status of the referral at any time (see View /Change Referral Status use case) Additional Requirements Notifications shall be sent based on the preference indicated in the user profile. Methods may include , SMS, postal mail or others. Where possible, electronic delivery methods will be selected over the more expensive postal mail delivery method providing the State is not legally mandated to send notifications via postal mail

183 UC-30: Accept or Deny Referral Actors Referring Party (sender of a referral) The Referring Party is any State worker or contractor who is providing services directly to a client and has the appropriate rights to make a referral. This may include a case worker or a similar person who is providing and/or coordinating services. Receiving Party (recipient of a referral) The Receiving Party is any State worker, contractor, program or entity who may provide services directly to a client. This may include a case worker or a similar person who is providing and/or coordinating services. Purpose and Objectives Once a referral has been executed, the Receiving Party will acknowledge receipt, if requested to. The Receiving Party must then either accept or deny the referral. The System allows the Referring Party to track referral status and receive notifications about a referral s receipt and acceptance by the Receiving Party. In this use case, the Receiving Party accepts (or denies) the referral in the Web portal and the System notifies the Referring Party. Trigger Events Receiving Party has received a referral from a Referring Party Pre-Condition Client consent is on file Referring Party has executed a referral in the System Referring Party has requested a notification of the referral acceptance or denial. Post-Condition The Receiving Party has accepted or denied the referral in the System The Referring Party has received a notification indicating the referral status Use Case Flow 1. The Receiving Party receives a notification of a new referral in the System 2. The Receiving Party logs into the Web portal to view a list of recent referrals 3. The System displays a list of recent referrals a. For each referral, the System presents the following summary information: i. Date and time of the referral ii. Referring Party name / entity

184 184 iii. Client name iv. Service / program requested v. Referral urgency: 1. Standard 2. Immediate / Urgent vi. Referral status 4. The Receiving Party selects a referral and reviews the referral containing the following: a. Date and time of the referral b. Referring Party information c. Client information d. Service / program requested e. Client referral type i. Mandated: Referrals that are required as part of incarceration, parole or other State/Federal-required arrangements ii. Voluntary: Referrals that are optional for the client to accept or deny f. Provider referral type: i. Required: Referrals that a Receiving Party is required to accept due to contractual arrangements with the State 1. Response requested is Acknowledgement ii. Optional: Referrals that a Receiving Party can accept/deny at their discretion 1. Response options include Accept and Deny iii. Response notification requested (yes/no) g. Referral condition i. New referral ii. Renewal iii. Change provider or location of service h. Reason for referral, may include but are not limited to: i. Assessment / initial evaluation for other services ii. Service delivery iii. Prior authorization requirement iv. Client relocation i. Referral urgency i. Standard ii. Immediate / Urgent j. Time in which response is required

185 185 k. Referral status l. Referral age m. Notes n. Attached documents o. Referral history including issuance, changes, withdrawals, and acceptances / denials / acknowledgements (the system will keep a log of changes to referral date / time, user, change made) 5. Upon review of the referral, the Receiving Party selects the Accept Referral or Deny Referral option a. The System provides a structured form for the Receiving Party to record acceptance / denial of the referral b. The System pre-populates the form with information of the receiving party based on the profile of the user logged into the Web portal, including but not limited to the following: i. Acceptance / denial ii. Date and time of the acceptance / denial iii. Name of the Receiving Party iv. Name of receiving organization v. Contact information ( , phone, etc.) vi. Case manager name (if different from person making referral) c. The System allows the Receiving Party to enter free text notes to request additional information or otherwise communicate with the Referring Party d. The System allows the Receiving Party to attach files to the acceptance e. The System allows the Receiving Party to indicate whether contact with client was made or an appointment was scheduled, including the date of the appointment 6. The Receiving Party reviews and submits their acceptance / denial a. The System allows the user to print and/or the referral b. The System stores the referral response details c. The System sends a notification to the Referring Party and / or client indicating the new status of the referral Association with Other Use Cases Record Client Consent Create Referral to Service / Program Modify or Withdraw Referral Acknowledge Referral Change Referral Status

186 186 Send Referral Notification View / Change Referral Status Alternative Flows If the Receiving Party denies the referral, the System prompts the Receiving Party to indicate a reason for the denial (both by selecting a reason code from a list and providing additional free text comments if required). Reasons may include: Erroneous referral (e.g. wrong worker, provider, service, program, etc.) Provider has no capacity Unable to contact client Other reason If the Referring Party has not indicated a desire to receive a notification, the System stores the denial of the referral without notifying the Referring Party. The Referring Party may look up the status of the referral at any time (see View / Change Referral Status use case) Additional Requirements Notifications shall be sent based on the preference indicated in the user profile. Methods may include , SMS, postal mail or others. Where possible, electronic delivery methods will be selected over the more expensive postal mail delivery method providing the State is not legally mandated to send notifications via postal mail

187 UC-31: View / Change Referral Status Actors Referring Party (sender of a referral) The Referring Party is any State worker or contractor who is providing services directly to a client and has the appropriate rights to make a referral. This may include a case worker or a similar person who is providing and/or coordinating services. Receiving Party (recipient of a referral) The Receiving Party is any State worker, contractor, program or entity who may provide services directly to a client. This may include a case worker or a similar person who is providing and/or coordinating services. Purpose and Objectives With the acceptance of a referral, the process of referral management within the System is complete. Once the referral has been accepted and initial contact with client has been made, the Receiving Party will manage the case in their own Systems and if applicable use the shared notes and messaging capabilities in the System to communicate with collaborating providers. While the status of referrals is not automatically tracked in the System beyond the acknowledgement and acceptance of a referral, the Provider will have the capability to assign additional referral statuses such as: Initial contact with Provider and Client has been made Appointment with client scheduled Initial appointment has occurred In this use case, the Referring / Receiving Party updates or views the status of a referral in the Web portal. Trigger Events Receiving Party wants to update the status of a referral Referring / Receiving Party wants to view the status of a referral Pre-Condition Receiving Party has accepted the referral in the System Post-Condition The Receiving Party has updated the status of a referral The Referring Party has received a notification indicating the referral status Use Case Flow 1. Referring / Receiving Party accesses the System to view a list of recent referrals

188 The System displays a list of referrals a. For each referral, the System presents the following summary information: i. Date and time of the referral ii. Referring Party name / entity iii. Client name iv. Service / program requested v. Referral urgency: 1. Standard 2. Immediate / Urgent vi. Referral status 3. The Referring / Receiving Party selects a referral and reviews the referral containing the following: a. Date and time of the referral b. Referring Party information c. Client information d. Service / program requested e. Client referral type: i. Mandated: Referrals that are required as part of incarceration, parole or other State/Federal-required arrangements ii. Voluntary: Referrals that are optional for the client to accept or deny f. Provider referral type: i. Required: Referrals that a Receiving Party is required to accept due to contractual arrangements with the State 1. Response requested is Acknowledgement ii. Optional: Referrals that a Receiving Party can accept/deny at their discretion 1. Response options include Accept and Deny iii. Response notification requested (yes/no) g. Referral condition i. New referral ii. Renewal iii. Change provider or location of service h. Reason for referral, may include but are not limited to: i. Assessment / initial evaluation for other services ii. Service delivery iii. Prior authorization requirement

189 189 iv. Client relocation i. Referral urgency i. Standard ii. Immediate / Urgent j. Time in which response is required k. Referral status l. Referral age m. Notes n. Attached documents o. Referral history including issuance, changes, withdrawals, and acceptances / denials / acknowledgements (the system will keep a log of changes to referral date / time, user, change made) 4. The Referring / Receiving Party updates the status from the summary or detailed view of the referral a. The System automatically changes the status from New to Pending Acknowledgement once the referral is sent to the Receiving Party b. The System presents the user with a list of statuses based on the lifecycle of the referral request (e.g. If the current status is rejected, the new status cannot be client has made initial contact ) c. The System sends a notification to the Referring Party and / or client with the prior and updated referral status Associations with Other Use Cases Record Client Consent Create Referral to Service / Program Acknowledge Referral Accept Referral View / Change Referral Status Alternative Flows None Additional Requirements Notifications shall be sent based on the preference indicated in the user profile. Methods may include , SMS, postal mail or others. Where possible, electronic delivery methods will be selected over postal mail delivery

190 UC-32: Record Shared Case Note Actors Provider The Provider is any contractor who is providing services directly to a client. This may include a case manager or a similar person who is providing coordinating services. Purpose and Objectives As part of case collaboration, providers will access the System to view client information (see View Client Information use case) and create referrals (see Create Referral to Service / Program use case). Providers will also have the capability to record observations in a shared environment such as a virtual collaborative case record. These notes will be stored in a repository and can be viewed by any collaborating providers who are authorized via the recorded client consent to collaborate on behalf of the client. Multiple shared case notes may be active for a single client and program. Collaboration teams may vary by case note, as needed, according to role-based permissions and client consent. The capability of having shared case notes allows the provider to record and communicate information about a client outside of the current source systems. Shared case notes do not replace existing case management functionality native to a program or service; they augment existing information and provide collaborating providers with additional insights not otherwise available. In this use case, the Provider creates a case note in the System to be read by collaborating providers. Trigger Events The Provider would like to record case notes in the System for sharing with other providers to enable case collaboration Pre-Condition A client has given consent for this Provider to share information on his / her behalf The Provider has logged on to the system and accessed an active client record Post-Condition The Provider has recorded a case note in the System Use Case Flow 1. The Provider selects the Record Shared Case Note option 2. The System displays a form for the Provider to enter a shared case note a. The System pre-populates the form partially based on the Provider logged into the System, including the following: i. Date and time of the note

191 191 ii. First and last name iii. Provider organization iv. Program / service v. Alternate contact and information b. If the Provider is responding to a previous shared note, the System populates the subject line and free text areas with references to the previous notes c. The System presents additional areas for the Provider to complete, including: i. An urgency indicator ii. A subject line iii. Free text areas iv. Attachment of external documents v. References to records located on the system vi. A read request flag that allows collaborating providers to indicate when they have read the note 3. The Provider enters the all required and any optional information 4. Optionally, the Provider may elect to save the note in draft form a. Other providers will not be notified and may not view draft notes 5. The Provider verifies and submits the note a. The System provides the ability to print case notes b. The System stores the case notes in a repository for the time the client has provided consent c. The System provides the capability to search case notes The System notifies other collaborating providers that a new case note has been posted (see View Alerts and Notifications use case) Associations with Other Use Cases Read Shared Case Note View Client Information Create Referral to Service / Program View Alerts and Notifications Alternative Flows None Additional Requirements

192 192 The System shall maintain a history of case notes The System shall provide a method to extract a shared case note that can be imported into a program system The System shall allow the capability to view the case note in the context of the collaborative virtual record The System shall allow the ability to search case notes through a Boolean type search function The system shall allow for the capability for a limited number of users to remove case notes entered in error

193 UC-33: Read Shared Case Note Actors Provider The Provider is any contractor who is providing services directly to a client. This may include a case manager or a similar person who is providing coordinating services. Provider includes both state staff (ESD, DCF, VR, etc.) and community-based providers (Choices for Care, Developmental Services, etc...) that directly coordinate the application and receipt of benefits and basically serve as case managers for these benefits. Purpose and Objectives The Providers may use the Web portal to communicate and coordinate their activities and services with client consent as recorded in the Consent Registry. The System will enable this communication in the form of referrals, shared client notes, and secure messaging between individual providers. Providers will also have the capability to record observations in a shared environment. These notes will be stored in a repository and can be viewed by any authorized provider who collaborates on the case in the system as long as the provider has the proper authorization. In this use case, the Provider reads case notes in the System that were posted by another Provider. Trigger Events The Provider is notified that a shared note was posted and would like to read it The Provider accesses a client record (see View Client Information use case) Pre-Condition The Provider has obtained consent for sharing information on behalf of the client Post-Condition The Provider has accessed and read a shared case note in the system Use Case Flow 1. The Provider logs on to the System and views a list of shared notes that have been received by the Worker account a. If on the landing page, the System shows read and unread case notes that have been posted for all clients for which the Worker has the appropriate rights, need and consent to view b. If in a client s record, the System shows read and unread case notes for that client c. The Provider may choose to order / filter notes by: i. Severity / urgency

194 194 ii. Read / unread status iii. Date iv. Sender v. Client (if in a multi-client screen) 2. The Provider selects a note 3. The System displays the case note, including the following: a. Date and time of the note b. Urgency / priority indication c. First and last name of the Collaborating Provider d. Organization of the Collaborating Provider e. Program / service of the Collaborating Provider f. Other Collaborating Providers the shared note was sent to (if applicable) g. Case note subject line h. Content of the case note i. Attached documents, if any 4. The Provider reads the case note, checks to see if the Collaborating Provider indicated an urgency or priority marking and responds accordingly 5. The receiving Provider may open any attached or referenced records or files 6. Optionally, the Provider may respond to the shared note (see Record Shared Note use case) 7. The receiving Provider closes the note in the system Associations with Other Use Cases Record Shared Note View Client Information Alternative Flows None Additional Requirements The System shall maintain a history of case notes The System has the capability to print case notes The System allows the capability to search case notes through a Boolean type search function

195 UC-34: Send Secure Message Actor Provider The Provider is any contractor who is providing services directly to a client. This may include a case worker or a similar person who is providing coordinating services. Purpose and Objectives Collaborating providers and case workers may need to communicate in order to coordinate their activities and services with client consent as recorded in the Consent Registry. The Web portal will enable this communication in the form of referrals, shared client notes and secure messaging between individual providers. Messaging in the system will comply with security standards required by policy and provide an enhanced alternative to phone, paper or communication, as the messages will be linked to the client record. This will ensure that information exchanged between providers and workers is compliant with the consent provided by the client. It also provides secure storage, the ability to report on messages exchanged and audit records exchanged. Secure messages can be sent from one Provider to another Provider, to a subset of collaborating workers/providers or to all workers/providers working on a case as allowed by client consent. Secure messages will be displayed within the context of a client record in the system. In this use case, the Provider sends a secure message. Trigger Events The Provider wants to communicate with one or more Providers collaborating on a case Precondition The Provider has accessed an active client record Post condition The System has sent a message to another Provider Use Case Flow 1. The Provider accesses a client record in the system and selects the Send Secure Message option a. The Provider views a list of agencies and providers to whom messages can be sent based on: i. Consent provided by the client as recorded in the Consent Registry ii. Workers / providers collaborating on the same case

196 196 b. The Provider may search the list of agencies and providers c. The Provider selects names to include in the secure message 2. The Provider selects one, several or all listed workers/providers based upon the client s consent a. The Provider may request an automated reading confirmation from the Provider receiving the message b. The Provider may use a System-provided form to enter a secure message c. The System pre-populates the form with information based on the profile of the user logged into the Web portal, including the following: i. Name and title of person recording the note ii. Provider organization iii. Program / Service iv. Alternate contact and information v. Client information d. The Provider enters free text case notes if desired 3. The Provider enters a message a. The System allows the Provider to attach electronic supporting documents as files 4. The Provider verifies the messages and submits it in the System 5. The System saves the message in the Web portal and sends notifications to the selected workers / providers Associations with Other Use Cases None Alternative Flows None Additional Requirements The System shall pre-populate the To field with the list of recipients from the previous message that a Provider is responding to. Additional recipients may be added to this list The System, before sending a message, shall validate that recipients of the message are active users within the system in order to prevent errors such as bounce backs and send failures.

197 UC-35: Read Secure Message Actor Provider The Provider is any contractor who is providing services directly to a client. This may include a case worker or a similar person who is providing coordinating services. Purpose and Objectives Collaborating providers and case workers may need to communicate in order to coordinate their activities and services with client consent as recorded in the Consent Registry. The System will enable this communication in the form of secure messaging between individual providers. Messaging in the system will comply with security standards required by policy and provide an enhanced alternative to phone, paper or communication. Querying the Consent Registry upon sending the message will ensure that information exchanged between providers and workers is compliant with the consent provided by the client. It also provides secure storage, the ability to report on messages exchanged and auditing of messages exchanged. Secure messages will be displayed within the context of a client record in the System. In this use case, the Provider receives and reads a secure message using the Web portal. Trigger Events The Provider has received a secure message in the System and wants to read it Pre-Condition The collaborating Provider has opened the System and sees a notice that there is a secure message Post-Condition The collaborating Provider reads a message in the Web portal Use Case Flow 1. The Provider opens the system and sees a notice that a secure message was sent from a collaborating Provider 2. The collaborating Provider opens the secure message a. The System displays: i. Name and title of person who sent the note ii. Provider organization iii. Program / service iv. Content of the message v. Attached documents

198 198 vi. Alternate contact and information b. If the option was chosen upon sending, the System sends an automated confirmation message to the originator of the message that the secure message was read 3. The collaborating Provider opens and reads the attached documents and files 4. The collaborating Provider replies to the message if desired. a. See Send Secure Message use case Associations with Other Use Cases Send Secure Message Alternative Flows None Additional Requirements None

199 UC-36: Make Program Activity Assignment Actors Client The Client is a recipient of benefits or services from the State and purchase of service providers. Provider The Worker is any worker or purchase of service provider who is providing services directly to a client. This may include a case manager or a similar person who is providing coordinating services. Case Worker The Case Worker is a State employee or purchase of service provider that has access to the System and the appropriate rights to perform the action described. Purpose and Objectives Work Programs provide an opportunity for clients to obtain work experience or develop additional skills needed for self-sufficiency. Providers participate in program activities by offering opportunities for clients to develop on the job experience and training. The Provider receives free labor and the Client receives the work experience they need to become self-sufficient. Program activity assignments also include educational opportunities to develop skills in a formal classroom setting. Clients are assessed to determine their current capabilities as well as skills that need further development and refinement. Assignments are made based on assessment results as well as other information such as the required number of hours for their assignment and type of assignment (core vs. non-core). Core assignments include direct work experience while noncore assignments may include additional education or training. Core work activities may include: 1. Unsubsidized employment 2. Subsidized private sector employment 3. Subsidized public sector employment 4. Work Experience Program (WEP) 5. On-the-Job Training 6. Job search and job readiness assistance 7. Community service 8. Vocational educational training 9. Providing childcare services to an individual who is participating in a community service program. Non-core work activities may include: 1. Job skills training directly related to employment 2. Education directly related to employment, in the case of a recipient who has not received a high school diploma or a certificate of high school equivalency 3. Satisfactory attendance at secondary school or in a course of study leading to a certificate of general equivalence, in the case of a recipient who has not completed secondary school or received such a certificate

200 200 In this use case, an Eligibility Worker identifies and makes a work program assignment for the Client. Trigger Events Client enrolls in a Program Activity Pre-Condition Client enrolls in a Program Activity Post-Condition Client deemed exempt Client assigned to one or more work assignments Use Case Flow 1. The Case Worker logs in to the System and searches for the Client record 2. Once the record is located, the Case Worker is able to see at least the following: a. Verified activity hours b. Scheduled activity hours c. Past Client timesheets d. Alerts and notifications associated with activities e. Barriers and challenges f. Past assessments g. Case plans 3. The Case Worker selects the Activity Assignment option a. Optionally, the System recommends a work assignment (core vs. non-core) and the number of hours based on the completed Client assessment b. Optionally, the Case Worker conducts a search to identify appropriate assignments. 4. The Case Worker may search for work assignments or refine recommended assignments based on the following information: a. Worker b. Type of work c. Number of hours d. Skills required

201 201 e. Skills to be developed f. Location g. Start date h. End date 5. The Case Worker selects a work assignment 6. The System updates the Client s record with the new activity assignment and marks the assignment as unavailable so it will not be open to other clients 7. The System sends a notification to the Client to confirm the activity assignment. The notification may include, but is not limited to: a. Provider name b. Provider location c. Assignment name d. Start date e. End date 8. The System sends a notification to the Provider to confirm the activity assignment. The notification may include, but is not limited to: a. Client name b. Client contact information c. Start date 9. If desired, the Case Worker or Provider may create a work schedule detailing the working days and hours 10. If additional work allowance or other assistance is provided, the Case Worker updates the system with the benefits issued (see Issue and Track Benefits use case) 11. If multiple assignments are required, repeat these steps as needed Association with Other Use Cases Track Time for Program Activity Assignment Appeal Decision Alternate Flows None Additional Requirements None

202 UC-37: Track Time for Activity Assignment Actors Client The Client is a recipient of benefits or services from the State and purchase of service providers. Provider The Worker is any worker or purchase of service provider who is providing services directly to a client. This may include a case manager or a similar person who is providing coordinating services. Case Worker The Eligibility Worker is a State employee or purchase of service provider that has access to the System and the appropriate rights to perform the action described. Purpose and Objectives Programs activities provide an opportunity for the Client to obtain work experience or develop additional skills needed for self-sufficiency. Providers participate in work programs by offering opportunities for clients to develop on the job experience and training. The Provider receives free labor and the clients receive the work experience they need to become self-sufficient. Work Program assignments also include educational opportunities to develop skills in a formal classroom setting. Each Provider is required to report on the hours a Client works or misses in a given month. For education-based assignments, Providers report on enrollment, attendance and graduation. In this use case, a Provider or Case Worker submits a Client s timesheet (or updates enrollment or attendance status) for a work assignment. Trigger Events Time/attendance reporting is due Enrollment or graduation occurs or is expected Pre-Condition Client begins or continues a work assignment Provider has an account with access to the required functionality Post-Condition Hours worked or missed are reported Notifications are sent Use Case Flow 1. The Case Worker or Provider logs in to the System and searches for the Client record

203 203 a. Once the record is located, the Case Worker selects the Activity Assignment option b. The Case Worker updates the record with changes to enrollment status or attendance c. A notification is sent to the Client indicating whether or not the bonus was earned d. If a bonus was earned, the System issues the benefit (see Issue and Track Benefits use case) e. Go to End 2. The System sends a reminder notification for timesheets to each Provider with an active work assignment 3. The Provider logs in to the self-service portal 4. The Provider selects the Activity Assignment option and records the hours worked / missed for each Client. The Provider also enters any relevant comments 5. The System sends a confirmation to the Provider indicating the successful submission of the timesheet(s) Association with Other Use Cases Make Program Activity Assignment Appeal Decision Issue and Track Benefits View Alerts / Notifications Alternate Flows If the Worker does not enter the timesheet by the due date, an Case Worker may update the Client s timesheet If the Client missed hours, they may provide good cause and make up the hours missed If a sanction is applied due to missed hours, a notification is sent to the Client informing them of the action taken and the Fair Hearing Rights If the Client does not comply with the sanction, benefits are revoked and a new application for benefits is required If the Client does comply with the sanction, benefits are re-instated at the end of the sanction period when the compliance form is signed Additional Requirements The System shall capture a Client s electronic signature on a Compliance Form (form used when Client completes required activities within the sanction period)

204 UC-38: Access and View Dashboard Actors Worker The Worker is an employee of a department and/or agency in Vermont or of a contractor who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this Solution, as well as any contractor. Public The Public is anyone that has access to the Internet that wishes to view information without an account. Purpose and Objectives The System will have the capability to generate and display population, program and clientbased dashboards. The information compiled on these reports will come from various source Systems across AHS programs as well as the System business intelligence environment. A subset of dashboards summarizing de-identified data or other aspects of program performance will be available to the Public upon approval by the State. The dashboards will provide users with an easy way to view essential information related to program and service delivery categories, individual clients, client 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 Client profile Availability of business intelligence and analytics capability Population and program-based dashboard reports can be accessed without selecting a specific client 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/pdd)

205 205 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 Living arrangements Defined program and service category process and outcome objectives Program and collaboration caseload information Number of cases by program, status (Pending/Active/Suspended/Terminated) Number of cases pending or suspended by reason Number of Applicants/Clients denied by reason Number of Applicants identified eligible for Exchange-based coverage Timeliness of eligibility determination Delay by reason Number disenrolled Clients 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

206 206 Data quality System performance Cost / efficiency Fraud, waste and abuse detection and recovery Level of utilization Other outcome-based reports Client centric dashboards will provide information on how a specific client relates to the overall characteristics of his or her population. To view client centric dashboards, users must first access a client record. The client centric dashboards require consent. Examples of information that users may want to access through a dashboard include: Client s age related to the average client population age and overall population age. Client s program participation compared to client population participation and overall population participation. Client s income compared to client population median income and overall population median income. Client s health profile compared to client population profile and overall population profile. Client s risk profile compared to client population profile and overall population profile. Client s health profile compared to health disparity Client s transitioning and re-entering the community from institutions / facilities (e.g. nursing facilities) - Cost information Utilization of programs and services Risk levels In this use case, the Worker or Public accesses and views a dashboard report in the System. Trigger Events The Worker has a desire to access a population or client specific dashboard report The Public has a desire to access a population specific dashboard Pre-Condition The Worker or Public has access to the System Post-Condition The Worker has viewed the dashboard report in the System

207 207 Use Case Flow 1. The Worker logs into the System a. For dashboards accessible by the Public, a log in would not be required 2. The Worker configures the dashboard view preferences based on access rights 3. The Worker or Public selects the list of population centric dashboards a. The System displays different types of reports available. 4. To view client specific dashboards, the Worker accesses a client record and then selects the dashboard. This is not available to the Public 5. The Worker or Public selects a dashboard from the list to view the dashboard a. The Worker or Public may select specific metrics and drill down to more granular reports that provide details about that metric. 6. The Worker or Public can export the data presented in the dashboard in various electronic formats (pdf, xls, csv, etc.) a. The System will allow the Worker or the Public to create a link or reference b. Public can export the data only in pdf Associations with Other Use Cases None Alternative Flows None Additional Requirements The System shall allow the Worker to configure dashboard preferences The System shall allow the Worker to conduct projective and predictive analytics The System shall allow users to subscribe to dashboards The System shall have the capability to include graphics and GIS maps The System shall allow the user to export information presented and underlying information easily with granularity consistent with the user s access rights The System shall allow printing of dashboard The System shall create an auditable list of all users that access reports with the information accessed The System shall provide the ability to suppress data sets with a sample size of zero or a sample size that does not meet the threshold for de-identified/anonymous data The System shall maintain information on the source system for each data element contained on the dashboard/report

208 The System shall allow the User to export the data used to create the dashboard/report in accordance with access rights 208

209 UC-39: Access and View Standard Report Actors Worker The Worker is an employee of a department and/or agency in Vermont or of a contracted entity who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this System, as well as any contractor. Public The Public is anyone that has access to the Internet that wishes to view information without an account. Purpose and Objectives Workers and the Public will have the capability to access reports in the Web portal. Reports will include parameter-based reports users can view and export, but not customize. A parameterbased report has a fixed structure, similar to a standard report, but the data within the report changes based on the parameters or criteria selected. Special requests for one-time-only reports or customized reports and reports of high complexity will continue to be addressed through ad hoc reporting process. Only a subset of Standard and Parameter Based reports will be made available to the Public. Parameters users will be able to specify may include, but are not limited to: Reporting period (last month, last quarter, customized date range, etc.) Claims, denials and benefits received Population characteristics (age range, gender, race / ethnicity, counts, program participation, income level, risk profile, etc.) Provider geography (zip code, county, etc.) League tables / ranking The content and data elements available will be developed at a later point in time. In this use case, the Worker or the Public views a parameter-based report. Note: The intent of this use case is to describe the basic System functionality related to accessing and viewing parameter-based standard reports, not to provide a complete and detailed listing of the report contents or the parameters users can specify. Trigger Events The Worker or the Public would like to access and view a parameter-based report Pre-Condition The Worker or the Public has access to the Web portal Post-Condition

210 210 The Worker or the Public has viewed a parameter-based report in the Web portal Use Case Flow 1. The Worker logs into the System 2. The Worker views the list of parameter-based reports a. The System displays a list of different types of reports available such as, but not limited to: i. Existing reports that are currently generated and published ii. Population centric reports related to the client s profile (demographics, health conditions, geography, etc.) iii. Person centric report for selected individual person or department (requires Worker to be working on an active client record) iv. Etc. 3. The Worker selects a report from the list and specifies the parameters a. The System displays the various parameters for the report, including but not limited to: i. Reporting period (last month, last quarter, customized date range, etc.) ii. Population characteristics (age range, gender, program participation) iii. Provider geography (zip code, region, county, census) iv. Person-based analyses v. Threshold-based and exception reporting (hotspotters) vi. Percent change reporting vii. Etc. b. The System allows users to specify multiple parameters 4. The Worker submits the report parameters 5. The System displays the report Associations with Other Use Cases None Alternative Flows None

211 211 Additional Requirements The System shall have the capability to include graphics and GIS maps in the Standard reports The System shall allow for the capability to sort and filter The System shall allow users to export reports in various formats (pdf, xls, csv, etc.) The System shall allow sending reports to other System participants and distribution lists The System shall allow printing reports The System shall notify users of the estimated time required to run a report if it exceeds a predefined time limit The System shall allow queuing of reports to limit interruption of other System processes The System shall create an auditable list of all users that access reports and which reports they access The System shall provide a mechanism to archive reports in order to prevent a proliferation of reports The System shall provide a mechanism to remove reports in order to prevent a proliferation of reports The System shall allow the user to export information presented and underlying information easily with granularity consistent with the user s access rights The System shall provide the ability to upload a data set (e.g. list of client names) for use as a parameter The System shall provide the ability to suppress data sets with a sample size of zero or a sample size that does not meet the threshold for de-identified/anonymous data If the user is a Worker, the System shall provide the option of saving the report parameters in order to re-run it another time The System shall provide the ability to perform calculations (e.g. unique count, average, etc.) The System shall provide the ability to compare the data from one reporting period to another The System shall provide the ability to identify hotspotters The System shall maintain information on the source system for each data element contained on the dashboard/report

212 UC-40: Access and View Parameter-Based Report Actors Worker The Worker is an employee of a department and/or agency in Vermont or of a contracted entity who participates in the benefit application process or has the need to view the application information for other benefit purposes. Access rights to the System to perform the action described will vary based on the roles assigned to each worker. The definition of Worker covers all State employees that have the rights to perform the described actions for this System, as well as any contractor. Public The Public is anyone that has access to the Internet that wishes to view information without an account. Purpose and Objectives Workers and the Public will have the capability to access reports in the System. Reports will include parameter-based reports users can view and export, but not customize. A parameterbased report has a fixed structure, similar to a standard report, but the data within the report changes based on the parameters or criteria selected. Special requests for one-time-only reports or customized reports and reports of high complexity will continue to be addressed through ad hoc reporting process. Only a subset of Standard and Parameter Based reports will be made available to the Public. Parameters users will be able to specify may include, but are not limited to: Reporting period (last month, last quarter, customized date range, etc.) Claims, denials and benefits received Population characteristics (age range, gender, race / ethnicity, counts, program participation, income level, risk profile, etc.) Geography (zip code, county, etc.) League tables / ranking The content and data elements available will be developed at a later point in time. In this use case, the Worker or the Public views a parameter-based report. Note: The intent of this use case is to describe the basic System functionality related to accessing and viewing parameter-based standard reports, not to provide a complete and detailed listing of the report contents or the parameters users can specify. Trigger Events The Worker or the Public would like to access and view a parameter-based report Pre-Condition The Worker or the Public has access to the Web portal.

213 213 Post-Condition The Worker or the Public has viewed a parameter-based report in the Web portal Use Case Flow 1. The Worker logs into the System 2. The Worker views the list of parameter-based reports a. The System displays a list of different types of reports available such as, but not limited to: i. Existing reports that are currently generated and published ii. iii. iv. Population-centric reports related to the client s profile, including, but not limited to: a. Demographic reports b. Health condition reports c. Geographic-based reports d. Provider reports Person-centric report for selected individual person or department (requires Worker to be working on a client record) Semi-automated person-centric reports that a worker needs to provide to external entities including, but not limited to: a. Benefit verification requests 3. The Worker selects a report from the list and specifies the parameters a. The System displays the various parameters for the report, including but not limited to: i. Reporting period (last month, last quarter, customized date range, etc.) ii. Population characteristics (age range, gender, program participation, estate recovery needs) iii. Geography (zip code, region, county, census) iv. Person-based analyses v. Threshold-based and exception reporting (hotspotters) vi. Percent change reporting vii. Person Identifier(s), for person-centric reports b. The System allows users to specify multiple parameters 4. The Worker submits the report parameters 5. The System displays the report Associations with Other Use Cases

214 214 None Alternative Flows None Additional Requirements The System shall have the capability to include graphics and GIS maps in the Standard reports The System shall allow for the capability to sort and filter The System shall allow users to export reports in various formats (pdf, xls, csv, etc.) The System shall allow sending reports to other Vermont participants and distribution lists The System shall allow printing reports The System shall notify users of the estimated time required to run a report if it exceeds a predefined time limit The System shall allow queuing of reports to limit interruption of other System processes The System shall create an auditable list of all users that access reports and which reports they access The System shall provide a mechanism to archive reports in order to prevent a proliferation of reports The System shall provide a mechanism to remove reports in order to prevent a proliferation of reports The System shall allow the user to export information presented and underlying information easily with granularity consistent with the user s access rights The System shall provide the ability to upload a data set (e.g. list of client names) for use as a parameter The System shall provide the ability to suppress data sets with a sample size of zero or a sample size that does not meet the threshold for de-identified/anonymous data If the user is a Worker, the System shall provide the option of saving the report parameters in order to re-run it another time The System shall provide the ability to perform calculations (e.g. unique count, average, etc.) The System shall provide the ability to compare the data from one reporting period to another The System shall provide the ability to identify hotspotters The System shall maintain information on the source system for each data element contained on the dashboard/report

215 215

216 UC-41: Create Ad Hoc Query And Report Actors Analyst The Analyst is an employee or contractor that has access to the System and the appropriate rights to perform analyses above and beyond accessing standard and parameterized reports. This role will vary in rights and responsibilities based on the individual Analyst and the program(s) they are analyzing. Purpose and Objectives Some authorized Workers will have the capability to create additional cross-program queries and reports in response to needs that are not met by dashboards, standard reports or parameter-based reports (see Access and View Dashboard, Access and View Standard Report and Access and View Parameter-Based Report use cases). The System will provide ad hoc query and reporting access to those with the appropriate access levels to do so, as defined by Vermont policy. This form of query and reporting is the most flexible of the reporting capabilities and may require a wide range of data sources, statistical tools, resource skills and understanding of State and Federal data access policies. Ad hoc queries are one method to define and standardize reports that then can be used in dashboards, standard reports and parameter-based reports. In this use case, the Analyst accesses data sources, creates queries and views a custom report. Trigger Events The Analyst has a need to develop an ad hoc report Pre-Condition The Analyst has access to the System The Analyst has access to advanced query functionality in the System and needed data sources The Analyst has appropriate need and approval to access the queried data sources Post-Condition The Analyst has created a new report in the System Use Case Flow 1. The Analyst logs into the System 2. The Analyst views data sources that are available to him/her a. Data sources may include: i. Data within Vermont assets such as the Master Client Index, Master Provider Index and centralized data stores

217 217 ii. Data within legacy systems that are connected to the System and may be queried from the system iii. Data from other external sources that may be imported for use in the query 3. The Analyst uses tools within the System or external statistical tools to create queries based on the data contained there. Tools range from simple comparing, filtering and sorting across few or many variables organized in hierarchies via the use of statistical tools such as time series analysis and regression to structured predictive models 4. The System displays the report based on the defined queries 5. The System allows the Analyst to save the report for future use a. The System allows the Analyst to specify whether this is a report accessible to others and allows a selection of users or groups of users that can have access to it Associations with Other Use Cases None Alternative Flow None Additional Requirements The System shall allow sandbox and temporary data for use in future queries including mashups with internal and external data The System shall allow different access levels for analyzing versus publishing to allow for different users to perform each function The System shall have the capability to include advanced statistical functionality and sources such as GIS maps The System shall allow users to export reports in various formats (pdf, xls, csv, etc.). The System shall allow sending reports (or links of reports) to other Web portal participants. The System shall allow printing of reports. The System shall notify users of the estimated time required to run a report if it exceeds a predefined time limit The System shall allow queuing of reports to limit interruption of other System processes The System shall create an auditable list of all users that access reports and which reports they access The System shall provide a mechanism to archive reports in order to prevent a proliferation of reports

218 218 The System shall provide a mechanism to remove reports in order to prevent a proliferation of reports The System shall provide the ability to upload a data set (e.g. list of client names) for use within the query The System shall provide the ability to suppress data sets with a sample size of zero or a sample size that does not meet the threshold for de-identified/anonymous data If the user is a Worker, the System shall provide the option of saving the query in order to re-run it another time The System shall provide the ability to identify hotspotters The System shall maintain information on the source system for each data element contained on the dashboard/report The System shall allow the User to export the data used to create the dashboard/report in accordance with access rights The system shall provide the ability to compare data from one reporting period to another

219 UC-42: Setup Alert and Notification Rules Actors Program Administrator A worker responsible for management of the program with rights to change program rules when required by law, mandate or policy changes. A very limited number of individuals will have the ability to perform this role. Purpose and Objectives Alerts and notifications are presented to workers and clients during the course of applying for and delivering services to a client. Some alerts and notifications are presented in real-time, while others are delivered after an event has occurred. To deliver these alerts and notifications the rules behind them must be established and maintained. In this use case, the Program Administrator creates a new rule, changes an existing rule or inactivates an existing rule. Note: For the purposes of these use cases, alerts refer to those messages that have a more pressing time requirement, while notifications are of lesser priority and are less time-sensitive. Trigger Events A Program Administrator wants to setup a new alert / notification rule A Program Administrator wants to change or inactivate an existing alert / notification rule Pre-Condition New notification rule or change to existing rule has been defined and approved Post-Condition A new alert / notification rule is set up or an existing alert / notification rule is changed Use Case Flow 1. The Program Administrator logs into the System 2. The Program Administrator selects the Create New Notification / Alert option 3. The Program Administrator defines the trigger for the alert or notification a. The trigger may be based on any of the following Individually or combined using arithmetic and Boolean logic operators i. Specified thresholds of a criterion / criteria ii. Specified dates / times iii. Specified event iv. Pre-defined indicators

220 The Program Administrator defines the population who will receive the alert / notification a. The System presents criteria for the Program Administrator to select. This list of characteristics includes information including, but not limited to: i. Geography, by county, city, zip code, etc. ii. Services, by agency, program, etc. iii. Provider, by service type, program affiliation, etc. iv. Client demographics, by income, age, race, language, ethnicity, etc. v. Client conditions, by diagnosis, conditions, co-existing conditions, etc. vi. Changes on waitlist or program criteria affecting waitlists b. The System presents information on the expected size and characteristics of the population based on the criteria selected 5. The Program Administrator defines the contents of the alert / notification. The content should include, but is not limited to: a. Alert / notification summary b. Alert / notification details 6. The Program Administrator selects whether or not to receive a notification upon expiration of the alert / notification 7. The Program Administrator defines the delivery method(s). Delivery methods include, but are not limited to: a. AHS platform presentation (screen) b. c. SMS d. Postal mail 8. The system changes the status of the rule to Active or Inactive between effective dates 9. To update an existing rule, the Program Administrator selects the rule requiring updates and makes the desired changes. See Step 3 for the components of a rule 10. The System saves the new rule or updates to the rule Associations with Other Use Cases All use cases with alerts or notifications Alternative Flows None Additional Requirements The System shall provide version control

221 221 The System shall maintain an audit log of all changes The System shall maintain previous versions of alerts and notifications The System shall provide the capability to roll back to prior version of alerts and notifications The system will support notifications and letters in multiple formats, to include mail, text, and automated voice messages.