As more and more medical devices utilizing network connection technology are developed, cybersecurity will continue to grow in terms of importance and focus among regulators and manufacturers.
Many connected devices store or transmit patient data for which there is an expectation of both privacy and accuracy. Any sort of cyber threat could have consequences for the integrity of the data and the privacy of the patient.
In fact, when building a connected device, it’s recommended to always assume your device will be the subject of some kind of cyber threat in order to mitigate such events from ever taking place. Regulatory bodies across the world have developed standards and requirements to guide medical device manufacturers with creating safe and secure connected devices.
In this article, we’re going to look at some key regulatory guidelines for medical device cybersecurity found in IEC 62304, ISO 14971 and FDA guidance documents, which represent industry best practices and current manufacturing standards:
IEC 62304 is known as a functional safety standard. It covers safe design and maintenance practices for medical device software throughout the entire product lifecycle. This standard applies to both SaMD (Software as a Medical Device) and to medical devices that have software embedded as part of their functionality.
One of the best cybersecurity practices from IEC 62304 is that safety should be built in from the beginning of development. The software safety classification guidelines from the standard determine the safety-related processes you’ll need to follow. Your classification will impact the requirements of your entire software lifecycle.
The three safety classes for software-related medical devices are:
Class A: No injury or damage to health is possible.
Class B: Injury is possible, but not serious.
Class C: Death or serious injury is possible.
There are nine parts to IEC 62304, which operate under the assumption that a quality management system is being used and, of which, there’s a risk management system in place.
The nine parts of IEC 62304 are:
Part 1: Scope.
Part 2: Normative references.
Part 3: Terms and definitions.
Part 4: General requirements.
Part 5: Software development process.
Part 6: Software maintenance process.
Part 7: Software risk management process.
Part 8: Software configuration management process.
Part 9: Software problem resolution process.
Part 5 of IEC 62304 delves into the software development process for medical devices. There are tasks that must be completed for each device class. Using common software development tools can help you to fulfill those requirements. For example, Class B and C software require tests for software requirements, which can be met by using a purpose-built tool.
Part 7 outlines requirements for software risk management. Essentially, you need to show that you’ve conducted a risk analysis and that you can demonstrate traceability from a hazardous situation to a risk control measure. This is where a traceability matrix is an essential tool to use.
In Part 8, medical device developers are cautioned against using SOUP (Software of Unknown Providence). This is third-party software, including any open-source libraries where anyone has access to the coding. It’s not that you can’t use it, but you must follow a rigorous screening process to prove that the software meets the coding guidelines and won’t leave you vulnerable to cyber threats.
Another critical component of Part 8 is how you manage change. Software often requires updates or changes, and you need to show you follow an appropriate process for managing changes, testing them, and mitigating risk.
The primary focus of ISO 14971:2019 is the international standard for medical device risk management. As a form of risk, cybersecurity for medical devices also falls under the ISO 14971 umbrella, particularly as it applies to patient safety.
ISO 14971 provides recommended guidelines for the application of risk management for medical devices (or SaMD) as a whole. The primary goal of the standard is to ensure a safe interaction between the device and the patient or end user.
Documentation is the key - you need to show how you have implemented safety-related procedures in various stages throughout the product lifecycle. This is closely related to the points covered in IEC 62304, which talk about the whole lifecycle of the software.
Risk analysis and mitigation are essential components of the risk management guidelines. For example, you should anticipate any way in which your connected device might fail and what the consequences of that failure might be. This helps you to build in any necessary fail-safes to minimize the potential for a hazard.
A technical report associated with ISO 14971 was published by AAMI, known as TIR57:2016, which outlines the principles for medical device security. This document bridges the connection between security risk and safety related risk management practices found in ISO 14971, as shown in the venn diagram figure below:
AAMI TIR57:2016
The main purpose of TIR57:2016 is to provide guidance for conducting cybersecurity risk assessments of medical devices and managing risks from security threats that could impact the confidentiality, integrity, and/or availability of the device or the information processed by the device.
IEC 80002-1:2009 for medical device software also provides guidance on the application of ISO 14971 to medical device software. This standard focuses on risk analysis, risk management, risk evaluation and risk control as it applies to medical device software.
FDA provides guidance to help medical device manufacturers design and maintain products that are cyber secure. The agency publishes regular guidance documents and informational articles on cybersecurity best practices that are free to the public.
Most notable of these FDA guidance documents are premarket management of cybersecurity in medical devices as well as postmarket management of the same. These guidelines are intended to assist with identifying issues related to cybersecurity that manufacturers should consider in the design and development of medical devices as well as in the ongoing, postmarket management of the devices.
The crux of these FDA guidelines is that manufacturers must develop a set of traceable, documented cybersecurity controls. Particularly, when it comes to the post-market environment, FDA also recognizes that cybersecurity is a shared responsibility between stakeholders of the medical device. For example, a healthcare facility that provides a connected device shares responsibility for cyber-safe practices with the manufacturer of that device.
With that said, you will also find guidance having to do with limited access to “trusted users only” and requiring appropriate authentication. FDA publishes a list of recognized consensus standards, of which include IEC 62304, ISO 14971, and the AAMI technical report.
In addition, FDA continues to emphasize the importance of managing cybersecurity across the entire software lifecycle in order to ensure devices are safe and effective for users.
Manufacturers of connected devices placed on the EU market should be familiar with more than just the new medical device regulations (MDR and IVDR). An accompanying guidance document, MDCG 2019-16, has been published which covers cybersecurity for software devices and provides manufacturers with guidance on fulfilling the cybersecurity requirements in the EU.
There are multiple touchpoints on cybersecurity within MX1 of the guidance document. These guidelines also provide a structure for designing devices with cybersecurity as a priority. General cybersecurity requirements include data protection, conformity assessment and postmarket surveillance.
According to these guidelines, design and risk procedures must account for cybersecurity. MDR outlines eight practices for cybersecurity management of your device:
Security Management – All security-related activities should be planned and documented.
Specification of Requirements – These must be defined in a similar vein to your software specifications.
Security by Design – Your design process should be in compliance with the device and incorporate cybersecurity.
Implementation – Cybersecurity design should be implemented properly. You also need to ensure any procedures on software releases are followed.
Verification and Validation Testing – Define these activities and tie them to the risk of your software, then performing validation testing.
Management Security – How you will handle any security issues if they do arise.
Update Management – Defining how you would assess any risks and roll out any updates.
Security Guidelines – Provide user documentation on how to operate the software with cybersecurity in mind.
Cybersecurity is a growing area of focus among regulators in the medical device industry, especially as more devices become network-connected.
Not only should you carefully scrutinize your medical device cybersecurity practices and take a risk management approach as a good practice measure, it’s also becoming a regulatory expectation. Greenlight Guru partners with word-class leaders in medical device cybersecurity, like Velentium, to help manufacturers further mitigate security risks.
You should have documented processes and procedures that outline your risk-based approach to device security throughout the product lifecycle in order to meet the common requirements found across all regulatory guidelines on cybersecurity.
Greenlight Guru is the best solution for full lifecycle management of connected medical devices. Users can easily demonstrate closed-loop traceability and securely access, store, and share documents and records within the Part 11 compliant platform. Get your free demo of Greenlight Guru.
Looking for a design control solution to help you bring safer medical devices to market faster with less risk? Click here to take a quick tour of Greenlight Guru's Medical Device QMS software