For early-stage digital pathology companies, regulatory strategy often takes a back seat to algorithm development and clinical validation. This is understandable — you cannot regulate a product that does not work — but it creates a predictable bottleneck when the science is mature enough to pursue clearance and the team discovers that the regulatory documentation gap is enormous. Getting ahead of this by understanding the SaMD (Software as a Medical Device) framework early is not about legal compliance for its own sake. It is about building the software architecture and documentation infrastructure in a way that makes eventual clearance tractable.
This piece describes the regulatory landscape as it applies specifically to IHC biomarker quantification software — tools that compute HER2, PD-L1, or Ki-67 scores from whole-slide images and present results in a clinical context. It is not legal advice. For any actual regulatory submission, engage a qualified regulatory affairs specialist with SaMD experience. But it is an honest map of the terrain as we understand it in 2025.
Does IHC Scoring Software Require FDA Clearance?
The first question is whether the software is a medical device at all under FDA's definition. Under the 21st Century Cures Act (2016) and FDA's 2019 final guidance "Proposed Regulatory Framework for Modifications to Artificial Intelligence/Machine Learning-Based Software as a Medical Device," software is a medical device if it meets the definition in 21 CFR 880.3700 (General Purpose Laboratory Equipment) or Section 201(h) of the Federal Food, Drug, and Cosmetic Act — meaning it is intended for use in the diagnosis of disease or for treatment decisions.
IHC quantification software sits in a nuanced zone. Software that computes a Ki-67 percentage and presents it as a decision aid to a pathologist who then exercises independent clinical judgment may qualify under FDA's "clinical decision support software" provisions — potentially falling outside device regulation under the CDS provisions of the 21st Century Cures Act if it meets all four criteria: it is not intended to acquire or process a signal from a device; it displays information in a form that allows a clinician to review the basis for the recommendation; a clinician independently reviews the basis for the recommendation; and it is not intended to replace clinical judgment but to support it.
However, software that computes an IHC score that is directly imported into a diagnostic report without mandatory pathologist review of the underlying data would likely be classified as a device. The key regulatory distinction is whether the healthcare professional can independently review the basis for the recommendations — if the algorithm's output is presented as a validated measurement with a supporting spatial heatmap and cell-level detection data, and the pathologist can review all of that before signing off, the CDS exclusion may apply. If the output is a number with no accessible supporting data, it is harder to make that argument.
The 510(k) Pathway and Predicate Identification
If the software is determined to require clearance, the most common pathway for IHC quantification tools is 510(k) premarket notification, which requires demonstrating substantial equivalence to a legally marketed predicate device. The relevant device classification for pathology image analysis software is typically product code QNL (pathology-class II), and several cleared predicates exist in the computational pathology space — though the landscape of cleared AI-assisted IHC scoring software is still relatively sparse compared to, say, radiology AI tools.
A 510(k) submission for IHC software requires a substantial equivalence argument that addresses: intended use (the same patient population and clinical indication as the predicate), technological characteristics (if different from the predicate, the submission must show they do not raise new safety or effectiveness questions), and performance data demonstrating that the device performs comparably to the predicate for the specific intended use.
The performance data requirement is where the analytical validation work matters. For an IHC scoring tool, this means a clinical study comparing algorithmic output to a reference standard (typically a panel of expert pathologists) on a statistically powered cohort, with appropriate sensitivity, specificity, and concordance metrics stratified by the clinically relevant scoring categories. The study design should anticipate what FDA will want to see — pre-specified primary endpoints, pre-specified acceptability criteria, and an analysis plan that addresses the specific clinical decision the score is intended to support.
The De Novo Pathway for Novel AI Tools
If no adequate 510(k) predicate exists — which is possible for novel algorithmic approaches that do not map cleanly to existing cleared devices — the De Novo classification pathway provides a route to authorization. De Novo creates a new device classification and is typically more resource-intensive than 510(k), but it also creates a new predicate that subsequent 510(k) submissions can reference.
For AI pathology tools incorporating machine learning models that adapt post-deployment (a concept FDA has been developing guidance on under the "predetermined change control plan" framework), De Novo may be appropriate even when traditional predicates nominally exist, because the adaptive nature of the algorithm may constitute a different technological characteristic than a static predicate device.
IVD Companion Diagnostic Considerations
For IHC scoring tools tied specifically to FDA-approved companion diagnostics — such as PD-L1 scoring intended to inform pembrolizumab treatment eligibility — the regulatory pathway is significantly more complex. Companion diagnostic (CDx) software falls under the IVD (In Vitro Diagnostic) regulatory framework and requires either a separate PMA (Premarket Approval) application or co-development coordination with the pharmaceutical sponsor. The bar for analytical and clinical validation in the CDx context is substantially higher than for a general decision-support tool.
We are not saying that the CDx pathway is categorically required for all algorithmic PD-L1 scoring — a tool marketed explicitly for research use only (RUO) or investigational use does not require CDx clearance. What we are saying is that any marketing language or clinical workflow positioning that implies treatment eligibility determination requires careful regulatory review before deployment.
SaMD Risk Classification: IMDRF Framework
FDA has aligned with the International Medical Device Regulators Forum (IMDRF) SaMD risk classification framework, which categorizes SaMD by the severity of the healthcare situation it addresses and the significance of its role in that situation. Under this framework, software that provides a "critical" information output used to drive diagnosis or treatment in a "serious" disease context (such as IHC scoring in oncology) falls in the highest risk category — Category IV — and warrants the most stringent regulatory scrutiny.
This matters practically because it means the validation bar is higher, the quality management system requirements are more stringent, and the post-market surveillance obligations are more demanding than for lower-category SaMD. An IHC scoring tool should be designed with the assumption that it will ultimately need to meet Category IV standards, not the assumption that regulatory requirements can be bolted on later.
Documentation Architecture: Building for the Submission
The regulatory documentation burden for a 510(k) submission is significant and is substantially more tractable when built into the development process from the start. The key documents a submission will require include:
- A software description document (SDD) covering software architecture, intended use, user interface design, and how the software fits into the clinical workflow
- A risk management file per ISO 14971 (Application of Risk Management to Medical Devices) — which requires hazard identification, risk estimation, risk control measures, and residual risk evaluation
- Software development lifecycle documentation per IEC 62304 (Medical Device Software — Software Life Cycle Processes) — including requirements, design, verification, and validation records
- Analytical performance testing data — the concordance study against reference standard pathologist reads
- Usability engineering documentation per IEC 62366-1, demonstrating that the user interface design supports safe and effective use
- Cybersecurity documentation per FDA's 2023 cybersecurity guidance for medical devices
Building a software development process that generates this documentation as a natural byproduct — rather than reconstructing it retrospectively from code commits and meeting notes — is the practical difference between a 6-month submission preparation timeline and an 18-month one.
The Research Use Only Escape Hatch and Its Limits
Many early-stage digital pathology tools are marketed and deployed under "Research Use Only" (RUO) labeling. RUO explicitly removes the product from FDA device regulation but also imposes an obligation: the product genuinely cannot be used in clinical decision-making. The FDA has issued warning letters to diagnostics companies using RUO labeling for products that were demonstrably being used in clinical workflows. The distinction is not a formality — if an academic center's pathology department is using an RUO-labeled tool's output in diagnostic reports, the tool is functioning as a medical device regardless of its label.
For a company building toward eventual clearance, the RUO period should be understood as a research and validation phase, not a permanent deployment strategy. The clinical sites using the tool during RUO should understand this boundary, the output should not flow directly into clinical reports without explicit investigational use agreements, and the company should be actively building the submission-ready validation package while the tool is in investigational use.
The SaMD regulatory landscape for IHC scoring tools is navigable. It is not fast, it is not cheap, and it rewards companies that plan their documentation architecture early. A tool built with 510(k)-ready architecture from the outset — risk management records, IEC 62304 process documentation, pre-specified analytical performance endpoints — is in a fundamentally different position than one that has been deployed in investigational use for two years without any documentation infrastructure. The science of getting the IHC score right and the regulatory science of proving it are both necessary, and they are best built in parallel.