Smartwatch with a heart rhythm reading and a health app on a phone, at home

Sectors · Digital applications and wearable devices

Health app and wearable companies on the way to a medical claim.

Mental health programmes, sleep tracking, heart rhythm features, glucose and cycle tracking and rehabilitation exercises start as wellness products. Once a product screens, diagnoses, monitors or treats a condition, it falls under the EU MDR, and in the US under the FDA device rules unless an FDA wellness or enforcement discretion policy applies. The medical functions in the firmware, the app and the cloud need an IEC 62304 file. We read your claims, write down which functions are medical, and build and document the medical part.

Book a 30 minute call Write to us

Products: App · wearable firmware · cloud
Standards: EU MDR · FDA · IEC 62304 · ISO 13485
First step: Free 30 minute call with engineering

The software path

The steps from a wellness product to a medical claim.

Intended purpose

The app store description and the feature list may already make the product a medical device.

ImprovementEach function is marked as wellness or medical in writing, so you know which claims need a medical file.

Design

App, firmware and cloud were built as one prototype, without written requirements or architecture.

ImprovementRequirements and architecture are written down for the medical part, so the file starts from the design.

Implementation

The firmware knowledge sits with one person.

ImprovementThe firmware is documented in the same lifecycle as the app, so more than one person can change it.

Verification

Tests are written shortly before the CE marking or the FDA submission.

ImprovementFirmware, app and cloud are tested together, including a dropped link, a flat battery and a phone update.

Release

App, firmware and backend each have their own release, so the documented version is not the one in the field.

ImprovementOne release record covers app, firmware and backend, with a compatibility matrix and a record of the versions in use in the field.

Field support

Complaints, connection faults and phone updates reach the team one by one, with no common record.

ImprovementComplaints go into your complaint handling, and the software faults among them into one IEC 62304 problem resolution process, so each one is assessed and answered.

Change

A new feature, for example a heart rhythm notification, can move the product from wellness to medical without anyone noticing.

ImprovementThe effect of a new feature on the regulatory status is checked before the feature is built.

The goal

A claim, a code base and a file that match.

For the company

A regulatory plan that an investor or partner can read
Wellness and medical functions kept apart in the code and in marketing
An IEC 62304 file that grows with the code

For the device at home

A wearable that stores readings while the phone is offline and warns the user before the battery runs out
Readings and alerts stored on the device, numbered and forwarded, with gaps detected in the app and the backend
Firmware updates that are signed and verified

For users

New medical features that reach them sooner, tested as medical functions
Fixes that reach the device quickly through a signed update
A product that claims only what it can do

Problems and solutions

What we hear, and what we do about it.

We do not know whether our claims make the product a medical device.

We read the app store description, the labelling and the feature list against Article 2(12) of the MDR and the MDCG 2019-11 guidance (from the EU Medical Device Coordination Group). We write down which functions are wellness and fitness and which are medical. Once the intended purpose (what the manufacturer states the software is for) is fixed, we build and document the medical part under IEC 62304.

IEC 62304 gap analysis

We want to add a heart rhythm notification, and the firmware has no IEC 62304 documentation yet.

We review the firmware first. Then we document and develop the sensor drivers, the Bluetooth communication, the power management and the update process under the same IEC 62304 lifecycle as the app and the cloud.

Embedded and firmware development

We want CE marking or FDA clearance, and the code was written as a prototype.

We review the app and backend code against IEC 62304 before the CE marking or the FDA submission. We reconstruct the requirements and the architecture that exist only in the code, and you get a written report of what is missing.

IEC 62304 gap analysis

The firmware came from a contractor who has left.

We take over the sensor drivers, the Bluetooth communication and the update process. We read the code and document it while the product stays on the market.

Legacy modernisation and takeover

Our questionnaire scores now feed a recommendation, and an AI feature is next.

We specify the limits, the escalation and the logging as requirements and test them like any other requirement. The AI feature gets a versioned model, its verification results and the information that tells users they are dealing with an AI system.

From AI model to medical device

We are afraid of a regulatory project that runs past the next funding round.

The first step is a review with a written report that you can show an investor. Each step after it is a separate contract with its own scope and result.

How we work

Domains

Where wellness and fitness end and the medical device begins.

Domain	Wellness and fitness function	Where it becomes a medical device
Mental health	Mood journal, meditation, general stress programmes	A screening score with a referral, a treatment programme for a diagnosed condition
Sleep	Sleep duration and sleep stages for general wellbeing	Detection of sleep apnoea, a therapy programme for insomnia
Heart and circulation	Heart rate during exercise	ECG rhythm analysis, an atrial fibrillation notification, blood pressure for diagnosis
Metabolic health	Food and activity logging	Glucose alerts for diabetes management, insulin dosing advice
Women's health	Cycle tracking for personal planning	Contraception or fertility claims, pregnancy monitoring
Movement and rehabilitation	Step counts and fitness programmes	Rehabilitation exercises after injury or surgery

Fit

When we are the right partner.

Call us when

You want to add a medical claim to a wellness and fitness product
You want the firmware of a wearable documented before a medical feature goes in
You plan CE marking or an FDA submission for code that was written as a prototype
You want a clear answer when an investor or partner asks where the product stands under the MDR

Talk to us

Tell us what your product claims today.

A medical claim, undocumented firmware, a submission plan or an AI feature. Write a few lines, or book a free 30 minute call with engineering.

Book a 30 minute technical call

FAQ

Frequently asked questions.

Is our app or wearable a medical device?

It depends on the intended purpose. A product for general wellbeing is not. A product that screens, diagnoses, monitors or treats a condition is, and the claims in your app store description and marketing count towards that purpose. We work from the MDCG 2019-11 guidance in the EU and the FDA general wellness guidance in the US.

Which class would it be?

Software that provides information for diagnostic or therapeutic decisions is class IIa under Rule 11 of the MDR. It is a higher class where a wrong decision can lead to serious deterioration of health.

Can we keep a wellness and fitness version and add a medical version?

Yes, if the two have separate intended purposes and separate labelling, and a clear boundary in the code and in the marketing keeps them apart.

Do you work on the wearable firmware as well as the app?

Yes. We develop and document the sensor drivers, the Bluetooth communication, the power management and the update process under the same IEC 62304 lifecycle as the app and the cloud.

What does a first project cost, and how fast can it start?

The first call is free. Each step after it is quoted individually and agreed in writing. We reply within one business day. A gap analysis (a review of what is missing against the standard) can start within two weeks of the signed order, and an engineering team within two to three weeks of signature.

Related services and sectors.

IEC 62304 gap analysis Embedded and firmware development AI model to medical device Medical device cybersecurity SaMD and digital health companies Longevity and preventive health companies