FDA drafts guidance on device production and quality system software assurance

Regulatory NewsRegulatory News | 12 September 2022 | By

The US Food and Drug Administration (FDA) has issued a draft guidance on software assurance for computer and data processing systems associated with medical device production.
 
FDA said the draft guidance is a document for industry and agency staff to evaluate computer software with “a risk-based approach to establish confidence in the automation used for production or quality systems, and identify where additional rigor may be appropriate.” Additionally, the document outlines how stakeholders can validate the software and determine it is being used appropriately.
 
The guidance will eventually be a supplement to the “General Principles of Software Validation” final guidance published in January 2002 and take the place of Section 6 of that guidance, which focuses on validation of automated process equipment and quality system software.
 
The agency said using this computer software risk-based framework would help meet the requirements of 21 CFR 820.70(i), which dictates the maintenance schedule requirements of medical equipment under FDA’s purview, while also assisting manufacturers with their assurance activities and ensuring product quality. “FDA believes that these recommendations will help foster the adoption and use of innovative technologies that promote patient access to high-quality medical devices and help manufacturers to keep pace with the dynamic, rapidly changing technology landscape, while promoting compliance with laws and regulations implemented by FDA,” they wrote.
 
In the draft guidance, FDA outlined a computer software assurance risk framework that includes assessing the intended use of the computer software, using a risk-based analysis for software that is part of the production or quality system to identify the right assurance activities based on the risk level and creating a record of the system to document it is operating as intended.
 
FDA makes a distinction in the guidance between software that is directly part of the production process and software in support of the production or quality system. FDA said software is directly part of the process or quality system for medical device production if it is part of the automation process, inspection, testing or collection of data during production; is used for automating processes, collection, and data processing in quality systems or is used in the quality system regulation to maintain a quality record.
 
Software is used to support the process if it is part of the testing or monitoring system for software that is directly part of the production or quality system and part of the automation process for record keeping, rather than maintaining a quality record, FDA said.
 
The agency acknowledged that software might have more than one intended use, which may carry different risks based on their features, functions, and operations within a production or quality system. “FDA recommends that manufacturers examine the intended uses of the individual features, functions, and operations to facilitate development of a risk-based assurance strategy,” they wrote. “Manufacturers may decide to conduct different assurance activities for individual features, functions, or operations.”
 
After software has been classified as being part of the production or quality system associated with a medical device, stakeholders should use a risk-based analysis to identify appropriate assurance activities for the software. That includes identifying “forseeable” risks to the software and whether the failure could prevent the software from operating as intended, which could impact production or the quality system (process risk) or cause a medical device to injure a patient or user (medical device risk).
 
“Specifically, FDA considers a software feature, function, or operation to pose a high process risk when its failure to perform as intended may result in a quality problem that foreseeably compromises safety, meaning an increased medical device risk,” the agency said.
 
High process risks are typically features, functions, or operations of the software that maintain the parameters of the process; use limited human involvement to measure, inspect, analyze, or accept a product or process; correct or adjust process parameters with limited human involvement; issue directions for 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 classify process risks on a spectrum of high risk to low risk, FDA divided process risk into “high process risk” and “not high process risk” categories in the guidance, explaining the agency is “primarily concerned with the review and assurance for those software features, functions, and operations that are high process risk because a failure also poses a medical device risk.”
 
When a manufacturer identifies a high process risk in their software, they should determine whether or not the feature, function, or operation poses potential harm to a patient or user and apply appropriate assurance activities based on the level of risk assessed. The manufacturer can use risk-based testing to identify which assurance activities are appropriate “in which the management, selection, prioritization, and use of testing activities and resources are consciously based on corresponding types and levels of analyzed risk to determine the appropriate activities.”
 
For example, in high-risk software testing, scripted testing may be more appropriate, while not high-risk software testing could include unscripted testing using ad-hoc testing, error-guessing, exploratory testing or a combination of testing methods.
 
Manufacturers should also ensure an appropriate record is created to document that software feature, function, or operation is working as intended. The appropriate record should have the intended use, risk determination, and documentation assurance activities of the software feature, function, or operation.
 
“Documentation of assurance activities need not include more evidence than necessary to show that the software feature, function, or operation performs as intended for the risk identified,” the agency wrote. “FDA recommends the record retain sufficient details of the assurance activity to serve as a baseline for improvements or as a reference point if issues occur.”
 
Draft Guidance

 

© 2022 Regulatory Affairs Professionals Society.

Discover more of what matters to you

18;20;