Attachment - Sandata Business Rules.pdf

IL DHS

EVV Technical

Configuration Business Rules v 1.0

Non Agency

Updated

Month Year

Presented to: Illinois Department of Human Services

Presented by: Sandata Technologies, LLC

3 Confidential and Proprietary DHS Business Rules-draft January 30, 2018

REVISION HISTORY

Date Author Description

May 2015 J. Ross Creation of initial draft of document (based on original business rules document)

July 15, C. Holthaus 6.2 WebCM Processing Rules updated

Nov 2015 C. Holthaus Major updates by IL DHS

Dec 2016 J. Zbinden WebCM Transactions finalized

Sept

IL DHS and Sandata Business Rules Committee

Version 1.0 finalized

4 Confidential and Proprietary DHS Business Rules-draft

APPROVAL

Title Name Signature Date

IL DHS – HSP/Manager, IP Unit EVV and Impact

Manjula Rigg

IL DHS – Dept. of Innovation and Technology

Cheryl Holthaus

Sandata – Account Manager

Joy Zbinden

REFERENCES

Document Description Last Modified Date

DHS EVV Technical Configuration Business Rules Revised Final_2013_08_29_2013

Final signed program business rules

08/29/2013

Data Interface Specification V1.4 Current data interface specifications for the program

10/13/2014

Customer Portal User Guide – IL DHS Original DHS Member Portal User Guide

6/6/2014

5 Confidential and Proprietary DHS Business Rules-draft

Revision History

Approval

References

1.0 Terminology

2.1. Account / Agency

2.2. Actual Hours

2.3. Adjusted Hours

2.4. Approval

2.5. Authorization

2.6. Authorization Status

2.7. Call In

2.8. Call Out

2.9. Call Processing / Call Matching

2.10. Client / Customer / Participant

2.11. Cross Reference / XRef

2.12. Dashboard

2.13. Electronic Visit Verification - EVV

2.14. Employee / IP (Individual Provider)

2.15. Exception

2.16. Fixed Visit Verification

2.17. Formal Eligibility (IL DHS)

2.18. Interim Call / Extraneous Call

2.19. Interim Eligibility (IL DHS)

2.20. Interrupt Services (IL DHS)

2.21. Interactive Voice Response (IVR)

2.22. Mobile Visit Verification (MVV)

6 Confidential and Proprietary DHS Business Rules-draft

2.23. Overnight Visit

2.24. Pay Hours

2.25. Pay Period

2.26. Payer

2.27. Provider Agency

2.28. Rates

2.29. Reason Codes

2.30. Santrax ID

2.31. Schedule

2.32. Service

2.33. Service Plan (IL DHS)

2.34. Unknown Employee

2.35. Unknown Client / Phone Number

2.36. TVV – Telephonic Visit Verification

2.37. User

2.38. Visit

2.39. Visit Status

Interfaces

4.1 Process Flows

Rules

4.1 Visit Approval

6.2. EVV / Web CM Processing Rules

Illinois DHS Use Cases & Transactions

Sandata Transaction Handling

Rounding Rules

Rules – Payroll Export

7 Confidential and Proprietary DHS Business Rules-draft

2.0 UAT Environment

3.0 Appendix 1 – Interface Field Mapping

8 Confidential and Proprietary DHS Business Rules-draft

Overview

At the origination of the program, IL DHS and Sandata agreed to a set of business rules for the program. The program has been active since January 1, 2014 and the following is intended to update the business rules and provide additional clarification where needed. Many of the sections from the original business rules have been omitted. These sections remain as-is from the original document.

This document is limited to the non-Agency portion of the program only, The document is divided into the following major sections:

Terminology

Interfaces

Data Flows

Rules

UAT Environment specifications

Each section is organized with a short description of the configuration element(s) followed by a summary of technical configuration decisions.

9 Confidential and Proprietary DHS Business Rules-draft

1.0 TERMINOLOGY

The following terms are being provided and defined for the benefit of all participants. We have identified that terminology is key to program success and we have seen many cases where Illinois DHS and Sandata identify the same item in different ways.

2.1. Account / Agency

A unique number for each entity that requires its workers to participate in electronic visit verification. The unique number for the IL DHS customer directed services account is 2070. This number is part of the transaction that is sent to Sandata to assist in identification.

Homemaker and Home Health agencies providing service to IL DHS customers and using Sandata have their own unique account number.

2.2. Actual Hours

The actual hours computed for the visit before any rounding rules are applied. This is calculated as follows: Call Out Date/Time minus Call In Date/Time. Actual time is not user modifiable. If either the Call In or the Call Out is missing, this value will not be calculated.

2.3. Adjusted Hours

The user has the ability to set hours to reflect the time worked if it is different from the time captured by telephony. This includes an adjusted in and adjusted out. The user can update either or both the adjusted in and adjusted out. The other value will be the call in or out value.

Once adjusted times are entered, the hours worked on the visit are calculated based on Adjusted Out minus Adjusted In.

Adjusted times are IN ADDITION TO any time captured by EVV and the EVV values are retained.

2.4. Approval

For the IL DHS program, prior to visits being exportable, a user must explicitly Approve the visit. For a visit to be Approvable, all exceptions must first be fixed. If the visit is ready for approval, the visit status will be ‘Approvable’. The user has to approve a visit in order for it to be included in the Payroll Export.

2.5. Authorization

A standard authorization in Sandata terminology is authorization for a particular service or set of services to be provided to a customer. The following screens are used by a Santrax user to create a new authorization and are being provided to illustrate a standard authorization in the Santrax EVV system. The authorization defines the basic information related to the services to be provided along with the total authorization hours/units, the date range, whether the authorization has any limits and the associated plan of care (the actual tasks to be performed during the visit).

10 Confidential and Proprietary DHS Business Rules-draft

Authorization fields shown on the dashboard include:

Dashboard Field Description

Service Identifies the service type that is approved for the Customer (examples: PA, RN, LPN, CNA)

Start Date Identifies the date the service will begin, for the current month, when the authorization is not expired.

End Date Identifies the date the service will stop, for the current month, when the authorization is not expired.

Status Active: The authorization has not expired.

Exceeded: The hours used have exceeded the total allowed for the authorized service. This is calculated based on all available hours for the period based on either actual calls or adjusted hours. Approval state is not taken into consideration.

Expired: The authorization’s end date has passed.

Reference The reference id or unique identifier for the parent authorization. This value is generally provided by the Payer.

Units The number of units for the authorizations based on the authorization type.

Auth_Type The type of units to be provided (Hours, Units, Visits). If the value is units, the conversion needs to be provided. Most programs use 1 Unit = 15 minutes but this could vary.

Limit_Type How the authorized units are divided within the timeframe.

None, Day, Week, Month, Year

Effective Active or Exceeded (but not expired) authorizations will display the effective start date and end date.

Overall Statistics Shows the total % of hours used during the current calendar year. The description shows the total number of hours available for the year and the actual number of hours used through the current date.

Current Statistics Shows the total % used for the current limit period (e.g.

Month) of the authorization. The description shows the total number of hours available for the month and the actual number of hours used through the current date.

11 Confidential and Proprietary DHS Business Rules-draft

2.6. Authorization Status

The authorization status is the utilization of the authorization for the period as shown on the Dashboard. Possible status values are:

Active or Expired - Expired authorizations are past the ending date for service. Based on the payer and program rules, authorizations continue past their expiration date until explicitly cancelled.

Exceeded – The hours used have exceeded the total allowed for the authorized service. This is calculated based on all hours used during the period based on both actual calls and adjusted hours. Hours are counted towards the total regardless of whether the visit has been approved.

At Risk – If the usage trend continues throughout the period (hours used / day), the member will exceed the total available for the period. Usage can be reviewed to determine if there is an issue.

2.7. Call In

The system time captured when the worker checks in regardless of the method used to generate the ‘call’. Value is captured both in local time based on the account setting and Eastern Standard time. Offset relative to GMT (Greenwich Mean Time) is also captured for handling DST (Daylight Savings Time) changes.

2.8. Call Out

The system time captured when the worker checks out regardless of the method used to generate the ‘call’. Value is captured both in local time based on the account setting and Eastern Standard time. Offset relative to GMT (Greenwich Mean Time) is also captured for handling DST (Daylight Savings Time) changes.

2.9. Call Processing / Call Matching

As calls are received by the Santrax EVV system through any of the call methods (TVV, MVV, FVV – IL DHS uses only TVV), the system utilizes a complex, rule-based methodology to determine the visit assignment. . In the customer directed world, Santrax must rely on the correct selection of ‘Call In’ and ‘Call Out’ by the employee / IP. Specific business rules utilized in this program are detailed in the rule section below.

Santrax EVV will continue trying to find the optimal match for all incoming calls throughout the current day. Calls may be reassigned throughout the day based on additional calls received. Once a user updates a visit, this automatic matching is disabled.

12 Confidential and Proprietary DHS Business Rules-draft

2.10. Client / Customer / Participant

Individual or member receiving services. The customer is identified by a customer id which must be unique within each agency. It is generally set based on a 3rd party system. For IL DHS, customers are identified by a unique case ID generated by the agency’s case management system (WebCM.)

It is suggested that the customer also be identified by a unique identifier such as the Social Security Number. This will allow for cross-agency queries as needed to identify duplication. Per industry standards, all communications with Social Security Numbers are encrypted.

2.11. Cross Reference / XRef

Within IL DHS, the Cross Reference (referred to as XREF) is a transaction that authorizes the IP to provide services. The Xref contains the provider ID, Customer ID, type of service and start date.

2.12. Dashboard

For the member portal, the dashboard is a place available for the user to get summarized information. The page is divided into 3 sections:

Dashboard Filters – Allows the user to select the customer to be reflected in the remainder of the dashboard. The customer will always be available as a drop down. The first customer based on last name alphabetically will be selected. The Payer drop down will ONLY be shown if the customer has more than 1 payer.

Alerts – intended to show the user how many visits require attention and/or need approval. Selecting these tiles will direct the user to the visit screen with the appropriate filters applied.

Authorization Usage – Intended to provide information to the customer relative to the utilization of their authorization. This is described in detail in the section labeled ‘Authorization’.

2.13. Electronic Visit Verif ication - EVV

EVV is a set of technologies to capture the beginning and ending of a visit. Technologies to capture visits include, but are not limited to, Telephonic Visit Verification, Fixed Visit Verification and Mobile Visit Verification. Not all methodologies are utilized in all programs.

2.14. Employee / IP (Individual Provider)

For IL DHS, the individual providing services to the customer are referred to as Individual Providers (IPs). IPs are hired by the customer to provide PA, CNA, LPN and/or RN services.

13 Confidential and Proprietary DHS Business Rules-draft

2.15. Exception

As calls are received and visits created, the system calculates exceptions. These exceptions are configurable based on the specific business rules determined for the account. The intent of visit maintenance and/or the customer portal is to allow the system user to review and correct these exceptions to create approvable visits.

Visit Maintenance Exceptions for Non-Agency

Visit Maintenance Exceptions are created when the EVV system identifies that a defined exception case is true for a specified visit. Some exceptions are for notification purposes only. Others will impact the completion status of the visit and its ability to be exported for payroll.

More than one exception can apply to a single visit and fixing one issue within Visit Maintenance may fix multiple exceptions by association.

When exceptions occur, Portal users will be able to log in and view hours worked, authorization information, and approve time for submittal to payroll. Each Portal user will only be able to view or modify visits for his or her assigned Customers and Individual Providers as provided in the crosswalk file from DHS. The security set-up will prevent each Portal user from seeing any information for customers and IPs not assigned to them.

IL DHS support staff will be able to review EVV exception situations in Santrax Visit Maintenance to identify problem areas. IL DHS can then use this information to intervene and correct issues going forward. For example, a particular IP who always seems to call in with the wrong ID entered could be targeted for further training.

The following exceptions will apply for non-agency visits.

Warning Only Exceptions

Employee Speaker Verification Exception: The speaker’s voice when compared to the underlying enrollment indicates that there is a high probability that the user is not the original enrollee. Warning Only.

Unmatched Client (Customer) ID/Phone Exception: Customer ID entered by IP during the call does not match phone number for

Customer. Warning Only.

Exceptions That Must Be Corrected

Missing Service Exception: The service value was not entered or was incorrectly entered on the EVV call. The Portal user will be able to explicitly set the correct values via an easy to use edit screen. Must be resolved for the visit to be considered complete.

14 Confidential and Proprietary DHS Business Rules-draft

Unknown Client (Customers): This exception happens when the IP calls from an unknown location. The Portal user would need to recognize a visit transaction for an IP by the date plus the in and/or out time alone. To make it more complex the IP may have called in from an unknown location and called out from a known location. Must be resolved for the visit to be considered complete.

It is suggested that the Portal user simply enter any missing values using the edit screen, or use the Add Visit screen, to account for the time.

Unknown Employee: An IP that has entered a Santrax ID that does not match with any known IP in the Santrax system; user made a Santrax call and did not enter a Santrax ID. Must be resolved for the visit to be considered complete.

Visits Without In-calls: A call in cannot be identified for the visit. Must be resolved for the visit to be considered complete.

Visits Without Out-calls: A call out cannot be identified for the visit. Must be resolved for the visit to be considered complete.

2.16. Fixed Visit Verif ication

When no phone is available, a Fixed Visit Verification device is used to capture the date and time of the visit. The times are called in to EVV after the visit is completed using an available phone. IL DHS does not use FVV.

2.17. Formal Eligibility (IL DHS)

When a customer is determined to be eligible for the Home Services program their case status is set to Formal Eligibility.

2.18. Interim Call / Extraneous Call

An interim call (also known as an extraneous call) is a call which is neither the in call nor the out call. Cases when this occurs include:

1. Call is received within a few minutes of the in or out. This is generally a 5 minute window and is designed to overcome user error on call in/out. The first call received becomes the IN and the last call received becomes the OUT. The other calls become interim or extraneous.

2. A call that is received between an in and an out call and is not identified as either an in or out call.

2.19. Interim Eligibility (IL DHS)

When a customer is temporarily determined eligible for the Home Services program their case status is set to Interim Eligibility.

2.20. Interrupt Services (IL DHS)

A variety of reasons may cause a customer’s services to be temporarily stopped. When this occurs, the case is put into Interrupt status.

Hospitalization, rehab in a nursing facility, extended absence from the home are a few examples.

15 Confidential and Proprietary DHS Business Rules-draft

2.21. Interactive Voice Response (IVR)

EVV conducted via standard call in / out from either a landline or a cell phone if allowed by the program. The system captures the originating phone number from which the call is made along with any keypad entries in response to prompts. Behavior of the IVR is configurable depending on business rules and features enabled.

2.22. Mobile Visit Verif ication (MVV)

Mobile Visit Verification device uses a tablet device to capture the date and time of the visit. IL DHS does not use MVV.

2.23. Overnight Visit

Any visit which begins on Day 1 and ends on Day 2. These visits are limited to a maximum of 24 hours although they COULD be scheduled back-to-back for live-in services. Overnight visits are billed and reported on the day the visit began.

2.24. Pay Hours

1. Initial Value – Computed value based on the In and Out call assignments. Intended to represent the length of the visit that will be billed and paid as applicable. Referred to as ‘Hours’ in the member portal.

2. Adjustments/Updates –When the user adjusts/updates the values for the visit through any available mechanism including the member portal, the underlying pay hours will be updated to reflect the correct values.

2.25. Pay Period

Pay Period is the range of dates covered by a particular pay period. The pay period is available as a drop down to simplify and speed selection of the date range. There are two pay periods per month, the 1st through the 15th and the 16th through the last day of the month.

2.26. Payer

Party responsible for payment of the services provided.

2.27. Provider Agency

The agency or intermediary responsible for ensuring that care is provided.

16 Confidential and Proprietary DHS Business Rules-draft

2.28. Rates

All IPs (PAs, CNAs, LPNs and RNs) are paid at a flat rate. Rate increases are date driven and outlined within the SEIU contract with the State. The rate was initially passed on the Xref transaction due to a previously defined variable rate for skilled work but that negotiated rate was discontinued January of 2014. Currently, a null is passed in the rate on the Xref transaction.

2.29. Reason Codes

Reason codes must be used when making Visit Maintenance updates and when manually verifying visits. There is also the ability to add free text to support additional clarification, however, a reason code(s) must first be selected before adding supporting free text. Users must associate an appropriate reason code with each incident of visit maintenance conducted in the EVV system. The below table outlines all specific reason codes as well as examples of use.

Code Reason Code Examples of Use

Wrong Phone Number - Customer

Verified

This reason code is typically used in conjunction with an Unknown Client (Customer) exception to indicate that the phone number utilized was incorrect relative to the one specified for the customer.

02 Invalid ID – Customer Verified

This reason code is typically used in conjunction with an Unknown Employee Exception. It would generally be used when the IP is manually matched to the visit.

03 Phone Unavailable - Customer Verified

This reason code is typically used in conjunction with the Visits Without Any Calls exception, Visits Without In-Call exception or Visits Without Out-Call Exception. It is generally used to indicate when a phone is unavailable either due to lack of equipment or due to a customer utilizing the phone when the provider arrives.

Individual Provider failed to call in/out – customer verified individual provider worked hours entered as daily pay hours

This reason code is typically used in conjunction with Visits Without In-Call exception or Visits Without Out-Call exception. It attests that the hours worked were verified by the customer.

17 Confidential and Proprietary DHS Business Rules-draft

Code Reason Code Examples of Use

10 Customer Does Not Have Home Phone

This reason code is typically used in conjunction with an Unknown Client (Customer) exception or various call exceptions to indicate that a home phone could not be utilized for the visit.

Customer Refused Individual Provider

Use of Phone

This reason code is typically used in conjunction with an Unknown Client (Customer) exception or Visits Without Any Calls exception to explain why the IP did not make calls during the visit.

15 Services Provided Outside of the Home

This reason code is typically used when an Individual Provider provides services to customer outside of home (e.g. doctor’s visit).

16 FVV Requested This reason code is typically used when an FVV device has been requested but not yet delivered.

Phone Lines Not Working - Individual

Provider Not Able to Call

This reason code is typically used when an Individual Provider indicates the phone line is not working, therefore Individual Provider is not able to call.

99 Other

This reason code is to be used when making a change or changes to a visit in Visit Maintenance and the reason for the change does not directly relate to any of the other existing memo codes in the reason code set. When using this reason code, it is recommended that supporting free text should be applied after this code is selected to further substantiate the reason for the correction.

2.30. Santrax ID

The Santrax ID will be used when calling into the EVV system at the beginning and at the end of the visit. The Santrax ID will be a four to nine digit code representing a unique identifier for the IP. The Social Security number is not recommended for this use. The Santrax ID is generated by IL DHS’ WebCM the very first time the IP is set to Active status. No IP will be issued more than one Santrax ID

18 Confidential and Proprietary DHS Business Rules-draft

2.31. Schedule

The schedule is generally created before the service is provided and specifies start and end times, the employee providing the services, the service code for the visit, etc. Schedules are generally received from 3rd party systems. IL DHS Customer Directed services do not include formal scheduling.

2.32. Service

All Individual Providers will be required to identify which service they are performing as part of the log out call. This entry will be done as part of the task entry functionality. This indicator will be used to determine which rate should be applied to the service. Rates will be sent to Sandata as part of the data exchange process. The following entries will be available:

Task ID Task Name Associated Service Code

11 CNA 04198

12 LPN 04197

13 PA (Personal Assistant) 04150

14 RN 04196

Read back of the tasks will be available in both English and Spanish.

2.33. Service Plan (IL DHS)

Home Services counselors are responsible for meeting with the customer and developing a service plan to meet the customer’s needs. This service plan identifies services that will be performed by PAs, CNAs, RNs, LPNs, Homemaker agencies as well as Home Delivered meals, Emergency Home Response, Adult Day Care and/or Adult Day Care Transportation services. Based on need, a plan cannot exceed a service cost maximum.

2.34. Unknown Employee

A visit where the IP providing services could not be determined. This is generally based on an incorrect or missing entry when the IP is prompted for their Santrax ID as part of the In or Out Call.

2.35. Unknown Client / Phone Number

Calls initiated from outside the home will show as an unknown phone number exception. These calls will not be associated with a particular customer unless the phone number used has been associated with the customer as part of the customer information provided.

These visits can be associated with the appropriate customer using the tools provided.

19 Confidential and Proprietary DHS Business Rules-draft

2.36. TVV – Telephonic Visit Verif ication

The most commonly used form of electronic visit verification will be from telephones. The following telephone types are approved: Landline telephone; if a landline installment is not possible, the customer’s cell phone will be used.

2.37. User

A system user is anyone who logs into one of Sandata’s systems. This would include agency supervisory and managerial staff, payer staff as applicable as well as authorized members. Users can only see the data of members to whom they are authorized.

2.38. Visit

A visit consists of at least a schedule or a call. In consumer directed care, given the absence of schedules, a visit will not exist in the system until calls are made by the worker or are manually added.

2.39. Visit Status

o Incomplete – There is an exception applied to the visit which is preventing approval. All issues must be resolved before the visit can be available for approval.

o Ignored – Visit that the system user has chosen to ‘Ignore’. These can be filtered so they no longer appear as requiring action. These visits will not be approvable and will not be exported.

o Approved – Visit has been approved and is eligible for the next payroll sweep. It can still be unapproved and adjusted / updated if needed.

o Approvable – All issues have been resolved and visit is in a state where it can be approved.

o Processed – Visit was approved and has been exported for payment. The visit is no longer available for adjustment / update.

o Expired – Visits that were previously in “Approvable” status but were not approved within 365 days (always going back to the first of the month) following the visit date. These visits cannot be edited or approved.

20 Confidential and Proprietary DHS Business Rules-draft

INTERFACES

4.1 Process Flows

The following diagram illustrates the basic process flows for IL DHS.

CONSUMER DIRECTED DATA FLOW

IL DHS WebCM IL DHS

EVV Visits Extract (Payroll Export)

Customers Service Plans/Authorizations IPs IP/Customer Cross

References (Xref)

Sandata

Salient Data Warehouse

EVV Visits Extract (Payroll Export)

Customers Service Plans/Authorizations IPs IP/Customer Cross

References (Xref)

21 Confidential and Proprietary DHS Business Rules-draft

STATE OF IL – DATA INTERFACES – NON AGENCY MODEL

E N

T

IT

IE

S

A N

D D

A T

A

IN

T E

R F

A C

E S

DWH

IL DHS

EVV

3. Individual Providers

7. Client – IP X-Ref

10. Approved IP Visits

20. Approved Visits

2. Customers

5. Service Plans

1. Customers

4. Individual Providers

6. Service Plans

18.

7.5 Client – IP Xref

22 Confidential and Proprietary DHS Business Rules-draft

OutputInput

Customer / Client File

(1 and 2)

Service Plan / Authorization File

(5 and 6)

Employee / IP File

(3 and 4)

Xref File (7)

Client Hold in Queue Until

Authorization is Received

Create 1 Client Record Per Auth /

Account

Authorization Hold in Queue Until Client is Received

Employee Hold in Queue Self Directed

Account Only No Wait

Reformat Hold in Queue Until Client is received.

Self Directed Account Only

Add Xref and Billing Information

Employee/IP Hold in Queue Daily Extract

Authorization Hold in Queue Daily Extract

Client Hold in Queue Daily Extract

Place in inbox For Load via Existing Real Time Transfer

Inbox Process (minor updates needed for new fields)

Santrax Load ONLY the

Client ID for the Agency for Xref with Schedule and Xport

Extract Completed Visits Using Current

Process (minor updates needed for new fields)

Extract Basic Account Data

Extract Payroll Data

Employee/IP

Authorization

Client Record

Schedule Hold in Queue

Until Client and Auth Received from IL

DHS to EVV Daily to DW

Release from Queue when Clients and

Auths Received from

IL DHS

Agency Customer Hold in Queue Until

Client and Auth Received from IL

DHS to EVV Daily to DW

Agency Worker Hold in Queue

No Wait to EVV Daily to DW

Schedule

Real Time

Agency Customer, Worker, Schedule Files to Directory

(15)

Create Daily File in Directory (all records received) (2,4,6)

Daily Account CSV File to Directory

(9)

Completed / Approved Visits to Directory (18/20)

Scheduled Payroll Export

Agency Schedule (14)

Agency Customer (14)

Agency Workers (14)

Completed Visits

23 Confidential and Proprietary DHS Business Rules-draft

RULES

4.1 Visit Approval

Visit Created Incomplete Approvable Approved Processed

Unapprove

Ignore Expired

Manually created

24 Confidential and Proprietary DHS Business Rules-draft

Visit Creation

For a visit to exist in the portal, one or more of the following elements must exist:

o An EVV Call In o An EVV Call Out o A manually created visit via the Add/Edit screen

Date must be known o Date is a basic element of the visit and is derived either based on the date of the call considered the ‘In Call’ or set when a user adds a visit via the Add/Edit screen.

Sandata must be in receipt of Customer; Individual Provider (IP); Service Plan and XREF files supporting all delivered services.

Visits can be ignored in either the Incomplete or Approvable status. Ignored visits are not available for approval or export.

Visits in Ignored status can be unignored. An unignored visit will revert to the status it was in when it was ignored.

Correcting an Incomplete Visit Visits will appear as ‘Incomplete’ until all issues with the visit have been resolved. For a visit to be in an approvable state:

Client / Customer o Customer must be known

The customer will be identified based on the phone number from which a Telephony-Based EVV call originated if it is identified with the client.

The customer can be identified using the ‘Unknown Calls’ filter by using the ‘Assign To’ feature.

o Customer must have an active Service Plan and XREF at the time of the service

Service being provided to the client must be valid based on the eligibility dates in the Service Plan and XREF for the date of service.

Customer cannot be in interrupt status.

Individual Provider o IP must be known

IPs identify themselves by entering their ‘Santrax ID’ during the call in and out process. Santrax IDs are unique and assigned to each IP by IL DHS.

If the IP enters an incorrect Santrax ID or no Santrax ID at all, this can be fixed on the Portal Add/Edit screen.

o IP must be active at the time of the service.

Active is defined as:

IP start date must be greater than or equal to the date of service.

Non-active is defined:

Suspended;

Inactive; or

25 Confidential and Proprietary DHS Business Rules-draft

Terminated.

o IP must be valid for the customer and service.

A Xref must exist authorizing the IP to work for that customer. The Xref also authorizes the service type and start date.

Service o Service must be a valid service for the program.

IPs are instructed to enter the service as part of the Santrax call. Services for the IL DHS programs are entered during the ‘task’ portion of the call. The value only needs to be entered on the out call. These values are understood to be services, versus tasks, and are stored appropriately as part of the visit. Values are:

11 – CNA;

12 – LPN;

13 – PA;

14 – RN.

If the IP does not enter a service on the call (hang up without entry or select an incorrect code without correcting), the service will default to blank.

If the service is blank, a valid value must be selected via the Add/Edit screen.

o Service must be valid for the customer.

The service being performed must be valid for the customer based on the XREFs received using the Eligibility Start

Date as the first date of service.

The ‘Close/Deletion’ receipt date for the Service Plan will be the last date of approvable service.

If a new / updated service plan is received for the customer, the prior plan with be effective until the eligibility start date of the new plan minus 1 day. Backdating cases and other outliers are discussed in the Xref processing rules section of this document.

Visit Date/Time An In and Out date and time must exist.

o In and Out times can be registered based on the use of any form of Electronic Visit Verification (EVV). IL DHS uses telephony-based EVV.

o If an In and/or an Out does not exist for a visit, they can be added via the Add/Edit Screen.

o Maximum length of a visit to be available for approval in the Visits screen is 24 hours.

o For a visit that crosses midnight, the ‘Overnight’ box will need to be checked.

o Once a visit has been created either manually or by telephony, the date cannot be edited.

26 Confidential and Proprietary DHS Business Rules-draft

Visit Approval When approving a visit, the following additional edits are performed:

The system is checked for any IP conflicts. If the IP is servicing another visit for any time period overlapping the one being approved, the visit will not be approvable. The user will get an error message.

Visits greater than 365 days, always going back to the first of the month, cannot be approved.

Visit Unapproval An approved visit can be unapproved at any point prior to the export to payroll. Once the visit is exported, it can no longer be changed in any way and/or unapproved.

Visit Export

The Visit Export (Approved Visits File) includes all approved visits and is received by IL DHS to be used for payroll purposes.

Visits will only be included in the payroll export if they were made on or prior to the last day of the most recently completed pay period (1st-

15th of the month or 16th-31st of the month.)

When visits that begin on the last day of the pay period and end on the first day of the next pay period, the full visit will be exported in the pay period of the begin day.

27 Confidential and Proprietary DHS Business Rules-draft

6.2. EVV / Web CM Processing Rules

IL DHS creates four general types of transactions (customer, provider, plan and cross reference) via their case management system and transmits them in near real time to Sandata via their web service. Transactions are only generated when staff make changes (scenarios below) in the case management system.

Illinois DHS Use Cases & Transactions

Item Number

Use Case

Transactions Sent

Implied Transactions

1 Create a Service Plan

Plan contains EVV Services Create Customer, Create Plan, Create Xref

Plan does NOT contain EVV Services Delete Customer Delete Plan, Delete Xref

2 Clear Completion Date

Previous Plan is NOT EVV and current plan is EVV

Delete Customer Delete Plan, Delete Xref

Previous plan is EVV and current is not

EVV

Create Customer, Create Plan, Create Xref (using prior plan)

Previous plan is EVV and current plan is

EVV

Create Plan, Create Xref

3 Maintain Provider

Add Provider Create Provider, Create Xref

End Date Provider Service Delete Xref

Suspend Provider Create Provider, Delete Xref

Inactivate Provider Delete Provider

Terminate Provider Delete Provider

4 Change Customer Information Create Customer

5 Close Case Delete Customer Delete Plan, Delete Xref

6 Interrupt Status Create Customer (status change), Delete Plan Delete Xref

7 Restore Status (EVV Case) Create Customer, Create Plan, Create Xref

8 Reverse Status to Status Plan or Interim Create Customer, Create Plan, Create Xref

28 Confidential and Proprietary DHS Business Rules-draft

Item Number

Use Case

Transactions Sent

Implied Transactions and EVV Case

9 MCO Batch Creates Plan

Current Plan not EVV and MCO plan has EVV Services

Create Customer, Create Plan, Create Xref

Current plan is EVV and MCO plan is EVV Create Plan, Create Xref

If MC plan has no EVV Services Delete Customer Delete Plan, Delete Xref

10 Temporary Addendum Expires Create Plan, (DW Ignore Flag set) – sending the previous plan with a different start date, Create Xref

11 Accept Transfer Create Customer

12 Caseload Maintenance Create Customer

13 Admin Transfer Create Customer

14 Add Case Indicator Create Customer

Sandata Transaction Handling

Transaction Pre-Conditions Cases EVV Updates Post-Conditions

CREATE CUSTOMER

Date Fields Received: DHS has a Status Date – won’t get record until customer is in plan status – which will never be in the future. deathDate is received by Sandata but not used.

Create

Customer

DeathDate is not null Update Customer with additional information

(primarily a warehouse attribute – it not stored in

EVV – ignore). Should not to anything with this data – we don’t store death date. No Action – falls under the no changes to EVV data.

Customer does not exist customer does not exist; Add Customer record to EVV:

CLIENTS.BEG_DATE = Today

CLIENTS.END_DATE = open;

Send to DW

29 Confidential and Proprietary DHS Business Rules-draft

Customer

Customer exists no changes to customer EVV data; No Action; Send to DW

Create

Customer exists changes to customer EVV data;

Current Customer Record:

CLIENTS.END_DATE = current day – minus one

11:59 p.m.

Create New Customer Record:

CLIENTS.BEG_DATE = current date

CLIENTS.END_DATE = open;

Send to DW

CREATE IP

Date Fields Received: termDate Term date is today’s date

Create IP IP does not exist IP does not exist;

termDate is null;

Add IPs record to EVV:

WORKERS.BEG_DATE = today

WORKERS.END_DATE = open;

Send to DW

Create IP IP does not exist termDate is not null; If term date is in a future then IP record is added as above, otherwise rejected

Create IP IP exists term date is null;

no changes to IP EVV data;

No Action; Send to DW

Create IP IP exists term date is null;

changes to IP EVV data;

Current IP Record:

WORKERS.END_DATE = current day minus one

11:59pm

Create New Worker Record:

WORKERS.BEG_DATE = current date

WORKERS.END_DATE = open;

Send to DW

Create IP IP exists term date is today; No action taken. Send to DW

CREATE PLAN

Date Fields Received: eligibilityStartDate, eligibilityEndDate (end date must be > start date)

Create Plan Customer & xref must exist first or record will be held customer does not have a plan;

eligibilityEndDate is null, in the past or in the future;

Add Authorization record to EVV:

AUTHORIZATIONS.BEG_DATE = eligibilityStartDate or current date if null

AUTHORIZATIONS.END_DATE = open ended;

30 Confidential and Proprietary DHS Business Rules-draft

Create Plan Customer & xref must exist first or record will be held customer has a plan;eligibilityStartDate is current day or in the future;

Current Authorization

Record:AUTHORIZATIONS.END_DATE = New Plan eligibilityStartDate - 1 day;

Create new

Authorization:AUTHORIZATIONS.BEG_DATE = eligibilityStartDate

AUTHORIZATIONS.END_DATE = open;

Send to DW

Create Plan Customer & xref must exist first or record will be held customer has a plan;

eligibilityStartDate is in the past;

eligibilityStartDate is after the current plan's eligibilityStartDate;

Current Authorization Record:

AUTHORIZATIONS.END_DATE = New Plan eligibilityStartDate - 1 day;

Create new Authorization:

AUTHORIZATIONS.BEG_DATE = eligibilityStartDate

AUTHORIZATIONS.END_DATE = open;

The current service record is closed with the eligibility start date -1. If other services exist between old and new eligibility days, they would be recalculated to accommodate the new dates received. XREF remains the same we had before if a new xref is not received

All visits for 365 days back starting on 1st day of month will be recalculated based on the changes received.

Leave approved or processed as-is.

Send to DW

Create Plan Customer and xref must exist first or record will be held customer has a plan;

eligibilityStartDate is in the past;

eligibilityStartDate is before or the same as the current plan's eligibilityStartDate;

Remove Current Authorization Record;

Assuming one exists before the one removed, update Prior Authorization Record:

AUTHORIZATIONS.END_DATE = eligibilityStartDate

- 1 day;

Create new Authorization:

AUTHORIZATIONS.BEG_DATE = eligibilityStartDate

AUTHORIZATIONS.END_DATE = open;

Service record is not removed but closed with the eligibility start date -

1. If other services exist between old and new eligibility days, they would be recalculated to accommodate the new

31 Confidential and Proprietary DHS Business Rules-draft dates received. XREF remains the same we had before if the new xref is not received

All visits for 365 days back starting on 1st day of month will be recalculated based on the changes received.

Leave approved or processed as-is.;

Send to DW

CREATE XREF

Date Fields Received: startDate – This value reflects the FIRST time the employee worked for the client under the service plan and will not be updated except in certain cases. Would correspond to the first plan which we might not have it the plan predated evv.

CREATE XREF Plan, Customer and IP must exist first or record will be held

Invalid Service – service is not on the plan; Reject Record;

CREATE XREF Plan, Customer and IP must exist first or record will be held

XREF for customer/ip/plan does not exist; Create XREF Record:

XREF_SERVICE.beg_date = startDate;

XREF_SERVICE.end_date = open date if StartDate is in the past, recalculate visits for customer, IP from startDate to current assuming they haven’t been approved or processed;

Send to DW

Create XREF Plan, Customer and IP must exist first or record will be held

XREF for customer/ip/plan exists;

startDate is in the future;

Current Xref record is closed with the new date -1

New record will be loaded using the start date of the newly received start date

32 Confidential and Proprietary DHS Business Rules-draft

Create XREF Plan, Customer and IP must exist first or record will be held

XREF for customer/ip/plan exists;

startDate after current XREF_SERVICES.beg_date; and start date in the past but after the last Xref begin date - is rare but possible;

Current Xref record is closed with the new date – 1

New record will be loaded. using the start date of the newly received start date

Recalculate visits for the customer from XREF

StartDate to current except for approved or processed; Time frame for visit recalculation is

365 days in the past, always going back to the first of the month.

Send to DW

Create XREF Plan, Customer and IP must exist first or record will be held

XREF for customer/ip/plan exists;

startDate predates current XREF_SERVICES.beg_date;

Start date in the past before the prior start date – rare but possible;

Current Xref record is closed with the new date – 1

New record will be loaded.

Recalculate visits for the customer from XREF

StartDate to current except for approved or processed; Time frame for visit recalculation is

365 days in the past, always going back to the first of the month.

DELETE CUSTOMER

Date Fields Received: statusStartDate?

Delete

Customer

Update or

Remove Plan and

XREFs for the

Customer being deleted using startDate, and lesser of endDate and deathDate as input customer does not exist;

INVALID CASE - Reject Record;

33 Confidential and Proprietary DHS Business Rules-draft

Delete

Customer

Update or

Remove Plan and

XREFs for the

Customer being deleted using startDate, deathDate as input

Customer exists;

If the deletion indicator is received then the client/customer record is closed with the transaction date – 1.

The Xref and Service Plan are closed on the transaction date.

The death date is received but is ignored.

DELETE IP –

Delete IP record is never sent

Date Fields Received: termDate - For the drop down, if the employee was active at any point within the period selected, they should be displayed.

Delete IP Update or

Remove XREFs for the IP being deleted using termDate as input based on DELETE

XREF rules termDate is null; INVALID CASE - Reject Record;

Delete IP Update or

Remove XREFs for the IP being deleted using termDate as input based on DELETE

XREF rules

IP does not exist; INVALID CASE - Reject Record;

34 Confidential and Proprietary DHS Business Rules-draft

Delete IP Update or

Remove XREFs for the IP being deleted using termDate as input based on DELETE

XREF rules

IP exists;

termDate is current date – will always be the case;

Update IP Record:

WORKERS.END_DATE = current day 11:59pm;

1. Suspended IP - IP remains active and xref closed as of the end of current date.

2. Delete IP - IP closed as of end of yesterday.

Send to DW

DELETE PLAN

Date Fields Received: eligibilityStartDate, eligibilityEndDate

Delete Plan Explicit "Delete" sent;

Update the current authorization:

AUTHORIZATIONS.END_DATE = today at 11:59pm

Delete XREFs for the plan being deleted based on

DELETE XREF rules

DELETE XREF

Date Fields Received: startDate

Delete XREF None Explicit "Delete" sent; XREF_SERVICE.ENDDate = today @11:59 pm; Send to DW

35 Confidential and Proprietary DHS Business Rules-draft

Rounding Rules

The user has the ability to enter an adjusted in and/or out time for a past visit. The following rules apply regarding this ability and the effect of the rounding rules:

1. No rounding will be utilized.

2. Payment will be based on approved EVV hours.

Rules – Payroll Export

A.1 Frequency

Visits will be exported to IL DHS two times a month based on a schedule to be determined by the State of Illinois DHS and provided to Sandata in a timely fashion. Any changes to a given date on the payroll must be communicated to Sandata to allow time for the change to be scheduled.

B.1 Business Rules

a. Data sent to State of Illinois will be at the individual visit level.

b. Only visits for Individual Providers will be provided to State of Illinois (EVV production account 2070 only).

c. Only approved visits will be exported

d. The transaction in the Approved Visits File includes:

i. Approval

ii. Known Employee

iii. Employee must have a Social Security Number

iv. Known Client

v. Valid Service for the program and the client based on the Service Plan

vi. Approved Hours

36 Confidential and Proprietary DHS Business Rules-draft

e. If the visit exceeds the authorized hours for the service, the visit will still be exported for payment.

f. For the scheduled payroll export, the export will include all approved visits through either the 15th of the current month or the last day of the prior month depending on when the export is run. If it is run between the 16th and end of the month, it would pick up approved visits only through the 15th of the current month. If it is run from the 1st to the 15th, it would pick up approved visits only through the last day of the prior month.

The following parameters are set for the payroll export.

i. The Approval Date look back is set to 35 days. The interface will review all visits that have been modified in the 35 days prior to the date the export is run.

ii. The Visit Date look back is set to 365 days, always going back to the first of the month. This date is one year prior to the first day of the month of the pay period being exported.

Run Date Last Day Selected

1-15th of the month Last day of prior month

16th to end of month 15th of current month

g. Once a visit has been exported, no adjustments can be made

h. Three e-mails will be automatically generated from Sandata’s Splunk site to notify recipients of the progress of the export.

i. An e-mail will be sent notifying recipients that the export started.

ii. An e-mail will be sent notifying recipients that the export successfully completed.

iii. An e-mail will be sent notifying recipients of the total number of transactions and the time the export completed.

iv. These e-mails are triggered by processes that run every fifteen minutes continuously. Since the export starts at

7:00 p.m. CT, it is captured by the process that runs at 7:15 p.m. CT.

Rules – Sandata EVV to Data Warehouse – Approved Visits

C.1 Frequency

File will be sent to the data warehouse on a daily basis and will contain only approved visits.

37 Confidential and Proprietary DHS Business Rules-draft

The file will be named as follows and the output will be sent as a single file combining the output from interfaces #18 and #20 (see table on page 21):

CompletedVisit_mmddyyyy_hhmmss.xml

D.1 Business Rules

a. Only Approved visits will be sent. For the scheduled job, the job will pick up all visits approved that day which may include visits made in the past. The job will be scheduled to run nightly (*).

*Currently set to run at 1:45 AM.

See the EVV WebCM Scenarios section of this document for specific cases.

38 Confidential and Proprietary DHS Business Rules-draft

2.0 UAT ENVIRONMENT

Sandata has created an environment to be used for User Acceptance Testing of changes made to the Customer Portal. The unique number for the IL DHS UAT account is 2198. The UAT environment receives data from IL DHS’ QA WebCM account. The interfaces and exports in the UAT environment are identical to the interfaces and exports in production with the exception that the Approved Visits File/Payroll Export is only run on request.

39 Confidential and Proprietary DHS Business Rules-draft

3.0 APPENDIX 1 – INTERFACE FIELD MAPPING

Mapping of DHS Service Plan to Sandata Authorization.

DHS Service Plan Sandata Authorizations caseId auth_ref_number caseNumber loc sequenceNumber not used warehouse only customerId not used warehouse only customerSsn client_id_custom respitePlanIndicator respite planTypeCode not used warehouse only impairmentDonScore not used warehouse only needDonScore not used warehouse only miniMentalDonScore not used warehouse only primaryAssignedCounselor not used warehouse only caseLoad not used warehouse only authorizingCounselor not used warehouse only customerSignatureDate not used warehouse only eligibilityStartDate beg_date eligibilityEndDate not used warehouse only reassessmentDate not used warehouse only serviceCostMaximumAmount (Dollars) auth_limit_max services (Auths) segment - One to many for the service plan serviceTypeCode service_code limitType auth_limit_type_id hoursPerMonth auth_limit visitsPerMonth auth_limit

40 Confidential and Proprietary DHS Business Rules-draft

DHS Service Plan Sandata Authorizations recordStatus not used warehouse only

Mapping of DHS IP to Sandata Worker.

DHS IP Sandata Worker Notes workerkey Sandata assigned unique key for the workers record.

beg_date Day following date worker was received / became active in the Sandata system.