The MDR Pathway for Solo Developers. Reading Rule 11 Without a Compliance Department.

When a solo developer first reads the EU Medical Devices Regulation, a particular kind of dread sets in. The document is over five hundred pages. It speaks of notified bodies, conformity assessment procedures, technical documentation, post-market surveillance, vigilance, EUDAMED, summary of safety and clinical performance, periodic safety update reports. The vocabulary alone suggests an industry only accessible to companies with dedicated regulatory affairs departments.

That impression is partly correct and partly wrong. Yes, the MDR is heavy. Yes, full conformity assessment for higher-risk devices is genuinely expensive and slow. But the regulation also accommodates smaller, lower-risk software in a way that is workable for a careful solo developer, provided you read it carefully and resist two opposite temptations: pretending the regulation does not apply, or pretending you cannot possibly meet it.

The question that comes first

Before anything else, the question is whether the software you are building qualifies as a medical device at all. Article 2(1) of the MDR defines a medical device by its intended purpose. If the manufacturer intends it for diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, it is a medical device. If it is intended merely for general lifestyle, fitness or wellbeing, it is not.

This is not a question to answer casually. The „intended purpose” is what the developer claims about the product: in the user-facing description, in marketing, in the app store listing, in screenshots. A wellness tracker becomes a medical device the moment its manufacturer claims it helps manage a condition. The line is drawn by language as much as by function.

For a solo developer, the most honest first step is to draft the intended purpose statement before writing any code, and treat it as a constraint document. It will tell you whether you are entering the MDR’s scope or staying outside it.

What Rule 11 actually says

If the software does qualify as a medical device, classification rules in Annex VIII determine its class. Rule 11 is the one that applies to most software medical devices. Simplified: software intended to provide information used to take decisions for diagnostic or therapeutic purposes is at least Class IIa. Software intended for monitoring physiological processes can be Class IIa or IIb depending on the parameters monitored. Software intended for general non-decision-supporting documentation can be Class I.

The practical effect is that the difference between Class I and Class IIa is the difference between self-declaration and a notified body. Class I devices can be brought to market by the manufacturer’s own conformity declaration, registration with the national authority, and the necessary technical documentation, without involving a notified body. Class IIa and above require notified body involvement, which adds substantial cost and time.

For solo developers, the realistic path is therefore to design the application so that it sits as low in the classification hierarchy as is honestly compatible with its purpose. This is not about gaming the rule. It is about being clear with yourself and with the regulator about what the software does, and choosing scope accordingly.

Class I and self-declaration is the difference between a six-month process and a three-year one. Choose scope deliberately.

Where the class line actually runs

The abstract reading of Rule 11 becomes concrete as soon as one places real software features on the scale. A short series of examples, the way they tend to fall in practice:

An app that takes a patient’s pain scores, displays them in a list and lets the treating clinician download a PDF export is Class I. It collects and documents; it proposes no decision.

The same app with an alert threshold (for example: a pain score above 7 triggers a hint to call the hotline) edges towards the Class IIa line. The decisive question is whether the app now provides information used for a therapeutic decision. If the hint merely repeats the standard guidance the patient already has, Class I still fits. If the hint proposes a dose adjustment or recommends a specific action, Class IIa is the more likely fit.

A medication reminder app is usually Class I, because it is a pure organisation aid with no therapeutic recommendation. An app that calculates medication doses (such as insulin from carbohydrates and blood glucose) is Class IIa or higher, because the calculation result directly carries a therapeutic decision.

A symptom diary for patients with a chronic condition that stores data locally and lets the user export it on demand is Class I. The same diary with a feature that predicts a risk profile for the next exacerbation from the trend data is Class IIa.

The point is not to talk a Class IIa app down to Class I through careful wording. The intended purpose and the actual functionality have to match. The point is to choose the functionality deliberately. An app that starts as a pure documentation tool and leaves decision support to the clinicians is regulatorily much more manageable than an app that carries the decision itself, and in many clinical contexts it is also the more honest choice.

The technical file: less mysterious than it sounds

Annex II of the MDR lists what the technical documentation must contain. The list is long, but the substance is recognisable to anyone who has worked thoughtfully on a software project: a device description, an intended purpose statement, a list of relevant standards applied, the design and manufacturing information, the risk analysis, the verification and validation evidence, and the labelling and instructions for use.

For a small developer, this can be assembled progressively as the product matures. Risk analysis under ISO 14971 is the spine: it lists hazards the device could introduce, evaluates likelihood and severity, and documents the mitigations. Usability engineering under IEC 62366 documents how human factors were considered. Software life cycle processes under IEC 62304 frame the development itself.

None of these standards is invented to torment small teams. They are codifications of the basic question: did you think carefully about what could go wrong, and did you do something about it? A solo developer who writes honest answers to those questions, version-controlled and dated, is most of the way there. For a complementary perspective on the architectural side, see Privacy by Design in Health Apps.

The quality management system question

The harder requirement is the quality management system. For Class I devices, a documented QMS is required but does not have to be certified under ISO 13485. For Class IIa and above, certification by a notified body is typically expected.

For a one-person studio, building a QMS that is real but proportionate is possible. The system must define how design decisions are reviewed, how changes are controlled, how supplier qualifications are managed (even if the suppliers are open-source library maintainers), how post-market surveillance is handled, and how the developer ensures the product continues to perform as claimed. The documentation does not have to be voluminous. It has to be lived.

A useful exercise is to write the QMS as a set of short standard operating procedures, one or two pages each, that match what the developer actually does. If the SOP says something different from the practice, one of them is wrong.

Engaging a notified body when needed

For Class IIa devices, a notified body must conduct the conformity assessment. Notified bodies have been under capacity pressure since MDR came into application. Lead times measured in many months are common. For a small developer, the engagement starts long before the actual audit: pre-submission consultations are usually possible and worth the cost.

The studio’s working assumption is that engagement should begin as soon as the technical file is approximately seventy percent complete. Earlier than that, you waste the notified body’s time and your own. Later, you risk a sudden bottleneck just when you want to launch.

The post-market reality

What is often underestimated by solo developers is the post-market obligations. Once the device is on the market, the manufacturer must operate a post-market surveillance system, file a Periodic Safety Update Report (for Class IIa and above), and respond to incidents under the vigilance system. These are ongoing duties, not one-time hurdles.

For a one-person studio, the design constraint this implies is that the product must be operable indefinitely with the resources available. A complex post-market plan that requires a team to execute is a plan that will fail. A simpler plan, executed every quarter without fail, beats an elaborate one that lapses after eighteen months.

What this looks like in practice

The studio’s working model for a Class I or borderline IIa software medical device is roughly this. Define the intended purpose narrowly and write it down before coding. Build the application around local-only data and a minimum of external dependencies. Maintain a risk file in version control from the first sprint. Document design decisions as they happen, not retrospectively. Write the user instructions and labelling alongside the UI, not afterwards. Engage external clinical and regulatory review at the seventy-percent mark. Plan post-market surveillance as part of the product, not as paperwork bolted on at the end.

None of this requires a compliance department. It requires honest, paced, version-controlled work. That is what good software development looks like anyway.

Frequently asked

When does an app qualify as a medical device under EU MDR?

An app qualifies as a medical device when the manufacturer intends it for diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease (Art. 2(1) MDR). The intended purpose is determined by what the manufacturer claims (in app store listings, marketing, descriptions), not by function alone.

What does Rule 11 of the MDR say?

Rule 11 (Annex VIII MDR) classifies software medical devices. Software intended to provide information for diagnostic or therapeutic decisions is at least Class IIa. Software for monitoring physiological processes is Class IIa or IIb depending on the parameters monitored. Software for general non-decision-supporting documentation can be Class I.

What is the practical difference between Class I and Class IIa?

Class I devices can be brought to market via the manufacturer's own conformity declaration plus registration with the national authority, without a notified body. Class IIa requires conformity assessment by a notified body, which adds substantial time and cost (often years instead of months).

Can a solo developer meet MDR requirements?

Yes, with careful planning. Required: a narrowly defined intended purpose drafted before coding, technical documentation per Annex II (built progressively), risk analysis under ISO 14971, usability engineering under IEC 62366, software lifecycle under IEC 62304, a documented QMS proportional to the class, and a post-market surveillance system that is operable long-term.