General Questions
What is the intent of the My Health Record Connecting Systems - Security Conformance Profile?
Cyber security is a continuing threat worldwide. The intent of the profile is to uplift cyber security maturity across the digital health ecosystem, by introducing consistent security measures for connecting systems. These measures are designed to complement and strengthen existing measures employed by the Agency to protect national infrastructure and patient information.
What do I need to do to pass conformance?
The conformance process is being reviewed while the conformance profile continues to be iteratively developed. The steps that software developers will be required to complete in order to achieve conformance will be published on the My Health Record Connecting Systems Security Conformance Profile web page in early 2025.
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 software connections to My Health Record.
Who is responsible for resolving conformance requirement conflicts with Electronic Prescribing?
The Agency has sought to align the new security requirements with existing security measures in other conformance schemes, to the extent possible. However, the cyber security threat landscape is continuously evolving and in cases where conflicting requirements have been identified, the Agency will work with impacted parties to practically resolve the conflict.
Were end-users consulted on these security requirements? How would end-user workflows be affected by measures such as timeouts and screen locks?
The My Health Record Connecting Systems Security Conformance Profile is designed for healthcare software systems. The Agency has received feedback about potential impacts for end-user experience and end-user adoption challenges from stakeholders during the review periods. The requirements are also based on the Information Security Manual (ISM), Australian Signals Directorate’s (ASD) Essential Eight and Open Worldwide Application Security Project (OWASP). These requirements are considered best practice and are applicable to a broad range of settings locally and internationally. Additionally, they have been informed by user research.
Will the Agency provide guidelines for healthcare providers (clinicians, aged care providers) that software developers can use to inform their customers?
The Agency intends to provide implementation guidance where appropriate, to support software developers and healthcare providers understand and implement the requirements.
Can the Agency provide guidance on the required settings, so that industry does not have to determine this individually?
Guidance on the applicability of the security requirements in different settings can be found within the conformance profile and the Conformance Assessment Scheme documents. If developers require additional support on the applicability of the requirements to their software, please contact help@digitalhealth.gov.au.
Are there any costs associated for conformance with the new requirements?
There is no cost for the Agency’s conformance assessment. There may be costs incurred by software developers to implement requirements, depending on whether or not there are product changes required to conform e.g. penetration and vulnerability testing.
Will there be financial compensation to cover independent testing services?
No. Ensuring your software products are hardened against cyber security threats is a core part of every business operating in the healthcare sector. 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.
Will the security requirements affect healthcare providers or clinical workflow?
The security requirements are intended to minimise the impact on existing clinical workflow. However, there may be minor impacts as a result of specific requirements not previously implemented in a software product e.g. multi-factor authentication.
What will happen if businesses don’t comply with the security requirements?
The Agency will work with your organisation to understand any issues affecting your ability to implement the conformance requirements and to assist you to achieve conformance for your software products. Your participation in the My Health Record program is important and the Agency will assist you as best it can.
Do businesses need to do self-assessment or observed assessment?
The conformance process is being reviewed. The steps that software developers will be required to complete in order to achieve conformance will be published on the My Health Record Connecting Systems Security Conformance Profile web page in early 2025.
Will this affect a healthcare provider’s access to My Health Record?
No. The security requirements harden clinical information systems without interfering with the ability to access My Health Record. The Agency will partner with you to help you protect your systems and your client’s information. Contact help@digitalhealth.gov.au to speak to a specialist.
As this is a major reform for the healthcare industry, will the Agency be undertaking a Regulatory Impact Assessment/Analysis?
The Australian Government requires that “All Cabinet submissions require a Regulatory Impact Statement (RIS). If a decision is not going to Cabinet, a RIS is still required where the policy proposal is likely to have a measurable impact on business, community organisations or individuals. This includes new regulations, amendments to existing regulations and, in some cases, sunsetted regulations being remade (available here)". Further, a RIS is required for “Any policy proposal or action of government, with an expectation of compliance, that would result in a more than minor change in behaviour or impact for people, businesses or community organisations (available here, p. 8).
The 2023–30 Australian Cyber Security Strategy aims to “to undermine cybercrime business models and put Australians in a strong position to respond effectively, including if they are asked to pay a ransom (p. 16)”. The Australian Government recognises that “uplifting cyber maturity can be challenging for small and medium businesses, particularly when balancing competing priorities. Without appropriate support and guidance, investment in cyber security can seem overwhelming (p. 18)” and the government will “work with industry to ensure cyber security is appropriately considered in the boardroom, informed by clear guidance on cyber best-practice and lessons learned from previous cyber incidents (p. 24)”. To protect the Australian Government and community from cyber threats, the Australian Government has developed the Protective Security Policy Framework (PSPF) and the Information Security Manual (ISM).
- The PSPF helps Australian Government entities to protect their people, information and assets, both at home and overseas.
- The purpose of the ISM is to outline a cyber security framework that an organisation can apply, using their risk management framework, to protect their systems and data from cyber threats.
In line with the Strategy, PSPF and ISM, the Australian Digital Health Agency (Agency) has developed the “My Health Record Connecting Systems Security Conformance Profile”. Development of conformance requirements for My Health Record enables the System Operator (the Agency) to protect the availability and integrity of My Health Record. While these security requirements contain some new requirements, they are an extension of the existing scheme and are designed to mitigate new and evolving cyber security risks.
The Agency considers that the development of a RIS is not required in this circumstance for the following reasons.
- The Protective Security Policy Framework was introduced in 2018 and is therefore not a new requirement for industry working with the Australian Government.
- The Agency is not accountable for regulation of the PSPF and/or ISM and therefore, an Agency owned RIS would not be appropriate. Should an issue arise, or be identified by the Agency, this would be escalated to the relevant parties for further investigation and where applicable, prosecution (e.g. Australian Signals Directorate).
- The requirements outlined in the “My Health Record Connecting Systems Security Conformance Profile” continue to support industry mature its cyber security arrangements and is not a new requirement.
Scope Questions
What does the new Security Requirements for My Health Record Connecting Systems Conformance Profile contain?
The profile contains software requirements that harden clinical information systems from cyber security attacks, to uplift information security and protect patient information and your software product. The requirements are based on the Australian Cyber Security Centre Information Security Manual (ISM). The controls have been selected from ISM to help protect systems against a range of online and cyber security threats.
Which systems need to conform to the profile?
All Clinical Information System (CIS) and Contracted Service Provider (CSP) that use one or more My Health Record B2B web services need to conform to the profile.
Do these requirements apply to secure facilities such as pathology laboratories that already undergo National Association of Testing Authorities (NATA) accreditation that includes physical and software security?
Yes, the conformance requirements are still applicable to pathology laboratory software systems.
Will the security requirements affect mobile services?
Software products accessing the My Health Record system via the My Health Record FHIR Mobile Gateway are not required 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.
Are there any plans to update the My Health Record Service adaptor. It hasn't been updated past Java 8. (2021)?
The conformance profile applies to the software system capabilities (conformance requirements), and software provider organisation (compliance requirements). The My Health Record service adaptor is out of scope in this context.
Are these requirements for systems connecting to My Health Record only or any government health system? Are there plans to extend this to any software system holding protected health information?
At this stage, the scope of the security requirements is limited to systems connecting to My Health Record. The security requirements are a first step in a long-term strategy to uplift the cyber security posture of clinical information systems. In future, the requirements may be extended to systems connecting to other national infrastructure or participating in interoperable digital health ecosystems. These security requirements build on the security requirements already applicable to Electronic Prescribing. These controls help you protect your customers data and the healthcare information belonging to My Health Record consumers.
Requirements Questions
What can I do if I find requirements that are conflicted between the Electronic Prescribing and Security Requirements Conformance Profile?
Where conflicts are identified, the Agency will work to resolve them in a timely manner and update the conformance profile as part of ongoing maintenance and continuous improvement.
Authentication hardening
Where software provides configuration (e.g. password requirements, locking), would it be sufficient to provide guidance regarding 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.
Do you anticipate 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.
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.
Regarding two-factor authentication, our customers use their own Identity Provider (e.g. Active Directory). Hence, the software developer cannot control whether our customers use MFA or not. Can you please confirm?
Agree. The security requirement mandates that the software has MFA capability. It is up to the healthcare provider organisation to determine how it is used based on their risk profile.
If a software developer has implemented two-factor authentication but the organisation or users choose to disable it, who would be responsible?
The security requirements mandates that the software has MFA capability. It is up to the healthcare provider organisation to determine how it is used based on their risk profile.
15-minute timeouts can affect efficiency for certain roles. If software is configurable, could this be the responsibility of the customer using the software?
Yes, the 15-minute timeout will be the default maximum, but the software can support local customisation of this.
One of the requirements (SEC-0081) mentions screen locking. Is this referring to the machine login? It seems unreasonable for an application or website to control this.
It is either session or screen depending on the context.
Application development
SEC-0090 mentions handling all system return values. Can you clarify what this means? Doing for all function & API calls within the Practice Management System (PMS) seems unreasonable.
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.
System patching
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.
Does automatically deploying patches apply to Practice Management System (PMS) updates or security patches on the machine?
This applies to PMS updates.
Encryption
What would you suggest if encryption of data at rest may force a full SQL licence to some customers?
Expenditure incurred for software license will need to be 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.
Data backup
Is there flexibility on Practice Management System (PMS) needing to validate a customer's conformance?
Yes, if certain checks are infeasible then this can be noted and considered.
Can the Agency confirm if SEC-0130 and SEC-0151 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.
Where scope is outside the software (e.g. backups, encryption, operating system patching), would provision of guidance to clients regarding these responsibilities meet 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, and the software must provide these functionalities to enable organisational compliance. Providing additional 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.
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 important 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
For clarity, is section 4 (Compliance) 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.
What about Security Information and Event Management (SIEMS) - ingesting system logs/monitoring/alerts/notification tools as existing control measure unmet 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.
What about the requirements for other IT assets (developer websites/work tools) apart from software product connecting to national infrastructure?
The security requirements are an attempt to uplift the security of clinical information systems in the sector. The Agency’s preference would be for software developers to uplift the security to all of their systems as this will strengthen the digital health ecosystem. That is, not limited to components connected to My Health Record; however, we understand that this first release has a limited scope of influence due to it being for My Health Record connecting systems only.
Technical Questions
Will I have to repeat Notice of Connection (NOC) testing with Services Australia or Accenture?
No. Your My Health Record System Declaration of Notice of Connection letter stating you have notice of connection is still valid and NOC testing need not be repeated.
Is there any chance that the My Health Record and HI services could get a newer, more modern implementation, perhaps PRODA-based, like Medicare Web Services, PBS Online etc?
Yes, as part of the My Health Record modernisation project, there is a dedicated working group tasked with devising options for modern authentication and access solutions.
Implementation Questions
What is the timeframe for passing security conformance?
The initial reduced suite of requirements will need to be implemented by all systems within 12 months of the publication of the final version of the profile (in early 2024). The Agency will consider requests for extensions to this timeframe upon request, on a case-by-case basis. The next version of the profile that will introduce additional mandatory requirements (previously ‘recommended’) will be released after 12 months to reflect the evolving threat environment, with an implementation timeframe to be set in consultation with stakeholders at that time.
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.
Will the Agency enforce these security requirements, or is it just a suggestion?
Conformance with the profile will be mandatory. The Agency intends to provide adequate time to the industry to uplift their system maturity in line with these security requirements prior to any enforcement, including time for deployment of the conformant systems. In the interim, should the Agency be notified or discover through security monitoring activities evidence indicating that software used by a healthcare provider poses a threat to My Health Record, the Agency may require the software developers of the healthcare provider take appropriate remediation activities to address security concern(s). Depending on the severity of the security concern(s), the software and/or healthcare provider may not be permitted to connect to My Health Record until all concerns have been adequately addressed.
Is the Agency going to provide the education to users, noting that a number of the requirements are environmental and outside control of the software developers?
Yes, the Agency can support with uplifting the knowledge in the sector. However, this will require a coordinated approach to ensure that education reaches the intended target audience.
If the software developer integrates with Healthcare Information Provider Service (HIPS), does the software developer still need to conform to these security requirements?
Yes.
Can the Agency provide an "air gap" type solution, so all parties don't also need to duplicate this huge body of work.
Many of the security requirements are applicable to and applied on the clinical information system that is connected to the My Health Record. It is not about protecting the My Health Record. There is no way that the HIPS middleware could be used to secure the Clinical Information System that is connected to the My Health Record through it.
Do these requirements apply if the healthcare service switches off My Health Record functionality in the software?
Yes. The security requirements apply to software that provides functionality that connects to the My Health Record. regardless of whether the healthcare service decide to switch off the My Health Record functionality.