My Health Record Connecting Systems - Security Conformance Profile - FAQs

DG-3113

Type

Guide

Version

1.0

Status

Active

Created date

02/06/2023

Updated date

16/02/2026

This is the current version.

General Questions

1. I already have production access to My Health Record. Do I need to do this extra conformance?
Yes. This new profile will apply to all existing and new connecting systems to the My Health Record.

2. Are there any costs or financial compensation in implementing the new requirements?
There is no cost for the Agency’s conformance assessment, and no financial compensation is offered to cover an independent testing service. The Agency expects that most software developers who need to conform to the requirements for independent penetration and vulnerability testing are already undertaking this testing as part of their core business and product management. However, there may be costs incurred by software developers to implement requirements, depending on whether there is product changes needed to conform.

3. Will this affect a healthcare provider’s access to My Health Record?
No. The security requirements will not affect the healthcare provider’s ability to access My Health Record system. The Agency will work with you to protect your systems and patient health information. Please contact the Agency help centre via help@digitalhealth.gov.au(link sends email.

4. Do test evidence need to fall within a specific timeframe to be considered valid for assessment? If so, what is the timeframe?
The validity of the test evidence is determined by its alignment with the current software version, rather than the date it was collected.

Scope Questions

1. Which systems need to conform to the profile, and can these requirements be applied at the department level or at the system level?
Conformance is applied on the healthcare software and not the organisation itself. Therefore, all Clinical Information System (CIS), Contracted Service Provider (CSP) including Healthcare Information Provider Service (HIPS) that use one or more My Health Record B2B web services need to conform to the profile.

2. Will the security requirements affect mobile services?
Software products accessing the My Health Record system via the My Health Record FHIR Mobile Gateway do not have to conform to the profile. However, mobile application developers are strongly encouraged to review the requirements and consider whether the security of their mobile applications could be strengthened through adoption of any applicable requirements.

Authentication Hardening Questions

1. Where software provides configuration (e.g. password requirements, locking), would it be sufficient to provide guidance on the required settings, rather than enforcement?
The conformance requirements apply to software capabilities and behaviours, and the software must provide these functionalities to enable organisational compliance.

2. Do you expect greater use of the passkeys for multi-factor authentication, which has been endorsed by Google, Apple, Microsoft, and others?
Yes. The security requirements are agnostic on the method of authentication used and by doing so supports the use of passkeys.

3. If a software forces a user to log in to the system only after connecting to a virtual private network (VPN), does a privileged provider still require a mandatory two-factor authentication?
It is mandatory to authenticate privileged users using multi-factor authentication (MFA) regardless of the use of a VPN.

4. The 15-minute timeouts can affect efficiency for certain roles. If the software is configurable, can the timeout period be customised by the users?
The 15-minute period of inactivity should trigger a session timeout, and this will be the default maximum. However, if the software can support local customisation of this, the users should only set the period of inactivity up to a maximum of 2 hours.

5. In addition to our core application, we have quite a few standalone utilities that will connect to the same database. Would requirement SEC-0081 (Session timeout) apply just to our core application which has My Health Record functionality, or would it apply to everything?
SEC-0081 (Session Timeout) requirement will only apply to the core application that connects to the My Health Record via the B2B gateway and not to the other standalone applications connecting to the same database.

6. Do these requirements apply if the healthcare service switches off My Health Record functionality in the software?
Yes. The security requirements apply to the software. This is because the software still has the capability to connect to the My Health Record system regardless of whether the healthcare service opts to switch off the My Health Record functionality.

7. We are currently creating a cloud-based login for our system that will be optional and separate to the local login that already exists. If the cloud login is the only one that supports MFA, would this meet this requirement?
If the cloud login is optional and a user can log in using either local or cloud, then MFA functionality will need to be implemented on both.

8. Is SEC-0271 (Multi-factor Authentication) requirement mandatory for on-premise systems e.g., desktop application?

Yes. the requirement is mandatory requirement for all software products that connect to the My Health Record (MHR) system.

This applies to all software types, including desktop applications, on-premises systems, cloud-based systems, and hybrid deployments.

The conformance profile does not differentiate by hosting model. If the product can access MHR directly or indirectly then the MFA capability must be implemented for the solution to be conformant to the MHR Security Profile.

9. Does Multi-factor Authentication apply to the whole application, or only the My Health Record functionality?

The requirement applies to the whole application. The MFA capability must be applied at the point where the user authenticates to the application.

This is because:

Conformance applies to the software product as a whole, not to individual features.
Strong user authentication must occur before a user is able to access My Health Record.
SEC‑0271 cannot be met by applying MFA only around certain menus or functions.

10. Is multi-factor authentication (MFA) required when systems must operate offline (without internet connectivity) but still needs to access My Health Record (MHR)?

If the system is offline and MHR access is not possible, MFA is not required during offline usage. However, once the software goes online again, MFA must be successfully completed before any access to My Health Record occurs.

This means:

Users may authenticate offline without MFA only while MHR access is impossible.
Once the system regains connectivity and can interact with MHR, the user must authenticate using MFA before making any MHR API calls.
The application should remain operational offline for clinical safety purposes.

Security Testing Questions

1. Is it necessary that the testing service provider that will perform penetration or vulnerable testing on our software be CREST accredited?
The Agency is open to considering requests to use other non-CREST accredited penetration testing companies. The Agency can collaborate with vendors to assess the suitability of non-CREST accredited penetration testing service providers. It is recommended that vendors consult with the Agency to have non-CREST accredited penetration testing service providers assessed for suitability before procuring any services.

2. Our application is mostly on premise; however, we are looking at incorporating various cloud-based features to it. Would the penetration testing only need to have the cloud accessible endpoints in scope?
For the cloud product, a penetration testing might be conducted. On the other hand, for software that is on premise, vulnerability test might be conducted. They both are optional requirements.

3. Would using an Application Security Posture Management tool be appropriate to carry out testing for our software instead of engaging a CREST accredited organisation?
While the Agency would encourage and support the use of automated testing tools as part of the development pipeline, this would not meet the intent of SEC-0221.

4. Does Amazon Web Services (AWS) Inspector meet the penetration testing or vulnerability testing requirements outlined in the My Health Record Connecting Systems Security Conformance Profile?

No, this is because AWS Inspector alone does not meet SEC‑0220 (penetration testing) requirement. For any web‑facing application, SEC‑0220 requires penetration testing by an independent, CREST‑accredited third party. This ensures that external attack surfaces are assessed with a level of rigor appropriate to systems interacting with My Health Record.

While tools like AWS Inspector supports ongoing vulnerability scanning, it cannot replace formal penetration testing. Automated scanners identify known issues but lack the depth of manual testing and exploitation techniques. However, when integrated into the secure development lifecycle or continuous integration/continuous deployment pipelines, these tools still contribute valuable evidence.

Application Development – Conformance Questions

1. Can you clarify what handling all system return values means as outlined in SEC-0090 (Return values of system calls)?
Software handling all possible return values for system calls is considered good programming practice. The Agency understands that it will be impractical for software to be exhaustively tested to gain conformance on this requirement. The Agency intends on testing a proportion of the system calls. The software developer will be attesting to the fact that all system calls are appropriately handled in their software.

2. How will a software developer demonstrate conformance to requirement SEC-0020 (Prohibit use of Microsoft Office templates with embedded Flash, Silverlight, or Shockwave controls?

To demonstrate conformance to SEC-0020, the software developer needs to incorporate the below response into the MHR Security Profile Conformance Test Script.

Attestation: No test evidence is required; however, by indicating a test result of "Pass," you confirm that the software complies with this requirement.

The MHR Security Profile Conformance Test Specification will be revised to include the above in the next version of the document.

System Patching Questions

1. Is the conformance profile requesting enterprise customers to conduct testing and gain approval before deploying patches into production?
There is no intention to force enterprise customers to change the way they currently provide assurance of patches/updates before deploying into production.

2. Automatically deploying patches - does this apply to Practice Management System (PMS) updates or security patches on the machine?
This applies to PMS updates.

Encryption Questions

1. What would you suggest if encryption of data at rest may force a full SQL licence to some customers?
Expenditure incurred for software license are borne by the Healthcare Provider Organisation. The Agency understands that this will be a significant piece of work to educate healthcare provider organisations on the importance of protecting their patient data. Depending on the software developer and their product requirements there may be other alternative database products/technologies that meet encryption at rest at no software license cost that could be explored by the software developer.

2. Are notes outlined on each requirement for SEC-0089 (Disk encryption for systems) and SEC-0126 (Database encryption) mandatory?
No, it is still a recommended requirement. The notes section is not a part of the conformance requirement for conformance purposes but provides important guidance and recommendations for the requirement to be implemented.

3. Is there any minimum Transport Layer Security (TLS) version needed for My Health Record system?
For software connected or is connecting to the My Health record system, the software must use TLS v1.2 or above. In addition, it must use a compliant cipher otherwise, the connection to My Health Record will be blocked. The Agency is also decommissioning TLS versions 1.0 and 1.1 as acceptable protocols in connecting to MHR.

Listed below are the different cypher suites that are compliant and non-compliant.

Compliant Cipher Suites

ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256

Non-Compliant Cipher Suites (will be blocked)

ECDHE-RSA-AES256-SHA384
AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA256

Data Backup Questions

1. Can the Agency confirm if SEC-0130 (Minimum storage time) and SEC-0151 (Backup frequency) for Desktop Applications means that software not organisation needs backup and do it daily for 3 months?
SEC-0151 states that the software providing backup and restore functionality only.
SEC-0130 states that the software shall not automatically delete or overwrite a backup file.
These requirements merely facilitate the correct backup and restore practices by the healthcare provider organisation.

2. If the scope, such as backups, encryption or operating system patching, falls outside the software, would offering guidance to clients on these responsibilities fulfill requirements?
The profile includes two main sections, conformance and compliance requirements, and there are relevant requirements around system patching, data backup and restoration in both sections. The conformance requirements apply to software capabilities and behaviours. The software must provide these functionalities to enable organisational compliance. The provision of more guidance to implementing organisations will be beneficial to guide end users on these functionalities.

The compliance requirements apply to the software provider organisation. The implementing organisation must comply with these requirements by signing a declaration form.

3. Why are backup requirements included when the documents are stored in the My Health Record?
Backups are for local records managed by the software. The backup requirements are not just for documents stored in the My Health Record. It also includes all vital information and configuration settings. The purpose of including backup requirements within the profile are to ensure that recovery can be performed in the event of an incident (hence why other data such as system configurations and settings are included in the backup scope).

Compliance Questions

1. Does Compliance Requirements in the My Health Record Connecting Systems – Security aimed solely at software developers rather than the software itself?
Correct. The compliance requirements are specifically for the software provider organisations to comply with, and not the software.

2. Can Security Information and Event Management (SIEMS), which ingests system logs/monitoring/alerts/notification tools be use as an existing control measure to address compliance requirement?
A SIEM solution helps detect, analyse, and respond to security threats. If you are referring to having a SIEM in your organisation, a SIEM may be used to augment the Security Requirements conformance profile and should not be considered as an alternative control.

Application Development - Compliance Questions

1. Does SEC-0420 (Security vulnerability notification) requirement only referring to third party software that our organisation may use.
Yes, this requirement applies if third party software is used.

Implementation Questions

1. What is the timeframe for passing security conformance?
The finalised implementation timeline is available in My Health Record Connecting Systems Security Conformance Profile Implementation Timeline.

2. Do software developers only need to declare conformance against the mandatory requirements as a minimum standard?
It is expected that mandatory requirements and all relevant conditional requirements are met. However, the Agency encourages that the recommended requirements are implemented to healthcare software systems where possible as it can become mandatory in future releases of the My Health Record Connecting Systems Security Conformance profile.

3. How does my software remain conformant to the Security Conformance Profile?

The implementation will remain conformant until one of the below conditions apply:

The conformance profile or related technical documents including the conformance assessment scheme (this document) relevant to the declaration of conformance is sunsetted or declared superseded.
The software is not re-tested in accordance with section 5.1 of the My Health Record System Conformance Assessment Scheme.
The software is subject to investigation or incident and the software developer fails to demonstrate an action plan for resolution.
Three (3) years have elapsed since the previous declaration of the My Health Record Connecting Systems Security Conformance Profile was submitted to the Agency, noting aspects of the Security Conformance Profile refer to annual security testing in some circumstances.
The software developer does not comply with the obligations specified in the My Health Record Conformance Vendor Declaration Form vendor deed poll.

Please refer to My Health Record System Conformance Assessment Scheme for further information.

4. What will happen if my software has a technical limitation to implement a particular security requirement?
The Agency will work with your organisation to understand any issues affecting your ability to implement the conformance requirements. Your participation in the My Health Record program is important and the Agency will help as best it can, so you achieve conformance for your software products.

5. Can on-premises and cloud-based applications have different approaches to meet the requirements?
Yes. Different product offerings will be bound to different conditional requirements depending on many facets, including whether they are on-premises or cloud-based applications.

6. Will there be an opportunity to apply for exemptions given our software is in development?
For software currently under development which will integrate with My Health Record system, the Agency expects that the new software will fulfill the necessary requirements of the My Health Record Connecting Systems Security Conformance Profile as part of their My Health Record conformance.

7. Will I have to repeat Notice of Connection (NOC) testing with System Operator?
The software does not need to go through a full Notice of Connection (NoC) testing process. However, an increment to the software version is needed and a minimal NoC is needed to demonstrate a successful upload of a document to the My Health Record system.

8. When does authoring software connected to My Health Record (via HIPS v8.3 or higher) not need a version change, and when does it?

The authoring software's version does not need to increment if connected to My Health Record via HIPS v8.3 or higher with Health Viewer v1.1 implemented and there are no changes to the authoring software itself. However, the authoring software must increment its version if there is an update to the authoring software, such as MHR Security Conformance Profile requirements.

9. What is the implementation timeline for software developers to meet the MHR Security Conformance profile requirements, and does it include time for vendors to roll out updates to their customers?

The 12-month implementation timeline for software developers to meet the MHR Security Conformance profile requirements applies solely to the required software updates. It does not include any additional time vendors may need to deploy the updated software to their customers.

10. If an organisation uses HIPS to access the My Health Record system, are all connected systems still required to conform with the My Health Record Connecting System Security Conformance Profile? Why?

Yes. Software systems that connect through HIPS are still required to conform with the MHR Security Conformance Profile. Accessing MHR via HIPS, including through B2B gateway services, does not by itself ensure conformance with the security requirements.