Anyone building in health runs into this question early, usually in the form of a feature that would be popular and would also change what the product legally is. It is worth understanding before the feature is built rather than after.
The distinction in plain terms
Broadly, software becomes a medical device when it is intended to diagnose, prevent, monitor, predict, or treat a condition in an individual. The operative words are intended and individual. Publishing general information about what a test measures is not that. Taking one person’s results and producing a conclusion about that person is.
Intent is judged by what the product does and how it is marketed, not by what the terms of service say. A disclaimer under a diagnosis does not convert it into information.
Where ordinary features cross the line
- A health score computed from someone’s results.
- A traffic light that labels an individual’s value as safe or dangerous against a threshold you chose.
- A triage prompt telling a specific person how urgently to seek care.
- Anything that names a likely condition, however hedged.
Each is a determination about an individual. Each is also exactly what users ask for, which is why this boundary needs deciding by design rather than by drift.
Why we built on the information side
Not because the regulated path is illegitimate — it exists for good reasons and serious products take it. Because it is a different company: clinical evidence, a quality system, notified bodies, post-market surveillance, and a release cadence measured in quarters.
We chose to be useful inside the information boundary and to be honest that it is a boundary. Which is why we say who to speak to and how soon, and never what you have.
This article explains how our technology works. It is health information, not medical advice.