惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Google DeepMind News
Google DeepMind News
D
Docker
Last Week in AI
Last Week in AI
WordPress大学
WordPress大学
月光博客
月光博客
小众软件
小众软件
量子位
V
Visual Studio Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
T
Tailwind CSS Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
罗磊的独立博客
博客园 - 叶小钗
美团技术团队
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Apple Machine Learning Research
Apple Machine Learning Research
博客园 - 三生石上(FineUI控件)
博客园 - 聂微东
博客园 - 司徒正美
Microsoft Azure Blog
Microsoft Azure Blog
博客园 - Franky
Hugging Face - Blog
Hugging Face - Blog
GbyAI
GbyAI
C
Check Point Blog

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
CE marking under MDR — what's actually new, and what team...
Priya Nair · 2026-05-15 · via DEV Community

Priya Nair

I’ve spent the last five years shepherding Class IIa/IIb Technical Files through audits, answering notified‑body questions at odd hours, and patching gaps that only show up under Annex II scrutiny. To be fair, MDR’s intent — strengthen clinical evidence, tighten post‑market vigilance, raise the bar on documentation — is sensible. In practice this means more paperwork, but also clearer expectations if you stop treating CE as a tick‑box.

Here’s what is genuinely new under MDR, and where I see teams repeatedly going wrong.

What is actually new (or newly emphasised)

  • PRRC (Article 15): You must have a Person Responsible for Regulatory Compliance with demonstrable expertise. This is not optional. In practice that means named responsibility, documented qualifications and visibility in your QMS.
  • Stronger clinical requirements (Annex XIV): Clinical evaluation and Post‑Market Clinical Follow‑up (PMCF) are more demanding. Notified bodies now expect an evidence continuum — pre‑market clinical data, ongoing PMCF and periodic updates to the clinical evaluation report.
  • Technical documentation expectations (Annex II): The Technical File needs to explicitly show conformity to the General Safety and Performance Requirements (Annex I). Traceability between requirements, risk controls, verification/validation and clinical evidence is inspected in detail.
  • Classification vigilance (Annex VIII): Devices get re‑classified more often under MDR rules (software and rule changes, notably). You can’t assume legacy classification still applies.
  • Post‑market system and reporting: PMS plans, continuous vigilance and Periodic Safety Update Reports are under closer review. The system is now a live obligation, not an annual add‑on.
  • Implant cards and labelling: For implantable devices there are prescriptive requirements for what must be provided to patients and healthcare professionals (Article 18).
  • UDI and EUDAMED readiness: UDI is mandated; EUDAMED and actor registration are the channels for transparency. Whether your team enters data or your regulator will find it, you still carry the duty.

What teams still get wrong

  • “We just need more clinical studies.” Not always. Randomised controlled trials are ideal in some contexts but not required for every device. Annex XIV asks for appropriate clinical evidence and a demonstration that benefit–risk is acceptable. Appropriate can be bench tests, bench+clinical, post‑market data — justified and well‑documented.
  • “Equivalence is simple.” Equivalence claims are heavily scrutinised. Notified bodies want comparative technical, biological and clinical justification — plus evidence you control the manufacturing and post‑market data of the equivalent device. In practice, relying on a competitor’s data without strong comparability is a dead end.
  • “Harmonised standards = automatic compliance.” Harmonised standards give a presumption of conformity, but you must still demonstrate their proper application and address any residual risks per Annex I.
  • “We can delay PMCF.” PMCF is part of clinical evaluation under Annex XIV: it’s proactively expected, proportionate to risk, and should be planned. Saying “we’ll do it later” raises flags at audit.
  • “A CE certificate is forever.” Certificates have validity, surveillance, and re‑assessment triggers (major changes, significant incidents). Treat them as conditional, not permanent.
  • “EUDAMED will sort transparency for us.” Don’t rely on EUDAMED as a safety net. Your PMS, vigilance reporting and UDI duties stay with you; a database is a tool, not a compliance strategy.

Practical steps that actually survive an audit

  • Map Annex I to your product: create a Requirements‑to‑Evidence matrix linking each Annex I requirement to risk controls, verification activities and supporting clinical data. This is the single best control for Annex II audits.
  • Formalise your PRRC role: include a job description, qualifications record and documented responsibilities in your QMS. Auditors ask for this explicitly (Article 15).
  • Treat clinical evaluation as iterative: maintain a living Clinical Evaluation Report (CER) and PMCF plan. Record the rationale when you decide observational PMCF is sufficient versus a prospective clinical study.
  • Use a traceability tool: whether an eQMS or a simple spreadsheet, ensure traceability across change control, CAPA, risk management and technical documentation. Connected workflow reduces audit surprises and speeds up evidence retrieval.
  • Be explicit on equivalence: if you claim equivalence, document the technical, clinical and manufacturing comparators, plus a justification for using their data. If you can’t, plan your own clinical evidence pathway.
  • Integrate PMS outputs into CER: post‑market data should feed clinical evaluation and risk management. Make the loop visible — incident → investigation → CAPA → risk assessment → CER update.

A final, practical note on QMS tooling

An eQMS that supports automated CAPAs, traceability and change impact analysis is not a silver bullet, but it makes life far easier. Look for native workflow integration between document control, risk, CAPA and Technical File modules — being able to pull a traceability report in seconds is worth the subscription for teams approaching a notified‑body audit.

What single MDR requirement gives your team the most trouble in audits — PRRC, clinical evaluation/PMCF, Annex II traceability, or something else?