Summary

This Standard Operating Procedure (SOP) establishes systematic processes for identifying, evaluating, and controlling nonconforming products and processes in medical device manufacturing and software development. It defines clear procedures for handling deviations from specifications, implementing appropriate disposition decisions, and preventing recurrence through integrated corrective and preventive actions.

Why is SOP Nonconformance important?

Nonconformance control is fundamental to maintaining medical device quality and patient safety. When products or processes deviate from established specifications, they can potentially compromise device safety, effectiveness, or regulatory compliance. Regulatory authorities require manufacturers to have robust systems for identifying and controlling nonconforming products to prevent defective devices from reaching patients.

This SOP is critical because it provides systematic decision-making for handling quality problems. Without proper nonconformance controls, defective products might be released to market, processes might continue producing defects, and quality issues could go unaddressed. The procedure ensures that every deviation is properly evaluated for safety impact, appropriately dispositioned, and analyzed for root causes that could lead to broader quality improvements.

Integration with CAPA systems ensures that significant nonconformances trigger investigations into systemic causes and implementation of preventive measures, creating a feedback loop that continuously improves your quality management system.

Regulatory Context

Under 21 CFR Part 820 (Quality System Regulation):

  • Section 820.90 mandates procedures for controlling nonconforming product
  • Nonconforming product must be identified and controlled to prevent unintended use or delivery
  • Disposition decisions must be documented and approved by authorized personnel
  • Must evaluate for rework, repair, accept as-is, or scrap with appropriate authorization

Integration with other QSR requirements:

  • Nonconformance data must feed into CAPA system under 820.100
  • Links to complaint handling procedures under 820.198
  • Supports design control nonconformance evaluation under 820.30

Special attention required for:

  • Authorization levels for disposition decisions, especially “use as-is”
  • Documentation of safety and effectiveness impact evaluation
  • Integration with complaint handling for field-discovered nonconformances
  • CAPA triggering criteria for significant or recurring nonconformances

Guide

Establishing Comprehensive Nonconformance Identification

Proactive identification of nonconformances requires multiple detection methods throughout your operations. Train personnel to recognize deviations from specifications, established procedures, or expected outcomes. Nonconformances can be discovered during incoming inspection, in-process testing, final inspection, customer complaints, or internal audits.

Clear identification criteria help ensure consistent detection. Define what constitutes a nonconformance for your specific products and processes, including dimensional tolerances, functional specifications, software requirements, and procedural deviations. Document these criteria in work instructions and training materials.

Immediate containment is critical when nonconformances are identified. Physically segregate nonconforming products, stop affected processes, and prevent unintended use or delivery. Use clear labeling or physical barriers to identify nonconforming items.

Conducting Thorough Nonconformance Evaluation

Safety impact assessment is the first priority when evaluating any nonconformance. Determine whether the deviation could affect device safety, effectiveness, or regulatory compliance. Use your risk management process to evaluate potential hazards and their severity.

Root cause analysis should be proportional to the significance of the nonconformance. Minor deviations might require only basic investigation, while safety-related or recurring nonconformances need comprehensive analysis using tools like fishbone diagrams, 5-why analysis, or failure mode analysis.

Scope assessment determines whether the nonconformance affects only specific units or indicates broader systemic issues. Investigate whether similar products, processes, or time periods might be affected. This helps determine the extent of containment actions needed.

Implementing Appropriate Disposition Strategies

Disposition decision-making requires clear authority levels and approval processes. Establish who can authorize different disposition options, with higher authority required for “use as-is” decisions or safety-related evaluations.

Rework procedures must ensure that modified products meet all original specifications. Document rework instructions, verify completion through appropriate testing or inspection, and update records to reflect the rework performed.

Repair decisions for products that cannot be restored to original specifications require careful evaluation. Ensure repaired products still meet essential safety and performance requirements. Document repair procedures and conduct appropriate verification testing.

Use as-is decisions are the most critical and require thorough justification. Demonstrate that despite the nonconformance, the product still meets essential requirements for safety and effectiveness. Higher management authorization is typically required for these decisions.

Scrap decisions must ensure proper disposal and prevent inadvertent use of nonconforming products. Follow appropriate disposal procedures, especially for electronic waste or controlled materials.

Managing Software-Specific Nonconformances

Software nonconformances often require different handling than hardware issues. Code defects, logic errors, or performance issues need evaluation for safety impact using your IEC 62304 software safety classification.

Version control integration ensures that software nonconformances are properly tracked and resolved. Use your software development procedures to implement fixes, conduct verification testing, and update documentation appropriately.

Regression testing is critical when correcting software nonconformances to ensure fixes don’t introduce new problems. The extent of testing should be proportional to the safety classification and scope of changes.

Documenting and Tracking Nonconformances

Nonconformance reports should capture all essential information including description of the deviation, products affected, safety assessment, root cause analysis results, disposition decision, and corrective actions taken.

Trending and analysis of nonconformance data helps identify systematic quality issues. Regular review of nonconformance types, frequencies, and root causes can reveal improvement opportunities and trigger preventive actions.

Records management must ensure nonconformance documentation is maintained according to your document control procedures and regulatory requirements. These records provide important evidence during audits and regulatory inspections.

Integrating with CAPA and Continuous Improvement

CAPA triggering should be clearly defined for different types of nonconformances. Safety-related issues, recurring problems, or systemic failures typically require formal CAPA investigation and implementation.

Effectiveness verification ensures that corrective actions actually resolve the nonconformance causes. Follow up on implemented actions to confirm they’re working as intended and haven’t created new problems.

Process improvement opportunities often emerge from nonconformance analysis. Use this data to update procedures, improve training, enhance inspection methods, or modify product designs to prevent future occurrences.

Example

Scenario

During final software testing of your medical device application, you discover that the dosage calculation algorithm produces incorrect results when patient weight exceeds 150kg. The software is classified as IEC 62304 Class B. Here’s how you would handle this nonconformance:

Immediate Identification and Containment: Stop software release process, quarantine affected software builds, and notify development team. Document the nonconformance in your tracking system with details about the specific calculation error and affected weight ranges.

Safety Impact Evaluation: Assess that incorrect dosage calculations could lead to inappropriate treatment recommendations, potentially causing patient harm. Classify as high-priority safety-related nonconformance requiring immediate attention.

Root Cause Investigation: Analysis reveals that the algorithm uses integer arithmetic causing overflow errors with large weight values. Code review shows insufficient input validation and edge case testing during development.

Disposition Decision: Software cannot be released as-is due to safety implications. Requires rework to fix calculation algorithm and implement proper input validation. No repair or use as-is options are acceptable for safety-critical software.

Corrective Actions: Develop software patch with corrected algorithm, implement comprehensive input validation, conduct extended testing with full weight range, and update test procedures to include edge case scenarios.

Verification: Complete regression testing confirms algorithm fixes work correctly across all weight ranges without affecting other functionality. Documentation updated to reflect changes and lessons learned.

Example Nonconformance Report

NCR Number: NCR-2024-012
Date Identified: March 8, 2024
Product: MedDevice Software v2.1.3
Nonconformance Description: Dosage calculation algorithm produces incorrect results for patient weights >150kg

Safety Assessment: HIGH RISK - Incorrect calculations could lead to inappropriate dosing recommendations

Root Cause: Integer overflow in weight calculation function; insufficient edge case testing during development

Disposition: REWORK REQUIRED

  • Correct calculation algorithm to handle full weight range
  • Implement proper input validation
  • Enhance test coverage for edge cases
  • Update development procedures

Actions Taken:

  • Algorithm corrected in v2.1.4
  • Input validation implemented for weight range 0-300kg
  • Extended test suite executed and passed
  • Code review process enhanced for calculation functions

Verification: Regression testing completed successfully; full weight range validated

CAPA Required: Yes - Investigation into development testing procedures to prevent similar issues

Approved by: Quality Manager, Software Team Lead
Closure Date: March 20, 2024

Q&A