Intertech Engineering Associates, Inc.

Medical Device Validation Series. Part 1 of 4

Medical Device Validation Series. This is part one of a four-part series on medical device validation practices.

Part 1, Introduction

The Food and Drug Administration (FDA) pays special attention to software because it is now embedded in a large percentage of electromedical devices, and the amount of device functionality controlled by software is continually growing. Software also controls many of a medical device manufacturer’s design, development, manufacturing, and quality processes, regardless of whether software is a part of the manufactured device.

Software failures often can be invisible and difficult to detect; thus, these failures can have disastrous consequences on the operation or quality of medical devices. For this reason, the FDA specifically requires validation of both device and quality-system automation software. Validation activities are meant to keep defects from getting into the software, as well as to detect and correct any defects that do end up in the software.

The FDA’s control over software used by medical device manufacturers is detailed in the Quality System Regulations (QSRs) found in FDA regulation 21 CFR 820. Software regulations focus on the development and use of two large categories: (1) software that is part of the device being manufactured and (2) software that is used to design, develop and manufacture the product or otherwise automate any part of the quality system.

Guidelines for complying with the FDA’s regulations are published by the agency as a “Guidance Document”. These documents are updated periodically, and new a guidance is issued as the need arises. While compliance with the guidelines is voluntary, the device manufacturer should be prepared to explain and defend any deviation from the guidances.

The most important FDA guidance available for the validation of software is the General Principles of Software Validation (GPSV), and can be obtained for free from the FDA’s website (https://www.fda.gov/downloads/MedicalDevices/…/ucm085371.pdf ). This is a “must read” for all software engineers and quality engineers working with software in the medical device industry.

From: Vogel, David A., Ph.D. “Validating Medical Device Software Includes and Goes Beyond Testing.” Medical Product Outsourcing Mar. 2006

The Essential Performance SNAFU

The Essential Performance SNAFU:

Defining what Essential Performance is for a medical device is a challenge, but the definition is especially challenging and often confusing when software is part of the product. This article series is intended to share what is happening in the industry once Essential Performance is defined, and provide some guidance on how to address compliance and safety avoiding the snafu’s we have observed in this process.

The compliance community has been using the Essential Performance (EP) to focus testing and evaluation of medical products since the 3rd edition of IEC60601-1 (published in 2005). Some medical device manufacturers are fortunate enough to have their Essential Performance defined for them by Particular standards if they are available for their medical device. Those less fortunate, who are still defining their products, are often challenged to determine what is essential.  Often the manufacturer is left confused and industry test houses are not helping manufacturers make decisions to assure their device is safe when it comes to matters relating to complex devices containing software that have no EP or if they haven’t defined or understood the aspects of the software that is EP.

Part 1: IEC60601-1 Essential Performance (EP) and Basic Safety (BS) Definitions and Origins

When did EP become required and why?

The National Committee issued the 3rd Edition of IEC60601-1 in 2005. This 3rd edition was driven by the committee’s desire to address the perceived end users need to ensure that both Basic Safety and Essential Performance together be considered in one standard for medical devices.  This recognition meant that separate handling of Basic Safety and Performance, as is the case with standards of other (non-medical) equipment, would be ineffective in addressing the hazards resulting from the inadequate design of medical equipment.

What is the definition of EP and its impact?

The IEC60601-1 standard defines measures to apply in the design and evaluation of a medical device intended to provide a degree of confidence the device operates safely.  Specifically, the measures in the standard are intended to support that the device demonstrates Basic Safety and meets its Essential Performance during operation. Basic safety refers to controlling the risk of physical hazards such as electrocution, burns or other physical injuries that the device could cause.  Essential Performance relates to controlling the risk of operational hazards that can arise if the device does not operate within performance expectations. Manufacturers are directed per IEC60601-1 to determine what the Essential Performance characteristics are for their medical device, through analysis and an understanding of risks.

Once the Essential Performance for a medical device is defined, many clauses in the standard identify specific handling and testing of the device to ensure that the device operation does not impact this defined essential performance such that a potential hazard can be created. The definitions provided in the standard are listed below:

Essential Performance is defined per IEC60601-1 section 3.27 as:

“Performance of a clinical function, other than that related to Basic Safety, where loss or degradation beyond the limits specified by the manufacturer results in an unacceptable Risk.

Note Essential Performance is most easily understood by considering whether its absence or degradation would result in an unacceptable Risk.”

Basic Safety is defined by clause 3.10 of IEC 60601-1 as:

“Freedom from unacceptable risk directly caused by physical hazards when ME Equipment is used under Normal Condition and Single Fault Condition”

IEC60601-1 is referred to as the General standard.  Within the series, there are collateral standards and particular standards. Collateral standards are semi-horizontal standards that cover other pertinent topics such as EMC, Usability or Alarms. Particular standards, are standards that have additional applicable clauses based on the type of medical device, such infusion pumps or hemodialysis equipment. Not all devices have a Particular standard.  Particular standards end in a “-2” and are often referred to as “dash 2” standards. The Particular standard provides aspects of essential performance to be considered in the design and evaluation.

If there is no dash 2 standard available for the class of devices, the manufacturer must define for themselves what is Essential Performance for their medical device. The definition (in clause 3.27 of IEC60601-1) guides manufacturers and test houses to conclude that all unacceptable RISK is characterized by the Essential Performance which is the collection of device functions identified as “clinical function” and Basic Safety.  An example would be infusion pumps delivery accuracy.

The definition of Essential Performance and the guidance provided to identify Essential Performance in the standard has posed challenges for manufacturers. This challenge becomes evident in asking this question: Can there be a functional failure that is not of a clinical function and also is not related to Basic Safety? To answer this question, a risk analysis of the final product and its software is necessary. Shortcutting this question and necessary risk analysis would put medical device users and patients at risk.

One topic of particular concern to medical device manufacturers that have devices with software in them is:  “Does Essential Performance impact what we need to do for software?”. Certainly, if risk analysis identifies failures to software that can lead to a risk to the patients or users, then software practices such as those in IEC62304 can be applied as well as software validation. However, there exists a perceived loophole in IEC60601-1 that may lead manufacturers to conclude, based on the definition of the device’s Essential Performance, they do not need to include software validation nor comply with IEC62304 during software development. This perceived loophole all rests on what manufacturers choose to declare as Essential Performance or more importantly what they choose not to declare as Essential Performance. We will further discuss this loophole and how to define Essential Performance for a device in a future part of this article series.

The CE Mark, the MDD (soon to be MDR) and Software Validation?

In the European Union (EU) manufacturers need a CE mark to legally market their medical devices. To receive a CE mark the device will need to be certified to internationally recognized standards identified as a part of the manufacturers’ technical file. IEC60601-1 is a typical standard referenced for medical electrical equipment and systems as well as ISO14971 which is the standard typically utilized for medical device risk analysis. Manufacturers are also obligated to determine which Medical Device Directive (MDD) is applicable to them and certify to compliance for this, which includes having processes in place to meet the directive. IEC60601-1 and ISO14971 both include clauses addressing software. The medical device directive will take precedence over voluntary standards. It is important to recognize that the current Medical Device Directive, Council Directive 93/42/EEC in M5 clause 12.1a, and the new Medical Device Regulation defined in Annex I, clause 17.21, requires software validation for medical devices (regardless of what is Essential Performance for the device).

Medical Device Cybersecurity Introduction and Attack Types

Medical Device Cybersecurity Introduction and Attack Types

Medical device manufactures have been aware of the importance of Cybersecurity for several years and the FDA has been publishing guidance on it since 2005.

The responsibility for cybersecurity is shared among the various stakeholders one of whom is the medical device manufacturer. Device manufacturers have recognized both the business and regulatory imperatives to address this through the design and development process.

The FDA has indicated through the cybersecurity guidance documents and a publication that it feels the responsibility for the manufactures to address cybersecurity is implied in the Quality System Regulations (QSRs). Specifically, the need for manufactures to assess cybersecurity risk and develop product requirements to address any vulnerability as part of software validation and risk analysis.

Several of the FDA guidance documents recommend that device manufacturers develop a set of controls to both assess and maintain functionality and safety in the presence of cybersecurity threats. This assessment is recommended to start during the development and encompasses the defining of “design inputs” related to cybersecurity.

Like other risk management perspectives, business and product, addressing cybersecurity needs to be considered throughout the development process.

To understand how a company should consider approaching these regulatory requirements it is helpful to start by understanding the potential motivations and nature of the attacks seen to date. Although we should anticipate that new attack methods will be developed, minimally we need to address known methods.

Learn More “Medical Device Cybersecurity Introduction and Attack Types”