Whanau ora workflow

Background

This article describes implementation of the core 'Whanau ora' service within Kotahi.

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

• Green = Kotahi
• Blue = Aiga
• Orange = Penelope

flowchart TB subgraph F0[<b>Family to be enrolled in Whanau ora] direction TB F1[Parent]:::none F2[Child]:::none F3[Matua]:::none F1<-.->F2 F3<-.->F1 F3<-.->F2 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 TL1[Set up as clients]:::kotahi-.-> TL2[NHI lookup]:::kotahi-.-> TL3[Define whanau relationships]:::kotahi-.-> TL4[Assign to Whanau ora service]:::kotahi-.-> TL5[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 notification --> TL0 TL5 --> WN0 classDef kotahi fill:#99cc99 classDef penelope fill:#eb4910,color:lightgrey classDef none fill:#ffffff classDef default none

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.

Sharing contact with whanau in Kotahi

This simply makes a copy of this form in the record of all family members.

Kotahi contact shared from another Whanau member

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.

Using Kotahi for MAST assessment and goal plan reviews

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. 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.

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: If you are doing a MAST assessment it's really important you change the 'MAST Assessment date' on the first page. This will automatically pull through onto a new requisition form and save a few seconds of your time. If you are simply updating goals/goal plan, and not doing a MAST assessment, then you can leave this field alone.

Ensure the MAST assessment date is updated so it will come through to a requisition form

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.

Setting up a group activity in Kotahi

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.

Recording group activity attendance for clients

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.

Requisition

The requisition process is probably the area of greatest change, since there is an opportunity to streamline process and make it more transparent/auditable.

Some information will automatically pull through onto a new requisition form

Open a 'Requisition form' for your client. Some information should be pre-populated. The family total spend amount should be updated by Finance after each approved payment. This will keep a running total available in Kotahi for all family members.

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 Finance to arrange and/or pay. Finance update the total spend for the family, to keep a running total.

Requisition process flowchart

A full flowchart of the process is shown below.

Legend

• Green = Kotahi
• Orange = Penelope

flowchart TB  %% Set direction inside subgraphs to ensure vertical alignment 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 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/adjust values]:::kotahi WA3[Save approval form]:::kotahi end subgraph GM0[<b>GM] direction TB GM1[Review requisition]:::kotahi GM2[Note recommendation/adjust values]:::kotahi GM3[Save approval form]:::kotahi end subgraph F0[<b>Finance] direction TB F1[Access invoice data]:::kotahi F2[Arrange payment]:::kotahi F3[Update family total spend]:::kotahi F4[Close Payment Task]:::kotahi end  %% Adjust connections to reduce width N4 --> K1 --> K2 --> K3 --> K4 --> K5 K5 -- TL Notification --> WA1 WA1 --> WA2 --> WA3 N2-.->N4 WA3 -- Approved --> GM0 GM1 --> GM2 --> GM3 GM3 -- Finance Notification --> F0 WA3 -- Info Needed --> K2 F1 --> F2 --> F3 --> F4  %% Class definitions classDef kotahi fill:#99cc99 classDef penelope fill:#eb4910, color:#ffffff classDef default none

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

• Green = Kotahi

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 classDef default none