Appendix 9
The lawful pathways explained
When synthetic outputs have more than very low re‑identification risk, treat them as personal information and rely on an appropriate lawful pathway before use or sharing.
Why a pathway is needed
Using health data to generate synthetic outputs is typically a secondary purpose under privacy principles and needs an exception/permission.
Two stages can apply
You need a lawful basis for handling source data (always personal information) and also for synthetic outputs if they remain personal information.
Document the decision
Record the chosen pathway, assumptions, approvals, conditions, and controls so reviewers can audit the end-to-end data flow.
Not legal advice
This page is a governance-friendly summary. Confirm which privacy law(s) apply and which exception/pathway is valid for your organisation and dataset (especially across jurisdictions).
Common lawful pathways
Use the decision tree for complex scenarios, then select and document one (or more) pathways that cover the full data flow.
Directly related + within reasonable expectations
Some privacy regimes allow secondary use/disclosure if it’s directly related to the primary purpose and within what individuals would reasonably expect.
When it fits
- • The use case has a clear public benefit linked to health services.
- • Your organisation’s collection notices and practice make this expectation plausible.
- • The project’s data handling stays proportionate and tightly governed.
Typical evidence
- • Collection notices / privacy statements
- • Use case assessment and public benefit justification
- • Internal approvals and governance sign-off
Caution: This is highly context-dependent—if expectation isn’t well established, use another pathway.
Consent
Use/disclose personal information where valid consent is obtained (voluntary, informed, specific, current, and capable).
When it fits
- • You can practically obtain consent from the relevant cohort.
- • Consent can clearly cover purpose and participating organisations.
- • You can operationalise withdrawal, record-keeping, and versioning.
Typical evidence
- • Consent wording and participant information
- • Consent register / audit trail
- • Withdrawal management process
Caution: Often infeasible at scale for historic collections; don’t assume implied consent is sufficient.
Ethics approval (HREC) for research / health service management
Many regimes permit secondary use/disclosure for research or management of health services, often with Human Research Ethics Committee approval and potentially a waiver of consent.
When it fits
- • The project is research or health-service-management oriented.
- • Multiple parties or jurisdictions are involved (consider a nationally certified HREC).
- • Synthetic outputs may still be personal information due to residual re-identification risk.
Typical evidence
- • HREC approval letter (and any waiver conditions)
- • Protocol + data flow diagrams
- • Privacy Impact Assessment (PIA)
Caution: HREC approvals are conditional—match data flows and controls to what was approved.
Required or authorised by law
Use/disclose where another law clearly requires it (mandatory) or authorises it (permitted) within a defined scope.
When it fits
- • You can point to a clear legal authority tied to organisational functions or a data-sharing statute.
- • The activity sits within the scope and conditions of that authority.
- • You can document interpretation and controls for the authorised sharing.
Typical evidence
- • Citation of the enabling provision
- • Legal advice or internal legal memo
- • Information sharing agreement / DSA/DUA
Caution: “Not prohibited” is not the same as “authorised”—the authority must be clear and direct.
Effectively de-identified (very low re-identification risk)
If data is de-identified so identity is not apparent and cannot reasonably be ascertained in context, it may fall outside personal information in many regimes.
When it fits
- • Re-identification risk is demonstrably very low in the intended release environment.
- • You’ve assessed auxiliary data and attacker knowledge assumptions.
- • You can control downstream context changes (or reassess when they occur).
Typical evidence
- • Re-identification risk assessment results (Step 4)
- • Release context description and controls
- • Ongoing monitoring / reassessment triggers
Caution: Risk is contextual and can change—what’s safe in a secure enclave may not be safe for public release.
Other exceptions and directions
Some jurisdictions include additional mechanisms (e.g., codes of practice, public interest directions) that can enable specific secondary uses/disclosures.
When it fits
- • A specific exception is available and applicable in your jurisdiction.
- • Conditions can be satisfied and independently verified.
- • Governance can enforce the permitted scope over time.
Typical evidence
- • Copy of the direction/code and applicability assessment
- • Governance approvals
- • Contractual + technical controls
Caution: These are jurisdiction-specific and can be narrow—confirm applicability before relying on them.
Quick checklist for governance packs
Minimum inclusions
- Law(s) applying and the selected lawful pathway(s)
- Project purpose and why it’s a secondary purpose
- Data flow diagram (who handles what, where, and when)
- Approvals/conditions (HREC, delegated authority, legal basis)
Controls & assurance
- Re-identification risk results and release context
- Technical controls (access, logging, secure enclaves)
- Contractual controls (DSA/DUA, no re-identification clauses)
- Reassessment triggers (context changes, new auxiliary data)