QMSR vs ISO 13485: How FDA's Quality Management System Regulation Relates to ISO 13485:2016

QMSR vs ISO 13485 is the comparison between FDA’s quality-system regulation for US finished devices intended for human use, scoped by 21 CFR 820.1(a), and the ISO 13485 medical-device quality-management standard incorporated by reference as stated in 21 CFR 820.10(a). For US human-device manufacturers subject to Part 820, the documented quality management system must comply with applicable ISO 13485 requirements and other applicable Part 820 requirements.

The practical comparison is therefore not a choice between two interchangeable systems. Separate the governing instrument from the evidence used to assess it. The following framework keeps system conformity, certification and product authorization from collapsing into a single status.

As a practical safeguard, do not mark a site FDA-compliant or a device FDA-approved solely because an ISO certificate is present. Keep certification, regulatory-conformity and product-authorization decisions separate, with a stated scope and evidence basis for each.

Throughout this comparison, Part 820 provisions describe US regulatory requirements for human-device manufacturers within scope. Official guidance is a separate source category; proposed workflows are industry practice; software is implementation support. These categories distinguish binding obligations from recommendations and tools.

For US finished devices intended for human use, 21 CFR 820.1(a) governs the methods, facilities and controls used for design, manufacture, packaging, labeling, storage, installation and servicing. This is a device-specific applicability boundary, not a general rule for every regulated manufacturing sector.

US human-device manufacturers subject to Part 820 must establish and maintain a quality management system appropriate for their specific devices. For those US manufacturers, where only some covered operations are performed, the obligation extends only to requirements applicable to the operations in which they are engaged.

For US human devices, 21 CFR 820.3(a) defines a finished device as a device or accessory suitable for use or capable of functioning, whether or not packaged, labeled or sterilized. In a practical scope assessment, unfinished packaging is therefore a poor substitute for assessing the product’s functional status.

For US human-device operations, Part 820’s manufacturer scope expressly includes contract sterilization, relabeling and specification development. As an assessment practice, examine each party’s actual activities and interfaces rather than treating outsourcing as a complete answer to applicability.

For US human devices, 21 CFR 820.1(b) provides that device-specific applicable requirements supersede more general applicable requirements where Part 820 conflicts with other FDA regulations; where incorporated ISO provisions conflict with the FD&C Act or its other implementing regulations, the Act or those regulations control.

Record the boundary before building the crosswalk

A proposed assessment sequence—not a prescribed regulatory procedure—is: jurisdiction → product type and finished-device status → device family → performed operations → outsourced interfaces → owner assessment → documented rationale. This keeps the FDA QMSR assessment tied to the operating model before detailed process mapping begins.

• Record jurisdiction, product type and device family so the scope decision identifies the products and market being assessed.
• List performed operations and outsourced interfaces separately, naming the responsible parties and the evidence used to describe their roles.
• Assign an assessment owner and record the rationale for each applicability decision, including unresolved questions and the person responsible for resolving them.

Use this record as an input to ISO 13485 readiness planning, not as a substitute for evaluating the applicable requirements.

Use a cross-reference register to connect each applicable provision to a local process, an accountable role and execution evidence. For an FDA QMSR implementation review, the table below separates binding regulatory connections from suggested artifacts and function assignments. The suggested evidence and owners are practical review choices, not additional mandatory record formats or prescribed organizational roles.

Connect the procedure to evidence of execution

A documented procedure describes how work is intended to happen; an execution record shows what happened in a particular instance. As a practical review method, follow each register entry from the applicability decision through the current procedure to a completed assessment or activity record. For unique device identification, for example, review system ownership alongside evidence of an actual assignment rather than treating a procedure title as proof of operation.

Keep neighboring-rule criteria in their own current applicability assessments and link those decisions back to the register. When the product, process or assessment changes, have the assigned owner review the relationship and record whether the local procedure and execution evidence still fit. This keeps the crosswalk useful as a control map rather than a list of regulatory references.

In common legacy device-quality usage, DMR means device master record, DHF means design history file and DHR means device history record. Their practical distinction is evidence purpose: product specifications, design-decision history and production-execution evidence, respectively. Treat these as mapping categories, not as a claim about current legal naming or retention requirements. Renaming folders alone does not establish conformity.

Use a purpose-based inventory rather than declaring a universal one-to-one replacement by a medical device file. The locations below are illustrative, not prescribed repositories.

For US human-device manufacturers under 21 CFR 820.3(b), rework means action on nonconforming product so it fulfills specified requirements in the medical device file (MDF) before release for distribution. This definition is not a complete inventory of MDF contents. For US human devices under that same provision, organization means manufacturer as defined in Part 820; this is a terminology boundary, not a statement about certification scope.

For the proposed data model, keep applicability decisions, control mappings, evidence records, exceptions and review decisions as separate record types. Link them using stable record identifiers, revision references and accountable owners. An applicability decision explains why a control applies; a mapping points to evidence; an exception records a gap; a review decision records the disposition. These are illustrative design fields, not mandated fields.

As a practical data-integrity design check, retrieve the historical evidence through those links: can a reviewer identify the applicable revision and distinguish an unresolved exception from an accepted review decision?

For US human-device manufacturers, 21 CFR 820.10(c) requires manufacturers of class II, class III and specified class I devices to comply with the incorporated design-and-development requirements. Establish that applicability before planning design controls for a proposed change.

The following is a recommended evidence lifecycle for change control, not a summary of ISO clauses. Its purpose is to connect the reason for a change to the affected devices, the decision and the evidence that the action worked.

1. Open the change request with the triggering information and proposed action. Identify the specification being changed, affected device configurations and the rationale for excluding other configurations.
2. Review risk and plan verification. Record what could be affected, what evidence supports the proposed decision and what results would support acceptance. Identify unresolved assumptions before approving implementation.
3. Identify controlled document changes. Connect the proposed specification revision to affected manufacturing, inspection, labeling or service instructions, as relevant.
4. Capture implementation evidence. Identify which revisions were introduced, where they took effect and which device configurations received the change. Keep planned work distinguishable from completed work.
5. Review after implementation. Compare observed results with the intended outcome and decide whether further assessment, correction or monitoring is warranted.

Complaint trends, nonconforming output and supplier issues commonly feed this assessment. A signal is not itself proof that a design change is necessary: triage may support a process correction, supplier action, further investigation or a documented decision not to change the design. Preserve the reasoning connecting the input to that disposition.

Keep technical evaluation, quality decision and implementation status separate. As a practical ownership model, name the engineering reviewer for technical adequacy, the authorized quality approver for the proposed action and the operations owner for implementation evidence. At review, ask: which specification changed, which configurations are affected, what supports the decision, which instructions changed and how is implementation demonstrated?

For implementation planning, distinguish software that performs a device’s product functions from software used to operate the manufacturer’s quality processes. Treat the latter as an evidence-handling environment: where records originate, move, change and become available for review. Assess electronic-record and electronic-signature applicability separately; do not infer a 21 CFR Part 11 conclusion from QMSR status alone.

Specify what crosses the interface

A practical MES–QMS interface specification commonly covers the following design considerations, rather than treating each field as a universal legal mandate:

• Authoritative source: which system controls the record and resolves conflicting copies.
• Record identifier and device or lot relationship: how the receiving system preserves identity and context.
• Revision: which version was sent and whether it remains current.
• Transfer status and receiving-system acknowledgment: distinguish sending from confirmed receipt and usable acceptance.
• Reconciliation owner: who investigates differences and documents closure.

Recover exceptions before relying on the evidence

For rejected, duplicated or partially transferred records, a practical recovery sequence is to retain the source record, identify the failure and prevent unreviewed reliance on incomplete information. Correct the cause, reconcile source and destination, and document the recovery decision. Before retrying, check whether the destination already holds part of the transfer so that recovery does not create another duplicate.

For example, assume a manufacturing record arrives without its inspection attachment. A successful transport status alone is insufficient for the intended review. The reconciliation owner checks the attachment relationship and records the resolution; an authorized reviewer then evaluates the complete evidence.

Assess access controls, change history, signature functions and retrieval in their intended operating context—not as proof of compliance. Keep that feature assessment separate from the legal applicability decision. In an electronic release workflow, system status can indicate readiness for review; approval and release decisions remain with authorized humans.

Use a jurisdiction-and-product matrix as a practical scoping tool, starting from the applicability boundary above. The entries below are assessment prompts, not legal conclusions. Populate operating roles and named owners for each product line before deciding which processes can be shared.

For US HCT/Ps regulated as devices, 21 CFR 820.1(a)(4) adds donor-eligibility requirements under part 1271, subpart C, and applicable current good tissue practice requirements under 21 CFR 1271, subpart D. This statement does not extend to all HCT/Ps.

Use EU MDR and IVDR as separate market-assessment workstream labels, not as declarations of equivalence to QMSR.

A shared complaint intake can capture product and market identifiers, then route assessments to distinct owners and retain their decision records. Shared document control can similarly identify which products and markets each procedure covers. A common workflow should preserve these boundaries rather than merge separate determinations into a single completion status.

These hypothetical cases illustrate review practice, not additional legal requirements.

Relabeler: a controlled labeling revision

Assume a US finished human-use device operation performs relabeling, but not design. The unit of analysis is a controlled labeling revision. Apply the operations-based scope discussion above: identify the labeling process, governing instruction revision, execution evidence and outsourced interfaces, including label supply and approval handoffs. Link the revision to relevant device history evidence. The assumed role is not a blanket exemption conclusion.

Next decision: the labeling process owner, with quality review, decides whether the revision is ready for use, using approved instructions, execution checks and resolved supplier-interface questions.

Design change: a device configuration

Assume a US class II device manufacturer is implementing an approved design-change request. The unit is the affected device configuration. Using the design-applicability discussion above, follow that configuration to the change rationale, supporting evidence references and revised production instructions. Use requirements traceability to expose missing connections rather than treating request approval as implementation authorization.

Next decision: the designated change approver decides whether to authorize implementation, using configuration-specific evidence, reviewed instructions and the disposition of unresolved questions.

Complaint interface: a complaint record

Assume a US finished human-use device manufacturer transfers complaint intake between systems. The unit is a complaint record whose transfer lacks its device identifier and receipt acknowledgment. Assign transfer recovery to the integration owner: retain original intake information, investigate the missing identifier and reconcile the receiving record. Record recovery actions separately from the complaint owner's assessment; technical recovery does not decide reportability.

Next decision: the complaint owner determines the assessment and escalation path using original intake, reconciled identifiers, receipt evidence and documented uncertainties, preserving the decision trail without assuming a reporting outcome.

Use these practical review tests to prepare explainable evidence, not to predict agency inspection priorities. Start with an actual device configuration, lot or service event and follow its evidence relationships through to a recorded decision. Assess missing connections and ambiguous ownership, rather than only whether a procedure exists.

Retrieving a current document answers what is available now. Establishing the version associated with a historical record answers what instruction or specification governed that activity. A working hyperlink alone does not establish that relationship.

For transfers, use the MES–QMS integration boundary as a review point. For closed actions, distinguish implementation evidence from the subsequent CAPA effectiveness check. Record each retrieval gap with an owner and a resolution decision so the exercise produces actionable findings.

Use the following as proposed work packages: applicability confirmation, process mapping, evidence retrieval, interface testing, role assignment, gap disposition and ongoing review. These are planning activities, not statutory milestones or deadlines. Adapt their sequence and the suggested accountable functions below to the devices and operations involved.

For each gap, record the affected device or process, applicable source, current evidence, missing relationship or control, interim handling, owner, planned action and reviewer. Classify unresolved legal applicability separately from implementation work: an interpretation awaiting a regulatory decision is not the same as an agreed control awaiting execution. Record the interpretation before using it as a task’s acceptance basis.

Base closure on documented review of implementation evidence, not a completed task status. Record the reviewer’s decision and any residual actions, naming the accountable reviewer identified in the table above. Where appropriate, distinguish implementation completion from a later CAPA effectiveness check.

Reassess when device scope, performed operations, suppliers, system interfaces or relevant regulatory references change. Route unresolved cross-functional issues into management review; this proposed approach does not prescribe a review interval.

What if evidence sits with a supplier?

Ask whether the reviewer can retrieve the relevant version and assess its connection to the affected device or process. Track an access request separately from acceptance of the evidence.

When should a closed gap reopen?

Compare new information with the recorded closure basis. If it undermines that basis, preserve the original decision and open a linked reassessment with an owner and interim handling.