Guide · Privacy & de-identification
How do you de-identify documents under the Privacy Act 1988?
Under the Privacy Act 1988 (Cth), information is de-identified when it is no longer about an identifiable individual, or an individual who is reasonably identifiable. Redaction alone rarely reaches that bar: the test covers what can be re-identified by combining your document with other information reasonably available, not just what is visible on the page.
In practice that means three things must hold together: direct identifiers removed, indirect identifiers treated, and a documented re-identification risk assessment retained as evidence.
Most teams treat de-identification as a redaction task: find the names, black them out, ship the file. That interpretation fails the statutory test often enough that it is worth understanding precisely where the line sits, because the consequence of getting it wrong is a notifiable data breach under Part IIIC.
What the Act actually requires
Section 6 of the Privacy Act defines personal information as information about an identified individual, or an individual who is reasonably identifiable. That second limb is where most de-identification work breaks down. It is not a question about your document in isolation. It is a question about your document plus whatever else a motivated party could reasonably obtain.
A file that says "37-year-old male participant, SIL house in Katoomba, incident 14 March" contains no name, no address and no participant number. In a town of that size, with a publicly listed provider roster, it is still reasonably identifiable, and therefore still personal information.
The three layers that have to hold
1. Direct identifiers
Names, participant and client numbers, Medicare and CRN numbers, addresses, phone numbers, email addresses, dates of birth, signatures, photographs. These are the layer most tools handle, and handling them is necessary but not sufficient.
2. Indirect identifiers (quasi-identifiers)
Age, gender, postcode, service type, dates of specific events, employer, rare diagnoses, household composition. Individually harmless; in combination frequently unique. The classic finding in the literature is that a small number of these fields is enough to single out most people in a population.
3. Contextual and residual risk
Free-text case notes, document metadata, file names, tracked changes, and the mere fact that a document sits in a named folder. Metadata is the most commonly missed of these. A PDF exported from a case management system routinely carries the author, the originating record and the export timestamp.
Why the assessment matters more than the redaction
De-identification is not a binary state you achieve; it is a risk position you take and must be able to defend. If a regulator or auditor asks how you concluded a dataset was de-identified, "we ran it through a tool" is not an answer. A defensible position needs: the method applied, the identifiers considered, the residual risk accepted, who accepted it, and when.
This is the part that argues for building the assessment into the system rather than running it as a separate process. If the evidence is generated as a by-product of doing the work, it exists when you need it. If it is a document someone is supposed to write afterwards, it does not.
Where automation helps, and where it does not
| Task | Automate? | Why |
|---|---|---|
| Direct identifier detection | Yes | High recall, well-understood patterns, faster and more consistent than manual review. |
| Metadata and residual-artefact stripping | Yes | Purely mechanical, and the most commonly missed layer when done by hand. |
| Quasi-identifier combination risk | Assisted | A model can surface candidate combinations; a human decides what residual risk is acceptable. |
| Accepting residual risk | No | This is an accountable decision. It needs a named person and a timestamp. |
| Free-text clinical narrative | Assisted | Context-dependent. Full automation produces both over-redaction and misses. |
If you are handling fewer than a few hundred documents a year, a careful manual process with a written assessment template is genuinely sufficient, and you should not buy or build anything. The economics change at volume, and at the point where the same document set is de-identified repeatedly for different recipients.
Common questions
Is redaction the same as de-identification?
No. Redaction removes visible content from a document. De-identification is a legal standard about whether an individual remains reasonably identifiable from the information as a whole. A redacted document can still be personal information.
Does de-identified data still fall under the Privacy Act?
Properly de-identified information is no longer personal information and falls outside the Act. The difficulty is that de-identification is context-dependent. Data released into one environment may be de-identified while the same data released into another is not.
Do we need to keep the original identified version?
Usually yes, and often you are required to. Retention obligations sit independently of de-identification. The two need to be handled as separate lifecycles, which is a frequent source of accidental non-compliance.
What happens if de-identified data is re-identified?
If re-identification occurs and the information is likely to result in serious harm, it may trigger notification obligations under the Notifiable Data Breaches scheme. This is why the residual risk assessment is the artefact that matters.
This guide is general information about how the Privacy Act 1988 (Cth) applies to de-identification practice. It is not legal advice, and obligations vary by sector and by what other information is reasonably available in your context.