We updated you earlier this year on the introduction of the Therapeutic Products Bill (“Bill”), which has been proposed as a replacement of the Medicines Act 1981 (“Medicines Act”) and Dietary Supplements Regulations 1985. This article focuses on the implications of the Bill for the health technology industry, namely for health-related software.

Software providers should take note that the ‘market authorisation’ regime for therapeutic products will, if the Bill is passed in its current form, apply to certain categories of standalone software with health-related functions. Essentially, this will mean that health software (including computer and smartphone apps) would be subject to similar regulatory requirements as traditional medicines or medical devices, regardless of whether it interacts with a physical medical device.

A call for public submissions on the Bill closed recently and we will keep you updated on developments affecting the software industry.

Regulation of health technology

One of the Bill’s aims is to bring New Zealand’s regulatory regime for therapeutic products in line with technological changes that have occurred, and continue to occur, in the healthcare industry.

A key development is the rise of health technology, or “healthtech”, which currently faces limited regulation under the Medicines Act. In a regulatory context, healthtech products tend to fall into three categories:

1. physical medical devices with no software component (e.g. a syringe or a thermometer);
2. physical medical devices that rely upon embedded software to perform their intended function, e.g. a CT scanner (such software is commonly referred to as “Software in a Medical Device” or “SiMD”); and
3. standalone software with a health-related application, which functions independently of a physical medical device, but may interact with a non-medical device such as a computer, smartphone or smartwatch (commonly referred to as “Software as a Medical Device” or “SaMD”).

Physical medical devices and SiMD are currently regulated as “medical devices” (or software comprised in a medical device) under the Medicines Act. However, SaMD is not clearly captured by the current Medicines Act and is assumed to fall outside of New Zealand’s medicines regime.

What are the proposed changes?

The Bill proposes new regulatory hurdles for standalone health software by:

• extending the scope of “medical device” to include a new concept of “software as a medical device”, defined as “software that meets the definition of a therapeutic product without any associated hardware (other than an unrelated device that is needed solely to present a user interface)”; and
• extending the market authorisation regime to medical devices (currently, the supply of medical devices in New Zealand is not subject to Medsafe approval and new devices only need to be notified on a public register).

The Bill also clarifies the distinction between SiMD and SaMD by specifying that SaMD excludes software “intended for use as a component part of a product that is a medical device”.

Under the Bill, SaMD is subject to similar requirements as are currently imposed on medicines and medical products. Pre-market approval from the regulator will be required to:

• “import” SAMD – by making software developed outside NZ available to persons in NZ;
• “export” SaMD – by making software developed in NZ available to persons outside NZ; and
• advertise SaMD products in or outside New Zealand.

Like other medicines and medical products, under the Bill SaMD will require a NZ-based “sponsor” which has primary responsibility for ensuring the software complies with the conditions of its authorisation. Certain obligations will also apply to the “responsible manufacturer”, being the person or company primarily responsible for its development. In a software context this is likely to be the company that holds itself out as the owner of the software and/or under whose name or brand the software is supplied. The sponsor and manufacturer (if separate entities) must also have a contractual relationship in place which enables the sponsor to comply with its obligations under the Bill.

Is my software by captured by the Bill?

The Bill resolves some of the current uncertainty about the application of the Medicines Act to software. However, the proposed definition of “software as a medical device” remains open for interpretation and Parliament is yet to provide detailed guidance on this issue.

Standalone software will fall within the proposed regime if it is a “therapeutic product”, being a product intended for use in, on, or in relation to humans for a therapeutic purpose. Therapeutic products may also be specified in regulations – although none have been proposed with the Bill so far.

A “therapeutic purpose” includes any of the following:

• preventing, diagnosing, monitoring, alleviating, treating, curing, or compensating for a disease, ailment, defect, or injury;
• influencing, inhibiting, or modifying a human physiological process;
• testing the susceptibility of humans to a disease or an ailment;
• influencing, controlling, or preventing human conception;
• testing for human pregnancy;
• investigating, replacing, modifying, or supporting part of a human’s anatomy;
• investigating a human physiological process;
• supporting or sustaining human life;
• providing vitamin, mineral, or other human nutritional supplementation;
• maintaining or promoting human health;
• disinfecting medical devices; and
• a purpose connected with a purpose referred to above.

Some of these purposes are very broad and it is possible that, without further clarification or regulations, any software application that promotes health and wellbeing (such as a step counter, fitness tracker or general information service) could be subject to the proposed rules.

In practice, it is likely that the Bill will be refined, or interpreted, along similar lines to Australia’s Therapeutic Goods Act 1989 (“Therapeutic Goods Act”), which has undergone recent, similar reforms with respect to “software based medical devices”. Certain classes of software are excluded from the regulatory requirements for medical devices, or are exempt from certain requirements only. The Therapeutic Goods Administration (“TGA”), Australia’s therapeutic goods regulator, has also published detailed guidance on the software it considers to be captured by these two categories. Based on this guidance, and underlying legislation, the Australian position is as follows:

Excluded software

Consumer health life-cycle prevention, management and follow up

Software that falls within one of the following categories:

• Software that is intended by the manufacturer to be used by a consumer:

• for the self-management of an existing disease, condition, ailment or defect that is not a serious disease or serious condition, ailment or defect;
• to promote or facilitate general health or wellness by measuring or monitoring (through non-invasive means) a physical parameter, such as movement, sleep, heart rate, heart rhythm, temperature, blood pressure or oxygen saturation; or
• to improve general health or wellness by coaching, or encouraging behavioural change, in relation to personal or environmental factors, such as weight, exercise, sun exposure or dietary intake;
• but does not provide information that re-quires the interpretation of a health professional, nor is it intended to provide a diagnosis, treatment, or a specific recommendation or decision about the treatment of a serious condition.

• Software intended to be used as patient reported outcome measures (PROMs) and patient surveys, provided there is no diagnostic, monitoring, prediction, treatment or recommendation component to this software.

Digital mental health

Software that is a digital mental health tool (including a cognitive behaviour therapy tool) based on established clinical practice guidelines that are referenced and displayed in the software in a manner that is reviewable by the user. As an example, the TGA explains that a smartphone app for treatment of anxiety that does not show the clinical guidelines on which the treatment is based, will not be excluded.

Enabling technology for telehealth, healthcare care facility management

Software that falls within one of the following categories:

• communication software for enabling telehealth consultations;
• software for administering or managing health processes or facilities;
• software for storing or transmitting patient images;
• software for providing alerts or information to health professionals in relation to patient care, provided health professionals must exercise their own judgement in determining whether to action the alert or information;
• clinical workflow management software;
• ‘middleware’ that controls in-vitro diagnostic devices or medical devices but does not recommend a diagnosis or make treatment decisions.

Digitisation of paper-based or other published clinical rules or data

Software that falls within one of the following categories:

• simple calculators that use relevant published clinical standards or authoritative sources to make or display calculations, but are not intended to control the administration of a calculated dosage;
• software intended to be used in clinical practice to collect, use, disclose and otherwise manage patient clinical data within or between healthcare facilities (e.g. electronic patient records and health records).

Population-based analytics 

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.

Laboratory information management systems and laboratory information systems

Software that allows a laboratory to automate workflows, integrate instruments, manage samples and deliver reports, but not to generate diagnostic outputs.

Exempt software

Clinical decision support system (CDSS) software

Software that meets the following three criteria (subject to exemption conditions being met):

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.

It is unclear whether New Zealand will follow the Australian example, but this seems highly likely given the similarities between the two regulatory frameworks. The TGA’s approach is also aligned with agreed principles issued by the International Medical Device Regulators Forum, members of which include the TGA and regulators from the EU, UK and US.

Implications for the software industry

Until further clarification is provided about the intended scope of the Bill, any software with a health application could be impacted. Companies that commission, design, develop, distribute and resell health software in or outside of New Zealand should consider whether their products meet the threshold for SaMD, and what the consequences could be for their organisation as well as other members of their supply chain.

In practice, for many already operating in the health software space, the proposed regime may pose only an administrative burden as opposed to subjecting them to new, more onerous product safety standards. NZ companies operating in the EU, US, UK or Australia are likely already subject to pre-market approval requirements. Equally, non-NZ companies offering SaMD in NZ may be subject to these requirements in their ‘home’ countries.

Increased regulation of SaMD could have a significant impact on NZ providers that are yet to go to market, or do not operate outside NZ. We also expect that regulator approval will be conditional upon compliance with applicable product safety and information security standards, which could include the Privacy Act 2020 and Health Information Privacy Code 2020. This means that even experienced health software providers may need to consider whether they are demonstrably compliant with NZ’s privacy laws, which are not identical (but are often similar) to the privacy laws of other jurisdictions, including Australia.

Talk to the experts

Our specialists Hayley Miller, Campbell Featherstone, David Lewis and their teams are on hand to assist and have extensive experience advising health software providers, and distributors of medical devices, on their regulatory obligations in New Zealand. They also have particular expertise in advising software providers on all things privacy and cybersecurity.

This article was written by Ashleigh Ooi, an associate in our commercial, technology and privacy team.