My Health Records Rules 2026

EXPLANATORY STATEMENT

My Health Records Act 2012

My Health Records Rules 2026

Purpose and operation

The My Health Records Act 2012 (the Act) provides for the establishment and operation of the My Health Record (MHR) system to provide healthcare recipients and their healthcare providers with access to their key health information online where and when they need it.

Section 109 of the Act provides that the Minister may make Rules, known as My Health Records Rules, about matters that are required or permitted by the Act to be dealt with in the My Health Records Rules.

The My Health Records Rule 2016 will be repealed and replaced with the My Health Records Rules 2026 (the 2026 Rules). The 2026 Rules update and consolidate key regulatory requirements underpinning the MHR system and reflect current policies and system requirements.

The 2026 Rules maintain the key policy settings of the My Health Records Rule 2016 and support the secure operation of the system by prescribing rules that relate to:

• the minimum access control mechanisms that the System Operator must put in place to allow individuals to manage their My Health Record;
• the requirements that must be met by healthcare provider organisations, contracted service providers, repository operators and portal operators to be eligible to register and remain registered with the MHR system, including obligations to support the security and integrity of the system;
• identity verification matters;
• the circumstances which trigger suspension or cancellation of access to a healthcare recipient’s My Health Record;
• the continued application of the opt-out model to all healthcare recipients.

This instrument repeals the My Health Records (Assisted Registration) Rule 2015 (Assisted Registration Rule) as it is not required given the underlying policy intent is achieved through the Act. The provision for healthcare recipients to apply for registration under section 6 of Schedule 1 to the Act, by using the approved form and including any information or documents required by the form, provides authority for an application process whereby healthcare provider organisations may assist individuals with My Health Record registration, making a separate rule unnecessary. As such, the Assisted Registration Rule will be repealed. This will not impact existing policy settings or operational practices.

The My Health Records (Opt-out Trials) Rule 2016 (Opt-out Rule) is no longer required and is also repealed by this instrument. It served a time limited purpose in supporting the national transition from an opt-in model to an opt-out approach for the MHR system. The Opt-out Rule facilitated trial arrangements and enabled the phased evaluation and rollout of the opt-out approach. With the national opt-out model now fully implemented, the trial specific provisions have no ongoing operational or regulatory function, supporting repeal.

The My Health Records (National Application) Rules 2017 (National Application Rules) also will be repealed by this instrument. The National Application Rules enabled the national implementation of the MHR system’s opt-out model under Schedule 1 to the Act. While it is necessary to retain provision for the opt-out model to apply to all healthcare recipients, this is provided for in the 2026 Rules. Accordingly, a standalone instrument is no longer required.

Background

The Act provides for the establishment and operation of the national MHR system, to provide access to key health information relating to individuals’ healthcare.

Healthcare identifiers, assigned under the Healthcare Identifiers Act 2010 (HID Act), provide a key foundation of the MHR system. Under the HID Act, the Healthcare Identifiers (HI) service operator assigns unique healthcare identifiers to consumers, individual healthcare providers and healthcare provider organisations so that health information can be accurately matched with those consumers and providers. A healthcare identifier is a key prerequisite for consumers to be registered for a My Health Record and for providers to access the MHR system. The 2026 Rules provide for numerous matters to support the exchange of information between the HI service operator and the MHR System Operator for the purposes of operating the MHR system.

The Act also provides for the Rules to specify matters to promote the effective administration of the MHR system. This instrument prescribes a number of matters to support trust and transparency in the MHR system and to promote the security and integrity of the system.

Authority

Section 109 of the Act provides that the Minister may make rules, by legislative instrument, on matters that the Act requires or permits to be addressed in the My Health Records Rules. Specific rule-making powers are detailed further in Attachment A.

Reliance on subsection 33(3) of the Acts Interpretation Act 1901

Subsection 33(3) of the Acts Interpretation Act 1901 provides that where an Act confers a power to make, grant or issue any instrument of a legislative or administrative character (including rules, regulations or by-laws), the power shall be construed as including a power exercisable in the like manner and subject to the like conditions (if any) to repeal, rescind, revoke, amend, or vary any such instrument.

Commencement

This instrument commences on 1 April 2026.

Consultation

A public consultation process occurred in August 2025 to inform the review of legislative instruments made under the Act, including the 2016 Rule. States and territories were consulted through various working groups and committees. The Australian Digital Health Agency and Services Australia were consulted on an ongoing basis throughout this review.

Consultation confirmed general agreement that most provisions in the 2016 Rule should be remade.

General

The instrument is a legislative instrument for the purposes of the Legislation Act 2003.

Details of the instrument are set out in Attachment A.

This instrument is compatible with the human rights and freedoms recognised or declared under section 3 of the Human Rights (Parliamentary Scrutiny) Act 2011. A full statement of compatibility is set out in Attachment B.

ATTACHMENT A

Details of the My Health Records Rules 2026

PART 1—PRELIMINARY

Section 1 – Name

This section provides that the title of the instrument is the My Health Records Rules 2026. In this document the instrument is referred to as “the Rules”.

Section 2 – Commencement

This section provides that the instrument commences on 1 April 2026.

Section 3 – Authority

This section provides that the instrument is made under the My Health Records Act 2012.

Section 4 – Schedules

This section provides that each instrument that is specified in a Schedule to this instrument is amended or repealed as set out in the applicable items in the Schedule.

There is one Schedule that repeals the following instruments:

• My Health Records (Assisted Registration) Rule 2015
• My Health Records (National Application) Rules 2017
• My Health Records (Opt-out Trials) Rule 2016
• My Health Records Rule 2016

Section 5 – Definitions

This section defines terms that are used in the Rules.

Specifically, Act means the My Health Records Act 2012 and healthcare identifier has the same meaning as in the Healthcare Identifiers Act 2010.

The term health information in this instrument has the same meaning as the definition in the Privacy Act 1988 (Privacy Act).

The note to this section clarifies that a number of terms used in the instrument are defined in the MHR Act, including access control mechanisms, My Health Record, participant in the MHR system and record.

The table below provides a summary of defined terms used in the instrument:

Section 6 – Definition of authorised representative of a healthcare recipient—persons to which healthcare identifier not required to have been assigned

Under paragraph 6(6) of the Act, a person cannot be the authorised representative of a healthcare recipient unless the person has been assigned a healthcare identifier under paragraph 9(1)(b) of the HID Act, or the Rules provide that a healthcare identifier is not required to have been assigned.

This section of the Rules applies so that a person who is a professional representative of a healthcare recipient, may be an authorised representative of the recipient, even if they have not been assigned a healthcare identifier.

Section 7 – Definition of nominated representative of a healthcare recipient—persons to which healthcare identifier not required to have been assigned

Under subsection 7(3) of the Act, a nominated representative of a healthcare recipient must not be permitted to set access controls in relation to the healthcare recipient’s My Health Record, unless the nominated representative has been assigned a healthcare identifier under paragraph 9(1)(b) of the HID Act or the Rules provide that a healthcare identifier is not required to have been assigned.

This section of the Rules applies so that a nominated representative may set access controls, even if the person has not been assigned a healthcare identifier, in circumstances where the person is a professional representative of that healthcare recipient.

Part 2—THE SYSTEM OPERATOR AND THE FUNCTIONS OF THE CHIEF EXECUTIVE MEDICARE

Division 1—Functions of the System Operator—requirements for access control mechanisms

Section 8 – Access controls set by registered healthcare recipients for access by healthcare provider organisations and nominated representatives

Subsection 15(b) of the Act provides that one of the functions of the System Operator is to establish and maintain access control mechanisms, subject to any requirements set out in the Rules, that allow a healthcare recipient to determine which healthcare provider organisations and nominated representatives may access their My Health Record, including specific records within that My Health Record.

In this context, access control refers to the mechanisms that govern who can view or use information in a healthcare recipient’s My Health Record. These mechanisms give the healthcare recipient the ability to set preferences and restrictions, such as permitting or limiting access for particular healthcare provider organisations or nominated representatives, and to apply those controls to their My Health Record as a whole or to specific documents within it. Access controls ensure that access to a person’s health information is consistent with their instructions and privacy preferences.

Section 8 of the Rules provides for the minimum requirements which must be made available by the System Operator, to allow a healthcare recipient to manage access to their My Health Record and the information contained within it.

Subsection 8(2) of the Rules provides that default access controls must apply where a healthcare recipient has not set any of the access controls provided for in section 8. The default access controls which are to apply are specified in section 9 of the Rules.

Subsection 8(3) applies so that there must be access control mechanisms which allow a healthcare recipient to restrict access to their entire My Health Record. There must also be an ability for the healthcare recipient to lift that restriction, or grant access to their My Health Record, on a particular occasion.

For example, a healthcare recipient may choose to restrict all healthcare provider organisations from accessing their My Health Record. If they subsequently attend a general practice clinic and wish the general practitioner to view their record, the System Operator must support a mechanism that enables the restriction to be lifted; that is, for access to be granted on that occasion. Under the 2016 MHR Rule, there was provision for access codes to be applied to restrict access. A healthcare recipient could disclose the code to a healthcare provider to enable that provider to obtain access, which would result in the healthcare provider organisation being added to the healthcare recipient’s access list. If the healthcare recipient intended the approval to be single‑use, they must re‑apply the restriction afterwards. The 2016 MHR Rule had also provided that organisations were not permitted to retain access codes, which respected that a healthcare recipient may grant access, but then choose to again restrict access for the provider.

Subsection 8(3) of the Rules continues to enable the use of codes as record‑access mechanisms. However, it provides flexibility for the System Operator to adopt alternative technical solutions that support the same policy intent. For example, future system changes may allow for one‑time permission to access a healthcare recipient’s My Health Record, such as through a single‑use token or similar mechanism without requiring the healthcare recipient to manually reinstate restrictions.

While the Rules do not include the requirement from the 2016 MHR Rules which prevented the retention of access codes, this approach will continue as an administrative measure, to support the policy intent that a healthcare recipient may grant one-off access and then reapply a restriction, until alternative one‑time or temporary access mechanisms are available.

Subsection 8(4) applies so that there must be access control mechanisms which allow a healthcare recipient to restrict access to certain information in their My Health Record. In this context, “certain information” does not extend to demographic information or to specific information contained within a particular document or individual record. There must also be an ability for the healthcare recipient to lift that restriction on a particular occasion. As with subsection 8(3), this updates the provisions which applied under the 2016 MHR Rule, replacing the requirement for access codes with a more flexible provision which will allow the System Operator to adopt different approaches to delivery of this functionality.

Subsection 8(5) applies to prevent healthcare providers from being able to see that information exists in My Health Record where the healthcare recipient has restricted access to that information. The exceptions to this are where the organisation is on the access list and the recipient has specified that the organisation may access the particular information or where the recipient lifts the restriction on a particular, or one-off, occasion.

There is also an exception which applies, so that if the organisation uploaded the information to My Health Record, it will be able to see the information. Subsection 8(6) affirms that this should occur without the need for the healthcare recipient to lift the restriction, or grant access, on a particular occasion.

The MHR system also provides for healthcare recipients to nominate to receive alerts when certain things occur. Subsection 8(7) provides that at a minimum, the System Operator must allow a healthcare recipient to be alerted when an organisation first accesses their My Health Record or accesses their My Health Record in case of an emergency or serious threat, as provided for under section 64 of the Act. The healthcare recipient must also be able to nominate to receive alerts if a nominated representative of the recipient views health information in their My Health Record.

Section 9 – Default access controls

Unless a healthcare recipient sets access controls to restrict access to their My Health Record, default access controls will apply. These operate so that registered healthcare provider organisations involved in a person’s care can view clinical information in the record, but access is logged and subject to the strict legislative requirements under the Act.

Under section 9 of the Rules, by default, a registered healthcare provider organisation providing healthcare to a healthcare recipient will be able to access the recipient’s My Health Record.

Under paragraph 9(2)(b) there will be an access list of all healthcare provider organisations permitted to access a healthcare recipient’s My Health Record. Paragraph 9(2)(c) provides that a healthcare recipient must be able to view the access list, which will show them which providers have access to their My Health Record. By default, a healthcare provider organisation who has not accessed the recipient’s My Health Record for a period of three years, will be removed from the access list, according to paragraph 9(2)(d). This ensures the currency of providers with access, so that only those healthcare provider organisations involved in the provision of care to the healthcare recipient retain access to their My Health Record.

Paragraph 9(2)(e) ensures the quality of information in the My Health Record, so that even if a healthcare provider organisation is no longer on the access list for a healthcare recipient, if the organisation had uploaded information to the recipient’s My Health Record, it may access that information, by request to the System Operator.

Subsection 9(3) requires that a healthcare recipient must be able to delete health information or a record in their My Health Record.

For the purposes of this instrument, deleting health information does not involve its permanent removal or destruction. Rather, the information is archived and no longer accessible, such that healthcare recipients and healthcare providers can no longer view it or reinstate access on a particular occasion, including in emergency situations. The System Operator will continue to have access to the deleted information for auditing, maintaining referential integrity, and other authorised purposes.

Section 10 – Circumstances for automatic suspension of access to a healthcare recipient’s My Health Record

This section details circumstances for automatic suspension of access to a healthcare recipient’s My Health Record. Access is to be suspended when the System Operator is advised that a healthcare recipient has died, when a person’s authorisation to act as a representative ceases, or while the System Operator investigates whether a person is eligible to be a representative. The Rules also require suspension where there is a serious risk to the healthcare recipient, ensuring that access is paused while safety concerns are assessed. The table in subsection 10(2) sets out circumstances for automatic suspension of access for specified entities. 

Under item 1 of the table, if the System Operator is notified by the HI Service Operator that an authorised representative of the healthcare recipient has died, access to the healthcare recipient’s My Health Record is automatically suspended for the authorised representative and any nominated representatives that had been nominated by that authorised representative, unless the authorised representative was a professional representative.

If the authorised representative was a professional representative, and there is another professional representative employed by the same employer as the authorised representative who has died, then the nominated representatives who had been nominated by the former authorised representative will not have access suspended.

Item 2 of the table similarly provides for suspension of access to a healthcare recipient’s My Health Record for a nominated representative where the System Operator is notified by the HI Service Operator that the representative is deceased, but prior to formal notice of death.

Note the corresponding provisions under section 11, which apply so that an authorised or nominated representative’s access will be cancelled once formal notice of death is received. Section 10 allows the System Operator to suspend access pending that formal notification. In this case, the HI Service Operator will notify the System Operator that the healthcare identifier of the representative has been retired, which occurs on formal notice of death. This aligns with subsection 51(6) of the Act which provides for cancellation of the registration of a healthcare recipient if the System Operator is satisfied that the healthcare recipient has died.

Under items 3 and 5 of subsection 10(2), if the System Operator receives information which prompts an investigation into whether a person remains a nominated representative for a healthcare recipient, and/or whether the nominated representative’s access should be cancelled, for example because there is evidence the recipient may not have consented to the nomination, then the System Operator must suspend access for the person for the period of the investigation.

There is similar provision in items 4 and 6 of the table for suspension of access for an authorised representative, and any nominated representative of the healthcare recipient who had been nominated by that authorised representative, if the System Operator is investigating whether to cancel the authorised representative’s access or is notified that the person may not meet the requirements under the Act to be an authorised representative.

Note the corresponding provisions under section 11 of the Rules, which provide for cancellation of an authorised or nominated representative’s access where the System Operator is satisfied that the person is no longer a representative of the healthcare recipient.

Items 7 and 8 of subsection 10(2) provide for suspension of access for authorised or nominated representatives where the System Operator is notified that continuing access to a healthcare recipient’s My Health Record poses or may pose a serious risk to an individual’s life, health or safety. This might include a risk to the healthcare recipient themselves, or another person, such as the parent or carer of a healthcare recipient.

Section 11 – Circumstances for automatic cancellation of access to a healthcare recipient’s My Health Record

This section details circumstances for automatic cancellation of access to a healthcare recipient’s My Health Record. Access is automatically cancelled when a healthcare recipient takes control of their own record, ending any previously authorised representative’s access, if access had not already been cancelled. The Rules also provide for cancellation where a person’s authority to act as a representative has ceased, ensuring that only individuals with a current and lawful basis for acting on behalf of the healthcare recipient retain access. These provisions help maintain the integrity of the MHR system by ensuring access aligns with current legal and personal authorisations.

Circumstances for automatic cancellation are summarised below.

Retirement of healthcare identifier (HI) or death

• Access is cancelled when an authorised representative’s healthcare identifier (HI) is retired, usually following formal notification of death. Nominated representatives appointed by an authorised representative also lose access unless continuity applies for professional representatives.
• A nominated representative’s access is cancelled immediately once their HI is retired.
• Access is cancelled once the System Operator is notified of the death of a nominated representative.

Changes affecting authorised representatives

• Access is cancelled when a person ceases to be the authorised representative of a child under 14 and will not meet the requirements to act as an authorised representative when the child turns 18. Any nominated representatives appointed by that person also lose access. Effectively, if the System Operator is satisfied that an individual will continue to be eligible to be the authorised representative for a healthcare recipient after the recipient turns 18, for example because the healthcare recipient has impaired capacity, then the System Operator may continue access for that individual. Otherwise, access is cancelled, as a healthcare recipient is able to take control of their own My Health Record from the age of 14.
• Access is cancelled when a healthcare recipient turns 18, and the authorised representative does not meet requirements under subsection 6(4) of the Act. Any nominated representatives appointed by that person also lose access. Effectively, this means that where an individual was an authorised representative for a healthcare recipient between the age of 14-17 years, the individual will no longer be an authorised representative when the healthcare recipient becomes an adult. The exception is where the healthcare recipient is not capable of making decisions for himself or herself, then access may continue. From the age of 18, if a healthcare recipient wishes an individual to continue to have access to their My Health Record (such as for a parent), the healthcare recipient may nominate the individual to be a nominated representative.
• Access ceases when a healthcare recipient aged between 14-17 withdraws the authorised representative nomination or turns 18. Any nominated representatives appointed by that person also lose access. 
• Access ceases when the System Operator is no longer satisfied that an individual meets the requirements under the Act to be an authorised representative or if the authorised representative advises that they no longer wish to act as a representative of a healthcare recipient. Any nominated representatives appointed by that representative also lose access unless continuity applies for professional representatives.
• Access is cancelled when a person is no longer an authorised representative for any unlisted reason. This ensures access only continues where authority is current.

Changes affecting nominated representatives

• Access is cancelled when the nominated representative withdraws their consent to act as a representative.
• Access is cancelled when a person is no longer a nominated representative for any reason not otherwise listed.

Division 2 — Functions of the System Operator—other functions conferred by this instrument

Section 12 – Purpose of this Division

This Division confers other functions on the System Operator as provided for under subsection 15(n) of the Act. In the Act, references to “this Act” include the regulations made under the Act, and the My Health Records Rules.

Section 13 – Deleting information or a record in the My Health Record system in certain circumstances

Section 13 operates to ensure that harmful, unsafe or incorrect information is contained to protect individuals and maintain the safety and integrity of the MHR system.

The section provides for information or a record to be deleted, or removed, from the My MHR system if the System Operator is satisfied of certain circumstances. Where the System Operator is so satisfied, the System Operator may delete the information or direct another participant in the MHR system to delete the information. Note the corresponding requirements under sections 35, 47 and 57 of the Rules for relevant participants to comply with such a direction given by the System Operator.

The circumstances that could result in information being deleted under this section include that the information or record contains a defamatory statement under paragraph 13(a) or affects or may affect the security or integrity of the MHR system under paragraph 13(b).

Other circumstances include, under subsection 13(c), where the System Operator is satisfied that information or a record should be deleted to reduce the clinical risk that may be posed to a healthcare recipient if the information is not removed, where the information or record had been uploaded contrary to the requirements specified in paragraph 45(ba) of the Act. This paragraph provides that certain records should only be uploaded to My Health Record if the record had been prepared by a person with registration or credentials that are not conditional, suspended, cancelled or lapsed, other than in circumstances prescribed in the Rules. In other words, the person preparing the information must have up-to-date registration or credentials to practice their particular health profession.

Note that this operates together with section 24 of these Rules. Section 24 applies so that information may be uploaded where the person preparing the document did not have current registration or credentials to practice their particular health profession, but that was only because fees to maintain their registration or credentials were overdue by less than 6 months.

The combined effect of these provisions is that the System Operator may act to remove information from the MHR system if there is a clinical risk to a person due to information having been prepared by someone who did not have the required credentials to practice their health profession at the time the document was prepared. For example, if a healthcare provider organisation uploads a document authored by an individual healthcare provider (e.g. a general practitioner or registered nurse) whose registration has been suspended in response to allegations of misconduct; the System Operator may remove that document where such action is necessary to minimise clinical risk to the healthcare recipient.

Section 14 – Suspending access to the My Health Record system if security, integrity or operations are or may be compromised

This section provides that the System Operator may suspend access to the MHR system where the security, integrity or operation of the system has been, or may be, compromised. This may include suspending access for healthcare recipients, their authorised or nominated representatives, or other system participants.

Subsection 14(2) provides examples of the situations that may warrant suspension of access, including where there are security issues with a participant’s IT systems or login credentials, where there are difficulties verifying identity, or where a participant has failed to meet the required technical standards and interoperability requirements. These examples are indicative of the types of reasons that may result in suspension of access, and do not limit the System Operator’s discretion to suspend where it is considered that the security, integrity or operations of the MHR system may be compromised.

Subject to the exceptions in subsections 14(6) and (7), subsections 14(4) and (5) apply to require the System Operator to provide written notice to an entity whose access has been suspended as soon as practical after the suspension occurs. The notice must include the reasons for the suspension and, if relevant, detail what the entity must do in order to have their access restored.  

Subsection 14(6) provides for circumstances when notice of suspension is not required; that is where the suspension of access relates to minor operational matters and is unlikely to last more than 24 hours.

Subsection 14(7) applies so that notice to an entity whose access has been suspended is not required if the suspension affects a significant number of healthcare recipients and is more appropriately communicated through a public notice (e.g. media release).

Subsection 14(8) applies so that once the System Operator is satisfied that the risk has been resolved, access to the MHR system must be restored.

Section 15 – Providing a mechanism to access My Health Record system

This section applies so that the System Operator may establish a secure way for registered healthcare provider organisations to access the My Health Record system. In 2026, the National Provider Portal (NPP) served as this mechanism. The NPP was previously provided for in the MHR Rule 2016. The NPP provides a web‑based interface that allows authorised healthcare providers to view a patient’s My Health Record without needing a fully integrated clinical information system. This section will support alternative mechanisms for healthcare providers to access the My Health Record system, should other options be developed in future.

Part 3—REGISTRATION

Division 1—Registering healthcare recipients

Section 16 – Matters System Operator to have regard to

Section 40 of the Act and sections 3 and 6 of Schedule 1 to the Act provide for the registration of healthcare recipients for a My Health Record. Those provisions require, among other things, that the System Operator be satisfied that the identity of the healthcare recipient have been appropriately verified in order to register a healthcare recipient for a My Health Record. The Rules may provide for matters that the System Operator must have regard to in determining whether the identity of the healthcare recipient has been appropriately verified.

Section 16 of the Rules provides for the following matters the System Operator must have regard to:

1.    if the healthcare recipient is a child, whether:
   1.             the birth mother of the recipient has a healthcare identifier; and
   2.             the HI Service Operator has evidence confirming the identity of the birth mother
2.    otherwise, whether:
   1.             the healthcare recipient has a healthcare identifier; and
   2.             the HI Service Operator has evidence confirming the identity of the recipient.

Paragraph 16(b) applies so that in addition to the requirement for a healthcare recipient to have been assigned an individual healthcare identifier in order to be eligible for My Health Record registration, the HI Service Operator must have evidence confirming the identity of the recipient, such as a birth certificate, Medicare card, or other relevant identifying documentation. This confirmation avoids the creation of duplicate records. The relevant identification documents are not provided to the System Operator. The System Operator relies on the verification by the HI Service Operator.

Paragraph 16(a) provides an alternative option when registering a child for a My Health Record. In practice, for many newborn children, evidence confirming their identity is provided as part of Medicare registration, when proof of birth and other information may be provided, triggering automatic assignment of a healthcare identifier for a child, pursuant to the HID Act. Under the 2016 MHR Rule, effectively, a My Health Record could not be created for a child until this process occurred (or another application triggered registration). Section 16 will support earlier creation of a My Health Record, with the support of the birth mother, where the mother’s details are able to be connected with the child’s for the purposes of assigning a healthcare identifier. To avoid duplicate healthcare identifiers or My Health Records, this would only occur where the child’s record was connected to the birth mother, who also had a healthcare identifier with verified evidence of identity. This would support the accurate matching of records when evidence confirming the identity of the child, such as their birth certificate, was received at a later time.

This provision enables earlier capture of clinical information for newborns across maternity, neonatal and hospital discharge workflows, aligns with existing Medicare and HI Service processes that already verify birth mothers and collect proof‑of‑birth information, and reduces delays between birth, assignment of an individual healthcare identifier and availability of a My Health Record. It also maintains strong identity governance by allowing early record creation only where the child can be reliably linked to a verified parent and supports continuity of identity assurance as later documents strengthen the child’s identity without creating duplicate records.

A current example relates to newborns who require urgent medical intervention immediately after birth. In these circumstances, essential clinical information must be accessible to treating clinicians without delay, and a My Health Record may be manually created to support this. For instance, Services Australia currently manually registers newborns diagnosed with Spinal Muscular Atrophy (SMA), where diagnosis is typically made in utero through genetic screening. Effective treatment must be administered within the first week of life, and failure to do so significantly reduces the child’s life expectancy. This process involves a coordinated effort between jurisdictions and Services Australia to ensure timely access to lifesaving therapies. Manual record creation in these cases is generally informed by file notes associated with the mother’s Medicare record, enabling rapid establishment of the newborn’s My Health Record to support sharing of key information to their record about any immediate clinical action taken.

Section 16 intentionally does not prescribe operational processes for identity verification, as identity verification continues to be carried out under existing HI Service operational policies and Services Australia’s evidence‑based identity verification frameworks, which include document checks, Medicare enrolment matching, and identity‑proofing and retention processes. Section 16 specifies only what must be verified, not how, deliberately allowing flexibility for ongoing HI Service modernisation, alignment with broader Commonwealth identity‑management frameworks, and future digital identity capabilities such as interoperable identity services, parent or guardian linkages, and birth‑registration integration.

This approach is consistent with the HID Act, particularly sections 12-15 of that Act relating to the collection and use of identifying information to assign or confirm an individual healthcare identifier without mandating any prescribed verification method, and subsection 7(3) which defines what identifying information may be collected while leaving the method of verification to operational policy.

Division 2—Registering healthcare provider organisations

Subdivision A—When organisations are eligible for registration—requirements organisations must comply with

Section 17 – Purpose of this Subdivision

This section explains that Subdivision A of Division 2 specifies requirements that a healthcare provider organisation must comply with to be eligible for registration.

Section 18 – Organisation officers must have authority to act on behalf of organisation

For the purposes of the Rules, the definitions of responsible officer, organisation maintenance officer, network and network organisation are as defined in the HID Act.

Section 18 provides for certain people who must be authorised to act on behalf of an organisation in relation to its engagement with the System Operator.

For an organisation that is a seed organisation for a network, or an organisation that is not part of a network, the following persons must be authorised:

• the responsible officer for the organisation, and
• the organisation maintenance officer for the organisation.

For an organisation that is a network organisation within a network, the following persons must be authorised:

• the responsible officer for the organisation, 
• the organisation maintenance officer for the organisation; and
• the organisation maintenance officer for the seed organisation for the network.

This ensures the System Operator can verify the identity of the people with whom it is dealing and that those officers are duly authorised representatives. It is the responsibility of the healthcare provider organisation to ensure that the necessary authorities are in place so that the organisation can comply with this requirement.

Section 19 – Organisation must give System Operator and service operator certain information

This section requires that organisations must give the System Operator a list of all individual healthcare providers who will be authorised to access the MHR system through a mechanism provided by the System Operator, via or on behalf of the organisation. In 2026 the National Provider Portal was this mechanism.

Further, paragraph 19(1)(b) requires a seed organisation for a network to provide a record of the linkages between healthcare provider organisations within the network.

Both the list and the network linkage record must be provided in the approved form.

Section 20 – Organisations that are network organisations —seed organisation for network must be a registered healthcare provider organisation

Section 20 applies to healthcare provider organisations that are a network organisation within a network. It requires the seed organisation for the network to be a registered healthcare provider organisation.  

This section applies so that a network organisation may only be registered for the MHR system, if the seed organisation for the network is also registered.

There is a corresponding requirement in section 42 that requires the seed organisation to remain registered in order for the network organisation to also remain eligible.

Section 21 – Organisation must have security and access policy

This section requires healthcare provider organisations to have a written security and access policy that covers, at a minimum, the matters outlined in subsection 21(2). The policy must also be drafted so that it is possible to assess the organisation’s compliance with the policy.

The purpose of requiring organisations to have a security and access policy is to ensure organisations consider and implement appropriate practices to protect My Health Record information, such as ensuring that only authorised people can access it; users are trained in the use of the system and associated obligations to ensure information is handled lawfully; security controls are in place; and that risks or incidents are able to be identified and addressed quickly.

Subsection 21(2) sets out the minimum requirements that must be addressed by an organisation’s security and access policy. These include:

• User Authorisation: Describe how staff are authorised to access the MHR system and how accounts are created, modified, suspended, or deactivated. The policy must also provide for the removal of a user’s access in particular circumstances, including when:

• the user leaves the organisation
• the user’s security is compromised
• the user’s duties no longer require access, or
• the user is an individual healthcare provider who ceases to be linked to the organisation.

• Mandatory Training: Explain the training requirements that apply before a user is granted access to My Health Record. Subsection 21(3) provides that training must cover responsible system use, legal obligations of healthcare provider organisations and users, and the consequences of breaching those obligations. In addition to training ahead of granting access, there is a requirement for ongoing training annually, and following any significant changes to My Health Records legislation or the system, to ensure users remain aware of how to use the system and their ongoing obligations. Note – where a user completes training with another provider, this may be sufficient to meet the training requirements in this section. The onus would be on each organisation to determine whether training undertaken with another entity is appropriate and sufficient, having regard individual business risks, and to keep relevant records evidencing that the relevant training requirements under this section have been satisfied.
• Compliance with verification requirements: The organisation must have processes to ensure section 74 of the Act will be complied with. Section 74 requires that individuals who request access to a healthcare recipient’s My Health Record on behalf of the organisation, must provide enough information so that the System Operator can identify the individual making the request without having to seek further information from another person.
• Management of data breaches: The security and access policy must detail the processes to be applied to ensure compliance with section 75 of the Act. Section 75 applies where a healthcare provider organisation that is, or has ever been, registered with the MHR system becomes aware of an event or circumstances involving the organisation related to unauthorised access to, or risk to the security or integrity of, the MHR system. Under section 75 there are obligations to notify of the circumstances and take reasonable steps to respond to the issue.
• Security Measures: Outline the organisation’s physical security, information security and cybersecurity controls and technical and organisational measures, including user account practices; system maintenance and data protection requirements; and processes for monitoring and review of those controls. Subsection 21(4) provides further detailed requirements in relation to the user account practices required by organisations.
• Managing Security Risks: Describe the strategies to manage security risks related to the MHR system, including processes to promptly identify, respond to, and report on risks.

Section 22 – Organisation must give System Operator security and access policy on request

This section requires a registered healthcare provider organisation to provide the System Operator with a copy of its security and access policy if requested by the System Operator.

The System Operator may consider evidence that provides reasonable assurance that key controls described in the policy are in place and operating; demonstrating an entity’s cyber security maturity, risk management practices and control effectiveness to ensure the confidentiality, integrity and availability of the MHR system.

The System Operator will provide reasonable time for the entity to produce the requested information. If the organisation fails to do so, the System Operator may determine that the organisation is not eligible to be registered.

Subdivision B—Condition of registration—uploading of records, etc

Section 23 – Kinds of records

Paragraph 45(b)(ii) of the Act applies to prevent certain records from being uploaded by a registered healthcare provider organisation, unless the record has been prepared by an individual healthcare provider who has been assigned a healthcare identifier (identified individual healthcare provider). That paragraph provides for the Rules to specify the types of records to which this obligation applies.

Section 23 of the Rules applies so that all records must be prepared by an identified individual healthcare provider except for advance care planning information, which is defined in section 5 of the Rules, and shared health summaries, which are subject to specific requirements set out in the Act.

Section 24 – Prescribed circumstances

This section is made under section 45 of the Act, and operates together with sections 13 and 23 of these Rules.

Under section 45 of the Act, a registered healthcare provider organisation may only upload certain records to My Health Record if the record has been prepared by an identified individual healthcare provider and where that provider’s registration or credentials are not conditional, suspended, cancelled or lapsed, other than where provided for in the rules. In other words, section 45 of the Act requires the healthcare provider who authors a record to have current registration or credentials to practice their particular health profession. If not current, unless an exception provided for in the rules applies, the record must not be uploaded to My Health Record.

This section applies so that a record may be uploaded where the healthcare provider’s registration or credentials are not current, where that is due to non-payment of fees required to maintain their registration or credentials. The fees must not be overdue by more than 6 months.

While short arrears for registration or credentials are seen as low risk and not sufficient to prevent records authored by those providers from being uploaded to My Health Record, inclusion of documents by providers with continued failure to maintain registration or credentials may present a risk to the trust in and integrity of the MHR system.

Division 3—Registering repository operators and portal operators

Section 25 – Purpose of this Division

Division 3 is made for the purposes of paragraphs 48(a) and 109(3)(b) of the Act. This section specifies the requirements that repository operators and portal operators must comply with to be eligible for My Health Record registration.

Section 26 – Person must have an operator officer

Under this section, repository operators and portal operators are required to have at least one and no more than three operator officers to be eligible for registration.

The role of the operator officer is set out in this section. They must be responsible for receiving communications from the System Operator and acting as the main contact between the System Operator and the operator. They must also keep the System Operator updated with the current professional and business details of both the operator and the operator officer.

Section 27 – Person must have security and access policy

This section requires repository operators and portal operators to have a written security and access policy that covers, at a minimum, the matters outlined in subsection 27(2). The policy must also be drafted so that it is possible to assess the entity’s compliance with the policy.

The purpose of requiring repository and portal operators to have a security and access policy is to ensure entities consider and implement appropriate practices to protect My Health Record information, such as ensuring that only authorised people can access it; users are trained in the use of the MHR system and associated obligations to ensure information is handled lawfully; security controls are in place; and that risks or incidents are able to be identified and addressed quickly.

Subsection 27(2) sets out the minimum requirements that must be addressed by an operator’s security and access policy.

Section 28 – Person must give security and access policy to System Operator with application for registration

This section requires an applicant to provide the System Operator with a copy of their security and access policy when applying to be registered as a repository operator or portal operator.

The System Operator may consider evidence that provides reasonable assurance that key controls described in the policy are in place; demonstrating an entity’s cyber security maturity, risk management practices and control effectiveness to ensure the confidentiality, integrity and availability of the MHR system.

While the System Operator would not endorse the policy, the review requirement supports oversight and enables the System Operator to identify security or compliance gaps that may affect the security and integrity of the MHR system.

Section 29 – Person must have technical and after-hours contacts

This section requires operators to maintain appropriate contact arrangements to respond to or resolve issues related to the MHR system.

The section requires a business hours point of contact and technical support, as well as two points of contact with authority to resolve, or coordinate the resolution of, any technical, security or operational issues affecting the operator outside of normal business hours, including on public holidays.

Division 4—Registering contracted service providers

Section 30 – Purpose of this Division

This section provides that Division 4 specifies the requirements that a person must comply with to be eligible for registration as a contracted service provider.

The term “contracted service provider” is defined in the Act. A contracted service provider is an entity that provides information technology services or health information management services relating to the MHR system to a healthcare provider organisation under contract.

Section 31 – Person must have a contracted service provider officer

Section 31 provides that contracted service providers are required to have at least one and no more than three contracted service provider officers to be eligible for registration.

The role of the contracted service provider officer is set out in this section. They must be an employee of the entity seeking registration and be responsible for receiving communications from the System Operator in relation to the MHR system and acting as the main contact between the System Operator and the contracted service provider. They must also keep the System Operator updated with the current professional and business details of both the contracted service provider and the contracted service provider officer.

Section 32 – Person must have security and access policy

This section requires contracted service providers to have a written security and access policy that covers, at a minimum, the matters outlined in subsection 32(2). The policy must also be drafted so that it is possible to assess the entity’s compliance with the policy.

The purpose of requiring contracted service providers to have a security and access policy is to ensure entities consider and implement appropriate practices to protect My Health Record information, such as ensuring that only authorised people can access it; users are trained in the use of the MHR system and associated obligations to ensure information is handled lawfully; security controls are in place; and that risks or incidents are able to be identified and addressed quickly.

Subsection 32(2) sets out the minimum requirements that must be addressed by an operator’s security and access policy.

Section 33 – Person must give security and access policy to System Operator with application for registration

This section requires an applicant to provide the System Operator with a copy of their security and access policy when applying to be registered as a contracted service provider.

The System Operator may consider evidence that provides reasonable assurance that key controls described in the policy are in place; demonstrating an entity’s cyber security maturity, risk management practices and control effectiveness to ensure the confidentiality, integrity and availability of the MHR system.

While the System Operator would not endorse the policy, the review requirement supports oversight and enables the System Operator to identify security or compliance gaps that may affect the security and integrity of the MHR system.

Division 5—Cancellation, suspension and variation of registration

Section 34 – Requirements after registration is cancelled or suspended—retention, transfer or disposal of records

This section applies to a person that is, or has previously been, a registered portal operator or registered repository operator.

It provides obligations for an entity that was an operator, which apply after the entity’s registration as a repository operator or portal operator has been cancelled.

Under subsection 34(2), an entity that was a portal operator, but whose registration has been cancelled, must not retain access to any healthcare recipient’s My Health Record information unless the System Operator has provided written authorisation.

Under subsection 34(3), an entity that was a repository operator, but whose registration has been cancelled, must not transfer or dispose of any information held in relation to a healthcare recipient’s My Health Record without written authorisation from the System Operator.

Part 4—OTHER MATTERS—CONDITIONS ON THE REGISTRATION OF PARTICIPANTS IN THE MY HEALTH RECORD SYSTEM

Division 1—Preliminary

Section 35 – Purpose of this Part

This section provides that Part 4 provides for the conditions of registration which apply to My Health Record participants. The effect of this Part is to provide the requirements that an entity must satisfy to maintain their My Health Record registration.

Consistent with other provisions in the Rules, the conditions are structured to reflect the obligations applicable to different categories of participants.

Unauthorised collection, use or disclosure of My Health Record information, may constitute contraventions of sections 59 and 59A of the Act. These provisions include criminal offences (with penalties of imprisonment and fines) and civil penalties of up to 1,500 penalty units.

There are notification requirements under the Act for participants to advise the System Operator if they are no longer eligible to be registered for My Health Record, including because they cannot meet the conditions of registration. Failure to notify is an offence attracting a civil penalty of up to 1,500 penalty units.

A breach of the obligations under these Rules is also an offence under section 78 of the Act, with a civil penalty of 100 penalty units.

Division 2—Registered healthcare provider organisations

Section 36 – Complying with directions to delete information or a record

This section supports section 13 of the Rules, so that if the System Operator directs a registered healthcare provider organisation to delete information or a record, the organisation must comply with the direction.

Together, these sections help to ensure that inappropriate, unsafe or incorrect information is contained to protect individuals and maintain the safety and integrity of the MHR system.

Section 37 – Uploading records

This section requires healthcare provider organisations to take reasonable steps to ensure that records uploaded to My Health Record by, or via, the organisation are not inaccurate, incorrect, misleading, defamatory or out of date. Subsection 37(2) sets out circumstances where the obligation does not apply.

Subsection 37(3) clarifies that this section does not affect any other obligations of an entity covered by this section related to clinical record-keeping or communication to healthcare recipients.

Section 38 – Notifying System Operator of certain matters

This section provides for a registered healthcare provider organisation to advise the System Operator of certain events. The obligations apply to help maintain the accuracy of information in the MHR system. They also ensure the System Operator is aware of relevant changes for the healthcare provider organisation to support the effective administration of the MHR system.

Subsection 38(2) requires the organisation to provide notice in writing within two business days of the event happening.

Events triggering a notice requirement are as follows:

• Where the organisation becomes aware of a non‑clinical error in information it has accessed or downloaded from the MHR system. A non‑clinical error is a mistake that does not relate to clinical decisions or judgement, such as a file that is corrupted or incomplete. The organisation must explain what the error is.
• Where the organisation undergoes a material change. A material change in relation to a participant in the MHR system is defined in section 5 of the Rules to include a change in the participant’s legal name or structure, or the participant entering into administration, becoming insolvent or being involved in a merger or acquisition. The organisation must describe what has changed.
• If a responsible officer or organisation maintenance officer for the organisation changes, or the contact details for a responsible officer or organisation maintenance officer change, the organisation must tell the System Operator. This would include requirement to notify of the new officer and/or new contact details for the officer. This ensures the System Operator has current information in relation to the individuals authorised to act for the organisation.
• If the organisation engages or ceases to contract with a contracted service provider (CSP). The combined effect of items 5 and 6 in the table in this section is to require the organisation to tell the System Operator if it engages a contracted service provider, or if the contracted service provider for the organisation changes. The organisation must notify the System Operator of the contracted service provider’s name, and ABN and ACN if known, as well as the date the provider commenced or ceased to contract with the organisation. There is a corresponding requirement in Section 60 of the Rules for contracted service providers to notify the System Operator of the healthcare provider organisations they contract with. This ensures the System Operator has awareness of links between contracted service providers and healthcare provider organisations, to support its administration of the MHR system.

Section 39 – Compliance with interoperability requirements

Section 39 requires healthcare provider organisations to comply with the interoperability requirements for the MHR system. Section 5 of these Rules defines interoperability requirements for the MHR system to mean the conformance requirements and standards applicable to that system, published by the Australian Digital Health Agency, as existing from time to time.

Section 40 – Providing assistance to the System Operator on request

This section requires a registered healthcare provider organisation to help the System Operator to respond to issues related to the MHR system. For example, a request for assistance may be in relation to an inquiry, audit, review, investigation, complaint or other matter.

The obligation to promptly assist the System Operator as necessary only applies if the System Operator has provided reasonable notice to the organisation of the assistance required.

Section 41 – Uploading advance care planning information

Under this section, a registered healthcare provider organisation may upload advance care planning information, as defined in section 5 of the Rules, for a healthcare recipient to the MHR system if the person clearly instructs them to do so. If the organisation uploads information on behalf of a healthcare recipient, it must keep a record of the healthcare recipient’s instructions and how those instructions were provided. For example, the organisation must record whether the person gave instructions in writing, verbally, or through a form.

Section 5 defines advance care planning information as a document prepared by, or on behalf of, a healthcare recipient that states the recipient’s expressed wishes about the future provision of healthcare to the recipient. The definition is intended to broadly cover the types of information and documents through which a healthcare recipient can indicate their preferences for future healthcare. Examples of the types of documents that might be uploaded pursuant to this provision include advance care directives, advance care plans or documentation related to a substitute decision maker for the healthcare recipient for health-related purposes.

This does not prevent a healthcare provider organisation from uploading clinical documents, such as clinical care plans, or comprehensive care plans, which document shared decisions made with patients, carers and families in relation to plans for care including the tests, interventions, treatments and other activities to help achieve the goals of care. These plans may be uploaded in the same way as any other clinical document.

Section 42 – Organisations that are network organisations—seed organisation for network must be a registered healthcare provider organisation

This section provides that where a healthcare provider organisation is a network organisation within a network, the seed organisation for the network must also be a registered healthcare provider organisation in order for the network organisation to remain eligible for My Health Record registration.

Section 43 – Security and access policy—general 

This section contains a number of requirements that a registered healthcare provider organisation must follow in relation to their security and access policy. These requirements include:

• communicating and making the policy easily accessible to all employees, contracted healthcare providers and individual healthcare providers linked to the organisation who are accessing the MHR system via or on behalf of the organisation;
• taking all reasonable steps to ensure that the organisation as a whole and entities mentioned in subsection 43(1) comply with the policy;
• keeping the policy up to date, pursuant to the requirements set out in subsection 43(3).

Under subsection 43(4), the organisation must keep each version of the policy for five years from the date it was in place. Section 44 provides that the organisation must also provide to the System Operator a copy of the current policy, or an earlier iteration of the policy, if requested by the System Operator.

The Privacy Act, including the Australian Privacy Principles (APPs), applies to regulated entities that collect, use or disclose personal information in connection with the My Health Record system. In particular, APP 11 requires entities to take reasonable steps to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure.

APP 11 continues to apply to all APP entities under these Rules. The Rules operate alongside the existing obligations in the Privacy Act. APP entities must therefore maintain reasonable technical and organisational measures to protect personal information from misuse, interference, loss, and unauthorised access, modification or disclosure.

Where the Rules prescribe additional safeguards or processes, these are to be read as complementary to APP 11 rather than replacing it. APP entities must also continue to destroy or de‑identify personal information when it is no longer required, unless a statutory retention duty applies.

Section 44 – Security and access policy—giving to System Operator on request

This section requires a registered healthcare provider organisation to provide the System Operator, on request, with a copy of the participant’s security and access policy.

The System Operator may consider evidence that provides reasonable assurance that key controls described in the policy are in place and operating; demonstrating an entity’s cyber security maturity, risk management practices and control effectiveness to ensure the confidentiality, integrity and availability of the MHR system.

While the System Operator would not endorse the policy, the requirement to provide it on request supports oversight and enables the System Operator to identify security or compliance gaps that may affect the security and integrity of the MHR system.

Section 45 – Security and access policy—application record-keeping

A registered healthcare provider organisation must keep records that show how it has applied and met its requirements in relation to the security and access policy requirements set out in Section 21.

Records which evidence that the organisation has satisfied its obligations under paragraphs 21(2)(a) and (b) must be kept for five years. These provisions apply to require the organisation to keep records of the user accounts created, changed, suspended or deactivated, and the training that was provided initially to users before they are granted access to My Health Record, and the ongoing training provided to users to meet the requirements in subparagraphs 21(2)(b)(ii) and (iii).

Records of how the obligations under paragraphs 21(2)(c) and (d) must be kept for two years. Paragraph 21(2)(c) requires an organisation to have processes to ensure it does not contravene sections 74 or 75 of the Act.

Section 74 of the Act requires an organisation to ensure that individuals seeking access to a healthcare recipient’s My Health Record on behalf of the organisation can be identified by the System Operator. Logs showing who accessed the MHR system would satisfy this requirement.

Section 75 of the Act requires an organisation to take certain steps in the event it identifies unauthorised collection, use or disclosure of health information in a healthcare recipient’s My Health Record, or becomes aware of an event or circumstances involving the organisation which impact or potentially impact the security or integrity of the MHR system. The requirements in sections 21 and 43 of the Rules ensure that organisations have clear processes to identify, manage and respond to such scenarios and comply with the requirements of section 75 of the Act. They must also keep records to evidence these processes and any action planned or taken to comply with the section 75 requirements.

Paragraph 21(2)(d) of the Rules requires organisations to set out in their security and access policy, the physical security, information security and cybersecurity, including technical and organisational, measures that will be implemented. The corresponding requirements in paragraph 45(1)(d) are to keep records for two years of how those measures have been implemented. For example, documented application of the user account management practices, system maintenance activities, data protection, encryption and back-up procedures that have been employed and when, should be kept to satisfy this requirement.

The records required by section 45 are intended to provide evidence that an organisation is complying with its obligations under the Rules and are designed to reflect record-keeping data minimisation principles. The requirements to keep evidence for 5 years of the application of paragraphs 21(2)(a) and (b) relate to policy and process-level information. The types of information required to evidence application of the processes and measures required by paragraphs 21(2)(c) and (d) involve more detailed audit-type information and are only required to be kept for 2 years. Relevantly, notifications under section 75 of the Act related to data breaches or unauthorised MHR access must be notified as soon as practicable after becoming aware of the relevant issue.

Under section 46 of the Rules, the System Operator may request a copy of a record required to be kept under section 45.

Section 46 – Security and access policy—giving application records to System Operator on request  

Section 46 provides for the System Operator to make a written request to a healthcare provider organisation for a copy of a record required to be kept under section 45. These are the records which evidence how an organisation is implementing its security and access policy.

If requested, the organisation must provide a copy of the relevant records within 7 days of receipt of the request.

Division 3—Registered repository operators and portal operators  

Section 47 – Application  

This section provides that Division 3 applies to a person who is a registered repository operator or portal operator.

Section 48 – Complying with directions to delete information or a record

This section supports section 13, so that if the System Operator directs a registered repository or portal operator to delete information or a record, the operator must comply with the direction.

Together, these sections help to ensure that inappropriate, unsafe or incorrect information is contained to protect individuals and maintain the safety and integrity of the MHR system.

Section 49 – Ensuring operator officer carries out duties

This section requires a participant to ensure that its operator officers perform the functions required of them under paragraph 26(2)(b).

These obligations are to receive communications about the MHR system, and liaise with the System Operator, on behalf of the operator and to maintain the professional and business details of the operator and the operator officer.

It is not sufficient for a participant merely to appoint operator officers. The participant must actively ensure that those officers carry out their responsibilities competently and in accordance with the requirements of the MHR system.

Section 50 – Notifying System Operator of certain matters

This section sets out the circumstances in which a person must notify the System Operator, and the matters that must be included in that notification. It also requires that the notification be provided in writing within two business days of the relevant circumstance arising, ensuring the System Operator is informed in a timely and consistent manner.

Events triggering a notice requirement are as follows:

• where the operator becomes aware of a non‑clinical error in information that has been accessed or downloaded from the MHR system by the operator or employee of the operator. A non‑clinical error is a mistake that does not relate to clinical decisions or judgement, such as a file that is corrupted or incomplete. The operator must explain what the error is.
• where the operator undergoes a material change. A material change in relation to a participant in the MHR system is defined in section 5 to include a change in the participant’s legal name or structure, or the participant entering into administration, becoming insolvent or being involved in a merger or acquisition. The operator must describe what has changed.
• if an operator officer changes, or the contact details for an operator officer change, the operator must tell the System Operator. This would include requirement to notify of the new officer and/or new contact details for the officer. This ensures the System Operator has current information in relation to the individuals authorised to act for the operator.

Section 51 – Compliance with interoperability requirements

Section 51 requires registered repository and portal operators to comply with the interoperability requirements for the MHR system. Section 5 of these Rules defines interoperability requirements for the MHR system to mean the conformance requirements and standards applicable to that system, published by the Australian Digital Health Agency, as existing from time to time.

Section 52 – Providing assistance to the System Operator on request

This section requires a registered repository or portal operator to help the System Operator to respond to issues related to the MHR system.

The obligation to promptly assist the System Operator as necessary only applies if the System Operator has provided reasonable notice to the operator of the assistance required.

Section 53 – Security and access policy—general

This section contains a number of requirements that registered repository operators and portal operators must follow in relation to their security and access policy. These requirements include:

• communicating and making the policy easily accessible to all employees and users accessing My Health Record via or on behalf of the operator;
• taking all reasonable steps to ensure that the entities mentioned in subsection 53(1) comply with policy;
• keeping the policy up to date, pursuant to the requirements set out in subsection 53(3).

Under subsection 53(4), the operator must keep each version of the policy for five years from the date it was in place. Section 53 provides that the operator must also provide to the System Operator a copy of the current policy, or an earlier iteration of the policy, if requested by the System Operator.

Section 54 – Security and access policy—giving to System Operator on request

This section requires registered repository operators or portal operators to provide the System Operator on request, with a copy of its security and access policy.

The System Operator may consider evidence that provides reasonable assurance that key controls described in the policy are in place and operating; demonstrating an entity’s cyber security maturity, risk management practices and control effectiveness to ensure the confidentiality, integrity and availability of the MHR system.

While the System Operator would not endorse the policy, the review requirement supports oversight and enables the System Operator to identify security or compliance gaps that may affect the security and integrity of the MHR system.

Section 55 – Security and access policy—application record-keeping

Registered repository operators and portal operators must keep records that show how the operator has applied and met its requirements in relation to the security and access policy requirements set out in section 27.

Records which evidence that the operator has satisfied its obligations under paragraphs 27(2)(a) and (b) must be kept for five years. These provisions apply to require the operator to keep records of the user accounts created, changed, suspended or deactivated, and the training that was provided initially to users before they are granted access to My Health Record, and the ongoing training provided to users to meet the requirements in subparagraphs 27(2)(b)(ii) and (iii).

Records of how the obligations under paragraphs 27(2)(c) and (d) must be kept for two years. Paragraph 26(2)(c) requires an organisation to have processes to ensure it does not contravene section 75 of the Act.

Section 75 of the Act requires an entity to take certain steps in the event it identifies unauthorised collection, use or disclosure of health information in a healthcare recipient’s My Health Record, or becomes aware of an event or circumstances involving the entity which impact or potentially impact the security or integrity of the MHR system. The requirements in sections 27 and 53 of the Rules ensure that entities that are, or seek to become, registered repository operators or registered portal operators have clear processes to identify, manage and respond to such scenarios and comply with the requirements of section 75 of the Act. They must also keep records to evidence these processes and any action planned or taken to comply with the section 75 requirements.

Paragraph 27(2)(d) of the Rules requires operators to set out in their security and access policy, the physical security, information security and cybersecurity, including technical and organisational, measures that will be implemented. The corresponding requirements in paragraph 55(1)(d) are to keep records for two years of how those measures have been implemented. For example, documented application of the user account management practices, system maintenance activities, data protection, encryption and back-up procedures that have been employed and when should be kept to satisfy this requirement.

The records required by section 55 are intended to provide evidence that an operator is complying with its obligations under the Rules and are designed to reflect record-keeping data minimisation principles. The requirements to keep evidence for 5 years of the application of paragraphs 27(2)(a) and (b) relate to policy and process-level information. The types of information required to evidence application of the processes and measures required by paragraphs 27(2)(c) and (d) involve more detailed audit-type information and are only required to be kept for 2 years. Relevantly, notifications under section 75 of the Act related to data breaches or unauthorised MHR access must be notified as soon as practicable after becoming aware of the relevant issue.

Under section 56 of the Rules, the System Operator may request a copy of a record required to be kept under section 55.

Section 56 – Security and access policy—giving application records to System Operator on request

Section 56 provides for the System Operator to make a written request to a repository operator or a portal operator for a copy of a record required to be kept under section 55. These are the records which show evidence of how an operator is implementing its security and access policy.

If requested, the operator must provide a copy of the relevant record/s within 7 days of receipt of the request.

Division 4—Registered contracted service providers

Section 57 – Application

This section provides that Division 4 applies to the contracted service providers who are registered to participate in the MHR system.

Section 58 – Complying with directions to delete information or a record

This section supports section 13, so that if the System Operator directs a registered contracted service provider to delete information or a record, the provider must comply with the direction.

Together, these sections help to ensure that inappropriate, unsafe or incorrect information is contained to protect individuals and maintain the safety and integrity of the MHR system.

Section 59 – Ensuring contracted service provider officer carries out duties

This section requires a contracted service provider to ensure that its contacted service provider officers perform the functions required of them under paragraph 31(2)(b).

These obligations are to receive communications about the MHR system, and liaise with the System Operator, on behalf of the provider and to maintain the professional and business details of the provider and the contracted service provider officer.

It is not sufficient for a participant merely to appoint contracted service provider officers. The participant must actively ensure that those officers carry out their responsibilities competently and in accordance with the requirements of the MHR system.

Section 60 – Notifying System Operator of certain matters

This section sets out the circumstances in which a person must notify the System Operator, and the matters that must be included in that notification. It also requires that the notification be provided in writing within two business days of the relevant circumstance arising, ensuring the System Operator is informed in a timely and consistent manner.

Events triggering a notice requirement are as follows:

• where the contracted service provider becomes aware of a non‑clinical error in information that has been accessed or downloaded from the MHR system by the provider or employee of the provider. A non‑clinical error is a mistake that does not relate to clinical decisions or judgement, such as a file that is corrupted or incomplete. The provider must explain what the error is.
• where the provider undergoes a material change. A material change in relation to a participant in the MHR system is defined in section 5 to include a change in the participant’s legal name or structure, or the participant entering into administration, becoming insolvent or being involved in a merger or acquisition. The provider must describe what has changed.
• if a contracted service provider officer changes, or the contact details for a contracted service provider officer change, the provider must tell the System Operator. This would include requirement to notify of the new officer and/or new contact details for the officer. This ensures the System Operator has current information in relation to the individuals authorised to act for the provider.
• if the entity becomes or ceases to be a contracted service provider for a registered healthcare provider organisation. The combined effect of items 5 and 6 of this section is to require the entity to keep the System Operator updated of all healthcare provider organisations for which it is a contracted service provider. The entity must notify the System Operator of the healthcare provider organisation’s name and healthcare identifier, and if applicable its business name under the Business Names Registration Act 2011. There is a corresponding requirement in section 38 of the Rules for healthcare provider organisations to notify the System Operator where they have a contracted service provider. This ensures the System Operator has awareness of links between contracted service providers and healthcare provider organisations, to support its administration of the system.

Section 61 – Compliance with interoperability requirements

Section 61 requires contracted service providers to comply with the interoperability requirements for the MHR system. Section 5 of these Rules defines interoperability requirements for the MHR system to mean the conformance requirements and standards applicable to that system, published by the Australian Digital Health Agency, as existing from time to time.

Section 62 – Providing assistance to the System Operator on request

This section requires a contracted service provider to help the System Operator to respond to issues related to the MHR system.

The obligation to promptly assist the System Operator as necessary only applies if the System Operator has provided reasonable notice to the provider of the assistance required.

Section 63 – Security and access policy—general

This section contains a number of requirements that contracted service providers must follow in relation to their security and access policy. These requirements include:

• communicating and making the policy easily accessible to all employees and users accessing My Health Record via or on behalf of the provider;
• taking all reasonable steps to ensure that the entities mentioned in subsection 63(1) comply with policy;
• keeping the policy up to date, pursuant to the requirements set out in subsection 63(3).

Under subsection 63(4), the provider must keep each version of the policy for five years from the date it was in place. Section 64 provides that the provider must also provide to the System Operator a copy of the current policy, or an earlier iteration of the policy, if requested by the System Operator.

Section 64 – Security and access policy—giving to System Operator on request

This section requires a contracted service provider to provide the System Operator on request, with a copy of its security and access policy.

The System Operator may consider evidence that provides reasonable assurance that key controls described in the policy are in place and operating; demonstrating an entity’s cyber security maturity, risk management practices and control effectiveness to ensure the confidentiality, integrity and availability of the MHR system.

While the System Operator would not endorse the policy, the review requirement supports oversight and enables the System Operator to identify security or compliance gaps that may affect the security and integrity of the MHR system.

Section 65 – Security and access policy—application record-keeping

A contracted service provider must keep records that show how it has applied and met its requirements in relation to the security and access policy requirements set out in section 32.

Records which evidence that the provider has satisfied its obligations under paragraphs 32(2)(a) and (b) must be kept for five years. These provisions apply to require the provider to keep records of the user accounts created, changed, suspended or deactivated, and the training that was provided initially to users before they are granted access to My Health Record, and the ongoing training provided to users to meet the requirements in subparagraphs 32(2)(b)(ii) and (iii).

Records of how the obligations under paragraphs 32(2)(c) and (d) must be kept for two years. Paragraph 32(2)(c) requires a provider to have processes to ensure it does not contravene section 75 of the Act.

Section 75 of the Act requires an entity to take certain steps in the event it identifies unauthorised collection, use or disclosure of health information in a healthcare recipient’s My Health Record, or becomes aware of an event or circumstances involving the entity which impact or potentially impact the security or integrity of the MHR system. The requirements in sections 32 and 63 of the Rules ensure that contracted service providers have clear processes to identify, manage and respond to such scenarios and comply with the requirements of section 75 of the Act. They must also keep records to evidence these processes and any action planned or taken to comply with the section 75 requirements.

Paragraph 32(2)(d) of the Rules requires providers to set out in their security and access policy, the physical security, information security and cybersecurity, including technical and organisational, measures that will be implemented. The corresponding requirements in paragraph 65(1)(d) are to keep records for two years of how those measures have been implemented. For example, documented application of the user account management practices, system maintenance activities, data protection, encryption and back-up procedures that have been employed and when, should be kept to satisfy this requirement.

The records required by section 65 are intended to provide evidence that a provider is complying with its obligations under the Rules and are designed to reflect record-keeping data minimisation principles. The requirements to keep evidence for 5 years of the application of paragraphs 32(2)(a) and (b) relate to policy and process-level information. The types of information required to evidence application of the processes and measures required by paragraphs 32(2)(c) and (d) involve more detailed audit-type information and are only required to be kept for 2 years. Relevantly, notifications under section 75 of the Act related to data breaches or unauthorised MHR access must be notified as soon as practicable after becoming aware of the relevant issue.

Under section 66 of the Rules, the System Operator may request a copy of a record required to be kept under section 65.

Section 66 – Security and access policy—giving application records to System Operator on request

Section 66 provides for the System Operator to make a written request to contracted service provider for a copy of a record required to be kept under section 65. These are the records which evidence how a provider is implementing its security and access policy.

If requested, the provider must provide a copy of the relevant record/s within 7 days of receipt of the request.

Section 67 – Accessing the My Health Record system or using health information included in a healthcare recipient’s My Health Record

This section confirms that contracted service providers are not permitted to access or use My Health Record information on their own initiative but rather must only do so to the extent instructed to do so by a healthcare provider organisation.

When they access the system, they must also give the System Operator the healthcare identifier of the healthcare provider organisation that gave the instructions to access or use the health information.

Unauthorised collection, use or disclosure of information from the MHR system, constitutes a contravention of sections 59 and 59A of the Act. Such contraventions attract civil penalty provisions under the Act.

Part 5—Other requirements relating to the My Health Record system

Section 68 – Purpose of this Part

This section notes that the Rules in Part 5 are made under paragraph 109(3)(d) of the Act.

Section 69 – Requirements for System Operator—system availability

This section applies so that a participant in the MHR system may request the System Operator to provide details of when the MHR system was unavailable. Where such a request is received, the System Operator must provide that information.

This supports participants to confirm, manage and explain delays, investigate issues and keep accurate records in relation to MHR system access.

Part 6—Other matters—authorised representatives and nominated representatives

Section 70 – Requirement for System Operator—identity verification for healthcare recipients on ceasing to have an authorised representative

This section applies in circumstances where a healthcare recipient who previously had an authorised representative no longer has an authorised representative. In that case, if the healthcare recipient had previously verified their identity with the System Operator, they are required to verify their identity before they can access their My Health Record.

An example of the application of this provision is when a child becomes old enough to manage their own My Health Record, and no longer has an authorised representative, before the child may access their record, they must verify their identity with the System Operator.

This protects the person’s privacy, as the System Operator will authenticate the person before providing access to their My Health Record and the sensitive health information contained within their record.

Section 70 of the Rules intentionally does not prescribe operational processes for identity verification, as identity verification continues to be carried out under existing HI Service operational policies and Services Australia’s evidence‑based identity verification frameworks, which include document checks, Medicare enrolment matching, and identity‑proofing and retention processes. Section 70 specifies only what must be verified, not how, deliberately allowing flexibility for ongoing HI Service modernisation, alignment with broader Commonwealth identity‑management frameworks, and future digital identity capabilities such as interoperable identity services, parent or guardian linkages, and birth‑registration integration.

This approach is consistent with the HID Act, particularly sections 12-15 of that Act relating to the collection and use of identifying information to assign or confirm an individual healthcare identifier without mandating any prescribed verification method, and subsection 7(3) which defines what identifying information may be collected while leaving the method of verification to operational policy.

Part 7—Opt-out model for the participation of healthcare recipients in the My Health Record system

Section 71 – Opt-out model applies to all healthcare recipients in Australia

This section applies the opt‑out model to all healthcare recipients in Australia, as provided for in item 2 of Schedule 1 of the Act.

The effect of this provision is to continue the application of the model which applies so that all healthcare recipients are registered for a My Health Record unless they choose not to have one. Under the Act, a person who is registered for a My Health Record may at any time request that their My Health Record be cancelled.

Part 8—Application, transitional and saving provisions

Division 1—Provisions for this instrument as originally made

Section 72 – Security and access policy requirements for certain registered entities existing immediately before 1 April 2026

This section sets out the transitional and grandfathering arrangements in relation to the security and access policies that participants must have to remain registered with the MHR system.

Where an entity was registered immediately prior to the commencement of these Rules, the previous provisions under the 2016 MHR Rule related to the security and access policy requirements will continue to apply to the entity for a six-month transitional period. From 1 October 2026, the provisions in sections 21, 27 or 32 of these Rules (as applicable depending on the relevant participant) will then apply.

This approach will allow time for entities already participating in the MHR system to review and adjust their policies and processes to ensure they can remain registered and comply with the amended requirements.

Schedule 1—Repeals of instruments

Item 1 – Repeal of instruments

This item repeals the following instruments:

• My Health Records (Assisted Registration) Rule 2015
• My Health Records (National Application) Rules 2017
• My Health Records (Opt-out Trials) Rule 2016
• My Health Records Rule 2016

ATTACHMENT B

Statement of Compatibility with Human Rights

Prepared in accordance with Part 3 of the Human Rights (Parliamentary Scrutiny) Act 2011

My Health Records Rules 2026

This Disallowable Legislative Instrument is compatible with the human rights and freedoms recognised or declared in the international instruments listed in section 3 of the Human Rights (Parliamentary Scrutiny) Act 2011.

Overview of the Instrument

The instrument provides for a number of matters to support the secure and effective operation of the My Health Record system, in line with requirements established by the My Health Records Act 2012 (the Act).

The instrument:

• supports the application of access control settings that may be applied by healthcare recipients to manage who can access their information via their My Health Record;
• prescribes the requirements that must be met by healthcare provider organisations, contracted service providers, repository operators and portal operators to be eligible to register and remain registered with the MHR system, including obligations to support the security and integrity of the system;
• prescribes the circumstances which trigger suspension or cancellation of access to a healthcare recipient’s My Health Record;
• specifies requirements for verifying the identity of healthcare recipients and their representatives;
• supports the continued application of the opt-out model to all healthcare recipients.

Human rights implications

The instrument engages the following human rights:

The Right to Privacy

Article 17 of the International Covenant on Civil and Political Rights (ICCPR) protects against arbitrary or unlawful interference with privacy. This right is also reflected in Article 22 of the Convention on the Rights of Persons with Disabilities and Article 16 of the Convention on the Rights of the Child. Article 17 of the ICCPR provides that no one shall be subjected to arbitrary or unlawful interference with his or her privacy, family, home or correspondence, nor to unlawful attacks on his or her honour or reputation, and that everyone has the right to the protection of the law against such interference or attacks. The right to privacy includes respect for informational privacy including in respect of storing, using and sharing private information. It also includes the right to control the dissemination of personal and private information. The right to privacy also includes the right to the protection of one’s personal data.

The Human Rights Committee has said that, pursuant to Article 17(2) of the ICCPR, State Parties are required to regulate the processing, use and conveyance of automated personal data, and to protect those affected against misuse. The Committee has said, moreover, that State Parties must take all appropriate measures to ensure that the gathering, storage and use of sensitive personal data is consistent with their obligations under Article 17.

The Legislative Instrument reduces privacy risks and safeguards an individual’s right to privacy in the following ways.

The Instrument sets out obligations on participants in the MHR system, including healthcare provider organisations, repository and portal operators, and contracted service providers, to adopt policies and practices to promote secure connections to My Health Record, and ensure that access to health information via My Health Record is only permitted by authorised users, who are subject to upfront and ongoing obligations to undergo training in the appropriate use of My Health Record.

The Instrument also details the minimum access controls that the System Operator must make available to healthcare recipients, to allow them to manage who can access their information via My Health Record. The Instrument provides for mechanisms to provide transparency for healthcare recipients as to who has access to their My Health Record and the application of controls to limit access to some or all of their information. Together with the provisions of the Act which allow a healthcare recipient to elect not to have a My Health Record, or to advise their healthcare providers that they do not wish certain information to be uploaded to My Health Record, this Instrument provides for additional controls that allow a healthcare recipient to manage and restrict access if desired.

The Instrument also outlines situations where access to the MHR system or a healthcare recipient’s My Health Record is to be suspended or cancelled.  The ability to suspend or cancel access if there is a risk to the security, integrity or operations of the system, is a privacy positive outcome that ensures that the MHR system protects the privacy of healthcare recipients. 

The Instrument further specifies situations where a person’s identity must be verified, ensuring that people accessing sensitive information are authorised and authenticated.

Conclusion

The instrument is compatible with human rights because it promotes better health outcomes for Australians by enabling consumers to have better access to their health information, while supporting them to manage who may access their information. The instrument engages the right to privacy for the legitimate objective of promoting better access to health services and applies a number of privacy-enhancing settings to promote the security and protection of personal data.

Mark Butler
Minister for Health and Ageing