What's in this template?
This My Health Record Authorised User Access Register is a fillable register, not a policy. It gives practices the record Rule 42 of the My Health Records Rule 2016 assumes exists: who is currently authorised to access the My Health Record system on the practice's behalf, when they were authorised, whether their training is done, when their access was last reviewed, and when it was removed.
The template includes:
- A 14-row starter register covering name, role, HPI-I, authorisation date, authorising officer, training completion, periodic review, and removal
- A column guide explaining exactly what belongs in each field, so it stays consistent as different staff maintain it over time
- Landscape layout designed to be filled in directly or transferred straight into a spreadsheet or your clinical software
Editable placeholder fields
{{practice_name}},{{hpi_o}}{{responsible_officer}},{{register_owner}}{{next_review_date}}
A register, not a restatement of the policy
Your Security and Access Policy already sets out how users are authorised, reviewed and removed under Rule 42. This document does not repeat that. It is the evidence that the policy is actually being followed: an auditable list of who currently has access, and the paper trail behind every grant, review and removal.
That distinction matters because an assessor or the System Operator does not ask to see your policy alone. They ask you to show who has access right now, and to prove that access was reviewed on schedule and removed the day someone left. A policy document cannot answer that question. A current, maintained register can.
What the guidance actually expects
Rule 42 requires the practice's Security and Access Policy to address how individuals are authorised to access the My Health Record system, and how access is suspended or removed. The OAIC's Rule 42 guidance and its published assessments of registered organisations consistently point to the same practical control: a register of authorised users, kept current, containing enough detail (name, role, and typically the individual's Healthcare Provider Identifier where they hold one) to identify who accessed the system and confirm the access was authorised.
The audit log built into your clinical software records what happened: who accessed which record, and when. This register records who was allowed to, which is the piece the audit log alone does not answer, because a log entry does not tell you whether that person's access was ever formally authorised, or whether it should have been removed months earlier.
How to customise this template
- Download the Word document and replace every
{{placeholder}}with your details. - Populate it from your current access list, not from memory. Cross-check against your clinical software's user administration screen, because that is usually the most accurate live record of who can actually log in.
- Add a row the day someone is authorised, not in a batch update later. A register with authorisation dates that all match your last audit is a sign the register was backfilled, not maintained.
- Complete the removal column the same day access ends. This is the column an auditor checks first, because a former staff member with live access is the most common Rule 42 finding.
- Use the periodic review column at every access review set out in your Security and Access Policy, typically quarterly or six-monthly, and record the outcome even when nothing changes.
- Move it into a spreadsheet or your clinical software if a Word table becomes hard to keep current with a larger team. The content Rule 42 expects does not depend on the file format.
Related templates and tools
- My Health Record Security and Access Policy: the Rule 42 policy this register supports. Its authorisation, review and removal rules are what this register evidences.
- My Health Record Staff Training and Awareness Procedure: the training this register's training-completed column cross-references.
- My Health Record Data Breach Notification Procedure: this register is usually the first document checked when assessing who could have been involved in a My Health Record incident.
- Healthcare privacy and cyber security: how Rule 42 fits the wider privacy picture.
Frequently asked questions
Is a separate access register actually required by Rule 42?
Rule 42 requires the Security and Access Policy to address authorisation, review and removal of access, and both the OAIC's guidance and its published assessments of registered organisations point to a maintained register as the practical way an organisation demonstrates it is doing that. A policy that describes a process nobody can produce evidence of is not enough if the System Operator or the OAIC asks to see it in action.
What is HPI-I and do we need it for every row?
The Healthcare Provider Identifier – Individual is the unique number assigned to a registered healthcare provider under the Healthcare Identifiers Act. Record it for anyone who holds one. Non-clinical staff, such as reception or administrative users with system access, may not hold an HPI-I, in which case leave that column blank rather than leaving the row out of the register altogether.
How often should access be reviewed?
Your Security and Access Policy sets the cadence, and quarterly or six-monthly is common in general practice. Whatever the interval, this register's periodic review column is where that review is evidenced, with a date and an outcome, even in reviews where no access changes.
What happens if we find someone on the register whose access was never removed?
Remove their access immediately, record the removal date and reason in the register, and treat the gap as a finding for your next Security and Access Policy review, not just a register correction. If there is any indication the account was used after it should have been removed, assess it against the Data Breach Notification Procedure.
Can this register live inside our clinical software instead of a separate document?
Yes. The template is a starting structure, not a mandated format. What matters is that the same fields, who, when authorised, training status, review history, and removal date, exist somewhere current and are actually checked at each access review, whether that is a Word table, a spreadsheet, or a module inside your practice management system.
Do locums and students go on this register?
Yes, for the period they hold authorised access. Their authorisation date, training completion and removal date matter as much as a permanent staff member's, and a locum whose access was never formally removed after their placement ended is one of the most common gaps found in a Rule 42 review.