Is your health product a medical device?

This is the single most consequential question in health software, and it is routinely asked after the build has started. By then the answer either costs nothing or costs a year.

This is not legal or regulatory advice. It is the shape of the question, so you know whether you need to ask someone qualified.

What tends to make software a device

Broadly, software is more likely to be regulated when it informs or drives a clinical decision rather than merely administering information.

• Diagnosing, screening or predicting a condition.
• Recommending or calculating a treatment or dose.
• Monitoring a physiological parameter and alerting on it.
• Interpreting an image, signal or test result.

And more likely to fall outside when it supports the running of care rather than the care itself: appointment booking, record storage and retrieval, billing, messaging, rostering, general wellness content.

The line is narrower than people expect

A symptom checker that lists possibilities is usually in scope. A calculator that simply performs arithmetic a clinician would do anyway may not be. A dashboard that displays values is often fine; the same dashboard that flags one as concerning may not be.

Intended purpose matters as much as function. What you claim the product does — in your marketing as much as your documentation — is part of how it is assessed.

What it changes if the answer is yes

• A classification, and a conformity route appropriate to it.
• A quality management system covering how you build, not just what you ship.
• Clinical evaluation, risk management and a documented safety case.
• Post-market surveillance — the obligation does not end at launch.

None of this is impossible. All of it takes time, and all of it is cheaper to design around than to retrofit onto a finished product.

What to do before you build

1. Write down, in one sentence, what the product is for and what it claims.
2. Take that sentence to someone qualified in your target markets — the answer can differ between them.
3. Get the determination in writing before scoping the build.
4. If it is a device, bring the regulatory requirements into the architecture conversation rather than the launch checklist.

The cheaper question first

Sometimes the answer is to narrow the claim. A product that presents information and leaves the judgement to a clinician may do the same commercial job as one that makes the judgement, at a fraction of the regulatory cost.

That is a product decision, not a compliance one, and it is worth making deliberately. More on how we approach this on our healthcare page.

Does a symptom checker count as a medical device?

Usually yes, in most major markets. Software that suggests possible conditions from user-entered symptoms is generally treated as informing a clinical decision, which brings it into scope. Software that only stores, transmits or displays information a clinician entered usually is not. The determination depends on your claims and your target market, so get it in writing before scoping the build.

Can we avoid regulation by changing our wording?

Sometimes, and legitimately. Intended purpose is part of how software is assessed, so a product that presents information and leaves judgement to a clinician may fall outside scope where one that makes a recommendation does not. That is a genuine product decision with real consequences for what the product does — not a labelling trick, and regulators treat it as the former.