The Challenge
Over the past six years, medical device manufacturers across Europe have faced a common realization: under the EU MDR, technical documentation is no longer a one time submission exercise. It has become a living reflection of how well an organization governs its products over time.
Across different device types — from software driven platforms to complex, connected hardware — many organizations encountered similar problems during EU MDR review. These challenges were rarely caused by missing documents alone. Instead, they reflected deeper issues in how post market signals, clinical evidence, risk management, and change control were connected — or not connected — inside the quality system.
What Was Going Wrong
Two composite examples illustrate patterns seen repeatedly during EU MDR transitions.
In one case, a software intensive product line struggled to keep clinical justification, post market data, and frequent software changes aligned. Updates were happening quickly, but the supporting evidence did not always evolve at the same pace. As a result, reviewers questioned whether current product claims were still fully supported by the available clinical and risk rationale.
In another case, a network connected hardware platform entered MDR review with strong bench testing and standards compliance, yet still faced extended review cycles. Service history, supplier changes, and field performance data existed — but they were managed in separate systems and were slow to influence formal regulatory decisions. Reviewers struggled to see a clear, end to end story explaining how real world use was feeding back into benefit risk conclusions.
Despite their technical differences, both organizations were facing the same underlying problem: their evidence existed, but it was fragmented.
Example 1: Software as a Medical Device (SaMD)
Device profile: AI-enabled cardiac-monitoring platform with cloud analytics, algorithm-supported event detection, mobile workflow components, and clinician review interfaces.
Illustrative EU MDR classification scenario: Often Class IIa, but potentially higher depending on intended purpose and clinical impact.
This composite example reflects a pattern seen in software programs that transitioned from a development-centered compliance model to a full EU MDR lifecycle evidence model. The underlying technical problem was not simply software complexity; instead, the failure point was that software releases, algorithm updates, cybersecurity activities, complaint data, PMCF outputs, and CER maintenance were governed through separate channels and were not consistently traceable back to intended purpose, claims, benefit-risk conclusions, and post-market actions.
Key issues identified:
-
The CER was technically present, but it did not always keep pace with software releases, model adjustments, or evolving product claims, creating visible gaps between marketed functionality and current clinical justification.
-
PMS operated too narrowly around complaints and incidents instead of functioning as a broader, proactive surveillance process that also used trend data, user feedback, software performance signals, and vulnerability intelligence.
-
PMCF was initially underdeveloped or weakly justified, which is a common failure mode when manufacturers rely too heavily on pre-market evidence or literature without a clear strategy for post-market clinical confirmation.
-
Cybersecurity evidence (including vulnerability monitoring, update governance, and security risk controls) was managed as an engineering or IT activity rather than as part of the device’s safety and regulatory evidence set.
-
Change assessments did not always show whether a software update affected intended purpose, clinical claims, usability, interoperability, or the residual risk profile, leaving Notified Body reviewers with incomplete change rationale.
-
Traceability between design controls, risk files, verification and validation, clinical evidence, and Annex II/III technical documentation was incomplete or difficult to follow.
NB review profile: The focus of reviews typically centered on intended purpose and claims consistency, CER sufficiency, PMCF justification and outputs, Annex III PMS evidence, cybersecurity lifecycle controls, software change assessment, and traceability across risk management, verification, and clinical documentation.
Typical review period: Approximately three major deficiency cycles and about 30 months from formal review start to approval.
|
Example 2: Network-Connected Electrical Medical Equipment
Device profile:Infusion pump platform with embedded software, wireless connectivity, serviceable hardware, accessory interfaces, rechargeable power elements, and hospital network interaction.
Illustrative EU MDR classification scenario: Commonly Class IIb, with review emphasis extending well beyond traditional electrical safety testing.
This composite example reflects a pattern seen in connected hardware platforms that entered the EU MDR with strong bench-testing packages but weaker lifecycle integration. IEC 60601 and related verification evidence remained important, but they were not sufficient on their own. The larger issue was that service history, supplier changes, field performance, cybersecurity maintenance, CER updates, PMCF planning, and significant change assessment were often managed in separate systems and were not translated quickly enough into the formal evidence set reviewed by the Notified Body.
Key issues identified:
-
Bench and standards-based evidence existed, but it was not always clearly connected to current CER conclusions, PMS outputs, servicing trends, and benefit-risk acceptability under real-world use conditions.
-
Service records, complaint data, and field corrective information were often stored outside the core PMS and risk review process, delaying escalation of recurring reliability or usability signals.
-
Supplier changes, component obsolescence, and redesigns were frequently handled as operational or engineering events first, with regulatory impact assessment added too late in the process.
-
Network and cybersecurity controls were not always maintained as lifecycle evidence tied to safety, usability, and post-market monitoring, even though connected electrical systems increasingly drew scrutiny under EU MDR Annex I expectations.
-
PMCF strategy was sometimes too generic, especially where manufacturers assumed complaint history and literature alone were enough to support long-term clinical and benefit-risk conclusions.
-
Technical documentation did not always show clean traceability across design changes, supplier controls, risk management, verification and validation, and Annex III post-market outputs.
NB review profile: The review focus typically centered on intended purpose and claims consistency, CER and PMCF linkage, Annex III PMS maturity, service and complaint integration, supplier and change-control evidence, cybersecurity coverage for connected functionality, and traceability across risk management and technical documentation.
Typical review period: Approximately three major deficiency cycles and about 24 months from formal review start to approval.
|
Shared EU MDR Pain Points Across Both Device Types
Although software and electrical devices differ technically, the root causes of difficulties with EU MDR review are often similar: evidence resides in too many places, post-market processes are only partially connected to regulatory decision making, and change control does not reliably trigger updates across the full evidence set.
Shared Problem 1: Fragmented Evidence Systems. In both examples, CER, PMS, PMCF, cybersecurity, servicing, CAPA, risk management, and change records were initially managed as partially separate streams. That fragmentation produced inconsistent rationales, duplicate work, delayed updates, and avoidable traceability gaps during review.
Shared Problem 2: Lifecycle Governance Failures. Both organizations started from a submission-focused mindset in which documents were updated episodically and owned by separate functions. The EU MDR forced a shift toward continuous lifecycle governance, where new signals from the field, suppliers, software changes, and clinical follow-up – rather than isolated document revision – drove coordinated QMS action.
Shared Problem 3: Notified Body Expectations Evolved Rapidly. Review expectations also matured over time. As EU MDR implementation progressed, reviewers increasingly focused on documentation structure, internal consistency, PMS-to-risk linkage, PMCF justification, cybersecurity evidence for connected products, and the quality of significant change assessments rather than on isolated documents alone.
That shift often translated into repeated deficiency rounds, extended stop-the-clock periods, and longer overall review timelines, particularly when the initial submission did not clearly connect Annex II and Annex III content or when remediation required structural QMS changes rather than simple document edits.
What Ultimately Solved the Problems
-
TPLG (Total Product Lifecycle Governance). In both examples, the turning point was a shift to TPLG as the governance and operating model for the product line. It integrated functions horizontally across product teams and vertically through the QMS, enabling Regulatory, Quality, Clinical, Engineering, Cybersecurity, Operations, Service, and Product leadership to review the same lifecycle signals and translate them into coordinated actions across risk management, design controls, PMS, PMCF, CAPA, supplier controls, and technical documentation maintenance.
TPLG established one operating forum per product line for reviewing complaints, service data, PMCF outputs, cybersecurity findings, software and hardware changes, supplier events, benefit-risk shifts, and pending documentation impacts. Its value was not simply more meetings; it was a structured decision path for determining whether a signal required risk reassessment, clinical follow-up, CAPA escalation, verification work, labeling change, or a technical documentation update. In that sense, TPLG was the mechanism that enabled a connected evidence ecosystem.
-
Trigger-Based Documentation Updates. Both examples improved when document maintenance stopped depending on ad hoc author decisions and instead relied on predefined lifecycle triggers tied to QMS processes. Those triggers ensured that complaints, vulnerabilities, software releases, supplier changes, CAPAs, PMCF findings, and other post-market signals consistently prompted the appropriate downstream assessments.
Example Trigger Model
|
Trigger Event |
Required Action |
|
Increased complaints |
PMS + risk review |
|
Cybersecurity vulnerability |
Risk reassessment |
|
Major software release |
CER impact review |
|
Supplier change |
Verification reassessment |
|
CAPA initiation |
Technical documentation review |
|
PMCF signal |
CER update |
This trigger-based approach materially improved lifecycle control, traceability, and review readiness.
-
Connected Evidence Ecosystems. The most effective shift was moving from standalone deliverables to a connected evidence ecosystem – the evidence architecture produced by TPLG – in which design history or medical device file content, risk files, clinical evidence, PMS outputs, and change records could be reviewed as one coherent system for creating and maintaining technical documentation.
Rather than treating complaints, PMCF, CER, cybersecurity, servicing, CAPA, supplier controls, and risk management as separate compliance workstreams, the organizations connected them through TPLG governance, common traceability expectations, and clearer update triggers. The result was a connected evidence ecosystem that was easier to maintain internally and easier for reviewers to navigate externally.
Key EU MDR Lessons Learned
The EU MDR requires manufacturers to maintain proportionate but active post-market systems, current clinical and risk justifications, and evidence flows that can withstand detailed review across the device lifecycle.
|
Lesson |
What It Means |
|
Documentation is now dynamic |
Evidence must be updated as products, risks, and field data evolve |
|
Fragmentation is the biggest risk |
Siloed Quality, Engineering, Clinical, Cybersecurity, and Service data create gaps and delays |
|
TPLG enables the system |
TPLG is the governance model that enables a connected evidence ecosystem across the product line and QMS |
|
Triggers improve control |
Defined trigger events turn signals into timely reviews, updates, and actions |
|
The best performers built interactive systems, not compilations of files |
The strongest organizations operationalized governance, monitoring, and evidence flow |
Final Takeaway
Whether the device is software-driven, electrically complex, or both, the EU MDR has made technical documentation inseparable from lifecycle governance. The regulatory question is no longer whether or not the file is complete; now it is whether the manufacturer can show that claims, risks, clinical evidence, post-market data, and changes remain aligned over time.
The organizations that navigated the EU MDR most effectively were not necessarily those with the shortest original files – they were the ones that built stronger cross-functional governance, treated PMS and PMCF as operational inputs rather than reporting outputs, linked cybersecurity and servicing to patient-safety evidence where relevant, and maintained disciplined traceability across Annex II, Annex III, and core QMS processes.
The primary EU MDR challenge is not producing more documents; it is establishing a governance model such as TPLG that can create and sustain a connected evidence ecosystem that keeps product-line evidence connected, current, justified, and review-ready throughout the life of the device.
Need assistance with your EU MDR implementation or compliance? ELIQUENT Life Sciences can help! We offer a variety of training options and have a team of EU MDR consultants ready and able to assist with any challenges you’re facing.