Health Hacking: Dealing with the cyber threat in digital health

Software and the electronic devices it controls, has become increasingly important in the healthcare industry over recent years. Digital health products, as they’ve come to be known, allow individuals to take a more active role in monitoring their health and fitness.

But as these devices continue to gain momentum, serious questions are being asked about the cyber security around them. First, can users be confident that their health information will be kept safe? And second, can users be confident that the device they’re using will continue to work reliably? Clearly these questions are even more important in the case of devices where the consequences of compromised operation are potentially personal injury or death.

Both the Australian Therapeutic Goods Administration (TGA) and the United States Food & Drug Administration (FDA) regulate certain types of software as medical devices under their respective therapeutic goods regimes.

A key pre-market issue in the regulation of medical software is cyber security. Consideration of cyber security at the pre-market stage (i.e. during design and development) is vital to minimise the risk of a cyber security incident, and also to ensure that the device can be sold in Australia.

When will software be regulated as a medical device?

In Australia medical devices are regulated under the Therapeutic Goods Act 1989 (Cth) (Therapeutic Goods Act).

Increasingly, devices falling under this legislation are being used to assist medical practitioners in their monitoring, diagnosis and treatment of their patients. Wearable devices, remote patient monitoring tools and sensors that track a patient’s consumption of their medication are all examples of the growing application of digital technologies in the health sector.

Unless an exception applies, software will fall under the definition of a “medical device” if the manufacturer intends for it to be used in the diagnosis, prevention, monitoring, treatment or alleviation of a disease.[1] This intention is ascertained from statements made by the manufacturer in labelling, instructions, advertising or in any other documentation about the software.[2]

For example, the following types of software are likely to be considered medical devices under the Therapeutic Goods Act:

• mobile phone apps that measure a user’s blood sugar level or blood pressure;

• x-ray image processing software; and

• diagnostic software.

Where an electronic device is controlled by such software, that device may (or may not) itself also be separately regulated as a medical device.

On the other hand, software that is only intended by the manufacturer to be used for presenting information (e.g. a health records management system or a dosage calculator) is unlikely to be treated as a medical device unless it incorporates a therapeutic function.[3]

Certain software exempted from FDA regulation

While consideration of the “intended use” of a product allows the Therapeutic Goods Act to apply flexibly to new technology, it is not always clear whether certain types of software (especially software used for “low risk” therapeutic purposes) will be regulated under the Therapeutic Goods Act.

In the United States, greater clarity on this issue has recently emerged with the passing of legislation that expressly clarifies the scope of the definition of a medical device as it applies to software.

The 21st Century Cures Act ,[4] which was signed into law on 13 December 2016, expressly exempts five categories of software from the definition of a medical device, being software which would otherwise fall within the definition of a medical device but which Congress has decided is low risk and will not be regulated as a medical device. These categories include:

• software for transferring, storing or displaying medical information about an individual; and

• software used to analyse medical information which also provides recommendations to a health care professional about the prevention, diagnosis or treatment of a disease. Importantly, the software cannot be designed such that the health care professional will primarily rely on any of the recommendations – the software must enable health care professionals to independently review the basis for each recommendation.

Software that falls within these exemptions is not subject to FDA regulation.

Cyber security risks for medical software

Given that medical software is often connected to the Internet or networked with other devices, cyber security is a critical consideration. It is also an issue that is receiving increased attention from the TGA and the FDA.

There are two key risks that need to be considered and managed in relation to the cyber security of medical software. The first is that sensitive health information may be lost or accessed by unauthorised parties. The second is that the function of the device could be compromised if there is a cyber security incident.

While many manufacturers of medical software appreciate their post-market cyber security obligations (e.g. to monitor their software and issue patches to solve defects and vulnerabilities), the pre-market requirements can often be overlooked.

Broadly, at the pre-market stage a manufacturer is required to take steps in its design of the software to mitigate the risk of a cyber security incident occurring throughout the lifecycle of the device (i.e. to both protect personal information and to protect the functionality of the device).

From a regulatory perspective, consideration of these cyber security risks is necessary to ensure that the device meets the “essential principles” for safety and performance as required under the Therapeutic Goods Act.[5] A manufacturer must ensure that it has a record of the steps it has taken to ensure that the software complies with these essential principles.

For many devices, this information may need to be disclosed to the TGA as part of the conformity assessment process.

Failure to take account of cyber security

If a developer of medical software fails to properly design and build their product in a manner which takes account of their cyber security obligations:

1. there is a risk that the device will not be permitted to be sold in Australia[6];

2. there is a risk that a manufacturer of a the device will contravene Australian Privacy Principle 11 for failing to implement reasonable steps to protect personal information from interference, loss or unauthorised access.[7] A serious or repeated interference with privacy can lead to a civil penalty of up to $2.1 million.

3. if the device is supplied in Australia, there is a risk that the manufacturer will contravene its obligations under the Therapeutic Goods Act, including the obligation not to supply a device that does not comply with the “essential principles”.[8] The maximum civil penalty for failing to comply with these requirements is $10.5 million.[9]

Cyber security – How can you get it right?

Consideration of cyber security at the design and development stage is vital. Not only will it ensure that the device can be legally supplied in Australia, it will also minimise the risk of non-compliance with the Therapeutic Goods Act and the Privacy Act 1988 (Cth).

The TGA recommends that software developers should perform risk assessments on their medical software as part of the design and development process by examining the specific clinical use of the software in the host environment.[10]

In order to demonstrate compliance with the essential principles for safety and performance under the Therapeutic Goods Act, developers should document their approach to cyber security in writing.

In general, relevant documents may include information about the way in which the software has been designed to ensure that it secures and protects personal information from unauthorised access, and to ensure that the function of the software will not be adversely affected if it is subject to a cyber security incident.

The TGA hasn’t published specific guidance about the information it requires in relation to cyber security. However, we expect that high risk medical devices (i.e. those used to treat or diagnose serious diseases) will need more information than lower risk devices to confirm that the software meets the essential principles.

The position in the United States regarding documenting the approach to cyber security is clearer. The FDA’s (non-binding) guidance document “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices” recommends that manufacturers keep a record of the following:[11]

• hazard analysis, mitigations, and design considerations regarding intentional and unintentional cyber security risks and controls of the medical device;

• a traceable matrix that links actual cyber security controls to the cyber security risks considered;

• a summary of the plan to provide patches and software updates as needed throughout the lifecycle of the medical device to continue to assure its safety and effectiveness;

• a summary describing the controls that are in place to ensure that the medical device will maintain its integrity (including that it will be free of malware);

• device instructions for use and product specifications related to recommended cyber security controls appropriate for the intended use environment; and

• a record of the design/bug log may also be useful for higher risk medical software.

Manufacturers of medical software that have not addressed and documented these issues in the design of their product risk the device not being cleared for sale in the United States.

Key considerations for software developers

When designing software, developers should consider whether their software will be regulated as a medical device under the Therapeutic Goods Act. Indeed, developers should consider at the outset how the claims they make about their software and their instructions for the use of their software might affect the way in which their product is regulated in relevant markets.

If the software is a medical device, developers must consider and document their approach to cyber security. This should occur at an early stage of the design and development process.

Although the FDA’s guidance on premarket documentation is not binding in Australia, developers of medical software should be aware of its existence. The guidance will be of critical importance to Australian software developers looking to take their software to the United States market. The guidance also provides a useful insight into the types of information that the TGA may consider relevant to demonstrating that the software complies with the essential principles.