MTL-130: Is My Health Software a Medical Device?

What you will learn

By the end of this topic, you should be able to frame a health-software function, identify the claims and clinical decisions that matter, distinguish an initial device determination from classification, recognise important differences between the US, EU and Great Britain, and prepare a documented rationale for specialist review.

The short answer: it depends on purpose and function

Health software is not automatically a medical device. The decisive question is normally what the manufacturer intends the software to do, for whom, using which information and with what effect on diagnosis, monitoring, prediction, prognosis, treatment, prevention or another legally defined medical purpose.

The same technology can produce different regulatory outcomes. A camera may scan a barcode, document a wound or analyse an image for a diagnostic recommendation. A language model may draft administrative text, summarise records or generate patient-specific clinical advice. The technology label does not settle the question.

Begin with the claim, not the code

Do not ask whether an app, algorithm or AI model is inherently a medical device. Ask what each software function is intended to do and how its output is used.

Use the right decision sequence

1. ProductDefine users, population, setting and commercial claims

2. FunctionsSeparate the distinct purposes performed by the software

3. Medical purposeTest each function against the applicable legal definition

4. PolicyConsider exclusions, non-device functions and enforcement approach

5. ClassificationApply the jurisdiction-specific rules only after qualification

6. PathwayDetermine evidence, quality-system and market-access obligations

Qualification asks whether a function is a medical device. Classification asks what class applies. Market pathway asks what must happen before and after placing it on the market. Record these as related but separate decisions.

Assess each distinct software function

A product may combine regulated and non-regulated functions. FDA explicitly frames a function as a distinct purpose of the product; European guidance similarly permits modular analysis while requiring credible boundaries and control of interactions.

List what the software receives, stores, transforms, analyses, displays, recommends or controls.
Identify the intended user of each output: patient, caregiver, health professional, technician or administrator.
State what decision or action follows from the output.
Describe whether the output is informational, persuasive, diagnostic, therapeutic or controlling.
Map dependencies on sensors, medical devices, records, cloud services, models and human review.
Identify which functions can affect the safety or performance of another medical device.

Do not use an artificially narrow boundary to exclude a function or dependency that is necessary for the claimed medical performance.

Make the intended purpose specific enough to assess

A vague statement such as “supports better health” is not enough. A useful intended-purpose statement describes the target condition or health process, intended users and population, use environment, inputs, outputs and the clinical role of those outputs.

Claims are not limited to the formal intended-purpose statement. Websites, demonstrations, app-store descriptions, sales material, user instructions and the behaviour of the product can all shape how the function is understood. Product, clinical, regulatory and marketing teams should therefore work from one controlled position.

Use MTL-102 — Intended Purpose, Users and Use Environments to establish that foundation.

Many health-related functions are not device functions

Depending on the exact claims and jurisdiction, functions may fall outside medical-device regulation when they only support administration, communication, storage, general education or healthy lifestyles and do not perform a specific medical purpose.

Administration

Scheduling, billing, staff allocation and general workflow without a patient-specific medical function.

Reference and education

Static information or faithful presentation of approved instructions without analysis or personalised recommendation.

Storage and transfer

Electronic storage, communication, format conversion or display that does not analyse or alter the medical meaning.

General wellness

Lifestyle encouragement unrelated to diagnosis, treatment or a specific disease or condition.

Professional tools

Certain tools that allow a professional independently to review the basis for a recommendation may receive different treatment in the US.

Medical functions

Analysis, prediction, recommendation or control serving a patient-specific medical purpose is more likely to be regulated.

These are starting points, not universal exemptions. Small changes in wording, personalisation, urgency, automation or reliance can change the conclusion.

United States: separate device status from FDA oversight policy

For the US, assess whether each software function meets the device definition in section 201(h) of the Federal Food, Drug, and Cosmetic Act and whether a statutory exclusion in section 520(o) applies. FDA's Digital Health Policy Navigator then helps identify relevant policy for administrative functions, healthy-lifestyle functions, electronic patient records, data transfer or display, clinical decision support and other device software functions.

The initial outcome may be: likely not a device; a device function for which FDA intends to exercise enforcement discretion; or a device function that is the focus of FDA oversight. Enforcement discretion is not the same as a legal conclusion that the function is not a device.

Clinical decision support requires particular care. Consider the intended user, whether the output supports or directs a decision, the seriousness of the situation and whether the health professional can independently review the basis of the recommendation. Patient- and caregiver-facing functions do not use the same non-device CDS route.

MTL-302 — US FDA Medical-device Regulations provides the wider framework.

European Union: qualify the function before applying classification rules

Under the EU MDR or IVDR, begin with the manufacturer's intended purpose and the applicable legal definition. Software may qualify as medical device software when it performs a medical purpose in its own right. An action on data beyond simple storage, communication, lossless compression or simple search is an important part of the analysis, but the action must still serve the relevant medical purpose.

Define whether the software is independent, drives or influences hardware, is an accessory, or contains separable medical and non-medical modules. If it qualifies under the MDR, consider all applicable Annex VIII rules; Rule 11 is central for many information and monitoring functions. IVD software follows the IVDR definitions and classification rules.

Continue with MTL-323 — MDCG 2019-11 Software Qualification and Classification for the detailed EU analysis.

Great Britain: document a separate UK conclusion

Software placed on the Great Britain market must be assessed under the medical-device legislation that applies there and current MHRA guidance. The familiar questions remain important: intended purpose, action on data, clinical role, software boundary, relationship to hardware and applicable classification rules.

Do not copy an EU conclusion into a UK file without checking the current UK legal basis, classification and market-access arrangements. Northern Ireland has a different regulatory position from Great Britain and should be assessed separately.

The MHRA's stand-alone software guidance includes decision support for apps, symptom checkers, clinical calculators and software that drives or influences a device.

AI does not decide whether the product is a medical device

Using machine learning, a large language model or another AI technique does not by itself make software a medical device—and calling a product an assistant or copilot does not keep it outside regulation. Apply the same intended-purpose and function analysis.

AI can, however, make the facts more difficult. Outputs may be probabilistic, personalised or difficult to explain; performance may depend on changing data and context; and the product may generate outputs that extend beyond the claims originally assessed. Record the model's role, input constraints, output presentation, human oversight and prohibited uses when defining the function.

This regulatory-status decision is the entrance to the MTL-131 — AI and Machine-learning Foundations for Medical Devices and the wider MedTechLearning AI pathway. It is not a substitute for data governance, bias assessment, risk management, verification, clinical evidence, change control or post-market monitoring.

Worked triage examples

Step-by-step injection companion

An app that faithfully presents approved instructions and records completion may be non-device educational or information software. The conclusion may change if it interprets patient data, determines dose or timing, detects an error, controls the injector or gives patient-specific therapeutic advice.

General wellbeing tracker

A tracker encouraging sleep, exercise or healthy habits without reference to a specific disease may fall outside the device definition. Claims to detect deterioration, predict a condition or guide treatment move it towards a medical function.

Clinician decision support

A transparent calculator that lets a professional independently review its inputs, method and basis may receive different treatment from a function that provides an opaque, time-critical directive. Analyse the precise jurisdiction and policy criteria.

AI image classifier

Software that analyses a patient image to identify or prioritise suspected pathology has a clear diagnostic or clinical decision-support role and is likely to be a medical device, subject to jurisdiction-specific classification.

A conditional conclusion is often the correct first answer

State which product claims and behaviours support the conclusion, and identify the changes that would cause reassessment.

If it is a device, the work has only started

Device status does not tell you the regulatory class or market pathway. The next assessment should address the applicable jurisdiction, classification rule, product code or predicate strategy where relevant, conformity-assessment route, quality-management-system scope, technical documentation and required evidence.

Confirm the manufacturer and each market to be served.
Freeze the intended purpose and regulated software boundary used for classification.
Identify the applicable device or IVD framework.
Apply every potentially relevant classification rule and document exclusions.
Define the premarket submission, conformity assessment, registration and listing route.
Plan software lifecycle, risk, usability, cybersecurity, privacy and clinical or performance evidence.
Establish post-market, vigilance, support and change-control responsibilities.

Create a reproducible regulatory-status record

A short, approved decision record is more valuable than an undocumented conversation. It should allow a reviewer to reproduce the conclusion from the controlled product information available at the time.

Product and claims

Name, version, manufacturer, markets, intended users, population, environment and controlled intended-purpose sources.

Typical evidence: Product description, claims matrix, labelling and promotional review.

Function analysis

Inputs, processing, outputs, intended decisions, users, dependencies and modular boundaries.

Typical evidence: Function inventory, data-flow diagram, architecture and use scenarios.

Jurisdictional rationale

Legal definition, exclusions, policy position, classification rule and pathway for each intended market.

Typical evidence: Cited decision record, reviewer comments and regulatory approval.

Assumptions and triggers

Unresolved facts, limitations, prohibited claims and changes that require reassessment.

Typical evidence: Action log, escalation record and change-screening criteria.

Reassess status when claims or behaviour change

Regulatory status can change without a complete product rewrite. A new patient population, output, integration, model, data source, marketing claim or user group can alter the intended purpose or the applicable policy.

Screen new and revised claims before publication.
Review changes that add personalisation, prediction, recommendation or automation.
Reassess when a professional-facing function becomes patient-facing.
Evaluate new interfaces that drive or influence a hardware device.
Review real-world use that differs from the documented intended use.
Link the decision record to MTL-129 — Configuration and Change Management.

Common misconceptions

“It only provides information.”

Information used for diagnosis or treatment can itself be the medical output.

“A clinician makes the final decision.”

Human involvement does not automatically remove device status; the function and applicable criteria still matter.

“It is just a wellness app.”

The actual claims and patient-specific functions matter more than the product category chosen by marketing.

“It runs in the cloud, so it is not a device.”

Deployment location does not remove a medical purpose.

“Enforcement discretion means non-device.”

In the US, a device function may remain a device even where FDA does not presently intend to enforce particular requirements.

“The EU answer applies everywhere.”

Definitions and policy routes differ. Prepare a jurisdiction-specific conclusion.

Health-software regulatory triage checklist

Identify the manufacturer and intended markets.
Write a specific intended-purpose statement.
Separate every distinct software function.
Describe each function's inputs, processing, outputs and intended users.
State the patient-specific decision or action influenced by each output.
Identify administrative, educational, storage, communication and wellness functions.
Test each remaining function against the applicable legal device definition.
Consider jurisdiction-specific exclusions, guidance and enforcement policy.
Define the regulated boundary and relationship to hardware or other devices.
Apply classification rules only after qualification.
Document the rationale, assumptions, reviewers and cited sources.
Define change triggers and escalate uncertainty before claims or release.

IN DEPTH

Turn a product description into a defensible decision

Follow the output to the decision

Start with a verb rather than a technology label. Does the function store, retrieve, calculate, prioritise, recommend or control? Then describe the action its user is expected to take. A dashboard that displays a recorded value and a dashboard that interprets that value to recommend treatment may look nearly identical, yet the second introduces a different clinical role. Write the function description before discussing the market route. Capture the input, processing, output, intended user, population, setting and foreseeable consequence of an incorrect result. This makes assumptions visible to clinical, product and regulatory reviewers.

Examine the complete claim

An intended-purpose statement is evidence of intent, but it should agree with the interface, instructions, sales material and actual designed workflow. A disclaimer saying ‘for information only’ does not resolve a product whose principal feature recommends patient-specific treatment. Equally, the presence of health information alone does not settle qualification. Review screenshots and example outputs beside the claims register. If the commercial team describes diagnosis while engineering describes record keeping, resolve that discrepancy before treating the regulatory assessment as complete.

Keep market conclusions separate

Use one factual description of the function and a separate rationale for each jurisdiction. Record the legal definition considered, any exclusion or policy relied upon, the facts that make it applicable, remaining uncertainty and the reviewer. Device qualification, device classification and the submission or conformity-assessment route answer different questions. Do not copy an EU class into a US assessment or assume that a US non-device conclusion settles Great Britain. Where evidence is missing, record a provisional conclusion and an action to resolve it rather than forcing a confident answer.

WORKED DECISION

A clinic assistant gains a new feature

Teaching scenario

A fictional clinic application books appointments, displays uploaded blood-pressure readings and drafts visit summaries. The team proposes an AI feature that analyses those readings and tells a patient whether to increase a prescribed dose. Marketing wants to launch all four functions under the existing ‘administrative assistant’ description.

1. Separate the functions

Create four entries in the function inventory. For each, identify whether it merely transports or presents information, transforms clinically relevant information, or proposes a treatment action. The dosing recommendation requires its own assessment. Also examine whether errors in the summarisation or display functions could affect that recommendation; a modular boundary must include safety-relevant dependencies.

2. Challenge the proposed boundary

The treatment recommendation is patient-specific and intended to influence medication use. Calling the overall product administrative does not explain this function. The team pauses its release and asks regulatory and clinical reviewers to assess its medical purpose and applicable market requirements. This is an initial escalation decision, not a universal classification for every possible implementation.

3. Record what would change the conclusion

A later design may remove dose recommendations and restrict the function to transferring clinician-authored instructions without interpretation. That is a changed function requiring reassessment, not a wording adjustment. Conversely, adding urgency ranking to a summary may create another clinical decision role. Preserve the before-and-after outputs and update the claims register.

EVIDENCE IN PRACTICE

Example function-assessment record

This abbreviated teaching example shows the reasoning to capture. Adapt it to the product, risk and quality-system procedures, and link to the underlying evidence.

Function and configuration: F-04, proposed dosing feature; input source, output examples, model/service version and dependencies linked.
Decision and rationale: Release held pending market-specific qualification, classification and pathway review; patient-specific treatment recommendation identified.
Evidence and ownership: Claims register, screenshots and clinical workflow reviewed by product, clinical and regulatory leads; open questions have named owners.
Reassessment trigger: Change to recommendation, intended user, population, automation, jurisdiction or clinical reliance.

PUT IT INTO PRACTICE

Make the decision yourself

A developer says that mandatory clinician approval makes every AI recommendation non-device software. Draft a response and identify three facts you need before reaching a conclusion.

Write down your decision, the missing evidence and the next action before opening the answer.

Read the model answer

Clinician review is relevant to the workflow and may matter to a particular jurisdiction’s criteria, but it is not a general exemption. Establish the intended clinical purpose, the information processed and recommendation produced, and how the clinician can understand and independently assess the basis within the real workflow. Then apply the actual criteria for each target market. A strong answer distinguishes a human-factors control from a qualification rule and does not infer classification from the presence of an approval button.

Apply this to your project

Use the example record above to document one real decision. Identify the assumption most likely to change the conclusion, the evidence needed to test it and the person responsible for the next step.

Read alongside this lesson: FDA: Clinical Decision Support Software — examine the criteria, not simply whether a clinician is involved

Authoritative starting points

This module supports initial learning and triage. It is not a formal regulatory determination. Confirm current legislation, guidance, product classification and market-access requirements for each jurisdiction, and seek competent regulatory advice where the conclusion is uncertain or commercially significant.

KEY TAKEAWAY

Purpose determines status; jurisdiction determines the route

Define each function precisely, connect its output to the intended clinical use, apply the rules for every target market, and preserve the reasoning as controlled evidence.