Computer Software Assurance for Production and Quality System Software (DRAFT)
This guidance provides recommendations on computer software assurance for computers and automated data processing systems used as part of medical device production or the quality system. It focuses on establishing confidence in automation through a risk-based approach and describes various methods and testing activities to fulfill regulatory requirements.
This is a draft guidance. Not for implementation.
What You Need to Know? 👇
What is computer software assurance and how does it differ from traditional software validation?
Computer software assurance is a risk-based approach for establishing confidence that software is fit for its intended use. Unlike traditional validation, it focuses on the risk of compromised safety/quality to determine appropriate assurance activities, following a least-burdensome approach where validation effort matches the actual risk level.
Which software systems require validation under 21 CFR 820.70(i)?
Software used directly in production or quality systems (automating processes, testing, data collection) and supporting software (development tools, testing scripts, general record-keeping) both require validation. However, general business software like email or accounting applications typically don’t require validation under this regulation.
How do I determine if my production software poses “high process risk”?
Software poses high process risk when failure could result in quality problems that foreseeably compromise safety. Examples include software maintaining critical process parameters, performing automated inspections without human review, or producing patient labeling. Low-risk software typically involves data collection for monitoring purposes.
What testing methods are acceptable for computer software assurance?
Acceptable methods include scripted testing (robust or limited), unscripted testing (ad-hoc, error-guessing, exploratory), and risk-based testing approaches. High-risk software typically requires more rigorous scripted testing, while low-risk software may use unscripted methods. The approach should match the risk level.
What documentation is required for computer software assurance records?
Records must include intended use, risk determination, description of assurance activities conducted, testing results, issues found and disposition, conclusion statement, date/person who performed testing, and appropriate review/approval. Documentation should be proportionate to risk - more detailed for high-risk software.
How does this guidance affect PMA supplement requirements for software changes?
For PMA/HDE devices, software changes that may result in quality problems foreseeably compromising safety require 30-day notice submission. Changes that don’t foreseeably compromise safety can typically be reported annually. The risk-based approach helps determine which submission pathway is appropriate.
What You Need to Do 👇
Recommended Actions
- Establish a process to determine software intended use and categorization (direct vs supporting)
- Implement risk assessment methodology to identify high process risk vs not high process risk software features
- Define appropriate validation activities based on risk level
- Create documentation templates aligned with risk-based approach
- Review and update supplier assessment process for software vendors
- Establish procedures for maintaining software in validated state
- Train relevant personnel on risk-based computer software assurance approach
- Review existing software validation documentation against new guidance requirements
- Implement electronic record keeping system compliant with Part 11 requirements where applicable
- Create process for periodic review of software validation status
Key Considerations
Non-clinical testing
- Testing activities should be commensurate with the risk level (high process risk vs not high process risk)
- Different testing approaches can be used: scripted testing (robust or limited) and unscripted testing (ad-hoc, error-guessing, exploratory)
- Testing documentation should be proportional to risk level
Software
- Software must be validated for its intended use if used in production or quality system
- Two categories of software: directly used in production/quality system vs supporting software
- Risk-based approach required to determine validation effort
- Continuous monitoring and maintenance of validated state throughout software lifecycle
- Leveraging of vendor validation work is acceptable for lower risk software
Cybersecurity
- Electronic signature requirements must comply with 21 CFR Part 11 when applicable
- System security considerations for data integrity and transfer
Safety
- High process risk determination when software failure may result in quality problems that foreseeably compromise safety
- Additional validation efforts required for high-risk features
Other considerations
- Documentation requirements should be risk-based and include intended use, risk determination, testing activities, results, and conclusions
- Electronic records can be used instead of paper documentation
- Supplier assessment and purchasing controls should be established
Relevant Guidances đź”—
- Content of Premarket Submissions for Device Software Functions
- Off-The-Shelf Software in Medical Devices: Documentation Requirements for Premarket Submissions
- Software Validation for Medical Device Production, Quality Systems, and Device Components
- Electronic Records and Electronic Signatures - Scope and Application
Related references and norms đź“‚
- IEC/IEEE/ISO 29119-1: Software and systems engineering – Software testing - Part 1: Concepts and definitions