Digital Pathology Software QMSR Checklist: SaMD Lifecycle, Validation, Cybersecurity, and Change Control

Digital pathology software can support image review, measurement, prioritization or pathology diagnosis, but those products do not share one regulatory profile. Intended use, users, specimen types, input devices, output claims and system dependencies determine the applicable classification, marketing pathway and quality-system evidence. Under the Quality Management System Regulation (QMSR), software development must also operate as a controlled lifecycle: requirements, risk management, verification, validation, cybersecurity, release, change control and postmarket feedback need to connect.

This checklist focuses on software as a medical device (SaMD) used with digital pathology workflows. It separates product-software validation from imaging-system evidence, clinical evaluation, cybersecurity artifacts and assurance for production or quality-management software.

Establish intended use before selecting controls

Begin with the clinical task and user decision. State whether the software displays images, identifies regions, quantifies features, prioritizes cases or assists a pathology diagnosis. Identify specimen types, scanners, viewing software, input formats, users, output devices and the intended role relative to standard-of-care review.

21 CFR 864.3750 covers a specific Class II category: a software algorithm device intended to evaluate acquired whole-slide images and assist users in determining a pathology diagnosis. Its labeling provisions address specimens, inputs, outputs, users, necessary devices and the adjunctive role of the software. Do not treat that classification as a blanket answer for every digital pathology product. Record the applicable classification and authorization basis for the actual device.

QMSR incorporates ISO 13485:2016 into 21 CFR Part 820 and retains FDA-specific provisions. The QMSR implementation guide covers the broader quality-system sequence. For software, the practical question is whether one requirement can be traced through architecture, risk controls, verification, validation, release and later change.

Build the SaMD lifecycle as one evidence chain

FDA’s Content of Premarket Submissions for Device Software Functions guidance, issued June 14, 2023, describes documentation supporting FDA’s evaluation of device software. A submission package is not a substitute for lifecycle compliance. Maintain controlled requirements and architecture, identify software items and interfaces, manage anomalies, connect hazards to mitigations and retain objective evidence for the released configuration.

Digital pathology adds system dependencies. Scanner performance, image compression, color presentation, viewing behavior, network constraints and user workflow can affect the software claim. FDA’s technical performance assessment guidance for whole-slide imaging devices can inform relevant imaging-system evaluation, but it does not by itself establish clinical performance. Keep technical platform evidence distinct from software analytical and clinical evidence.

The adopted IMDRF framework for SaMD clinical evaluation separates valid clinical association, analytical validation and clinical validation. Map each claim to the right category. A precise tissue-region measurement, a heat map and a diagnostic aid do not necessarily require the same evidence. The radiology AI validation article provides a related model for data provenance, leakage control and performance traceability.

Treat cybersecurity as a lifecycle control

FDA’s current Cybersecurity in Medical Devices guidance was issued in February 2026 and supersedes the 2025 version. Assess cybersecurity during design, not as a release-week document exercise. The threat model, architecture, security requirements, testing, labeling and vulnerability-response process should align with the device’s intended environment.

Section 524B applies to a “cyber device” when statutory elements are met: software validated, installed or authorized by the sponsor; capability to connect to the internet; and technological characteristics that could be vulnerable to cybersecurity threats. FDA’s cybersecurity frequently asked questions explain those elements and related obligations, including vulnerability monitoring and response, processes supporting cybersecurity updates and a software bill of materials when applicable. Document the applicability decision rather than assuming every pathology product is, or is not, a cyber device.

Maintain a current component inventory covering commercial, open-source and off-the-shelf software. Assign ownership for monitoring, triage, remediation, customer communication and patch release. A scanner, hospital network, cloud service or operating-system change can alter exposure, so cybersecurity review belongs inside change control and postmarket surveillance.

Gate every software change before release

Not every software update requires a new 510(k), but a documented assessment is needed when the device is subject to 510(k) requirements. FDA’s software-change guidance provides a decision framework for changes to existing devices. Evaluate the change against intended use, risk controls, architecture, performance evidence, cybersecurity, labeling and validation coverage. Record why the affected evidence remains adequate or what new evidence is required.

Model retraining, threshold changes, scanner additions, operating-system updates and interface changes can affect different parts of the evidence chain. An authorized PCCP may support specified modifications under its conditions; the PCCP guide explains how to organize that assessment. For imaging AI lifecycle controls, see the QMSR for AI and ML medical devices article.

Do not confuse validation of the marketed pathology software with assurance for software used in production or the quality system. FDA’s February 2026 Computer Software Assurance guidance addresses risk-based assurance for production and quality-management-system software. An eQMS workflow, automated test tool or manufacturing application needs an intended-use and risk-based assurance assessment; that assessment does not replace product-software verification and validation. Our Part 11 guide can help assess applicable electronic-record controls.

Download the digital pathology checklist

Download the editable Digital Pathology QMSR Release-Readiness Checklist.xlsx. Assign owners, record configuration scope and link validation, cybersecurity and change-control evidence. It is a preparation aid, not an FDA form, certification tool or substitute for product-specific regulatory judgment.

• Intended use, classification, users, specimens and compatible devices are controlled.
• Requirements connect to risk controls, verification, validation and release.
• Technical, analytical and clinical evidence are mapped to the correct claims.
• Cybersecurity applicability, SBOM and vulnerability-response ownership are current.
• Every software change has a documented quality and regulatory impact decision.

FDA primary sources

Use current 21 CFR Part 820, 21 CFR 864.3750, FDA’s device software submission guidance, whole-slide imaging technical assessment guidance, SaMD clinical evaluation notice, cybersecurity guidance, cybersecurity FAQs, software-change guidance and Computer Software Assurance guidance.

Turn checklist work into traceable execution

Use MedTech Copilot to structure lifecycle evidence, validation decisions, cybersecurity ownership and change-control actions around clear next steps. Qualified human reviewers remain responsible for applicability, release and regulatory decisions. The goal is practical, evidence-backed, inspection-ready implementation—not automated assurance of compliance.