Intertech Engineering Associates, Inc.

The Essential Performance SNAFU part 4 of 4

Actual cases and what manufacturers can do to avoid a SNAFU

Intertech Engineering Associates Inc. has seen a recent trend of problems manufacturers are experiencing that are related to the consequences of decisions made (SNAFU’s) after Essential Performance is defined. Unfortunately, guidance is not clear to manufacturers and some test houses might be making matters worse by not providing clear interpretations to the manufacturers.  Here are two examples of cases Intertech has encountered over the last year.


Observation Case 1: CE Marked Device From Outside of the US, Missing FDA Expected Software Validation

Medical device manufacturers has received a CE mark, are running into trouble when trying to bring their devices into the US, when software is part of the device.  The products are getting caught up in the FDA 510(k) clearance process and are deemed to not have adequate software documentation.


Intertech has been assisting clients, who need to address FDA deficiencies after withdrawing their submissions as a result of receiving multiple questions from the FDA. In some cases, manufacturers are interpreting (per the IEC 60601-1 standard) that if the defined essential performance does not include the product software, that software validation is not required.  Interpretation of clause 14 (PEMS) ofIEC60601-1 is not what drives the FDA 510(k) review process.  The FDA still expects not only a process for software development to be followed but the software outputs from this process to be fully validated, specifically the product software, regardless of whether the software is part of Essential Performance.


The FDA has indicated, as of 2015, 69% of 510(k) submissions result in AI (Additional Information) requests from the FDA. A prior FDA analysis of review times concluded that up to 20% of the submissions have deficiencies with a key finding that the software documentation is inadequate. 1


If medical devices are first marketed outside of the US and have the software but don’t have software validation, they will have problems getting FDA clearance to market in the US.


Observation Case 2: Essential Performance Replacing Risk Analysis

Manufacturers and some test houses are determining that the Essential Performance characteristics are the same as the identification of functions that require risk controls. In this case, a medical device manufacturer can conclude that if software controlled functions are not part of what is deemed Essential Performance or Basic Safety in a medical device, the software itself need not require risk analysis. This approach, in essence, replaces (or would be in conflict with) further risk review of the software as suggested by ISO14971 (Medical devices — Application of risk management to medical devices), which requires an evaluation of hazardous situations and faults that may arise from software. Additionally, hazard analysis is necessary to support safe software as described in the FDA software validation guidance (General Principles of Software Validation).


Intertech is finding that manufacturers are relying solely on the process of defining Essential Performance and not performing functional failure (safety) analysis of their software design or implementation. Failing to analyze fault conditions to identify the hazard or hazardous conditions is a necessary part of risk analysis, and if manufacturers avoid software fault analysis, because a top-down determination of what is essential performance, potential hazards will be missed and be unmitigated. In addition to the safety concerns posed by skipping a software level risk analysis, this poses a compliance issue with the FDA and with the company’s notified body caused due to the missing analysis.


The possibility of cutting short a risk analysis task is appealing to a manufacturer,  even more so if a test house suggests some tasks are not required. Cutting tasks during the certification or clearance step in the process is easily perceived as a budgetary advantage, particularly since the compliance tasks budgets are typically underestimated and the schedule is tight at the end of projects.


Another situation Intertech is encountering is if the medical device software is not considered a part of Basic safety or Essential Performance,  manufacturers and some test houses are deciding that IEC 62304 (Medical Devices – Software Lifecycle Processes) as well as IEC60601-1-8 (General requirements, tests, and guidance for alarm systems in medical electrical equipment) may not apply. Currently, IEC62304 is an FDA recognized standard used to define the activities necessary in software development and IEC60601-1-8 is the standard that defines requirements for alarm systems. Neither of these standards specifically states that product software needs to be part of Basic Safety or Essential Performance as a prerequisite for compliance.


Tactics to avoid the SNAFU

There are some steps manufacturers can take to avoid the pitfalls and improve product quality. Consider the following takeaways to protect you, as it relates to software and essential performance:


Basic Safety and Essential Performance alone is not enough

Basic safety and essential performance are important characteristics for compliance and are key drivers for IEC60601-1 compliance, but they are not the only things that should give manufacturers confidence their product is safe. Software validation, proper risk analysis, software development process and basing decisions via utilization of the risk management process in addition to the compliance activities.


Perform Software Validation

Software validation is not waivable in any medical device. The selection of software validation activities for medical device software should be commensurate with the complexity of the software design and the risks associated with its implementation and the impacts on the intended use.


Software Validation is not just testing

Software validation is not just testing; software validation is about building confidence in the software, which gives the manufacturer, and the regulator confidence in the medical product. The process of validation and building confidence includes addressing activities of a software development lifecycle applied during and after the software is developed. David Vogel highlights in chapter 3 of his textbook, (Medical Device Software Verification, Validation, and Compliance), which software validation is about building confidence that is driven with the philosophy of two prongs of confidence building which include prevention as well as defect elimination.


Perform software safety analysis

Manufacturers developing medical devices with software should put into place, or seek a supplier that has in place, a process to analyze software and evaluate the consequences of software failure on the system during the software design and implementation efforts. This analysis is to be performed on medical device software regardless of the essential performance characteristics, device classification or the software level of concern.


Manufacturers are accountable for product safety

Manufacturers should remember that they are responsible and accountable for their product safety, not the test houses used to provide certifications to standards. If interpretations from a test house do not seem appropriate, question the rationale, as many good test houses are open to the discussion and providing rationale. If the rationale or answers to questions on interpretation to standards from a test house does not result in an agreement, contact your notified body or seek alternative input from a recognized authority.