Checklist Use Cases
This document details the various use cases and variants to them that the Checklist feature should support.
Use Case 1 - Service User Assignment
A Checklist can be assigned to a service user. The assignment happens through the Create Assignment screen: -
Assignments at a Service User level can be completed in two ways: -
By the Assignment Type of Client
By the Assignment Type of Room
When a Checklist is Assigned by either of these two methods it is linked to a service user and so should be accessible to complete as part of providing support to that service user.
Core Checklist Settings
Various settings on the Checklist and Assignment screens will affect the behaviour of the Checklist on difference platforms.
Stage 1 - Describe Your Checklist
The settings for this are: -
Setting | Behaviours |
---|---|
Start Date | The Start Date defines the first date a Checklist Instance can be created. If this date is in the future an instance will not be created until that date. |
Display Checklist on Home Status… | The Checklist will appear on the Home Status, Staff Task List or Service User Task List as long as it is an Active Instance, the Target Shift is valid or the Start Time, End Time or Late Time are set. For Staff Task Lists the staff member must be able to access the Checklist. |
Target shift | Uses the Site Shift Settings. Only used if the Start Time and End Time are blank. If Start Time and End Time are used the target shift is ignored. An active instance has a status of 4 - Outside of Target Time returned on the Checklist Home Page for instances that are outside of their target times. |
Start Time, End Time, Late Time | These are optional. If they are used the Target Shift is ignored. They define when an active instance can be accessed. If the Checklist is viewed between the Start and End Time a status of 2 is returned - Ongoing (Amber). If the Checklist is viewed after the End Time, but before the Late Time the status is 3 - Late (Red Cross) |
NFC Tag Only Checklist | If this is set then the Checklist can only be assigned as an NFC Only Checklist. This setting will stop the user from being able to select Manual or QR Code options at the Assignment stage. |
When does a Checklist Instance Expire | This is a setting that defines when an Active Instance is moved to an Historic Instance. The default value is: - This means that the Instance remains active until another instance for that Checklist is created. If the Checklist is a repeating Checklist, the instance will remain active indefinitely. This setting value means that the Checklist Instance will become historic once the time period after the Shift End or Late Time end has been reached for the date it became active. This will happen within 5 minutes of this time as the process is run within the 5 minute agent job. The activation date is the date that the Instance was created. For a first instance that date will equal the Start Date on the Checklist. |
Stage 2 - Who can complete this Checklist
The settings here are as follows: -
Setting | Behaviours |
---|---|
Who can complete this Checklist | This setting defines who can complete the Checklist. It defines staff members either specifically, by role or by category. If this setting is not set then anyone in the organisation is able to access that Checklist. This setting is only relevant for Assignments for Clients, Rooms, CSG’s. It is not relevant to Assignments associated with Staff. |
Stage 3 - Does this Checklist Repeat?
The settings in this section are as follows: -
Setting | Behaviours |
---|---|
Does the Checklist repeat | This setting defines if the Checklist instances are repeating. The repeat frequency can vary. For example, if we had a Checklist that had a Start Time of 15:00 and Late Time of 14:59 which repeated each day, then a new instance would be created at the same time the current instance expires. |
Stage 4 - Who can add tasks to this Checklist
The settings in this area are as follows: -
Setting | Behaviours |
---|---|
Who can add tasks to this Checklist | This setting defines who can add Tasks to this Checklist. For example, if we looked at a Maintenance Checklist. You may want it that other staff can add tasks to the Checklist, but the only person who can complete the Checklist are staff who have the role of Maintenance. Adding of Tasks should be supported on all Platforms. |
Stage 5 - Output when Checklist is Completed
These are the settings for this area: -
Setting | Behaviours |
---|---|
Output when a Checklist is Completed | This setting contains the template that is used when a Tasks is saved or a Checklist is completed. The output is used if the Assignment requires a Care Note to be created. The format of the template can use the following placeholders: - #ChecklistName# #TasksCompleted# #TasksCompletedCR# #Tn# This placeholder is replaced with the word COMPLETED. #Tn-Description# The above placeholders are for each Task on a Checklist. The n equals the unique Task ID primary key. This allows for templates to be created with specific task entries in specific locations. Other special template commands include: - {IF “#Tn#” CONTAINS “Completed” THEN “Your content” “} In this example we test to see if the specific Task has been completed. {IF “#Tn-ExtraText#” CONTAINS “Test” THEN “Your content” “} In this example we test to see if the extra data contains a specific value. {IF “#Tn-ExtraText#” DOES NOT CONTAIN “Test” THEN “Your content” “} |
Only create a note when the Checklist is Completed | This setting means that a note is only created if the Checklist has been completed. If this setting is not set then each time a set of tasks are saved a note is created and stored against the service user. If this setting is set then when the final entry on the checklist is completed and the completed flag is updated, the note is then created. If this setting is checked and the checklist is not completed (e.g. it expires) then no note is created. |