Medical device Study Guide

📖 Core Concepts Medical Device (US FDA) – Instrument, apparatus, machine, etc., intended for diagnosis, cure, mitigation, treatment or prevention of disease without achieving its primary purpose through chemical action. Medical Device (EU MDR) – Similar to US definition but also includes software and must not act by pharmacological, immunological or metabolic means. Risk Classification – System that groups devices by potential harm; determines level of regulatory control (e.g., US Class I‑III, EU Class I, IIa, IIb, III). Quality Management System (QMS) – Structured set of processes (ISO 13485) ensuring devices are designed, produced, and serviced consistently to meet regulatory and customer requirements. Risk Management (ISO 14971) – Continuous identification, evaluation, control, and monitoring of hazards throughout the device life‑cycle. Notified Body (EU) – Independent, accredited organization that assesses conformity of medium/high‑risk devices and issues certificates of conformity. Unique Device Identification (UDI) – Permanent, machine‑readable identifier that enables traceability of a device from manufacture to patient. Post‑Market Surveillance (PMS) – Ongoing activities (e.g., adverse‑event reporting, trend analysis) required especially for high‑risk devices to ensure continued safety. 📌 Must Remember US regulatory milestones: FD&C Act (1938) → Medical Device Amendments (1976). EU regulatory shift: Directive 93/42/EEC & 90/385/EEC → MDR (Regulation No 2017/745) fully in force 26 May 2021; full application by 26 May 2024. Classification hierarchy: US – Class I (general controls) < Class II (special controls) < Class III (premarket approval). EU – Class I < IIa (short‑term invasive) < IIb (long‑term invasive) < III (high‑risk). ISO 13485 = QMS for medical devices. ISO 14971 = Risk management process. IEC 60601‑1 = Electrical safety & essential performance. IEC 62304 = Software life‑cycle processes. MDR key new requirements: stricter pre‑market clinical evidence, UDI system, enhanced PMS, and higher scrutiny by Notified Bodies. FDA mobile app guidance (2013) – Apps are regulated based on the medical claims they make; updates may trigger new review. Cybersecurity – Must be managed per NIST framework; FDA 2016 non‑binding recommendations apply. AI/ML – No dedicated pathway (as of 2020); FDA proposed framework (Jan 2021) and MDR (May 2021) now address AI/ML software. 🔄 Key Processes Device Classification (US/EU) Determine intended use & invasiveness → assign risk class → identify applicable regulatory controls. Conformity Assessment (EU) Prepare technical documentation → self‑declare for Class I (or certain IIa) → submit to Notified Body for higher classes → receive CE mark & Declaration of Conformity. Risk Management (ISO 14971) Hazard identification → risk estimation → risk evaluation → risk control (protective measures) → residual risk assessment → post‑market monitoring. Quality Management Implementation (ISO 13485) Define QMS scope → document processes → train personnel → conduct internal audits → management review → continuous improvement. Software Development Life‑Cycle (IEC 62304) Planning → requirements → design → implementation → verification → validation → maintenance → retirement. Post‑Market Surveillance (High‑Risk Devices) Collect real‑world performance data → analyze trends → issue field corrective actions → update risk management file. 🔍 Key Comparisons US vs. EU Classification US: 3 classes (I, II, III). EU: 4 classes (I, IIa, IIb, III). Regulatory Pathway for Software US: FDA guidance (2013) + 2025 draft guidance; classification based on claim. EU: MDR (2021) includes AI/ML requirements; CE marking via Notified Body. Notified Body (EU) vs. FDA Review (US) EU: Third‑party assessment for Class IIa‑III; issue certificate of conformity. US: FDA directly reviews pre‑market submissions (510(k), PMA) for Class II‑III. ISO 13485 vs. ISO 9001 ISO 13485: Focused on regulatory compliance & risk; no continuous improvement clause. ISO 9001: General QMS, emphasizes customer satisfaction & improvement. ⚠️ Common Misunderstandings “All medical devices need FDA approval.” – Only Class II/III (or Class I with special controls) require pre‑market submission; many Class I devices are exempt. “MDR only affects new devices.” – Existing devices certified under the old directives must be re‑certified by 26 May 2024. “If a device is software, ISO 14971 does not apply.” – Software hazards (e.g., incorrect algorithm output) are covered by ISO 14971 and IEC 62304. “UDI is optional.” – Under MDR (EU) and FDA’s UDI rule, a unique identifier is mandatory for most devices placed on the market after the compliance dates. “Cybersecurity can be added after launch.” – Risk must be assessed early; retrofitting security may compromise battery life, size, and cost. 🧠 Mental Models / Intuition “Risk → Controls → Evidence” – Higher risk → more stringent controls (design, testing, clinical evidence) → stronger regulatory documentation. “Regulation as a Funnel” – Device starts broad (concept) → classification narrows the path (self‑declaration vs. Notified Body vs. FDA PMA). “Safety = Hazard + Controls” – Think of each hazard as a “leak” that must be plugged (risk control) and then monitored (PMS). 🚩 Exceptions & Edge Cases Class I devices with “special controls” (e.g., sterile surgical gloves) require FDA 510(k) despite low risk. EU “Rule‑based” classification – Certain devices (e.g., active implantable) automatically fall into Class III regardless of invasiveness. Software as a Medical Device (SaMD) – May be classified based on intended use and risk even if the hardware is low‑risk. Compounded devices – Custom‑made devices for a specific patient may be exempt from some MDR requirements but still need to meet safety standards. 📍 When to Use Which Choose US vs. EU pathway – If marketing in both regions, design to meet the stricter of the two (usually EU MDR). Select ISO standard – Use ISO 13485 for QMS; add ISO 14971 for risk; IEC 60601‑1 for electrical safety; IEC 62304 for software. Determine need for Notified Body – Required for any EU device classified IIa (except certain low‑risk), IIb, or III. Apply FDA mobile app guidance – If the app claims diagnostic or therapeutic benefit, treat it as a device; otherwise, it may be exempt. 👀 Patterns to Recognize Invasiveness + Duration → Higher EU class (short‑term ≤30 days → IIa; long‑term >30 days → IIb). “Implantable + Active” → EU Class III (e.g., pacemaker). Claims of “treating disease” → FDA regulatory trigger (even for a simple algorithm). Presence of patient data transmission → cybersecurity risk tier assessment. 🗂️ Exam Traps Confusing US Class II with EU Class IIa – Remember the EU has two middle classes; a “moderate‑risk” device may be IIa or IIb depending on invasiveness and duration. Assuming all software is exempt from ISO 14971 – Software hazards are explicitly covered; omission leads to non‑compliance. Overlooking UDI requirement for legacy devices – Devices placed on the market after MDR compliance dates must have a UDI even if previously approved. Misreading “special controls” as optional – Certain Class I devices are subject to FDA‑mandated special controls; ignoring them can invalidate a submission. Thinking post‑market surveillance is only for recalls – PMS is a continuous obligation for high‑risk devices, not just a reaction to problems. --- Use this guide for a rapid, confidence‑building review before your exam. Focus on the bolded keywords, understand the flow from risk → classification → regulatory path, and watch out for the common traps highlighted.