Regulatory Updates 11 min read

MCI Prognostic Software Classified Class II: What to Do

J

November 11, 2026

What Changed, and What Is the Lesson?

FDA published a classification order in the Federal Register on November 5, 2026 (document 2026-22590, titled "Medical Devices; Neurological Devices; Classification of the Prognostic Assessment Software of Mild Cognitive Impairment"). The order places this device type into class II with special controls. FDA says it took the action because class II classification, with those special controls, provides a reasonable assurance of safety and effectiveness. The special controls are codified in the order, and the order is the document you will be held to.

The lesson I would take from it: a classification order converts a one-company approval into a public rulebook. Before the order, the only way to understand what FDA expected from this kind of software was to read one sponsor's decision documents. After it, the expectations sit in codified regulatory text, and your job becomes showing, control by control, that you meet them. That is a more predictable conversation, but only if you read the controls before you write your validation protocol rather than after.

Source: Federal Register, 2026-22590.

What I Can and Cannot Tell You From the Order Summary

I want to be exact about this, because compliance work goes wrong when guesses get mistaken for text. The published summary of the order confirms the class (II), the control type (special controls) and the rationale (reasonable assurance of safety and effectiveness). The details that decide your plan are in the codified portion of the order, and I am not going to paraphrase them from memory:

Item to pull from the order Where it appears Why it decides your plan
Identification paragraph (what the device is, what it takes in, what it outputs) Codified text, new section in 21 CFR Part 882 Your intended use must fit inside it, or you are outside the device type
21 CFR section number and product code Codified text and FDA's Product Classification database Needed for your 510(k) cover sheet and predicate search
Special controls (lettered or numbered list) Codified text Each one becomes a test report, design output or labeling statement
510(k) exemption status Order text, and 21 CFR 882 exemption language if any Decides whether you file a submission at all
Effective date Dates section at top of the notice Starts the clock for any compliance transition
Originating De Novo request and granted device Background section Names your most likely predicate

If you only do one thing after reading this article, fill in that table from the order, with a page or paragraph reference next to each row. I'd rather you spend twenty minutes with the primary text than rely on any secondary summary, including mine.

What Does Class II (Special Controls) Mean for This Device?

Section 513(a)(1)(B) of the Federal Food, Drug, and Cosmetic Act defines class II as the category for devices where general controls alone are not enough to assure safety and effectiveness, but enough information exists to establish special controls that can. Two layers apply to you:

  • General controls reach nearly every device: establishment registration and device listing (21 CFR Part 807), labeling (21 CFR Part 801), medical device reporting (21 CFR Part 803), corrections and removals (21 CFR Part 806), and the quality system requirements of 21 CFR Part 820.
  • Special controls are the device-specific requirements written into the classification regulation. They are what this order adds.

Under section 510(k) of the FD&C Act and 21 CFR Part 807 Subpart E, a class II device needs premarket notification unless FDA exempts it. The order states whether it does. I would not assume either answer, because a software device with a prognostic output is an unlikely candidate for an assumption.

Why Did FDA Classify It This Way?

Under section 513(f)(2) of the FD&C Act, a device with no predicate is automatically class III until the sponsor asks FDA to classify it by risk through a De Novo request. Orders with this title format are how FDA publishes the resulting classification once a request is granted. The background section of the order identifies the request and the granted device, and you should note both, because that device is where your predicate search begins.

What matters for you is the reasoning FDA attaches to the risk. For prognostic MCI software, the risk is not physical harm from the device itself. It is a wrong output acted on by a clinician or patient: a falsely reassuring score that delays follow-up, or a falsely alarming one that drives unnecessary testing and distress. When you read the special controls, ask which risk each one is answering. If you cannot connect a control to a risk, you will struggle to defend your evidence for it in a submission.

What Is the Device, and What Is Not Covered?

The exact definition belongs to the identification paragraph, so quote it in your intended use work rather than relying on a shorthand. What I can offer is the way to test fit. Set your claim next to each element of the paragraph (input, function, output, user, population) and mark every mismatch. The adjacent categories below are the ones that most often cause trouble, and each gets decided by the claim, not by the technology:

Your software claims to... Likely regulatory question
Estimate future progression in people with MCI Compare directly to the identification paragraph of this order
Identify or diagnose cognitive impairment now A different claim; look up the existing classification for the diagnostic function before assuming this order applies
Measure current cognitive performance over time Check existing neurological device regulations in 21 CFR Part 882
Recommend or select a treatment A different risk profile; expect it to fall outside this device type
Offer brain training with no disease claim May be outside device regulation, depending on claims; see FDA's general wellness policy guidance

If your labeling or marketing says more than the identification paragraph allows, you may have a device that does not match this type and needs its own De Novo request.

How Do You Use the Special Controls?

I am deliberately not listing the controls here. They are in the order, and what I might guess from other software classifications would not be a substitute. Here is how to work with them once you have them in hand.

  1. Create one row per control. Columns: control text (verbatim), the design output or test that satisfies it, evidence location, gap, owner.
  2. Split each control into testable parts. A single control that mentions population, reference standard and follow-up period is three evidence questions.
  3. Tie each row to a risk file entry. Under ISO 14971:2019 clause 7 (risk control), a special control is a risk control measure candidate, and the matrix should show which hazard it covers. Our risk management guide covers how the two documents connect.
  4. Plan the software documentation level. FDA's guidance "Content of Premarket Submissions for Device Software Functions" (June 14, 2023) sets documentation expectations by documentation level, and your submission needs to be consistent with the level you select.
  5. Hold open questions for a Pre-Submission. Where a control is ambiguous for your validation data, FDA's Q-Submission program (guidance "Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program") is the way to ask before you spend a year on a study.

How Does This Change Your 510(k) Strategy?

If the order does not exempt the device type, the 510(k) route looks like this.

Predicate. The granted device named in the order is the obvious candidate, along with any device later cleared under the same product code. Pull the decision summary for each. It shows what testing the predicate's sponsor presented against the same controls.

Substantial equivalence. The statutory standard is in section 513(i) of the FD&C Act, and the determination is described at 21 CFR 807.100. For prognostic algorithms, technological differences such as model type, inputs or output scale are where a reviewer will probe. Write up each difference and explain why it does not raise different questions of safety and effectiveness.

Special controls as acceptance criteria. Because they are codified, you cannot negotiate them away the way you can negotiate a sponsor-proposed test plan. Your design controls should treat them as design inputs under ISO 13485:2016 clause 7.3.3. The design controls page walks through that traceability.

If the device is exempt. An exempt device still has to meet the special controls and the general controls, including Part 820. Exemption removes the submission, not the obligation. Check the exemption language for limitations, because FDA often restricts exemptions to devices that stay within the described type.

Which Quality System Requirements Apply?

FDA's Quality Management System Regulation (final rule published February 2, 2024, 89 FR 7496) took effect February 2, 2026, and amended 21 CFR Part 820 to incorporate ISO 13485:2016 by reference. For a software-only prognostic device the clauses that matter most:

  • Clause 7.3 (design and development): inputs should include the intended population, performance targets and data requirements.
  • Clause 4.1.6 (validation of software used in the QMS) and clause 7.5.6 (validation of processes for production and service provision): these cover software that supports your quality system and processes whose output cannot be fully verified by later inspection.
  • Clause 7.4 (purchasing): third-party datasets, cloud hosting and pretrained components fall under supplier controls. See our guide to ISO 13485 software validation and IEC 62304.
  • Clause 7.3.9 (control of design and development changes): model retraining is a design change and needs the same discipline as a code change.

For cyber devices, section 524B of the FD&C Act requires cybersecurity information in premarket submissions, and FDA's premarket cybersecurity guidance (first issued September 2023) describes the content. IEC 62304 governs the software life cycle process.

What About Algorithm Updates After Clearance?

Models get retrained and data sources shift. Whether a change needs a new 510(k) is assessed under FDA's guidance "Deciding When to Submit a 510(k) for a Software Change to an Existing Device" (October 2017). Section 515C of the FD&C Act, added by the Food and Drug Omnibus Reform Act of 2022, lets sponsors include a predetermined change control plan in a submission, and FDA's final guidance "Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions" (December 2024) describes what the plan should contain. If you expect to retrain, decide before submission whether to propose one, because it is easier to agree on when the device is first reviewed.

What If You Already Market Similar Software?

Software that makes a prognostic claim for MCI and has neither clearance nor a De Novo grant is a device marketed without authorization, regardless of how it was positioned earlier. The Federal Register notice does not promise a grace period, and I would not assume one. If you are marketing under a clearance for a different intended use, the question is whether your current claims are covered by it; a labeling or claim change that affects intended use is one of the triggers in the 2017 software change guidance. If you are marketing under enforcement discretion or the general wellness policy, compare the claims you make today against the identification paragraph and ask regulatory counsel where the line sits.

What Should You Do in the Next 90 Days?

  1. Weeks 1-2: Read the order and complete the extraction table above, including the effective date and exemption status.
  2. Weeks 2-4: Map every claim in your intended use, labeling and promotional material against the identification paragraph. Treat any mismatch as a regulatory decision.
  3. Weeks 3-6: Build the control-to-evidence matrix and link it to your risk file.
  4. Weeks 4-8: Audit validation data (population, reference standard, follow-up length, subgroup coverage) against the controls.
  5. Weeks 6-10: Check your QMS against ISO 13485:2016 and Part 820, concentrating on design controls, software validation and supplier controls.
  6. Weeks 8-12: Decide on a Pre-Submission and on whether to propose a PCCP.

For help with the submission side, see our 510(k) overview. To talk through mapping special controls to your design history, you can reach Certify Consulting at certify.consulting.

I will say it plainly: the companies that struggle with a new classification are usually the ones who built the evidence first and read the controls second.

Jared Clark, JD, MBA, PMP, CMQ-OE, CQA, CPGP, Principal Consultant at Certify Consulting

Last updated: 2026-11-11

Frequently Asked Questions

What class is prognostic assessment software of mild cognitive impairment?

FDA classified it into class II with special controls in a Federal Register order published November 5, 2026 (document 2026-22590). FDA determined that class II provides reasonable assurance of safety and effectiveness for this device type.

Does this device type need a 510(k)?

A class II device needs a 510(k) under section 510(k) of the FD&C Act and 21 CFR Part 807 Subpart E unless FDA exempts it. The order states the exemption status, so confirm it in the order text before planning.

What is the difference between general controls and special controls?

General controls apply to nearly all devices and include registration and listing, labeling, MDR, corrections and removals, and Part 820. Special controls are device-specific requirements codified in the classification regulation, and they are what this order adds.

Do I need a predetermined change control plan for an MCI prognostic algorithm?

It is optional. Section 515C of the FD&C Act and FDA's December 2024 final PCCP guidance for AI-enabled device software functions allow a sponsor to propose one in the submission. It is worth considering if you expect to retrain the model.

How does the QMSR affect this device?

The QMSR took effect February 2, 2026 and incorporates ISO 13485:2016 into 21 CFR Part 820 by reference. Design and development (clause 7.3), software validation (clauses 4.1.6 and 7.5.6) and purchasing (clause 7.4) are the clauses with the most weight for software-only devices.

J

Jared Clark

Principal Consultant, Certify Consulting

Jared Clark is the founder of Certify Consulting, helping organizations achieve and maintain compliance with international standards and regulatory requirements.