Is my health app a medical device?

Why is someone asking you this now?

Because the person asking carries an obligation of their own that depends on your answer. An investor cannot close a round over an unpriced regulatory liability. A hospital cannot add a product to a procurement list without knowing its class. A distributor placing your software on the European market takes on duties under Regulation (EU) 2017/745 that are keyed to what the product is. None of them can answer for you, and all of them read the same evidence: what your product says about itself.

That evidence is defined, and the definition is wider than most founders expect. Article 2(12) of the Regulation defines intended purpose as "the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation". Your landing page sits inside that list. So does your app store description, your onboarding copy and the deck a salesperson sent last week.

The second reason the question is live now is that the guidance underneath it moved. The Medical Device Coordination Group revised its software guidance, MDCG 2019-11, and the revision went up on the European Commission health site on 17 June 2025 carrying "October 2019 / June 2025 rev.1" on its cover. Any answer your team wrote before that date was reasoned against the superseded version. The guidance binds nobody by its own account, and it is still what the notified body reviewer and your customer's regulatory affairs lead have both read.

What is actually being decided, and who wrote it?

Whether one paragraph you wrote falls inside Article 2(1). The definition of a medical device opens with "any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes", and then lists four of them. The first is "diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease". The second is "diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability". The third is "investigation, replacement or modification of the anatomy or of a physiological or pathological process or state". The fourth is "providing information by means of in vitro examination of specimens derived from the human body", which routes a product to Regulation (EU) 2017/746 and its own parallel test.

Four words in that opening carry the test: intended by the manufacturer. The Regulation does not ask what your software computes. It asks what you have said it is for, and it accepts your own published words as the evidence of that.

Two products can share a codebase, a model, a data pipeline and a set of test results, and qualify differently. A feature that presents a week of heart rate readings and a feature that flags an irregular rhythm and suggests the user seeks care can run on the same signal processing. One of those descriptions puts a medical purpose in front of the qualification test. The other does not. Nothing in the repository distinguishes them. The difference lives on a marketing page, and the marketing page is inside Article 2(12).

Two further provisions decide how far the definition reaches. Article 2(4) ends with "Software shall also be deemed to be an active device", so once a product qualifies, the rules written for active devices are the ones that classify it, and software gets no category of its own. Article 2(2) covers the case where the software is not a device on its own account: an accessory is "an article which, whilst not being itself a medical device, is intended by its manufacturer to be used together with one or several particular medical device(s) to specifically enable the medical device(s) to be used in accordance with its/their intended purpose(s) or to specifically and directly assist the medical functionality of the medical device(s)". A companion dashboard for somebody else's pump can be pulled in through that limb while failing the Article 2(1) test on its own.

The term the industry uses is not in the Regulation at all. MDCG supplies it: "MDSW is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a 'medical device'". The guidance adds the accessory note beside it, that software driving or influencing the use of a hardware medical device may be qualified as an accessory for that device.

Which words in the definition do the work?

Six phrases do it, spread across the definitions in Chapter I and the implementing rules in Annex VIII.

Six phrases in EU MDR Article 2 and Annex VIII that decide whether software is a medical device and what its class depends on.

The words	Where they sit	What they ask
"intended by the manufacturer"	Article 2(1)	What you have claimed, in every published place
The four specific medical purposes	Article 2(1), four indents	Whether any claim names diagnosis, prevention, monitoring, prediction, prognosis, treatment, alleviation, compensation, investigation, replacement or modification
"promotional or sales materials or statements"	Article 2(12)	Which surfaces count as evidence of what you intend
The accessory limb	Article 2(2)	Whether you enable or directly assist the medical functionality of somebody else's device
"Software shall also be deemed to be an active device"	Article 2(4)	Whether the active device rules reach you once you have qualified
"Software, which drives a device or influences the use of a device"	Annex VIII implementing rule 3.3	Whether your class is pinned to hardware you do not manufacture

Six provisions of Regulation (EU) 2017/745 decide whether software is a medical device and what its class attaches to, and every one of them is applied to a claim the manufacturer published rather than to the behaviour of the build.

Does class I mean you are outside the rules?

No, and the confusion is structural. Annex VIII Rule 11 is a classification rule, and classification runs after qualification. Article 51(1) reads "Devices shall be divided into classes I, IIa, IIb and III, taking into account the intended purpose of the devices and their inherent risks." The closing sentence of Rule 11, "All other software is classified as class I", therefore assigns a class to something that has already been established as a device. Software with no medical purpose never reaches Rule 11 at all, and software that reaches it and drops to the residual limb is a class I medical device.

What class I removes is the assessor. Article 52(7) leaves the declaration of conformity with the manufacturer for most class I products, so the calendar is shorter and no outside party enters your development records. What it leaves in place is everything else: Article 5(2) binds the Annex I general safety and performance requirements that apply to the device, and Article 5(3) requires a clinical evaluation in accordance with Article 61. Which assessment route each class takes, and which Annex IX chapters it runs through, is laid out under EU MDR software requirements.

MDCG adds a step most teams skip. Since a qualifying product counts as an active device, the guidance asks for seven rules of Annex VIII to be weighed together: 9, 10, 11, 12, 13, 15 and 22. Implementing rule 3.5 then picks between whichever of them apply, taking the strictest. A founder who reads Rule 11, lands on the residual limb and stops has looked at one rule of the seven.

What happens if you leave the question open?

Nothing visible happens, until somebody else answers it for you, and their answer arrives with a date attached to it. Five consequences are worth pricing before that happens.

The obligations are not triggered by your decision. Article 5(2) attaches the Annex I requirements to the device, taking its intended purpose into account, and Article 5(3) attaches the clinical evaluation. Neither provision waits for the manufacturer to classify. A product shipping today under an unwritten answer is already inside or outside; the only open variable is when someone checks.

Clinical evidence accrues over time and cannot be compressed. Article 61(10) does leave a route for software that cannot generate clinical data in the ordinary way, and that route ends in a written justification which has to be substantiated inside the Annex II file. Someone has to build the argument, and the fortnight before a funding close is a poor place to start it.

The conformity assessment route is somebody else's calendar. Article 52 sends class IIa and everything above it to a notified body, so the class you land in decides whether your launch date depends on a third party with a queue. Booking that slot is not an engineering task and it does not compress under pressure.

The transitional dates people quote were written for somebody else. Article 120(3a) and Article 120(3b) extend the market life of devices that already carry a certificate under the old Directives, out to 31 December 2027 or 31 December 2028 depending on class. Entry to that scheme closed twice over: Article 120(3c) attaches five conditions, two of which had to be met by 26 May 2024, with the signed notified body agreement due by 26 September 2024. A product qualifying for the first time this year holds no Directive certificate and met no 2024 deadline, so none of those dates belongs to it.

The last cost is the one that lands on engineering. A risk file assembled after three years of shipping has to reconstruct decisions nobody wrote down at the time. ISO/TR 24971 puts the obligation plainly: ISO 14971 requires traceability from every identified hazard through the analysis, the evaluation, the control measures and their verification, and the point of it is to prove that no hazard was left unaddressed. Built forwards, that trace is a step inside each feature's design. Built backwards, it means reopening decisions whose only surviving record is a closed pull request and, often, a person who has left. What the process asks for, and what testing feeds into it, is on ISO 14971 risk management and software testing.

What do you settle this week?

A written intended purpose statement and a reasoned qualification argument against it. Both are prose, and neither needs a lawyer to start.

Step 2 is the one that stalls, and it stalls for a reason that has nothing to do with regulation. Once the paragraph exists, two levers appear and only one of them belongs to engineering. You can narrow the claim, which is a product decision with a revenue consequence and belongs to whoever owns the pricing page. You can accept the class, which is a budget and a calendar decision and belongs to whoever will sign the notified body contract. Teams stall because those two people are in different meetings, and the engineer who noticed the problem is in neither. Get them in one room with the paragraph on a screen and the decision takes an afternoon.

The paragraph gets written badly in one predictable way. It is tempting to draft the intended purpose narrowly enough to reach the answer you want, then leave the product doing what it always did. That gap is exactly what an assessor, an investor's technical reviewer and a plaintiff's expert all look for, and it is the one discrepancy that testing finds without being asked. MDCG requires the statement to describe all functionalities that serve a medical purpose, and adds that for a modular product each module must independently meet the requirements while the collective functionality aligns with the declared intended purpose.

What changes once the answer is yes?

The documentation obligations reach backwards over code you have already written, and three standards start applying to a product that was built without them.

ISO 14971 names your product inside its own scope: the standard specifies a process for risk management of medical devices "including software as a medical device", and the risks it covers are listed as including data and systems security and usability. It requires the manufacturer to establish objective criteria for risk acceptability and specifies no acceptable risk levels, so the criteria are yours to write and yours to defend.

IEC 62304 defines its subject at 3.12 as a software system "developed for the purpose of being incorporated into the MEDICAL DEVICE being developed or that is intended for use as a MEDICAL DEVICE", with a note that this includes a medical device software product that is a device in its own right. Its clause 4.3 then assigns a software safety class. Under Edition 1.1 the gate to class A has two limbs, and the second is the one founders reach for: a worst case that leaves no unacceptable risk once the risk controls sitting outside the software have been counted. Class A is therefore a conclusion you argue and record, and the argument has to name the external controls holding it up. clause 1.4 then makes compliance a matter of inspecting the documentation the standard requires, including the risk management file. The clause set each class binds is on IEC 62304 software testing requirements.

ISO 13485 starts where this page started. Its Introduction 0.1 expects the organisation to identify its roles under the applicable regulatory requirements, identify the requirements that apply to its activities under those roles, and incorporate them into the quality management system. Until that question has an answer, the system has no scope to define itself against, which is why one undecided paragraph holds up more than it appears to.

Where the software is the whole of the device, the regime is heavier than a team expects and the test record becomes part of what is assessed. That case has its own page: testing software that is itself the medical device.

Where do teams get this answer wrong?

• The regulatory file holds one intended purpose statement and the website holds a different one, and Article 2(12) reads both.
• Rule 11 is applied before qualification, so a product with no medical purpose is given a class, or a qualifying product is described internally as class I and therefore unregulated.
• Only Rule 11 is checked, where the guidance asks for all seven applicable Annex VIII rules to be weighed and implementing rule 3.5 to pick the strictest.
• The classification decision is recorded as a class with no reasoning, where Annex II Section 1.1(f) asks for the justification of the rule applied.
• A disclaimer in the terms of service is treated as overriding the promotional statements that Article 2(12) puts on the same footing as the label.
• A hospital deployment is assumed to sit under the Article 5(5) in-house exemption while the software is supplied by an outside company, which fails condition (a) the moment the device is transferred to another legal entity.
• The safety class is recorded as A with no record of the external risk control measures that made the residual risk acceptable, which is the substance of what IEC 62304 clause 4.3 asks.
• The answer was written before 17 June 2025 and has not been read against MDCG 2019-11 Rev.1.

What can a testing supplier actually do here?

We do not classify your product, and no testing supplier can. Qualification is a determination the manufacturer makes and defends, and a vendor who offers to make it for you is offering something they cannot carry.

What testing establishes is the other half of the argument: what the product actually does, under the inputs it will meet in the field. A qualification argument rests on two documents that have to agree, an intended purpose statement saying what the software is for and an evidence set showing what it does. Where those two disagree, the disagreement is the finding, and it surfaces in a test report before it surfaces in a diligence room. We run the product against the claims on your own published surfaces, one claim at a time, and hand back the list of places where the observed behaviour is wider or narrower than the sentence.

Where the answer comes out yes, the work becomes evidence shaped for the file: a trace that starts at a hazard and ends at the risk left over, records carrying the build identifier and configuration behind each run, and platform coverage taken from the instructions for use instead of from the machines your team develops on. The execution side of that is medical device software testing, which also produces the protocols, matrices and reports holding the evidence together.

None of that work needs your production records. Where a test needs a real-world shape, the route to it is agreed in writing before an environment exists, and the de-identification is verified rather than assumed. We sign a Business Associate Agreement before any engagement that touches PHI. The questions a buyer puts to us first are answered at how we work with protected health information.

Two related questions come up in the same conversation and have separate answers. Whether a US privacy obligation attaches to your product is decided by a different test from this one, worked through at whether HIPAA testing applies to your app. Whether the FDA calls the same software a device is decided by its own definition at section 201(h) of the Federal Food, Drug, and Cosmetic Act, and the records a submission then reads are set out at preparing software records for an FDA submission.

Every provision cited above was verified on 2 September 2026: Regulation (EU) 2017/745 in its official consolidated text as at 1 January 2026 for the articles, annexes and rules, and IEC 62304, ISO 14971 and ISO 13485 for the clause numbers and definitions. Anything credited to MDCG 2019-11 Rev.1 is guidance, which the group says of itself carries no legal force.