QMSR for AI/ML Medical Devices: Design Controls, Software Validation, and Change Management

A radiology AI model can perform well in an experiment and still be difficult to release responsibly. The missing pieces are often not another algorithm: they are controlled requirements, reproducible testing, justified changes and retrievable evidence. QMSR for AI/ML medical devices makes those connections a quality-system concern, not merely a submission-writing exercise.

This guide focuses on device software used for imaging analysis. It translates regulatory expectations into a practical evidence trail without treating every radiology algorithm as the same device or promising that a checklist guarantees clearance.

What QMSR means for Imaging AI

The Quality Management System Regulation is FDA’s medical device quality-system framework under 21 CFR Part 820. It became effective February 2, 2026 and incorporates ISO 13485:2016 by reference, alongside FDA-specific provisions. FDA also began using CP 7382.850 for device manufacturer inspections. The FDA QMSR overview explains the transition and applicability.

QMSR governs how applicable manufacturers establish and operate their quality systems. It does not itself classify your algorithm, clear a product or replace a premarket submission. Start with device status, classification, intended use and applicable design-and-development requirements. Our QMSR complete guide provides the wider implementation context.

Turn intended use into controlled design inputs

Describe what the software does, who uses it, the patient population, imaging modality, anatomical target and role in clinical workflow. A tool that flags suspected abnormalities for review has different evidence needs from software claiming to diagnose or guide treatment. Specify supported scanner configurations and acquisition conditions rather than silently assuming all images are interchangeable.

Translate these boundaries into measurable inputs: supported image formats, exclusion handling, output presentation, processing limits and clinically justified performance criteria. Record where each criterion came from and who approved it. Link foreseeable hazards, including missed findings, excessive alerts, incorrect routing and over-reliance, to controls and tests.

Avoid requirements such as “accurate AI.” A defensible input identifies the task, population, metric, acceptance criterion and evaluation method. Thresholds must be justified for the particular device; no single accuracy number establishes suitability for every medical use.

Build one evidence chain, not disconnected binders

Use stable identifiers to connect each requirement to its risk analysis, implementation, verification result and validation conclusion. Separate the model artifact from the surrounding product: preprocessing, user interface, workflow routing, interoperability and error handling can affect safety even when model weights stay unchanged.

This table is a planning structure, not a substitute for applicable requirements. Sampling one complete release thread often reveals more than checking whether document titles exist. An unresolved test deviation should remain visible with its disposition, owner and effect on the release decision.

Separate verification from validation

Verification asks whether specified requirements were implemented correctly. Validation asks whether the device meets user needs and intended uses. For Imaging AI, that distinction prevents a successful unit-test suite from being presented as proof of clinical performance.

FDA’s device software submission guidance describes documentation for device software functions using Basic and Enhanced Documentation Levels. The documentation level must be justified; it is not determined solely by using machine learning. Submission documentation and quality-system records overlap, but one does not replace the other.

Retain reproducible configurations: code commit, model version, dataset snapshot, dependency versions and execution environment. Test realistic invalid inputs and degraded conditions, not only clean images. Document known anomalies and why their residual effects are acceptable or require correction. Where clinical studies are needed, plan endpoints and analyses before accessing final test results.

Treat every AI change as an impact assessment

Changes include retraining data, model architecture, operating thresholds, image normalization, libraries and user-facing outputs. Evaluate their effect on intended use, risk controls, performance, cybersecurity, interfaces and labeling. Assign review responsibilities and specify regression and revalidation evidence before implementation.

A supplier update is still a controlled change when it affects the device. Obtain sufficient information to assess it, define acceptance checks and retain the approved configuration. Deployment teams should be able to identify which version reached which environment and how a failed release can be contained.

A useful change record states the proposed modification, rationale, affected requirements, evidence needed, regulatory assessment and approval. “Performance improved” alone is not a defensible disposition if gains in one subgroup conceal losses in another.

Understand the boundaries of a PCCP

FDA’s August 2025 final AI-enabled device PCCP guidance describes a Description of Modifications, Modification Protocol and Impact Assessment. FDA reviews the plan within a marketing submission. An authorized PCCP can support specified modifications implemented consistently with that authorization without another marketing submission for each covered change.

It is not permission for unrestricted learning after deployment. A change outside the authorized plan requires its own regulatory assessment under the applicable pathway. Our interactive PCCP guide helps organize scope and evidence questions; it does not determine authorization.

Inspection-ready release checklist

• Approved intended use matches labeling and validation scope.
• Requirements, hazards, controls and test results are traceable.
• Dataset and model versions are recoverable without reconstruction.
• Deviations and known anomalies have documented dispositions.
• Change reviews distinguish quality approval from regulatory assessment.
• Release approval identifies the deployed configuration and monitoring responsibilities.

Assign owners to missing evidence and verify corrective actions rather than closing gaps through document renaming. Electronic approvals and audit trails also deserve attention; use our Part 11 guide to assess applicable electronic-record controls.

Download the Imaging AI evidence register

Download the Imaging AI Design Controls and Change Evidence Register.xlsx. Use it to record requirements, hazards, evidence references, configuration, change impact and approvals. It is an editable preparation aid, not an FDA form or certification tool. Keep patient information and confidential datasets out of a generic planning worksheet.

Put the evidence to work with MedTech Copilot

Explore MedTech Copilot to structure fragmented development, quality, risk, V&V and regulatory work into an evidence-backed workflow. Start with approved requirements and source references, then have qualified reviewers assess proposed outputs and unresolved gaps. Request a focused demonstration using a non-confidential example of your Imaging AI release process.

FDA primary sources

• Quality Management System Regulation: applicability, effective date and inspections.
• Content of Premarket Submissions for Device Software Functions: June 2023 final guidance.
• AI-enabled device PCCP recommendations: August 2025 final guidance.

Guidance generally describes recommendations, whereas applicable regulations establish obligations. Verify current versions and device-specific applicability before adopting an implementation plan.