A poor night’s sleep is not usually a mystery, most people can feel it before an app scores it. But once a product starts interpreting that score, the message can shift from “your sleep was shorter than usual” to “you may have a sleep disorder”, and somewhere along the way the product will likely have crossed a regulatory line.
The real product question is not only if the sensor spotted something, but also what the product does with that information next. These are not only wording choices, but they are also product and risk choices that should be considered as regulatory choices. As personal health products move from passive tracking into prediction and AI coaching, the boundary between wellness product and medical device is becoming more complex and easier to cross by accident.
The line is not in the hardware itself, but in the claim that It’s making.
A heart-rate sensor, sleep tracker, skin-temperature sensor, glucose sensor or hormone test is not automatically a medical device. The same measurement can sit in very different product categories depending on what the product claims to do. A device that says “your resting heart rate was higher than usual today” is probably still having a wellness conversation. A device that says “your heart-rate pattern may indicate atrial fibrillation” has changed the conversation entirely.
Whilst the sensors in these devices may be identical, the risk profile is not, because the practical dividing line is shaped by intended use: what the product claims to do, and what it encourages the user to do next. Most people intuitively grasp the difference between a trend and a diagnosis, or between a friend’s casual lifestyle suggestion and a clinical recommendation, but that distinction gets much harder to see once it’s dressed up in a clinical-looking app interface.
This is where many products start to drift, not through some grand strategic decision to become a medical device, but one feature at a time. A dashboard simplifies into a score, a score gets contextualised into an insight, and an insight ends up read as a recommendation. Before long, the app isn’t just tracking data anymore, it’s describing the user’s health.
The hidden risk isn’t the launch decision, it’s the claim drift that follows
Many teams think carefully about regulation at launch, but far fewer think about how a product’s claims evolve after that point, and this is exactly where claim drift becomes a problem. It rarely arrives as one obvious moment. Instead, it creeps in through a change to marketing copy here, a shortened piece of UX wording there, an update to the AI model driving feedback, or a new coaching layer bolted on to make the experience feel smarter, until a feature that began as low-risk lifestyle feedback finds itself operating much closer to clinical interpretation without anyone having decided that it should.
Claim drift can show up in a number of different ways, including the below:
- Language drift happens when the product moves away from softer wellness language such as “track” or “improve” and towards medical terms such as “detect”, “diagnose”, “treat”, “risk” or “screening”.
- Interpretation drift happens when the product stops simply displaying measurements and starts explaining what those measurements might mean medically.
- Personalisation drift happens as recommendations become more specific to the user’s physiology, history or risk profile, which in turn raises the user’s expectation that the advice is accurate and reliable.
- Confidence drift happens when very exact scores, percentages and statements make inherently uncertain outputs appear far more precise than they really are.
There’s also a version of this drift that has nothing to do with the product team at all: users repurposing the product themselves. A device designed to nudge someone towards better sleep or more steps can end up being used for something the manufacturer never intended and never claimed. An example of this is when people use their fitness trackers to monitor core temperature and heart rate changes in the hope of spotting an early sign of pregnancy, well before a test would confirm it. The product hasn’t made any medical claim, and the underlying sensor data hasn’t changed, but the way the user is interpreting and acting on that data has drifted into clinical territory.
None of these shifts, whether driven by the product team or by users themselves, are inherently wrong, and in fact some may be exactly where the product needs to go.
What matters is that they happen deliberately, supported by the right evidence, risk controls and regulatory strategy, rather than being allowed to accumulate quietly until the product has drifted into medical-device territory. That kind of quiet drift can create significant legal or reputational exposure, and the risk often remains invisible to the very decision-makers who would ultimately bear responsibility for the legal and moral consequences.
Designing for the boundary
Nobody needs a dashboard that turns the human body into an airport control tower. The real opportunity is interpretation with restraint. That is, taking the right signals, applying the right evidence and presenting them in a way that helps users make better decisions without overstating certainty. Good personal health design should help users understand themselves without turning every fluctuation into a miniature drama. A stress score should not make a user more stressed about being stressed.
This is where UX, human factors, regulatory strategy and technical development need to work together. The wording needs to be carefully considered and consistent with strategy. For innovators, the blurred line between wellness and medical device is therefore not just a one-off compliance hurdle. Some products should remain clearly in wellness territory, and others should be developed as medical devices because the intended benefit justifies the burden.
The important thing is not to pretend the boundary is not there. A good wellness product tells people something useful about their lives and good medical product gives reliable medical data. The best digital health teams know which one they are building rather than the UX and the product roadmap deciding for them further down the line.
A practical regulatory framing
The broad principle is similar across major markets. A product is less likely to be treated as a medical device if it simply supports general wellbeing, and more likely to be treated as one if it claims to identify, predict, monitor or guide action around a medical condition.
- In the UK, the MHRA puts weight on the product’s “intended purpose”, what the software is meant to do, who it is for and what decisions it supports.
- In the EU, the line is also drawn around intended medical purposes, including diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease.
- In the US, the FDA takes a lighter-touch approach to low-risk products that promote a healthy lifestyle, but disease-related claims change the picture.
The useful lesson for product teams is simple: decide what the product is for before the product starts deciding for you. If your product is starting to interpret personal health data, personalise recommendations or influence health-related decisions, do not leave that boundary to emerge by accident. Define the intended use early, test what users will understand from the experience, and make sure the claims, UX, evidence and regulatory strategy are all pointing in the same direction.
Some products should stay clearly in wellness. Others should be developed as medical devices because the user benefit justifies the additional responsibility. The important thing is to make that choice deliberately. If you are building in this space and are unsure where your product sits, come and talk to us. We can help you understand the boundary, reduce the risk of claim drift, and design a product that is both useful and responsibly positioned.
About the Author
Alex Barker
Consultant
Alex is an electronics consultant with hands-on experience across a wide range of industries, from high-pressure subsea systems to medical diagnostics and production automation. He holds a Master’s degree in Electronic Engineering from the University of Warwick and has worked in both in-house R&D and consultancy roles, gaining a reputation for delivering practical, well-engineered solutions, fast.