10 OAIC PIA Steps for Privacy by Design in Australian Healthcare

Privacy by design in healthcare means embedding patient-data protection into systems and workflows from the first design decision, not bolting it on afterwards. The immediate next step for any health project is to run a privacy impact assessment or at least a threshold assessment, guided by the Office of the Australian Information Commissioner (OAIC) and the Australian Privacy Principles (APPs). That one action surfaces risks early, before they become expensive to fix.

TL;DR:

• A new use of patient information, such as inferring a condition from search behavior, triggers a full privacy impact assessment despite existing safeguards.
• Revisit the PIA whenever a project adds a data source, integration, or user group, and track each recommendation as an assigned, dated project task.
• Use role based access, unique accounts, tamper resistant audit logs, and encryption together; encryption alone cannot prevent misuse by an authorized account holder.
• Schedule quarterly access reviews and test the breach response plan annually, with clinical, IT, and reception staff involved in the exercise.
• Systems connecting to My Health Record, electronic prescriptions, or the Healthcare Identifiers Service must meet Australian Digital Health Agency authentication and conformance requirements.

Table of Contents

• What privacy by design is and why it matters in healthcare
• Regulatory and policy context you must align with
• Privacy impact assessments: the OAIC 10-step workflow as your PbD engine
• Design and technical controls that make privacy real
• How the ASD Essential Eight supports privacy by design
• Privacy-preserving research environments and federated approaches
• Governance, culture and breach response that make it stick
• An operational checklist for delivering privacy by design
• How Meddle implements privacy by design in practice
• Why embedding privacy by design pays off beyond compliance
• Put privacy by design to work with Meddle
• FAQ
• Sources

What privacy by design is and why it matters in healthcare

Privacy by design (PbD) asks teams to treat privacy protection as a default setting, not an optional feature. The OAIC defines it as embedding good privacy practice into the design specifications of technologies, business processes and physical infrastructure, with a privacy impact assessment as the primary tool for understanding impacts before anything is built.

In clinical and technical terms, the original seven PbD principles translate into practical commitments for a health system:

• Proactive, not reactive: privacy risks are identified during planning, not after a breach.
• Privacy as the default: patient data is protected automatically, without the patient needing to request it.
• Privacy embedded into design: controls sit inside the architecture, not as an add-on module.
• Full functionality: privacy and clinical usability are both met, not traded off against each other.
• End-to-end security: protection covers the full data lifecycle, from intake to deletion.
• Visibility and transparency: patients and auditors can see how data is handled.
• Respect for patient privacy: the interface and workflow keep the patient’s interests central.

Health information carries this weight because the Privacy Act treats it as sensitive information, which means stricter handling rules than ordinary personal information. The OAIC’s guide to health privacy notes that the permitted health situation exceptions are narrow, so a project cannot assume broad reuse rights over patient records just because the data originated in a clinical setting. For technology teams, this means every new feature that touches patient data (a referral tool, a matching algorithm, a reporting dashboard) needs a documented reason tied back to the purpose the patient consented to, not an assumed one.

Regulatory and policy context you must align with

Australian privacy regulation does not mention “privacy by design” as a legal requirement by name, but the Privacy Act 1988 and the APPs function as its practical engine. APP 1 requires an entity to take reasonable steps to implement practices, procedures and systems that ensure compliance, which is a design obligation in substance. APP 11 requires reasonable steps to protect personal information from misuse, interference, loss, unauthorised access, modification or disclosure, which again pushes decisions back to the design stage rather than the incident response stage.

The OAIC’s role is to provide guidance, investigate complaints and, where necessary, enforce the Act. Its Guide to Health Privacy sets out a practical framework for health service providers built around four stages: embed, establish, evaluate and enhance. Practically, this means:

• Embed: build a privacy management plan into everyday operations, not a filing-cabinet document.
• Establish: assign clear accountability for privacy decisions to a named role.
• Evaluate: map what personal information your systems hold and where it flows.
• Enhance: review and strengthen staff training and breach response plans on a cycle.

The OAIC’s health privacy guidance, updated in 2025, recommends that providers maintain a record of the types of health information they hold and who can access it, alongside a documented breach response plan. (OAIC, Guide to Health Privacy) This single record often exposes the gap between what a system was designed to do and what it has quietly grown to do.

My Health Record and the Healthcare Identifiers Service add another layer. Systems that interact with My Health Record, electronic prescriptions or the HI Service must meet specific technical and access requirements, including authentication and conformance obligations set out by the Australian Digital Health Agency. Our guide to My Health Record compliance walks through what this means for providers connecting to the national system. Teams building referral or scheduling tools that touch identifiers should treat these requirements as non-negotiable inputs to the architecture, not afterthoughts added at integration testing. For a structured walk-through of meeting the APPs specifically, our six-step checklist for clinics breaks the obligations into actions a practice manager can actually run.

Privacy impact assessments: the OAIC 10-step workflow as your PbD engine

A privacy impact assessment (PIA) is where privacy by design stops being a principle and becomes a document with actions attached. The OAIC’s 10-step process gives healthcare and technology teams a repeatable structure, whether the assessment covers a new booking platform, a research database or an AI matching tool.

1. Threshold assessment: decide whether a full PIA is needed by checking if the project collects, uses or discloses personal information in a new way.
2. Plan the PIA: set scope, budget, timeline and who signs off at the end.
3. Describe the project: document what data is collected, why, and how it moves through the system.
4. Identify and consult stakeholders: bring in clinicians, patients, IT and legal early, not after the build starts.
5. Map information flows: trace every point where data enters, is stored, transformed or leaves the system.
6. Privacy impact analysis: assess each flow against the APPs and identify where risk sits.
7. Manage the risks: decide whether to accept, mitigate, transfer or avoid each identified risk.
8. Recommend changes: write concrete, assignable actions, not vague aspirations.
9. Report: produce a document stakeholders and auditors can actually read.
10. Respond and review: revisit the PIA when the project scope changes, rather than filing it away.

For a healthcare matching or referral platform, the threshold assessment step often gets skipped because teams assume existing privacy settings cover new features. They usually don’t. A new matching algorithm that infers a condition from search behaviour, for example, is a new use of personal information and triggers the full process.

Stakeholder consultation (step 4) matters more in health projects than most other sectors, because clinicians often see risks that engineers miss, such as a workflow that forces reception staff to read sensitive notes aloud in an open waiting room. Mapping information flows (step 5) should produce a visual diagram, not just a text description. Our guide to secure document sharing includes a template timeline for this kind of mapping work across a 90-day rollout.

The analysis and recommendation steps (6 to 8) work best when framed as a backlog, not a report appendix. Treat each recommendation as a ticket with an owner and a due date, the same way you would treat a security bug.

Pro Tip: Build PIA actions into your existing project management tool as tagged tickets, so privacy work shows up in sprint planning instead of sitting in a document nobody reopens.

The OAIC is explicit that a PIA is not a one-time gate. (OAIC, 10 Steps to Undertaking a PIA) When a system adds a new data source, a new integration or a new user group, step 10 kicks back in. Teams that treat the PIA as a living artefact, reviewed on the same cadence as a security audit, catch privacy drift before it becomes a breach. Our consent management guide covers how to keep consent records aligned with the information flows a PIA maps, which matters when a project’s scope expands beyond its original purpose.

Design and technical controls that make privacy real

Principles and assessments only matter if the system itself enforces them. Four technical control areas carry most of the weight in a healthcare context.

Data minimisation starts at the collection form. Every field on an intake questionnaire should map to a clinical or operational purpose; fields collected “just in case” are a liability, not an asset. Our pre-appointment questionnaire templates show how to word patient notices so collection stays scoped to what the consultation actually requires.

A minimisation checklist for any new form or API field:

• Does this field serve a specific clinical or operational purpose?
• Is there a less identifying way to capture the same signal?
• Does the retention period match the purpose, or does the data linger indefinitely?
• Can this field be de-identified before it reaches analytics or reporting tools?

Identity and access management is where most health data incidents actually originate, more often than external attacks. Role-based access, scoped to the minimum needed for a job function, combined with unique accounts per user rather than shared logins, gives every access event a traceable owner. The OAIC’s health privacy guidance treats this kind of accountability as central to meeting APP 11, and our 12-step guide to securing patient records sets out how to structure these permissions in practice.

Encryption protects data at rest and in transit, but it has limits: it does nothing to stop a legitimate, logged-in user from misusing data they are entitled to see. That is why encryption needs to sit alongside, not instead of, access controls and audit logging.

Logging and de-identification close the loop. Every access to a patient record should generate a log entry that is itself protected from tampering, and any data pulled into analytics, research or reporting should be de-identified wherever the purpose allows it.

Pro Tip: Run a quarterly access review where a compliance lead checks a sample of logged accesses against a plausible clinical reason. Unexplained access is usually a design gap, not a rogue user.

How the ASD Essential Eight supports privacy by design

Privacy and cybersecurity overlap more than most project plans acknowledge. A health system with perfect consent wording and a weak patching regime is still exposed. The Essential Eight, maintained by the Australian Signals Directorate, gives teams a practical baseline of eight mitigation strategies that reduce both security and privacy risk together.

The items most relevant to patient data protection are:

• Multi-factor authentication: stops the most common path to unauthorised record access.
• Patch applications and operating systems: closes known vulnerabilities before they are exploited.
• Restrict administrative privileges: limits how much damage a single compromised account can do.
• Application control: prevents unapproved software from running on systems that hold patient data.
• Regular backups: protects continuity of care when ransomware or system failure strikes.

The Essential Eight is built around a maturity model, so a small allied health practice and a large hospital network are not expected to implement every control at the same depth on day one. Choosing a maturity level and scaling up is more realistic than aiming for full maturity immediately and stalling. Our audit-ready guide to two-factor authentication sets out acceptance tests for MFA specifically, which is usually the fastest control to implement and one of the highest-impact.

When procuring cloud or software vendors, ask for evidence against these same mitigations rather than taking a sales deck’s word for it. Our security questionnaire for healthcare software gives a structured set of questions to put to any vendor handling patient data on your behalf.

Privacy-preserving research environments and federated approaches

Research teams working with health data face a sharper version of the same problem: the more datasets get linked, the higher the re-identification risk. Trusted research environments (TREs) and privacy-preserving hubs (PHTs) address this by keeping raw data in place and bringing the analysis to the data, rather than moving data to the analyst.

Research describing privacy-by-design environments for large-scale health research explains that TREs and PHTs use compute-to-data models, controlled access and vetted outputs to reduce sharing risk, rather than relying solely on de-identification of exported files. Federated learning extends this idea to machine learning: a model trains across multiple sites without any raw patient record leaving its source system.

For a healthcare project deciding between these approaches, a few questions help:

• Does the project need individual-level records, or would aggregate or model-level outputs suffice?
• Can the analysis run where the data already sits, rather than requiring a central copy?
• Is there a vetted-output process for anything leaving the controlled environment?
• Does the project span multiple institutions, where federated learning avoids a legally complex data-sharing agreement?

Compute-to-data models are usually worth the extra setup effort for multi-site research or any project where linking records across organisations would otherwise require broad new consent. They are less suited to a single clinic’s day-to-day operational reporting, where the data never leaves a tightly controlled system in the first place.

Governance, culture and breach response that make it stick

Technical controls fail quietly when nobody owns them. A privacy management plan, built around the OAIC’s embed, establish, evaluate, enhance cycle, turns scattered good intentions into an operating rhythm.

Practical steps that make a plan real rather than decorative:

• Name a privacy lead with authority to pause a project that fails a PIA, not just a title on an org chart.
• Build procurement clauses that require vendors to meet the same access, encryption and breach notification standards as internal systems.
• Run staff training on recognising and reporting a suspected breach, refreshed at least annually.
• Document a breach response plan that specifies who assesses, who notifies, and within what timeframe.
• Review supplier access on the same cycle as internal access, since third parties are a common entry point for incidents.

Breach notification obligations under the Notifiable Data Breaches scheme mean that an eligible data breach involving health information generally requires notifying affected individuals and the OAIC. Building the response plan before an incident, rather than during one, is the difference between a contained event and a prolonged one.

Pro Tip: Run a tabletop breach exercise once a year with clinical, IT and reception staff in the room. Most gaps show up in handovers between teams, not within any single team’s own process.

Vendor governance deserves the same rigour as internal governance. Our five pillars of data governance outline a procurement-ready framework for assessing whether a software partner’s practices match your own obligations under the Privacy Act.

An operational checklist for delivering privacy by design

Turning all of this into a shippable project means producing specific artefacts at specific points, not treating privacy as a mood that hovers over the whole build.

1. Threshold assessment completed before design sign-off.
2. Full PIA completed and reviewed before development starts on any feature touching patient data.
3. Information flow map kept current and reviewed at each major release.
4. Privacy backlog of PIA recommendations tracked to completion in the same tool as engineering tickets.
5. Access control audit scheduled quarterly, with evidence retained.
6. Breach response plan tested annually via a tabletop exercise.

Each sign-off point should produce a dated record, since the OAIC’s guidance treats ongoing review, not a single approval, as the mark of a mature privacy programme.

How Meddle implements privacy by design in practice

We built our platform around the same embed, establish, evaluate, enhance cycle the OAIC describes for health service providers. Our approach to data governance rests on five pillars, covering access control, encryption, consent handling, audit logging and vendor accountability, set out in full in our guide to healthcare data governance.

Within our matching and referral workflow:

• We scope data collection to what a referral or booking actually requires, rather than capturing a full clinical history upfront.
• We apply role-based access so reception, practitioners and administrators see only the records relevant to their function.
• We log access events to support the kind of audit trail the OAIC expects from health service providers.
• We maintain documentation clinics can review as part of their own procurement checks.

If you are assessing any vendor, including us, ask for evidence of access logging, a named privacy contact and a documented breach response process. Our security questionnaire template is a reasonable starting point for that conversation with any software partner.

Why embedding privacy by design pays off beyond compliance

Treating privacy by design as a compliance checkbox undersells what it actually delivers. The real payoff is trust: patients who believe their records are handled carefully are more willing to share the detail that makes care effective, and researchers get cleaner consent to work with. Clinics that build access controls and audit trails properly also tend to catch operational problems earlier, since a well-logged system makes a billing error or a misrouted referral visible long before it becomes a formal complaint.

My one recommendation for a team starting now: run the threshold assessment this week, on whatever project is closest to launch. It costs an afternoon and tells you immediately whether you are looking at a quick sign-off or a problem worth solving properly before it ships.

— Taylor

Put privacy by design to work with Meddle

Embedding these controls from scratch takes time most allied health practices do not have spare. We built our platform so clinics get secure digital records, access controls and audit logging already structured around the obligations covered above, rather than needing to design them from a blank page.

Specifically, we offer:

• Secure digital health records with role-based access built into the matching and booking workflow.
• Referral automation that keeps information flows documented rather than scattered across emails and faxes.
• Integration options, including FHIR-based connections, for clinics that need their existing systems to talk to Meddle without compromising access controls.
• Practical templates and guides, including our security questionnaire and data governance pillars, that clinics can use in their own procurement process.

If a clinical device or therapy partner needs coordinating alongside allied health care, our guide to coordinating light therapy appointments shows how that kind of scheduling fits into a broader care plan.

Our pricing page sets out plan options including Simple Rollout, SMS Notifications and CRM Integration, so you can see what fits your practice before committing to anything.

FAQ

What are the seven principles of privacy by design?

The seven original principles are: being proactive rather than reactive, making privacy the default setting, embedding privacy into design, maintaining full functionality without trade-offs, securing data end to end, keeping practices visible and transparent, and respecting the individual’s privacy throughout. In healthcare, these translate into scoped data collection, role-based access and audit logging built into systems from the start.

What does privacy by design actually mean?

Privacy by design means building privacy protection into a system’s architecture and processes from the outset, rather than adding it after launch. The OAIC recommends a privacy impact assessment as the practical tool for putting this into practice during design.

What do Australia’s privacy principles cover for health providers?

The Australian Privacy Principles set out obligations covering collection, use, disclosure, security, access and correction of personal information, with health information treated as a sensitive category requiring stricter handling. Our guide to meeting the APPs breaks these obligations into practical steps for clinics.

Can you give an example of privacy by design in a health system?

A patient intake form that only asks for information directly relevant to the consultation, paired with role-based access so only the treating practitioner can view clinical notes, is a working example of privacy by design. Logging every record access and running periodic audits, as described in the OAIC’s health privacy guidance, extends the same principle into daily operations.

How does a privacy impact assessment fit into privacy by design?

A privacy impact assessment is the practical engine that turns privacy by design from a principle into action, using the OAIC’s 10-step process to identify risks and assign fixes before a system is built. It should be revisited whenever a project’s scope changes, rather than filed away once.

Sources

• 10 steps to undertaking a privacy impact assessment | OAIC
• Cyber

Recommended

• 5 steps to align Australian healthcare consent with OAIC rules
• Australian clinics: 12 steps to secure patient records and meet APP 11