Software-based medical devices: key regulatory requirements, IP considerations and data privacy implications

By Phil O'Sullivan, Lauren John, Tracy Lu, Nick Li, David Liao, Artemis Kirkinis, Stefan Ladd, James Kelly
Cyber Data & Privacy Healthcare Intellectual Property Technology & Outsourcing

Time to assess your product against the revised legal framework 10 min read

Software is increasingly being used both as a medical device and in medical devices. Some of these devices inform clinical decisions. Others are wearable and provide day-to-day health or wellness-related monitoring and reporting functions. The demand for such devices is rapidly growing.

It is crucial that businesses understand the regulations that can apply to software-based medical devices, the IP considerations if they wish to protect such devices and the privacy-related risks associated with the collection and use of data from such devices. This Insight explores each of these issues in turn.

Key takeaways

healthcare-icons_1.pngUnless 'excluded' or 'exempt', software-based medical devices are required to be included in the Australian Register for Therapeutic Goods (ARTG) prior to supply into Australia and subject to full regulation by the Therapeutic Goods Administration (TGA). Most software operating in consumer wearable devices with health and fitness functions are likely to be excluded. Clinical decision support system software that meets certain criteria is exempt and does not need to be included in the ARTG, but remains subject to a degree of oversight by the TGA. The sponsor's intended purpose for the software is key to determining: (i) whether the relevant software is regulated; and (ii) the level of regulation to which it is subject.

healthcare-icons_2.pngWhile the value in software-based medical devices can be protected via various forms of intellectual property rights, there are particular challenges in Australia relating to the protection of: (i) computer-generated works; (ii) databases; (iii) computer-implemented inventions; and (iv) graphic user interfaces (GUIs), which businesses should be aware of in formulating their IP protection strategy for this jurisdiction.

healthcare-icons_3.pngThere is a growing focus by consumers, business and regulators on data-handling activities, particularly in the health sector where new technology enables the collection and use of increasingly rich and detailed data sets. As a result, businesses need to ensure compliance with their strict legal obligations while balancing community expectations, including those around transparency of data use. This can usually be achieved by providing a genuine value proposition to users when seeking permission for data use beyond enabling core product functionality.

Growing demand raises new legal challenges for businesses

In recent years, we have seen an explosion in digital software innovation in medical diagnosis and treatments, including:

  • the use of AI in medical decision-making (and support of same);
  • apps that monitor and report on the efficacy and safety of drugs;
  • apps that monitor chronic medical conditions;
  • virtual reality to replace pain killers; and
  • e-prescribing (to name a few).

We have also seen growing demand for wearable tech that can perform health-related functions, including devices that:

  • measure and track a user's heart rate, such as the electrocardiograph heart-monitoring feature of Apple's Series 4 'Apple Watch', which received US Food and Drug Administration (FDA) clearance in 2018;
  • measure blood sugar levels, such as Dexcom's G6 Pro Continuous Glucose Monitoring System, which gathers real-time glucose data from a user over a 10-day period, which similarly received FDA clearance in 2019; and
  • measure blood pressure and other vital signs, including those which have been deployed to identify early symptoms of, and assist in monitoring, COVID‑19.

However, the growth of software-based medical devices also raises new legal challenges for businesses, including in relation to how such products are regulated, how they can be protected, and how data collected by them can be used, particularly as the relevant legal frameworks are continuing to evolve.

Regulation of software-based medical devices

In Australia, significant reforms came into effect from 25 February 2021, in relation to the regulation of software-based medical devices.

Under the revised regime, software will come under regulation by the TGA if it meets the definition of a 'medical device' under section 41BD of the Therapeutic Goods Act 1989 (Cth). This would include any software used either on a standalone basis (ie software as a medical device (SaMD)), or in a device (eg in order to operate that device), that is intended by the supplier to be used for, among other things, the diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of a disease, condition, ailment, injury or disability (therapeutic purpose).

Software-based medical devices must be included in the ARTG prior to supply into Australia unless they are excluded or exempt.

Excluded software is deemed not to be a medical device and is hence not subject to any TGA regulatory requirements. This is in line with software that does not meet the definition of a 'medical device' in the first place (eg software with no therapeutic purpose).

In contrast, exempt software is still considered to be a medical device and must comply with some, but not all, regulatory requirements.

Excluded software

Under the Therapeutic Goods (Excluded Goods) Determination 2018 (Cth), software that is limited to performing any of the following five functions is expressly excluded from regulation by the TGA:

  1. Consumer health life-cycle prevention, management and follow up – eg consumer health and wellness products that do not make claims about 'serious' diseases or conditions ('serious' being specifically defined in the Therapeutic Goods (Medical Devices) Regulations 2002 (Cth) (the Medical Devices Regulations)).
  2. Enabling technology for telehealth, healthcare care facility management – eg software intended to administer or manage health processes or facilities, rather than patient clinical use cases.
  3. Digitisation of paper-based or other published clinical rules or data – eg software that replicates paper-based mental health assessments in electronic format.
  4. Population-based analytics – eg software that performs an analysis on a class or group of people and generates population statistics to use, for instance, in studying and controlling pandemics, and not to inform interventions for any of the individuals.
  5. Laboratory information management systems and laboratory information systems – eg software that allows a laboratory to automate workflows, integrate instruments, manage samples and deliver reports.

This means that common consumer health and fitness wearables, such as step counters, 'Fitbits' and similar devices, as well as diet and wellbeing apps (eg to support better mental health), would be unlikely to be regulated as medical devices in Australia. However, software that is intended to be used in clinical practice in respect of the diagnosis or treatment of a serious disease or condition, would likely be regulated.

Exempt software

Under the Medical Devices Regulations, clinical decision support system (CDSS) software that meets the following three criteria (subject to exemption conditions being met), would be considered an exempt medical device:

  1. it is intended by its manufacturer to be for the sole purpose of providing or supporting a recommendation to a health professional about preventing, diagnosing, curing or alleviating a disease, ailment, defect or injury in persons;
  2. it is not intended by its manufacturer to directly process or analyse a medical image or signal from another medical device; and
  3. it is not intended by its manufacturer to replace the clinical judgement of a health professional in relation to making a clinical diagnosis or decision about the treatment of patients.

Exempt CDSS software is not required to be approved by the TGA and included in the ARTG. However:

  • the TGA is required to be notified within 30 working days of supply of the software;
  • the software must meet the relevant 'Essential Principles' (which set out the fundamental design and manufacturing requirements for medical devices);
  • the TGA can take regulatory action such as a recall if there is a problem with the software; and
  • adverse events must also be reported to the TGA.
Regulated software

For software-based medical devices that are not excluded or exempt, and are therefore subject to full regulation by the TGA, the key points to be aware of are:

  • New classification rules. The revised Medical Devices Regulations introduced new rules for the classification of all software-based medical devices into the four classes of medical devices, which will determine the level of assessment undertaken by the TGA of the device's quality and safety. The manufacturer of the medical device is responsible for obtaining the relevant conformity assessment certification. The sponsor (which must be an Australian entity) is responsible for both submitting the certificate to the TGA as evidence of the manufacturer's compliance and applying for the device's inclusion in the ARTG. It is possible for software that offers similar functionality to be classified differently, depending on the seriousness of the diseases or conditions to which it is directed, or the level of potential risk if a treatment or intervention specified or recommended by the software is or is not received. For example, software that performs diagnosis or screening can be classified as Class III if it is for a disease or condition that may lead to the death of a person without urgent treatment; or can be classified as Class I if it is not for a serious disease or a serious condition.
  • Changes to Essential Principles. Medical devices (including exempt medical devices) are required to comply with the Essential Principles. The reforms have amended two of the previous Essential Principles, and introduced one new principle in relation to software-based medical devices. These included clarifications to existing requirements relating to cyber security and the management of data and information, and a new requirement that the current version and build number of the relevant software be made accessible and identifiable to users of the software-based medical device.

Safeguarding your IP

In addition to understanding the Australian regulatory landscape in which software-based medical devices sit, it is also critical that businesses have an appropriate IP protection strategy in place, particularly in consideration of some specific challenges in this jurisdiction as discussed below.

The underlying code for a software-based medical device is obviously critical and can be protected by copyright as a literary work. However, in Australia, unlike for example the UK, computer-generated works are not eligible for copyright protection. This has significant implications for software generated automatically by a computer program, rather than a human author.

It is also likely that the data which a software-based medical device uses, collects or generates would be highly valuable. However, in Australia, unlike for example the EU, there are no sui generis database rights which protect the content of databases where it can be proven that a substantial investment had been made in obtaining, verifying or presenting the data. That said, copyright may subsist in the way data has been arranged, structured or presented. This can provide an important tool for businesses seeking to protect proprietary databases from unauthorised third party use. Further information regarding how copyright can assist in protecting commercially valuable data is available here. Where the relevant data is not publicly available, businesses may also give consideration to protecting it as confidential information.

Copyright would not extend to protection of the functionality of a software-based medical device – this can be achieved through a patent. It is worth noting that in Australia, unlike a number of other jurisdictions, methods of medical treatment are considered patentable subject-matter. However, there may be other issues, such as whether the 'substance' of the invention represents an advance in computer technology (which is patentable) or merely a 'business innovation' (which is not). This will come down to how the software operates, which will require careful expert analysis. Further information on the patentability of computer-implemented inventions in Australia is available here.

Where the software is used in relation to a physical device with novel visual features, businesses may consider applying for a design registration to protect such features. The extent of design protection for GUIs, however, is unclear in Australia, as compared to the US and the EU, for example. Further information is available here.

Data and privacy: the financial, regulatory and reputation risks

By their nature, many software-based medical devices recognise and store data points about users and their health over a sustained period of time, with the potential to capture large volumes of personal and sensitive data from individuals. While this presents a clear opportunity for businesses to generate new data insights and/or provide more targeted and personalised healthcare, it also requires careful consideration from a privacy and data security perspective. In particular, demand from health consumers for transparency and a dynamic legislative and regulatory landscape with increasing focus on data handling activities bring significant financial, regulatory and reputational risk for businesses without a clear data strategy and appropriate data governance.

Privacy, surveillance and transparency

Data collected about an individual by software-based medical devices is likely to constitute health information (which is sensitive information, a category of personal information that generally has a higher degree of privacy protection than other personal information) under relevant federal, state and territory privacy legislation (including the Privacy Act 1988 (Cth) and the Health Records and Information Privacy Act 2002 (NSW)). These laws impose a range of obligations on businesses, including that they:

  • obtain consent to collect this health information from users;
  • only use such health information for the purpose for which it was collected, another directly related purpose which the individual would reasonably expect, or otherwise with consent;
  • appropriately secure such health information (including as transmitted from the device to the business or third parties);
  • ensure the quality and accuracy of health information; and
  • provide access to, and correct, health information.

Where software-based medical devices track a user's location, businesses need to consider their obligations under applicable state and territory surveillance legislation, which generally requires a user's consent to such tracking.

In addition to the strict legal obligations around health information, we are seeing consumers better understand the scope of data entities hold about them, and the potential uses and value of such data. In turn, consumers are demanding greater transparency around, and control over, the use of data, including where certain data has been deidentified, which suggests these issues do not originate solely from privacy concerns. This consumer sentiment is backed up by Australian regulators, including the Office of the Australian Information Commissioner (OAIC) and the Australian Competition & Consumer Commission, which focus on how failures to ensure transparent terms of use and clearly communicate data handling practices can undermine community trust.

In this environment, it is important for businesses to clearly articulate the end-to-end value proposition around the use of software-based medical devices, including:

  • how relevant risks have been addressed, such as the security measures in place to protect data;
  • how data (whether in identified or de-identified form) will be handled (including proposed sharing or subsequent interactions with third parties); and
  • how, and the extent to which, individuals can exercise control around their data, such as opting in/out of certain activities or using a dashboard to switch certain functionality on and off.

This can be done through a combination of public-facing documentation, specific terms of use and collection notices, and increasingly through providing functionality to users to self-manage data access and use. Previously, businesses may have been inclined to rely on implied consent obtained in the course of setting up devices and associated accounts. However, as a result of a change in consumer understanding and demands, there is a shift towards obtaining and maintaining more express forms of consent around use of data (which is adequately informed, specific and unbundled).

It is also vitally important to ensure that the business' practices in relation to data are consistent with those representations.

Information Security

The OAIC consistently reports that the health sector is the top sector reporting breaches under the Privacy Act Notifiable Data Breaches scheme. This is, in part, due to the sector:

  • utilising large numbers of connected remote end points; and
  • being a lucrative target for bad actors, with the potential for health information exploitation being one reason health records are estimated to be up to 10 times more valuable than other forms of personal information.

As such, it is no surprise that software-based medical devices and similar health and wellness tracking devices have made headlines for significant data breaches in recent years.

In 2018, popular nutrition and fitness tracking app MyFitnessPal, which was then owned by Under Armour, was targeted in a breach affecting more than 150 million users. Whilst Under Armour stated in its data breach notification that it did not believe users would experience significant harm as a result of the issue, a year later it was reported that the stolen credentials from the breach appeared for sale on the dark web.

Fitbit has also been compromised more than once. In 2016, several dozen Fitbit accounts were accessed by cybercriminals utilising account details from other breaches. In February 2020, it was reported that a hacker had leaked the account details of nearly 2 million Fitbit users and had access to account holders' location tracking history, in addition to other health metrics such as sleep tracking and nutrition.

Security requirements for software-based medical device businesses are generally governed by the Privacy Act (including Australian Privacy Principle 11 and the Notifiable Data Breach scheme), and similar obligations under state and territory health records laws, which require businesses to use reasonable steps to protect information from misuse, interference and loss, unauthorised access, modification and disclosure.

Additionally, TGA Essential Principle 12.1 imposes separate obligations on sponsors in respect of device design, production and maintenance in the context of cyber security. Under this Essential Principle, best practice must be followed in relation to the software to ensure:

  • protection against unauthorised access, influence or manipulation;
  • minimisation of risks associated with cyber security vulnerabilities, including through remediation, updates or patching as well as other compensating controls and improvements; and
  • making available sufficient information for a user to make a decision with respect to the safety of applying or not applying any relevant updates, compensating controls or other improvements.

As such, data security is a key component of any device or feature rollout, and businesses need to:

  • understand the data being collected by the delivery model, and the data flows involved in their practice;
  • adopt a privacy-by-design approach to new projects in the software-based medical device space, including the potential impact on any changes to law. Further information on the proposed amendments to the Privacy Act can be found here;
  • establish robust systems, information controls and monitoring and detection processes that are regularly tested, including:
    • ICT, physical and access security, including identifying and addressing vulnerabilities created by outdated systems or devices and perform appropriate due diligence on third-party vendors; and
    • reconsidering the appropriateness of such controls on a regular basis;
  • identify a data breach response team and have a comprehensive data breach response plan, in order to quickly and efficiently respond to potential data breaches and minimise both harm to individuals and the legal, financial and reputational costs of the breach; and
  • make any public communications about device vulnerabilities and incidents simple and easily interpretable, acknowledging and explaining any unknown factors and discussing the risks and benefits of their device.

What does this mean for businesses?

Software in the health sector, depending on its intended purpose, may be subject to stringent regulation as a software-based medical device in Australia and require regulatory approval prior to supply. Accordingly, it is important that businesses carefully assess their product against the revised legal framework around software-based medical devices, to ensure they have taken all necessary steps for compliance.

Beyond the regulatory space, there are a range of other considerations businesses should bear in mind in relation to software-based medical devices, including:

  • ensuring they have in place appropriate protections for any relevant intellectual property, which may require an Australian-specific approach; and
  • ensuring they have a robust data strategy and appropriate data governance which covers:
    • current and proposed future data flows;
    • how they will ensure compliance with legal requirements, including in relation to obtaining and maintaining consent and ensuring appropriate security;
    • community expectations in relation to product and data use, and the business' value proposition for users;
    • how risks arising from changes in the sector or new features or product lines will be addressed; and
    • how any potential breach (of law, security or community expectations) will be identified, responded to and (where appropriate) communicated to regulators and impacted users.