eCIRTS Use Case Scenarioselderaffairs.state.fl.us/doea/eCIRTS/eCIRTS_Use_Case_Scenarios.pdfo...

1 of 172

Use Case Scenarios

Tuesday, July 17, 2018

2 of 172

Document Information

Document Name Business Process and Requirements – Use Case Scenarios

Document Author(s) Deanna Settergren and John Collins

Date Submitted February 23, 2018

Revision History

Date Version Revised By Description 2/23/2018 1.0 Deanna Settergren

and John Collins eCIRTS Use Case Scenarios

3 of 172

Contents

1. OVERVIEW .................................................................................................................................6

Definition ...................................................................................................................................................... 6

Purpose ......................................................................................................................................................... 6

Expectations ................................................................................................................................................. 6

System Assumptions ................................................................................................................................... 6

Use Case Attributes ..................................................................................................................................... 8

2. SECURITY .................................................................................................................................10

UC-SECURITY-01: User Logs into the System through Web Browser .................................................. 10

UC-SECURITY-02: User Logs into the System Using Mobile App .......................................................... 13

UC-SECURITY-03: User Changes Their Password .................................................................................. 16

UC-SECURITY-04: Add a New User Account ............................................................................................ 19

UC-SECURITY-05: Modify a User Account Profile ................................................................................... 21

UC-SECURITY-06: Unlock a User Account ............................................................................................... 24

Security Requirements ............................................................................................................................. 26

3. APPLICATION FUNCTIONALITY ..........................................................................................30

UC-APPFUNCT-01: Search for Client or Client Contact .......................................................................... 31

UC-APPFUNCT-02: Create or Modify Client or Client Contact ............................................................... 33

Client Management Requirements .......................................................................................................... 36

UC-APPFUNCT-03: Create or Modify Case ............................................................................................... 39

UC-APPFUNCT-04: Referral Case ............................................................................................................. 42

UC-APPFUNCT-05: Schedule Screening or Assessment ......................................................................... 45

UC-APPFUNCT-06: Create or Modify a Screening ................................................................................... 48

UC-APPFUNCT-07: PASRR Requests ........................................................................................................ 51

UC-APPFUNCT-08: EMS Release ............................................................................................................... 54

UC-APPFUNCT-09: Create or Modify an Assessment ........................................................................... 57

UC-APPFUNCT-10: Create or Modify Care Plan .................................................................................... 60

UC-APPFUNCT-11: Determine Level of Care (LOC) .............................................................................. 63

UC-APPFUNCT-12: Finalizing Level of Care (LOC) Determination (Staffing) ................................... 66

UC-APPFUNCT-13: Create Ad Hoc Follow-up Task .............................................................................. 69

UC-APPFUNCT-14: Complete Follow-up Task ...................................................................................... 71

Case Management Requirements .......................................................................................................... 73

UC-APPFUNCT-15: Search for Provider ................................................................................................ 94

UC-APPFUNCT-16: Create or Modify Provider ..................................................................................... 96

UC-APPFUNCT-17 Invoicing ................................................................................................................. 100

UC-APPFUNCT-18: Create or Modify a Taxonomy Code .................................................................... 104

UC-APPFUNCT-19: Resource Directory Website................................................................................ 107

Provider Management Requirements ................................................................................................ 109

UC-APPFUNCT-20: Case Record Review Tool (CRRT) ....................................................................... 115

UC-APPFUNCT-21: Create Monitoring Plan ........................................................................................ 118

UC-APPFUNCT-22: Conduct Monitoring Analysis .............................................................................. 120

Quality Assurance Requirements ........................................................................................................ 123

UC-APPFUNCT-23: Receive Complaint ................................................................................................ 128

Complaint Requirements ..................................................................................................................... 131

4. SYSTEM CONFIGURATION .................................................................................................. 134

UC-SYSCONFIG-01: Create or Modify Workflow ................................................................................... 134

UC-SYSCONFIG-02: Create or Modify Standard Document Template ................................................ 137

UC-SYSCONFIG-03: Create or Modify Reports via Reports Wizard .................................................... 140

UC-SYSCONFIG-04: Create or Modify Form ........................................................................................... 142

UC-SYSCONFIG-05: Create or Modify Business Rules .......................................................................... 144

UC-SYSCONFIG-06: Create or Modify Dashboard ................................................................................. 146

4 of 172

System Configuration Requirements .................................................................................................... 149

5. INTERFACES AND INTEROPERABILITY ........................................................................... 155

UC-INTERFACEINTEROP-01: Upload Data Using System Batch Upload ............................................ 155

UC-INTERFACEINTEROP-02: User Uploads a File to a System Record ............................................... 157

UC-INTERFACEINTEROP-03: User Batch Uploads Data using an Encrypted HTTPS Site ................. 159

UC-INTERFACEINTEROP-04: Send Fax .................................................................................................. 162

UC-INTERFACEINTEROP-05: Send Email .............................................................................................. 164

Interface and Interoperability Requirements ..................................................................................... 166

5 of 172

1. Overview

Definition Use cases are primarily textual explanations of how a user will interact with the system or product to achieve a defined goal. They build a vision around the interactions of the system and the users, describing what the user wants to do without specifying the technical aspects of how to do it.

These use cases are not all inclusive of functionality supported in the “to-be” Electronic Client Information and Referral Tracking System (eCIRTS). These Use Cases should be viewed as a high-level description of functionality to be consumed by the vendor during the procurement phase of the project. While the use cases are not intended to design the “to-be” aspects of the system, they do provide alignment between the desired functionality defined in the Business Process Re-engineering document and the resulting requirements in the Requirements Traceability Matrix.

Purpose The purpose of these use cases is to describe the user goals and interactions that are required to achieve them. They are based on business requirements and to-be business process flows that have been gathered on the current system and translated into a high-level evaluation of requirements for the future state of the system. The use cases are meant to establish the link between a set of business objectives and the user needs and wants of the “to-be” system.

Expectations The expectation of forming the use cases is that a roadmap to the future system state will be delivered for a more granular level of technical functionality. It is also an aid when determining the functionality alignment of the “as-is” and “to-be” state systems.

System Assumptions • The system should have a database-driven back end.

• The system should allow for load balancing and redundancy.

• The system should provide reporting and data analytics functionality.

• The system performance should conform to agreed-upon performance service levels with the vendor.

• The system should allow at a minimum for the following roles:

o Users – active users of the system. o Clients – users of the system but whose data is being stored for demographic and

medical-based information tracking purposes and for accessing pertinent client information.

o Service Providers – active and non-active users of the system whose data is being stored for tracking financial impacts of services provided to clients.

o Administrators – active users of the system who have administrative rights in which to update and control system functionality.

o Finance Administrators – active users of the system who have financial administrative rights in which to create and edit service provider budgetary information.

• The system should allow for customized integration, including:

6 of 172

7 of 172

o Document and Records Management integration for managing and storing documentation associated with client data.

o Consolidated client record for managing all client-related information, documentation, and contacts (case notes, medical information, caregiver contact information, etc.).

o Customizable work queue dashboard displaying current assignments and alerts. o Unified calendaring and scheduling. o Automated communication and collaboration tools. o An integrated resource directory web page that facilitates searching for various home

and community-based services in the selected service area. o Online web-portal for providers eliminating the need for staff to manually enter annual

assessments and PASRR information. o Enhanced workflow minimizing or eliminating manual processes and increasing staff

collaboration and efficiency. o Better management capabilities via a staff management dashboard allowing supervisors

to monitor staff work queues, assign tasks, and access productivity analytics and reports.

o Enhanced mobile capability allowing staff to complete work assignments remotely via Wi-Fi or cellular and/or work offline with automatic system synchronization.

o Enhanced and automated scheduling based on staff-defined business rules with appointment reminders and optimal route mapping for assessors who travel to client locations.

o Ability for electronic signatures on required documentation submission eliminating several of the current paper processes regarding the printing, scanning, faxing, and mailing of relevant documentation.

o Automated correspondence generation and delivery, reducing manual entry errors as well as mailing and faxing costs.

o Improved system scalability to accommodate increased resource capacity needs, and improved system modularity and extensibility with the addition of a business rules engine to expand system functionality.

o The ability to push data via a specified format into the database without utilizing the standard GUI.

o The ability to gather address data for GPS-based mapping.

• The system should allow for interfaces with external systems, including:

o Agency for Health Care Administration (AHCA) – Active waiver enrollment information for Statewide Medicaid Managed Care (SMMC) Long Term Care (LTC) and Program of All-inclusive Care for the Elderly (PACE) programs, eligibility information for all active and waitlist clients, previously active but now terminated enrollment information, paid claims and encounter data for active clients, complaints related to SMMC LTC waiver consumed by Independent Consumer Support Program used by the Medicaid Waiver/ADRC Unit, and Level of Care data.

o Department of Children and Families (DCF) – Information about individuals who are being served by DCF in state programs and about to turn 60 making them DOEA’s responsibility, and Level of Care data.

o Department of Health (DOH) – Death certificate data of individuals 18 or older. o Enrollment Broker – Client information with the Comprehensive Assessment and

Review for Long Term Care Services (CARES), Level of Care determinations, for the SMMC LTC program, and CARES 701B assessments (.PDF format) for client data with a community recommendation (not nursing home clients) to the Enrollment Broker for the SMMC LTC program.

8 of 172

o Service Providers – Billing data is imported into CIRTS using the DOEA Electronic Data Interchange (EDI) File Exchange system.

• The system should have at a minimum the following:

o Client Records Management o Financial Records Management o Billing Management o Document/Records Management o EHR Integration Capability (integration with external EHR systems) o Communications Management for Email and Fax o Medical Records Management o Medical Code Search – Diagnoses, Medication List o ANSI 837 consumption o Taxonomy Management

Use Case Attributes Attribute Description Description The description is a summary of the Use Case purpose. Level The Level describes who or what embodies the goal of the Use Case. Trigger A Trigger describes an event that occurs as an external business event

or a system event which initiates the Use Case. Primary Actors The Primary Actors is a description of the main users interacting with

the system with the intention of fulfilling the purpose of the Use Case. This could be a named actor or a description of the actor.

Other Actors Other Actors is a description of actors who may interact with the system on an infrequent basis to fulfill the purpose of the Use Case. They may also be affected by the Primary Actor’s fulfillment of the main purpose of the Use Case.

Precondition The Preconditions describe the conditions that must be met prior to the initiation of the Use Case.

Main Success Scenario The Main Success Scenario describes the events and the order in which they must occur to achieve the Use Case goal. The scenario describes the users’ interactions with the system and the system responses. It is the most common scenario to reach the goal successfully.

Extension – Exception The Exception Extension describes the events and the order in which they occur as a failure to achieve the Use Case goal. Exceptions will end in a “Use Case Ends” in which the Main Success Scenario remains unresolved. In some scenarios, the Exception may recommend an alternate path or a different Use Case Scenario to achieve success in the end goal.

Extension – Alternative The Alternative Extension describes the events and the order in which they occur which deviates from the Main Success Scenario but still results in a successful achievement of the Use Case goal. There may be many alternative paths and they should not be expected to be all inclusive of available alternative paths.

Post Condition – Success End

The Post Condition – Success End describes the system response if the goal of the use case is successfully achieved.

Post Condition – Failure End

The Post Condition – Failure End describes the system response if the goal of the use case is not successfully achieved.

9 of 172

Frequency The Frequency describes the expectation of the availability and the usage of the Use Case scenario. For instance, there may be scenarios that require a “once a month” frequency or “on-demand.”

Security Security describes requirements for security based on the Department’s policies and applicable Statutes and Rules.

Usability/Accessibility Usability describes the degree to which a software can be used by specified consumers to achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use. Accessibility describes the design of products, devices, services, or environments for people who experience disabilities.

Requirements Matrix The requirements matrix is a list of the requirements with the potential of success of the Use Case goal.

10 of 172

2. Security

UC-SECURITY-01: User Logs into the System through Web Browser

1. Description User attempts to gain access to the system by entering an assigned user name and password on the Login Screen. 2. Level Summary 3. Trigger A user is required to perform a task within the system. 4. Primary Actor(s) • AAA/ADRC Staff • CARES Staff • DOEA Staff • Lead Agency Staff/OAA Providers 5. Other Actor(s) • N/A

6. Preconditions • The user is required to have a registered and active account (user name and password). • The user is required to have a secure network/internet connection.

11 of 172

2.1.1. Flow of Events: User Logs into the System through Web Browser Main Success Scenario (User Logs into the System through Web Browser) 1. The user accesses the system Login Screen by double-clicking the system desktop icon. 2. The default web browser is launched and the system login screen is displayed. 3. The user correctly enters their user name and password and selects Login. 4. The system displays the user’s Home Dashboard. Extensions Exception 1 Invalid Credentials Entered 3a User enters invalid credential information. 3b An error is displayed indicating the reason for the login failure. 3c The Main Success Scenario is rejoined at step 3 until successful login or login attempts allowed have been

exceeded – See Exception 2. Exception 2 User Account is Locked, Deactivated, or Suspended 3a The system displays a warning “User’s account has been locked or disabled. Please contact your system

administrator.” 3b The Use Case ends. See Use Case UC-SECURITY-06: Unlock a User Account. Alternatives Alternative 1 Password Forgotten 1. The user accesses the system Login Screen by double-clicking a system desktop icon. 2. The default web browser is launched and the system login screen is displayed. 3. The user selects Forgot Password and the system displays the Reset Password screen. 4. The user selects Reset Password, enters the email address associated with the account, and selects

Submit. An email is sent to the email address associated with the account. 5. The user navigates to their email application, selects the password recovery link from the system-

generated email, and the system displays the Change Password Screen. 6. The user enters a new password. 7. The user re-enters the password for confirmation and selects Save. 8. The system displays a confirmation of the change. 9. The system displays the Login Screen. 10. The Main Success Scenario is rejoined at step 3. Alternative 2 User Name Forgotten 1. The user accesses the system Login Screen by double-clicking the system desktop icon. 2. The default web browser is launched and the system login screen is displayed. 3. The user selects Forgot User Name and the system displays the Forgot User Name Screen. 4. The user enters the email address associated with the account and selects Submit. An email is sent to the

email address associated with the account. 5. The user navigates to their email system, selects the system-generated email, and the system displays the

email with the user name and a link to the Login Screen. 6. The user selects the link to the system Login Screen. 7. The system displays the Login Screen. 8. The Main Success Scenario is rejoined at step 3. Alternative 3 Expired Password 1. The user accesses the system Login Screen by double-clicking a desktop icon. 2. The default web browser is launched and the system login screen is displayed. 3. The user correctly enters their user name and password and selects Login. 4. The system displays the following message: “Your password has expired. Please reset your password.” 5. The user selects Reset and the system displays the Change Password Screen to reset the password. 6. The system requests the user to enter the current password. 7. The user enters a new password. 8. The user re-enters the new password for confirmation and selects Save. 9. The system displays a confirmation of the change. 10. The system displays the Login Screen.

12 of 172

11. The Main Success Scenario is rejoined at step 3. Post Conditions Success End Condition • The user is logged into the system and their Home Dashboard is displayed.

Failure End Condition

• The system fails to log the user into the system. • An error is displayed indicating the reason for the failure to login. • The login screen is displayed.

Frequency On Demand

Security

• Chapter 74-2, Florida Administrative Code; • Section 282.318, Florida Statutes; • 45 CFR Part 164, P.L. 104-191, HIPAA of 1996; and • 1902(a)(7) of the Social Security Act as further interpreted in regulations at 42 CFR

431.300 to 307

Usability/ Accessibility

• The ability to login should be accessible via mobile devices such as tablets with a cellular or Wi-Fi connection.

• The ability to login must be available in an offline mode with a synchronization of data after reconnection to the system.

• The system shall support Section 508 accessibility software standards.

13 of 172

UC-SECURITY-02: User Logs into the System Using Mobile App 1. Description User attempts to gain access to the system by entering an assigned user name and password on the Login Screen of a mobile application (app). 2. Level Summary 3. Trigger A user is required to perform a task within the system. 4. Primary Actor(s) • ADRC/AAA Staff • CARES Staff • DOEA Staff • Lead Agency Staff/OAA Providers

5. Other Actor(s) N/A

6. Preconditions • The user is required to have a registered and active account (user name and password). • The user is required to have the mobile app installed on their mobile device. • The user is required to have a secure network/internet connection.

14 of 172

2.2.1. Flow of Events: User Logs into the System Using Mobile App Main Success Scenario (User Logs into the System Using Mobile App) 1. The user accesses the system Login Screen by opening the system mobile application. 2. The default mobile application is launched and the system login screen is displayed. 3. The user correctly enters their user name and password and selects Login or uses biometric access. 4. The system displays the user’s Home Dashboard. Extensions Exception 1 Invalid Credentials Entered 3a User enters invalid credential information. 3b An error is displayed indicating the reason for the failure to login. 3c The Main Success Scenario is rejoined at step 3 until successful login or login attempts allowed have

been exceeded – See Exception 2. Exception 2 User Account is Locked, Deactivated, or Suspended 3a The system displays a warning that the user’s account has been locked. 3b The Use Case ends; See Use Case UC-SECURITY-06: Unlock User Account. Alternatives Alternative 1 Reset Password while Mobile 1. The user accesses the system Login Screen by opening the system mobile application. 2. The default mobile application is launched and the system Login Screen is displayed. 3. The user selects Forgot Password and the system displays the Reset Password screen. 4. The system displays the Challenge Questions to reset the password. 5. The user correctly answers each challenge question and selects Next. 6. The system displays the New Password Screen. 7. The user enters a new password. 8. The user re-enters the new password for confirmation and selects Save. 9. The system displays a confirmation of the change. 10. The system displays the Login Screen. 11. The Main Success Scenario is rejoined at step 3. Alternative 2 User Name Forgotten 1. The user accesses the system Login Screen by opening a mobile application. 2. The default mobile application is launched and the system Login Screen is displayed. 3. The user selects Forgot User Name and the system displays the Forgot User Name screen. 4. The user enters their email address associated with their account. An email is sent to the email

address associated with their account. 5. The user navigates to their email system, selects the system-generated email, and the system displays

the email with the user name. 6. The Main Success Scenario is rejoined at Step 1. Alternative 3 Password Expired 1. The user accesses the system Login Screen by opening the system mobile application. 2. The default mobile application is launched and the system login screen is displayed. 3. The user correctly enters their user name and password and selects Login. 4. The system displays the following message: “Your password has expired. Please reset your

password.” 5. The user selects Reset and the system displays the Change Password Screen to reset the password. 6. The system requests the user to enter the current password. 7. The user enters a new password. 8. The user re-enters the new password for confirmation and selects Save. 9. The system displays a confirmation of the change. 10. The system displays the Login Screen. 11. The Main Success Scenario is rejoined at step 3.

15 of 172

Post Conditions Success End Condition • The user is logged into the system and their Home Dashboard is displayed.


• The system fails to log the user into the system. • An error is displayed indicating the reason for the failure to login. • The login screen is displayed.

Frequency On Demand

Security


431.300 to 307





16 of 172

UC-SECURITY-03: User Changes Their Password 1. Description The user chooses to change their password. 2. Level Summary 3. Trigger • A user chooses to change their password prior to the password expiration date. • A user is prompted to change their password before their password expires. 4. Primary Actor(s) • AAA/ADRC Staff • CARES Staff • DOEA Staff • Lead Agency Staff/OAA Providers 5. Other Actor(s) N/A

6. Preconditions • The user is required to have a registered and active account (user name and password). • The user is required to have a secure network/internet connection.

17 of 172

2.3.1. Flow of Events: User Changes Their Password Main Success Scenario (User Changes Their Password) 1. The user accesses the system Login Screen by double-clicking a desktop icon. 2. The default web browser is launched and the system login screen is displayed. 3. The user correctly enters their user name and password and selects Login. 4. The system displays the user’s Home Dashboard. 5. The user selects Account Profile and the system displays the user’s account profile. 6. The user selects Change Password and the system displays the Change Password Screen. 7. The system requests the user to enter the current password. 8. The user enters a new password. 9. The user re-enters the new password for confirmation and selects Save. 10. The system displays a confirmation of the change. 11. The system displays the user’s account profile. Extensions Exception 1 Invalid Password at Login 3a User enters invalid credential information. 3b An error is displayed indicating the reason for the failure to login to the system. 3c The Main Success Scenario is rejoined at Step 3. Exception 2 New Password Does Not Meet Security Requirements 9a The user enters a password which does not meet the security minimum requirements. 9b The system displays a message indicating the unmet security requirement. 9c The Main Success Scenario is rejoined at Step 8. Alternatives Alternative 1 System Prompts User to Change Password Prior to Expiration 1. The user accesses the system Login Screen by double-clicking a desktop icon. 2. The default web browser is launched and the system Login Screen is displayed. 3. The user correctly enters their user name and password and selects Login. 4. The system displays the message: “Your password will expire in XX days. Click OK to change

password.” 5. The user selects OK and the system displays the Change Password Screen. 6. Resume the Main Success Scenario at Step 7. Alternative 2 Reset Password at First Login 1. The user accesses the system Login Screen by double-clicking a desktop icon. 2. The default web browser is launched and the system Login Screen is displayed. 3. The user correctly enters their user name and password and selects Login. 4. The system displays the message: “This is your first login. Please reset the password on your

account.” 5. The user selects OK and the system displays the Change Password Screen. 6. Rejoin the Main Success Scenario at step 7. Alternative 3 Administrator Resets User Password 1. User sends password reset request to the Account Administrator. 2. The Account Administrator accesses the system Login Screen by double-clicking a desktop icon. 3. The system displays the Account Request Screen, the Account Administrator selects Manage User

Accounts, and the Manage User Accounts Screen is displayed. 4. The Account Administrator selects Search Users and the system displays the User Search Screen. 5. The Account Administrator enters the required user information and selects Search. 6. The system displays a list of search results. 7. The Account Administrator selects the user from the list of Search Results and selects Reset Password. 8. The Account Administrator enters a new password and selects Save. 9. The system displays a confirmation of the change and the Account Administrator selects ÓK.

18 of 172

10. The system sends a confirmation email to the user regarding the password change and displays the Account Administrator's Home Dashboard.

Post Conditions Success End Condition

• The user successfully changes their password. • The user’s account profile is displayed.


• The system fails to change the password. • An error is displayed indicating the reason for the failure. • The user’s account profile is displayed.

Frequency On Demand

Security

• Chapter 74-2, Florida Administrative Code; • Section 282.318, Florida Statutes; • 45 CFR Part 164, P.L. 104-191, HIPAA of 1996; and • 1902(a)(7) of the Social Security Act as further interpreted in regulations at 42

CFR 431.300 to 307


• The ability to change a password should be accessible via mobile devices such as tablets with a cellular or Wi-Fi connection.


19 of 172

UC-SECURITY-04: Add a New User Account 1. Description An Account Administrator adds a new user account to the system. 2. Level Summary 3. Trigger The Account Administrator receives notification that an approved account request has been assigned to them for account creation. 4. Primary Actor(s) • Account Administrator 5. Other Actor(s) • Account Approver • Account Requestor • New User 6. Preconditions • Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed. • The Account Administrator is required to have an Account Administrator role. • A task to request a new user account has been created and is assigned to the Account Administrator.

20 of 172

2.4.1. Flow of Events: Add a New User Account Main Success Scenario (Add a New User Account) 1. The Account Administrator selects the Administration Module from the Home Dashboard and the

system displays the Administration Screen. 2. The Account Administrator selects Manage User Accounts and the system displays the Manage User

Accounts Screen. 3. The Account Administrator selects Create New Account and the system displays the New Account

Screen. 4. The Account Administrator provisions the account based on the required fields and approved role(s)

and selects Save. 5. The system saves the information and updates the Account Status to Activated. 6. The system sends the following notifications:

o Email to the new user with their login information, instructions for login, and a hyperlink to the Login Screen;

o Email to the Account Requestor; and o Email to the Account Approver notifying them of account activation.

7. The system displays the user’s Home Dashboard. Extensions Exception 1 Invalid Data Entered 4a Account Administrator enters invalid information into a field or fails to complete required fields. 4b An error is displayed indicating the reason for the failure to save. 4c The Main Success Scenario is rejoined at Step 4. Exception 2 Premature Exit 4a If the Account Administrator selects Cancel, the system returns them to the previous screen. Exception 3 User Account Already Exists 4a The system displays a message saying: “The User Account already exists. Please click OK and edit

the User Name before attempting to save.” 4b The Account Administrator selects OK and the Main Success Scenario is rejoined at Step 4. Post Conditions Success End Condition

• The user account request is created. • A message of successful request submission is displayed. • The system displays the Manage User Accounts Screen.


• User Account request fails to save to the system. • An error is displayed indicating the reason for the failure to save. • The system displays the Manage User Accounts Screen.

Frequency On Demand

Security


CFR 431.300 to 307

Usability/ Accessibility • The system shall support Section 508 accessibility software standards.

21 of 172

UC-SECURITY-05: Modify a User Account Profile 1. Description An Account Administrator modifies an existing user account. 2. Level Summary 3. Trigger The Account Administrator receives a notification of an account request with a modify status. 4. Primary Actor(s) • Account Administrator 5. Other Actor(s) • Account Approver • Account Requestor • User 6. Preconditions • Use Case UC-SECURITY-04: Add a New User Account has been completed. • The Account Administrator is required to have an Account Administrator Role. • A task to request an account modification has been created and is assigned to the Account

Administrator.

22 of 172

2.5.1. Flow of Events: Modify a User Account Profile Main Success Scenario (Modify a User Account Profile) 1. The Account Administrator selects the Administration Module from their Home Dashboard. 2. The system displays the Administration Screen. 3. The Account Administrator selects Manage User Accounts and the system displays the Manage User

Accounts Screen. 4. The Account Administrator selects Search Users and the system displays the User Search Screen. 5. The Account Administrator enters the required user information and selects Search. 6. The system displays a list of search results. 7. The Account Administrator selects the account to be modified and selects Edit. 8. The system displays the Account Profile Screen, the Account Administrator modifies the account

information, and selects Save. 9. The system saves the information. 10. The system sends the following notifications:

o Email to the Account Requestor; and o Email to the Account Approver.

11. The system displays the Manage User Accounts Screen. Extensions Exception 1 No Record Found 5a If no record is found, the system will display a message stating: “No Record Found.” 5b The Main Success Scenario is rejoined at Step 5. Exception 2 Invalid Data Entered 8a Account Administrator enters invalid information into a field or fails to complete required fields. 8b An error is displayed indicating the reason for the failure to save. 8c The Main Success Scenario is rejoined at Step 7. Exception 3 Premature Exit 8a The Account Administrator selects Cancel and the system returns the Account Administrator to the

previous screen. 8b The Main Success Scenario is rejoined at Step 7. Exception 4 Invalid Role Information Entered 8a The Account Administrator selects an invalid role and selects Save. 8b An error is displayed indicating the reason for the failure to save. 8c The Main Success Scenario is rejoined at Step 8. Alternatives Alternative 1 Deactivate a User Account 1. The Account Administrator selects the Administration Module from their Home Dashboard. 2. The system displays the Administration Screen. 3. The Account Administrator selects Manage User Accounts and the system displays the Manage User

Accounts Screen. 4. The Account Administrator selects Search Users and the system displays the User Search Screen. 5. The Account Administrator enters the required user information and selects Search. 6. The system displays a list of search results. 7. The Account Administrator selects the account to be deactivated and selects Edit. 8. The Account Administrator selects Deactivate Account. 9. The system saves the information and updates the Account Status to Inactive. 10. The system sends the following notifications:

o Email to the Account Requestor; and o Email Account Approver.

11. The system displays the Manage User Accounts Screen.

23 of 172

Alternative 2 Add A Role to Multiple User Accounts 1. The Account Administrator logs into the system and selects the Administration Module from their

Home Dashboard. 2. The system displays the Administration Screen. 3. The Account Administrator selects Manage User Accounts and the Manage User Accounts Screen is

displayed. 4. The Account Administrator selects the user accounts that will inherit the assigned role. 5. The Account Administrator selects Add Roles, selects the approved security roles and permissions,

and selects Save. 6. The system saves the information, updates the Request Status to Activated, and sends an email to the

Account Requestor and Account Approver notifying them of account modification. 7. The system displays the Account Administrator's Home Dashboard. Post Conditions Success End Condition

• The user account is updated. • A message of successful modification is displayed. • The system displays the Manage User Accounts Screen.


• User account modification fails to save to the system. • An error is displayed indicating the reason for the failure to save. • The system displays the Manage User Accounts Screen.

Frequency On Demand

Security


431.300 to 307


24 of 172

UC-SECURITY-06: Unlock a User Account 1. Description An Account Administrator selects Unlock Account on a user's account to restore access to the system. 2. Level Summary 3. Trigger The Account Administrator receives notification of an account request with an unlock status assigned to the Account Administrator. 4. Primary Actor(s) • Account Administrator 5. Other Actor(s) • User

6. Preconditions • Use Case UC-SECURITY-04: Add a New User Account has been completed. • The Account Administrator has a secure network/internet connection. • The Account Administrator is required to have the Account Administrator role.

25 of 172

2.6.1. Flow of Events: Unlock a User Account Main Success Scenario (Unlock a User Account) 1. The Account Administrator selects the Administration Module from their Home Dashboard. 2. The system displays the Administration Screen. 3. The Account Administrator selects Manage User Accounts and the system displays the Manage User

Accounts Screen. 4. The Account Administrator selects Search Users and the system displays the User Search Screen. 5. The Account Administrator enters the required user information and selects Search. 6. The system displays a list of search results. 7. The Account Administrator selects the account to be unlocked and selects Edit. 8. The Account Administrator selects Unlock Account and selects Save. 9. The system saves the information and updates the account status. 10. The system sends a notification to the user notifying them of the modification of their account. 11. The system displays the Manage User Accounts Screen. Post Conditions Success End Condition

• The user account is unlocked. • The system displays a message of completion. • The system displays the Manage User Accounts Screen.


• The user account update fails to save to the system. • An error is displayed indicating the reason for the failure. • The system displays the Manage User Accounts Screen.

Frequency On Demand

Security


CFR 431.300 to 307


26 of 172

Security Requirements

Type Req ID Category Requirements

Functional 10 Account Management

The system shall provide the ability to associate accounts with specific permissions granted by the "parent" entity.


The system shall provide the ability to maintain an administrator-defined list of required fields a user must complete to request an account (e.g., name, address) by business rules.


The system shall provide the ability for a user to securely reset the password for their account.


The system shall provide the ability for an authorized user to create an account and associate roles to the account.


The system shall provide the ability to define functionality applicable to role-based categories of users.


The system shall enable authorized users to manage users assigned to a role.


The system shall enable authorized users to create, activate, modify, or deactivate users for an unlimited number of roles.


The system shall enable authorized users to identify and report inactive user accounts.


The system shall provide authorized users with an Account Registration screen displaying pending registration requests and allowing the user to add new registrations or modify a denied or pending registration.


The system shall provide the ability to search for pending or denied account registration requests.


The system shall provide administrators with an Account Management screen to add, modify and disable system user accounts and roles associated with them.

Functional 22 Development and Support Services

The system shall enable authorized users to administer users, logs, reports and configurations.

Functional 23 Security The system shall enable restricting access to selected features by user identity and user role.

Functional 24 Security The system shall provide a single sign on which will seamlessly authenticate the authorized user into each module within the system based on the user's assigned security role(s).

Functional 25 Security The system shall enable authorized users to assign multiple individuals to a role.

Functional 78 Business Rules Engine

The system shall provide the ability to establish business rules for the automatic generation of notifications to appropriate recipients (e.g., authorized user, external user, clients, referring sources) for needed actions (e.g., follow-up required, need for data or documentation, scheduled appointment).


The system shall provide pop ups on how to correctly complete the data entry screens to reduce the amount of errors and deficiencies.

27 of 172



The system shall return error messages to the user when invalid information is entered into a data entry screen field.


The system shall provide users with context-sensitive help for user capabilities provided by the system.

Functional 166 Interfaces and Interoperability

The system shall provide for encrypted user authentication for remote users.


The system shall enable all data stored and transmitted on remote or mobile devices to be encrypted.

Functional 174 Mobility The system shall provide secure remote access for authorized users using wireless internet-enabled mobile computers or handheld devices.

Functional 181 Reporting and Dashboard

The system shall have the ability to present data in a dashboard format.


The system shall display the user's Home Dashboard as their primary landing page subsequent to login.

Functional 184 Search and Navigation

The system shall enable users to search, sort, filter, and view any data specific to a client or entity in the system.


The system shall enable authorized users to perform searches using 'wild cards.'


The system shall display a list of all matching records, including key information about each record, and allow sorting of the result set by the configured columns, when more than one record matches the search criteria.


The system shall enable users to select and view information about an individual record, when a search returns a list of records,


The system shall provide the ability to perform searches: full-text, keyword, date-range, and advanced searching using expression strings.


The system shall provide the ability to execute advanced search functionality from any area within the system.


The system shall require at least one search criteria is populated prior to executing a search.


The system shall provide the ability to group, sort and filter search results.


The system shall provide the ability to navigate to the appropriate record selected (within the context of the search).


The system shall provide the ability to combine multiple search criteria using logical ‘AND’, ‘OR’ and ‘BETWEEN’ operators.


The system shall provide the ability to search and retrieve records (or logical groups of records) matching compound search criteria.


The system shall allow users to save search criteria and results with user-defined names.

28 of 172



The system shall provide the ability to include unstructured data in query results (e.g., Microsoft Word documents, Adobe Acrobat PDF files).


The system shall provide large result sets in a paged manner and shall indicate either the page number viewed of the total number of pages or range of listed records of the total number of records returned.


The system shall provide query searching capabilities that can be used to search within a result set.


The system shall provide the ability to perform advanced searches based on configurable criteria.


The system shall allow for the user to access the Search Screen from the user's Home Dashboard.


The system shall provide users search screens displaying fields in relation to where the user is within the system. (e.g., if the user is on the Services Screen, the search fields relevant to searching for services and referrals should be displayed to the user)


The system shall provide the ability to specify the limit of the maximum number of records retrieved by a single page query.

Functional 210 Security The system shall provide the ability to filter the search results based on the user's role.

Functional 212 Security The system shall provide varying levels of permission to access data and functionality (e.g., no access, read-only access, create access, modify access, and delete access).

Functional 218 Usability The system shall notify the user if required fields are not entered into the form prior to committing data to the database.

Functional 219 Usability The system shall provide the user access to data, cases, and file attachments associated with a specific client.

Functional 258 Workflow The system shall notify the appropriate authorized users of work that has been routed to them.

Functional 327 Mobility The system shall provide local user authentication when the mobile computer or device is offline.

Non-Functional 602 Account

Management

The system shall enable authorized users to define standard “user profiles” from which individual user IDs may inherit privileges and roles.

Non-Functional 603 Account

Management The systems shall provide a unique identifier for the account registration request.

Non-Functional 604 Search and

Navigation The system shall provide navigation to the Account Registration screen determinant on user roles.

Non-Functional 647

Development and Support Services

The system graphical user interface (GUI) shall support at a minimum the current versions of the browsers listed using HTTPS protocol (port 443): Microsoft Internet Explorer and Edge; Google Chrome; Firefox; and Apple Safari.

Non-Functional 653 Mobility

The system shall be compatible with currently supported mobile device platforms (Apple iOS, Google Android, and Microsoft Windows).

29 of 172


Non-Functional 708 Security

The system shall provide the ability to establish standard "user profiles" consisting of one or more roles from which individual users may inherit access privileges.

Non-Functional 709

Security The system shall provide the ability for an administrator to modify the roles of a single user or group of users without modifying the original profile or role.

Non-Functional 710

Security The system shall provide the ability to assign role(s) to users effective for a specified date range.

Non-Functional 711 Security The system shall not display a password in clear text.


The system shall provide the ability for the user to reset their password prior to exceeding the limit of unsuccessful login attempts.


The system shall provide for a warning of password expiration using an administrator-configurable number of days prior to actual expiration.

Non-Functional 714 Security The system shall provide the user with a final warning to change

their password prior to password expiration. Non-Functional 718 Security The system shall provide the capability for an administrator to

create/modify user accounts.


The system shall provide the ability to associate a user to a specific business entity or entities within and external to the organization.

Non-Functional 720 Security The system shall provide the capability for an administrator to

reset a user's password without knowing the original password.

Non-Functional 721 Security The system shall provide the capability for an administrator to

require a user to reset their password on the next successful login.

Non-Functional 722 Security The system shall prevent the creation of duplicate user accounts.


The system shall provide the ability to enforce administrator-configurable security parameters (e.g., password strength, expiring passwords, lockout attempts, inactivity timeframes, etc.).

Non-Functional 726 Security The system shall provide the ability to generate automatic

notification of locked user accounts to a security administrator.


The system shall automatically disable the user account when the administrator-configurable number of unsuccessful attempts is exceeded.

Non-Functional 752 Security The system shall provide the ability to administer user security

based on roles.

30 of 172

3. Application Functionality

The Application Functionality section is comprised of the use cases required to complete the interactions between a given role and the system to execute business processes. The Application Functionality section is broken down into several subsections to group and highlight the various areas within the system where each group of staff will perform their daily activities. The Application Functionality section contains the following use cases:

• Search for Client or

Client Contact

• Create or Modify Client or Client Contact

• Create or Modify a Case

• Referral Case

• Schedule Screening or Assessment

• Create or Modify a Screening

• PASRR Requests

• EMS Release

• Create or Modify an

Assessment

• Create or Modify Care Plan

• Determine Level of Care (LOC)

• Finalizing Level of Care (LOC) Determination (Staffing)

• Create Ad Hoc Follow-up Task

• Complete Follow-Up Task

• Search for Provider

• Create or Modify Provider

• Invoicing

• Create or Modify Taxonomy Service

• Resource Directory Website

• Case Record Review Tool (CRRT)

• Create Monitoring Plan

• Conduct Monitoring Analysis

• Receive Complaint

31 of 172

Application Functionality – Client Management

Florida has 5.3 million residents over the age of 60 with 700,000 of these residents being served by DOEA. Client management comprises most of the system processes, tracking client status from initial contact through deactivating the record. This section consists of use cases for the Client Management Module within the system. The use cases detail the various processes found within the Client Management Module along with the steps needed to complete each task. The following use cases comprise the Client Management subsection:

• Search for Client or Client Contact • Create or Modify Client or Client Contact

UC-APPFUNCT-01: Search for Client or Client Contact 1. Description This use case provides the functionality for a user to search client records by identifiers such as name, date of birth, Social Security Number, etc. 2. Level Summary 3. Trigger • User must search to locate a client record in the system.

4. Primary Actor(s) • AAA/ADRC Staff • CARES Staff • DOEA Staff • Lead Agency Staff/OAA Providers

5. Other Actor(s) • Client • Client Contact

6. Preconditions • Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed.

32 of 172

3.1.1. Flow of Events: Search for Client or Client Contact Main Success Scenario (Search for Client) 1. The user selects Client Search from the Home Dashboard. 2. The system displays the Client Search Screen. 3. The user enters one or a combination of the following client or client contact demographic

information into the search screen: o First Name; and/or o Last Name; and/or o County; and/or o Date of Birth (clients only); and/or o Social Security Number (clients only); and/or o Medicaid ID Number (clients only); and/or o Unique Client Identification Number (clients only).

4. User selects Search. 5. The system displays the list of potential client or client contact matches ranked by the match

percentage against key demographic data. 6. The user selects the record and the system displays the client or client contact record. Extensions Exception 1 Invalid Data Entered 4a User enters invalid information into a field or fails to complete required fields. 4b The system displays an error indicating the reason for the failure. 4c The Main Success Scenario is joined at Step 3. Exception 2 Premature Exit 4a The user selects Cancel before the client search is complete. 4b The system displays the Client Search Screen and the Main Success Scenario is rejoined at step 3. Exception 3 No Record Found 5a If no record is found, the system will display a message stating: “No Record Found. Create New

Client?” o If the user selects No, the Main Success Scenario is rejoined at Step 3. o If the user selects Yes, the use case ends and the flow continues with Use Case UC-APPFUNCT-02:

Create or Modify Client or Client Contact. Post Conditions Success End Condition • The system displays the client or client contact record.


• An error is displayed indicating a reason the Search cannot be completed. • The system displays the Client Search Screen.

Frequency On Demand

Security


431.300 to 307


• The ability to search should be accessible via mobile devices such as tablets with a cellular or Wi-Fi connection.


33 of 172

UC-APPFUNCT-02: Create or Modify Client or Client Contact 1. Description This use case provides the functionality for an internal user such as AAA/ADRC Staff or CARES Staff to create or modify a client record. The Client Record contains demographics, client contact(s), contact history, cases, documents, waitlists, and services rendered by providers. 2. Level Summary 3. Trigger • An internal user must add or modify a client record.

4. Primary Actor(s) • ADRC/AAA Staff • CARES Staff • Lead Agency Staff/OAA Providers

5. Other Actor(s) • Client • Client Contact

6. Preconditions • Use Case UC-APPFUNCT-01: Search for Client or Client Contact has been completed.

34 of 172

3.2.1. Flow of Events: Create or Modify Client or Client Contact Main Success Scenario (Create a Client) 1. The user selects Create Client from the Home Dashboard. 2. The system displays the Client Information Screen. 3. The user selects the Client Type from the following drop-down list:

o Client; o Client with Contact(s); or o Anonymous Client.

4. The user selects Client and the system dynamically displays the fields required for a client. 5. The user enters the following client demographic information and selects Save:

o First Name (required); o Last Name (required); o Date of Birth (required); o Gender (optional); o Social Security Number (optional); o Medicaid ID Number (optional); o Mailing Address (required); o Physical Address (required); o Preferred Contact Method (required); and o Telephone Number (required).

6. The system performs a check for existing client records to determine if there is a potential match to an existing record. The system determines there is no match, creates the client record, and displays the Client Information Screen.

7. The user selects Create Case and this use case ends. See Use Case UC-APPFUNCT-03: Create or Modify Case.

Extensions Exception 1 Invalid Data Entered 5a User enters invalid information into a field or fails to complete required fields. 5b The system displays an error indicating the reason for the failure to save and defaults the user to the

first field with an error indicator such as a highlighted color. 5c The Main Success Scenario is joined at Step 3. Exception 2 Premature Exit 4a The user selects Cancel before the client record data entry is complete. 4b The system displays the message: “Save Client?”

o If the user selects Yes, the data entered is saved. When the user returns to the client record, the system displays the last active field when the user exited the screen.

o If the user selects No, the system discards the data entered and displays the Search Screen. Exception 3 Existing Record 5a The system displays a list of potential match(es) for the client record. 5b The user determines there is a matching record, selects the record, and the system displays the

existing Client Information Screen. The user confirms the information entered is correct and the Main Success Scenario is rejoined at Step 5.

Alternatives Alternative 1 Create a Client with Client Contact(s) 4a The user selects Client with Contact(s) from the Client Type drop-down list. 4b The system dynamically displays the fields required for a client with contacts. 4c The user enters the client demographic information as defined in the main success scenario, enters

the following Client Contact information, and selects Look-Up: o First Name; o Last Name; and o Telephone Number.

35 of 172

4d The system performs a look-up on the client contact information entered, the system returns no match(es) is found, and the user continues typing the required information.

o If the system finds a potential match(es), the user selects the match from the displayed list and the system associates the Client Contact information with the Client Record.

4e The user selects Primary or Secondary as the Contact Type selects Save. 4f The system saves the information and displays the Client Information Screen. 4g The user selects Create Case and this use case ends. See Use Case UC-APPFUNCT-03: Create or Modify

Case. Alternative 2 Add Anonymous Client 4a The user selects Anonymous Client and the system dynamically displays the fields required for an

anonymous client. 4b The user enters the City or ZIP Code, Age, and Gender of the Anonymous Client and selects Create

Information Only Case. 4c The system displays the Information Only Case Screen and this Use Case ends. See Use Case UC-

APPFUNCT-04: Referral Case. Alternative 3 Modify Existing Client Contact to Become a Client 1. The user selects the Client Record from the list of Search Results. 2. The system displays the Client Information Screen. 3. The user selects Edit Client Contact and the system displays the Contact Information Screen. 4. The user updates the Client Type field to Client. 5. The system displays the Client Information Screen to include the client information fields. 6. The Main Success Scenario is rejoined at Step 5. Alternative 4 Modify Existing Client or Client Contact 1. The user selects a client from the Search Results screen. 2. The system displays the Client Information Screen in view-only mode. 3. The user selects Edit, updates the information in the Client Information Screen, and selects Save. 4. The system saves the information and displays the Client Information Screen in view-only mode.


• The system saves the information. • The Client Information Screen is displayed.


• Data fails to save to the system. • An error is displayed indicating the reason for the failure to save. • The Client Information Screen is displayed.

Frequency On Demand

Security

• See Chapter 74-2, Florida Administrative Code; • Section 282.318, Florida Statutes; • 45 CFR Part 164, P.L. 104-191, HIPAA of 1996; and • 1902(a)(7) of the Social Security Act as further interpreted in regulations at 42 CFR

431.300 to 307.


• The ability to add or modify a client should be accessible via mobile devices such as tablets with a cellular or Wi-Fi connection.


36 of 172

Client Management Requirements



The system shall allow for priority search order to be set for search criteria when multiple criteria are provided by the user, e.g., Social Security number should be prioritized over first name and last name.

Functional 132 CRM The system shall have case management, client information tracking, and work resource management features.

Functional 145 Database Architecture

The system shall be client- and provider-centric with records linked to specific clients and/or providers.














The system shall enable users to select and view information about an individual record, when a search returns a list of records,

















37 of 172









The system shall allow for the user to access the Search Screen from the user's Home Dashboard.






The system shall provide the user with the total number of records found and total number of unduplicated records found matching the user's query.


The system shall copy search data to a subsequent user-initiated new client form if the system returns an empty or invalid search result.


The system shall enable an authorized user to search records by entering full or partial matches to key attributes.


The system shall allow navigation between related functionality without re-entering the original search criteria (e.g., selecting a client record from a search results screen and subsequently closing the record should allow the user to return to the original search results screen).


The system shall perform a match on existing client records when a new client is created.

Non-Functional 608 Application

Functionality The system shall provide a message to the user when a search results in no records returned.


Navigation

The system shall maintain user navigation history on data entry screens in the event the user exits the screen prior to completion such that they are returned to the location they last visited.

Non-Functional 675 System

Architecture

The system shall adhere to negotiated performance standards for searching, saving, retrieving, reporting, analysis and collating of data.

Non-Functional 753 Security The system shall provide the ability to administer user

security based on roles. Non-Functional 754 Security The system shall support Secure Sockets Layer (SSL) or,

preferably, Transport Layer Security (TLS).


The system shall support encryption using either Triple Data Encryption Standard (3DES) or, preferably, Advanced Encryption Standard (AES).

38 of 172


Non-Functional 756 Security The system shall encrypt data at the data layer in transit and

at rest.

39 of 172

Application Functionality - Cases Cases are used as a container to store all interactions with a client. This section consists of Use Cases for the Case Management Module and the information needed to complete each task required of the staff. The following use cases comprise the Cases subsection:

• Create or Modify Case • Referral Case • Schedule Screening or Assessment • Create or Modify a Screening • PASRR Requests • EMS Release • Create or Modify an Assessment • Create or Modify a Care Plan • Determine Level of Care (LOC) • Finalize Level of Care (LOC) Determination (Staffing) • Create Ad Hoc Follow-up • Complete Follow-up

UC-APPFUNCT-03: Create or Modify Case 1. Description Cases are used within the system as a container for individual tasks, follow-ups, contacts, assessments, and documents associated with an individual client. 2. Level Summary 3. Trigger • An internal user must document an interaction with or on behalf of a client.

4. Primary Actor(s) • CARES Staff • AAA/ADRC Staff • Lead Agency Staff/OAA Providers

5. Other Actor(s) • Client

6. Preconditions • Use Case UC-APPFUNCT-02: Create or Modify a Client or Client Contact has been completed.

40 of 172

3.4.1. Flow of Events: Create or Modify Case Main Success Scenario (Create Information Only Case) 1. The user selects Create Case from the Client Information Screen. 2. The system displays the Case Screen, defaults the Case Type to Information Only, and defaults the

Case Owner to the user. 3. The user enters the required information. 4. The user selects Close from the Case Screen. 5. The system updates the case status to Closed and displays the Client Information Screen. Extensions Exception 1 Invalid Data Entered 4a User enters invalid information into a field or fails to complete required fields. 4b The system displays an error indicating the reason for the failure to save and defaults the user to the

first field with an error indicator such as a highlighted color. 4c The Main Success Scenario is joined at Step 3. Exception 2 Premature Exit 4a The user selects Cancel before the case data entry is complete. 4b The system displays the message “Save Case?”

o The user selects Yes, the data entered is saved. When the user returns to the case, the system displays the last active field when the user exited the screen.

o The user selects No, the system discards data entered and displays the Client Information Screen.

Alternatives Alternative 1 Lead Agency Case 3a The user selects the Case Type from the following drop-down list:

o Assessment; or o Change of Condition.

3b The user updates the Case Owner if needed and selects Save., The system:

o Updates the Case Type and Case Owner; o Creates a Scheduling Task on the Case Owner’s Home Dashboard; and o Displays the Case Screen.

3c This Use Case ends. See Use Case UC-APPFUNCT-05: Schedule Screening or Assessment. Alternative 2 AAA/ADRC Case 3a The user selects the Case Type from the following drop-down list:

o Screening; or o Assessment.

3b The user updates the Case Owner if needed and selects Save. The system:

o Updates the Case Type and Case Owner; o Creates a Scheduling Task on the Case Owner’s Home Dashboard; and o Displays the Case Screen.

3c This Use Case ends. See Use Case UC-APPFUNCT-05: Schedule Screening or Assessment. Alternative 3 CARES Case 3a The user selects Assessment from the Case Type drop-down list. 3b The user updates the Case Owner if needed and selects Save. The system:

o Updates the Case Type and Case Owner; o Places a Scheduling Task on the Case Owner’s Home Dashboard; and o Displays the Case Screen.

3c This Use Case ends. See Use Case UC-APPFUNCT-05: Schedule Screening or Assessment.

Alternative 4 Complaint Case

41 of 172

3a The user enters notes as appropriate, updates the case type to Possible Complaint, and selects Save. 3b This use case ends. See Use Case UC-APPFUNCT-23: Receive Complaint. Alternative 5 Create a Referral Case 4a The user selects Referral Services from the Case Screen. 4b This Use Case ends. See Use Case UC-APPFUNCT-04: Referral Case. Alternative 6 Modify Case 1. The user selects Cases from the Client Information Screen. 2. The system displays the list of cases for the client. 3. The user selects the case to be edited and the system displays the Case Screen in edit mode. 4. The user updates the case details and notes. 5. The user selects Save, the system saves the updated information, and displays the Case Screen. Post Conditions Success End Condition

• Required data is saved to the system. • A message of successful completion is displayed. • The system displays the Client Information Screen.


• Required data fails to save to the system. • An error is displayed indicating the reason for the failure to save. • The system displays the Case Screen.

Frequency On Demand

Security


431.300 to 307


• The ability to enter case data be accessible and usable via mobile devices such as tablets with a cellular wireless connection.

• The ability to enter case data must be available in an offline mode with a synchronization of the data after reconnection to the system.


42 of 172

UC-APPFUNCT-04: Referral Case 1. Description Clients will contact the AAA/ADRC and request information regarding the services available to them. The AAA/ADRC staff will search for services using a Taxonomy system and add the services referred to the client to the open referral case. 2. Level Summary 3. Trigger • A client has contacted the AAA/ADRC and requests a referral for services available within their area

to fill a specific need. 4. Primary Actor(s) • AAA/ADRC Staff


6. Preconditions • Use Case UC-APPFUNCT-03: Create or Modify Case has been completed.

43 of 172

3.5.1. Flow of Events: Referral Case Main Success Scenario (Referral Case) 1. The user selects Referral Services from the Case Screen. 2. The system displays a Search for Services Screen. 3. The user enters the client geographic information and requested services into the Search for Services

Screen, selects Search, and the system returns search results. 4. The user selects the service(s) referred to the client and selects Add. 5. The system adds the services to the Case and returns to the Search for Services Screen.

Note: If the client needs additional services referred, the user will continue searching for and adding services until all services have been referred.

6. The user enters contact history notes for the services provided to the client and selects Needs Screening for Medicaid Services and other services, if needed.

7. User selects Save and is returned to the Case Screen. 8. The system:

o Saves the information; o Updates the case type to Referral; o Creates a Follow-up task according to business rules; o Sets case status to In Progress; and o Displays the Case Screen.

Extensions Exception 1 Service Not Found 3a User search fails to return the service being queried. 3b The system displays an error indicating the reason for the search failure. 3c The Main Success Scenario is joined at step 3. Exception 2 Invalid Data Entered 3a User enters invalid information into a field or fails to complete required fields. 3b The system displays an error indicating the reason for the failure to save and defaults the user to the

first field with an error indicator such as a highlighted color. 3c The Main Success Scenario is joined at Step 3. Exception 3 Premature Exit 7a The user selects Cancel before the case data entry is complete. 7b The system displays the message “Save Case?”




• The correct service(s) is located. • The service(s) is added to the record and saved in the system. • The system displays the Case Screen.


• The search fails to locate the service(s) being queried. • An error is displayed indicating the reason for the failure. • The system displays the Case Screen.

Frequency On Demand

Security


431.300 to 307

44 of 172




45 of 172

UC-APPFUNCT-05: Schedule Screening or Assessment 1. Description Screenings or Assessments must be scheduled for completion if they cannot be completed at the time of the initial client contact. 2. Level Summary 3. Trigger • A Screening or Assessment Case has been created and must be scheduled for completion.

4. Primary Actor(s) • AAA/ADRC Staff • CARES Staff • Lead Agency Staff/OAA Providers

5. Other Actor(s) • Client • Client Representative


46 of 172

3.6.1. Flow of Events: Schedule Screening or Assessment Main Success Scenario (Schedule Screening) 1. The Case Owner selects the Scheduling Task from their Home Dashboard and the system displays the

Case Screen. 2. The Case Owner selects Schedule Screening from the Case Screen. 3. The system displays the Case Owner’s calendar. 4. The Case Owner selects the date and time of the screening and selects Save. 5. The system:

o Places a Screening Task on the Case Owner’s calendar; o Places an alert on the Case Owner’s Home Dashboard; and o Displays the Case Screen; and o If the client has email on record, sends a calendar appointment to the client’s email address.


first field with an error indicator such as a highlighted color. 4c The Main Success Scenario is joined at Step 4. Exception 3 Premature Exit 4a The user selects Cancel before the entry is complete. 4b The system displays the message “Save Changes?”



Alternatives Alternative 1 Schedule an Assessment 1. The Case Owner selects the Scheduling Task from their Home Dashboard and the system displays the

Case Screen. 2. The Case Owner selects Schedule Assessment from the Case Screen. 3. The system displays the Case Owner’s calendar. 4. The Case Owner selects the date and time of the assessment and selects Save. 5. The system:

o Places an Assessment Task on the Case Owner’s calendar; o Places an alert on the Case Owner’s Home Dashboard notifying the Assessor to check for

Required Medical Documentation prior to the assessment; o Displays the Case Screen; and o If the client has email on record, sends a calendar appointment to the client’s email address.


• The Scheduling Task is saved in the system. • The system displays the Case Screen.


• The system fails to create the Scheduling Task. • An error is displayed indicating the reason for the failure to save. • The system displays the Case Screen.

Frequency On Demand

Security


CFR 431.300 to 307

47 of 172


• The ability to enter scheduling data be accessible and usable via mobile devices such as tablets with a cellular wireless connection.


48 of 172

UC-APPFUNCT-06: Create or Modify a Screening 1. Description Screening forms are used to conduct screenings for all DOEA programs. The Screening Form (701S) is used by the AAA/ADRC for enrollment and maintenance on the Assessed Prioritized Consumer List (APCL). The completion of this form generates a Priority Score and Rank. The potential client will contact the AAA/ADRC and ask to be placed on services for assistance with day to day activities. The AAA/ADRC will utilize the 701S Form to screen the client for services and assist with adding the client to the waitlist for services. 2. Level Summary 3. Trigger • A Screening Task has been received and assigned to the user for completion.

4. Primary Actor(s) • AAA/ADRC Staff


6. Preconditions • Use Case UC-APPFUNCT-05: Schedule Screening or Assessment has been completed.

49 of 172

3.7.1. Flow of Events: Create or Modify a Screening Main Success Scenario (Create Screening) 1. The Case Owner selects the assigned case from their Home Dashboard and the system displays the

Case screen. 2. The Case Owner selects Conduct Screening from the Case Screen. 3. The system displays a blank 701 Screening Form. 4. The Case Owner populates the form with information gathered from the client during the screening

and selects Complete. 5. The system computes the Priority and Rank Score, updates the Screening Task to Complete, and

displays the Waitlist Screen. 6. The user selects one, or multiple, programs from a check list, the system adds the client to each

appropriate program Waitlist, and selects Save. 7. The system:

o Validates the client’s demographic information against the DCF FLORIDA and AHCA FMMIS databases;

o Generates and prepopulates the Medicaid Eligibility Documents with client’s demographic information if priority and rank score are met and the client is on the SMMC LTCP waitlist; and

o Sends Medicaid Eligibility Documents via email if the client meets priority and rank score range and has elected to receive the documents via email, or notifies the user to print and mail Medicaid Eligibility Documents to the client if the client meets priority and rank score range and has not elected to receive the documents via email.

Extensions Exception 1 Invalid Data Entered 4a User enters invalid information into a field or fails to complete required fields. 4b The system displays an error indicating the reason for the failure to save. 4c The Main Success Scenario is joined at step 4. Exception 2 Premature Exit 4a The Case Owner exits the Screening prior to selecting Complete. 4b The system displays the message: “Save Screening?”

o The Case Owner selects Yes, the data entered is saved. When the user returns to the screening, the system displays the last active field when the Case Owner exited the screen.

o The Case Owner selects No, the system discards data entered and displays the Screening Task.

Alternatives Alternative 1 Previous Screening Exists 2a The system displays a message “Copy Previous screening dated: mm/dd/yyyy?”

o The user selects Yes, data from the previous screening is populated to the current screening form and the Main Success Scenario is rejoined at step 4.

o The user selects No, the Main Success Scenario is rejoined at step 3. Alternative 2 Modify Screening 1. The user selects Screening from the Case Screen. 2. The system displays the list of screenings for the client. 3. The user selects Modify Screening for the incomplete screening. 4. The user populates the form with the required information and selects Save (if further action is

required) or Complete (if no further action is required).

5. The system computes the Priority and Rank Score, updates the Screening Task to Complete, and displays the Case Screen.

6. The Main Success Scenario is rejoined in Step 7. Post Conditions Success End Condition

• Required screening data is saved to the system. • A message of successful completion is displayed.

50 of 172

• The system displays the Case Screen.


• Data fails to save screening data to the system. • An error is displayed indicating the reason for the failure to save. • The system displays the Case Screen.

Frequency On Demand

Security


431.300 to 307


• The ability to enter assessment data be accessible and usable via mobile devices such as tablets with a cellular wireless connection.

• The ability to enter assessment data must be available in an offline mode with a synchronization of the data after reconnection to the system.


51 of 172

UC-APPFUNCT-07: PASRR Requests

1. Description A PASRR Level I screening is completed for individuals seeking admission to a Medicaid-certified Nursing Facility (NF) to determine whether the individual has, or is suspected of having, a Severe Mental Illness (SMI), and/or Intellectual Disability (ID), or related condition. If an individual is suspected of having SMI and/or ID, or a related condition, a PASRR Level II is requested for completion for further client evaluation. 2. Level Summary 3. Trigger • A PASRR has been received.

4. Primary Actor(s) • CARES Staff


6. Preconditions • A PASRR Level I Form has been received from the Provider Portal and the system has:

o Validated the PASRR is complete and presented an Error Report if needed; o Created a new client record with client demographic information if no client record was found; o Populated the PASRR Level I data to the database for viewing from the PASSR Level I Screen; o Marked the record for verification required; and o Attached the PASRR Level I Form to the client’s record.

• The Use Case UC-SECURITY-01: User Logs into the system through Web Browser has been completed.

52 of 172

3.8.1. Flow of Events: PASRR Requests Main Success Scenario (Complete PASRR Level I) 1. The PASRR Level I Reviewer logs into the system and the system displays the user’s Home Dashboard. 2. The PASRR Level I Reviewer selects PASRR Level I Review Queue from their Home Dashboard and the

system displays the Queue Screen. 3. The PASRR Level I Reviewer selects a client from the Queue screen and the system displays the

PASRR Level I screen. 4. The PASRR Level I Reviewer reviews the information for accuracy and completeness of emailed,

electronically faxed, or scanned OCR output. 5. The PASRR Level I Reviewer selects Save, the system removes the Verification Required flag from the

client record, and displays the Queue Screen. Extensions Exception 1 Return PASRR for Corrections 4a The PASRR Level I Reviewer selects Return for Error Correction and the system displays the PASRR

Level I Return Screen. 4b The PASRR Level I Reviewer enters the required information, selects Send, the system sends the form

through an integrated fax, and displays the PASRR Level I Screen. 4c The Main Success Scenario is rejoined at Step 5. Exception 2 Invalid Data Entered 5a Invalid information is entered into a field or fails to complete required fields. 5b The system displays an error indicating the reason for the failure to save and defaults the user to the

first field with an error indicator such as a highlighted color. 5c The Main Success Scenario is joined at step 4. Exception 3 Premature Exit 5a The PASRR Level I Reviewer exits the PASRR prior to selecting Save. 5b The system displays the message: “Save PASRR?”

o The PASRR Level I Reviewer selects Yes, the data entered is saved. When the user returns to the PASRR, the system displays the last active field when the user exited the screen.

o The PASRR Level I Reviewer selects No, the system discards data entered and displays the PASRR Task.

Alternatives Alternative 1 PASRR Level II 5a The PASRR Level I Reviewer selects Save and Request PASRR Level II. 5b The system:

o Removes the Verification Required flag from the client record; o Creates a PASRR Level II Alert; o Assigns the PASRR Level II Alert according to business rules; and o Displays the Queue Screen.

5c The PASRR Level II Reviewer selects PASRR Level II Review Queue from their Home Dashboard and the system displays the Queue Screen.

5d The user selects the PASRR Level II Alert and the system displays the Client Information Screen. 5e The user selects Generate PASRR Notification from the Client Information Screen. 5f The system generates a PASRR notification letter, saves it to the client’s record as a PDF file and

displays the PDF file to the user. 5g The user selects Print, or Email, to send the letter to the client. 5h The user selects Create Case. 5i This use case ends. See UC-APPFUNCT-03: Create or Modify Case. Post Conditions Success End Condition

• The PASRR information is saved in the system. • The system displays the Queue Screen.

53 of 172


• The system fails to create the PASRR Level I. • An error is displayed indicating the reason for the failure to create the PASRR

Level I. • The system displays the Queue Screen.

Frequency On Demand

Security


CFR 431.300 to 307


54 of 172

UC-APPFUNCT-08: EMS Release

1. Description An Enrollment Management System (EMS) Release is a list of individuals, by PSA (Planning and Service Area), released from the Statewide Medicaid Managed Care (SMMC) Long Term Care (LTC) Program waitlist by DOEA to the ADRCs for assistance with enrollment in the SMMC LTC Program. 2. Level Summary 3. Trigger • An EMS Release Alert is generated in the system.

4. Primary Actor(s) • ADRC Staff (EMS Release Worker) • DOEA Staff


6. Preconditions • Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed. • A new EMS Release is generated in the system and the system creates an alert in the EMS Release

Queue.

55 of 172

3.9.1. Flow of Events: EMS Release Main Success Scenario (EMS Release) 1. The EMS Release Worker navigates to the EMS Release Queue from their Home Dashboard and the

system displays the EMS Release Queue. 2. The EMS Release Worker selects the EMS Release Alert and the system displays the Client Information

Screen. 3. The EMS Release Worker reviews the documentation required for the Medicaid waiver and selects

Generate Correspondence. 4. The system displays the Correspondence Screen and the EMS Release Worker selects the

Correspondence Type from the following drop-down list: o Category 1 – Some form of Medicaid/YES Form 5000-3008 o Category 2 – NO Medicaid/NO Form 5000-3008 o Category 3 – Some form of Medicaid/NO Form 5000-3008 o Category 4 – NO Medicaid/YES Form 5000-3008 o Category 5 – TXIX or SSI/YES Form 5000-3008 o Category 6 – TXIX or SSI/NO Form 5000-3008

5. The EMS Release Worker selects Send to Client. The system: o Generates the correspondence; o Sends the correspondence to the Client or Client Representative via their preferred contact

method; o Creates an EMS Release Alert on their Home Dashboard; and o Displays their Home Dashboard.

6. After confirmation from the client has been received, the EMS Release Worker selects the EMS Release Alert from their Home Dashboard and the system displays the Client Information Screen.

7. The EMS Release Worker selects Begin Timeline and the system sets the Applicant List (APPL) SMMC LTC enrollment span date on the Medicaid Waiver Timeline.

8. The EMS Release Worker selects Create Case once all documentation has been received, updates the case type to Assessment, updates the Case Worker to the CARES EMS Release Queue.

9. This Use Case ends. See Use Case UC-APPFUNCT-09: Create or Modify an Assessment. Extensions Exception 1 Premature Exit 2a If the user selects Cancel, the system returns the user to the previous screen. Exception 2 Individual Does Not Verify Interest in Pursuing Eligibility or is Unable to

Proceed 6a The EMS Release Worker selects the EMS Release Alert from their Home Dashboard and selects

Terminate from Waitlist on the Client Information Screen. 6b The EMS Release Worker selects one of the following Close Reasons:

o TALO/TPLO – Terminated APCL/APPL lost contact o TPNF – Terminated APPL no Form 5000-3008 o TPMA – Terminated APPL no Medicaid Application o TPIF – Terminated APPL Incomplete Financial Eligibility Process o TPCU – Terminated APPL CARES Unable to Assess for SMMC LTC Eligibility o TAHS/TPHS – Terminated APCL/APPL Client Hospitalized o TANH/TPNH – Terminated APCL/APPL Client in Nursing Home o TPMO/TAMO – Terminated APCL/APPL Client Moved

6c The system closes the individual’s Assessed Priority Consumer List (APCL) enrollment span, removes the individual from the waitlist, and displays the Client Information Screen.

Alternatives Alternative 1 Complete EMS Release 1. The EMS Release Worker selects the LOC Alert from their Home Dashboard and the system displays

the Case Screen.

56 of 172

2. The EMS Release Worker selects Send to DCF and the system displays the “Certification of Enrollment Status Home and Community-Based Services” (Form 2515).

3. The EMS Release Worker completes the required information and selects Submit. 4. The system updates the Medicaid Waiver Timeline with the date the information was submitted and

sends the information to DCF and the Enrollment Broker via a nightly batch process. 5. A batch file update is received from FMMIS and the system updates the client’s Medicaid Waiver

Timeline with the required information. Post Conditions Success End Condition

• The Case is created. • A message of successful completion is displayed. • The system displays the Waiver Release Report Screen.


• The Case is not created. • An error is displayed indicating the reason for the failure to save. • The system displays the Waiver Release Report Screen.

Frequency On Demand

Security


CFR 431.300 to 307


57 of 172

UC-APPFUNCT-09: Create or Modify an Assessment 1. Description The Assessment instrument and process provide the necessary information required to establish Level of Care to determine if the client requires nursing facility placement or home and community-based services. The Assessment instrument is conducted in an on-site, in-person setting to assess a client’s health, function, needs, and resources. It is used to complete an initial comprehensive assessment and an annual reassessment for clients enrolled in Department-funded, case-managed programs. In cases where an on-site visit is not required, a desk review or Medical Case File Review (MCFR) may be used instead to assess the client. 2. Level Summary 3. Trigger • An Assessment Task has been created and assigned to a user for completion.

4. Primary Actor(s) • CARES Staff

5. Other Actor(s) • Client • Client Representative • AAA/ADRC Staff • Lead Agency Staff/OAA Providers

6. Preconditions • Use Case UC-APPFUNCT-05: Schedule Screening or Assessment has been completed.

58 of 172

3.10.1. Flow of Events: Create or Modify an Assessment Main Success Scenario (Create CARES Assessment) 1. The Case Owner selects the Assessment Task from their Home Dashboard and the system displays the

Case Screen. 2. The Case Owner selects Conduct Assessment from the Case Screen. 3. The Case Owner selects an Assessment Type from the following drop-down list:

1. 701B – Comprehensive Assessment Form; 2. 701T – Mini Assessment Form (used for Nursing Facilities); or 3. MCFR – Medical Case File Review.

4. The system dynamically displays the Assessment Form based on the selected Assessment Type. 5. The Case Owner populates the form with information gathered from the client during the assessment. 6. The Case Owner selects Complete, the system computes the Priority and Rank Score (if required),

updates the Assessment Task to Complete, and displays the Case Screen. Extensions Exception 1 Invalid Data Entered 6a The Case Owner enters invalid information into a field or fails to complete required fields. 6b The system displays an error indicating the reason for the failure to save and defaults the Case Owner

to the first field with an error indicator such as a highlighted color. 6c The Main Success Scenario is joined at Step 5. Exception 2 Premature Exit 6a The Case Owner exits the Assessment prior to selecting Complete. 6b The system displays the message “Save Assessment?”

o The Case Owner selects Yes, the data entered is saved. When the user returns to the assessment, the system displays the last active field when the Case Owner exited the screen.

o The Case Owner selects No, the system discards data entered and displays the Assessment Task.

Alternatives Alternative 1 A Previous Assessment Exists for the Client 4a If a previous assessment exists, a message is displayed: “Copy Previous Assessment dated:

mm/dd/yyyy?” o The user selects Yes, assessment data from the previous assessment is populated to the

current assessment form and the Main Success Scenario is rejoined at step 5. o The user selects No, the Main Success Scenario is rejoined at step 4.

Alternative 2 Update Assessment Type while Conducting Assessment 5a The Case Owner updates the Assessment Type from the drop-down list, the system saves the

information entered, and dynamically displays or hides the additional questions. 5b The Main Success Scenario is rejoined at Step 5. Alternative 3 Lead Agency Role/OAA Provider Assessment 1. The Case Owner selects the client’s case from their Home Dashboard and the system displays the Case

Screen. 2. The Case Owner selects Conduct Assessment from the Case Screen. 3. The Case Owner selects an Assessment Type from the following drop-down list:

o 701A – Condensed Assessment Form; o 701B – Comprehensive Assessment Form; or o 701C – Congregate Meals Assessment Form.

4. The system dynamically displays the Assessment Form based on the selected Assessment Type. 5. The Case Owner populates the form with information gathered from the client during the assessment. 6. The Case Owner selects Complete, the system:

o Determines the Assessment type is a 701A or 701B and computes the Priority and Rank Score:

• Updates the Assessment Task to Complete; • Creates the Follow-Up Tasks; and

59 of 172

• Displays the Case Screen. • This Use Case ends. The flow continues with Use Case UC-APPFUNCT-10: Create or

Modify Care Plan. o Determines the Assessment Type is a 701C:

• Updates the Assessment Task to Complete; and • Displays the Case Screen.

7. The Case Owner enters a Case Note, selects the Close Reason from the drop-down menu, and selects Close.

8. The system updates the case status to Closed and displays the Case Owner’s Home Dashboard. Alternative 4 Modify Assessment 1. The Case Owner selects the case from their Home Dashboard and the system displays the Case

Screen. 2. The Case Owner selects Assessments from the Case Screen. 3. The system displays the list of assessments for the client. 4. The Case Owner selects Modify Assessment for the incomplete assessment. 5. The Case Owner populates the form with the required information and selects Save. 6. The system computes the Priority and Rank Score, updates the Assessment Task to Complete, and

displays the Case Screen. Post Conditions Success End Condition

• Required data is saved to the system. • A message of successful completion is displayed. • The system displays the Case Screen.


• Required data fails to save to the system. • An error is displayed indicating the reason for the failure to save. • The system displays the Case Screen.

Frequency On Demand

Security


CFR 431.300 to 307


• The ability to enter assessment data be accessible and usable via mobile devices such as tablets with a cellular wireless connection.

• The ability to enter assessment data must be available in an offline mode with a synchronization of the data after reconnection to the system.


60 of 172

UC-APPFUNCT-10: Create or Modify Care Plan 1. Description The Care Plan is a plan of action developed in conjunction with the client, caregiver, and/or designee. The Care Plan is a tool used by the Case Manager to document a client’s assessed needs, services to be provided, and costs associated with the provision of services to assist with the management of the client’s care.

2. Level Summary 3. Trigger • A Lead Agency has been referred a client for case management.

4. Primary Actor(s) • Lead Agency Staff/OAA Providers

5. Other Actor(s) • AAA/ADRC Staff • Client

6. Preconditions • Use Case UC-APPFUNCT-09: Create or Modify an Assessment has been completed.

61 of 172

3.11.1. Flow of Events: Create or Modify Care Plan Main Success Scenario (Create Care Plan) 1. The user selects the assigned case from their Home Dashboard and the system displays the Case

Screen. 2. The user selects Create Care Plan. 3. The system displays a blank Care Plan form. 4. The user selects Services Needed, the system displays the Services Needed information, and the user

enters the following information: o PSA; o Date; o Service; o Units; o Type; o Frequency; and o End Date.

5. The user selects Save and the system displays the Services Planned section prepopulated with from the Services Needed information.

6. The user enters the following Services Planned information: o Program; o Units; o Type; o Frequency; o Start Date; and o End Date.

7. The user selects Complete. 8. The system displays a PDF of the Care Plan and three options for obtaining client, caregiver, and/or

designee signature. o The client is in person and wishes to sign. The user presents the client with an on-screen

PDF of the Care Plan with an associated signature box for the client to sign electronically. o The user is remote and has an email on record for the client. The system will automatically

send a copy of the Care Plan to the client for signature. o The user is remote and does not have an email on record for the client. The user will print

the Care Plan and mail or hand deliver to the client for signature. 9. Once the signed Care Plan is received and attached to the Client’s Record the user selects Close Case

from the Case Screen. 10. The user enters a Case Note, selects the Close Reason from the drop-down menu, and selects Close. 11. The system updates the case status to Closed and displays the user’s Home Dashboard. Extensions Exception 1 Invalid Data Entered 7a User enters invalid information into a field or fails to complete required fields. 7b The system displays an error indicating the reason for the failure to save and defaults the user to the

first field with an error indicator such as a highlighted color. 7c The Main Success Scenario is joined at step 4. Exception 2 Premature Exit 4a If the user selects Cancel, the system returns the user to the previous screen. Exception 3 Case has Open Follow-ups or Tasks assigned to the Case 9a If tasks linked to the case are open, the system displays a pop-up message: “The case cannot be

closed until the following tasks are completed [system displays list of open tasks with an option to close the tasks].”

9b Once all tasks associated with the case are closed, the user enters a Case Note, selects the Close Reason, and selects Close.

9c The system updates the case status to Closed and displays the Client Information Screen.

62 of 172

Alternatives Alternative 1 Previous Care Plan Exists 3a The system displays a message “Copy Previous Care Plan dated: mm/dd/yyyy?”

o If the user selects Yes, data from the previous Care Plan is populated to the current Care Plan Form and the Main Success Scenario is rejoined at step 4.

o If the user selects No, the Main Success Scenario is rejoined at step 3. Alternative 2 Modify Care Plan 1. The user selects the assigned case from their Home Dashboard and the system displays the Case

Screen. 2. The user selects Existing Care Plan from the Case Screen. 3. The system displays the existing Care Plan. 4. The user selects the Care Plan needing modification, selects Edit, adds, removes, or updates the

services on the Care Plan, and selects Complete. 5. The system saves the Care Plan and displays the Care Plan Screen. Post Conditions Success End Condition

• The Care Plan is saved. • A message of successful completion is displayed. • The system displays the Case Screen.


• The Care Plan fails to save to the system. • An error is displayed indicating the reason for the failure to save. • The system displays the Case Screen.

Frequency On Demand

Security


CFR 431.300 to 307


• The ability to enter care plan data must be accessible and usable via mobile devices such as tablets with a cellular wireless connection.

• The ability to enter care plan data must be available in an offline mode with a synchronization of the data after reconnection to the system.


63 of 172

UC-APPFUNCT-11: Determine Level of Care (LOC) 1. Description An Assessor or Registered Nurse Specialist (RNS) determines a Level of Care (LOC) and enters the recommendation based on their medical professional knowledge and skills. The LOC is used to determine the client’s medical eligibility for a Medicaid waiver, Programs, and Nursing Facility and is based on the criteria found in Section 409.985, F.S., and Rules 59G-4.180 and 59G-4.290, F.A.C. In some cases, it is determined the client does not meet the Level of Care. In this instance, a No Level of Care (NLOC) recommendation is submitted and must be reviewed before the recommendation can become a part of the client’s record. 2. Level Summary 3. Trigger • An assessment has been completed and the client needs a LOC determination for staffing purposes.

4. Primary Actor(s) CARES Staff including:

• Assessor • RNS • Physician • CARES Assessor Supervisor (CAS) • Registered Nurse Supervisor (RN Supervisor) • Registered Nurse Consultant (RNC) • Program Operation Administrators (POA) • Regional Program Supervisor (RPS)


6. Preconditions • Use Case UC-APPFUNCT-09: Create or Modify an Assessment has been completed.

64 of 172

3.12.1. Flow of Events: Determine Level of Care (LOC) Main Success Scenario (Determine Level of Care (LOC)) 1. The Case Owner selects Level of Care Recommendation from the Case Screen. 2. The Case Owner enters the LOC Justification and selects Save. 3. System displays the DOEA-CARES Form 603 with the Client Demographic and current PASRR fields

populated from the client’s case information. 4. The Case Owner verifies the PASRR information, enters the LOC, Place and Program

Recommendations, effective date, and selects Complete. 5. The Case Owner enters any additional information needed and selects Save. 6. The system saves the information and displays the Staffing Screen. This Use Case ends. See Use Case

UC-APPFUNCT-12: Finalizing Level of Care (LOC) Determination (Staffing). Extensions Exception 1 Invalid Data Entered 4a The Case Owner enters invalid information into a field or fails to complete required fields. 4b The system displays an error indicating the reason for the failure to save and defaults the Case Owner

to the first field with an error indicator such as a highlighted color. 4c The Main Success Scenario is joined at Step 3. Exception 2 Premature Exit 5a The Case Owner exits the LOC Form prior to entering the LOC Justification. 5b The system displays the message “Save LOC?”

o The Case Owner selects Yes and the data entered is saved. When the user returns to the LOC Form, the system displays the last active field when the Case Owner exited the screen.

o The Case Owner selects No, the system discards data entered, and displays the Case Screen. Alternatives Alternative 1 No Level of Care Recommendation 6a The system displays a CARES Individual Review of No Level of Care (NLOC) Recommendation 610

Form, populates the form with case information data, creates a NLOC Task, updates the Task Reviewer per business rules, and places an alert on the reviewer’s Home Dashboard.

6b The reviewer logs into the system and selects the NLOC Task from their Home Dashboard. 6c The system displays the NLOC Form.

6d The reviewer updates the NLOC Form, enters review notes, and selects Save. 6e The system displays the reviewer’s Home Dashboard, reassigns the task as defined by business rules

until all required reviewers have reviewed and updated the NLOC Form as appropriate, and assigns the NLOC task to the Case Owner.

6f The Case Owner selects the NLOC Task from their Home Dashboard and the system displays the NLOC Form.

6g The Case Owner reviews the notes, enters a justification if needed, and selects Save. 6h The system saves the information and displays the Staffing Screen. This Use Case ends. See Use Case

UC-APPFUNCT-12: Finalizing Level of Care (LOC) Determination (Staffing). Post Conditions Success End Condition

• The Level of Care is saved for the client. • The system displays the Case Screen.


• The system fails to save the Level of Care. • An error is displayed indicating the reason for the failure to save the Level of Care. • The system displays the Case Screen.

Frequency On Demand

Security • Chapter 74-2, Florida Administrative Code; • Section 282.318, Florida Statutes; • 45 CFR Part 164, P.L. 104-191, HIPAA of 1996; and

65 of 172

• 1902(a)(7) of the Social Security Act as further interpreted in regulations at 42 CFR 431.300 to 307


• The ability to determine a LOC should be accessible via mobile devices such as tablets with a cellular or Wi-Fi connection.


66 of 172

UC-APPFUNCT-12: Finalizing Level of Care (LOC) Determination (Staffing) 1. Description Upon completion of an assessment, CARES staff must determine if an individual meets medical criteria (Level of Care) for a nursing facility, Medicaid, or community-based Medicaid Programs. These decisions are finalized in an interdisciplinary team meeting called “staffing.” The goal of staffing is to assign the appropriate and correct Level of Care, program recommendation, and placement recommendation.

2. Level Summary 3. Trigger • A Level of Care Recommendation needs finalization signatures.

4. Primary Actor(s) • CARES Staff • Physician

5. Other Actor(s) • Client • AAA/ADRC Staff

6. Preconditions • Use Case UC-APPFUNCT-11: Determine Level of Care (LOC) has been completed.

67 of 172

3.13.1. Flow of Events: Finalizing Level of Care (LOC) Determination (Staffing) Main Success Scenario (Finalizing Level of Case (LOC) Determination (Staffing)) 1. The Case Owner selects Attach Staffing Document(s) from the Staffing Screen and the system

displays a list of the electronic documents attached to the client record. 2. The Case Owner chooses the required document(s) for staffing and selects Attach. 3. The system places a hyperlink for each selected document on the Staffing Screen, generates the

Summary of Details document from the assessment data, and links it to the Staffing Screen. 4. The Case Owner enters any additional required information and selects Save. 5. The system checks to confirm documentation required for staffing has been selected as defined by

business rules and displays the Staffing Screen. 6. The Case Owner selects the staffing date and time from the Staffing Calendar and selects Save. 7. The system updates the case status to Pending Staffing, creates a Staffing Task, assigns the Staffing

Task per business rules, places a Staffing Appointment on the Case Owner’s calendar, and displays the Case Screen.

8. The Physician or CARES RNS logs into the system, selects the Staffing Task from their Home Dashboard, and the system displays the Staffing Screen.

9. The Physician or CARES RNS reviews the attached forms, client documentation, the LOC, and Recommended Placement and Program for the client.

10. The Physician or CARES RNS selects Confirm from the Staffing Screen and the system displays the DOEA-CARES Form 603 with an associated signature box for them to sign electronically or print and sign manually.

11. The system saves the information to the client’s case, reassigns the Staffing Task to the Case Owner, and displays the Physician’s or CARES RNS’s Home Dashboard.

12. The Case Owner accesses the Staffing Task from their Home Dashboard and the system displays the Staffing Screen.

13. The Case Owner selects Complete and Send LOC. 14. The system sends the LOC information and additional required documents via email or integrated

fax to DCF, Enrollment Broker, and Nursing Facilities (if needed) via a batch process according to business rules, and creates Follow-up Tasks per business rules.

15. The system updates the task status to Complete and displays the Case Screen. 16. The Case Owner enters a Case Note, chooses the Close Reason, and selects Close Case. 17. The system updates the case status to Closed and displays the Client Information Screen. Extensions Exception 1 Missing Documentation 5a A message is displayed to the user with a list of possible missing documentation. 5b The Main Success Scenario is joined at Step 2. Exception 2 LOC, Recommended Placement or Program Needs to be Updated Prior to

Completion 9a The Physician or CARES RNS selects Return to Case Owner. 9b The task is assigned to the selected Case Owner. The Case Owner updates the Staffing Screen with

the needed corrections, assigns the case back to the Physician or CARES RNS to continue with the Staffing process, and selects Save.

9c The Main Success Scenario is joined at Step 8. Exception 3 Case has Open Follow-ups or Tasks assigned to the Case 16a If tasks linked to the case are open, the system displays a pop-up message: “The case cannot be

closed until the following tasks are completed [system displays list of open tasks with an option to close the tasks].”

16b Once all tasks associated with the case are completed, the user enters a Case Note, selects the Close Reason, and selects Close.

16c The system updates the case status to Closed and displays the Client Information Screen.

68 of 172

Alternatives Alternative 1 Complete Staffing with NLOC Recommendation 13a The system displays the Case Note screen. 13b The Case Owner enters the NLOC Justification Reason and selects Save. 13c The Main Success Scenario is rejoined at Step 14. Alternative 2 EMS Release Individual 14a The system updates the task status to Complete, sends a Completed LOC Alert to the EMS Release

Worker, enters the LOC Date on the Medicaid Waiver Timeline, and displays the Case Screen. 14b The Main Success Scenario is rejoined at Step 15. Post Conditions Success End Condition

• The system saves the information. • A message of completion is displayed to the user. • The system displays the Client Information Screen.


• The system fails to save the information. • An error is displayed indicating the reason for the failure to save. • The system displays the Client Information Screen.

Frequency On Demand

Security


431.300 to 307




69 of 172

UC-APPFUNCT-13: Create Ad Hoc Follow-up Task 1. Description A Follow-up Task is created to alert the Case Owner to contact the client within a specified number of days for various reasons (e.g., client satisfaction, client placement, quality assurance, etc.). While most follow-ups are scheduled automatically by the system, the user may need to schedule an Ad Hoc Follow-Up Task when additional follow-ups are required outside of the pre-defined system tasks.

2. Level Summary 3. Trigger • An open case requires someone to follow up on information before the case can be closed.




70 of 172

3.14.1. Flow of Events: Create Ad Hoc Follow-up Task Main Success Scenario (Create Ad Hoc Follow-up Task) 1. The user selects the assigned case from their Home Dashboard. 2. The system displays the Case Screen. 3. The user selects Create Ad Hoc Follow-Up and system displays the Follow-up Form. 4. The user selects the Due Date and selects Save. 5. The system creates a task categorized as follow-up, assigns the task to the user, and places an alert

on the user’s Home Dashboard. Extensions Exception 1 Invalid Data Entered 4a User enters invalid information into a field or fails to complete required fields. 4b The system displays an error indicating the reason for the failure to save and defaults the user to the

first field with an error indicator such as a highlighted color. 4c The Main Success Scenario is joined at step 4. Exception 2 Premature Exit 4a The Case Owner exits the Follow-up Form prior to entering the Follow-up Due Date. 4b The system displays the message “Save Follow-up?”

o The Case Owner selects Yes and the data entered is saved. When the user returns to the Follow-up Form, the system displays the last active field when the Case Owner exited the screen.

o The Case Owner selects No, the system discards data entered, and displays the Case Screen. Post Conditions Success End Condition

• The Follow-up Task is saved to the system. • A message of successful completion is displayed. • The system displays the Case Screen.


• The Follow-up Task fails to save to the system. • An error is displayed indicating the reason for the failure to save. • The system displays the Case Screen.

Frequency On Demand

Security


CFR 431.300 to 307


71 of 172

UC-APPFUNCT-14: Complete Follow-up Task 1. Description Follow-up tasks are created to ensure the Case Owner gathers the additional required information within a specified number of days. The information obtained during the follow-up should be documented in the task and the case updated accordingly. Once the Follow-up Task is complete, additional Follow-up Tasks can be created, or the case can be closed with no further action required by the Case Owner. 2. Level Summary 3. Trigger • A Follow-up Task has been scheduled and is due to be completed.

4. Primary Actor(s) • AAA/ADRC Staff • CARES Staff • Lead Agency Staff/OAA Providers


6. Preconditions • Use Case UC-APPFUNCT-04: Referral Case has been completed. • Use Case UC-APPFUNCT-12: Finalizing Level of Care (LOC) Determination (Staffing) has been

completed. • Use Case UC-APPFUNCT-10: Create or Modify Care Plan has been completed.

72 of 172

3.15.1. Flow of Events: Complete Follow-up Task Main Success Scenario (Complete Follow-up Task) 1. The user selects the Follow-up Task from their Home Dashboard. 2. The system displays the Follow-Up Task. 3. The user performs the follow-up activities, updates the Follow-up Task, and enters appropriate case

notes. 4. The user selects Complete. 5. The system updates the task status to Closed, schedules a future follow-up task as defined by business

rules, and displays the user’s Home Dashboard. Exceptions Exception 1 Invalid Data Entered 4a The user enters invalid information into a field or fails to complete required fields. 4b An error is displayed indicating the reason for the failure to save. 4c The Main Success Scenario is rejoined at Step 3. Exception 2 Premature Exit 4a The Case Owner exits the Follow-up Form prior to selecting Complete. 4b The system displays the message “Save Follow-up?”

o The Case Owner selects Yes and the data entered is saved. When the user returns to the Follow-up Form, the system displays the last active field when the Case Owner exited the screen.

o The Case Owner selects No, the system discards data entered, and displays the Case Screen. Alternatives Alternative 1 Complete Follow-up and Close Case 4a The user selects Close Case. 4b The system updates the task status to Closed, deletes any scheduled Follow-up Tasks from the case,

updates the Case Status to Closed, and displays the user’s Home Dashboard. Post Conditions Success End Condition

• The system saves the information to the client’s case. • The system displays the user’s Home Dashboard.


• An error is displayed indicating the reason for the failure to save. • The system displays the user’s Home Dashboard.

Frequency On Demand

Security


CFR 431.300 to 307


73 of 172

Case Management Requirements


Business 1 Security The system shall have the ability to display an assessment or screening based on the current user's role.


The system shall allow for Enrollment Management System (EMS) Waitlist tracking.

Business 3

Database Architecture, Business Rules Engine

The system shall allow the ADRC to place a LOC request for a client with categories: EMS, APS, SIXT.

Functional 6 Correspondence and Forms

The system shall allow for the attachment of the client's Department of Children and Families (DCF) 2515 and 603 forms for completion once LOC is completed.

Functional 7 Workflow The system shall allow for automated notification to appropriate ADRC staff of completion of an LOC for a client if it originated from the ADRC via a Waitlist release.

Business 8 Workflow

The system shall provide the ability to notify predetermined user(s) of a submitted PASRR Level I and PASRR Level II when initiated through integrated fax or scan technology.

Business 9 Mobility The system shall provide a mechanism for authorized users to securely access needed system functionality offsite to support work events away from the office.




The system shall enable authorized users to add case types and attributes via configuration tables without a requirement to update programming code or compiling any software.


Functional 27 Events and Scheduling

The system shall provide the ability to modify existing scheduled events (e.g., begin date, end date, frequency, and business process-specific information).


The system shall provide the ability to notify the user of a scheduled event based on user-defined criteria or business rules within a workflow (e.g., reminder time, delivery mechanism).


The system shall provide the ability to link documentation to a scheduled appointment task or event.


The system shall allow authorized users to set threshold parameters on the results provided by the priority and rank scoring algorithm for use by the system to automatically initiate workflow actions without further intervention from the user.


The system shall provide the ability to create, modify and deploy a ranking and priority algorithm at the database level and initiated according to workflow actions and associated business rules.

74 of 172

Functional 34 Workflow The system shall update a client's MedWaiver pipeline checklist when a completed 3008 form is received and the client's status indicates an active pipeline status code.

Functional 35 Workflow

The system shall provide the ability to move a client currently in the MedWaiver APPL and APCL from one PSA to different PSA without disenrollment from their current MedWaiver APPL status. The system shall provide a notification of the action to the receiving PSA as defined by business rules.


The system shall allow for a client return to the MedWaiver pipeline without requiring a waitlist release after termination if requirements are met according to business rules. Examples of requirements for the conditional return to the Pipeline can be found on page 28 of the SMMC LTC EMS Procedures.doc.


The system shall provide the ability to utilize business rules to associate a scheduled event with the appropriate system records (e.g., case record to an appointment).

Functional 38 Application Functionality

The system shall provide users with a 701S Screening screen allowing authorized users to enter data as a telephonic screening is being conducted. This form contains a subset of fields available on the 701B Comprehensive Assessment. An example of the 701S Screening screen fields in the current CIRTS system is shown on page(s) 75 - 81 of the CIRTS_User_Guide_for_CARES 2013.pdf.


The system shall provide Medicaid Waiver Waitlist termination codes to track a client within the EMS enrollment span. An example of the report fields in the current CIRTS system is shown on page 53 of the SMMC LTC EMS Procedures.doc.


The system shall provide the ability to create, modify and delete EMS Waitlist Release Eligibility categories with correspondence codes and category descriptions. An example of the categories in the current CIRTS system is shown on page 14 of the SMMC LTC EMS Procedures.doc.


The system shall allow the ability to configure MedWaiver enrollment status allowed for concurrent enrollment based on type of enrollment and business rules. (e.g., it is not permitted to have a SIXT status at the same time as an APCL or APPL, it is not permitted to be in the PACE program and SMMC LTC at the same time).

Functional 43 CRM The system shall have the ability to track a client's enrollment on a waiver, OAA Program, or general revenue program waitlist.

Functional 44 CRM The system shall have the ability to track a start and end date of each client's enrollment on a waiver, OAA Program, or general revenue program.

Functional 45 CRM Client screen should display the client's current MedWaiver status.

Functional 46 CRM The system shall have the ability to automatically end the enrollment on individual program waitlists when they have

75 of 172

been moved to the MedWaiver Pipeline for SMMC LTC programs.


The system shall allow for the ability to complete an Eligibility Research checklist when a client is released from the Enrollment Management System (EMS) Waitlist.


The system shall provide the ability for an authorized user to create an EMS Waitlist Release checklist to be verified by the user prior to the release process. An example of the verification checklist is shown on page 14 of the SMMC LTC EMS Procedures.doc.


The system shall not allow a client EMS Release Status to reflect an active pipeline status code until the client demographic information such as SSN, First Name, Last Name and Date of Birth has been matched to FMMIS.


The system shall allow for a client's APPL enrollment status to update to complete and the MedWaiver pipeline to update with a closure date when the client status indicates enrolled in SMMC LTC.


The system shall enable downloading a printable view of (blank, completed or partially completed) online forms.


The system shall have the ability to determine which fields should be required and visible based on the type of 701 series assessment the user is completing.


The system shall allow for completion of the 701 Assessment and Screening Tool. An example of the 701B Comprehensive Assessment screen fields in the current CIRTS system is shown on page(s) 33 - 74 of the CIRTS_User_Guide_for_CARES 2013.pdf.


The system shall provide the ability to copy field data between data entry screens if common fields exist and are populated (e.g., copy data entered on a 701T screen to a 701B screen).


The system shall allow for the copying of previous assessment form data into a new assessment data entry screen for editing.


The system shall allow for the copying of shared data between common fields within a data entry screen (e.g., addresses, prescribing physicians for medications, etc.).


The system shall enable an authorized user to record assessment information on a Wi-Fi and cellular connected mobile device, as well as when offline.

Functional 60 Mobility The system shall enable authorized users to suspend a data entry screen and save the entered data information on a mobile device as a work in progress, including when offline.

Functional 61 Mobility The system shall provide the ability for a user to prepare for offline actions by downloading required data, forms, etc. prior to disconnecting from the system.


The system shall perform automated background saves on data entry screens at predetermined or configurable intervals to reduce the occurrence of lost data.

76 of 172


The system shall provide a positive acknowledgement the data entry has been accepted.


The system shall provide the ability, where appropriate, to save work in progress as a user-initiated action.


The system shall require a client SSN when a user attempts to add a client to a Medicaid Waiver/Program Waitlist by changing the client status to APCL, indicating they are on the assessed priority consumer list. The system shall present a message to the user "SSN is required when changing client status to APCL."


The system shall provide users with a Case Screen providing the ability to view cases related to a client, including options to add a new case, modify, close or reassign current cases. An example of the case screen fields in the current CIRTS system is shown on page 24 of the CIRTS_User_Guide_for_CARES 2013.pdf.


The system shall provide users with the ability to view a client's case note history in a list format allowing for the sorting of notes by column headings. At a minimum the column headings should include case note entry date, category, entered by user, PSA, date of event if different from date entered and a snippet of the case note. This screen should be accessible from the client's current or past Case screen. An example of a case note history screen in the current CIRTS system is shown on page(s) 116 - 122 of the CIRTS_User_Guide_for_CARES 2013.pdf.


The system shall display abbreviated client information on all screens presented to the user related to the client (e.g., the Care Plan Screen display a read-only view of the client's Name, SSN, Date of Birth).


The system shall allow partial save of data entry screens based on business rules once the required fields have been updated.


The system shall restrict users from completing a data entry screen until all required information is entered.


The system shall enable authorized users to override established dates as guided by the business rules.




The system shall provide the ability to maintain notifications based on business processes and system events.


The system shall allow the ability to create/modify/delete/save form data.


The system shall display the remaining free-text fields character count on data entry screens.


The system shall allow for electronic signature in compliance with Chapter 668, Florida Statutes.

77 of 172

Functional 128 CRM

The system shall provide the ability to communicate with clients or providers based on their preferred communication method (e.g., email notifications, fax, paper).

Functional 131 CRM The system should allow for a user or predefined condition to mark a client record as confidential so that only specific roles can access the client record and its related data.


Functional 133 CRM The system shall provide the ability to display customizable lists or menus for field completion.

Functional 135 CRM

The system shall provide a user dashboard to allow for quick and easy access to scheduled events, tasks, follow-ups, documents and alerts as they are associated with client or provider records.


The system shall provide the user with predefined selectable lists wherever possible. Drop-down lists, radio buttons and "lookup" tables will maximize the entry of correct and complete data and will ensure that business rules are followed.


Wherever applicable, the system shall provide pick lists and/or multi-pick lists instead of manual text entry. Pick lists shall not force a refresh of the screen after selection.


The system shall enable users to enter multiple characters to select a specific choice from a pick list. For example, the user should be able to enter “Jac” to get to Jacksonville rather than typing J several times to move through list to Jacksonville.


The system shall enable authorized users to create and maintain lists to be used as predefined selectable drop-down lists, radio buttons, and "lookup" tables.










The system shall enable users to search on available indexed help topics.


The system shall enable authorized users to create, maintain, search, and view system Frequently Asked Questions (FAQs) and their answers.


The system shall provide the ability to execute system events based on a user-configurable schedule.


The system shall provide a graphical calendar object to select from when entering or changing dates.

78 of 172

Functional 162 Integrated Imaging

The system shall provide the ability to systematically associate supporting documents to a client record or provider record (e.g., images, faxes, scanned physical and electronic documents).


The system shall provide document digital imaging functions that allow the user to view digital facsimiles of documents that are generated and associated with the system functions. The document digital imaging functions shall provide for easy duplicate printing of the selected document.

Functional 164 Integrated Imaging The system shall provide the ability to retrieve and view imaged documentation provided by users and clients based on business rules.




The system shall have the ability to process emails according to business rules in which the email message is sent with a specific subject line, contains particular keywords within the body of the message or is sent to a particular email address.

Functional 174 Mobility The system shall provide secure remote access for authorized users using wireless internet-enabled mobile computers or handheld devices.

Functional 175 Mobility The system shall provide the ability to securely record and to automatically synchronize data as it is captured between a mobile device and the system when offline.

Functional 176 Mobility

The system shall provide the ability to setup, modify, edit version control on documents maintained within the system allowing the user to view version history and restore previous versions as provided by their role.

Functional 178 Mobility

The system shall provide the ability of displaying audit trail information reflecting system activity by any user, either internal or external, to include data actions such as read/write/update/delete and archiving and printing. Audit trail information should also include date, time, and function of the data action.

Functional 179 Record Management and Audit

The system shall protect information and tools from unauthorized access, modification, and deletion.

Functional 180 Mobility The system shall use internal system clocks to generate time stamps for audit records.






The system shall provide the ability to remediate a system message without navigating to another screen (e.g., a display message, "All tasks must be closed close prior to closing the case" should allow the list of open tasks to be presented for user action).



79 of 172






The system shall enable users to select and view information about an individual record when a search returns a list of records.


















The system shall provide the ability to include unstructured data in query results (e.g., Microsoft Word documents, Adobe Acrobat PDF files).








The system shall provide the ability to prompt the user to save work in progress prior to navigating to a new business function.


The system shall provide users search screens displaying fields in relation to where the user is within the system. (e.g., if the user is on the Services Screen, the search fields relevant to searching for services and referrals should be displayed to the user).



80 of 172


Functional 211 Security

The system shall provide access to data and functionality at the most granular level available (i.e., field level for data and screen access, document type for documents, and individual menu item for functionality).




Functional 220 Usability

The system shall provide data quality editing, consistency and validity checks on data elements at the point of data entry. The system shall display a meaningful error message and prevent entry of data that does not pass edit checks.

Functional 221 Usability The system shall display meaningful descriptions in the place of system codes (e.g., 'Male' instead of 'M').

Functional 222 Usability The system shall provide configurable messages to the user in the event of a system error (e.g., technical information, resolution required).

Functional 223 Usability The system shall provide the ability to execute "copy and paste" functionality with third-party applications (e.g., Microsoft Word) per business rules.

Functional 229 Workflow The system shall be able to utilize preconfigured due dates and apply them at the action level when the action is created within the workflow.

Functional 238 Workflow The system shall allow for the users to assign and reassign cases, tasks, and appointments to other users of the system based on the user's role.

Functional 239 Workflow The system shall either notify the user or shall trigger a workflow when entered information does not match existing known information based on business rules.


The system shall enable managing client data and creating assessment and screening process workflows for an unlimited number of DOEA, AAA, ADRC, and Lead Agency activities.

Functional 258 Workflow The system shall notify the appropriate authorized users of work that has been routed to them.

Functional 259 Workflow The system shall enable ensuring that all the business rules associated with an activity have been satisfied before the next activity in the workflow is allowed to start.

Functional 260 Workflow When work associated with a workflow process activity has been completed, the system shall automatically route the work to the next process.

Functional 261 Workflow The system shall provide for each authorized user an electronic work queue (‘inbox’) capability to show assigned work.

81 of 172

Functional 262 Workflow The electronic work queue capability shall enable multiple options for sorting and filtering views of assigned work.

Functional 273 Workflow The system shall provide the ability to route a work item within a workflow.

Functional 282 Workflow The system shall provide authorized users the ability to assign priority to work items based on administrator-defined business rules.

Functional 285 Workflow The system shall provide the ability to create tasks from system and user-initiated events.


The system shall provide the ability to initiate a workflow through the receipt of an electronic form or occurrence of a system event (e.g., uploaded form, imaged documentation, receipt of referral, appointment scheduled, receipt of requested documentation).

Functional 288 Workflow The system shall provide the ability to move work items between workflow steps based on defined workflow rules.

Functional 292 Workflow The system shall provide the ability to add text-based notes to the work item or task.


The system shall provide the ability to issue administrator-defined time-based reminders (e.g., task not processed within defined time frames, task not yet assigned, processing on the task has not been initiated).

Functional 294 Workflow The system shall provide the ability for a reviewer to reject the task and return it to the original sender.

Functional 295 Workflow The system shall provide the ability to refer tasks to users outside of the assigned workflow.

Functional 296 Workflow The system shall provide the ability to close a task assignment based on administrator-defined business rules.

Functional 300 Workflow The system shall provide the ability to sort tasks by one or multiple task attributes.

Functional 301 Workflow The system shall include a drag-and-drop feature that will facilitate the manual assignment of work items where applicable per business rules.


The system shall provide authorized users to associate templated document creation actions to a workflow process according to business rules. (e.g., associate creation of a PASSR Notification document to the PASRR Level II request task).


The system shall create alerts according to business rules and apply a verification required status code to documents ingested into the system by OCR scan or fax technology when the OCR process determines the data integrity does not meet a pre-configured accuracy threshold. The verification required status code is removed after user intervention is used to confirm data accuracy.


The system shall provide a capability to prioritize cases based on business requirements.


The system shall provide users with a 701B Comprehensive Assessment screen allowing authorized users to enter data as an onsite assessment is being conducted. This form should be available in offline mode

82 of 172

and on mobile devices. An example of the 701B Comprehensive Assessment screen fields in the current CIRTS system is shown on page(s) 33 - 74 of the CIRTS_User_Guide_for_CARES 2013.pdf.


The system shall display a configurable list of fields on the 701B, 701T, and 701S screens including at a minimum the ClientID and Name, Priority Score, Rank, PSA and the OwnerID if the client is being processed by the Aging Network. An example of these fields can be found on page 35 of the CIRTS_USER_Guide_for_CARES 2013.pdf.

Functional 315 Mobility The system shall enable the external user or client to electronically sign on the mobile device to indicate documentation has been received.

Functional 316 Workflow The system shall allow the ability for authorized users to identify the availability of data entry screens on a mobile application platform.


The system shall provide users with the ability to view a list of past and current assessments provided to the client from the Client Screen. The list shall be a collection of links to view the Assessment Screen. An example of the View Assessments screen fields in the current CIRTS system is shown on page 30 of the CIRTS_User_Guide_for_CARES 2013.pdf.

Functional 321 Workflow The system shall allow for systematic case closure within the workflow when preconfigured business rules have been completed.


The system shall allow for the configuration of case types to be determined when the case is opened (e.g., Initial Assessment, Transferred Assessment, Reassessment Assessment, Annual Waiver Assessment, 701 Screening, Information Only).

Functional 324 Workflow The system shall prompt the user to open a new case or select an existing case if an assessment or screening is begun without navigation to a case screen.

Functional 327 Mobility The system shall provide local user authentication when the mobile computer or device is offline.

Functional 328 Mobility The system shall enable authorized users to view, capture, store, print, scan, and maintain data remotely using a mobile device.


The system shall provide users with a PASRR screen allowing authorized users to enter or modify a client's PASRR information. An example of the PASRR screen fields in the current CIRTS system is shown on page(s) 86 - 92 of the CIRTS_User_Guide_for_CARES 2013.pdf.


The system shall display the fields required for PASRR Level II data entry dependent on field values supplied during the PASRR Level I data entry.


The system shall set a PASRR Level I client data set as complete with an indicator to the user when all required fields have been entered, allowing the client case to proceed to the Staffing and Level of Care (LOC) process.

83 of 172


The system shall allow for the ability to generate and update a client's record with a medications list from an internal or external database (e.g., this should be a searchable picklist).


The system shall provide a link to the KEPRO portal from key navigation points and workflow actions as determined by business rules.


The system shall provide users with a 701T Assessment screen allowing authorized users to enter data as an on-site assessment is being conducted. This form should be available in offline mode and on mobile devices. This form contains a subset of fields available on the 701B Comprehensive Assessment. An example of the 701T Assessment screen fields in the current CIRTS system is shown on page(s) 81 - 83 of the CIRTS_User_Guide_for_CARES 2013.pdf.


The system shall provide users with a Follow-up screen displaying past and current follow-ups and allowing authorized users to add new ad hoc follow-ups or modify a client's current follow-up. This screen should include at a minimum the follow-up schedule date, follow-up type, performer of the follow-up, follow-up status, completed date, and PSA. An example of the Follow-up screen fields in the current CIRTS system is shown on page(s) 108 - 115 of the CIRTS_User_Guide_for_CARES 2013.pdf.


The system shall provide a capability to notify the user in a preconfigured number of days when no response has been received from a third party.


The system shall enable scheduling, assigning, and tracking of tasks based on business rules.


The system shall allow for direct email from the system to recipients selected by workflow actions or a user action.

Functional 358 CRM The system shall allow an optional date range to be applied to the client record address field(s).


The system shall provide the ability to generate appointment confirmation notifications.


The system shall have the capability to provide scheduling/availability requirements such as allotted hours or minutes for scheduling of tasks, events, follow-ups (e.g., default amount of time to place on a calendar when scheduling assessments, screenings, monitoring, etc.).


The system shall allow for the scheduling of appointments, events and tasks.


The system shall enable authorized users to update client contact information.


The system shall provide the ability to associate comments with the scheduled events.

Functional 366 Integrated Imaging The system shall provide the ability to manually associate correspondence to the appropriate case, client, or provider file.

84 of 172


The system shall enable an authorized user to create case types, case process workflows, and modify existing case types to reflect business rules.


The system shall enable an authorized user to configure the process for each case type per business rules.


The system shall allow the user to edit, modify, change data within a data entry screen until the completion has been indicated by the user or by established business rules.


The system shall allow the user to set the priority status of a case, task or calendar event as high or low independent of the automated process workflow.


The system shall provide the option to configure notifications to users upon appointment changes in the system.


The system shall allow for authorized users to schedule appointments on their own calendar as well as other users' calendars as defined by their role.

Functional 376 CRM The Client Screen should display a link to documents related to the client record (e.g., 3008, 701A, LOC, etc.).

Functional 377 CRM The system shall provide the ability to update client demographic data based on defined roles within the system.

Functional 383 CRM The system shall support assignment of due date and time.

Functional 386 CRM The system shall allow for a form to be completed and marked as a record (e.g., PDF form provided by external entities such as AHCA or internal DOEA PDF forms).


The system shall provide the ability to search the taxonomy by code and keyword.


The system shall provide the ability to mark a service or resource as a priority record forcing it to appear in the top of search results.


The system shall provide authorized users a data entry screen to add, modify and remove resource and service data for Services.


The system shall provide the ability to group services such that they can be reused for multiple agencies offering the same services. (e.g., Homeless Services: shelter, clothing, showers)


The system shall provide the ability to set parameters for service sites based on age and gender.

Functional 398 CRM The system shall provide a unique identifier for client and provider records as they are created.

Functional 399 CRM The system shall allow modifying client and provider information according to business rules.

Functional 400 CRM The system shall validate US Postal Service format for addresses (including foreign addresses) contained in system records.

85 of 172


The system shall provide a user-selectable list for the user to choose from if one ZIP Code represents multiple counties, cities, or towns. County and city fields should auto-populate based on ZIP Code input and allow user override.






The system shall provide automated notification of Medicaid Waiver Waitlist release based on established business rules.


The system shall allow for users to open multiple referral cases for a client as long as the open dates are different.

Functional 411 CRM

The system shall provide the ability to capture demographic information for a client (see CIRTS_User_Guide_for_CARES 2013.pdf attached to this document for field and screen examples).

Functional 412 CRM The system shall provide the ability to define the preferred method of communication for a provider and client record.

Functional 413 CRM The system shall allow multiple addresses and address types to be associated with a record.

Functional 414 CRM

The system shall have the capability to display similarly spelled names or phonetically similar names and other pertinent demographic data for selection to prevent the same entity from duplicate entries (e.g., Rick Smith and Ricky Smith, or transposed numbers within a SSN).

Functional 415 CRM The system shall display the fields required for data capture when the client record is set as anonymous during record creation.


The system shall allow for a keyword search of services available based on service area, county, city, or ZIP Code and to further refine the search results based on established filters.


The system shall provide the functionality to search for a provider using nearest location by city, county, ZIP code, PSA or provider name.


The system shall allow for the user to conduct a search for services and resources offered by the provider and add them to a client record.


The system shall display a message to the user "The PASRR data has not been entered." if a placement recommendation is nursing home (NUHO) or temporary nursing home (NHTP) and the PASRR data has not been entered for the client's Staffing. The system shall display the PASRR Screen, allow entry of the data and when complete, the system shall navigate the user back to the Staffing Screen.

86 of 172


The system shall display a list of choices using a drop-down list for a client’s program recommendation determinate on the value entered in the placement recommendation field when entering data into the Staffing Screen.


The system shall allow for a well-defined set of records to be bundled together for ease of review based on document type (e.g., Staffing Plan and Monitoring Plans).


The system shall provide users with a Staffing screen displaying past and current screening requests and allowing authorized users to add new a new staffing or modify a client's current staffing data. This screen should include at a minimum the staffing date, Level of Care, LOC Date, Placement and Program Recommendations and the PSA. An example of the Staffing screen fields in the current CIRTS system is shown on page(s) 94 - 102 of the CIRTS_User_Guide_for_CARES 2013.pdf.


The system shall provide users with the ability to add new staffing data for a client from the Staffing Screen.


The system shall provide the ability for authorized users to initiate the generation of a standard DOEA-CARES Form 603 with fields automatically populated from the client demographic data according to business rules.


The system shall provide a standardized summary of client data required for staffing a client from a variety of pre-determined sources (e.g., medications list and Activities of Daily Living from assessment, LOC recommendations from the 603 and 610 forms).


The system shall allow for the ability to collect data and report on clients with authorized Level of Care (LOC) forms that have been sent to the enrollment broker for SMMC LTC.


The system shall provide the ability to indicate the client enrollment status in SMMC LTC after the eligibility process is complete.


The system shall display fields related to Nursing Home data entry on the Staffing Screen when the Living Arrangement field indicates Nursing Home (NUHO) and populate those fields from the Nursing Home data previously collected if it exists.


The system shall provide the ability to populate the 2515 form with data collected during the Level of Care (LOC) data entry during the Staffing process.


The system shall enable batch processing for secure printing of documents categorized by type for the Staffing workflow.


The system shall provide the ability for administrators to build a decision tree for Level of Care (LOC) and Program Recommendation determined by combinations of recommended placement and considered programs. An example of the decision tree can be found in Appendix A of the Business Process and Definition Document.

87 of 172


The system shall recommend a Level of Care (LOC) and Program Recommendation by analyzing a preconfigured decision tree. The system shall allow the user to modify or accept the systematic recommendation.


The system shall provide users with the ability to add, modify and remove items from a picklist generated from documents associated with a client record to create a set of documents categorized for staffing review.

Functional 439 Workflow The system shall allow the initiation of the staffing workflow process when a Level of Care (LOC) request task is opened.


The system shall provide the ability to set notifications at pre-defined intervals of client enrollment in SMMC LTC after the eligibility process is complete if the enrollment process has not completed according to business rules.


The system shall generate a No Level of Care Recommendation 610 Form data entry screen, populated with data from the client demographics data and allow it to be completed based on workflow and business rules.

Functional 446 Security The system shall provide a capability to control access to documents using administrator-configurable security credentials.


The system shall provide the ability to report on interface transmissions (e.g., total number of records loaded, date of interface transmission, amount of time to execute the interface transmission, errors, and failures).

Functional 448 Integrated Imaging The system shall enable authorized users to upload electronic documents or files to system records.


The system shall provide the ability to support internal and external feeds of data using common available protocols.


The system shall provide the ability to transmit the exported data through multiple methods (e.g., SFTP, web service, single and batch transactional).


The system shall allow for the upload of documents from an external mechanism directly into the document management system with a link to the associated client record.

Functional 452 CRM The system shall provide the ability for a user to upload and link electronic documents to a record.


The system shall enable an authorized user to define a maximum image file size according to business rules.


The system shall provide the ability to associate forms, documentation, and reports to specific types of notifications.


The system shall have the ability to send electronically the LOC form to the following systems: Department of Children and Families' (DCF) ACCESS System, Enrollment Broker, Agency for Health Care Administration's (AHCA) HealthTrack, Agency for Health Care Administration's (AHCA) Florida Medicaid Management Information System (FMMIS).

88 of 172


The system shall interface with the Department of Children and Families' (DCF) KEPRO used to upload Pre-Admission Screening and Resident Review (PASRR) Level I and II documentation.

Functional 464 Integrated Imaging The system shall provide the ability to accept direct fax-to-image.


The system shall enable batch processing including parsing engines of ANSI 837, comma separated value (.csv) and text-based files.


The system shall enable batch processing of uploaded, faxed or scanned data received from external sources using business rules to update case records and provide notifications to case owners of the event.


The system shall integrate with inbound and outbound landline fax and cloud fax (e.g., CenturyLink Cloud Fax) technology.


The system shall provide the ability to integrate with third-party applications (e.g., address validation solutions, Master Data Management solutions, Microsoft Office, Adobe Acrobat, etc.).


The system shall provide users with a 701C Assessment screen allowing authorized users to enter data as the assessment is being conducted. This form should be available in offline mode and on Wi-Fi/cellular connected mobile devices. This form contains a subset of fields available on the 701B Comprehensive Assessment.


The system shall provide users with a 701A Assessment screen allowing authorized users to enter data as the assessment is being conducted. This form should be available in offline mode and on Wi-Fi/cellular connected mobile devices. This form contains a subset of fields available on the 701B Comprehensive Assessment.


The system shall provide a Care Plan Screen for authorized users to view, modify and add data relevant to services requested by a client and services planned for delivery to the client. At a minimum, this screen should capture the date of request and start, program, unit, type of service, revised date, service provider and end date.


The system shall allow the user to initiate the system to copy previous Care Plan form data into a new Care Plan data entry screen for editing during New Care Plan creation.


The system shall provide the user with an option to print, apply an electronic signature or transmit an electronic copy of the client's Care Plan at the time of completion.


The system shall provide the ability to add client based achievement goals and associated weighted outcome attributes taking into account the level of difficulty of expected attainment.


The system shall automatically generate a Care Plan creation alert with a due date according to business rules when a 701A or 701B assessment is completed.

89 of 172


The system shall have the ability to create a Care Plan for a client assigned to a Lead Agency. Examples of the Care Plan screens and associated fields can be found in CIRTS_User_Guide_for_CARES 2013.pdf and CIRTSManual4-26-2007 Aging Network.pdf.


The system shall provide data collection and reporting capabilities of clients released from the Medicaid Waiver Waitlist. An example of the report fields in the current CIRTS system is shown on page 53 of the SMMC LTC EMS Procedures.doc.


The system shall allow for the ability to build and run the "Waiver Release Report" to support Enrollment Management System (EMS) Waitlist tracking.


The system shall enable reporting of case types (clients, applicants, entities, facilities, organizations, companies, businesses, etc.).


The system shall provide the ability to view past Medicaid LTC enrollment spans, including waitlist and active enrollments that were terminated.


The system shall provide a Services Screen filtered by provider in addition to by client to display all active services being provided by the user's provider network when the user logged in has the role of provider or other role as designated by business rules.


The system shall provide the ability to identify the document type and appropriate line-of-business record/case file of any system generated correspondence without user intervention.


The system shall enable restricting read and edit access to data, records and documents based on user identity, role, and information type.


The system shall prevent modifying of data classified as permanent records based on business rules (e.g., Established LOC through the Staffing Process).


Functionality

The system shall provide users with a visual indication of data entry fields that are mandatory (e.g., an asterisk next to required fields).

Non-Functional 609 Business Rules

Engine

The system shall generate a unique case number of a selectable fixed or variable length for each case based on user-defined parameters and business rules.


Engine

The system shall enable capturing, storing and maintaining (adding, modifying, deleting) case information linking records to one client.


Engine

The system shall enable capturing, storing and maintaining (adding, modifying, deleting) criteria (questions or menus) for determining which case type is required.


Engine

The system shall enable capturing, storing and maintaining (adding, modifying, deleting) configuration information for each case type including, email addresses, forms and status updates.

90 of 172


Engine

The system shall default the case owner to the user opening the case unless otherwise specified by business rules.

Non-Functional 618 Correspondence

and Forms

Form data collection types should include, at a minimum, checkboxes, drop-down selection lists, text fields, signature capture, multi-select drop-down lists and Optical Character Recognition (OCR).


and Forms

The system should support standardized and customized user-based data entry screens, forms, and document templates.

Non-Functional 630 CRM The system shall provide the ability to process in excess of

1,000 inbound and outbound faxes per day.

Non-Functional 634 Database

Architecture

The system shall validate individual fields based on established business rules and/or data available and provide immediate feedback to the user.


Architecture All dates in the system shall carry the full four digits for the year.


Architecture

The system shall allow for the classification of documents, forms and records (e.g., 3008, 603, PASRR Level I, etc.) stored at the client and provider record level.


Architecture The system shall perform validation on all input fields based on preconfigured parameters.


Architecture The system shall be able to uniquely identify each user.


Architecture Database access shall be managed by roles.


Architecture



Architecture

The system shall be capable of supporting the current versions of the following computer and smartphone operating systems: Microsoft Windows; Apple iOS; and Google Android.

Non-Functional 649 Development and

Support Services The system shall provide the ability to present an error list for failed data imports and exports.

Non-Functional 650 Events and

Scheduling

The system shall provide the ability to maintain master copies of historical information related to scheduled events.


Scheduling The system shall provide for remote synchronization with a central database over Wi-Fi or cellular data connection.


Scheduling



Scheduling

The system shall not permit the deletion of records. Records should be marked as deleted, stamped with date and user, and then stored in history tables in accordance with records management retention policies.


Scheduling

The system shall not permit records to be physically deleted or altered except as part of a system administration archival process.

91 of 172

Non-Functional 658

Record Management and Audit

The system shall delete or archive case information, by type, on the configured date.

Non-Functional 659


The system shall have an audit trail on all fields.

Non-Functional 662


The system shall maintain current and historical records for active and inactive clients and providers, including record of all assessments, enrollments, screenings, LOC Recommendation, case notes, contract information, budget information, services provided, unit rates, record creation date, and supporting documentation by date and type.

Non-Functional 663


The system shall maintain a history of changes (add, modify, or delete) to status and client information including the date, time, and user ID of the user who performed the change.

Non-Functional 664


The system shall provide audit trail functionality to record data import, its source, and its point of entry.

Non-Functional 665


The system shall provide audit trail functionality for all generated notifications (e.g., user, date and time, type).

Non-Functional 666


The system shall produce audit records that contain sufficient information to, at a minimum, establish what type of event occurred, when (date and time) the event occurred, where the event occurred, the source of the event, the outcome (success or failure) of the event, and the identity of the user or external source associated with the event.


The system shall provide functionality that will assist DOEA in complying with the HIPAA Privacy Rule, HIPAA Security Rule, and HIPAA Breach Notification Rule.


Architecture

The system shall have the ability to adjust its internal clock and all timestamps to reflect time changes from Daylight Savings Time to Standard Time and from Standard Time to Daylight Savings Time.


Architecture

The system shall meet the seven conditions of MITA including: Modularity, Leverage, Industry Standards, Business Results, Reporting, and Interoperability, and MITA.


Architecture The system shall enable associating multiple cases and supporting records to a single client.


Scheduling

The system shall provide the ability to establish and maintain user-defined calendars and dates specific to business functionality (e.g., calendar for assessment, site visits or screening scheduling).

Non-Functional 687 Integrated Imaging

The system shall provide the ability to route correspondence to authorized users for identification using established workflows in the case of OCR failure.

92 of 172

Non-Functional 688 Workflow

The system shall display a warning message to the user when initiating the staffing process if an item is missing from a pre-configured checklist of requirements for the workflow action to begin. The system shall allow the user to follow-up on the warning message and be subsequently returned to the Staffing screen.

Non-Functional 690


The system shall provide an audit trail for each document including: activity (uploaded, modified, accessed, deleted), activity date, source, and user.


The system shall integrate with document management functionality to cross-reference documentation with the appropriate work item.

Non-Functional 693 Interfaces and

Interoperability

The system shall provide the ability to fully integrate with email software such as Microsoft Outlook using API standards.


Interoperability

The system shall provide a document management system or the ability to integrate into an external document management system (e.g., Microsoft SharePoint, NewGen OmniDocs, Hyland OnBase).

Non-Functional 700 Security The system shall log system transactions to provide an

audit trail of system access and activity.


The system shall provide the ability to report on user information (e.g., account status, assigned roles/permissions, user activity history, history of security profile changes for a user).

Non-Functional 740 Security The system shall enable data encryption at the data field

level in accordance with FIPS 140-2. Non-Functional 741 Security Either session-based encryption or message-based

encryption shall be used to encrypt the data.


The system shall enforce display, entry, modification, deletion, and exchange of information using the principle of Least Privilege.


The system shall provide access to appropriate data and functionality within the system based on administrator-configurable role(s) assigned to the user (e.g., access to data, documents, audit trail information, program information, and financial data).






Non-Functional 756 Security The system shall encrypt data at the data layer in transit

and at rest.


The system shall maintain the integrity and confidentiality of information during aggregation, packaging, and transformation in preparation for transmission.

93 of 172


The system shall provide the ability to mark data as "Confidential" or "Restricted" to prevent the data from being shared based on user's roles.

Functional 780 CRM The system shall allow an address to be designated as Active or Inactive.

94 of 172

Application Functionality - Provider The Provider information contained in the system consists of demographic information, budget information, approved services, and provided services. This section consists of use cases for the Provider Management Module within the system. The following use cases detail the screens within the Provider Management Module and the information needed to complete each task. The following use cases comprise the Provider subsection:

• Search for Provider • Create or Modify Provider • Invoicing • Add or Modify Taxonomy Service • Resource Directory Website

UC-APPFUNCT-15: Search for Provider 1. Description This use case provides the functionality for a user to search for provider records by identifiers such as Provider Name, Provider ID, or Medicaid Provider ID. 2. Level Summary 3. Trigger • User needs to search to locate a provider record in the system.

4. Primary Actor(s) • AAA/ADRC Staff • DOEA Staff • Lead Agency Staff/OAA Providers

5. Other Actor(s) • Client • Provider


95 of 172

3.17.1. Flow of Events: Search for Provider Main Success Scenario (Search for Provider) 1. The user selects Provider Search from the Home Dashboard. 2. The system displays the Provider Search Screen. 3. The user enters one or a combination of the following provider demographic information into the

search screen: • Provider Name; and/or • Contract Number; and/or • Medicaid Provider Identification Number; and/or • Phone Number; and/or • Provider Website; and/or • Provider email address; and/or • Unique Provider Identification Number.

4. User selects Search. 5. The system displays the list of potential provider matches ranked by the match percentage against

key demographic data entered. 6. The user selects the record and the system displays the Provider Record. Extensions Exception 1 Invalid Data Entered 4a User enters invalid information into a field or fails to complete required fields. 4b The system displays an error indicating the reason for the failure. 4c The Main Success Scenario is joined at Step 3. Exception 2 Premature Exit 4a The user selects Cancel before the provider search is complete. 4b The system displays the Provider Search Screen and the Main Success Scenario is rejoined at Step 3. Exception 3 No Record Found 5a If no record is found, the system will display a message stating: “No Record Found. Create New

Provider?” o The user selects No, the Main Success Scenario is rejoined at Step 3. o The user selects Yes, the use case ends and the flow continues with Use Case UC-APPFUNCT-

16: Create or Modify Provider. Post Conditions Success End Condition • The system displays a list of search results.


• The search fails to locate the provider record being queried. • An error is displayed indicating the reason for the failure. • The Provider Search Screen is displayed.

Frequency On Demand

Security


431.300 to 307


• The ability to search should be accessible via mobile devices such as tablets with a cellular or Wi-Fi connection.

• The ability to search must be available in an offline mode with a synchronization of data after reconnection to the system.


96 of 172

UC-APPFUNCT-16: Create or Modify Provider 1. Description This use case provides the functionality for an internal user such as AAA/ADRC Staff or DOEA Staff to create or modify a Provider Record. This Provider Record contains demographics, services, invoices, documents, and contracted budgets. 2. Level Summary 3. Trigger • An internal user needs to create or modify a provider record.

4. Primary Actor(s) • AAA/ADRC Staff • DOEA Staff

5. Other Actor(s) • Provider

6. Preconditions • Use Case UC-APPFUNCT-15: Search for Provider has been completed. • The user has the appropriate access privileges to create a Provider.

97 of 172

3.18.1. Flow of Events: Create or Modify Provider Main Success Scenario (Create Provider) 1. The user navigates to the Provider Screen from their Home Dashboard. 2. The user selects Create Provider and the system displays the Provider Information Screen. 3. The user completes the required provider demographic information and selects Save. 4. The system performs a check for existing Provider records to determine if there is a potential match

to an existing record. The system determines there is no matches, creates the Provider Record, and displays the Provider Information Screen.

5. User selects Create Contract Budget from the Provider Information Screen and the system displays the New Contract Budget Screen.

6. The user enters: o Contract Number; o Program Type (e.g., CCE, OAA, etc.); o Provider Services; o Provider Location Code; o Rates; o Units; o Service Dates; and o Any additional required information.

7. The user selects Complete. 8. The system saves the information, updates the Contract Budget Totals using the services, units, and

rate entered, places the provider services in Pending Signature status, then displays the Contract Budget Screen.

9. The user selects Generate Contract Budget on the Contract Budget Screen, the system creates the Contract Budget PDF file including the provider services in Pending Signature status, and displays the resulting Contract Budget PDF file to the user.

10. The user selects Print to print the Contract for signature, or Email to send the Contract for signature, selects Close, and the system displays the Contract Budget Screen.

11. After the signed contract has been received, the user selects Received Signed Contract from the Contract Budget Screen.

12. The system updates the Pending Signature items to Approved and displays the Provider Information Screen.


first field with an error indicator such as a highlighted color. 3c The Main Success Scenario is joined at step 3. Exception 2 Premature Exit 3a The user selects Cancel before the Provider record data entry is complete. 3b The system displays the message “Save Provider?”

o The user selects Yes, the data entered is saved. When the user returns to the Provider Record, the system displays the last active field when the user exited the screen.

o The user selects No, the system discards data entered and displays the user’s Home Dashboard.

Exception 3 Existing Record 3a The system displays a list of potential match(es) for the provider record. 3b The user determines there is a matching record, selects the record, and the system displays the

existing Provider Information Screen. The user confirms the information entered is correct and the Main Success Scenario is rejoined at Step 5.

Alternatives Alternative 1 Create Provider without Services

98 of 172

5a The user selects Close. 5b The system saves the provider information and displays the user’s Home Dashboard. 5c This Use Case Scenario ends. Alternative 2 Modify Provider Demographic Information 1. The user selects the Provider from the list of Search Results and the system displays the Provider

Information Screen. 2. The user selects Edit, updates the demographic information, and selects Save. 3. The system saves the information and displays the Provider Information Screen. Alternative 3 Edit Provider Services within the Fiscal Year 1. The user selects the Provider from the list of Search Results and the system displays the Provider

Information Screen. 2. User selects Contract Budget from the Provider Information Screen and the system displays the

existing Contract Budget in view-only mode. 3. The user selects Edit, updates the provider service information on the Contract Budget Screen, and

selects Save. 4. The system places the updates in Pending Signature status and displays the Contract Budget Screen. 5. The user selects Generate Amended Contract Budget on the Contract Budget Screen, the system

creates the Amended Contract Budget PDF file, including the Pending Signature items, and displays the Amended Contract Budget PDF file to the user.

6. The user selects Print to print the Amended Contract for signature, or Email to send the Amended Contract for signature, selects Close, and the system displays the Contract Screen.

7. After the signed contract has been received, the user selects Received Signed Contract from the Contract Screen.

8. The system updates the Pending Signature items to Approved, updates the Contract Budget totals if needed, and displays the Provider Information Screen.

Alternative 4 Create New Fiscal Year Provider Services 1. The user selects the Provider from the list of Search Results and the system displays the Provider

Information Screen. 2. User selects Create Contract Budget from the Provider Information Screen and the system displays

the New Contract Budget Screen. 3. The system displays the following message to the user: “Copy previous year’s Contract Budget?”

o The user selects Yes, data from previous year’s Contract Budget is populated into the Contract Budget Screen.

o The user selects No, the system displays a blank Contract Budget Screen for the current year. 4. The user enters or updates the Program Type, Provider Services, Units, Rate, and Service Dates, then

selects Save. 5. The system places the services in Pending Signature status, creates the Contract Budget Totals, and

displays the Contract Budget Screen. 6. The user selects Generate Contract Budget on the Contract Budget Screen, the system creates the

Contract Budget PDF file, and displays the Contract Budget PDF file to the user. 7. The user selects Print to print the Contract for signature, or Email to send the Contract for signature,

selects Close, and the system displays the Contract Screen. 8. Once the signed contract has been received, the user selects Received Signed Contract from the

Contract Screen. 9. The system updates the Pending Signature items to Approved and displays the Provider Information

Screen. Post Conditions

Success End Condition

• The system saves the information. • A message of successful completion is displayed. • The Provider Information Screen is displayed.


• The system fails to save the information. • An error is displayed indicating the reason for the failure to save. • The Provider Information Screen is displayed.

99 of 172

Frequency On Demand

Security


431.300 to 307


100 of 172

UC-APPFUNCT-17 Invoicing

1. Description Services provided to a client are entered into the system via batch processing or manually. These services are then used to populate the monthly invoices sent to DOEA for payment. 2. Level Summary 3. Trigger • Services have been provided and an invoice needs to be submitted.

4. Primary Actor(s) • Lead Agency Staff/OAA Providers (Providers) • AAA/ADRC Staff (Provider) • DOEA Staff including

o Contract Payment Auditor o Contract Manager o Accountant



101 of 172

3.19.1. Flow of Events: Invoicing Main Success Scenario (Invoicing) 1. The Provider selects Billing from the Provider’s Home Dashboard. 2. The system displays the Billing Screen. 3. The Provider selects Create Invoice from the Billing Screen and the system displays the Invoice Form. 4. The Provider:

o Selects the services to invoice; o Enters the Invoice Date Range; o Enters any additional administration services provided; o Selects the option to include or exclude a reconciled year-to-date (YTD) total; and o Selects Generate Invoice.

5. The system assigns a unique invoice identifier, updates each service status to Invoiced, creates the Invoice PDF file, and displays the PDF to the user.

6. The Provider selects Print to print the Invoice for signature, Email to send the Invoice for signature, or Electronic Signature to electronically sign the Invoice, selects Close, and the system displays the Billing Screen.

7. Once the Invoice has been signed, the Provider attaches the signed invoice and any supporting documents to the Invoice Form and selects Submit Invoice.

8. The system: o Saves the Invoice; o Creates an Invoice Task; o Assigns the Invoice Task to the DOEA Contract Payment Auditor (CPA) queue; o Sends a Pending Invoice email to the CPA distribution list; and o Displays the Billing Screen.

9. Using the hyperlink provided in the Pending Invoice email, the CPA logs into the system and the system displays the Invoice Form.

10. The CPA reviews the invoice and selects Create Code Sheet. 11. The system displays the FLAIR Code Sheet in edit mode, prepopulated using business rules. 12. The CPA reviews and updates the FLAIR Code Sheet and selects Approve Invoice. 13. The system:

o Saves the information; o Updates the Invoice status to Reviewing Documentation; o Updates the Service status to In Review; o Reassigns the Invoice Task to the DOEA Contract Manager (CM) queue; o Sends a Pending Invoice email to the CM distribution list; and o Displays the CPA’s Home Dashboard.

14. Using the hyperlink provided in the Pending Invoice email, the CM logs into the system and the system displays the Invoice Form.

15. The CM reviews the Invoice and supporting documentation then selects Approve Invoice. 16. The system:

o Updates the Invoice status to Final Pending Payment; o Updates the service status to Pending Payment; o Reassigns the Invoice Task to the DOEA Accountant queue; o Sends a Pending Invoice email to the Accountant distribution list; and, o Displays the CM’s Home Dashboard.

17. Using the hyperlink provided in the Pending Invoice email, the Accountant logs into the system and the system displays the Invoice Form.

18. The Accountant reviews the Invoice and selects Finalize Code Sheet. 19. The system:

o Updates the Invoice Status to Sent for Payment; o Updates the Service status to Waiting for Payment; o Creates a batch file of the code sheet to send to DFS FLAIR; and o Displays the Accountant’s Home Dashboard.

102 of 172

20. Once the Voucher Payment is received, the Accountant selects the Invoice Task from their Home Dashboard, and the system displays the Invoice Form.

21. The Accountant attaches the Voucher to the Invoice Form and selects Payment Received from the Invoice Form.

22. The system saves the information, updates the Invoice status to Final Paid, sends a Final Paid email to the Provider, updates the Invoice Task to complete, and displays the Accountant’s Home Dashboard.





Exception 2 Return Invoice for Corrections 1. The user reviews the invoice and selects Return for Corrections. 2. The user selects the appropriate group to return the invoice and the system prompts the user to

enter a Return Reason. 3. The user enters the Return Reason and selects Send. 4. The system creates an Invoice Returned task and assigns the task according to business rules. 5. The user selects the task from their Home Dashboard and the system displays the Invoice Form with

the notes of items to be corrected. 6. The user updates the Invoice Form and selects Submit Invoice. 7. The Main Success Scenario is rejoined at Step 8. Alternatives Alternative 1 Add Services Manually for Invoicing 1. The user selects Search Client from their Home Dashboard and the system displays the Search

Screen. 2. The user enters the required information, selects Search, and the system displays the Search Results. 3. The user selects the client from the list of search results and the system displays the Client

Information Screen. 4. The user selects Client Services and the system displays the Services Screen. 5. The user enters the required information and selects Save. 6. The system:

o Saves the information; o Updates the Contract Tracking Totals; and o Displays the Client Information Screen.


• The invoice is created. • The Invoice Screen is displayed.


• The system fails to create an invoice. • An error is displayed indicating the reason for the failure to create an invoice. • The Invoice Screen is displayed.

Frequency On Demand

Security • Chapter 74-2, Florida Administrative Code; • Section 282.318, Florida Statutes; • 45 CFR Part 164, P.L. 104-191, HIPAA of 1996; and

103 of 172

• 1902(a)(7) of the Social Security Act as further interpreted in regulations at 42 CFR 431.300 to 307


104 of 172

UC-APPFUNCT-18: Create or Modify a Taxonomy Code

1. Description The AAA/ADRC uses a Services Taxonomy to assist clients, or potential clients, with finding services to help with their daily activities. These services are used internally to assist a caller asking for a referral and externally for a client to access on the public facing website. The services are updated and maintained by the AAA/ADRC staff and require the ability to be categorized and prioritized when displayed in a list of search results. 2. Level Summary 3. Trigger • A request has been received to create or modify a code in the Taxonomy.

4. Primary Actor(s) • AAA/ADRC Staff


6. Preconditions • Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed and

they have navigated to the Taxonomy Module. • The user has access privileges to create or modify a Taxonomy Service.

105 of 172

3.20.1. Flow of Events: Create or Modify a Taxonomy Code Main Success Scenario (Create a Taxonomy Service) 1. The user selects Taxonomy from their Home Dashboard and the system displays the Taxonomy

Screen. 2. The user selects Add New Code and the system displays the Taxonomy Screen. 3. The user enters the following Code information:

o Service Category; o Service Name; o Service Location; o Provider Name(s); o Provider Information; and o Any additional required information.

4. The user selects Save. 5. The system saves the information and displays the Taxonomy Screen. Extensions Exception 1 Invalid Data Entered 3a User enters invalid information into a field or fails to complete required fields. 3b The system displays an error indicating the reason for the failure to save and defaults the user to the




Alternatives Alternative 1 Modify a Taxonomy Service 1. The user selects Taxonomy from their Home Dashboard and the system displays the Taxonomy

Screen. 2. The user selects Search for Taxonomy Services and the system displays the Search Screen. 3. The user enters the required information and selects Search. 4. The system displays a list of search results. 5. The user selects the service from the list of results and the system displays the service in view-only

mode. 6. The user selects Modify, the system displays the service in edit mode, the user updates the record as

required, and selects Save. 7. The system saves the information and displays the Taxonomy Screen. Post Conditions Success End Condition

• Required service data is saved to the system. • A message of successful completion is displayed. • The Taxonomy Screen is displayed.


• Required service data fails to save to the system. • An error is displayed indicating the reason for the failure to save. • The Taxonomy Screen is displayed.

Frequency On Demand

Security


CFR 431.300 to 307

106 of 172


107 of 172

UC-APPFUNCT-19: Resource Directory Website 1. Description Taxonomy services are available to search via the internal system or via a public facing Resource Directory website. The Resource Directory website allows for individuals to search for services in their area without the need to contact the AAA/ADRC for assistance. 2. Level Summary 3. Trigger • An individual would like to search for services using the public facing website.

4. Primary Actor(s) • Client

5. Other Actor(s) • AAA/ADRC Staff

6. Preconditions • The individual has navigated to the website to search for services.

108 of 172

3.21.1. Flow of Events: Resource Directory Website Main Success Scenario 1. The individual navigates to the Resource Directory via the DOEA eCIRTS Website. 2. The individual enters any one or combination of the following terms to search for taxonomy services:

o City; o ZIP Code; o Keyword; o Agency Name; o Program Name; and/or o Service Category.

3. The individual selects Search and the system displays the list of search results. 4. The individual selects a result and the system expands the information displayed to show all

information related to that selection. Extensions Exception 1 Invalid Data Entered 3a User enters invalid information into a field or fails to complete required fields. 3b The system displays an error indicating the reason for the failure to save and defaults the user to the

first field with an error indicator such as a highlighted color. 3c The Main Success Scenario is joined at step 2. Exception 2 Premature Exit 3a The user selects Cancel before the search is completed. 3b The system displays the Search Screen. The Main Success Scenario is rejoined at Step 2. Post Conditions Success End Condition • Search results are displayed to the client.


• The Search Results Fail to be displayed. • The Search Screen is displayed.

Frequency On Demand

Security


CFR 431.300 to 307


• The ability to search for Taxonomy Services should be accessible via mobile devices such as tablets with a cellular or Wi-Fi connection.


109 of 172

Provider Management Requirements












The system shall provide authorized users the ability to filter dropdown lists dependent on selection of parent or grandparent values on a data entry screen (e.g., billing services of a Lead Agency should be filtered by the Service indicated on a client's Care Plan).


The system shall provide the user with predefined selectable lists wherever possible. Drop-down lists, radio buttons and "lookup" tables will maximize the entry of correct and complete data and will ensure that business rules are followed.


Wherever applicable, the system shall provide pick lists and/or multi-pick lists instead of manual text entry. Pick lists shall not force a refresh of the screen after selection.


The system shall enable authorized users to maintain and manage the pick lists within the system.


The system shall enable users to enter multiple characters to select a specific choice from a pick list. For example, the user should be able to enter “Jac” to get to Jacksonville rather than typing J several times to move through list to Jacksonville.




The system shall provide the ability for an authorized user to create, modify, and delete look-up values including both codes and code values.









110 of 172



The system shall interface with electronic signature devices and software.


The system shall provide support for PDF electronic signatures.








The system shall provide the ability to mark a service or resource for publishing on a publicly accessible web page.


The system shall provide the ability to search the taxonomy by code and keyword.


The system shall provide authorized users a data entry screen to add, modify and set inactive taxonomy terms and hierarchy levels.


The system shall provide authorized users a data entry screen to add, modify and remove resource and service data for an Agency.


The system shall provide the ability to mark a service or resource as a priority record forcing it to appear in the top of search results.


The system shall provide authorized users a data entry screen to add, modify and remove resource and service data for a Site, capturing service delivery details for an Agency.


The system shall provide authorized users a data entry screen to add, modify and remove resource and service data for Services.


The system shall provide the ability to group services such that they can be reused for multiple agencies offering the same services (e.g., Homeless Services: shelter, clothing, showers).


The system shall provide authorized users a data entry screen to populate common use terms not contained in the taxonomy as searchable keywords (e.g., searching for the term "toothpaste" displays the taxonomy term "Grooming Supplies").


The system shall provide the ability to set parameters for service sites based on age and gender.


111 of 172



Functional 400 Provider and Contract Management

The system shall validate US Postal Service format for addresses (including foreign addresses) contained in system records.






The system shall provide authorized users the ability to add, modify and disable provider accounts and associated data such as provider name, type, county, PSA and services or referrals available.

Functional 412 CRM The system shall provide the ability to define the preferred method of communication for a provider and client record.


The system shall provide authorized users the ability to build a well-defined taxonomy or to import a licensed taxonomy (e.g., www.211taxonomy.org).


The system shall allow for a keyword search of services available based on service area, county, city, or ZIP Code and to further refine the search results based on established filters.


The system shall provide the functionality to search for a provider using nearest location by city, county, ZIP code, PSA contract number, or provider name.


The system shall allow for the user to conduct a search for services and resources offered by the provider and add them to a client record.


The system shall provide the ability for authorized users to add ad hoc services to the database if it does not exist by providing a GUI data entry screen.


The system shall provide a warning to the user during the process of adding an ad hoc service if the add service request returns a partial or full match on an existing service and allow them to accept the change or choose an existing service.


The System shall have the ability to track services and resources provided to a client including the unit increments the service was provided.


The system shall provide a Services Screen filtered by provider instead of by client to display all active services being provided by the user's provider network when the user logged in has the role of provider or other role as designated by business rules.

112 of 172



The system shall provide authorized users with the ability to set an invoice status indicating the system is required to include it in the next scheduled batch upload to the ACMS database.


The system shall interface with the ACMS system providing the ability for the ACMS system to upload data directly to the system.


The system shall parse uploaded data from the ACMS system and update identified invoices and billed services according to business rules (e.g., marking a service and invoice as Paid).


The system shall provide a hyperlink or other navigation path to authorized users from a service provided and billed to an invoice generated and from an invoice generated to a service provided and billed.


The system shall provide a services Billing Screen for authorized users to view, modify and add data relevant to services delivered to a client by a provider. This screen should be accessible from the relevant navigation points within the system such as from the Client Screen or the provider's Home Dashboard. At a minimum, this screen should capture the contract number, PSA, provider, lead agency, program, service provided and date, unit and type of unit and payment amount.


The system shall provide the ability for authorized users to generate a standard invoice for services provided to clients utilizing the services billed data and a date range as specified by the user.


The system shall provide the ability for authorized users to print an invoice as a PDF document from the services Billing Screen.




Engine



Functionality



and Forms



Architecture






113 of 172





Support Services



Support Services

The system shall be capable of supporting the current versions of the following computer and smartphone operating systems: Microsoft Windows; Apple iOS; and Google Android.

Non-Functional 653 Mobility


Non-Functional 654



Non-Functional 655






Architecture

The system shall have the ability to adjust its internal clock and all timestamps to reflect time changes from Daylight Savings Time to Standard Time and from Standard Time to Daylight Savings Time.


Architecture

The system shall adhere to negotiated performance standards for searching, saving, retrieving, reporting, analysis and collating of data.


Architecture



Architecture

The system shall calculate year-to-date and life-to-date reconciled totals for provider services billed as determined by business rules and provide the ability for the user to include a year-to-date or life-to-date reconciled total on the invoice.


Architecture The system shall provide unique identifiers for services billed.


Architecture The system shall utilize business rules to provide unique identifiers for system generated invoices.


Architecture

The system shall set a flag in the database for services invoiced and provide a reference link to the invoice including the service for billing.



114 of 172









Non-Functional 756 Security The system shall encrypt data at the data layer in transit and

at rest.

115 of 172

Application Functionality – Quality Assurance The Quality Assurance information contained in the system consists of a collection of tools used to provide quality assurance on the information managed within the system. This section consists of use cases for the Quality Assurance Module within the system. The following use cases detail the screens within the Quality Assurance Module and the information needed to complete each task. The following use cases comprise the Quality Assurance subsection:

• Case Record Review Tool (CRRT) • Create Monitoring Plan • Conduct Monitoring Analysis

UC-APPFUNCT-20: Case Record Review Tool (CRRT)

1. Description The case record review process is designed to provide quality assurance and performance reviews for Assessors and Staff Assistants. 2. Level Summary 3. Trigger • A quality assurance or performance review must be conducted on a CARES Assessor or Staff

Assistant. 4. Primary Actor(s) • CARES Staff

o Assessor o Staff Assistant o Manager

• DOEA Staff 5. Other Actor(s) N/A

6. Preconditions • The Use Case UC-SECURITY-01: User Logs in through Web Browser has been completed. • The user has the Manager role.

116 of 172

3.23.1. Flow of Events: Case Record Review Tool (CRRT) Main Success Scenario (Case Record Review Tool (CRRT)) 1. The Manager selects CRRT from their Home Dashboard and the system displays the Case Record

Review Tool (CRRT) Screen. 2. The Manager selects Create CRRT from the CRRT Screen and the system displays the CRRT Form. 3. The Manager enters the search criteria, a date range in which cases were opened, selects Search, and

system displays the search results. 4. The Manager selects Begin Review next to the case in the search results, the system updates the

CRRT with information from the selected case, and displays the CRRT Screen. 5. The Manager performs a review of the case, enters the required information in the CRRT screen,

selects a Due Date, and selects Send for Review. 6. The system calculates the Review Score and displays the CRRT Screen. 7. The Manager selects Sign Review and the system displays a box for electronic signature. 8. The Manager signs the document electronically and selects Save. 9. The system:

o Sets the CRRT status to Pending; o Creates a CRRT Task; o Assigns the task to the Assessor and/or Staff Assistant as defined by business rules; and o Displays the Manager’s Home Dashboard.

10. The Assessor and/or Staff Assistant logs into the system, selects the CRRT Task from their Home Dashboard, and the system displays the CRRT Screen.

11. The Assessor and/or Staff Assistant review the screen and select Sign Review and the system displays a box for electronic signature.

12. The Assessor and/or Staff Assistant signs the document electronically and selects Save. 13. The system updates the CRRT Task status to Closed, updates the CRRT status to Completed, and

displays the Assessor and/or Staff Assistant’s Home Dashboard. Extensions Exception 1 Invalid Data Entered 5a Use enters invalid information into a field or fails to complete required fields. 5b The system displays an error indicating the reason for the failure to save and defaults the user to the

first field with an error indicator such as a highlighted color. 5c The Main Success Scenario is rejoined at Step 5. Exception 2 Premature Exit 5a The user selects Cancel before the data entry is complete. 5b The system displays the message “Save CRRT?”


o The use selects No, the system discards the data entered and displays the CRRT Screen. Alternatives Alternative 1 Send CRRT for Corrections 11a The Assessor and/or Staff Assistant select(s) the case from the CRRT Screen and the system displays

the Case Screen. 11b The Assessor and/or Staff Assistant select(s) Edit and the system displays the Case in edit mode. 11c The Assessor and/or Staff Assistant make(s) the required corrections and select Save. 11d The system saves the information and displays the CRRT Screen. 11e The Assessor and/or Staff Assistant select Sign Review and the system displays a box for electronic

signature. 11f The Assessor and/or Staff Assistant sign(s) the document electronically and selects Save. 11g The system saves the information, updates the CRRT Task owner to the Manager, and displays their

Home Dashboard. 11h The Manager logs into the system, selects the CRRT Task from their Home Dashboard, and the

system displays the CRRT Screen.

117 of 172

11i The Manager verifies the required corrections have been completed, updates the form with any additional information, and selects Complete CRRT.

11j The system displays a box for electronic signature. 11k The Manager signs the document electronically and selects Save. 11l The system:

o Saves the information; o Updates the CRRT status to Complete; o Updates the task status to Closed; and o Displays the Manager’s Home Dashboard.


• The system saves the CRRT information. • The Home Dashboard is displayed.


• The system fails to create the CRRT. • An error is displayed indicating the reason for the failure to create the CRRT. • The CRRT Screen is displayed.

Frequency On Demand

Security


431.300 to 307


118 of 172

UC-APPFUNCT-21: Create Monitoring Plan

1. Description The monitoring process is designed to provide quality assurance for compliance requirements through case review and policy adherence verification. A monitoring plan is the collection of tools such as forms, documents, checklists, and randomized client lists required to perform the monitoring process. Monitors create Monitoring Plan(s) linked to users and groups of users of the system (e.g., providers and agencies). 2. Level Summary 3. Trigger • An agency or provider must be monitored based on an approved monitoring schedule.

4. Primary Actor(s) • AAA Staff • DOEA Staff

5. Other Actor(s) • Lead Agency Staff/OAA Providers

6. Preconditions • Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed. • The user is required to have the Monitor role.

119 of 172

3.24.1. Flow of Events: Create Monitoring Plan Main Success Scenario (Create Monitoring Plan) 1. The Monitor navigates to the Monitoring Module from their Home Dashboard and the system

displays the Monitoring Screen. 2. The Monitor selects Create Monitoring Plan from the Monitoring Screen. 3. The system displays the Monitoring Plan Wizard. 4. The Monitor selects the Program Type and the system displays a list of Providers matching the

selected Program Type. 5. The Monitor selects the Provider Name and the system displays the Provider information in the look-

up. 6. The Monitor selects Save and the system pre-populates the:

o Provider demographic information; o Program type; o Counties; and o Number of clients per program type on the Monitoring Plan Wizard Screen.

7. The Monitor inputs the remaining required information and selects Save. 8. The system:

o Saves the information; o Creates a Monitor Checklist based on the Provider and Program Types being monitored; o Sets the Plan status to Active; and o Displays the Monitoring Plan Screen.


first field with an error indicator such as a highlighted color. 6c The Main Success Scenario is joined at step 4. Exception 2 Premature Exit 5a If the user selects Cancel, the system returns the user to the previous screen. Alternatives Alternative 1 Previous Monitoring Plan Exists 6a If a previous Monitoring Plan exists, a message is displayed: “Copy previous Monitoring Plan dated:

mm/dd/yyyy?” 6b If the user selects Yes, data from the previous Monitoring Plan is populated into the current

Monitoring Plan Form. 6c The Main Success Scenario is joined at step 4. Post Conditions Success End Condition

• The Monitoring Plan is saved to the system. • A message of successful completion is displayed. • The system displays the Monitoring Screen.


• The Monitoring Plan fails to save to the system. • An error is displayed indicating the reason for the failure to save. • The system displays the Monitoring Screen.

Frequency On Demand

Security


431.300 to 307


120 of 172

UC-APPFUNCT-22: Conduct Monitoring Analysis

1. Description Comprehensive monitoring is conducted to assure the administration of state and federal programs and the delivery of services to elders conformed to standards of good practices and produced outcomes in agreement with the Department’s mission and contract requirements. Monitoring team members are responsible for conducting the review of approved monitoring standards and related activities included in the Department’s Monitoring Plan and agenda for each AAA. 2. Level Summary 3. Trigger • An agency or provider needs to be monitored based on an approved monitoring schedule.

4. Primary Actor(s) • AAA Staff • DOEA Staff

5. Other Actor(s) • Lead Agency Staff/OAA Providers

6. Preconditions • Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed. • The user is required to have the Monitor role.

121 of 172

3.25.1. Flow of Events: Complete Monitoring Plan Main Success Scenario (Complete Monitoring Plan) 1. The Monitor navigates to the Monitoring Module from their Home Dashboard and the system

displays the Monitoring Screen. 2. The Monitor selects the Monitoring Plan from the list of available plans and the system displays the

Monitoring Plan. 3. The Monitor selects the required items from the checklist, selects the Monitor Recipient(s), and

selects Send to Monitor Recipient(s). 4. The system:

o Sends an email to the Monitoring Recipient(s); o Creates a Monitoring Task (as needed); o Places the task on the Monitoring Recipient’s Home Dashboard (as needed); and o Displays the Monitor’s Home Dashboard.

5. The Monitoring Recipient selects the Monitoring Task from their Home Dashboard and the system displays the Monitoring Plan.

6. The Monitoring Recipient reviews the Monitoring Plan, attaches any requested documentation, updates the plan information, and selects Save.

7. The Monitoring Recipient selects Review Complete from the Monitoring Plan Screen. 8. The system:

o Updates the task status to Pending Document Review; o Assigns the task to the Monitor; o Sends an email to the Monitor of the change in status; o Places an alert on the Monitor’s Home Dashboard; and o Displays the Monitoring Recipient’s Home Dashboard.

9. The Monitor selects the Monitoring Task from their Home Dashboard and the system displays the Monitoring Plan Screen.

10. The Monitor performs a desk review of the documentation for completeness and accuracy. 11. The Monitor enters notes in the Monitoring Plan Screen. 12. The Monitor selects Create Preliminary Observation Report from the Monitoring Plan Screen. 13. The Monitor enters the required information, selects Complete, and the system:

o Saves the information; o Sends an email to the Monitoring Recipient(s) with a link to the report; o Updates the task status to Preliminary Sent; and o Displays the Monitor’s Home Dashboard.

14. The Monitor selects Create Exit Summary and the system displays the Exit Summary Screen. 15. The Monitor updates and completes the Exit Summary Screen, selects the Due Date, and selects Send.

The system: o Saves the information; o Emails the Monitoring Recipient(s) a link to the Exit Summary; o Updates the task status to Exit Summary Complete; o Creates an alert on the Monitoring Recipient’s(s’) Home Dashboard; o Creates calendar follow-up appointments for the Monitor and Monitoring Recipient(s);

and o Displays the Monitoring Plan Screen.

16. The Monitor selects Monitoring Report and the system displays the Monitoring Report Screen. 17. The Monitor completes the report and selects Complete. The system:

o Emails the Monitoring Recipient(s) a link to the Monitoring Report; o Sets the Monitoring Plan task status to Completed; and o Displays the Monitor’s Home Dashboard.

122 of 172


first field with an error indicator such as a highlighted color. 6c The Main Success Scenario is joined at step 4. Exception 2 Premature Exit 5a If the user selects Cancel, the system returns the user to the previous screen. Exception 3 Return to Monitoring Recipients 12a The Monitor determines corrections are needed, creates a note, and chooses Reassign. 12b The Monitor selects the Monitoring Recipient(s) from the drop-down list and selects Save.

o The task is assigned to the Monitoring Recipient(s). o The Monitoring Recipient updates the Monitoring Plan Screen with the needed

information and assigns the Monitoring Plan back to the Monitor to continue with the Monitoring process.

o The Main Success Scenario is rejoined at Step 10. Post Conditions Success End Condition

• The Monitoring Plan is saved to the system. • A message of successful completion is displayed. • The system displays the Monitoring Screen.


• The Monitoring Plan fails to save to the system. • An error is displayed indicating the reason for the failure to save. • The system displays the Monitoring Screen.

Frequency On Demand

Security


431.300 to 307


123 of 172

Quality Assurance Requirements








The system shall provide users with a Case Screen providing the ability to view cases related to a client, including options to add a new case, modify, close or reassign current cases. An example of the case screen fields in the current CIRTS system is shown on page 24 of the CIRTS_User_Guide_for_CARES 2013.pdf.


The system shall provide users with the ability to view a client's case note history in a list format allowing for the sorting of notes by column headings. At a minimum the column headings should include case note entry date, category, entered by user, PSA, date of event if different from date entered and a snippet of the case note. This screen should be accessible from the client's current or past Case screen. An example of a case note history screen in the current CIRTS system is shown on page(s) 116 - 122 of the CIRTS_User_Guide_for_CARES 2013.pdf.


The system shall display abbreviated client information on all screens presented to the user related to the client (e.g., the Care Plan Screen display a read-only view of the client's Name, SSN, Date of Birth).








The system shall enable users to search for and display correspondence item to which they have rights to view or modify.


The system shall maintain timers and monitor date-sensitive information based upon the time of distribution of the correspondence and other events.






124 of 172



The system shall provide the ability to retrieve and view imaged documentation provided by users and clients based on business rules.


The system shall enable authorized users to view audit trails by various selection criteria such as: case, external user, authorized user, and PSA.


The system shall provide the ability of displaying audit trail information reflecting system activity by any user, either internal or external, to include data actions such as read/write/update/delete and archiving and printing. Audit trail information should also include date, time, and function of the data action.






The system shall enable users to select and view information about an individual record when a search returns a list of records.



Functional 268 Workflow The system shall enable authorized users to view the current progress of an individual work item.

Functional 269 Workflow The system shall enable authorized users to view the current progress of a group of work items assigned to an individual, role, or program area.

Functional 297 Workflow The system shall provide the ability for authorized users to monitor the tasks within a workflow.


The system shall enable sorting, filtering, and viewing cases by PSA.

Functional 328 Mobility The system shall enable authorized users to view, capture, store, print, scan, and maintain data remotely using a mobile device.

Functional 332 CRM

The system shall provide the ability to historically search and report on case records based on status, user, client, owner, type, date/time, or any other case record fields as designed during the workflow generation.

Functional 335 CRM The system shall enable searching for cases by a user-specified date range on open, close, modify date fields, as well as by status, category and case owner.




125 of 172


Functional 379 CRM The system shall provide the ability to consolidate and record all contact activity associated with a client.


The system shall allow for a form to be completed and marked as a record (e.g., PDF form provided by external entitles such as AHCA or internal DOEA PDF forms).




The system shall allow for a well-defined set of records to be bundled together for ease of review based on document type (e.g., Staffing Plan and Monitoring Plans).


The system shall provide reports filtered by Monitoring exception type and associated provider for monitoring performance and analytics.


The system shall provide a Monitoring Plan Screen allowing authorized users to create customized groups of documents from a checklist of templates categorized for monitoring.


The system shall provide authorized users the ability to create and modify templates for the Preliminary Monitoring Report, Exit Summary and Final Monitoring Report data entry screens made available to monitoring process actions and selected ad hoc users for review and completion according to business rules.


The system shall provide the ability to manage documents from a centralized location when associated with a Monitoring Plan.


Functionality

The system shall provide the authorized users with a Case Record Review Screen to capture quality assurance workflow actions during the case review process.


The system shall provide the ability to create, modify and delete preconfigured exceptions and their attributes as defined in Monitoring business rules.


The system shall provide authorized users a Monitoring Screen displaying navigational links to resources critical to creating monitoring plans and initiating the monitoring process.


The system shall display the link to initiate monitoring plans from key navigation points within the system (e.g., if the user's role includes Monitor, it should appear on the Monitor's Home dashboard).


Navigation The system shall provide the ability for authorized users to search existing case record reviews.

Non-Functional 501 Reporting and

Dashboard

The system shall include the capability of tracking an individual's productivity (e.g., number of times and time spent viewing, processing, and completing tasks).

Non-Functional 510


System shall create audit history of time spent in all client-based screens, even when in offline or mobile mode.

126 of 172



The system shall include tools for comparing system monitoring results against historical measures.


The system shall include tools for monitoring and reporting capacity and performance for all system components.

Non-Functional 590

Development and Support Services

The system shall provide the ability to maintain metrics of system activity (e.g., numbers of users, types of users, search statistics, response times, system recovery time).




Functionality

The system shall enable capturing, storing and maintaining (adding, modifying, deleting) case information linking records to one client.


and Forms



Architecture






Non-Functional 662


The system shall maintain current and historical records for active and inactive clients and providers, including record of all assessments, screenings, LOC Recommendation, case notes, and supporting documentation by date and type.

Non-Functional 663


The system shall maintain a history of changes (add, modify, or delete) to status and client information including the date, time, and user ID of the user who performed the change.

Non-Functional 666


The system shall produce audit records that contain sufficient information to, at a minimum, establish what type of event occurred, when (date and time) the event occurred, where the event occurred, the source of the event, the outcome (success or failure) of the event, and the identity of the user or external source associated with the event.




Architecture


127 of 172



Scheduling

The system shall provide the ability to establish and maintain user-defined calendars and dates specific to business functionality (e.g., calendar for assessment, site visits or screening scheduling).

Non-Functional 690


The system shall provide an audit trail for each document including: activity (uploaded, modified, accessed, deleted), activity date, source, and user.


The system shall provide the ability to report on user information (e.g., account status, assigned roles/permissions, user activity history, history of security profile changes for a user).








128 of 172

Application Functionality - Complaints Complaint information contained in the system consists of the client demographic information and the Complaint Log. This section consists of a use case for the Complaint Module and the information needed to complete each task required of staff. The following use case comprises the Complaints subsection:

• Receive Complaint

UC-APPFUNCT-23: Receive Complaint

1. Description A complaint is the lowest level of expression of dissatisfaction about any matter other than an action, including, but not limited to, missed services, alleged abuse, neglect, exploitation, or a violations of enrollee rights and personal welfare. 2. Level Summary 3. Trigger • A client or representative has presented a complaint to a Lead Agency, AAA/ADRC, or DOEA.

4. Primary Actor(s) • Lead Agency Staff/OAA Providers • AAA/ADRC Staff • DOEA Staff


6. Preconditions • Use Case UC-APPFUNCT-01: Search for Client or Client Contact has been completed.

129 of 172

3.27.1. Flow of Events: Receive Complaint Main Success Scenario (Received Complaint and Determine Information Only) 1. The user selects Create Case from the Client Screen. 2. The system displays the Case Screen, defaults the case type to Information Only, and defaults the

Case Owner to the current user. 3. The user enters notes as appropriate, updates the case type to Possible Complaint, and selects Save. 4. The system saves the information, assigns the case to the Complaint Reviewer, and returns the user

to their Home Dashboard. 5. The Complaint Reviewer logs into the system, selects the assigned case from their Home Dashboard,

and the system displays the Complaint Screen. 6. The Complaint Reviewer researches the case information and contacts the client for possible case

resolution. 7. The Complaint Reviewer determines the case is an information only case and updates the case type

to Information Only, enters notes, and selects Close Case. 8. The system saves the information, updates the case status to Closed, and displays the Complaint

Reviewer’s Home Dashboard. Extensions Exception 1 Invalid Data Entered 7a User enters invalid information into a field or fails to complete required fields. 7b An error is displayed indicating the reason for the failure to save. 7c The Main Success Scenario is rejoined at Step 3. Exception 2 Premature Exit 3a The user selects Cancel before the Case record data entry is complete. 3b The system displays the message “Save Case?”

o The user selects Yes, the data entered is saved. When the user returns to the Case Record, the system displays the last active field when the user exited the screen.


Alternatives Alternative 1 Official Complaint 7a The Complaint Reviewer updates the Case Type to Official Complaint, enters notes, and selects Save. 7b The System displays the Complaint Screen pre-populated with the following required information

from the Client Information Screen: o Enrollee demographic information

• Enrollee's name; • Enrollee’s SSN or Medicaid ID; • Enrollee's address; and • County of service.

7c The Complaint Reviewer enters the following information: o Complaint date (required); o Complainant information;

• Complainant’s name (required); • Complainant phone number (required); • Complainant email address (optional) • Relationship to enrollee (required);

If “self,” complainant information is populated; o Plan name (required); o Referral (required);

• Agency name (optional); o Issue type (required);

• Common categories (optional); o Issue description (required);

130 of 172

• Complaint details (required); and o Resolution details (required upon closing).

7d The user enters the additional required information and selects Save. 7e The system saves the information and displays the Case Screen. 7f The Complaint Reviewer enters case notes and selects a Case Outcome from the following drop-

down list: o Issue Resolved; o Referred to AHCA; or o Referred to MCO.

7g The Complaint Reviewer selects Complete. 7h The system saves the information, schedules a Follow-up Task as defined by business rules, places

the task on the Complaint Reviewer’s Home Dashboard, and displays the Complaint Reviewer’s Home Dashboard.

Alternative 2 Refer Complaint 7a The Complaint Reviewer selects Refer Case from the Case Screen. 7b The Complaint Reviewer selects the Referral Group from the following drop-down list:

o ADRC; o CARES; o DOEA; or o Lead Agency.

7c The Complaint Reviewer selects Save and the system: o Creates a follow-up task on the Complaint Reviewer’s calendar; o Updates the assigned Case Owner per business rules; o Places an alert for the assigned Case Owner’s Home Dashboard; o Updates the case status to Pending; and o Displays the Complaint Reviewer’s Home Dashboard.


• The recipient of the complaint saves the complaint into the system. • The system displays the user's Home Dashboard.


• The system fails to log the complaint in the system. • An error is displayed indicating the reason for the failure to log the complaint in

the system. • The system displays the user's Home Dashboard.

Frequency On Demand

Security


CFR 431.300 to 307


131 of 172

Complaint Requirements




















The system shall provide the ability to remediate a system message without navigating to another screen (e.g., a display message, "All tasks must be closed close prior to closing the case" should allow the list of open tasks to be presented for user action).












132 of 172




The system shall provide administrators the ability to create and modify a Complaint Log Screen customized per business unit and PSA within the business units. An example of a complaint log for ADRC and providers can be found in the 2016 Complaint Log.xlsx.


The system shall provide an SMMC LTC Complaint Screen which is linked to a client record. A client may have multiple complaints open at a time. At a minimum the screen should provide fields for the date of the complaint, relationship to the enrollee, plan name, complaint referred to and a description of the issue. An example of the SMMC LTC complaint log can be found in the SMMC LTC Complaint Log.docx.


The system shall provide the ability to upload data directly to the ICSP database for SMMC LTC complaint tracking.


The system shall enable users to submit an online complaint and route per business rules.


The system shall enable authorized users to upload electronic documents or files to system records.


Engine



Functionality The system shall provide users with a visual indication of data entry fields that are mandatory (e.g., an asterisk next to required fields).


Functionality The system shall enable capturing, storing and maintaining (adding, modifying, deleting) case information linking records to one client.


and Forms The system should support standardized and customized user-based data entry screens, forms, and document templates.


Architecture

The system shall allow for the classification of documents, forms and records (e.g., 3008, 603, PASRR Level I, etc.) stored at the client and provider record level.



Non-Functional 654



Non-Functional 655





133 of 172



Architecture


134 of 172

4. SYSTEM CONFIGURATION UC-SYSCONFIG-01: Create or Modify Workflow

1. Description A workflow is a sequence or chain of processes wherein work passes from start through execution to completion. Workflow within a software application automates, to at least some degree, a process, or processes. A System Administrator will create a workflow to assist staff in completing a process to increase overall work efficiency. 2. Level Summary 3. Trigger • Received request to create or modify a workflow.

4. Primary Actor(s) • System Administrator

5. Other Actor(s) • DOEA Staff

6. Preconditions • Only System Administrators with the appropriate privileges can configure workflow. • The Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed

and the System Administrator has navigated to the Administration Screen.

135 of 172

4.1.1. Flow of Events: Create or Modify Workflow Main Success Scenario (Create Workflow) 1. The System Administrator selects Workflows from the Administration Screen. 2. The System displays the Workflows Screen. 3. The System Administrator selects Create New Workflow and the System displays the following

message: “New Workflow or Copy Existing Workflow?” 4. The System Administrator selects New Workflow and the System displays the Workflow Designer

Screen. 5. The System Administrator builds the workflow using a System Wizard or GUI and selects Save. 6. The System saves the workflow, sets the status to Pending Activation, and displays the Workflows

Screen. 7. The System Administrator selects Activate Workflow, enters the Activation Date, and selects Save. 8. The System sets the workflow status to Active on the Activation Date and displays the Workflows

Screen. Extensions Exception 1 Invalid Data Entered 5a The System displays a message for invalid data entered. 5b The System Administrator selects OK. 5c The Main Success Scenario is rejoined at Step 3. Exception 2 Premature Exit 5a The System Administrator selects Cancel. 5b The System returns to the Administration Screen and the Main Success Scenario is rejoined at Step 3. Alternatives Alternative 1 Create Workflow using Existing Workflow 1. The System Administrator selects Workflows from the Administration Screen. 2. The System displays the Workflows Screen. 3. The System Administrator selects Create New Workflow and the System displays the following

message: “New Workflow or Copy Existing Workflow?” 4 The System Administrator selects Copy Existing Workflow and the System displays a list of existing

workflows. 5. The System Administrator selects the existing workflow from the list and the System displays the

Workflow Designer Screen prepopulated with the values from the selected workflow. 6. The System Administrator customizes the workflow as required and selects Save. 7. The Main Success Scenario is rejoined at Step 6. Alternative 2 Modify Existing Workflow 1. The System Administrator selects Workflows from the Administration Screen. 2. The System displays the Workflows Screen with a list of existing Workflows. 3. The System Administrator locates the existing workflow and selects Edit. 4 The System displays the existing workflow in edit mode. 5. The System Administrator makes the required edits and selects Save. 6. The Main Success Scenario is rejoined at Step 6. Alternative 3 Activate Multiple Workflows at a Time 1. The System Administrator selects Workflows from the Administration Screen and the System displays

the Workflows Screen. 2. The System Administrator selects Workflows Pending Activation and the System displays a list of all

workflows with a Pending Activation status. 3. The System Administrator selects the checkbox next to each workflow with Pending Activation status

and selects Activate. 4. The System defaults the Workflow Begin Date to the system date.

5. The System saves the information, sets the status to Active, and displays the Workflows Screen.

136 of 172


• The workflow is successfully saved and status is set to Active. • The system displays the Workflows Screen.


• The system fails to save the workflow. • The system displays the Workflows Screen.

Frequency On Demand

Security


431.300 to 307

Usability/ Accessibility • The System shall support Section 508 accessibility software standards.

137 of 172

UC-SYSCONFIG-02: Create or Modify Standard Document Template 1. Description A standard document, or correspondence, is utilized when written communication must be mailed, faxed, or emailed to a client or provider. This ensures a standard message using consistent language is delivered to all clients and providers. A System Administrator creates a template in the system with the standard document or correspondence information. This allows other users to generate the documents from the client or provider record using system data to prepopulate the document. 2. Level Summary 3. Trigger • A request has been approved to create or modify a Document Template.

4. Primary Actor(s) • System Administration

5. Other Actor(s) • CARES Staff • DOEA Staff

6. Preconditions • Only System Administrators with the appropriate privileges can create or modify Document

Templates. • The Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed


138 of 172

4.2.1. Flow of Events: Create or Modify Standard Document Template Main Success Scenario (Create Standard Document Template) 1. The System Administrator selects Document Templates from the Administration Screen. 2. The System displays the Document Templates Screen. 3. The System Administrator selects Create Document Template. 4. The System displays the following message: “New Document Template or Copy Existing Document

Template?” 5. The System Administrator selects New Document Template and the System displays a new Document

Template Screen. 6. The System Administrator enters the template language, inputs the fields to be prepopulated, enters

the Document Template Name, and selects Save Document Template. 7. The System saves the information, sets the Document Template status to Pending Activation, and

displays the Document Template Screen. 8. The System Administrator selects Activate Document Template, enters the Activation Date, and selects

Save. 9. The System sets the Document Template status to Active on the Activation Date and displays the

Document Template Screen. Extensions Exception 1 Invalid Data Entered 5a The System displays a message for invalid data entered. 5b The System Administrator selects OK. 5c The Main Success Scenario is rejoined at step 5. Exception 2 Premature Exit 5a The System Administrator selects Cancel. 5b The System displays the Administration Screen and the Main Success Scenario is rejoined at Step 2. Alternatives Alternative 1 Use Existing Document as a Template 1. The System Administrator selects Document Templates from the Administration Screen. 2. The System displays the Document Templates Screen. 3. The System Administrator selects Create Document Template. 4 The System displays the following message: “New Document Template or Copy Existing Document

Template?” 5. The System Administrator selects Existing Document Template and the System displays a list of

Document Templates. 6. The System Administrator chooses the Document Template and selects Edit. 7. The System Administrator modifies the template language, inputs the fields to be prepopulated,

enters the Template Name, and selects Save Template. 8. The Main Success Scenario is rejoined at Step 7. Alternative 2 Upload a Standard Document Template 1. The System Administrator selects Document Templates from the Administration Screen. 2. The system displays the Document Templates Screen. 3. The System Administrator selects Upload Document Template. 4 The system displays a File Explorer window. 5. The System Administrator chooses the template file (that has been developed using template

standards) then selects Upload. 6. The system uploads the template programming logic and displays the Document Templates Screen. 7. The System Administrator names the document template and selects Save Template. 8. The Main Success Scenario is rejoined at Step 6. Alternative 3 Modify Standard Document or Correspondence Template 1. The System Administrator selects Document Templates from the Administration Screen. 2. The system displays the Document Templates Screen with a list of existing templates. 3. The System Administrator locates the template in the list and selects Edit.

139 of 172

4. The system displays the selected template in edit mode. 5. The System Administrator updates the document template as required and selects Save Template. 6. The Main Success Scenario is rejoined at Step 6. Post Conditions Success End Condition • The system saves the template and displays the Document Templates Screen.


• The system fails to save the template. • An error is displayed indicating the reason for the failure to save the template. • The system displays the Document Templates Screen.

Frequency On Demand

Security


CFR 431.300 to 307

Usability/ Accessibility • The System shall support Section 508 accessibility software standards.

140 of 172

UC-SYSCONFIG-03: Create or Modify Reports via Reports Wizard

1. Description Reports are used to assist with analysis, planning, decision making, and to provide relevant information to target audiences. The Report Developer creates or modifies the report using the Report Wizard to pull data from the system and display the data in the form of a report. 2. Level Summary 3. Trigger • A request is received to create or modify a report.

4. Primary Actor(s) • Report Developer

5. Other Actor(s) • AAA/ADRC Staff • CARES Staff • DOEA Staff • Lead Agency Staff/OAA Providers

6. Preconditions • The Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed

and the Report Developer has navigated to the Reports Screen. • The Report Developer is required to have access privileges to create a report.

141 of 172

4.3.1. Flow of Events: Create or Modify Reports via Reports Wizard Main Success Scenario (Create New/Ad Hoc Report) 1. The Report Developer selects Reports from the Reports Screen. 2. The System displays the Reports Screen. 3. The Report Developer selects New Report and the System displays the Report Wizard. 4. The Report Wizard guides the Report Developer through the required screens, allowing the Report

Developer to enter the required information into the wizard, and selects Create Report. 5. The system saves the information, sets the report status to Pending Activation, and displays the

Document Templates Screen. 6. The System Administrator selects Activate Report, enters the Activation Date, and selects Save. 7. The system saves the information, sets the status to Active on the Activation Date, and displays the

Reports Screen. Extensions Exception 1 Invalid Data Entered 6a The System displays a message for invalid data entered. 6b The Report Developer selects OK. 6c The Main Success Scenario is rejoined at Step 4. Exception 2 Premature Exit 6a The Report Developer selects Cancel. 6b The System displays the Reports Screen and the Main Success Scenario is rejoined at Step 3. Alternatives Alternative 1 Modify Existing Reports 1. The Report Developer selects Reports from the Reports Screen. 2. The system displays the Reports Screen with a list of the existing reports. 3. The Report Developer chooses the report, selects Edit, and the report is displayed in edit mode. 4. The Report Developer updates the required information and selects Save Report. 5. The system saves the information, sets the status to Pending Activation, and prompts the Report

Developer to enter an Activation Date. 6. The Main Success Scenario is rejoined at Step 6. Post Conditions Success End Condition

• The report is successfully saved and the report status is set to Active. • The system displays the Reports Screen.


• The system fails to save the report. • The system displays the Reports Screen.

Frequency On Demand

Security


CFR 431.300 to 307


142 of 172

UC-SYSCONFIG-04: Create or Modify Form 1. Description

Forms provide a representation of a GUI Window, i.e., a window or screen containing multiple fields used to enter data. Each field contains a field label so a user can ascertain its intended contents. Forms can resemble paper or database forms. Forms allow a user to enter data that is saved to a server/database for processing. 2. Level Summary 3. Trigger • A request is received to create or modify a form.


5. Other Actor(s) • AAA/ADRC Staff • CARES Staff • DOEA Staff • Lead Agency Staff/OAA Providers

6. Preconditions • Only System Administrators with the appropriate privileges can create or modify forms. • The Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed


143 of 172

4.4.1. Flow of Events: Create or Modify Form Main Success Scenario (Create New Form) 1. The System Administrator selects Forms from the Administration Screen. 2. The system displays the Forms Screen. 3. The System Administrator selects Create Form. 4. The system displays the Form Information Screen. 5. The System Administrator selects the fields and field types (e.g. text, number, date, list, etc.) to

appear on the form. 6. The System Administrator enters the required information for each field then selects Save. 7. The system saves the information, sets the Form status to Pending Activation, and displays the Form

Information Screen. 8. The System Administrator selects Activate Form, enters the Activation Date, and selects Save. 9. The system saves the information, sets the status to Active on the Activation Date, and displays the

Forms Screen. Extensions Exception 1 Invalid Data Entered 6a The system displays a message for invalid data entered. 6b The System Administrator selects OK. 6c The Main Success Scenario is rejoined at Step 4. Exception 2 Premature Exit 6a The System Administrator selects Cancel. 6b The system displays the Administration Screen and the Main Success Scenario is rejoined at Step 3. Alternatives Alternative 1 Modify Existing Forms 1. The System Administrator selects Forms from the Administration Screen. 2. The System displays the Forms Screen with a list of existing forms. 3. The System Administrator selects the form from the list and selects Edit. 4. The system displays the Form Information Screen in edit mode. 5. The System Administrator adds, removes, or modifies the fields on the form as required then selects

Save. 6. The Main Success Scenario is rejoined at Step 7. Post Conditions Success End Condition

• The form is successfully saved and the status is set to Active. • The system displays the Forms Screen.


• The system fails to save the form. • The system displays the Forms Screen.

Frequency On Demand

Security


CFR 431.300 to 307


144 of 172

UC-SYSCONFIG-05: Create or Modify Business Rules 1. Description A business rule is a rule that defines or constrains some aspect of business and always resolves to either true or false. Business rules are intended to assert business structure or to control or influence the behavior of the business. Business rules provide a simple mechanism to implement and maintain fast changing, commonly used rules applied to system forms. 2. Level Summary 3. Trigger • A request is received to standardize and optimize the business logic within a process.




and the System Administrator has navigated to the Administration Screen. • The System Administrator is required to have a System Administrator role.

145 of 172

4.5.1. Flow of Events: Create or Modify Business Rules Main Success Scenario (Create Business Rules) 1. The System Administrator selects Business Rules from the Administration Screen. 2. The System displays the Business Rules Screen. 3. The System Administrator selects Create Business Rule and the system displays the New Business

Rule Screen. 4. The System Administrator enters the required business logic and selects Apply Business Rule to Form. 5. The system displays the following message: “Please select the form(s) to apply the Business Rule(s).” 6. The system displays a list of form(s) to associate with the Business Rule. 7. The System Administrator selects the form(s), enters the required information, and selects Save. 8. The system saves the information and displays the Business Rules Screen. Extensions Exception 1 Invalid Data Entered 6a The system displays a message for invalid data entered. 6b The System Administrator selects OK. 6c The Main Success Scenario is rejoined at Step 3. Exception 2 Premature Exit 5a The System Administrator selects Cancel. 5b The system returns to the Administration Screen and the Main Success Scenario is rejoined at Step 3. Alternatives Alternative 1 Modify a Business Rule 1. The System Administrator selects Business Rules from the Administration Screen. 2. The system displays a list of existing business rules. 3. The System Administrator chooses the business rule and selects Edit. 4. The system displays the business rule in edit mode. 5. The System Administrator edits the business rule as required and selects Save. 6. The system saves the information and displays the Business Rules Screen. Post Conditions Success End Condition

• The business rule is successfully saved. • The system displays the Business Rules Screen.


• The system fails to save the business rule. • The system displays the Business Rules Screen.

Frequency On Demand

Security


CFR 431.300 to 307


146 of 172

UC-SYSCONFIG-06: Create or Modify Dashboard 1. Description A Dashboard is a user interface that provides a current summary, usually in graphic, easy-to-read form, of key information relating to work tasks, progress or status, and performance. 2. Level Summary 3. Trigger • A request is received to create or modify a standard dashboard user interface.




and the System Administrator has navigated to the Administration Screen. • The System Administrator is required to have the System Administrator role.

147 of 172

4.6.1. Flow of Events: Create or Modify Dashboard Main Success Scenario (Create Dashboard) 1. The System Administrator selects Dashboards from the Administration Screen. 2. The system displays the Dashboards Screen. 3. The System Administrator selects Create Dashboard and the system displays the Dashboard

Information Screen. 4. The System Administrator designs the dashboard layout and selects Save. 5. The System displays the following message: “Share Dashboard with a user(s) or role(s)?” and allows

the System Administrator to share the dashboard. 6. The system displays a Look Up Records window with a list of available users and roles. 7. The System Administrator selects the user(s) or role(s) to be granted access to the Dashboard and

selects Save. 8. The system saves the information, sets the status to Pending Active, and displays the Dashboard

Information Screen. 9. The System Administrator selects Activate Dashboard, enters the Activation Date, and selects Save. 10. The system sets the Dashboard to Active on the Activation Date and displays the Dashboard Screen. Extensions Exception 1 Invalid Data Entered 4a The system displays a message for invalid data entered. 4b The System Administrator selects OK. 4c The Main Success Scenario is rejoined at Step 3. Exception 2 Premature Exit 4a The System Administrator selects Cancel. 4b The system returns to the Administration Screen and the Main Success Scenario is rejoined at Step 3. Alternatives Alternative 1 Modify Dashboard 1. The System Administrator selects Dashboards from the Administration Screen. 2. The System displays the Dashboards Screen with a list of existing Dashboards. 3. The System Administrator selects the Dashboard to modify and selects Edit. 4. The System displays the Dashboard in edit mode. 5. The System Administrator updates the Dashboard as required and selects Save. 6. The Main Success Scenario is rejoined at Step 8. Alternative 2 User Modifies Home Dashboard 1. The user selects the Edit Dashboard icon on their Home Dashboard. 2. The system displays the user’s Home Dashboard in edit mode. 3. The user edits the configurable items displayed on the Dashboard and selects Save. 4. The system updates the Dashboard with the new information and displays the user’s modified Home

Dashboard. Post Conditions Success End Condition

• The Dashboard is successfully saved and status is set to Active. • The system displays the Dashboards Screen.


• The system fails to save the Dashboard. • The system displays the Dashboards Screen.

Frequency On Demand

Security


CFR 431.300 to 307

148 of 172


149 of 172

System Configuration Requirements



The system shall provide the ability to notify the user of a scheduled event based on user-defined criteria or business rules within a workflow (e.g., reminder time, delivery mechanism).


The system shall enable authorized users to enter and maintain data validation rules.


The system shall enable authorized users to define data dependencies.




The system shall provide the ability to maintain administrator-defined business rules specific to tracking information across multiple time zones (e.g., calendaring with the ability to reconcile 9:00 AM EST is 8:00 AM CST).


The system shall provide the ability for authorized users to create, modify and delete business rules for processing email messages sent to email addresses, contains keywords, or sent with a specific subject line.


The system shall allow the ability for system-based workflow actions populate fields as a business rule without intervention from the user.




The system shall enable an authorized user to create standard form letters for generating an unlimited number of correspondence types.


The system shall enable authorized users to modify correspondence (both system generated and manually generated).


The system shall provide the ability to store, retrieve, and resend one or many correspondence items in a single user request.


The system shall enable generating correspondence as printed letters or a variety of electronic media in accordance with business rules.


The system shall provide the ability to produce correspondence and envelope printing options, electronic files, and/or email for mass mailings.


The system shall have the ability to create or update correspondence templates for use in the development of correspondence.


The system shall utilize approved correspondence templates for use in the development of correspondence.

150 of 172



The system shall pre-populate correspondence variables based as determined in the template definitions.


The system shall provide the ability to create a review workflow process and approve templates for use in correspondence.


The systems shall support WYSIWYG editing of the correspondence.


The system shall support the maintenance of correspondence outside of a workflow (business process) where ad hoc generation/maintenance of correspondence may occur.

Functional 135 CRM The system shall provide a user dashboard to allow for quick and easy access to scheduled events, tasks, follow-ups, documents, and alerts as they are associated with client or provider records.

Functional 136 CRM The system shall enable authorized users to create, modify and delete hyperlinks to internal and external documents, records, files, or sites for use on their dashboard or within case notes.


The system shall enable authorized users to maintain and manage the pick lists within the system.




The system shall provide the ability for an authorized user to create, modify, and delete look-up values including both codes and code values.


The system shall provide the ability to deploy new functionality to the system without impacting existing non-related functionality.



Functional 217 Usability The system shall enable authorized users to configure the properties, format, and display of data elements.



Functional 224 Usability The system shall utilize colors or other visual and non-visual aids to facilitate the use of system functions in accordance with Section 508 standards.

Functional 225 Workflow The system shall automatically generate electronic communications, alerts or documents at user-specified milestones within a workflow.

151 of 172



The system shall enable users to configure rules-based notifications at a minimum system alerts (e.g., pop-up windows) and automatically generated notifications with variable narrative or appropriate web links.

Functional 227 Workflow The system shall allow for tasks to be created and initiated by a workflow action.

Functional 228 Workflow The system shall allow for authorized users to set due dates for workflow actions.

Functional 229 Workflow The system shall be able to utilize preconfigured due dates and apply them at the action level when the action is created within the workflow.

Functional 230 Workflow The workflow system shall allow only the current owner and authorized proxies (i.e., supervisors) of an action to modify routing information.

Functional 233 Workflow The system shall provide the ability to enable and disable review steps in a workflow based on business rules.

Functional 235 Workflow The system shall provide workflow functionality.

Functional 240 Workflow The system shall provide the ability to manage case data and create process workflows.

Functional 241 Workflow The system shall enable managing client data and creating assessment and screening process workflows for an unlimited number of DOEA, AAA, ADRC, and Lead Agency activities.

Functional 242 Workflow The system shall enable an authorized user to define external user data requirements and workflows for an unlimited number of external user types.

Functional 243 Workflow The workflow system shall be able to support automated and non-automated tasks.

Functional 244 Workflow The workflow system shall allow authorized users to define the business processes to be managed by the workflow.

Functional 245 Workflow The workflow system shall coordinate the execution of the defined processes.


The workflow system shall ensure that work can be moved through the defined process. This requirement provides the general capability that requires each work item to move through each defined process steps.

Functional 248 Workflow The workflow system shall allow the viewing of the existing workflows in both text and diagram form.

Functional 249 Workflow The system shall enable authorized users to create, edit, and terminate a workflow process.

Functional 250 Workflow The system shall enable authorized users to add, view, delete, or modify an activity to a workflow process.

Functional 251 Workflow The system shall enable authorized users to assign one or more users or roles to an activity associated with a workflow process.

Functional 252 Workflow The system shall enable authorized users to define alerts associated with a workflow activity.

152 of 172


Functional 253 Workflow The system shall enable authorized users to define time thresholds, parameters, and lead and lag times between activities for each workflow activity.

Functional 254 Workflow The system shall enable authorized users to define concurrent activities within a workflow transaction.

Functional 261 Workflow The system shall provide for each authorized user an electronic work queue (‘inbox’) capability to show assigned work.

Functional 271 Workflow The system shall have the capability to maintain workflows and work queues.

Functional 272 Workflow The system shall provide the ability to define workflow routes and associated details based on user-defined business processes.

Functional 275 Workflow The system shall provide the ability to modify workflow routes which are in production.

Functional 277 Workflow The system shall provide the ability to apply version control to workflows to maintain a history of changes to the workflow routes, actions, security and assigned user roles.

Functional 278 Workflow The system shall provide the ability to organize work items into work queues based on administrator-defined business rules.

Functional 279 Workflow The system shall provide authorized users the ability of to assign workflow users to work queues.

Functional 281 Workflow The system shall provide authorized users the ability to assign work items to users based on predefined business rules.


The system shall provide the ability to establish administrator-defined business rules to prevent assignment of work to a user based on user availability (e.g., vacation, sickness, existing workload).

Functional 285 Workflow The system shall provide the ability to create tasks from system and user-initiated events.

Functional 288 Workflow The system shall provide the ability to move work items between workflow steps based on defined workflow rules.

Functional 299 Workflow The system shall provide the ability to query the workflows, based on defined criteria, to find a specific task.


The system shall provide the ability to create customized notifications and alerts related to actions taken during a workflow process and assign them according to business processes (e.g., providing an alert to check for required medical documentation prior to the assessment that the user scheduled).


The system shall provide authorized users to associate templated document creation actions to a workflow process according to business rules. (e.g., associate creation of a PASSR Notification document to the PASRR Level II request task).

Functional 319 Workflow The system shall enable an authorized user to create new process workflows, and modify existing workflows to reflect business rules.

153 of 172



The system shall provide the ability to easily access associated functionality of workflows and their screens from a centralized dashboard.


The system dashboards shall be customizable to the role of the user.

Non-Functional 521 Reporting and

Dashboard The system shall provide the ability to view pre-existing reports according to the role of the user.


The system shall provide a dashboard management tool to track user configured outcome performance measurements.


The system shall generate and display management dashboards for reporting performance metrics and statistics (key performance indicators, business unit goals, and business and trend reporting or analysis).


The system shall provide a user-configurable dashboard utilizing on-demand queries and standard reports to provide information to the user in a summary drill-down format.


The system shall have the capability to verify that any new business rule created does not conflict or interfere with an existing rule.


and Forms



and Forms The system should support standardized and customized user-based data entry screens, forms, and document templates.


Architecture







The system shall display for editing data entry screens based on field restrictions and user role set at the action level of a workflow.


The system shall enable authorized users to rapidly configure and implement new business rules and workflows as needed (e.g., changes to federal or state laws, changes in Department policies or procedures, or other event-driven needs).


Architecture


154 of 172




155 of 172

5. Interfaces and Interoperability UC-INTERFACEINTEROP-01: Upload Data Using System Batch Upload

1. Description The user has completed a manual assessment, or provided services, and uploads the data via an ANSI 837, comma separated value (.CSV), or other supported file format file to populate assessment and services data for a client or set of clients to the system. 2. Level Summary 3. Trigger • An assessment or services have been completed and documented external to the system. The

assessments and services must be uploaded to the system for tracking and billing purposes. 4. Primary Actor(s) • Lead Agency Staff • AAA/ADRC Staff


6. Preconditions • Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed. • The client(s) and provider(s) linked to the data in the file must exist in the system.

156 of 172

5.1.1. Flow of Events: Upload Data Using System Batch Upload Main Success Scenario (Upload Data Using System Batch Upload) 1. The user selects Upload Batch File from the user’s Home Dashboard. 2. The system displays the Batch Upload Screen. 3. The user selects Upload Assessment Data. 4. The system displays the File Explorer window and the user selects Browse. 5. The user browses to the file, chooses the file, and selects OK. 6. The system uploads the file, parses, and validates the data. 7. Each client record is updated with the data and a confirmation report of success is displayed to the

user. Extensions Exception 1 Invalid Data Entered 6a The data validation is not successful; a failure report is displayed to the user with the following

information: o Date/time stamp of error; o Login of requestor; and o Error identifier and error message.

6b The Use Case Scenario ends and the system displays the user’s Home Dashboard. Exception 2 The File Upload is Interrupted 6a The upload of the file fails; a failure report is displayed to the user with the following information:

o Date/time stamp of error; o Login of requestor; and o Error identifier and error message.

6b The Use Case Scenario ends and the system displays the Client or Provider Record Screen. Alternatives Alternative 1 Upload Client Services Data 1. The user selects Upload Batch File from the user’s Home Dashboard. 2. The system displays the Batch Upload Screen. 3. The user selects Upload Service Data. 4. The system displays the File Explorer window and the user selects Browse. 5. The Main Success Scenario is rejoined at Step 5. Post Conditions Success End Condition

• Required data is uploaded and saved to the system. • A message of successful completion is displayed. • The system displays the user’s Home Dashboard.


• The system fails to save the data. • An error is displayed indicating the reason for the failure to save the data. • The system displays the Batch Upload Screen.

Frequency On Demand

Security


CFR 431.300 to 307


157 of 172

UC-INTERFACEINTEROP-02: User Uploads a File to a System Record 1. Description A user chooses to upload a file to a client or provider record within the system. 2. Level Summary 3. Trigger • A document is received and needs to be added to a client or provider record.



6. Preconditions • Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed. • The user has navigated to the Client or Provider Record.

158 of 172

5.2.1. Flow of Events: User Uploads a File to a System Record Main Success Scenario (User Uploads a File to a System Record) 1. The user selects Upload File from the Client or Provider Screen. 2. The system displays a File Explorer window. 3. The user selects Browse, selects the file to be uploaded, and selects OK. 4. The system validates the file type per business rules and displays a file document data entry screen. 5. The user enters the required metadata information and selects OK. 6. The system validates the selections, indexes the file, and uploads the file to the client’s or provider’s

system record. 7. The system displays a message of success and the Client Record Screen or Provider Screen is

displayed. Extensions Exception 1 Invalid Data Entered 6a The validation of the file type fails; a failure report is displayed to the user with the following


6b The Main Success Scenario is rejoined at Step 2. Exception 2 The File Upload is Interrupted 4a The upload of the file fails; a failure report is displayed to the user with the following information:


4b The Use Case Scenario ends and the system displays the Client Record Screen or Provider Record Screen.


• The file is uploaded and saved to the system. • A message of successful completion is displayed. • The system displays the Client Screen or Provider Screen.


• The system fails to save the file. • An error is displayed indicating the reason for the failure to save. • The system displays the Client Screen or Provider Screen.

Frequency On Demand

Security


CFR 431.300 to 307


• The ability to enter data must be accessible and usable via mobile devices such as tablets with a cellular wireless connection.

• The ability to enter data must be available in an offline mode with a synchronization of the data after reconnection to the system.


159 of 172

UC-INTERFACEINTEROP-03: User Batch Uploads Data using an Encrypted HTTPS Site

1. Description The user uploads an ANSI 837, .CSV, or other supported file format, to populate data for a client or set of clients. 2. Level Summary 3. Trigger • An assessment or services have been completed and documented external to the system. The

services must be uploaded to the system for tracking and billing purposes. 4. Primary Actor(s) • Lead Agency Staff/OAA Providers • AAA/ADRC Staff • Managed Care Organizations • Providers

5. Other Actor(s) • Client • CARES Staff

6. Preconditions • The Client(s) and Provider(s) linked to the data in the file must exist in the system.

160 of 172

5.3.1. Flow of Events: User Batch Uploads Data using an Encrypted HTTPS Site Main Success Scenario (User Batch Uploads Data using an Encrypted HTTPS Site) 1. The user opens the default web browser and navigates to the encrypted HTTPS site. 2. The system displays the Batch Upload screen. 3. The user selects Upload Assessment Files and the system displays the File Explorer window. 4. The user chooses the file(s) and selects OK. 5. The system displays the selected file(s) and prompts the user for the provider’s credentials. 6. The user enters their Medicaid Provider ID and DOEA Unique Provider ID then selects Upload. 7. The system uploads the file, parses, and validates the data. 8. Each client record is updated with the assessment data and a confirmation report is displayed to the

user. Extensions Exception 1 Invalid Data Entered 4a The data validation is not successful; a failure report is displayed to the user with the following


4b The Use Case Scenario ends and the system displays the Encrypted HTTPS Site. Exception 2 The File Upload is Interrupted 4a The upload of the file fails; a failure report is displayed to the user with the following information:


4b The Use Case Scenario ends and the system displays the Client or Provider Record Screen. Alternatives Alternative 1 Upload Client Service Data 1. The user opens the default web browser and navigates to the encrypted HTTPS site. 2. The system displays the Batch Upload screen. 3. The user selects Upload Service Files and the system displays the File Explorer window. 4. The user chooses the file(s) and selects OK. 5. The system displays the selected file(s) and prompts the user for the provider’s credentials. 6. The user enters the Medicaid Provider ID and DOEA Unique Provider ID then selects Upload. 7. The system uploads the file, parses, and validates the data. 8. Each client record is updated with the service data and a confirmation report is displayed to the user. Alternative 2 Upload PASRR Level I 1. The user opens the default web browser and navigates to the encrypted HTTPS site. 2. The system displays the Batch Upload Screen. 3. The user selects Upload PASRR Files and the system displays the File Explorer window. 4. The user chooses the file(s) and selects OK. 5. The system displays the selected file(s) and prompts the user for the provider’s credentials. 6. The user enters their DOH License ID then selects Upload. 7. The system verifies the license information, uploads the file, parses, and validates the data. 8. Each client record is updated with the PASRR data and a confirmation report is displayed to the user. Post Conditions Success End Condition

• If the system validation is successful, the client’s record is updated with data and a confirmation report is displayed to the user in the Batch Upload Screen.

• The system updates contract tracking totals with the services provided and displays the encrypted HTTPS Site.

161 of 172


• If the data validation was not successful, a failure report is displayed to the user with the following information: o Date/time stamp of error; o Login of requestor; and o Error identifier and error message.

Frequency On Demand

Security


CFR 431.300 to 307


162 of 172

UC-INTERFACEINTEROP-04: Send Fax 1. Description The user sends a fax from the system. 2. Level Summary 3. Trigger • A user is required to fax information from the system to an external recipient.

4. Primary Actor(s) • ADRC Staff • CARES Staff • Lead Agency Staff/OAA Providers


6. Preconditions • Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed. • Use Case UC-APPFUNCT-03: Create or Modify Case has been completed.

163 of 172

5.4.1. Flow of Events: Send Fax Main Success Scenario (Send Fax) 1. The user selects Client Documents from the Client Screen. 2. The system displays a list of Client Documents, the user selects the appropriate documents, and selects

Send Fax. 3. The user inputs the recipient's fax phone number. 4. The user selects Send Fax. 5. The user is returned to the Client Screen. Extensions Exception 1 Fax Attempt is Unsuccessful 3a If the fax fails to transmit properly, the user will click Cancel. 3b If user chooses to transmit fax again, the Main Success Scenario is joined at step 2, or user can print

and mail. Alternatives Alternative 1 Send Fax from Case Screen 1. The user selects Cases from the Client Screen. 2. The system displays the list of cases for the client. 3. The user selects the appropriate case and the system displays the Case Screen. 4. The user selects Client Documents from the Case Screen. 5. The system displays the list of documents associated with the case. 6. The user selects the document(s) and selects Send Fax. 7. The user inputs the recipient's fax phone number. 8. The user selects Send Fax. 9. The user is returned to the client Case Screen. Post Conditions Success End Condition

• The selected files are faxed to the recipient. • The Client Case screen is displayed.


• The system fails to fax the selected files. • An error is displayed indicating the reason for the failure to fax the selected files. • The Client Case screen is displayed.

Frequency On Demand

Security


431.300 to 307


164 of 172

UC-INTERFACEINTEROP-05: Send Email 1. Description The user sends an email from the system. 2. Level Summary 3. Trigger • A document must be sent for completion to a client or a provider.

4. Primary Actor(s) • ADRC Staff • CARES Staff • Lead Agency Staff/OAA Providers


6. Preconditions • Use Case UC-SECURITY-01: User Logs into the System through Web Browser has been completed. • Use Case UC-APPFUNCT-03: Create or Modify Case has been completed.

165 of 172

5.5.1. Flow of Events: Send Email Main Success Scenario (Send Email) 1. The user selects Client Documents from the Client Screen. 2. The system displays a list of Client Documents, the user selects the appropriate document(s), and

selects Email Selected Document(s). 3. The system opens the user’s default email client with the document(s) attached to a new email message,

and the user inputs the recipient's email address. 4. The user selects Send Email. 5. The user is returned to the Client Screen. Extensions Exception 1 Invalid Email Address 3a If the email address entered for the recipient is invalid, the system will display an error message. 3b The user selects OK and the Main Success Scenario is rejoined at Step 2. Alternatives Alternative 1 Send Email from Case File 1. The user selects Cases from the Client Screen. 2. The system displays the list of cases for the client. 3. The user selects the appropriate case and the system displays the Case Screen. 4. The user selects Client Documents from the Case Screen. 5. The system displays the list of documents associated with the case. 6. The user selects the document(s) and selects Email Selected Files. 7. The system opens the user’s default email client with the documents attached to a new email message

and the user inputs the recipient's email address. 8. The user selects Send Email. 9. The user is returned to the Case Screen. Post Conditions Success End Condition

• The selected files are emailed to the recipient. • The Client Screen is displayed.


• The system fails to email the selected files. • An error is displayed indicating the reason for the failure to email the selected files. • The Case Screen is displayed.

Frequency On Demand

Security


CFR 431.300 to 307


• The ability to login should be accessible via mobile devices such as tablets with a cellular or wi-fi connection.



166 of 172

Interface and Interoperability Requirements


Functional 8 Workflow The system shall provide the ability to notify predetermined user(s) of a submitted PASRR Level I and PASRR Level II when initiated through integrated fax or scan technology.


The system shall enable the scheduling, manual initiation, and control of all batch processes.


The system shall provide the ability to identify the method of transmission for each type of notification (e.g., paper, electronic).


The system shall provide the ability for authorized users to create, modify and delete business rules for processing email messages sent to specific email addresses, contains particular keywords or sent with a specific subject line.


The system shall provide the ability to produce correspondence and envelope printing options, electronic files, and/or email for mass mailings.


The system shall provide the capability to attach existing images, documents and correspondence to a new correspondence.


The system shall provide date time stamps or alert notifications for correspondence distribution as successful or unsuccessful in distribution (e.g., was the email or fax sent?)


The system shall provide a capability to develop and publish correspondence to multiple recipients within a defined business process (e.g., not developed one recipient at a time)


The system shall have the ability to produce and send corrected correspondence.


The system shall support the ability to manually and automatically resend correspondence if a system failure occurs before or during distribution (e.g., SMTP failure, internet connection failure, etc.).


The system shall support the maintenance of correspondence outside of a workflow (business process) where ad hoc generation/maintenance of correspondence may occur.


The system shall enable batch processing of user-configured mass e-mailings.

Functional 128 CRM The system shall provide the ability to communicate with clients or providers based on their preferred communication method (e.g., email notifications, fax, paper).






167 of 172



The system shall enable users to search on available indexed help topics.


The system shall report batch processing results (success, failure) for each batch job.


The system shall display a warning to all users if the browser does not meet the minimum technical requirements to display and utilize the application.


The system shall provide the ability to restart an interface transmission from a specific point (e.g., restart at failed record, restart from beginning).




The system shall provide document digital imaging functions that allow the user to view digital facsimiles of documents that are generated and associated with the system functions. The document digital imaging functions shall provide for easy duplicate printing of the selected document.


The system shall provide the ability to retrieve and view imaged documentation provided by users and clients based on business rules.


The system shall have the capability to perform optical character recognition (OCR) on scanned documents and images including documents uploaded in various formats (e.g., PDF, TIFF, JPEG, etc.).




The system shall have the ability to process emails according to business rules in which the email message is sent with a specific subject line, contains particular keywords within the body of the message or is sent to a particular email address.


The system shall automatically update a client's date of death field in the system to match the imported data from the Department of Health's (DOH) Office of Vital Statistics, according to business rules (e.g., if the current date of death is blank, the SSN, name and date of birth matches the Vital Statistic imported data).


The system shall allow the ability to created, modify, and send by email correction requests to the Department of Health's (DOH) Office of Vital Statistics.





168 of 172



The system shall provide the ability for authorized users to preform batch uploading from key navigation points within the system using a native Windows Browse and Select screen.

Functional 209 Security The system shall enable viewing of retrieved correspondence based on user-defined business rules and user roles.



Functional 232 Workflow The system shall enable sending an email and/or notification when a workflow step requires action from an authorized user.

Functional 236 Workflow The system shall allow for email generation to each provider associated with a client record using the provider record data to individualize the correspondence.

Functional 237 Workflow The system should allow for email generation based on an action designated within a workflow.


The system shall provide the ability to initiate a workflow through the receipt of an electronic form or occurrence of a system event (e.g., uploaded form, imaged documentation, receipt of referral, appointment scheduled, receipt of requested documentation).


The system shall provide the ability to issue administrator-defined time-based reminders (e.g., task not processed within defined time frames, task not yet assigned, processing on the task has not been initiated).


The system shall create alerts according to business rules and apply a verification required status code to documents ingested into the system by OCR scan or fax technology when the OCR process determines the data integrity does not meet a pre-configured accuracy threshold. The verification required status code is removed after user intervention is used to confirm data accuracy.


The system shall allow authorized users to upload assessment data to the system utilizing standardized formats (e.g., CSV, ANSI 837, PDF) without direct access to client data.


The system should allow for email generation based on an action designated within a workflow.


The system shall provide the ability to generate correspondence and populate appropriate fields with data from the database record.


The system shall enable sending email notifications to clients whose preferred method of notification is electronic.


The system shall provide the ability to manually associate correspondence to the appropriate case, client, or provider file.

169 of 172



The system shall provide the ability to upload data directly to the ICSP database for SMMC LTC complaint tracking.


The system shall provide the ability to report on interface transmissions (e.g., total number of records loaded, date of interface transmission, amount of time to execute the interface transmission, errors, and failures).


The system shall enable authorized users to upload electronic documents or files to system records.


The system shall provide the ability to support internal and external feeds of data using common available protocols.


The system shall provide the ability to transmit the exported data through multiple methods (e.g., SFTP, web service, single and batch transactional).


The system shall allow for the upload of documents from an external mechanism directly into the document management system with a link to the associated client record.

Functional 452 CRM The system shall provide the ability for a user to upload and link electronic documents to a record.


The system shall enable an authorized user to define a maximum image file size according to business rules.

Functional 456 Workflow The system shall enable authorized users to access relevant documents that are associated with a workflow action.


The system shall interface with the Department of Children and Families' (DCF) KEPRO used to upload Pre-Admission Screening and Resident Review (PASRR) Level I and II documentation.


The system shall allow authorized users to develop import procedures so data from external entities can be used to update records.


The system shall integrate with inbound and outbound email technology.


The system shall provide the ability to accept direct fax-to-image.


The system shall enable batch processing including parsing engines of ANSI 837, comma separated value (.csv) and text-based files.


The system shall enable batch processing of uploaded, faxed or scanned data received from external sources using business rules to update case records and provide notifications to case owners of the event.


The system shall integrate with inbound and outbound landline fax and cloud fax (e.g., CenturyLink Cloud Fax) technology.


The system shall provide the ability to integrate with third-party applications (e.g., address validation solutions, Master Data Management solutions, Microsoft Office, Adobe Acrobat, etc.).

170 of 172



The system shall provide the ability to generate and execute scripts to import and export data in multiple formats.


The system shall provide the ability for processing reports in batch.


The system shall allow for an ANSI 837 file to be uploaded, parsed, and data inserted into appropriate database fields.


The System shall have the ability to track services and resources provided to a client including the unit increments the service was provided.


The system shall provide a Services Screen filtered by provider instead of by client to display all active services being provided by the user's provider network when the user logged in has the role of provider or other role as designated by business rules.


The system shall provide authorized users with the ability to set an invoice status indicating the system is required to include it in the next scheduled batch upload to the ACMS database.


The system shall provide the ability for system administrators to schedule batch upload jobs to the ACMS database on pre-defined intervals.


The system shall interface with the ACMS system providing the ability for the ACMS system to upload data directly to the system.


The system shall parse uploaded data from the ACMS system and update identified invoices and billed services according to business rules (e.g., marking a service and invoice as Paid).


The system shall provide a hyperlink or other navigation path to authorized users from a service provided and billed to an invoice generated and from an invoice generated to a service provided and billed.


The system shall provide the ability to delineate between units of referral and units of information based on a completed follow-up within a specified date span from the date of Intake.


The system shall include tools for automated scheduling of system support events (e.g., data backup, external interface processing, batch processing).


The system shall provide defined and documented procedures and processes to restart system components and recover and restore incomplete transactions.




Engine



Functionality


171 of 172



and Forms



and Forms The system shall retain a history of all letters and notices generated.


and Forms The system shall indicate the status of a correspondence including unsent, sent, draft or final.


and Forms The system shall provide a unique identifier for correspondence items.


and Forms The system shall capture a date time stamp for incoming correspondence as it is received by the system.


and Forms The system shall capture the method of correspondence for the correspondence item (e.g., postal mail, email, text message).


and Forms The system shall store published correspondence in non-editable format (e.g., .pdf).


and Forms The system shall provide a date-time stamp on all published correspondence.


and Forms

The system shall maintain historical summary level information about the correspondence (e.g., status, routing, creation/update, version).

Non-Functional 630 CRM The system shall provide the ability to process in excess of

1,000 inbound and outbound faxes per day.


Architecture





Architecture The system shall provide the ability to "roll back" non-committed transactions in the event of a system failure.






Support Services



Support Services The system shall provide the ability to present an error list for failed data imports and exports.

Non-Functional 657


The system shall maintain a complete history of all batch jobs.

Non-Functional 658


The system shall delete or archive case information, by type, on the configured date.

172 of 172



Interoperability

The system shall provide the ability to perform secure file transfers using a file transfer method such as SFTP, FTPS, SSH, etc.


Interoperability

The system shall be implemented to ensure existing system interfaces are maintained and future interfaces can be easily created for data exchange.


Interoperability The system shall provide the ability to fully integrate with email software such as Microsoft Outlook using API standards.


Interoperability

The system shall provide a document management system or the ability to integrate into an external document management system (e.g., Microsoft SharePoint, NewGen OmniDocs, Hyland OnBase).

Non-Functional 724 Security The system shall scan all external file transfers for viruses

before accepting them into the data repository. Non-Functional 753 Security The system shall support Secure Sockets Layer (SSL) or,




Non-Functional 755 Security The system shall encrypt data transmission information (e.g.,

URLs, query strings, connection strings).

Non-Functional 756 Security The system shall encrypt data at the data layer in transit and at

rest.


The system shall enforce approved authorizations for controlling the flow of information within the system and between interconnected systems.


The system shall ensure transactions and messages are accurately received as they were sent and information is not altered by non-authorized individuals (message digest hash).


The system shall provide access controls that permit or deny access to the application, information, or other resources, based on parameters including the identity of the source system and the target.

Non-Functional 762 Security The system shall prevent unauthorized and unintended

information transfer between shared system resources.


The system shall monitor and control communications at the external boundary of the system and at key internal boundaries within the system.

eCIRTS Use Case Scenarioselderaffairs.state.fl.us/doea/eCIRTS/eCIRTS_Use_Case_Scenarios.pdfo...

Documents

Transcript of eCIRTS Use Case Scenarioselderaffairs.state.fl.us/doea/eCIRTS/eCIRTS_Use_Case_Scenarios.pdfo...