Utah System For Tracking Eligibility, Planning and Services
USTEPS
User Guidelines
Best Practices
Division of Services For People With Disabilities
(DSPD)
Table of Contents
Introduction:
1.0 Using USTEPS:
1.1 Data Confidentiality:
1.1.1 Accessing USTEPS In The Office:
1.1.1.1 Leaving The Computer On Unattended:
1.1.1.2 Passwords:
1.1.1.2.1 State Employee User ID and Password:
1.1.1.2.2 State Employee Password Maintenance:
1.1.1.2.3 Network Password Security:
1.1.2 Accessing USTEPS In Locations Outside Of The Office:
1.1.2.1 DSPD Employee USTEPS Access Outside Of The Office:
1.1.2.2 Non-State Employee USTEPS Access:
1.1.2.3 Accessing USTEPS With A Personal Computer:
1.1.3 Preserving Data Confidentiality and Integrity:
1.1.3.1 Viewing Data About Consumers Who Are Not On The Worker’s Caseload:
1.1.3.2 Best Practice – Maintaining Data Integrity And Preserving The Consumer’s Confidentiality:
1.1.3.2.1 Making Data Changes In Another Worker’s Case:
1.1.3.2.2 Denying The Request To Make Changes:
1.2 USTEPS Automated System Safeguards:
1.2.1 Login Security:
1.2.2 Automated Time-Out:
1.2.2.1 Recovering From A Time-Out:
1.2.2.2 Best Practice – Save Frequently:
1.2.3 USTEPS Transaction Messages:
1.2.4. User Roles:
1.3 USTEPS’s Fundamental Features
1.3.1 The Selected Consumer:
1.3.2 The Navigation Menu:
1.3.2.1 The Home Menu:
1.3.2.1.1 Messages.
1.3.2.1.2 Caseload.
1.3.2.1.3 The Home Screen For Supervisors.
1.3.2.2 Best Practice – Using Messages Appropriately On The Home Screen
1.3.2.3 The Log Menu
1.3.2.4 The Consumer Menu
1.3.2.5 The Contact Menu
1.3.2.6 The Sign Out Menu:
1.3.2.7 The Help Menu:
1.3.2.8 The Search Menu:
1.3.2.9 Supervisor Menu:
2.0 The Contact Process:
2.1 Minimum Requirement For Recording A Contact:
2.2 Best Practice For Recording A Contact:
2.3 Searching For A Person Who Is Going Onto The Form 1-1:
2.3.1 Search Before Processing Form 1-1:
2.3.2 Search Results:
2.3.2.1 The Search Reveals The Person Is Already In USTEPS:
2.3.2.2 Statuses That Do Not Allow For Starting A New Intake:
2.3.2.2.1 Reactivating The Person’s Intake:
2.3.2.3 Statuses that Do Allow For Starting A New Intake:
2.3.2.4 The Search Reveals The Person Is Not In USTEPS:
2.4 Reviewing And Utilizing Contact History:
2.5 Best Practice: Utilizing Contact History:
2.6 Recording Referrals Made To The Contact:
2.7 Start The Form 1-1 Process:
2.7.1 Filling Out The Form 1.1:
2.7.1.1 The Person’s Name:
2.7.1.2 Addressing The Form:
2.7.1.2.1 The Person is Homeless:
2.7.2 Printing and Mailing the Form 1-1:
2.7.3 Processing Form 1-1 For Walk-ins:
2.7.4 Resending the form:
2.7.4.1 Form 1-1 Returned Because of Invalid Address:
2.7.5 Completing The Form 1-1 Process:
2.7.5.1 Recording The Form Was Returned:
2.7.5.2 Verifying the Form’s Accuracy:
2.7.5.2.1 Processing an Illegal Copy of the Form:
2.7.5.2.2 Checking The Address:
2.7.5.2.3 Checking the Person’s Social Security Number:
2.7.5.3 Assigning The New Person To A Worker’s Caseload:
2.7.6 Best Practice: Start Intake When The Form 1-1 Is Returned:
2.7.7 Issues That Prevent The Form 1-1 Process From Being Completed:
2.7.7.1 Duplicated People:
2.7.7.2 Invalid SSN’s:
2.7.8 Best Practice: Preserving The Integrity Of The Person’s HLCI And SSN:
2.7.9 Best Practice: Preserving The Integrity Of The Form 1-1
2.7.10 Best Practice: Monitoring Form 1-1’s That Have Not Been Returned:
3.0 The 90-Day Intake Data Collection Period:
3.1 The data That, In General, Should Be Collected In order To Make An Eligibility Decision:
3.1.1 Demographic data for all Service Types:
3.1.1.1 Data Unique For ID And RC:
3.1.1.2 Data Unique For ABI:
3.1.1.3 Data Unique For PD:
3.1.2 Best Practice: Release of Information:
3.1.2.1 Specify Exactly What the Release Of Information Is For:
3.1.2.2 Blank Releases Should Not Be Signed Before Being Completed:
3.1.2.3 Worker Professionalism Should Govern How The Release Is Completed:
3.1.3 Processing the High Level Client Index (HLCI):
3.1.4 Best Practice: Maintaining the Person’s Physical Address and Mailing Address:
3.1.5 Completing the Social History:
3.1.6 Best Practice: Completing the Social History:
3.1.7.1 Completing The Social History:
3.1.7.2 Social Histories Should Be Complete And Thorough:
3.1.7.3 Updating Completed Social Histories:
3.1.7 Social History Data Mapped to the Needs Assessment Process:
3.1.8 Best Practice: Social History / Needs Assessment Data Mapping:
3.1.9 Best Practice: General Social History Items That Need To Be Entered and Maintained:
3.1.9.1 The person’s address:
3.1.9.2 The person’s telephone number:
3.1.9.3 The person has a guardian:
3.1.9.4 The person’s medical professionals:
3.1.9.5 The person’s medications:
3.1.9.6 The person’s important personal relationships:
3.1.9.7 The person’s needs, problems, etc.:
3.1.9.8 The person’s report of having a brain injury:
3.1.9.9 Adding Comments:
3.1.10 Assessments and Functional Limitations:
3.1.10.1 Answering Specific Functional Limitation Questions:
3.1.10.2 Eligibility Decision Based On Functional Limitations:
3.1.10.3 Functional Limitations For ABI:
3.1.10.4 Functional Limitations For ID & RC:
3.1.10.4.1 Under age 7:
3.1.10.4.2 Between ages 7 and 17:
3.1.10.4.3 Ages 18 and older:
3.1.10.5 Functional Limitations For PD:
3.1.11 Using Non-Traditional Assessment Sources To Justify A Functional Limitation
3.1.11.1 Recording Non-Traditional Assessments In USTEPS:
3.1.11.2 Documenting The Social History As An Assessment.
3.1.12 Recording Diagnoses:
3.1.12.1 Qualifying Diagnoses:
3.1.12.1.1 The Diagnosis Is Missing The ICD Code:
3.1.12.1.2 Diagnosis Credibility:
3.1.12.2 Non-Qualifying Diagnoses:
3.1.12.3 Only One Diagnosis Can Be “Qualifying”:
3.1.13 System Task for Completing the 90-Day Intake Data Collection Period:
3.1.14 Best Practice: Finishing The 90-Day Intake Data Collection Period:
3.1.14.1 Be Proactive About The 90-Day Clock:
3.1.14.2 Making The Eligibility Decision During the 90-Day Intake Data Collection Period:
3.1.14.3 Making Use Of The 90-Day Eligibility Decision Period:
3.1.14.4 Making Use Of The Eligibility Committee Process:
3.2 Inactivating The Person’s Intake:
3.2.1 USTEPS’s Awareness of the 90-Day clock:
3.2.1.1 Minimum Data For ID & RC:
3.2.1.2 Minimum Data For ABI:
3.2.1.3 Minimum Data For PD:
3.2.2 Personal Request To Terminate The Intake:
3.2.3 Preparing the “Inactivation Letter”:
3.2. Best Practice: Inactivating The Person:
3.3 Reactivating The Person’s Intake:
3.3.1 Reactivation Process:
3.4 Reviewing An Inactive Person’s Case File Without Reactivating Them:
3.5 Best Practice: Updating Data In An Inactivated Person’s Case File
4.0 The 90-Day Eligibility Decision Period:
4.1 Making The Eligibility Decision:
4.1.1 Making An “Eligible” Decision
4.1.1.1 Criteria For Approving Mental Retardation (ID) & Related Conditions (RC) Eligibility:
4.1.1.2 Criteria For Approving Acquired Brain Injury (ABI) Eligibility:
4.1.1.2.1 Rules For Determining Whether Or Not The Person Has A Qualifying Brain Injury Diagnosis:
4.1.1.2.1.1 The Brain Injury Diagnosis/ICD Code Must Match One That Is Found On The Approved List.
4.1.1.2.1.2 People Who Are Either In Services Or Applying For Services And Do Not Have An ICD Code With Their Diagnosis:
4.1.1.2.1.3 Verifying Brain Injury ICD Codes:
4.1.1.2.1.4 ICD Codes That Are Not Accepted As A Qualifying, “Stand Alone” ABI Diagnosis:
4.1.1.2.1.5 V Codes Cannot Be Used To Find The Person Eligible For Services:
4.1.1.2.2 Frequently Asked Questions About Brain Injury Diagnoses and ICD Codes:
4.1.1.3 Criteria For Approving Physical Disabilities (PD) Eligibility
4.1.2 Making An “Ineligible” Decision:
4.1.2.1 “Ineligible” Options For ID and RC:
4.1.2.1.1 Residency
4.1.2.1.2 Diagnosis:
4.1.2.1.3 Functional Limitations:
4.1.2.2 “Ineligible” Options For ABI:
4.1.2.2.1 Residency
4.1.2.2.2 Age:
4.1.2.2.3 CBIA Score:
4.1.2.2.4 Diagnosis:
4.1.2.2.5 Functional Limitations:
4.1.2.3 “Ineligible” Options For PD:
4.1.2.3.1 Residency:
4.1.2.3.2 Age:
4.1.2.3.3 Diagnosis:
4.1.2.3.4 Functional Limitations:
4.1.3 Logical Strategy For Making The Eligibility Decision:
4.1.3.1 Logical Strategy For Ruling On ID and RC Eligibility:
4.1.3.1.1 Examine Residency First:
4.1.3.1.2 Examine The Diagnosis Second:
4.1.3.1.3 Examine The Functional Limitations Third:
4.1.3.2 Logical Strategy For Ruling On ABI:
4.1.3.2.1 Examine Residency First:
4.1.3.2.2 Examine Age Second:
4.1.3.2.3 Examine Diagnosis Third:
4.1.3.2.4 Examine CBIA Assessment Fourth:
4.1.3.2.5 Examine Functional Limitations Fifth:
4.1.3.2.6 Resolving The Related Condition Question For People With Brain Injuries:
4.1.3.3 Logical Strategy For Ruling On PD:
4.1.3.3.1 Residency:
4.1.3.3.2 @Logic For Making the PD Decision@
4.1.4 Best Practice: Making The Eligibility Decision
4.1.4.1 Following The Path Of Least Resistance:
4.1.4.2 Initial Eligibility Decisions:
4.1.4.2.1 The 90-Day Eligibility Decision Period Has Expired:
4.1.4.3 Notice Of Agency Action (NOA):
4.1.4.3.1 NOA For The Initial “Eligible” Decision:
4.1.4.3.2 NOA For The Initial “Ineligible” Decision:
4.1.4.4 Making Multiple Eligibility Decisions during the 90-Day period:
4.1.4.4.1 Status Change For The Initial “Ineligible” decision:
4.1.4.4.2 Delaying the Eligibility Decision Until The 90-Day Eligibility Decision Period Has Expired:
6.0 The Eligibility Committee:
6.1 Sending A Case To The Committee:
6.1.1 Initiating The Process:
6.1.2 The Eligibility Referral Form:
6.1.3 The Supervisor Review:
6.1.4 The Eligibility Committee Representative Review:
6.1.5 The Eligibility Committee Recommendation:
6.1.6 Best Practices: Using The Eligibility Committee Process:
6.1.6.1 Sending A Case Back To The Worker:
6.1.6.2 Automated Log Notes Generated During The Committee Process:
6.1.6.3 Reviewing The Current Status/Progress Of The Eligibility Committee Process:
7.0 Consumer Logs:
7.1 Writing A Log Note:
7.1.1 The Activity Date:
7.1.2 The Contact Type:
7.1.2.1 Written Correspondence:
7.1.2.2 Face to Face:
7.1.2.2.1 Location:
7.1.2.2.2 Other:
7.1.2.3 Field Visit:
7.1.2.4 Monthly Summary
7.1.2.5 Office Visit
7.1.2.6 Recording
7.1.2.7 Telephone Call
7.2 Best Practice: Writing A Log Note:
7.2.1 Support Coordinator Activity:
7.2.2 Monthly Face-To-Face Visits:
7.2.3 Telephone Contacts:
7.2.4 Reviewing Monthly Summaries:
7.2.5 Reviewing Behavior Plans:
7.2.6 Referencing Health And Safety;
7.2.7 Documenting Problems And Interventions Along With Their Results:
7.3 Amending A Log Note:
7.4 Access To Log Notes:
7.5 System Generated Log Notes:
7.6 Using Log Notes As Documentation For Assessments:
8.0 Notice of Agency Action:
9.0 Waiting List:
9.1 Waiting List Services:
9.1.1 Updating the Waiting List Service Information:
9.2 Needs Assessment:
9.2.1 Updating/Rescoring the Needs Assessment:
9.3 Moving The Person From The Waiting List To “In-Services”:
10.0 Supervisor Functions and Features:
10.1 Transferring Cases From One Worker To Another:
10.1.1 Internal Team Transfers:
10.1.2 External Team/Office/Region Transfers:
10.1.3 Best Practice: Transfers:
10.2 Team Organization:
10.2.1 Notifying The USTEPS Team About Team Changes:
10.2.1.1 Employees who are newly hired:
10.2.1.1.1 New Worker USTEPS ID and Password:
10.2.1.2 Employees who have been resigned:
10.2.1.2.1 Temporary Case Load Assignment Changes:
10.2.1.3 Employees/Supervisors Who Are Transferring To Another team:
10.2.1.4 Best Practice: Employees Who Are Transferring To Another Team:
10.2.1.5 The creation/elimination of Teams:
10.3 Employee Training And Other System Support Issues:
10.4 Employee Certifications:
10.4.1 Notifying The USTEPS Team About Worker Certifications:
10.5 Bringing The Person Into Services:
10.5.1 Status Overrides:
10.5.2 Best Practice: Moving The Person Into Services:
11.0 Administering The Supports Intensity Scale (SIS):
12.0 Data Snapshots:
12.1 Utilizing The Snapshot Feature:
12.2 Best Practice: Utilizing The Snapshot Feature:
Introduction:
USTEPS is a web-based computer system that is designed to be accessible from any location in the world with an Internet connection. The system’s primary purpose is to help DSPD’s workers better serve people with disabilities by electronically accessing and utilizing all of the Division’s major business functions in their behalf. The business functions include, the Intake process, the Eligibility Decision making process, the Waiting List process, and the process for providing Support Coordination.
1.0 Using USTEPS:
Given USTEPS’s broad scope and availability, the worker should pay special attention to its common, fundamental processes and features. Doing so will help the worker preserve and protect the person’s dignity and confidentiality.
1.1 Data Confidentiality:
The State of Utah has established a number of policies and procedures that define how state employees should utilize technology. The following guidelines describe how the State’s policies affect USTEPS as well as the best practices the worker can use to safeguard its data.
1.1.1 Accessing USTEPS In The Office:
1.1.1.1 Leaving The Computer On Unattended:
If a computer is left on after the worker has gone home, it can be vulnerable to misuse. As a result, the worker should, “Log off and shut down when leaving for the day”(Security Awareness, Section 6 – Page 3,
1.1.1.2 Passwords:
The worker’s password is the key to entering USTEPS. Consequently, the worker should not disclose his or her user ID and password to anyone else (Security Awareness, Section 6 – page 5, If, however, such a discloser occurs, then the worker should immediately change their password once the reason for doing so has been resolved. A key issue to remember is that USTEPS records every transaction that happens in the system along with who did it. So, if a worker gives out their ID and password, then they make themselves vulnerable for being held directly responsible for actions taken, appropriate or otherwise, by the other person.
1.1.1.2.1 State Employee User ID and Password:
For State Employees, the worker’s USTEPS ID and password are the same as what they use to log into the state computer network (i.e. the Novell ID and password).
1.1.1.2.2 State Employee Password Maintenance:
State Employees are required to change their computer network password every 90 days. When the worker changes their password, it is immediately effective when they log into USTEPS.
1.1.1.2.3 Network Password Security:
The State’s network allows the worker to make three attempts to successfully log into their user account. If the worker fails to log in successfully three consecutive times, then their user account will be frozen such that it is not accessible/operable. The same security protocol applies to USTEPS. If the worker fails to log into USTEPS successfully three consecutive times, then their network account will be frozen – meaning the worker will not only be prevented from logging into USTEPS again, but they will also be prevented from logging into the State network. If the worker’s account is frozen, then they should open a trouble ticket with DTS (801-538-3440) to have the issue resolved.
1.1.2 Accessing USTEPS In Locations Outside Of The Office:
1.1.2.1 DSPD Employee USTEPS Access Outside Of The Office:
DSPD employees are free to access USTEPS in any location outside of their office. These alternative locations/resources could be a library, the provider’s location, a wireless Air Card, or the person’s home. Even so, the policies previously identified about shutting computers off, preserving the privacy of passwords, and protecting the data in the system should be followed. If the worker is using a computer provided by the “public” vendor to access USTEPS, then they should ensure that it has the protections (i.e. a firewall, anti-virus, etc.) required by the State (Security Awareness, Section 3 – Page 8,
1.1.2.2 Non-State Employee USTEPS Access:
Where appropriate, non-state employees will be allowed to access USTEPS (e.g. Private Support Coordinators). USTEPS is intentionally designed to limit the access non-state employees can have to consumer data. Even so, they should follow the same policies previously identified about shutting computers off, preserving the privacy of passwords, and protecting the data that state employees are asked to comply with.
1.1.2.3 Accessing USTEPS With A Personal Computer:
If the worker, whether a DSPD employee or not, is using their own personal computer to access USTEPS, then they should ensure that it has the protections (i.e. a firewall, anti-virus, etc.) required by the State before connecting to it (Security Awareness, Section 3 – Page 8,
1.1.3 Preserving Data Confidentiality and Integrity:
1.1.3.1 Viewing Data About Consumers Who Are Not On The Worker’s Caseload:
USTEPS is designed to be flexible and open. As a result, any DSPD employee has the ability to view data about any person regardless of where they are served (i.e. in the same office, a neighboring office, or a different region). However, despite the system’s open, unrestricted nature, workers should not abuse the privilege of viewing the data. The person’s right to privacy is still in force. As a result, DSPD employees are to keep and maintain the confidential nature of the consumer’s social history data, log notes, eligibility, etc., regardless of whether or not that person is on their caseload.
1.1.3.2 Best Practice – Maintaining Data Integrity And Preserving The Consumer’s Confidentiality:
If any part of the person’s file needs to be updated in USTEPS, then the worker who owns the file should be the one to implement the changes unless directed to do otherwise by the supervisor (e.g. a Senior Assistance Caseworker could make data entry changes for people who are not on their caseload as directed by the supervisor – this assumes that the workers involved are on the same team).
1.1.3.2.1 Making Data Changes In Another Worker’s Case:
If the worker desires to make data changes to a person’s case file who is served by a different team and/or region, then he or she should not add to or change the data until the following procedure is completed (Note: this procedure excludes writing logs in another worker’s case file – see 7.4 Access To Log Notes:):
- The worker asks his or her supervisor (A) about the possibility of changing the data contained in the other worker’s file.
- The supervisor (A) agrees that the change needs to be made.
- The supervisor (A) contacts the supervisor (B) of the worker whose case file that needs to be changed.
- The supervisor (B) reviews the situation and confers with the worker who owns the person’s case file.
- If, after discussing the situation, both the supervisor (B) and the worker who owns the file agree to allow the worker from the other supervisor’s (A) team to make the change, then supervisor (B) notifies supervisor (A) about the decision.
- Supervisor (A) informs their worker that they have permission to make the change.
1.1.3.2.2 Denying The Request To Make Changes:
If anyone identified in Section “1.1.3.2.1 Making Data Changes In Another Worker’s Case” denies the worker’s request to make the data entry changes in the other worker’s case file, then that worker cannot implement the changes.
1.2 USTEPS Automated System Safeguards:
USTEPS contains an array of security features that are intended to protect the integrity of the data it contains. These features, to some degree, reduce the chance that someone can inappropriately access the system as well as perform a transaction that is not appropriate. The following describes some of the features and how the worker should successfully interact with them.
1.2.1 Login Security:
USTEPS front line defense for protecting the data it contains is user access. The only people who can access USTEPS are those who have a valid user ID and password (see Sections “1.1 Data Confidentiality” , “10.2.1 Notifying The USTEPS Team About Team Changes” & “10.4 Employee Certifications”) and have been incorporated into the Division’s organizational structure (i.e. has been assigned to a team).