Featured Product
This Week in Quality Digest Live
FDA Compliance Features
Jennifer Chu
Findings point to faster way to find bacteria in food, water, and clinical samples
Matthew M. Lowe
Take this opportunity to prepare for the future
Etienne Nichols
QMSR for medical device companies
Kari Miller
CAPA systems require continuous management, effectiveness checks, and support
Etienne Nichols
The answers will reveal the truth about your product and get it to market faster

More Features

FDA Compliance News
Facilitates quick sanitary compliance and production changeover
Creates one of the most comprehensive regulatory SaaS platforms for the industry
Company’s first funding round will be used to accelerate product development for its QMS and MES SaaS offerings
Showcasing tech, solutions, and services at Gulfood Manufacturing 2022
Easy, reliable leak testing with methylene blue
Now is not the time to skip critical factory audits and supply chain assessments
Google Docs collaboration, more efficient management of quality deviations
Delivers time, cost, and efficiency savings while streamlining compliance activity
First trial module of learning tool focuses on ISO 9001 and is available now

More News

Wade Schroeder

FDA Compliance

Risk Management for Medical Devices

Gleaning best practices from regulatory standards

Published: Thursday, September 2, 2021 - 12:02

As more medical devices using network-connection technology are developed, cybersecurity will continue to grow in 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—“Medical device software—Software life cycle processes,” ISO 14971—“Medical devices—Application of risk management to medical devices,” and FDA guidance documents, which represent industry best practices and current manufacturing standards.

Applying security standards from IEC 62304 to full medical-device software life cycle

IEC 62304 is known as a functional safety standard. It covers safe design and maintenance practices for medical device software throughout the entire product life cycle. This standard applies to both software as a medical device (SaMD) 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 affect the requirements of your entire software life cycle.

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 along with it, 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 must 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 software of unknown provenance (SOUP). 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.

Greenlight Guru is the only medical-device success platform (MDSP) that offers Intelligent Document Management, the industry’s first solution that leverages artificial intelligence (AI) and machine learning (ML) to identify documents, product development artifacts, and quality events impacted by a change.

Managing security risks according to ISO 14971

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 must show how you have implemented safety-related procedures in various stages throughout the product life cycle. This is closely related to the points covered in IEC 62304, which talk about the whole life cycle 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 the Association for the Advancement of Medical Instrumentation (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 below:

AAMI TIR57:2016
Image source: 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 affect the confidentiality, integrity, and availability of the device or the information processed by the device.

IEC 80002-1:2009—“Medical device software—Part 1: Guidance on the application of ISO 14971 to 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 guidance on managing cybersecurity in medical devices

The U.S Food and Drug Administration (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 during 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 postmarket environment, the 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, which includes IEC 62304, ISO 14971, and the AAMI technical report.

In addition, the FDA continues to emphasize the importance of managing cybersecurity across the entire software life cycle to ensure devices are safe and effective for users.

Following cybersecurity practices for software devices in the European Union (EU)

Manufacturers of connected devices placed on the EU market should be familiar with more than just the new medical device regulations and in vitro diagnostic regulation (IVDR). An accompanying guidance document, MDCG 2019-16—“Guidance on Cybersecurity for medical devices,” has been that covers cybersecurity for software devices and provides manufacturers with guidance on fulfilling the cybersecurity requirements in the European Union.

There are multiple touch points 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. Medical device regulations outline eight practices for cybersecurity management of your device:
1. Security management. All security-related activities should be planned and documented.
2. Specification of requirements. These must be defined in a similar vein to your software specifications.
3. Security by design. Your design process should be in compliance with the device and incorporate cybersecurity.
4. Implementation. Cybersecurity design should be implemented properly. You also must ensure any procedures on software releases are followed.
5. Verification and validation testing. Define these activities and tie them to the risk of your software, then perform validation testing.
6. Management security. How you will handle any security issues if they do arise?
7. Update management. Define how you would assess any risks and roll out any updates.
8. Security guidelines. Provide user documentation on how to operate the software with cybersecurity in mind.

Choose a cyber-secure solution to manage your medical device

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.

You should have documented processes and procedures that outline your risk-based approach to device security throughout the product life cycle to meet the common requirements found across all regulatory guidelines on cybersecurity.

Your risk management practices should include a robust solution for full life-cycle management of connected medical devices. Users must be able to easily demonstrate closed-loop traceability and securely access, store, and share documents and records within the Part 11-compliant platform.

First published on the Greenlight Guru blog.


About The Author

Wade Schroeder’s picture

Wade Schroeder

Wade Schroeder is a Medical Device Guru at Greenlight Guru with a noticeable enjoyment of medical device product development processes. As an electrical engineer by trade, he began his career developing medical exam procedure chairs and later designing IVD devices. He has been a risk management enthusiast since the beginning and enjoys helping customers develop design processes that their team can be proud of and enjoy. He believes the best part of working with customers is helping them implement a culture of true quality within their team.