The Claim That Breaks Medical Device Technical File

Introduction

If you’ve felt Notified Bodies (NBs) pushing harder on “device lifetime” under EU MDR, you’re not imagining it. MDR doesn’t just ask whether a device is safe and performs on Day 1, it requires manufacturers to show that safety and performance are maintained for the entire lifetime the manufacturer claims, under normal use and maintenance. 

That single concept touches everything: design inputs, verification testing, risk management, IFU content, post-market surveillance, and (for reusable devices) reprocessing and ageing. 

The Regulatory Anchor: MDR Annex I, GSPR 6

MDR Annex I (General Safety and Performance Requirements) includes a very direct requirement: 

The characteristics and performance of a device must not be adversely affected to a degree that compromises health/safety during the lifetime of the device, as indicated by the manufacturer, when subjected to stresses from normal use and properly maintained per the manufacturer’s instructions.  

Two immediate implications fall out of that: 

1. You must define a lifetime (“as indicated by the manufacturer”). If you don’t, you can’t demonstrate compliance to the requirement. 
2. The lifetime claim must be supported by evidence that covers the stresses the device will actually see, including maintenance activities and, for reusables, reprocessing stresses. 

MDR also frames risk management as a lifecycle activity and explicitly includes reasonably foreseeable misuse as something manufacturers must consider. That matters because many lifetime failures happen in the grey zone between “perfect use” and real-world handling. 

What Counts as “Lifetime” (and Why “Indefinite” is a Red Flag)

A consistent theme across NB guidance is that undefined or indefinite lifetime claims are a common pitfall. 

Team-NB (the European Association of Medical devices Notified Bodies) explicitly flags this in its technical documentation guidance: pitfall = lifetime not defined / claimed indefinite; guidance = manufacturers must define lifetime in quantitative or otherwise appropriate terms. 

Their position paper goes further: it links lifetime definition to the risk management obligation to ensure risk controls remain effective across the claimed period. 

Useful definitions (that NBs recognise) 

Several internationally used definitions align on the same idea: 

• ISO 20417 defines expected lifetime / expected service life as the time period specified by the manufacturer during which the device is expected to remain safe and effective for use.  

• IMDRF uses the same core definition and adds context (e.g., lifetime can be influenced by stability, maintenance, upgrades).  

So practically: lifetime is not what you hope the device might survive — it’s what you claim, and therefore what you must support.

Where the Lifetime Must Show Up: Technical Documentation + IFU Alignment

NBs will typically expect lifetime to be visible and consistent across: 

1. Technical documentation (design and risk rationale, verification/validation evidence, acceptance criteria). 
2. Labelling / IFU (what the user must do, how many uses/cycles are permitted, how to identify end-of-life). 

For reusable devices specifically, external guidance built around EN ISO 17664 highlights a critical IFU expectation: if processing causes degradation, the IFU should include “the number of reprocessing cycles that can normally be tolerated” or an “end-of-life criterion”. 

That’s the bridge between “lifetime as a claim” and “lifetime as something a user can actually manage.” 

How Notified Bodies Tend to Assess Lifetime: The Evidence Logic

It’s about whether your technical file tells a coherent, defensible story: 

1. Define lifetime in meaningful, measurable terms 

Team-NB guidance is explicit that lifetime can be expressed as: 

• Years / months / days, or 
• Number of uses / cycles, or 
• Relative terms (commonly for software, e.g., time to next update).  

For reusable devices, NBs typically expect a cycle-based service life (e.g., “validated for X reprocessing cycles”) and clarity on what those cycles represent in real use. 

2. Show that “normal stresses” are genuinely covered 

GSPR 6 is about stresses during normal use + proper maintenance. 
For reusable devices, “normal stresses” routinely include: 

• Mechanical wear (hinges, cutting edges, seals) 
• Chemical exposure (detergents, disinfectants, residues) 
• Thermal exposure (washer-disinfector temperatures, steam sterilisation) 
• Corrosion, staining, coating breakdown 
• Repeated assembly/disassembly, brushing, flushing, lumen processing 

NBs will look for evidence that your test plan reflects worst-case design features and worst-case processing, not best-case. 

3. Make lifetime a design input, not an afterthought 

The cleanest technical files treat lifetime as a design input (“expected service life = X uses/cycles/years”) and then show design outputs and V&V that demonstrate the device meets requirements throughout that lifetime. 

This aligns with the MDCG view embedded in PMCF guidance: expected lifetime should be defined during the design input phase, considering the current state of the art for the intended use.  

4. Tie lifetime to clinical evaluation and PMCF (where relevant) 

Team-NB’s annex II technical documentation guidance makes the connection explicit: a clear device lifetime helps the assessor judge whether your clinical data and/or PMCF plan are appropriate for the claimed duration. 

And on the post-market side, MDCG PSUR guidance discusses lifetime in practical terms for how long PSUR expectations may extend after last placement on the market (i.e., shelf life + intended lifetime examples).  

The “Classic” Lifetime Mistakes That Trigger NB Pushback

These show up again and again in assessments: 

1. No lifetime stated anywhere meaningful (or only implied). 
2. “Unlimited” / “indefinite” lifetime without a defensible mechanism to ensure safety/performance forever (Team-NB flags this as a pitfall).  
3. Mismatch between IFU and evidence (e.g., IFU implies repeated reuse, but no cycle validation; or testing done for fewer cycles than claimed). 
4. No end-of-life criteria (nothing the user can inspect/measure to retire the device) even though processing causes degradation.  
5. Reprocessing not treated as a lifetime stressor (testing focuses on function, but ignores cleaning/disinfection/sterilisation impacts). 
6. Legacy devices relying on “we’ve always done it this way” without a structured lifetime justification supported by PMS/complaints/field data and targeted verification. 

A Practical Checklist for a Stronger “Device Lifetime” Section in Your Technical File

If you want this to read cleanly for an NB assessor, your lifetime package should make these points easy to find: 

• Lifetime definition (years and/or cycles/uses; include assumptions). 
• Rationale for that lifetime (materials, intended use, SOTA, comparable devices where appropriate). 
• Maintenance & inspection requirements (what the user must do to keep the device within safe performance; how this is communicated). 
• End-of-life criteria (objective retire/replace triggers; aligned with IFU).  
• Verification/validation evidence that covers lifetime stresses (including reprocessing/ageing for reusables). 
• Risk management linkage (how hazards change with ageing; confirmation that controls remain effective across lifetime).  
• Clinical evaluation / PMCF alignment (where clinical evidence needs to cover long-term performance, durability, or degradation).  
• Post-market plan that can detect emerging lifetime-related failure modes early (trend, complaints, service/repair data, returned goods).