Regulated Quality Systems: FDA QMSR and ISO 13485:2016
Quality management system engineering for medical device software under the FDA Quality Management System Regulation (QMSR, 21 CFR Part 820, effective February 2, 2026), which incorporates ISO 13485:2016 by reference. We build IEC 62304 software lifecycles, ISO 14971 risk management and IEC 62366-1 usability engineering into the way your team already works, and leave a design and development file your quality organization can stand behind.
The Customer Problem: Four QMSR Transition Gaps
The February 2, 2026 line
FDA now inspects under the Quality Management System Regulation. An ISO 13485 certificate does not exempt a manufacturer from FDA inspection.
Records under retired names
Procedures and records still use the former Part 820 vocabulary, while QMSR expects the ISO 13485 structure: a Design and Development File and a Medical Device File.
Risk management in pockets
ISO 14971 work lives in design controls. QMSR expects documented, risk-based decisions across suppliers, records, labeling and post-market activity.
Newly inspection-visible records
Internal audits, management reviews and supplier audits are now within FDA inspection scope, and labeling and packaging controls have their own section (21 CFR 820.45).
The Consequential Solution: Executable Design Controls
Design controls kept as linked records rather than documents assembled at the end. Each design input points to the risk controls it carries, the software requirements that implement it and the verification that proves it, so the design and development file is regenerated from the work, not reconstructed after a design freeze.
| Record | ISO 13485:2016 clause | What it holds |
|---|---|---|
| Design and Development File (DDF) | §7.3.10 | Design inputs and outputs, reviews, verification, validation, transfer and changes for one device or family, with the history of changes kept. |
| Medical Device File (MDF) | §4.2.3 | The device description, specifications, production and service procedures, labeling and the records that show conformity. |
| Production and service records | §7.5 | What was built or serviced, when, by whom and against which version of the specification. |
Existing design history content does not have to be recreated: QMSR expects it to be mapped and structured under the ISO 13485 terms.
What Netspective Offers: Engineering Responsibility
QMSR readiness gap assessment
An inspection-oriented review of your quality system documents, records and terminology against QMSR and ISO 13485:2016.
DDF and MDF structure
Design and development files (§7.3.10) and medical device files (§4.2.3) structured for reviewer traceability, with existing content mapped in.
IEC 62304 lifecycle and traceability
Software lifecycle processes and requirement-to-test traceability, using Qualityfolio to keep tests and evidence in Git.
Risk across the quality system
ISO 14971 risk management extended to suppliers, labeling and post-market activity; usability engineering under IEC 62366-1 through Human Factors Engineering.
Technical Architecture: The Design Trace Chain
- Design inputISO 13485:2016 §7.3.3
- Risk controlISO 14971, for a named hazard
- Software requirementIEC 62304 §5.2
- Verification§7.3.6, a dated record per cycle
- Design and Development File§7.3.10, compiled from the links
Where QMSR widens risk expectations
| Area | What QMSR expects | Evidence we build |
|---|---|---|
| Scope of risk | Risk management across the whole quality system and product lifecycle, not only design controls. | A risk file linked to suppliers, labeling and post-market records. |
| Decisions | Documented, risk-based decisions with controls scaled to risk and monitored. | Decision records that name the risk and the control they rely on. |
| Suppliers | Evaluation plus ongoing, risk-based performance monitoring. | Supplier records with criteria, monitoring results and dates. |
| Records and audits | Internal audits, management reviews and supplier audits within inspection scope. | Audit and review records kept accessible and traceable. |
| Labeling and packaging | 21 CFR 820.45 controls: UDI, expiration date, storage, handling and processing instructions. | Label records checked for each required element. |
Design Trace Explorer
Four steps from a Markdown design record to questions an inspector can ask again. All data here is illustrative.
Panel 1: A design input traced in Markdown
One design input with its risk control, software requirement and verification evidence, in the public Qualityfolio format.
---
doc-classify:
- select: heading[depth="1"]
role: project
- select: heading[depth="2"]
role: case
- select: heading[depth="3"]
role: evidence
---
# Infusion Rate Calculator: Design and Development File (illustrative)
@id ddf-example
## DI-014: Rate entry rejects values above the configured maximum
@id TC-DI-014
```yaml META
requirementID: DI-014 # design input, ISO 13485:2016 §7.3.3
riskControl: RC-031 # ISO 14971 risk control for hazard H-007
softwareRequirement: SRS-112 # IEC 62304 §5.2 software requirement
Priority: High
```
### Evidence
@id TC-DI-014
```yaml META
cycle: 2.0
cycle-date: 2026-10-12
assignee: Verification engineer
status: passed
```
- [Verification record](./evidence/TC-DI-014/2.0/result.auto.json)
Synthetic illustration Synthetic: no client data. It uses the public Qualityfolio Markdown structure to show the chain design input → risk control → software requirement → verification evidence. Field names beyond requirementID are illustrative.
Panel 2: Compile the records into SQLite
The records and their evidence files become one queryable database and a local dashboard.
# Parse the records and evidence into resource-surveillance.sqlite.db
spry rb run qualityfolio.md
# Serve the dashboard on this machine only
surveilr web-ui -d ./resource-surveillance.sqlite.db --port 9227 --host localhost
Writes: resource-surveillance.sqlite.db. Commands from the public Qualityfolio documentation, bound to localhost.
Panel 3: Design inputs without passing verification
Each design input with its risk controls and verification records; unverified and failing inputs come first.
-- Synthetic illustration: design inputs traced to risk controls and
-- verification, ISO 13485:2016 §7.3. Each table stands in for records in your
-- design and development file.
CREATE TABLE IF NOT EXISTS design_input (input_id TEXT PRIMARY KEY, title TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS risk_control (control_id TEXT PRIMARY KEY, hazard_id TEXT NOT NULL, input_id TEXT REFERENCES design_input (input_id));
CREATE TABLE IF NOT EXISTS verification (
record_id TEXT PRIMARY KEY,
input_id TEXT NOT NULL REFERENCES design_input (input_id),
status TEXT CHECK (status IN ('passed', 'failed', 'blocked')),
run_date TEXT
);
SELECT d.input_id,
d.title,
group_concat(DISTINCT r.control_id) AS risk_controls,
COUNT(DISTINCT v.record_id) AS verification_records,
COALESCE(MAX(v.run_date), '-') AS last_run,
CASE
WHEN COUNT(v.record_id) = 0 THEN 'not verified'
WHEN SUM(v.status = 'passed') = 0 THEN 'no passing record'
ELSE 'verified'
END AS trace_status
FROM design_input d
LEFT JOIN risk_control r ON r.input_id = d.input_id
LEFT JOIN verification v ON v.input_id = d.input_id
GROUP BY d.input_id, d.title
ORDER BY CASE trace_status WHEN 'not verified' THEN 1 WHEN 'no passing record' THEN 2 ELSE 3 END, d.input_id;
Synthetic illustration Table names are illustrative, not a Qualityfolio schema. Runs as written in SQLite 3.
Panel 4: Label records missing a required element
Label records checked against the elements 21 CFR 820.45 names.
-- Synthetic illustration: label records missing an element 21 CFR 820.45
-- asks to be checked (UDI, expiration date, storage, handling and processing
-- instructions). label_record stands in for your labeling records.
CREATE TABLE IF NOT EXISTS label_record (
label_id TEXT PRIMARY KEY,
device TEXT NOT NULL,
udi TEXT,
expiration TEXT,
storage TEXT,
handling TEXT,
processing TEXT
);
SELECT label_id,
device,
trim(
CASE WHEN udi IS NULL OR udi = '' THEN 'UDI ' ELSE '' END ||
CASE WHEN expiration IS NULL OR expiration = '' THEN 'expiration ' ELSE '' END ||
CASE WHEN storage IS NULL OR storage = '' THEN 'storage ' ELSE '' END ||
CASE WHEN handling IS NULL OR handling = '' THEN 'handling ' ELSE '' END ||
CASE WHEN processing IS NULL OR processing = '' THEN 'processing ' ELSE '' END
) AS missing
FROM label_record
WHERE missing <> ''
ORDER BY device, label_id;
Synthetic illustration A check of record completeness, not of label content or legibility. Runs as written in SQLite 3.
Verified Proof Ledger (Engineering Ground Truth)
| Claim | Status | What it rests on |
|---|---|---|
| Markdown test and trace records compiled into SQLite with a traceability dashboard | Built and tested | The public Qualityfolio repository and documentation. |
| Design and development file trace fields beyond requirementID | Designed | The synthetic illustration on this page; the record schema is set per engagement. |
| QMSR readiness gap assessment method | Designed | Delivered per engagement against QMSR and ISO 13485:2016; no public tool. |
| FDA clearance, inspection or audit outcome | Not established | FDA, notified bodies and auditors decide. We claim no outcome. |
| A replacement for regulatory counsel or your quality organization's sign-off | Not established | Engineering and documentation support; approval stays with your quality system. |
| 21 CFR Part 11 compliance of the tooling itself | Not established | Part 11 controls belong to the validated process the tools run in. |
Real-World Scenarios
FDA, notified bodies and auditors decide every outcome. These are the records we help build.
A SaMD start-up before its 510(k)
IEC 62304 Class B software gets a design and development file whose design inputs trace to risk controls and verification records.
An established manufacturer re-mapping records
Records kept under the former Part 820 structure are mapped into DDF and MDF form without recreating historical design work.
Supplier oversight by risk
Supplier evaluation extended to ongoing monitoring, with criteria and results kept as records an inspector can follow.
Scoped Pilot: The 2-Week QMSR Readiness and DDF Gap Analysis
What the two weeks deliver
Week 1: assess
Review quality system procedures, records and terminology against QMSR and ISO 13485:2016, with inspection-visible gaps marked.
Week 2: trace
Trace one design input end to end into a DDF structure, then deliver a prioritized gap list your team can act on.
Boundaries
- Engineering reference and documentation support, not formal legal or regulatory counsel.
- FDA, notified bodies and auditors decide clearance and audit outcomes; we guarantee neither.
- Your quality system stays yours: we build records into it; we do not operate it for you.
Engagement detail
What does Netspective regulatory consulting cover?
It covers FDA strategy across the 510(k), PMA, and De Novo pathways, HIPAA program design, quality management system build-out, NIST and FedRAMP authorization support, and ISO 14971 risk management. Each engagement produces documentation a reviewer can act on, delivered by a named engineer.
Four commitments that hold across every engagement
- FDA Strategy
- 510(k), PMA, and De Novo pathway selection grounded in device classification and predicate history.
- Quality System Design
- QMSR/ISO 13485 quality systems built for audit, not assembled after one is scheduled.
- Risk Management
- ISO 14971 risk files linked to verification records, not maintained as a standalone binder.
- Submission Traceability
- Requirement-to-evidence traceability a federal reviewer can actually follow.
Regulatory frameworks we specialize in
- FDA QMSR (21 CFR 820)
- ISO 13485
- ISO 14971
- IEC 62304
- HIPAA
- NIST SP 800-53
- FedRAMP
- SOC 2
Six regulatory programs
FDA Regulatory Pathways
510(k), PMA, and De Novo submission strategy mapped to a specific device classification and predicate history.
- 510(k) Predicate Analysis
- PMA Clinical Strategy
- De Novo Classification
- Pre-Submission (Q-Sub) Meetings
QMS Design (QMSR / ISO 13485)
Quality management system build-out under the FDA QMSR harmonization with ISO 13485, from document control to internal audit. See FDA QMSR Design Controls for the governing standard.
- Design Controls (ISO 13485:2016 §7.3 / former 21 CFR 820.30)
- Document Control
- CAPA Process Design
- Internal Audit Program
ISO 14971 Risk Management
Risk management files built to ISO 14971:2019, linked to verification records instead of maintained as a standalone binder.
- Risk Management Plan
- Hazard Analysis
- Risk Control Verification
- Residual Risk Evaluation
Technical Documentation (Medical Device File & Design and Development File)
Medical device files (ISO 13485:2016 §4.2.3) and design and development files (§7.3.10) structured for reviewer traceability, the records FDA QMSR now relies on in place of the former Part 820 record types, not reconstructed after a design freeze.
- Design and Development File (ISO 13485:2016 §7.3.10)
- Medical Device File (ISO 13485:2016 §4.2.3)
- Design Traceability Matrix
- Design Change Records (§7.3.9)
HIPAA Compliance Programs
HIPAA Security Rule compliance program design — administrative, physical, and technical safeguards mapped to an organization's actual systems. See HIPAA Engineering Practices.
- Security Risk Assessment
- Business Associate Agreements
- Breach Notification Procedures
- Workforce Training Program
NIST & FedRAMP Authorization
Federal authorization support for FedRAMP (NIST SP 800-53 Rev. 5 baselines) and secure software development attestation (NIST SP 800-218 SSDF), from control mapping through continuous monitoring.
- NIST SSDF Control Mapping
- FedRAMP SSP Authoring
- Continuous Monitoring Setup
- POA&M Management
Ready to Build?
Discuss which regulatory program applies to a specific engagement.
Engineering reference only. Not formal regulatory counsel. Consult your own quality system and legal counsel for a specific regulatory determination.