Māori Data Sovereignty — Implementation Guide for QA Engineers

1 The Hook

It is 9 am on a Monday and you are the senior QA engineer on the Ministry of Health EHR migration project. The integration test sprint starts today. The extract for your test environment has just arrived from the data engineering team: 80,000 de-identified patient records to support testing of the new inter-agency data sharing hub.

You open the field manifest. Among the standard fields — patient ID, date of birth, NHI number, clinical codes — you see two fields you did not fully account for in the test data strategy: iwi_affiliation and whanau_group_id.

You check the standard anonymisation script the team has been using all project. It strips both fields. Every record that had an iwi affiliation value comes through with a null. That is technically PII-safe — no individual can be re-identified from a null field. The Privacy Act check passes.

Then you check the integration test suite. The equity analysis reporting module — one of the primary requirements of this migration, mandated by the Health Strategy — has 23 test cases that verify iwi-level health outcome aggregation. With nulls in the iwi field, every single one of those tests fails. Not because the code is wrong. Because there is no data to aggregate.

You consider your options. You could restore the real iwi affiliation values, unstripped. But that means 80,000 real patients' cultural and ethnic identity data sitting in a shared test environment — a clear breach of Te Mana Raraunga and arguably the Privacy Act. You could skip the equity reporting tests. But they exist because the Ministry signed a commitment to iwi-level health equity measurement; skipping them means shipping without evidence the feature works. You could mark the tests as blocked and delay the sprint. But the migration has a hard deadline tied to funding.

Neither “strip it and break the tests” nor “keep it real and breach sovereignty” is acceptable. This lesson is about finding the third path.

2 What Is Te Mana Raraunga?

Te Mana Raraunga is the Māori Data Sovereignty Network. Its founding principle is that data about Māori people, drawn from Māori, or held by Māori, should be subject to Māori governance. This is not a software standard or a regulation. It is a declaration of indigenous rights, grounded in the same whakapapa of authority — tino rangatiratanga — that underpins the Treaty of Waitangi.

How Te Mana Raraunga differs from the Privacy Act 2020

This is the distinction that trips up most QA engineers. Both are real obligations, but they protect different things:

A Privacy Act de-identification pass does not fulfil Te Mana Raraunga obligations. You must address both, separately, with different techniques.

3 What Counts as Māori-Specific Data?

Māori-specific data does not always announce itself with an obvious field name. Here is how to categorise it when you receive a dataset:

Direct

• Iwi affiliation — explicit membership identifier for an iwi. The single most common field of this type.
• Hapū membership — sub-tribal group affiliation; more granular and often more sensitive than iwi.
• Marae association — the marae a person identifies with; carries geographic and relational implications.
• Whānau group identifier — a link to a family grouping within a system; present in health, social services, and education systems that use whānau-centred service models.
• Self-identified ethnicity (Māori) — a standard ethnicity field where the selected value is “Māori”; governed under both the Privacy Act (sensitive personal information) and Te Mana Raraunga at aggregate level.

Derived

• Geographic data that implies iwi territory — addresses or location codes within specific rohe (territorial areas) can be used to infer iwi affiliation, particularly in smaller communities. This matters for datasets that lack an explicit iwi field but include addresses.
• Aggregated health data with ethnicity breakdown — health conditions with known higher prevalence in Māori populations, when grouped by ethnicity, become de facto Māori population data even if no individual record has an iwi field. The aggregate carries collective meaning.

Content

• Te reo Māori text fields — names of marae, whānau collectives, place names (especially within custom input fields), and user-supplied text that contains te reo content.
• Transliterated names — personal names of Māori origin stored without macrons (e.g. “Maori” in place of “Māori”) are still Māori-identifying content even when the encoding is broken.

Relational

• Whānau structure data — multi-household family networks, extended kinship relationships, and shared guardianship arrangements are more interconnected in Māori social structures than typical nuclear-family models. Systems that represent whānau as a network graph — common in health and social services — carry collective identification risk even when individual fields are de-identified: the network structure itself can identify the whānau.

4 The Anonymisation Challenge

Standard anonymisation techniques, developed for western data privacy frameworks, fail in specific ways when applied to Māori-specific fields. Here is what goes wrong and why:

Why hashing fails

SHA-256 of “Ngāti Porou” is a3f7d9.... You cannot reverse it, so re-identification is prevented. But you also cannot test any report that aggregates by iwi. The hash is indistinguishable from any other hashed value. You have destroyed the analytical structure the test depends on while keeping the governance question unresolved — the data still came from real patients, and the decision to use it was made without Māori governance involvement.

Why generalisation fails

Replacing all iwi values with a single value like “Māori” removes the granularity that iwi-level equity reporting requires. An EHR system that reports health outcomes at iwi level — as many NZ health programmes require — cannot be tested with generalised values. You lose the distinctions the test is designed to verify.

Why shuffling fails

Randomly reassigning iwi affiliation values between records produces impossible combinations. A patient with a Northland address assigned to Ngāi Tahu (a South Island iwi) creates geographically implausible records. Downstream tests that check geographic plausibility, or that use address + iwi combination for service routing logic, will produce false failures. You also still have the governance problem: the data still originated from real patients.

How to do it: four steps

5 Concrete Test Scenario

What data you need

Enough synthetic records per iwi group to exercise the aggregation logic. For a dashboard with 20+ iwi groups:

• Major iwi groups (representing >5% of real population): at least 50 synthetic records each, so the percentage calculation in the dashboard is meaningful
• Minor iwi groups (representing <2%): at least 10–20 records each, enough to confirm they appear in the output at all
• Edge case: at least 1 iwi group with exactly 1 record, to test that the dashboard handles a count of 1 without dividing-by-zero or suppression logic errors
• Edge case: at least 1 client record with iwi_affiliation = NULL to test the “not stated” bucket in the dashboard

What to generate

• Realistic NZ personal names drawn from name frequency tables (not copied from any real person in the dataset)
• Valid NHI format: three uppercase letters + four digits + check digit (AAANNNNN), verified structurally correct but confirmed not present in production NHI list
• Geographic locations (suburb, region code) that are plausible for the assigned iwi territory — assign a Ngāi Tahu record an address in Canterbury or Otago, not Northland
• Benefit type, duration, and service codes drawn from the real distribution of the same, not random values
• Date of birth generating valid ages that match the real age-band distribution

What NOT to do

Test assertion example

6 Te Reo Māori Field Handling

Fields containing te reo Māori content require specific technical verification that is separate from the data sovereignty question. The encoding and search behaviour of these fields is where implementation bugs surface.

Unicode normalisation

Form fields that accept te reo Māori content — marae names, whānau collective names, iwi names in custom text fields — must be stored as NFC-normalised Unicode. NFC (Canonical Decomposition, followed by Canonical Composition) ensures that a character like ā is stored as a single code point (U+0101) rather than as the decomposed pair a + combining macron (U+0061 + U+0304). This matters for database sorting, equality comparisons, and string length calculations. A field that stores the same string in two different normalisation forms will produce false negatives on exact-match queries.

Test this explicitly: submit a form with an iwi name that includes macrons, retrieve the value via API, and assert that the stored form equals the NFC-normalised input — not just that the character displays correctly in the browser.

Macron rendering in legacy systems

This is not a trivial problem for older NZ government systems built on COBOL or Oracle databases with Latin-1 or Windows-1252 collation. Macrons are multi-byte characters. A field defined as VARCHAR2(50 BYTE) in Oracle will truncate a string of 50 macron-containing characters because each macron character occupies 2 bytes in UTF-8 — effectively halving the usable field length. Test for this specifically:

• Submit a field value at exactly the declared maximum length, using macron-containing te reo text
• Verify the value is stored and retrieved without truncation
• If truncation occurs, the fix is VARCHAR2(100 CHAR) rather than VARCHAR2(100 BYTE) in Oracle, or equivalent in the target database

Search and filtering with and without macrons

This requires a defined acceptance criterion before you write the test, because either behaviour can be correct depending on the decision made:

Search input: "Ngai Tahu" (no macron)
Stored value: "Ngāi Tahu" (with macron)

Option A — Strict Unicode match (returns no results):
  Acceptable if documented. User should see a helpful “did you mean Ngāi Tahu?” suggestion.
  A silent no-results response is a usability defect regardless of the policy.

Option B — Normalised search (returns Ngāi Tahu results):
  Requires explicit transliteration/normalisation in the search layer.
  Verify this is implemented deliberately, not accidentally (some search
  libraries normalise silently; confirm the behaviour is intended and tested).

Whatever the decision: write it as an acceptance criterion and test both
directions. A silent mismatch either way is a defect.

7 Governance Checklist for QA Teams

Before your test sprint begins, work through this checklist with your test lead and, where applicable, the project’s Māori data governance contact. If any item cannot be answered, treat it as a sprint blocker, not a post-launch action.

• Who approved the test data strategy for datasets containing Māori-specific fields? A named individual or governance body should be on record. “The data engineering team decided” is not governance approval.
• Has a Māori data governance advisor or relevant iwi data governance contact been consulted on the approach? This is required under Te Mana Raraunga for datasets that have collective significance. Document the consultation outcome even if it is a brief sign-off.
• Is the synthetic dataset stored with the same access controls as the production data? Named, audited access; NZ data residency; no open S3 buckets or shared-drive folders.
• Does the test data retention policy specify an expiry date and a named owner responsible for secure disposal? “Keep it until we no longer need it” is not a retention policy for taonga.
• Has the distribution profile (Step 1 metadata) been treated as sensitive? Even anonymised population statistics can carry sensitivity for small communities. Confirm it is stored with appropriate controls.
• Does the test coverage for the equity reporting module include test cases that would detect a systematic bias or filtering error that disproportionately affects one iwi group? Functional tests that only check “a value appears” will not catch equity-level defects.
• Is there a Māori stakeholder review planned for the equity reporting module before go-live? This review should look at whether the aggregation logic, the dashboard labels, and the data categories reflect the iwi-level reality they are meant to represent. QA can surface the need for this review; the decision to conduct it belongs to the project and agency leadership.
• Are the test assertions for iwi-level aggregation checking the correct denominator? (Total active records in the period, not total records in the synthetic dataset.) This is a common implementation error that produces systematically wrong percentages.

8 Prompt Lab

Use this prompt lab to generate a synthetic test data specification for a real project you are working on, or to get AI feedback on a governance approach you are designing. Edit the prompt before running — the more specific your scenario, the more useful the output.

9 Self-Check

Click each question to reveal the answer.

10 ISTQB Alignment