<h1>Whanau ora: Kotahi usage guide</h1>
# Contents <!-- TOC is suboptimal so build this manually :/ -->
[toc]
# Background
This note clarifies the Kotahi process for core **Whanau ora** contract (not [Tupaia](https://hackmd.io/_g2Rn2cvS8qISLjVSiz2oQ)).
The main system of record for Whanau ora is **Penelope**, and that will remain the place for full contact/assessment information until further notice.
The remit for using Kotahi is:
* Not to copy or replicate Penelope data, but
* To give K'aute an internal record of client/fanau activity and progress.
Therefore, the approach has been based on the principle:
> What is the *minimum* information K'aute needs to capture, to help us understand the impact we make and to reflect the work of our staff.
This guide steps through key steps of the defined pathway.
# Referral/intake
At the current time, K'aute's main referral/intake process is not changing.
Client referral and allocation will still happen in Aiga until further notice. Once a client is referred, the allocation process can occur in Kotahi as shown below.
**LEGEND**
<span style="background-color: #4e914e">Green</span> = Kotahi
<span style="background-color: #aeaeea">Blue</span> = Aiga
<span style="background-color: #eb4910 ">Orange</span> = Penelope
```mermaid
flowchart TB
subgraph F0[Family to be enrolled in Whanau ora]
direction TB
c1[Parent]:::none
c2[Child]:::none
c3[Matua]:::none
c1<-.->c2
c3<-.->c1
c3<-.->c2
end
subgraph AD0[<b>K'aute Admin]
direction TB
AD1[Client/fanau setup]-.->
AD2[Allocate to Team Lead]
end
subgraph TL0[<b>WO Team Lead/Admin]
direction TB
WA1[Set up as clients]:::kotahi-.->
WA2[NHI lookup]:::kotahi-.->
WA3[Define whanau relationships]:::kotahi-.->
WA4[Assign to Whanau ora service]:::kotahi-.->
WA5[Assign to WO Navigator]:::kotahi
end
subgraph WN0[<b>WO Navigator]
direction TB
WN1[Manage fanau as usual]:::penelope
WN2[Summaries/requisitions]:::kotahi
end
F0 -- Referral --> AD0
AD0 -- Email <br>notification --> WA1
WA5 --> WN0
classDef kotahi fill:#99cc99
classDef penelope fill:#eb4910,color:lightgrey
classDef none fill:#ffffff
```
# Key activities
## Setup/initiation
### Referral form
There is a Kotahi form for Whanau ora 'referrals'. As mentioned above, the usual Aiga process is not changing yet; referral information will need to be completed by WO Admin or Navigator after allocation.
The form can be completed electronically with the lead family member (who can also sign if a touchscreen/mobile device is available). Otherwise, a paper copy can be scanned and attached to this form as a record. There are no mandatory fields on this form.
Please remember that all Whanau relationships should already be defined, so that you can tick all members using the 'Share with Whanau' button:
This simply makes a copy of this form in the record of all family members:
### Consent and privacy waiver
These can also be added into Kotahi for new families (or entered retrospectively for existing families, if needed).
These are electronic copies of the existing 'Third party consent' and 'Privacy waiver' forms. Hard copies can be uploaded, or they can be completed digitally on a mobile device/touchscreen if appropriate.
## Assessment/Goal plan
The ongoing MAST Assessment and Goal plan review tasks have been merged in Kotahi. This lets us capture as much useful information as possible, whilst trying to cut down on manual/admin work for the team.
### MAST Assessment
Initial and ongoing (3-6 month) MAST reviews can be reflected in Kotahi using the 'Whanau ora assessment/goal plan' activity:
This form is designed to capture as much useful information as possible with minimum admin. The MAST assessment is recorded fully in Penelope, so we don't need to repeat it all here :smile:. However, the form lets you capture:
* Assessment score for each domain
* Assessment risk for each domain
* Up to 4 goals per domain
* Any other comments.
:::info
:+1: Any information you enter into this form will copy through when you do the next one!
:::
When it's time to do a MAST review, just start another one of these forms and simply update any risk or goal information.
:::warning
:warning: If you are doing a MAST assessment it's really important you change the 'MAST Assessment date' on the first page (see below). This will automatically pull through onto a new requisition form and save a few seconds of your time :wink:
:::
**If you are simply updating goals/goal plan, and not doing a MAST assessment, then leave this field empty!**
### Goal plan/goal plan review
The same form can be used for a Goal plan review. The difference is only that the 'MAST Assessment date' should be left blank.
All the previous goals and progress will pull through to your new form, so you only need to update any changes and then save. Yuss!
## Group activities
> Use 'Group activity' for anything like language days or events!
Group activities can be set up for Whanau ora clients, and used as a set for RSVP and/or attendance purposes:
Follow the form to enter relevant information. Families you are inviting to the event should be added as participants. You can also add new clients in here if they are not already in Kotahi.
At or after the event, your event can simply be edited to update with attendance details. If a client did not attend, just update their attendance and save the form:
These datasets can be sent to Finance from the Data team to assist with spend/reimbursement.
Where Finance supplies a 'spend' figure for the event, please just complete a Requisition and update family total spend accordingly so the running total is accurate. Info on completing Requisitions is up next yo.
## Requisition
> This is where things get serious :sunglasses:
The requisition process is probably the area of greatest change, since there is an opportunity to streamline process and make it more transparent/auditable.
Open a 'Requisition form' for your client.
:::success
:heavy_check_mark: 'Activity duration' should be used to help quantify the amount of time and effort that goes into working with families!
:::
Some information should be pre-populated:
:::warning
:warning: The family total spend amount should be updated by Team Lead/GM after each approved requisition. This will keep a running total available in Kotahi for all family members.
**Prior to go-live this will be updated with the current balance for each family.**
:::
There is space on this form for **five** separate request items. The WO Domain, supplier and requisition amounts can be entered for each.
The Budget and copies of invoices/receipts should be saved as a PDF and uploaded to this page, so it can be accessed by Team Lead/GM for approval.
This request can now be 'sent' to the approver to complete.
The selected approver will receive a notification, and complete the approval process.
Completed approvals are then notified to WO Admin and Finance to arrange and/or pay.
### Requisition process flowchart
A full flowchart of the process is shown below:
**LEGEND**
<span style="background-color: #4e914e">Green</span> = Kotahi
<span style="background-color: #eb4910 ">Orange</span> = Penelope
```mermaid
flowchart TB
subgraph N0[<b>Navigator prepares requisition]
direction TB
N1[Complete budget]:::none-.->
N2[Collate invoice/receipts]:::none-.->
N3[Enter Penelope requisition info]:::penelope
N4[Begin Requisition form]:::kotahi
end
subgraph K0[<b>Kotahi requisition]
direction TB
K1[Check 'date of last <br>MAST' is correct]:::kotahi-.->
K2[Update requisition details]:::kotahi-.->
K3[Upload Budget/invoice PDF]:::kotahi-.->
K4[Select Team Lead]:::kotahi-.->
K5[Save form]:::kotahi
end
subgraph TL0[<b>WO Team Lead]
direction TB
WA1[Review requisition]:::kotahi-.->
WA2[Note recommendation/<br>adjust values]:::kotahi-.->
WA3[Save approval form]:::kotahi
end
subgraph GM0[<b>GM]
direction TB
GM1[Review requisition]:::kotahi-.->
GM2[Note recommendation/<br>adjust values]:::kotahi-.->
GM3[Update family total spend]:::kotahi-.->
GM4[Save approval form]:::kotahi
end
subgraph F0[<b>Finance]
direction TB
F1[Access invoice data]:::kotahi-.->
F2[Arrange payment]:::kotahi-.->
F3[Close Payment Task]:::kotahi
end
N2-.->N4
N4-->K1
K5-- TL Notification -->TL0
WA3--GM Notification -->GM0
GM4--Finance Notification -->F0
classDef kotahi fill:#99cc99
classDef penelope fill:#eb4910,color:lightgrey
classDef none fill:#ffffff
```
### Requisitions for Group activity
Where WO families are being invited to group events, a 'Group activity' should be set up with all the invitees specified.
Finance will then work out the spread cost to be allocated to families.
This should still be added as a 'requisition', even though it is obviously a bit different. In this case, the requisition should be completed as usual and relevant details and amount entered.
Supporting documents won't be required, and the request only needs a **Team Lead** approval for reference. It obviously does not need to be notified to Finance either.
**LEGEND**
<span style="background-color: #4e914e">Green</span> = Kotahi
```mermaid
flowchart TB
subgraph N0[<b>WO Admin/Navigator]
direction TB
N1[Group activity set up]:::kotahi-.->
N2[Clients added]:::kotahi
GM1[Requisition for spread cost]:::kotahi-.->
GM4[Save requisition form]:::kotahi
end
subgraph TL0[<b>WO Team Lead]
direction TB
WA1[Review requisition]:::kotahi-.->
WA3[Save approval form]:::kotahi
end
subgraph F0[<b>Finance]
direction TB
F1[Spread cost]:::none-.->
F2[Report back spend per family]:::none
end
N2--Email RSVP-->F0
F2--Email-->GM1
GM4--TL Notification-->TL0
classDef kotahi fill:#99cc99
classDef penelope fill:#eb4910,color:lightgrey
classDef none fill:#ffffff
```
# Admin usage
> As at 17 October **only**!
This section contains a focused guide to help key Admin functions in working with Whanau ora clients.
## Finding clients
The quickest route to finding a client (or their family) is to search for the name in the 'Client Search' box on the right:
Note that only up to five records are shown - if the client you want isn't in the list then just keep typing!
We can only search by individuals, but their fanau members will be already set up and available via the 'Whanau' button on the left side:
## Getting latest info
To find the most recent info for a client, go their record and select 'Activity'.
This will list all completed activities in order from newest to oldest.
:::warning
Note that any incompleted/parked activities will show first, regardless of date!
:::
You can click on the activity to read it. Note that, depending on the client and associated services, some activities might be marked as :warning:**confidential**:warning:. You can still open and read these if necessary, but the owner will be notified that it has been viewed:
### Requisition status
The requisition workflow has multiple stages of approval. A new version of the form is saved at each stage.
This is how to identify the requisition status:
```csvpreview {header="true"}
Requisition status,Description
Submitted but not approved,You will see a completed 'Requisition Form' activity but no subsequent 'Requisition Approval' activity (or the approval is incomplete or parked).
Approved by Team Lead but not by GM/CE,You will see a completed 'Requisition Approval' activity but it will not have a 'TOTAL APPROVED REQUISITION AMOUNT' entered.
Approved by GM/CE but not yet paid/actioned,The latest completed 'Requisition Approval' activity has 'Ready for Finance' ticked.
Complete,The latest completed 'Requisition Approval' activity has 'Finance completed' ticked.
```
## Adding information
To record a contact like a message, or an incoming request, it is best to use the generic 'Narrative Case Notes' activity.
Find your client, go to 'Add Activity' near the top right. This takes you to the Activity tab.
Use the top right menu to choose the Narrative Case Note. You can now add as much information as you like to make a record of the contact.
If any follow-up action is required, then follow the below process:
1. Start a new narrative case note
2. Enter any information needed to record the contact
3. At the bottom, tick 'Send requisition task' and you can then choose who to assign the task to.
:::warning
:warning: This will usually be the Navigator. However if the request is **urgent** then check the Navigator is working first - otherwise send to another person or delegate who can complete the requisition.
:::
5. This emails the Navigator directly to tell them about your message
6. A notification is added for that user in Kotahi:
7. The Navigator will then need to follow up with the requisition, following their usual process.
8. Once complete, the Navigator must check the task is complete.
9. It is easy to see the status of a users' tasks, by using the 'Tasks' menu, and filtering for user and 'All Incomplete Tasks':
If it's still in the list then it hasn't been completed yet. Alternatively, you can check the client record to look at 'Activity' and find a requisition and any associated updates.
```mermaid
flowchart TB
subgraph N0[<b>WO Admin/Navigator]
direction TB
N1[Group activity set up]:::kotahi-.->
N2[Clients added]:::kotahi
GM1[Requisition for spread cost]:::kotahi-.->
GM4[Save requisition form]:::kotahi
end
subgraph TL0[<b>WO Team Lead]
direction TB
WA1[Review requisition]:::kotahi-.->
WA3[Save approval form]:::kotahi
end
subgraph F0[<b>Finance]
direction TB
F1[Spread cost]:::none-.->
F2[Report back spend per family]:::none
end
N2--Email RSVP-->F0
F2--Email-->GM1
GM4--TL Notification-->TL0
classDef kotahi fill:#99cc99,font-weight:bold
classDef penelope fill:#eb4910,color:lightgrey
classDef none fill:#ffffff
```
Sign in with Wallet
Connect another wallet