---
title: 'Pacific data sovereignty: Kaute <> Ahau'
disqus: hackmd
---

Pacific data sovereignty: K'aute <> Ahau
===

:::info
**Useful resources**
- K'aute website: https://kautepasifika.co.nz/
- Fale opening: https://www.youtube.com/watch?v=EwCTvOG701Q
:::

## Table of Contents

[TOC]

## Who are we?
> K'aute's context

K’aute Pasifika are a community provider offering health, social, education and employment services to people and families. Services are funded by a range of agencies such as Te Whatu Ora, Ministry of Social Development and Ministry for Pacific Peoples.

Historically our model for health services has been nurse-led services delivered out in the community with some consultations offered onsite where our families had transport. In 2023 we opened a physical health clinic and have been focused on developing an extended community health model (ie integrating broader primary care) which is based on Pasifika practices and ways of being and knowing. 2023 also saw the opening of our [Early Learning Centre](https://www.kautepasifikaelc.co.nz/), and the Fale. Our aspiration is to fully integrate our services and help families with anything they might need across their life course.

To support this service integration we are implementing a range of new ‘systems of record’ – for example, a Patient Management System (PMS) for the health clinic, and a Client Management System (CMS) for other community service lines. These are off-the-shelf products, and we have been careful to select products which allow us direct access to the underlying data.

As we develop the broader model of care which is based on truly *integrated* services (not just co-located services), we want to make best (and responsible) use of all data we can access – for example, linking ELC and PMS data to keep children current with vaccines where appropriate. There is obviously a lot of work to do around consent, privacy and social licence to explore before we do any of that.

## Data sovereignty
> What it looks like to us

We would like to explore how to put families in control of their own wellbeing data.

Practically this involves a service where wellbeing/health information defaults to ownership and control by the family and its members. That data can be shared back to K’aute, and written to the relevant system of record (e.g the PMS), as appropriate.

Below is an indicative diagram of a desired future state for K’aute data (not to scale):


What it shows is:
* A layer at the top where the family create and tell their own story about their wellbeing, and objectives they want to work on.
* This data (including key parts of health information ordinarily stored only in a PMS) resides only with the family and its members (or other groups as appropriate, such as churches, akin to Ahau's Pātaka).
* If we have built trust and social licence, then the family can share this data with us and it then gets written to a relevant system of record.
* Data can then be used for analytics/reporting as necessary (and subject to the terms of consent it was shared under).
* Consent is then an explicit and dynamic component in the model; we want this to be continuously reviewed and updated throughout the family journey and we should also consider the ‘right to be forgotten’ upon exiting our care.

### Indicative single user flow
---

sequenceDiagram

Faimafili->Nurse Asenati: Here's how my family are doing
Note right of Nurse Asenati: Let's take your BP
Nurse Asenati->Faimafili: Data added to record
Note left of Faimafili: Trust built over time
Faimafili->K'aute: I'll share my info with you
Note right of K'aute: Shared data written to PMS
K'aute->Nurse Asenati: Read data as needed
Faimafili->K'aute: See access/usage data
Note left of Faimafili: Trust enhanced

## Answers to questions from Ahau team
### General information
> What is the problem?
> What is the primary purpose of this database system?
> Can you provide an overview of the healthcare center's structure, services offered, and patient demographics?

**Problem statements:**
1. Family understanding of what they are consenting to is not well understood and/or checked/measured – is the consent obtained at the point of entry genuine;
2. Families cannot currently exert real data sovereignty (ownership and control) over their wellbeing data. The system/tool should enable this as a core requirement.

K’aute’s extended community health entity currently is only enrolling a restricted amount of patients as part of a project in BAU, but our goal is to deliver health and wellbeing services within a Pacific model of care to anyone who needs it. Our model is designed to make access to services as easy as possible, for example by minimising cost to patients and mitigating other barriers to access.

K’aute already has [a number of health contracts](https://kautepasifika.co.nz/services/health/), for example:
* Immunisation
* Chronic disease management
* Stop Smoking services
* Sexual health
* Wellchild/Tamariki ora
* B4 school checks
* Rheumatic fever
* Cervical screening

These will continue to be delivered but we want to move away from the mainstream practice of basing services in a physical centre. Ultimately our service will bear no resemblance to mainstream models and will be delivered in a wide range of ways/spaces/places.

:::warning
:information_source: Formal ‘health care’ is only one part of what K’aute offer – we are particularly interested in [holistic wellbeing](https://www.mpp.govt.nz/assets/Reports/Pacific-Wellbeing-Strategy-2022/PWS-Outcomes-Framework-A3.pdf), which spans across and beyond all of our services.
:::

Our model is being developed on several principles/understandings; all contributors to the continuum of care are equally important (ie GP is the last port of call) and security of tenure and appropriate housing are critical enablers of transformational and intergenerational outcomes.

### User requirements
>Who are the users of the system (doctors, nurses, administrative staff, family etc.)?
>How do patients and their families intend to interact with the system?
>Are there any specific roles or permissions for different user groups?
>Which devices are users going to be using to access your systems?

As we have roughly envisaged in the above diagram, we expect that a decentralised tool would be a place where families manage their own health/wellbeing information. Our initial thinking is that this information (which encompasses traditional data usually captured in a PMS, but also go beyond that to allow more flexible capture of a wellbeing journey) resides solely with the family/family member, unless they choose to share it with us.

On that basis, different family members would be the main users. However, practice staff (GP, Nurse, MCAs) would also probably need to engage with it depending on the exact model/process we decide on.

In terms of permissions, there are probably three components that spring to mind:
1. The ability of a family to add/remove family members to their group
1. The ability of family members to choose which data is private or visible to the family
1. The ability of a family to choose whether or not to share their information with K’aute (alongside this is an ability to see some audit metadata – who accessed our data and when? - as well as revoke permission).

In terms of devices, we need to do some work to understand more about what families think. But, in the spirit of enabling all types of access, we anticipate that this thing is easily accessible via any digital device.

### Data management
> What types of data will be stored in the database (patient records, medical history, appointments, billing information, etc.)?
> How is the data currently managed, and what improvements are desired?

In theory, we’d like a full PMS data set to be stored so that the family truly has control of all their data. In terms of putting a manageable scope around a POC/pilot we might want to limit to a subset of that bigger data set. But in theory, it would encompass anything that a PMS would traditionally store:
* Prescribing
* Diagnosis
* Measurement
* Appointments/consult notes
* Referrals

::: danger
:warning: Some data points need much more careful consideration than others. For example, a modern PMS has built-in third party interfaces for referrals or prescribing and these will be way outside scope of a POC.
:::

Alongside this routine healthcare data, we’d like the family to be able to do the following:
* Family members/profiles (inc. some identifier we can connect to our data store in event that family do share the data with us)
* ‘Our story’ – a place where families can describe themselves in their own words
* Goals/objectives – a way to define objectives, including milestone dates, actions, as well as a way for family members to annotate or contribute to a goal/objective in their own way (and, again, share with us if they choose).

### Security / privacy
> What security measures should be in place to protect sensitive health information?
> Are there any legal or compliance requirements for healthcare data, such as HISO?

A full [Privacy Impact Assessment](https://www.privacy.org.nz/responsibilities/privacy-impact-assessments/) would be required, and we would also like to seek opinion of the Office of the Privacy Commissioner as a safeguard.

There are legal requirements around different parts of healthcare data, spread across a range of legislation. However, these rules are based entirely in a model of centralised data capture. For example both the [Health Act 1956](https://www.legislation.govt.nz/act/public/1956/0065/latest/DLM305840.html) and the [Retention of Health Information Regulations 1996](https://www.legislation.govt.nz/regulation/public/1996/0343/latest/DLM225616.html) place obligations on providers who hold information about people. The purpose of this proposal breaks that assumption apart and leads to some grey areas around legislation and regulation. This is all to say that some detailed work will need to be done on this topic to fully understand this, before breaking any ground.

Privacy considerations also take on a different form here, since family health data would be shared according to potentially detailed rules (for example, I’ll share my vaccination history but not my sexual health data). These must be followed very strictly and, furthermore, revocation or change of access grant needs careful planning.

### Integration
>Does the system need to integrate with other existing systems or external databases?
>Are there any specific standards or protocols that need to be followed for interoperability?

Yes, the system would need to interoperate with a Patient Management System. This requires use of the [FHIR](https://www.hl7.org/fhir/overview-dev.html) standard and is currently only available via MedTech's [ALEX](https://medtechglobal.com/nz/medtech-alex/) platform.

### Languages and Cultures
>Considering the diverse population from the Pacific Islands, are there specific languages or cultural considerations that need to be accommodated in the system?
>How can the system be made accessible and user-friendly for individuals from various cultural backgrounds?

Yes we’d really like to make the app/thing genuinely reflective of our families’ culture and traditions – not only in terms of data model and approaches, but in language and accessibility. Probably a good reference point here is work of MPP who focus on a ‘core’ of 9 Pacific languages. In defining a pilot or POC we might choose to limit by language so that, for example, we only offer one or two languages and only families using those languages are invited to take part initially.

:::info
[MPP](https://www.mpp.govt.nz/programmes/pacific-language-weeks/) have organised language activities for Rotuman, Samoan, Kiribati (Tungaru), Cook Islands, Tongan, Tuvaluan, Fijian, Nieuan and Tokelauan. As of 2024 Solomon Islands Pidgin and PNG Tok Pisin are also included!
:flag-tk: :flag-vu: :flag-tv: :flag-to: :flag-sb: :flag-pg: :flag-nu: :flag-ki: :flag-fj: :flag-ck: :flag-ws:
:::

### Collaboration and Communication
>How should the system facilitate communication between healthcare providers, patients, and their families?
>Are there specific features like messaging, tele-health capabilities, or appointment scheduling that are important?

Health interactions – such as scheduling or telehealth – are traditionally quite well catered for in PMS ‘patient portal’ products such as MyIndici or ManageMyHealth. However, these obviously rely on a pre-existing centralised data store. At the pilot stage it seems unlikely that the cost-benefit to replicate these will stack up, but this is certainly something to take to our community stakeholder fono and seek further advice on.

### Scalability and Future Needs
>What is the expected growth in terms of patient numbers and data volume?
>Are there plans for future expansion or additional features?

As indicated, we envisage running a POC with a limited number of families (recognising that there will be support work/orientation needing to go alongside this as well as some of the research/evaluation and profile-raising/advocacy we want to do around this whole approach). Optimistically, all being well, we would eventually want to roll out a successful pilot to all our families. If successful, we would like to extend the principles of data sovereignty across as much of our work as possible/appropriate. In the future, all being well, this would potentially allow families to share with other entities/agencies/providers.

For context, we currently have ~4,200 families engaged with K’aute Pasifika services in total. Additionally, it is worth pointing out that we are really interested in sharing this work with other Pacific providers who we work with as part of a collective (Aere Tai) across Te Manawa Taki. But there will be significant interest outside of this region and, indeed, much further afield.

### Training and Support
>What training resources will be provided to healthcare staff, patients, and their families?
>What kind of ongoing support and maintenance are expected?

We’d really value Ahau’s experience on this front, but we do know that digital equity and digital literacy is a problem for many Pacific families. We recognise that families will need a solid support/care system in place to help them make use of this. We haven’t thought about this component in much detail yet, but it is obviously really important!

### Budget and Timeline
>What is the budget allocated for the project?
>What is the desired timeline for the development and implementation of the system?

We do not yet have a formal budget for this work, however there is funding we can access as long as we can articulate a really good use case and demonstrate a realistic chance of success in partnership with a proven supplier.

We wanted to check our alignment with Ahau at an early stage, but there are still quite a few governance steps to work through before we can break ground. Part of doing that will be defining the scope of a POC in more detail.

## Questions?