· MEDICAL DEVICE QUALITY

Medical Device Quality System (ISO 13485 / QMSR)

The medical device quality system is governed by ISO 13485 and, in the United States, 21 CFR Part 820 — now being harmonised into the Quality Management System Regulation (QMSR), which incorporates ISO 13485 by reference. Device quality is distinctively risk-management-led, from design controls through to software lifecycle and post-market surveillance.

What an explainer is not

A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.

[ POSITION IN THE FRAMEWORK ]

7 DIMENSIONS · 25 LINKS

Medical device quality spans the quality-system and CSV disciplines: a risk-management-led QMS running from design controls to post-market feedback, converging on ISO 13485 as the FDA QMSR takes effect.

06 · QUALITY MATURITY — MEDICAL DEVICE QUALITY SYSTEM (ISO 13485 / QMSR), REACTIVE TO ADAPTIVE

L1
Reactive

The quality system is paper compliance; complaints are handled ad hoc and design history is reconstructed on request.

L2
Defined

Design controls and CAPA are proceduralized, but the risk file is assembled at the end rather than driving the design.

L3
Controlled

The DHF traces inputs through verification and validation; ISO 14971 risk management runs through design and production.

L4
Predictive

Complaints, adverse events, and field data trend into the risk file and design changes before regulators ask.

L5
Adaptive

One harmonized QMS (ISO 13485/QMSR) governs the portfolio; risk knowledge steers design, software lifecycle, and suppliers.

SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →

07 · REGULATORY & EVIDENCE

GOVERNING STANDARDS · 4

Derived from the 4 standards SPEQ maps to this subject, across 3 regulatory bodies: FDA, ISO, IEC.

RECORDS & OBJECTIVE EVIDENCE

  • Design History Files with input-to-validation traceability
  • Risk management files maintained per ISO 14971 across the lifecycle
  • CAPA records with root cause and effectiveness verification
  • Complaint-handling files with reportability evaluations
  • Supplier evaluation and control records

COMMON INSPECTION FINDINGS

  • Design validation not performed under actual or simulated use conditions
  • Risk files never updated with post-production information
  • CAPA procedures inadequate, or corrective actions unverified
  • Complaints closed without evaluating reportability
  • Process validation missing where output is not fully verified
EVERY CHIP IS A DOOR · WALK THE FRAMEWORK FROM ANY SUBJECTHow SPEQ maps the framework →

ISO 13485 and the FDA QMSR

ISO 13485 is the international quality-management standard for medical devices — process-based, risk-aware, and the de facto global expectation. In the US, the FDA’s Quality System Regulation (21 CFR 820) historically stood apart, but the QMSR final rule harmonises the two by incorporating ISO 13485 by reference, taking effect in February 2026. For most manufacturers this converges two systems into one, with FDA-specific additions layered on top.

Design controls

The requirement that most distinguishes device quality from pharma is design controls: a formal, traceable process from design inputs (requirements) through design outputs, verification (did we build it right?), validation (did we build the right thing?), design review, and design transfer — all captured in the Design History File. Inadequate design controls are among the most common and consequential device inspection findings.

Risk management runs through everything (ISO 14971)

Device quality is risk-management-led end to end. ISO 14971 defines the application of risk management across the device lifecycle — risk analysis, evaluation, control, and post-production monitoring — and it is woven into design controls, production, and post-market surveillance rather than bolted on. For a device, "have you managed the risk?" is close to the whole question.

Software as a medical device (IEC 62304)

When software is part of, or is itself, a medical device, IEC 62304 defines the software development lifecycle — with a safety classification (A/B/C) that scales rigour to the harm a failure could cause. It connects to the wider quality system and to computer-system validation, and it is increasingly central as devices become software-defined.

CAPA and post-market

As with pharma, CAPA is where problems become prevention — and for devices it is consistently one of the most-cited inspection areas, alongside complaint handling and post-market surveillance. A device quality system is judged heavily on whether its feedback loops (complaints, adverse events, field data) actually drive corrective and preventive action.

WORKED EXAMPLE — SPEQ SYNTHESIS

A hypothetical Class II device manufacturer, established in the European market under its notified-body certificate, plans to enter the United States. Its quality system is built around its existing certification. The regulatory lead is asked what changes.

  1. Separate the system question from the market-access question

    Two distinct workstreams run in parallel: what the quality system must satisfy, and what the route to market requires. Conflating them produces a plan that treats a submission as a quality-system deliverable, or the reverse.

  2. Map the existing system against the other jurisdiction’s expectations, clause by clause

    Much of a mature system transfers. The value of the exercise is in the residue — the places where a requirement has no counterpart in the current system — and a summary-level mapping reliably misses exactly those.

  3. Examine the areas that differ in substance rather than in wording

    Complaint handling, reporting obligations, design history documentation and labelling tend to differ in what must be done, not only in what it is called. These are where a mapping done on vocabulary gives false comfort.

  4. Decide whether to run one system or two, and record the reasoning

    A single harmonised system is usually cheaper to operate and harder to build; two systems are easier to build and reliably diverge. This is an organisational determination with long consequences, and it should be made deliberately rather than by default.

  5. Plan for inspection by an authority with different expectations

    The evidence a notified body examines and the evidence a regulator examines overlap but are not the same, and the posture differs. Preparing for one and assuming the other is where confident organisations are surprised.

  6. Sequence the work against the market timeline honestly

    Quality-system changes that require operating history cannot be compressed. Saying so early is far cheaper than discovering it during a submission review.

A clause-level gap analysis, a list of substantive rather than vocabulary differences, a recorded decision on system architecture, an inspection-readiness view, and a sequence honest about what cannot be accelerated. Whether the system satisfies either authority is determined by those authorities, on the organisation’s evidence.

WHAT WOULD CHANGE THIS

  • A software-only device shifts the centre of gravity to design controls, lifecycle processes and cybersecurity, where the mapping above finds most of its residue.
  • If the device is Class III or its equivalent, the route to market rather than the quality system usually dominates the plan.
  • An organisation entering its FIRST regulated market has no system to map from, and builds against one framework rather than reconciling two — a simpler problem than this one, not a harder one.

FREQUENTLY ASKED

What is ISO 13485?

The international standard for a medical device quality management system — process-based and risk-aware, and the de facto global expectation for device manufacturers across design, production, and post-market activities.

What is the FDA QMSR?

The Quality Management System Regulation — the FDA final rule that harmonises 21 CFR Part 820 with ISO 13485 by incorporating the ISO standard by reference. It takes effect in February 2026, largely converging the US device quality requirements with the international standard.

What are design controls?

A formal, traceable design process — design inputs, outputs, verification, validation, design review, and design transfer, documented in the Design History File. Unique in emphasis to devices, and among the most commonly cited inspection findings.

How does ISO 14971 fit in?

ISO 14971 is the device risk-management standard, applied across the whole product lifecycle and woven through design controls, production, and post-market surveillance. Device quality is fundamentally risk-management-led, which is why 14971 sits at its centre.

PROFESSIONAL · INSPECTION PLAYBOOK · SPEQ SYNTHESIS

The inspection-readiness playbook for this topic

CHECKING ACCESS

Checking your Professional access…