Writing an intended purpose that classifies you upward by accident
Marketing copy is evidence of intended purpose. A landing page claiming the product detects a condition can qualify software that the regulatory file describes as a wellness tool.
The EU Medical Device Regulation — Regulation (EU) 2017/745 — governs the safety, performance and market access of medical devices in the European Union, software included. It sets classification rules, general safety and performance requirements, clinical evidence expectations, conformity assessment routes and post-market obligations. For anything above Class I, a notified body must be involved.
Rule 11 is the provision that reshaped digital health. Software intended to provide information used to take decisions for diagnostic or therapeutic purposes is Class IIa — rising to IIb where such a decision could cause serious deterioration in health or require surgical intervention, and to III where it could cause death or an irreversible deterioration. Software intended to monitor physiological processes is IIa, or IIb where the parameters are vital and variation could create immediate danger. Everything else is Class I.
The practical effect is that products which would have been Class I under the old directive are now IIa. That means a notified body, a certified quality management system, an audit, and a timeline measured in quarters rather than weeks. Notified body capacity remains the binding constraint for most first-time manufacturers, and the queue is not something a well-run project can compress — it has to be planned around from the beginning.
The upstream question is still qualification. Intended purpose determines everything, and it is set by what you claim — including in your marketing.
Marketing copy is evidence of intended purpose. A landing page claiming the product detects a condition can qualify software that the regulatory file describes as a wellness tool.
Contract capacity early. Review queues, not engineering effort, set the date for most first submissions.
Surveillance, clinical follow-up and vigilance plans are part of conformity assessment. They are reviewed at audit, before you have any post-market data at all.
It turns on intended purpose. If the software is intended for a medical purpose — diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease — it is a device, regardless of how it is built. Intended purpose is set by what you claim, and marketing copy counts as evidence of it.
Software providing information used to take diagnostic or therapeutic decisions is Class IIa; IIb where such a decision could cause serious deterioration or require surgical intervention; III where it could cause death or irreversible deterioration. Software monitoring physiological processes is IIa, or IIb for vital parameters where variation creates immediate danger. Everything else is Class I.
Not for plain Class I, which is self-declared. A notified body is required for Class Is, Im and Ir, and for everything from IIa upward. This is why Rule 11 mattered so much — it moved a large amount of software that was Class I under the old directive into IIa, and with it into notified body scope.
Plan in quarters, not weeks. For Class IIa and above the binding constraint is usually notified body review capacity rather than your engineering effort, and queues are not something a well-run project can compress. Contracting capacity early is the single most effective thing you can do for the timeline.
Working out how EU MDR applies to what you are building is usually the first conversation.
Get in touch →