My Health Record Data Breach Notification Procedure Template (Section 75)

What's in this template?

This My Health Record Data Breach Notification Procedure gives Australian healthcare practices the operational steps for section 75 of the My Health Records Act 2012: the mandatory duty to notify both the System Operator (the Australian Digital Health Agency) and the OAIC of a notifiable data breach involving the My Health Record system, as soon as practicable. It is built from the OAIC's Guide to Mandatory Data Breach Notification in the My Health Record System.

The template includes:

1. The relationship to your general Data Breach Response Plan, stated as a direct comparison table so staff never mistake one duty for the other
2. The three notifiable data breach categories under section 75, with a healthcare example for each
3. An immediate containment checklist
4. A 6-step dual notification procedure, with owners and timeframes, including the request that the System Operator notify affected patients
5. The notification content checklist, including the explicit rule against naming affected patients to the OAIC or on the System Operator's form
6. Appendix A: a breach register for every incident assessed, whether or not it met the notification threshold

Editable placeholder fields

• {{ }}Practice name{{practice_name}}, {{ }}Hpi o{{hpi_o}}
• {{ }}Responsible officer{{responsible_officer}}, {{ }}Responsible officer email{{responsible_officer_email}}
• {{ }}Privacy officer{{privacy_officer}}, {{ }}It support contact{{it_support_contact}}
• {{ }}Effective date{{effective_date}}, {{ }}Next review date{{next_review_date}}, {{ }}Approved by{{approved_by}}

This is not your general data breach plan

This is the single most important thing to understand about this document: section 75 is a separate legal duty from the Notifiable Data Breaches scheme, and having a Data Breach Response Plan does not discharge it.

The threshold here is deliberately lower than the general scheme. A possible breach is enough to trigger notification, and there is no serious harm test to clear first. That is why a practice needs this procedure as a fast, separate trigger rather than folding My Health Record incidents into the general plan and hoping the same steps cover both.

The two schemes do not double up. Under section 26WD of the Privacy Act, a breach that has been, or must be, notified under section 75 is not notified again under the NDB scheme. The OAIC's own example is a practice manager who views a patient's My Health Record without authorisation: the GP notifies the System Operator and the OAIC under section 75, and there is no need to notify under the Privacy Act as well. If the same practice manager also downloads a patient's information from the practice's own clinical database, that part is outside the My Health Record system and goes through the general Data Breach Response Plan. Where an incident has both parts, both procedures run at the same time, each for its own part.

What the law actually requires

Section 75 defines a notifiable data breach across three categories, and any one of them is enough on its own:

1. Unauthorised collection, use or disclosure: a person has, or may have, contravened the Act in a way involving unauthorised collection, use or disclosure of health information in a My Health Record.
2. System compromise: an event has, or may have, occurred that compromises, or may compromise, the security or integrity of the My Health Record system.
3. Circumstantial threat: circumstances have, or may have, arisen that compromise, or may compromise, the system's security or integrity.

Categories 2 and 3 do not require an actual contravention of the Act. A leaked password list containing the practice's My Health Record login, or a NASH PKI certificate found on an unattended device, can each be a notifiable event on its own, before anyone has actually misused anything.

Once identified, both the System Operator and the OAIC must be told as soon as practicable. The OAIC's guidance is that reporting "should not be at the expense of initial efforts to contain" the breach, and that missing information "should not delay reporting, as further information can be provided when it becomes available". An incomplete notification, followed up with more detail as it becomes available, is the expected pattern, not a failure to notify properly the first time. The OAIC prefers its Report a My Health Record data breach form for this, not the Notifiable Data Breaches form.

Section 75 also requires the practice to contain the breach, evaluate the risks, and ask the System Operator to notify affected patients (and the general public if a significant number are affected). The request is required once the breach is confirmed (section 75(6)(d)), or when it is reasonably likely to have happened and could be serious for at least one patient (section 75(5)(c)). The Australian Digital Health Agency says the request is needed even if the practice has already contacted the patients itself.

How to customise this template

1. Download the Word document and replace every {{ }}Placeholder{{placeholder}} with your details.
2. Confirm your Responsible Officer, the person named to the Australian Digital Health Agency, matches the person named in your Security and Access Policy.
3. Brief staff on Section 4, the three notifiable categories, so a possible breach is reported the day it is noticed rather than sat on while someone tries to confirm it.
4. Confirm the relationship in Section 3 is understood by whoever leads your general breach response, so the My Health Record part of an incident goes through this procedure and any part outside the system goes through the general plan.
5. Keep the notification content checklist in Section 7 handy, and note the rule against naming affected patients in the OAIC notification.
6. Review at least annually, aligned with the section 43 policy review, or sooner after any incident handled under it.

Related templates and tools

• Data Breach Response Plan: the general NDB scheme plan, for a breach outside the My Health Record system and for any part of an incident outside it, such as the practice's own clinical records. Its section 7 points back to this procedure.
• My Health Record Security and Access Policy: the section 21 security and access policy (formerly Rule 42) this procedure supports.
• My Health Record Authorised User Access Register: identifies who had access, which is often the first question in a breach assessment.
• Notifiable Data Breach assessment tool: use it to work through the general NDB threshold for any part of an incident outside the My Health Record system.
• ICT Continuity and Cyber Incident Response Plan: the technical response (containment, eradication, recovery from backup) when the My Health Record incident is also a cyber security incident, under RACGP 6th edition F8.A.
• Healthcare privacy and cyber security: how the My Health Records Act sits inside the wider privacy picture.

Frequently asked questions

Do we still need a general Data Breach Response Plan if we have this procedure?

Yes. This procedure covers the section 75 duty for anything involving the My Health Record system: notifying the System Operator and the OAIC, and asking the System Operator to notify affected patients. A breach notified under section 75 is not notified again under the general Notifiable Data Breaches scheme (Privacy Act s 26WD). The general plan covers everything else: a breach that has nothing to do with the My Health Record system, and any part of an incident outside it, such as the practice's own clinical database. Most practices need both documents.

What counts as a "possible" breach under section 75?

Any of the three categories in the Act: a possible unauthorised collection, use or disclosure of health information in a My Health Record, a possible compromise of the system's security or integrity, or circumstances that may compromise it. The word "may" is doing real work here. You do not need to confirm the breach actually happened or that harm resulted before the notification duty applies.

Who do we notify: the System Operator, the OAIC, or both?

Both, for a registered healthcare provider organisation. The System Operator is the Australian Digital Health Agency. Some entity types, such as state and territory authorities, notify the System Operator only, but a general practice or allied health provider notifies both. The practice does not notify patients under the NDB scheme for the My Health Record part of the breach: it asks the System Operator to notify them.

How fast does this have to happen?

As soon as practicable. The OAIC's guidance does not set a fixed number of days, but it is explicit that notification should not be delayed while containment efforts are still under way, and that an initial notification can be updated with more information later. Treat "as soon as practicable" as the same working session the incident is discovered in, not the next business day.

Can we name the affected patient in the notification to the OAIC?

No. The template's notification checklist carries this as an explicit rule: identify affected people internally by record or reference number, and do not include their identities in what is sent to the OAIC or in the fields of the System Operator's form. Give them only to the System Operator, when it asks for them, so it can notify the patients.

Is there a penalty for not reporting?

Yes, a civil penalty of up to 1,500 penalty units applies to a registered healthcare provider organisation that fails to notify under section 75(2). The System Operator itself faces no penalty for failing to pass a breach on to the OAIC, but the OAIC can investigate where it suspects a breach has gone unreported, which is a separate exposure for the practice if its own notification never happened.

Does every incident go in the breach register, or only the ones we report?

Every incident assessed under Section 4 of this procedure, whether or not it met the notification threshold. That record is what the System Operator or the OAIC will expect to see if they ask how the practice handles potential breaches, and it is also the evidence that near-misses are being tracked, not just confirmed incidents.