Platform thinking can accelerate a MedTech roadmap by letting you reuse a QMS, a risk file, and sometimes clinical evidence across multiple devices. But under MDR, the platform label does not exist. Each device with a distinct intended purpose is its own regulatory object, and a platform approach only pays off when you structure the technical file modularly from day one.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR regulates devices, not platforms. Each intended purpose defined under Article 2(12) can trigger its own classification and conformity assessment route.
  • A platform approach makes sense when you plan three or more devices sharing architecture, risk profile, and clinical rationale.
  • A point-solution approach wins when speed to first CE mark matters more than roadmap breadth, because a narrow intended purpose simplifies everything downstream.
  • Under Annex II you can structure one technical file modularly to serve multiple variants, but Notified Body review still treats each device as distinct.
  • The manufacturer carries all Article 10 obligations regardless of whether you frame the product as a platform or a point solution.

Why this choice shapes the next two years

Founders arrive at this decision with a product idea that keeps expanding. The catheter becomes a catheter family. The mobile app becomes a suite. The AI model starts with one indication and spawns three more before the first clinical data arrives. Somewhere in a pitch deck, the word "platform" appears, and with it the question: do we regulate it as one thing, or many things?

The wrong answer costs twelve months. A platform framing without the underlying modular engineering creates a technical file that collapses under audit. A point-solution framing without reuse discipline means you pay three times for work you could have done once. Both mistakes are recoverable, but both burn runway.

This post separates the strategic framing from the regulatory reality. MDR does not care what you call your product architecture. It cares about intended purpose, risk class, and conformity assessment per device. The platform-versus-point-solution decision is really a decision about how you define intended purpose under Article 2(12), how you scope your Annex II technical documentation, and how you sequence clinical evidence work.

What MDR actually says

MDR defines intended purpose in Article 2(12) 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". That definition is the load-bearing wall of every regulatory decision you make.

Three MDR provisions interact with the platform question:

Article 51 and Annex VIII govern classification. Classification applies to each device according to its intended purpose and the rules in Annex VIII. If your platform hosts two devices with different intended purposes, they may fall into different classes and require different conformity assessment routes under Annex IX, X, or XI.

Annex II specifies the content of the technical documentation. Annex II does not prohibit structuring documentation to cover a device family. The header of Annex II refers to documentation drawn up for the device, and where relevant, variants or configurations. In practice, Notified Bodies accept modular technical files provided each device variant can be extracted and reviewed against the GSPR as a complete file.

Article 10 assigns all manufacturer obligations to you as the legal manufacturer. Those obligations apply per device. A shared QMS is encouraged by EN ISO 13485:2016+A11:2021. Shared risk management is supported by EN ISO 14971:2019+A11:2021. But declarations of conformity, CE certificates, PMS plans, and PSURs are device-specific.

What MDR does not do is recognise a "platform" as a regulatory category. The word does not appear in the regulation. When founders say "we have a platform," auditors hear "we have a set of devices, and we need to understand how each one meets the GSPR."

A worked example

Consider two versions of the same company: a startup building a cardiac monitoring wearable with an algorithm that flags atrial fibrillation.

Version A — Point solution. Intended purpose: "intended to detect signs of atrial fibrillation in adults aged 22 and older from single-lead ECG data, to support referral to a cardiologist." One device. Classification under Rule 11 likely falls into Class IIa because the output informs clinical decisions that are not immediately life-threatening. One Notified Body route under Annex IX. One clinical evaluation report. Time to first CE mark, assuming a well-run startup, is roughly 14 to 18 months from freeze to certificate.

Version B — Platform. Intended purpose as pitched internally: "a continuous cardiac monitoring platform for arrhythmia detection, heart failure prediction, and post-surgical recovery tracking." Three intended purposes, potentially three classifications, three clinical evaluations, three bodies of evidence. Under Annex VIII Rule 11, heart failure prediction could push toward Class IIb because of the severity of the decisions it informs. Each indication carries its own clinical data requirement under Article 61 and Annex XIV.

Version A ships in 16 months. Version B, if run in parallel, takes 28 to 36 months and burns three times the clinical budget. If run sequentially, the first indication ships in 16 months, but each subsequent indication adds 8 to 12 months.

The platform framing pays off only if Version B can genuinely reuse work: one architecture document, one SOUP assessment, one cybersecurity dossier under EN IEC 81001-5-1:2022, one usability file under EN 62366-1:2015+A1:2020, and a modular clinical evaluation where the state of the art section and the methodology are shared across indications. If the startup cannot structure the technical file that way, the platform framing creates overhead without reuse.

The decision is not "which is better." The decision is: which framing matches our engineering discipline and our capital plan.

The Subtract to Ship playbook

The lean move is to start narrow, build reuse scaffolding, and expand the intended purpose only when a second indication has clinical and commercial evidence to justify it.

Step 1 — Pick the beachhead intended purpose. Write the Article 2(12) statement for the single indication with the strongest product-market fit signal. Resist the pitch-deck temptation to list three indications. One intended purpose is one device, one classification, one CER, one certificate.

Step 2 — Engineer for reuse without paying for it upfront. Structure your QMS, risk management file, software architecture, and SOUP list so they can serve future variants. This costs almost nothing at the start if you plan for it. It costs a rewrite if you do not.

Step 3 — Write the technical file modularly from day one. Use the Annex II sections as a skeleton. For each section, mark which content is device-specific and which is shared across future variants. Share the QMS reference, the risk management method, the usability engineering approach, and the cybersecurity architecture. Isolate the intended purpose, the clinical evaluation, the claims, the labelling, and the performance testing per variant.

Step 4 — Budget clinical evidence per indication, not per platform. Under Article 61 and Annex XIV, clinical evidence must support the specific intended purpose. You cannot average evidence across indications. Budget each indication as its own project, with its own CEP, its own literature search, and its own clinical data strategy.

Step 5 — Sequence the expansion after the first certificate. Once the first device is CE marked, expanding is a change management exercise. Depending on the change, it may be a significant change requiring Notified Body review under Annex IX. Plan this sequencing with your Notified Body during the first audit, not after.

Step 6 — Only use the word platform externally. Internally, track devices. Externally, market a platform if it helps your commercial narrative. The regulatory system tracks devices. Your investors track a platform story. Both can be true at once.

The lean approach is rarely "build a platform." It is "ship a device, engineer for reuse, expand when evidence justifies it."

Reality Check

  • Have you written a single Article 2(12) intended purpose statement for the specific device you will submit first, or are you still holding three candidate indications open?
  • Can you point to each Annex II section and say which content is device-specific and which is shared across future variants?
  • If you were forced to ship only one indication in the next 16 months, which one has the clearest clinical and commercial evidence today?
  • Does your QMS documentation anticipate multiple devices, or is it written as if only the first device exists?
  • Have you budgeted clinical evidence work per indication under Article 61, or are you still assuming one CER will cover multiple indications?
  • Does your pitch deck platform story match the regulatory reality your Notified Body will see, or is there a gap?
  • Who on your team is responsible for translating the platform narrative into device-level regulatory objects, and do they have the authority to push back on scope creep?

Frequently Asked Questions

Can one CE certificate cover a platform with multiple indications? A CE certificate is issued for specified devices with specified intended purposes. One certificate can cover multiple device variants if they share an intended purpose and are covered by the same conformity assessment. Different intended purposes typically require separate certificates or extensions to an existing certificate.

Is a modular technical file allowed under MDR? Annex II does not prohibit modular structuring. Notified Bodies accept it in practice as long as each device variant can be reviewed as a complete file against the GSPR in Annex I. The test is whether an auditor can reconstruct a full file for any single device variant from the modular documentation.

If we start as a point solution, can we expand to a platform later? Yes. This is the Subtract to Ship sequence. Ship the first device, then manage each new indication as either a certificate extension, a significant change, or a new device depending on the scope of the change. Plan the sequence with your Notified Body.

Does a platform approach reduce clinical evaluation work? It reduces shared methodological work, such as the state of the art analysis and the literature search protocol. It does not reduce the device-specific clinical data required under Article 61 for each indication. Clinical evidence must support the specific intended purpose you claim.

Should we list multiple intended purposes to keep options open? No. A broad intended purpose under Article 2(12) expands your clinical evidence burden, complicates classification, and often pushes you into a higher class under Annex VIII. A narrow, honest intended purpose is nearly always the lean choice.

Who decides whether our product is one device or several? You do, through the intended purpose statement. The Notified Body and competent authority then review whether your decision is consistent with MDR. In contested cases, classification disputes are resolved through the procedure the Notified Body follows with the relevant competent authority.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Articles 2(12), 10, 51, 61. Annexes I, II, VIII, XIV.
  2. MDCG 2021-24 (October 2021) — Guidance on classification of medical devices.
  3. EN ISO 13485:2016+A11:2021 — Medical devices, Quality management systems.