A medical-device quality management system is not simply a document repository with approval workflows. It is the operating system that connects intended use, regulatory requirements, product risk, design evidence, supplier controls, manufacturing records, complaints and postmarket action.
That distinction matters because a general-purpose quality system may control documents and corrective actions while still missing the traceability and lifecycle evidence expected for a medical device. Software can support the system, but the organization must define the processes, responsibilities and records that make the system effective.
The current U.S. quality-system framework
On February 2, 2026, the U.S. Food and Drug Administration’s Quality Management System Regulation (QMSR) became effective. The revised 21 CFR Part 820 incorporates ISO 13485:2016 by reference and adds or clarifies U.S.-specific requirements. FDA describes this as an alignment of its device current good manufacturing practice framework with the quality-management standard used by other regulatory authorities.
The FDA QMSR overview and the current 21 CFR Part 820 are the primary U.S. references. ISO explains that ISO 13485:2016 defines a quality-management system specific to organizations involved in medical devices and related services.
ISO 13485 certification and regulatory compliance are related but different questions. ISO states that certification is not required by the standard itself. A manufacturer still has to determine and meet the regulatory requirements that apply to its devices, markets and activities. Website copy should therefore never treat a certificate, a compliant process and a cleared or approved product as interchangeable claims.
How a medical-device QMS differs from a generic QMS
| System element | General quality approach | Medical-device requirement |
|---|---|---|
| Product definition | Customer needs and product specifications | Intended use, indications, users, use environments, device classification and applicable regulatory controls |
| Risk | Business, process or product risk as the organization defines it | Product safety risk managed across the lifecycle, commonly using ISO 14971 as the framework |
| Design | Project procedures chosen by the company | Controlled design and development where applicable, with planned reviews, inputs, outputs, verification, validation, transfer and change control |
| Traceability | Record links sufficient for internal operations | Documented relationships among requirements, risks, design outputs, tests, manufacturing records, labeling and postmarket information |
| Suppliers | Commercial qualification and incoming quality | Controls proportionate to how a supplier can affect device safety, performance and regulatory compliance |
| Complaints and feedback | Customer-service and defect trends | Evaluation, investigation, recordkeeping and regulatory reporting when applicable |
| Records | Evidence retained to support the business process | Specified records, retention, integrity, accessibility and regulatory inspection expectations |
Risk management must connect to engineering
ISO 14971:2019 defines a lifecycle process for identifying hazards, estimating and evaluating risk, implementing controls and monitoring whether those controls remain effective. ISO confirmed the 2019 edition as current in 2025. The risk-management file should not operate as a parallel paperwork exercise. Its outputs should influence design inputs, architecture, user-interface requirements, protective measures, verification methods, manufacturing controls and postmarket monitoring.
For example, a hazardous situation caused by excessive actuator motion may lead to mechanical travel limits, current or torque limiting, position plausibility checks, watchdog behavior, user-interface warnings and specific fault-injection tests. A useful QMS keeps that chain visible: hazard to risk control, risk control to requirement, requirement to implementation, and implementation to objective evidence.
See the official ISO 14971:2019 overview for the standard’s scope and lifecycle role.
Design controls are more than phase-gate paperwork
Under current 21 CFR 820.10(c), manufacturers of Class II and Class III devices, plus specified Class I devices, must comply with the design-and-development requirements of ISO 13485 Clause 7.3. The exact development model can vary. Iterative prototypes, agile software increments and concurrent engineering can fit within a controlled process when responsibilities, configuration, review, evidence and change history remain clear.
A working design-control system should answer practical questions:
- Who approved each input, and what user need or risk does it address?
- Which design output implements the requirement?
- What verification demonstrates that the output meets the input?
- What validation demonstrates that the resulting device meets user needs and intended use?
- Which product configuration was tested?
- How did a design change affect risk, interfaces, test coverage, labeling and manufacturing?
The QMS has to cover the entire product system
Hardware, software and interfaces
Electrical, mechanical, optical, fluidic and software subsystems cannot be controlled in isolation. Interface requirements often contain the most consequential assumptions: signal ranges, connector keying, timing, tolerance stackups, calibration dependencies, thermal boundaries, fault states and communication behavior. The QMS should make ownership and verification of those interfaces explicit.
Human factors
FDA’s 2026 human-factors guidance emphasizes intended users, uses and use environments. User-interface risks should feed design inputs early enough for formative work to change the design. Summative or validation activities cannot compensate for an unsafe interface architecture discovered too late.
Cybersecurity
For connected or software-enabled devices, security is part of product design and risk management. FDA’s 2026 medical-device cybersecurity guidance recommends cybersecurity design inputs, acceptance criteria and evidence appropriate to the device and system. The QMS should connect threat modeling, architecture, software configuration, vulnerability handling and update processes.
Production and post-production information
Design transfer is not an administrative handoff. Production equipment, fixtures, inspection methods, software-loading steps, calibration, work instructions and acceptance criteria must reproduce the approved design. Complaints, nonconformances, service records, supplier data and production trends should then feed risk review and corrective action.
What to evaluate before selecting QMS software
Start with process and evidence needs. A software demonstration can make weak processes look complete because every screen contains a status field. Evaluate whether the system can represent the relationships and controls your organization actually needs.
- Map applicable requirements. Define device types, markets, organizational roles and lifecycle activities.
- Define controlled records. Identify approvals, signatures, configuration baselines, retention and access requirements.
- Model traceability. Test whether a reviewer can move from user need to design input, risk control, output, verification and change history.
- Test change impact. Confirm that a design or supplier change triggers the right technical and quality reviews.
- Assess integrations. Consider product lifecycle management, source control, issue tracking, ERP, calibration, training and complaint systems.
- Plan migration and validation. Moving records or automating regulated workflows creates its own integrity and verification work.
A useful QMS produces better engineering evidence
The strongest medical-device QMS makes technical decisions easier to reconstruct and challenge. It helps teams find ambiguous inputs, unmanaged interfaces, incomplete risk controls and missing verification before those gaps reach a submission, transfer build or field issue.
Outer Reef’s medical-device quality and regulatory engineering connects quality planning to the mechanical, electrical, software and systems work that produces the evidence.
