The interconnectivity of diagnostic technology is revolutionizing healthcare – but also introducing significant risk. Here’s what you need to know about diagnostic device development in the era of cybersecurity regulations.

In July 2019, a mother gave birth to her daughter while the hospital’s internal computer network was down due to a ransomware attack. Her daughter was born with her umbilical cord wrapped around her neck – a condition that caused severe brain damage, and sadly, her eventual death nine months later.

According to reports, the heart rate monitor in the room registered signs of the fetus’s distress, but since the hospital computer network was down, the hospital staff were not notified of these warning signs.

Following the delivery, the attending obstetrician obtained the readout from the patient’s room and texted the nurse manager to say she would have performed a Caesarean section had she seen the results sooner.

This was the first case of an alleged death resulting from a ransomware attack on a hospital.

Without a doubt, the interconnectivity of diagnostic devices to both hospital information systems and the cloud brings tremendous opportunities for improved patient outcomes. However, with this opportunity comes a responsibility for device manufacturers and healthcare providers to protect against cybersecurity incidents. With greater connectivity, the potential impact and scale grows in magnitude. The connected diagnostic device of today is part of a larger ecosystem, with implications that reach beyond a single device to hospital-wide, and even worldwide.

The industry is taking notice. Regulatory bodies are rapidly developing processes to address the increased risk and frequency of sophisticated cyber-attacks, especially as medical industries, devices and patient welfare are increasingly being targeted. And hospitals and other health care organizations (HCOs) want assurance that devices comply with all regulations and cybersecurity best-practices.

Cybersecurity has become a priority diagnostic device product development consideration, just like traditional considerations such as reliability, feature set and cost.

There is no question that medical device cybersecurity is a life-or-death matter. The sophistication and gravity of cybersecurity attacks has been gradually increasing, disrupting delivery of patient care, causing delayed diagnoses, treatments, and even death.

Since the death of the baby born during the ransomware attack in 2019, additional incidents have occurred, including in 2021, when an unreported number of patients were prevented from getting cancer treatments at multiple locations due to a cybersecurity attack on the cloud infrastructure of an oncology provider.

In response to these incidents and many others, regulatory bodies and HCOs are putting in place new cybersecurity guidelines for device manufacturers. The US Food and Drug Administration (FDA) has dramatically increased its scrutiny of medical device cybersecurity – including their potential for compromising broader HCO networks.

The FDA has issued guidance regarding cybersecurity device design, labelling and documentation that is recommended to be included in premarket submissions for devices with cybersecurity risk. Per the FDA, this can facilitate an efficient premarket review process and help ensure that marketed medical devices are sufficiently resilient to cybersecurity threats.

The guidelines require manufacturers to:

• Take steps to assure that appropriate safeguards are in place to reduce the risk of failure due to cybersecurity threats;
• Ensure they are using “state of the art” security techniques; and
• Remain vigilant about identifying risks and hazards associated with their medical devices, including risks related to cybersecurity.

An HCO’s physical and data security is beyond manufacturers’ control. Instead, efforts should be focused on making your device a responsible part of the broader ecosystem and providing sufficient confidence for HCOs to integrate your device with their systems.

Given the criticality of cybersecurity in medical devices, the rapidly advancing state of the art of cybersecurity approaches and the vast array of security analysis frameworks available, the burden of ensuring a secure system can seem overwhelming. Trying to perform this analysis and retrofitting cybersecurity to a device as a single analysis towards the end of development is a recipe for poor outcomes.

Instead, consider a best-practice approach of integrating cybersecurity thinking throughout the entire development process, from initial concept development through to post-market monitoring.

No connected diagnostic or medical device operates alone. It is just one element of a complex technological and logistical ecosystem and, as a manufacturer, you need to understand that ecosystem. Start your planning during very early product definition and continue it throughout.

Only by integrating cybersecurity analysis into the entire development process is a meaningful evaluation of the nature and magnitude of the threats possible.

Below are just a few considerations for cybersecurity analysis in the product development process:

• Assess device market and intended use – a major trauma center and a small, single-doctor clinic will have vastly different requirements and expectations.
• Consider device concept and device requirements – weigh security trade-offs and expectations stemming from this earlier analysis. For example, will the target users expect lab information systems (LIS) connectivity, or perhaps WiFi connectivity to tablets or mobile phones?
• Evaluate the severity of run-time hazards – consider the risk of harm or death to patients either through malfunction or non-operation.
• Protected health information/ personally identifiable information – consider the need to particularly protect personal or protected health information.
• Protect intellectual property (IP) – cybersecurity attacks can steal IP such as algorithms, barcode decryption secrets, and software encryption keys.

Product documentation should clearly communicate:

• How to effectively use the security features provided;
• The trade-offs of disabling provided security features; and
• The assumed HCO responsibility for security of the system.

This communication is what enables the HCO to effectively manage risk, by minimizing the chance of a security breach – and if one occurs- helping to reduce the chance of serious harm.

Once cybersecurity considerations are properly evaluated and aligned with regulations and expectations of the intended ecosystem, manufacturers have the decision-making framework to make informed trade-off decisions. This can allow for reduced overall development costs and better market penetration through closer alignment to end-user needs.

For example, consider a benchtop device that performs tests using whole blood, targeting small and medium HCOs. It connects to the HCO’s network either through ethernet or WiFi and uses this connection to check for software updates. Additionally, it integrates with the HCO’s LIS for receiving test orders and transmitting results.

Some development trade-offs can be illustrated through the following examples:

• Regulatory bodies expect “state of the art” security options, so you may choose to support WPA2 (Wi-Fi Protected Access 2) for the WiFi security. When attempting to sell into developing countries, you may discover that they only support older WEP (Wired Equivalent Privacy) security due to lack of modern equipment. However, supporting WEP introduces a security risk that may make your instrument unappealing to HCOs that require more advanced security.
• LIS standards allow encryption, but many LIS vendors do not implement any form of encryption. Additionally, many hospitals are slow to upgrade and are still running old LIS systems without support for encryption. Since demand is low, you may decide to save time by not implementing a feature that most users will not want or use. However, if an HCO with a LIS that supports encryption has a data breach through the unencrypted LIS connection, there may be lasting repercussions for your organization, including reputational damage. As a result, HCOs may be less willing to integrate your device into their organizations.

Cybersecurity is more than just removing features or making development trade-offs; sometimes you need to add additional features to mitigate risks.

Let’s look at these examples:

• If device results are time-critical and the instrument is undergoing a Distributed Denial of Service (DDoS) attack, you may want to drop network connections to operate in a reduced functionality mode. This can allow time-critical tests to run uninterrupted.
• Results export is often considered a critical feature, especially if there is no network connectivity. Since results contain Protected Health Information (PHI) and Personally Identifiable Information (PII), for example patient name and date of birth, this is a potential risk of Health Insurance Portability and Accountability Act (HIPAA) Unfortunately, you cannot just remove this feature as it is required for traceability and auditability by HCOs. Since this risk cannot be mitigated by the usual means, consider creating an immutable audit log of exports and a notification system. In this way, if a data breach is detected, it can be identified and those affected can be notified.

In today’s challenging, highly dynamic cybersecurity environment, it’s critical to incorporate secure development and cybersecurity considerations throughout the entire product development lifecycle and beyond into post market monitoring, updates and mitigations.

With the rapidly changing cybersecurity landscape and the wide range of frameworks and regulatory requirements, developing a secure device can seem like a daunting prospect. However, by working collaboratively with a medical device development partner experienced in designing and implementing up to date cybersecurity measures for a full range of connected devices, you can have increased confidence that your device will be safe, reliable and secure.