Editing Kotahi CMS overview

==Background==
Kotahi is a SaaS Client Management System (CMS) that, as at June 2024, is the preferred solution for K'aute Pasifika to transition to from [[Aiga]].

Implementing a modern fit-for-purpose CMS is a key part of K'aute's digital strategy, and also a key enabler for the wellbeing model.

==Key information==
Product website for Kotahi is at [https://kotahi.nz/ https://kotahi.nz/].

Customers have a subdomain to log into, configure services and use the product itself.<ref>K'aute's login url is [https://kautepasifika.kotahi.nz/ https://kautepasifika.kotahi.nz/].</ref>

==Core concepts==
Some key concepts that Kotahi uses are noted below:
* There is no 'family' object (as known in the Aiga system). People are always added as individuals, but are then connected via 'whanau' relationships. This enables both an individual view, and the ability to bulk-write transactions against families, for example in the case of Whanau ora.
** Available family relationships can be configured.
** Making best use of this implies an initial and ongoing data-entry task.
* Everything is configurable. Kotahi does not prescribe how anything must be done - it is up to us to define how we want to organise and manage clients/families within the system. This implies a few important things:
** Need for thorough BA work on priorities such as: compliance, contract reporting.
** Ideally a firm understanding of the 'wellbeing' future state, so we can start to work within that context rather than simply replicating Aiga in a new system.<ref>Although it should be noted the productivity advantages of Kotahi would represent a massive win, even if this was the case.</ref>
** Careful balancing of 'required' versus 'optional' tasks (and associated deadlines) so that service quality is maintained and can be tracked, but also allowing flexibility and judgement of staff depending on their caseloads and operational priorities.
* A 'service' is superficially the same as a 'contract' in Aiga. However, in Kotahi a 'service' really serves two main purposes:
** Used simply as a 'contract' it would allow easy visibility and reporting of contract activity.
** 'Service' is functionally just a container for 'tasks' or 'activities', which can be configured as mandatory and scheduled. Therefore, it is possible to use this service concept in a broader sense depending on operational needs.
* 'Tasks' are things that need to be done within a 'Service'. Again, these are all 100% configurable:
** Tasks can be configured on a timeline so that, for example, monthly assessments are automatically set up for the case manager to complete and progress/adherence is visible.
** Tasks can be configured as simple checks, or built in the system as 'forms' or assessments - providing the ability to capture all the information electronically, and then pick it up and report on it as needed.
* Audit. All activity in Kotahi is audited, and clearly visible to anyone. In terms of access control there are basically two options:
** 'Confidential' activity can be tagged as confidential. Anyone can still view this is they wish, however it will be flagged in the audit and the 'case manager' will be notified.
** Alternatively, a 'hard lock' can be set by removing individual staff from accessing anything to do with a particular service. Choosing which approach to take also requires careful consideration.

==Implementation==
This section is a placeholder list for issues/considerations regarding implementation:
# Use of Aiga/Kotahi in parallel as teams/services are onboarded and impact on access to information and reporting needs to be considered.
# Backloading Aiga data. Kotahi does have the ability to 'import' client data, but there is no such facility for other content.
# 'Admin' users. Kotahi enables us to be self-sufficient, but only if we have suitably trained and competent people to admin our system. K'aute should identify 4-5 roles who will consistently be able to admin our system as required - including user management, and configuration of services/tasks as necessary.
# Client files. Presently, teams<ref>This issue was raised by Whanau ora team, but affects all.</ref> store client files in Sharepoint, so they can be uploaded to relevant systems when time permits. These are currently separated/identified by their Aiga client ID. If this business process needs to persist then we need to think about how client IDs will be 'migrated' and it will be possible to link Kotahi clients with Sharepoint files. Alternatively, it seems more efficient to remove this step completely and store documents directly in Kotahi. However, this requires change in operational workflow of affected teams and, as a minimum, careful backloading of all current files.

== Update Logs ==

Update logs detailing Kotahi service/activity configuration changes are available at [[:Category:Update logs]].

==References==

[[Category:Kotahi]]