Subscription pricing for medical software is entirely legal under MDR, but every pricing tier, feature flag, and configuration toggle is a regulatory artefact. If Plan A and Plan B expose different medical functionality, you are either shipping two intended purposes under one CE certificate, or you are turning a commercial switch into a significant change. Neither is fatal. Both require the pricing model and the QMS to be designed together.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR Annex VIII Rule 11 classifies software that provides information for diagnostic or therapeutic purposes, and the classification depends on the medical decision the software influences, not on the pricing tier.
  • Feature flags that gate medical functionality are part of the configuration management scope of EN 62304:2006+A1:2015 and must be controlled like any other software change.
  • A pricing tier that exposes a new clinical feature is a change to the intended purpose unless the feature was already in scope of the original Article 2(12) definition and the original clinical evaluation.
  • MDCG 2019-11 Rev.1 remains the authoritative guidance for software qualification and classification under Rule 11, and it does not care whether your customers pay monthly or annually.
  • The Subtract to Ship move is to design the intended purpose broadly enough to cover the commercial roadmap, then freeze the medical functionality perimeter and let pricing modulate only within that perimeter.

Why this matters

A recurring conversation with SaMD founders: "We want to ship a free tier with basic triage, a Pro tier with risk scoring, and an Enterprise tier with a dashboard for clinicians. Is that a problem?"

The answer is, it depends on exactly one thing: which of those features sits inside your CE-marked intended purpose and which sits outside. If all three tiers use functionality that is covered by a single Article 2(12) intended purpose and a single clinical evaluation, then you are running three commercial packages of one medical device. If Pro exposes a medical decision that Free does not, and that decision was not covered by the original clinical evaluation, then Pro is a different device or a significant change to the same device.

Founders who do not think this through end up in one of three painful places: shipping a feature flag that accidentally places a new device on the market without Article 5 compliance; delaying a paid feature launch by months because the notified body wants to re-review; or writing an intended purpose so broad and vague that the notified body rejects it as non-specific.

The solution is cheap if you start early and expensive if you start late. Start early.

What MDR actually says

Annex VIII Rule 11 classifies software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes. Class IIa is the baseline. Class IIb applies when decisions may cause serious deterioration in a person's state of health or surgical intervention. Class III applies when decisions may cause death or irreversible deterioration. Software intended to monitor physiological processes is Class IIa, or Class IIb where monitoring vital physiological parameters with variations that could result in immediate danger. Everything else stays Class I.

Rule 11 classifies based on the medical purpose of the information produced. Not on pricing, not on deployment model, not on whether the customer pays monthly.

Article 2(12) on intended purpose remains the load-bearing definition. Whatever you claim in the label, IFU, promotional material, and clinical evaluation is the intended purpose, and it governs the regulatory scope. A paid feature that does something outside that scope is not inside the CE certificate.

MDCG 2019-11 Rev.1 (October 2019, revised June 2025) is the authoritative guidance on software qualification and classification under Rule 11. It lays out the decision logic the notified body will use to classify your software. Read it alongside Annex VIII, not as a substitute.

Significant change rules. Article 120(3) covers legacy devices under MDD certificates continuing under MDR transition, but for a device already CE marked under MDR, the question of whether a software modification constitutes a significant change is governed by the Article 10(9) quality management obligations, Annex IX change control, and the MDCG guidance on significant change (MDCG 2020-3 for legacy, applied by analogy; notified bodies apply similar logic for MDR-native changes). Practically: a change that affects the intended purpose, the performance, the safety, or the clinical claims triggers notified body notification and potentially a conformity reassessment.

EN 62304:2006+A1:2015 governs medical software lifecycle processes, including configuration management. Feature flags, if they gate medical functionality, are configuration items under EN 62304 and must be managed accordingly. You cannot toggle medical features in production without the change control process catching up.

A worked example

A SaMD startup ships a symptom-triage web application. Intended purpose, Article 2(12): "Software intended to provide lay users with guidance on whether to seek urgent, non-urgent, or self-care pathways based on self-reported symptoms." Classified under Rule 11 as Class IIa because the information is used to take decisions with diagnostic purpose, but the severity of a wrong output falls below the Class IIb threshold (with notified body agreement; contested classifications are routine here).

They want to launch three tiers:

Free tier. The core triage feature. Pro tier (EUR 9.99/month). Core triage plus a personalised symptom history, symptom tracking over time, and automatic flagging if a tracked symptom escalates. Clinician tier (EUR 29/month per seat). Everything in Pro plus a dashboard view for clinicians to see a panel of consenting patients, with risk-stratification based on the triage outputs.

Analysis:

  • The Free tier sits cleanly inside the original intended purpose and clinical evaluation.
  • The Pro tier's symptom history is likely covered, but automatic escalation flagging is a new medical decision output ("is this symptom pattern escalating to an urgent pathway?") that may or may not sit inside the original clinical evaluation. If the clinical evaluation did not evaluate the performance of the escalation flagging algorithm, then the Pro tier is a significant change and cannot ship as a pricing toggle. It ships as a version update with change control, impact analysis, clinical evaluation update, and notified body notification.
  • The Clinician tier adds a new intended user (a healthcare professional) and a new medical decision output (risk stratification across a panel). This is almost certainly outside the original intended purpose. It is either a new intended purpose requiring a substantial conformity reassessment or, arguably, a separate device.

A founder who ships all three tiers behind feature flags on the day of CE mark has, at minimum, committed to significant change notifications they did not budget for, and at worst, placed a new device on the market without Article 5 compliance.

A founder who anticipates this builds the intended purpose from day one to cover the commercial roadmap explicitly, runs the clinical evaluation to cover all three feature sets, and treats the pricing tiers as a commercial wrapper around a single, pre-qualified medical functionality perimeter. Cost: perhaps two extra months of clinical evaluation work up front. Savings: six to twelve months of conformity reassessment later.

The Subtract to Ship playbook

Draw the medical functionality perimeter before you draw the pricing tiers. Write down every medical decision your software could output over the next eighteen months. Draw a ring around all of them. Everything inside the ring must be covered by the intended purpose, the clinical evaluation, and the classification. Everything outside the ring is a future project with its own regulatory timeline.

Design pricing to modulate within the perimeter, not across it. Inside the perimeter, you can sell any subset at any price. Outside, you cannot. If Clinician tier needs to stratify risk across a panel and panel-level stratification is not inside the perimeter, do not ship it behind a feature flag. Either expand the perimeter now, knowing the cost, or defer the tier.

Treat feature flags as configuration items under EN 62304. Each flag that gates medical functionality needs to be documented, version-controlled, and included in change impact analysis. A hot-toggle of a medical feature in production, even "for one beta customer", is a release and triggers the release process.

Do not use pricing tiers to differentiate clinical performance. A "Pro algorithm" that performs differently from a "Free algorithm" is two devices in one product. This is legal only if the intended purpose and clinical evaluation cover both. It is almost never what founders actually want. The cheaper move is to ship one clinical-performance version and gate non-clinical features (export, branding, seat count, support) across tiers.

Read MDCG 2019-11 Rev.1 before you finalise the pricing page. The classification logic affects which features you can bundle at which tier without crossing a classification boundary. A Pro tier that pushes you from Class IIa to Class IIb because of the severity of decisions it influences changes your entire conformity assessment.

Budget for the post-market surveillance consequences of tiering. If different cohorts of users experience different medical functionality, your PMS plan has to segment by cohort. You cannot pool complaint data across tiers if the tiers expose different medical features, because you lose the ability to link a complaint to a specific functionality.

Keep configuration changes inside Annex IX change control. If a tier change for a specific customer activates a new feature, that is a configuration change for that customer. Under Annex IX the QMS has to handle it as a controlled change, not as a billing-system event.

Reality Check

  1. Have you written down the full medical functionality perimeter you expect to sell over the next eighteen months, and is it covered by your current intended purpose?
  2. Does each pricing tier in your plan sit entirely inside the perimeter, or does at least one tier expose functionality outside it?
  3. Have you classified every medical decision output under Rule 11, using MDCG 2019-11 Rev.1 as the decision logic?
  4. Are your feature flags documented as configuration items under EN 62304, with version control and impact analysis?
  5. Do you have a written rule for when a feature flag toggle triggers your change control process?
  6. Does your clinical evaluation cover the highest-functionality tier, or only the baseline?
  7. Is your PMS plan segmented by tier if different tiers expose different medical functionality?
  8. Have you checked whether any tier crosses a classification boundary that would require a different conformity assessment route?

Frequently Asked Questions

Can I charge different prices for the same medical software feature? Yes. Charging different prices for the same feature is a commercial decision, not a regulatory one. It is only when different prices correspond to different medical functionality that MDR becomes involved.

Does adding a feature to a paid tier always trigger a significant change? Not always. If the feature is inside the original intended purpose, clinical evaluation, and classification, and it does not affect performance, safety, or claims, it may be a non-significant change. If any of those conditions fail, it is significant.

How does MDCG 2019-11 Rev.1 affect my pricing roadmap? It governs how your software is classified, which determines your conformity assessment burden and the ceiling on what you can ship without notified body involvement. Bundling features that push you across a classification boundary changes the economics of your whole plan.

Can I ship a free tier without CE marking? No. If the free tier is a medical device under Article 2(1), it must be CE marked. Price is irrelevant to Article 5. A free medical device is still a medical device.

What about a feature flag I use only for internal testing? Internal testing of a non-released feature is fine under your development QMS, but once the flag is toggled on for a real user, that feature is in the field and the release process applies.

Does the EU AI Act overlap with SaaS pricing for SaMD? The EU AI Act interacts with MDR for AI-enabled SaMD, adding obligations on high-risk AI systems that run in parallel to MDR. Pricing decisions that affect model behaviour (e.g. a Pro tier with a different model) may need to be reflected in both the MDR file and the AI Act conformity work.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex VIII Rule 11, Article 2(12), Article 10(9), Annex IX.
  2. MDCG 2019-11 Rev.1 (October 2019, revised June 2025) on qualification and classification of software in Regulation (EU) 2017/745.
  3. EN 62304:2006+A1:2015, medical device software lifecycle processes.