eduKateSG · Why Science?
Classify decision-support software one function at a time
Use current FDA CDS resources through the four statutory criteria, medical images and signals, health care professional users, recommendations, independent review, time pressure, AI transparency and device pathways.
Clinical decision support software can organise patient facts, surface medical knowledge and help a health care professional think. The regulatory question depends on the exact function, not simply on whether the product uses software or artificial intelligence.
FDA’s January 2026 final guidance explains four criteria for certain CDS functions excluded from the device definition. All four matter, including whether the professional can independently review the basis for the recommendation.
Did you know? Showing an explanation is not always enough. If a decision is so time-critical that the user cannot examine the basis before acting, genuine independent review may be difficult.
This guide supports software classification and evidence literacy. It does not classify a specific product or replace clinical judgment.
Chapter index
Chapters 1–9: inputs, outputs, users and statutory criteria
- 1. Classification follows the software function
- 2. The January 2026 guidance is the current anchor
- 3. The statutory exclusion has four criteria
- 4. Medical images and signals create a boundary
- 5. The input should be medical information
- 6. The output should support an HCP
- 7. Independent review is essential
- 8. Time-critical decisions affect reviewability
- 9. The intended user matters
Chapters 10–17: reviewability, urgency, multiple functions and decisions
- 10. Specific outputs can change risk
- 11. Plain-language basis supports independence
- 12. Opaque AI can challenge criterion four
- 13. Non-device status is not a quality endorsement
- 14. Device CDS follows normal pathways
- 15. Multiple-function products need boundaries
- 16. FAQs clarify current examples
- 17. A strong CDS receipt records the reasoning
CHAPTER 1 OF 17 · Define the function
1. Classification follows the software function
Clinical decision support software becomes classifiable when input, output, user, time pressure and basis for the recommendation remain connected. A product can contain multiple functions, so each clinical decision support function should be analysed by what it actually does. This keeps a software label from replacing a function-by-function test.
Try this
Evidence question: Which official page, guidance or decision supports the point about classification follows the software function? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for classification follows the software function. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for classification follows the software function, its identifier or version context, and one limit that must remain visible.
CHAPTER 2 OF 17 · Define the function
2. The January 2026 guidance is the current anchor
FDA’s January 2026 guidance interprets the statutory criteria for certain CDS functions excluded from the device definition. FDA issued and re-issued final Clinical Decision Support Software guidance in January 2026 to explain its current interpretation. It also protects the clinician’s ability to independently review the basis.
Try this
Evidence question: Which official page, guidance or decision supports the point about the january 2026 guidance is the current anchor? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for the january 2026 guidance is the current anchor. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for the january 2026 guidance is the current anchor, its identifier or version context, and one limit that must remain visible.
A software function must meet all applicable non-device CDS criteria to fit that exclusion. A function must satisfy all criteria in section 520(o)(1)(E) to be excluded from the device definition under that provision. Examples and FAQs make the current interpretation traceable.
Try this
Evidence question: Which official page, guidance or decision supports the point about the statutory exclusion has four criteria? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for the statutory exclusion has four criteria. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for the statutory exclusion has four criteria, its identifier or version context, and one limit that must remain visible.
CHAPTER 4 OF 17 · Define the function
4. Medical images and signals create a boundary
The same product can contain device and non-device functions that require separate analysis. The first criterion excludes software intended to acquire, process or analyse medical images, signals from in vitro diagnostics or patterns or signals from signal-acquisition systems. Clinical responsibility and patient-specific context remain with qualified professionals.
Try this
Evidence question: Which official page, guidance or decision supports the point about medical images and signals create a boundary? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for medical images and signals create a boundary. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for medical images and signals create a boundary, its identifier or version context, and one limit that must remain visible.
Clinical decision support software becomes classifiable when input, output, user, time pressure and basis for the recommendation remain connected. The second criterion concerns displaying, analysing or printing medical information about a patient or other medical information. This keeps a software label from replacing a function-by-function test.
Try this
Evidence question: Which official page, guidance or decision supports the point about the input should be medical information? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for the input should be medical information. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for the input should be medical information, its identifier or version context, and one limit that must remain visible.
FDA’s January 2026 guidance interprets the statutory criteria for certain CDS functions excluded from the device definition. The third criterion concerns supporting or providing recommendations to a health care professional about prevention, diagnosis or treatment. It also protects the clinician’s ability to independently review the basis.
Try this
Evidence question: Which official page, guidance or decision supports the point about the output should support an hcp? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for the output should support an hcp. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for the output should support an hcp, its identifier or version context, and one limit that must remain visible.
A software function must meet all applicable non-device CDS criteria to fit that exclusion. The fourth criterion requires that the health care professional can independently review the basis for the recommendation and not rely primarily on it. Examples and FAQs make the current interpretation traceable.
Try this
Evidence question: Which official page, guidance or decision supports the point about independent review is essential? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for independent review is essential. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for independent review is essential, its identifier or version context, and one limit that must remain visible.
CHAPTER 8 OF 17 · Apply the four criteria
8. Time-critical decisions affect reviewability
The same product can contain device and non-device functions that require separate analysis. If the user lacks time to understand the basis before acting, independent review may not be realistic even when explanatory material exists. Clinical responsibility and patient-specific context remain with qualified professionals.
Try this
Evidence question: Which official page, guidance or decision supports the point about time-critical decisions affect reviewability? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for time-critical decisions affect reviewability. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for time-critical decisions affect reviewability, its identifier or version context, and one limit that must remain visible.
Clinical decision support software becomes classifiable when input, output, user, time pressure and basis for the recommendation remain connected. A patient-facing output is not analysed as HCP decision support merely because a clinician could also see it. This keeps a software label from replacing a function-by-function test.
Try this
Evidence question: Which official page, guidance or decision supports the point about the intended user matters? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for the intended user matters. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for the intended user matters, its identifier or version context, and one limit that must remain visible.
FDA’s January 2026 guidance interprets the statutory criteria for certain CDS functions excluded from the device definition. A ranked differential, treatment directive, risk score or alert can carry different reliance and transparency concerns. It also protects the clinician’s ability to independently review the basis.
Try this
Evidence question: Which official page, guidance or decision supports the point about specific outputs can change risk? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for specific outputs can change risk. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for specific outputs can change risk, its identifier or version context, and one limit that must remain visible.
CHAPTER 11 OF 17 · Test independent review
11. Plain-language basis supports independence
A software function must meet all applicable non-device CDS criteria to fit that exclusion. Inputs, logic, data sources, validation, limitations and known performance should be understandable enough for the intended professional user. Examples and FAQs make the current interpretation traceable.
Try this
Evidence question: Which official page, guidance or decision supports the point about plain-language basis supports independence? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for plain-language basis supports independence. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for plain-language basis supports independence, its identifier or version context, and one limit that must remain visible.
CHAPTER 12 OF 17 · Test independent review
12. Opaque AI can challenge criterion four
The same product can contain device and non-device functions that require separate analysis. Complex models are not automatically devices, but an unexplained output can make independent review of the basis difficult. Clinical responsibility and patient-specific context remain with qualified professionals.
Try this
Evidence question: Which official page, guidance or decision supports the point about opaque ai can challenge criterion four? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for opaque ai can challenge criterion four. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for opaque ai can challenge criterion four, its identifier or version context, and one limit that must remain visible.
CHAPTER 13 OF 17 · Follow the pathway
13. Non-device status is not a quality endorsement
Clinical decision support software becomes classifiable when input, output, user, time pressure and basis for the recommendation remain connected. A function excluded from the device definition under the CDS provision has not thereby received FDA clearance or approval. This keeps a software label from replacing a function-by-function test.
Try this
Evidence question: Which official page, guidance or decision supports the point about non-device status is not a quality endorsement? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for non-device status is not a quality endorsement. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for non-device status is not a quality endorsement, its identifier or version context, and one limit that must remain visible.
FDA’s January 2026 guidance interprets the statutory criteria for certain CDS functions excluded from the device definition. A CDS function meeting the device definition may require classification and a 510(k), De Novo or PMA pathway depending on risk and controls. It also protects the clinician’s ability to independently review the basis.
Try this
Evidence question: Which official page, guidance or decision supports the point about device cds follows normal pathways? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for device cds follows normal pathways. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. If a field is missing, write “not shown” and follow the official documentation rather than inventing a value.
Evidence checkpoint
Record the evidence object for device cds follows normal pathways, its identifier or version context, and one limit that must remain visible.
A software function must meet all applicable non-device CDS criteria to fit that exclusion. Device and non-device functions can coexist, and interactions between them may matter to the safety and effectiveness of the device function. Examples and FAQs make the current interpretation traceable.
Try this
Evidence question: Which official page, guidance or decision supports the point about multiple-function products need boundaries? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for multiple-function products need boundaries. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Before comparing two records, check that their object types, methods, versions and units really align.
Evidence checkpoint
Record the evidence object for multiple-function products need boundaries, its identifier or version context, and one limit that must remain visible.
The same product can contain device and non-device functions that require separate analysis. FDA’s 2026 FAQ and town-hall materials help apply the guidance, but examples should not replace analysis of the actual function. Clinical responsibility and patient-specific context remain with qualified professionals.
Try this
Evidence question: Which official page, guidance or decision supports the point about faqs clarify current examples? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for faqs clarify current examples. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Finish by naming one supported statement and one stronger statement that still needs another evidence layer.
Evidence checkpoint
Record the evidence object for faqs clarify current examples, its identifier or version context, and one limit that must remain visible.
Clinical decision support software becomes classifiable when input, output, user, time pressure and basis for the recommendation remain connected. Save the software version, intended user, inputs, output, urgency, recommendation basis, independent-review materials, four-criterion analysis and regulatory record. This keeps a software label from replacing a function-by-function test.
Try this
Evidence question: Which official page, guidance or decision supports the point about a strong cds receipt records the reasoning? Answer in three parts: identify the visible field or file, explain how it bears on the question, and state the boundary of that evidence. Preserve the database’s own object names and accession rather than flattening everything into the word ‘data’.
Try this: Save the identifier, date, version and one limit for a strong cds receipt records the reasoning. Turn the result into a compact claim-evidence-reasoning note, then ask a partner to retrace it. Keep the identifier, retrieval date and source page in the note so the route can be repeated.
Evidence checkpoint
Record the evidence object for a strong cds receipt records the reasoning, its identifier or version context, and one limit that must remain visible.
Contents · Previous chapter · Continue at the Science Learning Hub
A CDS classification is strongest when input, recommendation and independent review stay visible
The four-criterion route turns a vague software label into a testable analysis. Careful readers describe the function first, then examine each statutory element and any linked decision record.
Save the product and software version, exact function, intended user, patient and medical inputs, image or signal processing, output, urgency, basis shown, data sources, validation, limitations, four-criterion analysis, multiple-function interactions, classification and access date.
| Reading object | What it can support | Question to keep visible |
|---|---|---|
| Software function | Unit analysed under the CDS criteria | What exactly does it do? |
| Input | Medical information, image or signal | Which criterion is affected? |
| Recommendation | Support provided to the HCP | How specific and urgent? |
| Independent review | Ability to understand the basis | Can the user review it in time? |
Sources and next reading
Substantive resource claims in this article were checked against the primary pages below. A structured record is a route into evidence; it does not by itself prove a scientific conclusion. Recheck the live record, evidence labels and release context before using it in assessed work or research.
For a classroom enquiry, save a short research receipt containing the question, search terms, selected object, exact identifier, version, access date and the evidence boundary you observed. Add the file or page that supports each statement. This small routine turns browsing into accountable science learning and gives a teacher, classmate or future analyst a route they can independently follow.
Before sharing the conclusion, ask another reader to retrace the route without verbal hints. If they reach a different version, file or interpretation, improve the receipt and narrow the claim. Reproducibility begins with this practical check. It teaches careful reading, supports fair collaboration and keeps uncertainty visible while evidence moves from an online service into notes, analysis and a final explanation.
A useful final review separates five questions. What object was found? Which organisation or repository maintains it? What exact evidence was inspected? Which statement does that evidence support? What remains uncertain? Answer each question in one sentence, then connect every answer to a visible field, file or source page. This review catches common mistakes: citing a collection when a file supplied the value, treating the newest release as the analysed release, confusing permission with scientific suitability, or turning a discovery count into a conclusion. It also gives students a calm way to improve work. A missing detail becomes a next research step instead of an invitation to guess. When the route is complete, the final explanation can stay simple because the identifiers, dates, versions, limitations and supporting evidence are already organised underneath it.
Primary sources
- FDA Clinical Decision Support Software Guidance — accessed 25 October 2026.
- FDA Clinical Decision Support FAQs — accessed 25 October 2026.
- FDA CDS Town Hall — accessed 25 October 2026.
- FDA Medical Device Software Guidance Navigator — accessed 25 October 2026.
- FDA Digital Health Guidance List — accessed 25 October 2026.