A clinical evidence strategy medtech portfolio plan treats every SKU, variant, and future device in the pipeline as one evidence system, not one CER at a time. The strategy defines a shared clinical data pool governed by a master clinical evaluation plan, family-level Clinical Evaluation Reports where MDR Annex XIV Part A permits, a Post-Market Clinical Follow-up plan under Annex XIV Part B that harvests evidence across SKUs, and a multi-year roadmap that schedules literature updates, equivalence reassessments, and any new clinical investigations once — not per variant. Startups that plan clinical evidence at the portfolio level rather than the SKU level cut CER authoring cost by half or more and keep every device in the family auditable on the same cycle.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • A portfolio-level clinical evidence strategy treats all current and planned devices as one evidence system anchored in a shared clinical data pool and a master Clinical Evaluation Plan.
  • MDR Article 61 and Annex XIV Part A permit family-level Clinical Evaluation Reports where devices share the same intended purpose, technology, and risk profile, with variant-specific addenda for differences.
  • MDCG 2020-5 equivalence rules apply within a family as well as between devices, and MDCG 2023-7 access-to-data requirements still hold for implantable and Class III variants.
  • A single portfolio PMCF plan under Annex XIV Part B can harvest evidence across SKUs simultaneously, feeding every CER in the family from one data stream.
  • Planning clinical evidence at the portfolio level typically cuts total CER authoring cost by half or more compared with writing each variant as a standalone evaluation.

Why portfolio thinking changes the clinical evidence math

Most startups write their first Clinical Evaluation Report for one device. Then they write a second CER for the next variant, from scratch, because that is how the first one was structured. Then a third. By the fourth SKU, the clinical team is drowning, the CERs contradict each other on small points, and the notified body starts asking why the literature search in CER-03 produced different results than the one in CER-01 done three months earlier.

The problem is not effort. The problem is architecture. Clinical evidence under MDR Article 61 and Annex XIV Part A is not fundamentally a per-device obligation — it is an obligation that each device on the market must be supported by sufficient clinical evidence. Nothing in the regulation requires that evidence to be assembled independently for each SKU. If two devices share the same intended purpose, the same core technology, and the same risk profile, the evidence supporting them is largely the same evidence. Treating them as independent files duplicates work and introduces inconsistencies that the reviewer will find.

A portfolio-level clinical evidence strategy flips the question. Instead of asking "what evidence does this device need?", the strategy asks "what is the evidence system that supports every device we ship and every device we plan to ship, and how do we update it once?". That single reframing is where the cost savings live.

The shared clinical data pool

The first building block of a portfolio strategy is a single governed clinical data pool. The pool contains every piece of clinical data the company has identified, appraised, and deemed relevant to any device in the portfolio — published literature, equivalence data from competitor devices where access under MDCG 2023-7 is documented, clinical investigation data, PMCF data, PMS complaints, vigilance data, and registry data.

The pool is governed by one master Clinical Evaluation Plan that defines the scope, the search strategy, the databases, the inclusion and exclusion criteria, and the appraisal criteria once. Every CER in the portfolio then draws from the same pool using the same method. When the literature is updated, it is updated once for the entire pool — and every CER downstream inherits the update in its next revision cycle.

The pool is not a filing cabinet. It is a versioned, controlled resource with a clear owner, a defined update cadence, and an audit trail. Under Annex XIV Part A, the clinical evaluation must follow a methodologically sound procedure, and the pool is the infrastructure that makes the procedure reproducible across devices.

Family CERs under Annex XIV Part A

MDR Annex XIV Part A specifies content, not chapter numbering, and it does not require a separate CER document per SKU. Where devices share the same intended purpose, the same core technology, and the same risk profile, a single family-level CER covering the family is permissible and — in practice — preferred by most notified bodies, provided the differences between variants are addressed transparently.

The mechanism is straightforward. The family CER establishes the shared clinical picture: the state of the art, the data from literature, the equivalence analysis where relevant under MDCG 2020-5, the GSPR mapping to Annex I, and the benefit-risk determination for the family. Variant-specific addenda then address what is unique about each variant: the specific size, the specific material option, the specific indication subset, the specific risk controls that differ. Each addendum is short. Each addendum references the shared family CER for everything it does not need to repeat.

The boundary of "family" is the critical design decision. Devices that share the same intended purpose and the same technological characteristics can sit inside one family. Devices whose intended purpose or core technology diverges cannot. MDCG 2019-11 Rev.1 gives useful boundary examples for software, and MDCG 2021-24 informs classification boundaries that often align with family boundaries. The founder's job is to draw the family lines early and defend them to the notified body — if the family is drawn too broadly, the reviewer will split it; if it is drawn too narrowly, the company duplicates work it did not need to duplicate.

Leveraging PMCF across SKUs

The Post-Market Clinical Follow-up plan under MDR Annex XIV Part B is the other major lever. PMCF is often written as a per-device obligation in the first cycle, with each device carrying its own standalone plan and its own standalone activities. That architecture is expensive and leaves the portfolio with multiple half-powered data streams instead of one powerful one.

A portfolio PMCF plan under Annex XIV Part B consolidates the activities. One registry enrolment covers multiple variants. One PMCF survey instrument collects outcome data across the family. One structured literature surveillance process feeds every CER in the pool. One user feedback loop from the PMS system is parsed device-by-device but collected once. Each variant's PMCF plan then references the portfolio plan and specifies only what is variant-specific — a particular safety endpoint, a particular use population, a particular follow-up duration.

Guidance on PMCF plan and report templates is given in MDCG 2020-7 and MDCG 2020-8 respectively. The templates are written device-by-device, but nothing in the templates prevents a manufacturer from referencing a portfolio-level plan and appending variant-specific sections. The reviewer's question is whether the activities are proportionate to the clinical uncertainty of each device and whether the data will be analysable at the device level. If both answers are yes, a portfolio-level PMCF plan is legitimate and — again — strongly preferred by experienced reviewers.

A worked multi-product example

Consider a startup with three devices on the roadmap. Device A is a Class IIa measurement device already CE-marked. Device B is a Class IIa variant of Device A with a larger form factor for a paediatric population. Device C is a Class IIb next-generation version with an added software-based analysis module under Annex VIII Rule 11. All three share the same core measurement technology and the same fundamental intended purpose (measuring the same physiological parameter for the same clinical decision), but with variant-specific differences.

The per-device approach writes three CEPs, three CERs, three PMCF plans, three literature searches, three equivalence analyses, three GSPR traceability tables, and three benefit-risk determinations. The portfolio approach writes one master CEP defining scope across the family, one shared clinical data pool, one family CER covering Devices A and B with a paediatric addendum for B, one separate but linked CER for Device C addressing the software module under MDCG 2019-11 Rev.1 and Rule 11, one portfolio literature surveillance process, and one portfolio PMCF plan with variant-specific endpoints.

The methodological rigour is the same. The article and annex references are the same. The GSPRs mapped are the same (plus the Rule 11 software specifics for Device C). What changes is the number of documents the team writes and the number of separate update cycles the team maintains. In practice, a founder who builds this architecture before writing CER-01 saves the equivalent of one full CER per additional SKU across the portfolio lifetime.

The multi-year evidence roadmap

A portfolio clinical evidence strategy is not a document. It is a roadmap. The roadmap lives on one page and sits next to the product roadmap. For every planned device, it specifies which family the device joins, which sections of the existing pool already cover it, which gaps need new evidence, whether those gaps close with literature, equivalence under MDCG 2020-5 and MDCG 2023-7, harmonised standards, or new clinical investigations under EN ISO 14155:2020+A11:2024, and when the CER for that device lands relative to the device's target CE-marking date.

The roadmap also schedules update cycles. Under MDR Article 61(3), CERs are updated throughout the device lifecycle at a frequency proportionate to the risk class. The portfolio roadmap lands all family CER updates on the same cycle, feeds them from the same updated literature search, and pushes the updated evidence through every variant addendum simultaneously. A notified body seeing this architecture during surveillance audits will not need to ask why CER-A and CER-B are different versions of the same search — they are not.

Every line item on the roadmap traces to a specific MDR article, annex paragraph, or MDCG provision. Anything that does not trace comes off the roadmap. This is the Evidence Pass of the Subtract to Ship framework (065) applied at portfolio scale.

Reality Check — Where do you stand?

  1. Do you have a single master Clinical Evaluation Plan that scopes clinical evidence across every current and planned device in your portfolio, or one CEP per device?
  2. Do you have a shared, version-controlled clinical data pool with a named owner and a defined update cadence?
  3. Have you drawn explicit family boundaries for your devices, with documented reasoning about shared intended purpose, technology, and risk profile?
  4. Where devices share a family, do you have a family-level CER with variant-specific addenda, or three separate CERs for three variants of the same thing?
  5. Does your PMCF plan under Annex XIV Part B cover the portfolio, or do you have multiple parallel plans duplicating activities?
  6. Is your clinical evidence update cycle synchronised across the family so that all CERs inherit the same updated literature search in the same revision?
  7. Does your multi-year clinical evidence roadmap align with your product roadmap and your CE-marking timeline for each SKU?

Frequently Asked Questions

What is a clinical evidence strategy for a medtech portfolio? A clinical evidence strategy for a medtech portfolio is a single plan that treats every current and planned device as one evidence system, anchored in a shared clinical data pool and a master Clinical Evaluation Plan. It defines family boundaries, shared literature and equivalence evidence, family-level Clinical Evaluation Reports under MDR Annex XIV Part A where permissible, and a portfolio PMCF plan under Annex XIV Part B, so evidence is assembled and updated once across SKUs rather than rebuilt per device.

Can one CER cover multiple devices under MDR? Yes, where the devices share the same intended purpose, the same core technology, and the same risk profile. MDR Annex XIV Part A specifies content, not a one-CER-per-device rule, so a family-level CER with variant-specific addenda is permissible and commonly accepted by notified bodies provided the differences between variants are addressed transparently and each variant's GSPR mapping and benefit-risk determination is traceable.

How do equivalence rules apply across a device family? MDCG 2020-5 equivalence rules apply within a family as well as between unrelated devices. Where a new variant in the family relies on clinical data generated on an earlier variant, the manufacturer must still demonstrate technical, biological, and clinical equivalence between the variants in the same way. For implantable and Class III variants, MDCG 2023-7 sufficient-levels-of-access requirements apply — which is straightforward within a single company's own portfolio but must still be documented.

Can a single PMCF plan cover multiple devices in the portfolio? Yes. MDR Annex XIV Part B and the MDCG 2020-7 PMCF plan template do not prohibit a portfolio-level plan. The plan must ensure activities are proportionate to the clinical uncertainty of each device and that data can be analysed at the device level. A portfolio PMCF plan with variant-specific endpoints and one shared data-collection infrastructure is legitimate and typically preferred over multiple parallel plans.

When should a startup build a portfolio clinical evidence strategy? Before writing CER-01. Building the portfolio architecture retrospectively, after three standalone CERs already exist, costs more than writing them as a family in the first place — because the team now has to reconcile three independent literature searches, three appraisal frameworks, and three incompatible structures. The cheapest moment to design portfolio thinking is when the second device is still on the roadmap and the first device has not yet been submitted.

Does a family CER pass notified body review as cleanly as a per-device CER? In our experience, cleaner — provided the family boundaries are defended, the variant-specific addenda are complete, and the GSPR traceability is variant-specific where it needs to be. Reviewers see a lot of copy-paste CERs across portfolios with inconsistent literature searches and contradictory conclusions. A disciplined family CER with one controlled data pool and clean addenda is easier to review than three disconnected documents.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 61 (clinical evaluation), Annex XIV Part A (clinical evaluation) and Annex XIV Part B (post-market clinical follow-up). Official Journal L 117, 5.5.2017.
  2. MDCG 2020-5 — Clinical Evaluation — Equivalence: A guide for manufacturers and notified bodies, April 2020.
  3. MDCG 2020-7 — Post-market clinical follow-up (PMCF) Plan Template, April 2020.
  4. MDCG 2023-7 — Guidance on exemptions from the requirement to perform clinical investigations pursuant to Article 61(4)-(6) MDR and on 'sufficient levels of access' to data needed to justify claims of equivalence, December 2023.
  5. EN ISO 14155:2020 + A11:2024 — Clinical investigation of medical devices for human subjects — Good clinical practice.
  6. EN ISO 14971:2019 + A11:2021 — Medical devices — Application of risk management to medical devices.

This post is part of the Clinical Evaluation & Clinical Investigations series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Clinical evidence is a portfolio problem, not a per-device problem — and startups that architect it that way before writing CER-01 save the equivalent of one full clinical evaluation per additional SKU across the lifetime of the product line.