Fitness App Medical Device Rules: The Claim Decides, Not the Sensor

Two apps read the same optical heart rate sensor at the same sample rate through nearly the same filtering code. One is a wellness product with no regulatory obligations at all. The other is a Class IIb medical device in the European Union, which means a notified body, a clinical evaluation, and a launch date roughly a year further out.

The difference is not the hardware. It is not the algorithm either. Fitness app medical device rules turn on intended purpose, and intended purpose is established by what you say the product is for. Your marketing site, your app store listing, your onboarding copy, the label on the button.

Which means the most consequential regulatory decision in a wellness product is usually made by someone in growth, on a Tuesday, trying to improve conversion.

The sensor does not decide, the claim does

Both regimes agree on this starting point even though they diverge afterwards.

The EU Medical Device Regulation qualifies software by the manufacturer's intended purpose, regardless of what hardware it runs on. The Medical Device Coordination Group restated this when it revised MDCG 2019-11 in June 2025, and the MDR text says plainly that fitness and wellness applications are not medical device software. That is a genuine safe harbour. It is also narrower than most product teams assume, because it protects the category, not the sensor.

The FDA arrives at the same place from a different direction. Its general wellness policy is one of enforcement discretion: a product intended to support or promote a healthy lifestyle, rather than to diagnose, treat, cure, mitigate or prevent a specific disease, and presenting minimal safety risk, is left alone.

Read those two definitions again and notice what is doing the work. Support a healthy lifestyle, yes. Name a disease, no. The moment a screen says the word "detect" next to a condition, the sensor has not changed and the classification has.

What general wellness permits after 6 January 2026

The FDA updated its general wellness guidance on 6 January 2026, and the update matters because it moved in the permissive direction on exactly the features wellness apps have been shipping.

The updated position allows non invasive, sensor based wearables to sit inside general wellness even where they estimate physiological values, including heart rate and glucose, provided two conditions hold. The product avoids disease, diagnostic and clinical management claims. And it presents minimal safety risk.

That second condition carries more weight than teams expect. Minimal risk is assessed against what a user might reasonably do with the output. A number on a screen labelled as an estimate for general awareness is low risk. The same number with a threshold, a colour and a push notification is an invitation to act, and acting is where harm lives.

So the practical reading is this. Estimating is usually fine. Alerting is where you should stop and check. Advising is almost always over the line.

Rule 11, and why the EU classifies by consequence

The European test is structurally different and it catches teams who have only read the American one.

Once software qualifies as a medical device in the EU, Annex VIII Rule 11 decides its class, and it decides by asking what happens if someone acts on the output. Software providing information used for diagnostic or therapeutic purposes falls into Class III where a wrong decision could cause death or an irreversible deterioration in health, and Class IIb where a wrong decision could cause other serious adverse effects. Lower consequence sits at IIa.

This is why the EU line lands in a different place from the US one. The FDA asks what you claim. The MDR asks what the consequence of the claim is. A feature can look modest and still classify high, because the classification is measuring the downside of trusting it.

An irregular rhythm notification is the standard worked example. Nothing about it feels dramatic in a product review. But the user's next action is either to seek care or, worse, to be reassured and not seek care, and both branches have serious clinical consequences. That is Rule 11 territory, and the fact that your app also counts steps does not partition the product.

Four features that cross the line, and the wording that pulls them back

Here is the part nobody publishes. These are real product decisions, and in each case the compliant and the regulated version are separated by a sentence.

Sleep. Regulated wording: "detects sleep apnoea". Wellness wording: "estimates time spent in light, deep and REM sleep". The first names a condition and implies diagnosis. The second describes an activity pattern. Same accelerometer, same model.

Heart rate. Regulated: "alerts you to atrial fibrillation". Wellness: "shows your resting heart rate trend over 30 days". The trend is information about lifestyle. The alert is a screening claim about a named arrhythmia.

Weight and body composition. Regulated: "helps manage obesity". Wellness: "tracks body composition change against a goal you set". Obesity is a diagnosed condition and management is a therapeutic claim. Goal tracking is not.

Recovery and readiness. Regulated: "tells you when it is safe to train after injury". Wellness: "scores recovery from heart rate variability, sleep and recent load". Safety advice after injury is clinical decision support. A composite score with the inputs shown is a fitness metric.

Two things follow from that list.

First, the pull back is cheap if you do it before launch and expensive afterwards, because the claim will already be in your app store listing, your paid ads, your press coverage and your support macros. We have watched a team spend three weeks removing one verb from 40 surfaces.

Second, and less obvious: if the regulated version is the product you actually want to build, build it deliberately. Choosing scope on purpose with a budget attached is a far better position than arriving in scope by accident because a growth experiment tested well.

What actually changes on the day you are in scope

Being a medical device brings a set of continuing obligations rather than a single approval event, and the engineering cost sits mostly in the continuing part.

Device registration. EUDAMED registration with a UDI became mandatory on 28 May 2026. That is a data obligation with a product identifier scheme behind it, and it needs to be maintained as versions ship.

A quality management system with teeth. Design controls, traceability from requirement to test, change control, and post market surveillance. In practice this reshapes how your team ships. A UI change that touches a clinical output is no longer a same day deploy.

Clinical evaluation. Evidence that the thing does what you claim, proportionate to the class.

The AI Act, if there is a model in the path. AI enabled devices now carry obligations under both the MDR and the EU AI Act at once. Two regimes, two sets of documentation, one product, and the overlap between them is still being worked out in practice.

None of that is a reason to avoid the category. Regulated products defend their market share far better than unregulated ones, which is precisely why the barrier exists. It is a reason to know which side you are on before you commit a roadmap.

The app store reviews this before any regulator does

Long before a regulator looks at your product, two reviewers will.

Apple and Google both run health specific policies, and both ask for the same thing in different words: if the app makes a health claim, show the evidence and show the regulatory status. Submissions get held for a written explanation, and the reviewer is reading your listing text, not your architecture diagram.

This has a useful consequence. App review is a free, fast, adversarial read of your claims, and it happens on a two day cycle rather than a two month one. Teams treat a health related rejection as a nuisance. It is closer to a warning shot, because the sentence that triggered it is usually the same sentence that would have qualified the product in the EU.

Two patterns account for most of the holds we see. A screenshot in the listing showing an alert next to a condition name, where the app itself never makes that claim, and marketing has run ahead of the product. And a feature description written for conversion, where "know if something is wrong with your heart" tested better than "see your heart rate trend" and nobody routed the change past anyone.

Add your app store metadata to the claims register. It is the surface most likely to drift and the one least likely to be reviewed.

Corporate wellness raises the bar without changing the law

If you sell to employers, a second pressure arrives from a direction that has nothing to do with regulators.

Corporate wellness deals come with procurement, and procurement asks for things by name. ISO/IEC 27001. SOC 2. A data processing agreement. An answer to where health fields live and who can query them. The employer is not asking about your device classification at all. They are asking whether an incident in your product becomes an incident in their HR function.

That changes two engineering decisions.

The eligibility feed becomes a health adjacent system. An employer or benefits administrator sends you a list of who is covered. Join that to activity and body composition data and you have built something that can answer a question no employer should be able to ask, which is how a named employee is doing. The fix is architectural: eligibility resolves to an internal member id and never travels alongside health fields in the same query path.

Reporting has to be aggregate by construction, not by convention. A dashboard that can filter to one person will eventually be filtered to one person. Set a floor, commonly 10 or more members per segment, and enforce it in the query layer rather than in the UI, because the UI is not what an exported CSV goes through.

Neither of those is a regulatory requirement. Both of them are the difference between passing an enterprise security review in three weeks and passing it in three months.

The rule you are already inside, whichever side of the line you sit

One thing does not depend on any of the above.

The FTC's Health Breach Notification Rule covers health records held by entities that are not HIPAA covered, and its 2024 amendments, effective 29 July 2024, explicitly brought direct to consumer wellness technology inside it. The definition of a breach includes an unauthorised disclosure even when it was voluntary. An analytics or advertising software development kit passing health fields out of your app is therefore a reportable event, not a vendor integration.

Most fitness apps we review have between four and nine third party SDKs in the mobile client, and almost none have an inventory of what each one transmits. That inventory is a day of work and it is the highest value day in this entire article, because it is the obligation that already applies to you today regardless of how carefully your copy is worded.

What this costs, with the hours shown

The rate is $40 to $100 per hour by role. Data classification and access model work sits near the ceiling, inventory and documentation nearer the floor, and mixed teams blend to around $65.

Staying out of scope, deliberately.

Module	Hours	What it covers
Intended purpose statement and claims review	20 to 40	Every surface audited, wording rewritten, a claims register that stays current
Health data classification and access model	60 to 120	Health fields held apart from the commercial record, own retention, own access
SDK and disclosure inventory	30 to 60	What every third party library transmits, and the removal of the ones that should not
Consent, retention and export	50 to 100	Lawful basis per field, retention justified, user export that works

Worked example: 30 plus 90 plus 45 plus 75 equals 240 hours. That is $9,600 at $40, $24,000 at $100, and about $15,600 at a $65 blend. The full span is 160 to 320 hours.

Choosing to be in scope. Add two modules.

Module	Hours
Clinical evaluation support pack	90 to 200
QMS hooks: traceability, change control, post market surveillance	80 to 180

Worked example: 240 plus 145 plus 130 equals 515 hours, which is $20,600 to $51,500 across the band and about $33,475 at the blend. The full span across all six modules is 330 to 700 hours.

Deliberately excluded: notified body fees, any conformity assessment charge, and legal counsel. The first two belong to an accredited body and the third belongs to a lawyer. None of them belong in an engineering estimate, and any supplier who folds them into one number is guessing.

A claims review that takes an afternoon

You do not need a regulatory programme to find out where you stand. You need three hours and a spreadsheet.

Hour one. Collect every claim. App store listing, website hero and features, onboarding screens, push notification copy, empty states, paid ad creative, and the support macros. Support macros matter more than people think, because an agent telling a user the app can spot a problem is a claim your company made.

Hour two. Mark every verb. Circle detect, diagnose, screen, monitor, treat, manage, prevent, and any named condition. Those words and those nouns are where qualification happens. Estimate, track, show, score and log are the other list.

Between hours two and three, sort the flagged claims into three piles. Rewrite, accept, or escalate. Rewrite is the default and covers most of them. Accept means the claim is the product and the budget follows. Escalate is the small pile where the wording is genuinely ambiguous, and that pile is what counsel should see, at perhaps four to six lines rather than an entire website.

That sorting step is what keeps the exercise to an afternoon. Teams that skip it send everything to a regulatory consultant and get back an invoice covering questions they could have answered themselves in twenty minutes.

Hour three. Decide, once, in writing. For each flagged claim: rewrite it, or accept scope and put a number against it. A claims register with a decision beside each line is the single artifact that makes every later regulatory conversation short.

Do that before the next roadmap review rather than after it. The whole exercise costs less than one sprint and it is the difference between choosing your regulatory position and inheriting it.