Skill Guide

Regulatory awareness: FDA SaMD, EU MDR, and IEC 62304 software lifecycle standards

The competency to interpret, apply, and ensure compliance with the distinct regulatory pathways and technical standards governing the development and market authorization of software used as, or within, a medical device across major global markets.

This skill mitigates significant commercial and legal risk by ensuring products can legally enter and remain in key markets like the US and EU, directly impacting time-to-market, total cost of development, and long-term liability exposure.

1 Careers

1 Categories

9.1 Avg Demand

15% Avg AI Risk

How to Learn Regulatory awareness: FDA SaMD, EU MDR, and IEC 62304 software lifecycle standards

1. Master core terminology: SaMD (Software as a Medical Device), IVD (In Vitro Diagnostics), risk classification (FDA Class I/II/III, EU MDR Class I/IIa/IIb/III). 2. Understand the fundamental purpose of each standard: FDA's Total Product Lifecycle (TPLC) approach for SaMD, the EU MDR's essential requirements and conformity assessment routes, and IEC 62304's role in defining software development lifecycle processes and documentation. 3. Develop a habit of tracing every design and test decision to a specific regulatory requirement.

Move from theory to practice by creating a compliance mapping matrix linking your product's intended use and risk classification to specific clauses in FDA guidance, EU MDR Annexes, and IEC 62304. Common mistake: Treating IEC 62304 as a checklist rather than a risk-based lifecycle framework, leading to over-documentation of low-risk components and under-specification of high-risk ones.

Master the skill by architecting multi-market regulatory strategies, such as leveraging a clinical evaluation report (CER) for both EU MDR and FDA Pre-Submission. Lead cross-functional teams to implement a Quality Management System (QMS) under ISO 13485 that seamlessly integrates with the software lifecycle processes defined in IEC 62304, managing dependencies between design controls, risk management (ISO 14971), and post-market surveillance.

Practice Projects

Beginner

Case Study/Exercise

Regulatory Pathway Identification

Scenario

You are presented with a concept for a mobile app that uses a phone's camera and algorithm to track moles for changes, providing a risk score but not a diagnosis.

How to Execute

1. Use FDA's SaMD categorization framework to determine its risk category based on the significance of the information provided (health status vs. clinical decision) and the seriousness of the condition. 2. Classify it under EU MDR Annex VIII rules, applying Rule 11 for software. 3. Draft a one-page summary outlining the required regulatory pathway (e.g., FDA De Novo or 510(k)) and EU MDR conformity route (e.g., Annex IX, Chapter II).

Intermediate

Project

IEC 62304 Documentation for a High-Risk Module

Scenario

Your team is developing a SaMD with a high-risk (Class C) software module responsible for calculating a drug dosage recommendation.

How to Execute

1. Create a Software Development Plan (SDP) for the module citing IEC 62304 clauses. 2. Develop a detailed Software Requirements Specification (SRS) tracing each requirement to a system requirement and risk control measure. 3. Define the Software Architecture Design (SAD), specifying interfaces and segregation of duties. 4. Produce a verification and validation plan for the module, demonstrating traceability from requirements to test cases.

Advanced

Case Study/Exercise

Post-Market Surveillance and Change Management

Scenario

A SaMD on the EU market has a cybersecurity vulnerability discovered post-launch. A minor algorithm update is also planned to improve accuracy.

How to Execute

1. Apply EU MDR's post-market surveillance plan to evaluate if the vulnerability constitutes a serious incident or a field safety corrective action (FSCA). 2. Use the FDA's 'Deciding When to Submit a 510(k) for a Software Change to an Existing Device' guidance to assess if the algorithm update and cybersecurity patch require a new submission. 3. Document the change management decision, including a risk-benefit analysis and updated regulatory impact assessment, in the Technical File and DHF (Design History File).

Tools & Frameworks

Regulatory Guidance & Standards

FDA: 'Software as a Medical Device (SaMD): Clinical Evaluation' guidanceEU MDR (2017/745) and relevant MEDDEV/ MDCG guidance documentsIEC 62304:2006/AMD1:2015 Medical device software - Software life cycle processes

Primary source documents for compliance. Applied during design input, risk classification, and verification/validation planning to define mandatory requirements and acceptable practices.

Quality & Risk Management Systems

ISO 13485:2016 Quality Management SystemISO 14971:2019 Application of risk management to medical devicesISTQB or similar software testing certifications

Foundational frameworks for the overarching QMS and risk management process. IEC 62304 implementation is a subset of an ISO 13485-compliant QMS. ISO 14971 provides the methodology for risk analysis that feeds into software requirements.

Interview Questions

Answer Strategy

Contrast the US 'predetermined change control plan' (PCCP) concept for adaptive algorithms with the EU's stricter pre-market clinical evaluation and ongoing performance monitoring. Highlight that FDA focuses on the analytical and clinical validation of the algorithm's output, while EU MDR emphasizes clinical performance and safety throughout the entire lifecycle under Annex XIV. Sample answer: 'The FDA SaMD framework is product-centric, using risk-based categorization to determine evidence needs and proposing PCCP for certain AI/ML updates. The EU MDR applies a more holistic, lifecycle-centric approach under ISO 13485, requiring a Clinical Evaluation Report (CER) with ongoing PMCF studies to demonstrate continuous conformity, irrespective of the update type.'

Answer Strategy

Tests the candidate's application of post-market surveillance, vigilance reporting, and QMS integration. A strong answer follows a structured process: 1) Containment & Investigation: Quarantine the issue, log in the CAPA system, and perform root cause analysis per ISO 13485. 2) Risk Assessment: Use ISO 14971 to evaluate if this constitutes a decrease in safety or performance. 3) Reporting: Determine if it meets the threshold for a Field Safety Corrective Action (FSCA) and a report to the Competent Authority via the EU MDR vigilance system (MEDDEV 2.12/2). 4) Corrective Action: Implement and validate the fix, update the risk management file and Technical File.