FDA Drafts Guidance on Device Production and Quality System Software Assurance

Regulatory news

| September 12, 2022 | By Jeff Craven

The United States Food and Drug Administration (FDA) has published draft software assurance guidelines for computer and data processing systems associated with the production of medical devices.

The FDA said the draft guidelines are a document for industry and agency personnel to evaluate computer software with “a risk-based approach to establishing confidence in automation used for production systems or quality, and identify where additional rigor may be appropriate”. Additionally, the document describes how stakeholders can validate the software and determine that it is being used appropriately.

The guide will eventually be a complement to the final guide “General principles of software validation” published in January 2002 and supersedes section 6 of this guide, which focuses on the validation of automated process equipment and quality system software.

The agency said that using this IT software risk-based framework would help meet the requirements of 21 CFR 820.70(i), which dictates maintenance schedule requirements for medical equipment under the jurisdiction of the FDA, while assisting manufacturers with assurance activities and ensuring product quality. “The FDA believes that these recommendations will help drive the adoption and use of innovative technologies that promote patient access to high-quality medical devices and help manufacturers keep pace with the dynamic and rapidly changing technology landscape. , while promoting compliance with laws and regulations implemented by FDA,” they wrote.

In the draft guidance, the FDA outlined a computer software assurance risk framework that includes evaluating the intended use of computer software, using risk-based analysis for software that is part of of the production or quality system to identify the right assurance activities based on the level of risk and the creation of a record of the system to document that it is operating as intended.

The FDA makes a distinction in the guidelines between software that is a direct part of the production process and software in support of the production or quality system. The FDA has declared that software is directly part of the quality process or system for the production of medical devices if it is part of the automation process, inspection, testing, or data collection during production ; is used to automate processes, data collection and processing in quality systems or is used in quality system regulation to maintain a quality record.

Software is used to support the process if it is part of the software testing or monitoring system that is directly part of the production or quality system and part of the record keeping automation process, rather than maintain a quality record, the FDA said.

The agency recognized that software may have more than one intended use, which may carry different risks depending on its characteristics, functions and operations within a production or quality system. “The FDA recommends that manufacturers review the intended uses of individual features, functions, and operations to facilitate the development of a risk-based assurance strategy,” they wrote. “Manufacturers may decide to conduct different assurance activities for individual features, functions, or operations.”

Once software has been classified as part of the production or quality system associated with a medical device, stakeholders should use risk-based analysis to identify appropriate assurance activities for the software. This includes identifying “foreseeable” risks to the software and whether the failure could prevent the software from performing as intended, which could impact production or the quality system (process risk) or cause a medical device to fail. injure a patient or user (medical device risk).

“Specifically, the FDA considers a software feature, function, or operation to be of high process risk when its failure to perform as intended may result in a quality issue that predictably compromises safety, meaning a risk increased for medical devices,” the agency said.

High process risks are typically software features, functions, or operations that maintain process parameters; use limited human intervention to measure, inspect, analyze or accept a product or process; correct or adjust process parameters with limited human intervention; issue instructions to a patient or user of a medical device; or automates data that monitors or tracks the safety and quality of a medical device.

While manufacturers can categorize process risks on a high-to-low risk spectrum, the FDA has divided process risk into “high process risk” and “non-high process risk” categories in the guidelines, explaining that the The agency is “primarily concerned with review and assurance for software features, functions and operations that pose a high risk to processes, as failure also poses a risk to medical devices.

When a manufacturer identifies a high process risk in its software, it must determine whether or not the feature, function or operation poses a potential hazard to a patient or user and apply the appropriate assurance activities based on the assessed level of risk. The manufacturer can use risk-based testing to identify appropriate assurance activities “where the management, selection, prioritization and use of testing activities and resources are consciously based on the corresponding types and levels of risk analyzed to determine appropriate activities”.

For example, in high-risk software testing, scripted testing may be more appropriate, while non-high-risk software testing might include unscripted testing using ad hoc testing, error detection, testing exploratory or a combination of test methods.

Manufacturers should also ensure that an appropriate record is created to document that the software feature, function, or operation performs as intended. The proper record should contain the intended use, risk identification, and assurance activities documentation of software functionality, function, or operation.

“Documentation of assurance activities need not include more evidence than necessary to show that the software feature, function, or operation is performing as intended for the identified risk,” the agency wrote. “The FDA recommends that the record retain enough detail about the assurance activity to serve as a baseline for improvements or a point of reference in the event of a problem.”

Orientation project

© 2022 Society of Regulatory Affairs Professionals.

Comments are closed.