FDA QSR (21 CFR Part 820) & Part 11 Compliance

In Plain Language

The FDA Quality System Regulation (21 CFR Part 820) and Electronic Records rule (21 CFR Part 11) establish how medical software must be built to ensure clinical safety and efficacy. In software engineering, these rules require that every user requirement is linked to an automated test (Design Verification), changes are tracked in a Design History File (DHF), and releases are signed with tamper-proof electronic signatures.

Plain-Language Executive Summary

FDA Quality System regulations govern how medical software must be designed, tested, and validated to ensure it never harms a patient. It mandates a complete paper trail proving every clinical feature was deliberately planned (Design Inputs), verified with automated tests (Design Outputs), and signed with tamper-proof electronic signatures.

Primary Protected Asset

Patient Safety & Clinical Device Efficacy — Ensuring software algorithms do not misdiagnose patients, corrupt medical imagery, or fail during real-time physiological monitoring.

Who It Applies To & Penalties for Non-Compliance

Applicability & Covered Scope

Any software functioning as a medical device (diagnosing, monitoring, treating disease) or embedded in physical clinical equipment. Covers Software as a Medical Device (SaMD), clinical decision support algorithms, electronic health record (EHR) modules, and companion diagnostics.

Inspection Observations & Recalls

FDA Form 483 inspection observations, Warning Letters, import alerts, mandatory product recalls, and federal consent decrees halting commercial distribution. Inadequate software validation is one of the most frequent causes of FDA 483 inspection citations and mandatory medical device recalls.

FDA Design Controls (21 CFR § 820.30) & NUP Fulfillment

FDA design controls enforce a structured, verified progression from user needs to production code:

1. Design Controls & Design History File (DHF)

21 CFR § 820.30
Statutory Requirement: Establish and maintain procedures to control the design of the device, ensuring user needs become verified product specifications.
Deterministic NUP Fulfillment: Automated DHF compilation tracking requirements from Jira/SpecKit down to Git commit hashes and Vitest test execution reports.

2. Software Verification & Validation (V&V)

21 CFR § 820.30(f) & (g)
Statutory Requirement: Verify design outputs conform to design inputs and validate that devices conform to defined user needs and intended uses.
Deterministic NUP Fulfillment: Multi-layer testing pyramid (unit, integration, end-to-end clinical simulation) with automated traceability matrices.

3. Electronic Records & Electronic Signatures (Part 11)

21 CFR Part 11
Statutory Requirement: Ensure electronic records and signatures are trustworthy, reliable, and legally equivalent to paper records and handwritten signatures.
Deterministic NUP Fulfillment: Dual-credential GPG commit signing and cryptographic release attestations with non-repudiable audit logs.

4. CAPA: Corrective and Preventive Action

21 CFR § 820.100
Statutory Requirement: Analyze processes, work operations, audit reports, and quality records to identify and investigate existing and potential causes of nonconforming product.
Deterministic NUP Fulfillment: Blameless post-mortem CAPA workflow linking production bugs back to automated regression test assertions.

Auditable Artifacts & Design History File (DHF) Evidence

The deterministic pipeline automatically compiles and seals these auditable DHF artifacts upon release:

  • Design History File (DHF) Index & Traceability Matrix (`traceability-matrix.json`)
  • Software Verification Protocol & Summary Report (Vitest CI execution artifacts)
  • Software Hazard Analysis & ISO 14971 Risk Management File
  • 21 CFR Part 11 Electronic Signature Validation Package
Try This with AI: DHF Software Traceability Matrix Generator

Copy this prompt into your AI coding assistant to automatically generate requirement-to-test traceability matrices.

You are a Medical Device Software Quality Engineer. Generate a traceability matrix linking: 1. Software Requirement: 'SYS-REQ-0042: Real-time arrhythmia alerting within 500ms'. 2. Architecture Component: 'AlertNotificationService.ts' (Design Output). 3. Verification Test: 'AlertNotificationService.test.ts' asserting <500ms latency threshold. 4. Risk Hazard Mitigation: 'HAZ-008: Missed cardiac alert risk rating reduced from High to Acceptable'. Output the matrix in valid JSON matching the NUP DHF traceability schema.

Related Quality Gate: Compliance Checklist: FDA DHF Release Gate

Validate DHF completeness and electronic signatures with Checklists.

Open Checklist

FDA 820.30 Document Templates

Get copyable markdown boilerplates for SRS, SDD, and Master Test Plans.

Open Templates

Community Discussion & Feedback

Attributed peer feedback and official Netspective architecture notes.

Was this documentation helpful?(100% found this helpful • 0 ratings)

Leave Feedback or Question

○ Loading user info...
0/2000 chars

Discussion (0)

Loading discussion thread...