What Is IEC 62304? Medical Device Software Guide

Full announcement (unchanged)

What Is IEC 62304? A Guide to Medical Device Software Follow a manual added link Follow a manual added link The Essential Guide to Requirements Management and Traceability Follow a manual added link The Essential Guide to Requirements Management and Traceability Chapters • 1. Requirements Management • Overview • 1 What is Requirements Management? A Complete Guide • 2 Why Do You Need Requirements Management? • 3 Four Stages of Requirements Management Processes • 4 Adopting Agile Requirements Management Tools • 5 Status Request Changes • 6 Conquering the 5 Biggest Challenges of Requirements Management • 7 Three Reasons You Need a Requirements Management Solution • 8 Guide to Poor Requirements: Identify Causes, Repercussions, and How to Fix Them • 9 What Is a Requirements Management Plan? A Practical Guide • 10 Enterprise Requirements Management: Keeping Traceability Current • 2. Writing Requirements • Overview • 1 Functional Requirements Examples and Templates • 2 What Is a Product Requirements Document? A Complete PRD Guide • 3 What Is a User Requirement Specification (URS)? How to Write and Manage One • 4 Identifying and Measuring Requirements Quality • 5 How to Write a System Requirements Specification (SRS) Document • 6 The Fundamentals of Business Requirements: Examples of Business Requirements and the Importance of Excellence • 7 Adopting the EARS Notation to Improve Requirements Engineering • 8 What Is a Compliance Risk Assessment? Steps, Framework, and Examples • 9 Jama Connect Advisor™ • 10 How to Write an Effective Product Requirements Document (PRD) • 11 Functional vs. Non-Functional Requirements • 12 What Are Nonfunctional Requirements and How Do They Impact Product Development? • 13 What Is a Software Design Specification? Key Components + Template • 14 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS) • 15 8 Do’s and Don’ts for Writing Requirements • 16 Project Requirements: Types, Process, and Best Practices • 17 INCOSE Guide to Writing Requirements • 18 How to Write Technical Requirements That Survive Verification • 19 Types of Requirements in Engineering: A Complete Guide • 3. Requirements Gathering and Management Processes • Overview • 1 Requirements Engineering • 2 Requirements Analysis • 3 A Guide to Requirements Elicitation for Product Teams • 4 Requirements Gathering Techniques for Agile Product Teams • 5 Requirements Gathering in Software Engineering: Process, Techniques, and Best Practices • 6 Defining and Implementing a Requirements Baseline • 7 Managing Project Scope — Why It Matters and Best Practices • 8 Requirements Decomposition and How AI Supports It • 9 How Long Do Requirements Take? • 10 How to Reuse Requirements Across Multiple Products • 11 Requirements Prioritization Techniques: 7 Methods for Engineers • 12 How to Run a Requirements Gathering Workshop • 4. Requirements Traceability • Overview • 1 What Is Traceability? A Guide for Regulated Product Teams • 2 Tracing Your Way to Success: The Crucial Role of Traceability in Modern Product and Systems Development • 3 Bidirectional Traceability: What It Is and How to Implement It • 4 Change Impact Analysis (CIA): A Short Guide for Effective Implementation • 5 What is Engineering Change Management (ECM)? A Complete Guide • 6 What is Meant by Version Control? • 7 Key Traceability Challenges and Tips for Ensuring Accountability and Efficiency • 8 The Role of a Data Thread in Product and Software Development • 9 What is a Traceability Matrix? A Guide to Requirements Traceability • 10 How to Create and Use a Requirements Traceability Matrix (RTM) • 11 Requirements Traceability Matrix Pros and Cons: A Practical Guide • 12 Live Traceability vs. After-the-Fact Traceability • 13 Requirements Traceability, What Are You Missing? • 14 Requirements Traceability: Links in the Chain • 15 What Are the Benefits of End-to-End Traceability During Product Development? • 16 Requirements Volatility: 7 Essential Management Strategies • 17 FAQs About Requirements Traceability • 18 What Is AI Traceability? How to Implement It • 19 Product Traceability for Regulated Industries: A Complete Guide to Audit-Ready Compliance • 20 What Is the Traceability Information Model? • 21 Supply Chain Traceability: What to Send Suppliers and What to Get Back • 22 What Is an Engineering Change Order (ECO)? • 5. Solutions for Capturing and Tracking Requirements • Overview • 1 Selecting the Right Requirements Management Tools • 2 Why Investing in Requirements Management Software Makes Business Sense During an Economic Downturn • 3 Why Word and Excel Alone is Not Enough for Product, Software, and Systems Development • 4 Can You Track Requirements in Excel? • 5 What Is Application Lifecycle Management (ALM)? • 6 Requirements Management Tools Jira • 7 Requirements Management Checklist: Selecting the Right Tool • 6. Requirements Validation and Verification • Overview • 1 Requirements Verification and Validation for Product Teams • 2 Best Practices for Verification and Validation in Product Development • 3 Requirement Validation and Traceability Explained • 4 What Is System Integration Testing (SIT)? A Complete Guide • 7. Meeting Regulatory Compliance and Industry Standards • Overview • 1 Understanding ISO Standards • 2 Understanding ISO/IEC 27001: A Guide to Information Security Management • 3 What is DevSecOps? A Guide to Building Secure Software • 4 Compliance Management • 5 What Is Functional Safety (FuSa)? Standards, Lifecycle, and Where Programs Fail • 6 Failure Mode and Effects Analysis (FMEA) Explained • 7 TÜV SÜD: Ensuring Safety, Quality, and Sustainability Worldwide • 8 What Is IEC 62443? A Complete Guide to Industrial Cybersecurity • 9 DFARS Compliance: A Guide for Defense Contractors • 10 CMMC vs FedRAMP: What’s Different and Which One Applies to You • 11 Automotive SPICE (ASPICE) 4.0: A Complete Guide • 12 Restriction of Hazardous Substances (RoHS) Compliance Guide • 13 MISRA C and MISRA C++ Explained: Rules for Safer Embedded Code • 14 REACH Compliance for Product Engineering Teams • 15 Radio Equipment Directive (RED) Cybersecurity Requirements • 16 What Is a Software Bill of Materials? • 8. Systems Engineering • Overview • 1 What is Systems Engineering? A Guide for Modern Engineering Teams • 2 How Do Engineers Collaborate? A Guide to Streamlined Teamwork and Innovation • 3 The Systems Engineering Body of Knowledge (SEBoK) • 4 What Is MBSE? Model-Based Systems Engineering Explained • 5 Digital Engineering Between Government and Contractors • 6 Digital Engineering Tools: The Key to Driving Innovation and Efficiency in Complex Systems • 7 What Is Bill of Materials (BOM) Management? A Guide to Controlling Product Data • 9. Automotive Development • Overview • 1 Understanding IATF 16949: A Quick Guide to Automotive Quality Management • 2 What Is ISO 21434? Automotive Cybersecurity Engineering Explained • 3 What Is an Automotive Safety Integrity Level (ASIL)? • 4 What Is SOTIF? A Guide to ISO 21448 for ADAS Safety • 10. Medical Device & Life Sciences Development • Overview • 1 The Importance of Benefit-Risk Analysis in Medical Device Development • 2 Software as a Medical Device: Revolutionizing Healthcare • 3 Navigating the Risks of Software of Unknown Pedigree (SOUP) in the Medical Device & Life Sciences Industry • 4 What’s a Design History File, and How Are DHFs Used by Product Teams? • 5 What Is ISO 13485? A Guide to Medical Device Quality Management Systems • 6 What Is IEC 62304? A Guide to Medical Device Software • 7 What Is a Device Master Record (DMR)? Definition and FDA Requirements • 8 Failure Modes, Effects, and Diagnostic Analysis (FMEDA) for Medical Devices: What You Need to Know • 9 Embracing the Future of Healthcare: Exploring the Internet of Medical Things (IoMT) • 10 What Is General Safety and Performance Requirements (GSPR)? What You Need To Know • 11 What Is IEC 62366? Usability Engineering for Medical Devices • 12 What Is the Quality Management System Regulation (QMSR)? • 13 510(k) vs PMA: Differences in FDA Device Approval and Clearance • 14 EU MDR Compliance Requirements and Timeline • 15 Essential Performance Requirements and How to Identify Them • 16 DHF vs DMR vs DHR: What Changed Under the FDA QMSR • 17 Computer Software Assurance for Production and Quality Systems • 18 IVDR Compliance: What Manufacturers Need to Know • 19 IVDR Compliance: What Manufacturers Need to Know (copy) • 20 IEC 60601-1 Guide for Medical Devices • 21 A Guide to Medical Device Requirements Management • 11. Aerospace & Defense Development • Overview • 1 What is ITAR Compliance? What Engineering Teams Need to Know • 2 What Is DO-278A? A Guide for Compliance Teams • 3 ARP4754B Explained: Changes, Recognition, and Compliance • 4 What Is a Safety Integrity Level (SIL)? How to Calculate and Apply It • 5 A Guide to Aerospace Requirements Management • 6 What Is ARP4754A? A Complete Guide to Civil Aircraft and Systems Development Assurance • 7 Understanding ARP4761A: Guidelines for System Safety Assessment in Aerospace • 8 What Is DO-254? A Complete Guide to Airborne Hardware Design Assurance • 9 What Is DO-178C? A Guide to Airborne Software Certification • 12. Architecture, Engineering, and Construction (AEC industry) Development • Overview • 1 What is the AEC Industry? • 13. Industrial Manufacturing & Machinery, Automation & Robotics, Consumer Electronics, and Energy • Overview • 1 What Is IEC 61508? A Guide to the Functional Safety Standard • 2 Understanding ISO 13849: The Foundation of Functional Safety in the Machinery Sector • 3 IEC 62061 – Functional Safety for Machinery Systems • 4 ISO 10218: Ensuring Safety in Industrial Robotics • 14. Semiconductor Development • Overview • 1 Why Chiplets Are Changing the Game in Tech Innovation • 2 Integrating Digital Engineering and the Digital Thread for Semiconductor Design • 15. AI in Product Development • Overview • 1 What Is AI in Product Development? A Complete 2026 Guide • 2 AI Test Case Generation: A Complete Guide for Regulated QA Teams • 3 Using AI to Write Software Requirements: What Works and What Doesn’t • 4 What Is the Model Context Protocol (MCP) for Requirements Management? • 5 AI for Systems Engineering: Benefits, Risks, and How to Start • 6 How to Automate Requirements Management • 16. Risk Management • Overview • 1 What Are Failure Modes? Types, Examples, and How to Identify Them • 2 What Is Software Risk Management? • 3 What Is a Risk Assessment Matrix? How to Build and Use One • 4 Types of FMEA: Definitions, Differences, and When to Use Each • 5 DFMEA vs PFMEA: Scope, Timing, and the Handoff Between Them • 17. Product Development Terms and Definitions • Overview • 1 Concurrent Engineering: Benefits, Challenges, and Best Practices • 2 eBOM vs mBOM: Differences and When Each Matters Chapter 10: What Is IEC 62304? A Guide to Medical Device Software Chapters • 1. Requirements Management • Overview • 1 What is Requirements Management? A Complete Guide • 2 Why Do You Need Requirements Management? • 3 Four Stages of Requirements Management Processes • 4 Adopting Agile Requirements Management Tools • 5 Status Request Changes • 6 Conquering the 5 Biggest Challenges of Requirements Management • 7 Three Reasons You Need a Requirements Management Solution • 8 Guide to Poor Requirements: Identify Causes, Repercussions, and How to Fix Them • 9 What Is a Requirements Management Plan? A Practical Guide • 10 Enterprise Requirements Management: Keeping Traceability Current • 2. Writing Requirements • Overview • 1 Functional Requirements Examples and Templates • 2 What Is a Product Requirements Document? A Complete PRD Guide • 3 What Is a User Requirement Specification (URS)? How to Write and Manage One • 4 Identifying and Measuring Requirements Quality • 5 How to Write a System Requirements Specification (SRS) Document • 6 The Fundamentals of Business Requirements: Examples of Business Requirements and the Importance of Excellence • 7 Adopting the EARS Notation to Improve Requirements Engineering • 8 What Is a Compliance Risk Assessment? Steps, Framework, and Examples • 9 Jama Connect Advisor™ • 10 How to Write an Effective Product Requirements Document (PRD) • 11 Functional vs. Non-Functional Requirements • 12 What Are Nonfunctional Requirements and How Do They Impact Product Development? • 13 What Is a Software Design Specification? Key Components + Template • 14 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS) • 15 8 Do’s and Don’ts for Writing Requirements • 16 Project Requirements: Types, Process, and Best Practices • 17 INCOSE Guide to Writing Requirements • 18 How to Write Technical Requirements That Survive Verification • 19 Types of Requirements in Engineering: A Complete Guide • 3. Requirements Gathering and Management Processes • Overview • 1 Requirements Engineering • 2 Requirements Analysis • 3 A Guide to Requirements Elicitation for Product Teams • 4 Requirements Gathering Techniques for Agile Product Teams • 5 Requirements Gathering in Software Engineering: Process, Techniques, and Best Practices • 6 Defining and Implementing a Requirements Baseline • 7 Managing Project Scope — Why It Matters and Best Practices • 8 Requirements Decomposition and How AI Supports It • 9 How Long Do Requirements Take? • 10 How to Reuse Requirements Across Multiple Products • 11 Requirements Prioritization Techniques: 7 Methods for Engineers • 12 How to Run a Requirements Gathering Workshop • 4. Requirements Traceability • Overview • 1 What Is Traceability? A Guide for Regulated Product Teams • 2 Tracing Your Way to Success: The Crucial Role of Traceability in Modern Product and Systems Development • 3 Bidirectional Traceability: What It Is and How to Implement It • 4 Change Impact Analysis (CIA): A Short Guide for Effective Implementation • 5 What is Engineering Change Management (ECM)? A Complete Guide • 6 What is Meant by Version Control? • 7 Key Traceability Challenges and Tips for Ensuring Accountability and Efficiency • 8 The Role of a Data Thread in Product and Software Development • 9 What is a Traceability Matrix? A Guide to Requirements Traceability • 10 How to Create and Use a Requirements Traceability Matrix (RTM) • 11 Requirements Traceability Matrix Pros and Cons: A Practical Guide • 12 Live Traceability vs. After-the-Fact Traceability • 13 Requirements Traceability, What Are You Missing? • 14 Requirements Traceability: Links in the Chain • 15 What Are the Benefits of End-to-End Traceability During Product Development? • 16 Requirements Volatility: 7 Essential Management Strategies • 17 FAQs About Requirements Traceability • 18 What Is AI Traceability? How to Implement It • 19 Product Traceability for Regulated Industries: A Complete Guide to Audit-Ready Compliance • 20 What Is the Traceability Information Model? • 21 Supply Chain Traceability: What to Send Suppliers and What to Get Back • 22 What Is an Engineering Change Order (ECO)? • 5. Solutions for Capturing and Tracking Requirements • Overview • 1 Selecting the Right Requirements Management Tools • 2 Why Investing in Requirements Management Software Makes Business Sense During an Economic Downturn • 3 Why Word and Excel Alone is Not Enough for Product, Software, and Systems Development • 4 Can You Track Requirements in Excel? • 5 What Is Application Lifecycle Management (ALM)? • 6 Requirements Management Tools Jira • 7 Requirements Management Checklist: Selecting the Right Tool • 6. Requirements Validation and Verification • Overview • 1 Requirements Verification and Validation for Product Teams • 2 Best Practices for Verification and Validation in Product Development • 3 Requirement Validation and Traceability Explained • 4 What Is System Integration Testing (SIT)? A Complete Guide • 7. Meeting Regulatory Compliance and Industry Standards • Overview • 1 Understanding ISO Standards • 2 Understanding ISO/IEC 27001: A Guide to Information Security Management • 3 What is DevSecOps? A Guide to Building Secure Software • 4 Compliance Management • 5 What Is Functional Safety (FuSa)? Standards, Lifecycle, and Where Programs Fail • 6 Failure Mode and Effects Analysis (FMEA) Explained • 7 TÜV SÜD: Ensuring Safety, Quality, and Sustainability Worldwide • 8 What Is IEC 62443? A Complete Guide to Industrial Cybersecurity • 9 DFARS Compliance: A Guide for Defense Contractors • 10 CMMC vs FedRAMP: What’s Different and Which One Applies to You • 11 Automotive SPICE (ASPICE) 4.0: A Complete Guide • 12 Restriction of Hazardous Substances (RoHS) Compliance Guide • 13 MISRA C and MISRA C++ Explained: Rules for Safer Embedded Code • 14 REACH Compliance for Product Engineering Teams • 15 Radio Equipment Directive (RED) Cybersecurity Requirements • 16 What Is a Software Bill of Materials? • 8. Systems Engineering • Overview • 1 What is Systems Engineering? A Guide for Modern Engineering Teams • 2 How Do Engineers Collaborate? A Guide to Streamlined Teamwork and Innovation • 3 The Systems Engineering Body of Knowledge (SEBoK) • 4 What Is MBSE? Model-Based Systems Engineering Explained • 5 Digital Engineering Between Government and Contractors • 6 Digital Engineering Tools: The Key to Driving Innovation and Efficiency in Complex Systems • 7 What Is Bill of Materials (BOM) Management? A Guide to Controlling Product Data • 9. Automotive Development • Overview • 1 Understanding IATF 16949: A Quick Guide to Automotive Quality Management • 2 What Is ISO 21434? Automotive Cybersecurity Engineering Explained • 3 What Is an Automotive Safety Integrity Level (ASIL)? • 4 What Is SOTIF? A Guide to ISO 21448 for ADAS Safety • 10. Medical Device & Life Sciences Development • Overview • 1 The Importance of Benefit-Risk Analysis in Medical Device Development • 2 Software as a Medical Device: Revolutionizing Healthcare • 3 Navigating the Risks of Software of Unknown Pedigree (SOUP) in the Medical Device & Life Sciences Industry • 4 What’s a Design History File, and How Are DHFs Used by Product Teams? • 5 What Is ISO 13485? A Guide to Medical Device Quality Management Systems • 6 What Is IEC 62304? A Guide to Medical Device Software • 7 What Is a Device Master Record (DMR)? Definition and FDA Requirements • 8 Failure Modes, Effects, and Diagnostic Analysis (FMEDA) for Medical Devices: What You Need to Know • 9 Embracing the Future of Healthcare: Exploring the Internet of Medical Things (IoMT) • 10 What Is General Safety and Performance Requirements (GSPR)? What You Need To Know • 11 What Is IEC 62366? Usability Engineering for Medical Devices • 12 What Is the Quality Management System Regulation (QMSR)? • 13 510(k) vs PMA: Differences in FDA Device Approval and Clearance • 14 EU MDR Compliance Requirements and Timeline • 15 Essential Performance Requirements and How to Identify Them • 16 DHF vs DMR vs DHR: What Changed Under the FDA QMSR • 17 Computer Software Assurance for Production and Quality Systems • 18 IVDR Compliance: What Manufacturers Need to Know • 19 IVDR Compliance: What Manufacturers Need to Know (copy) • 20 IEC 60601-1 Guide for Medical Devices • 21 A Guide to Medical Device Requirements Management • 11. Aerospace & Defense Development • Overview • 1 What is ITAR Compliance? What Engineering Teams Need to Know • 2 What Is DO-278A? A Guide for Compliance Teams • 3 ARP4754B Explained: Changes, Recognition, and Compliance • 4 What Is a Safety Integrity Level (SIL)? How to Calculate and Apply It • 5 A Guide to Aerospace Requirements Management • 6 What Is ARP4754A? A Complete Guide to Civil Aircraft and Systems Development Assurance • 7 Understanding ARP4761A: Guidelines for System Safety Assessment in Aerospace • 8 What Is DO-254? A Complete Guide to Airborne Hardware Design Assurance • 9 What Is DO-178C? A Guide to Airborne Software Certification • 12. Architecture, Engineering, and Construction (AEC industry) Development • Overview • 1 What is the AEC Industry? • 13. Industrial Manufacturing & Machinery, Automation & Robotics, Consumer Electronics, and Energy • Overview • 1 What Is IEC 61508? A Guide to the Functional Safety Standard • 2 Understanding ISO 13849: The Foundation of Functional Safety in the Machinery Sector • 3 IEC 62061 – Functional Safety for Machinery Systems • 4 ISO 10218: Ensuring Safety in Industrial Robotics • 14. Semiconductor Development • Overview • 1 Why Chiplets Are Changing the Game in Tech Innovation • 2 Integrating Digital Engineering and the Digital Thread for Semiconductor Design • 15. AI in Product Development • Overview • 1 What Is AI in Product Development? A Complete 2026 Guide • 2 AI Test Case Generation: A Complete Guide for Regulated QA Teams • 3 Using AI to Write Software Requirements: What Works and What Doesn’t • 4 What Is the Model Context Protocol (MCP) for Requirements Management? • 5 AI for Systems Engineering: Benefits, Risks, and How to Start • 6 How to Automate Requirements Management • 16. Risk Management • Overview • 1 What Are Failure Modes? Types, Examples, and How to Identify Them • 2 What Is Software Risk Management? • 3 What Is a Risk Assessment Matrix? How to Build and Use One • 4 Types of FMEA: Definitions, Differences, and When to Use Each • 5 DFMEA vs PFMEA: Scope, Timing, and the Handoff Between Them • 17. Product Development Terms and Definitions • Overview • 1 Concurrent Engineering: Benefits, Challenges, and Best Practices • 2 eBOM vs mBOM: Differences and When Each Matters What Is IEC 62304? A Guide to Medical Device Software IEC 62304 is the international standard for developing and maintaining medical device software, whether the software is a medical device on its own or built into one. Every software system it covers gets a safety class of A, B or C, based on the worst-case harm the software could contribute to, and that class decides how much planning, design, testing and documentation you have to produce. FDA recognizes the current edition, so a 510(k) sponsor can cite it in a submission. FDA submissions should also show traceability from requirements to verification and risk controls. The sections below explain what each safety class requires, how risk controls trace to their verification, and how Software of Unknown Provenance (SOUP), code you use but didn’t develop for the device, is controlled at each class. What Is IEC 62304? The standard sets life cycle requirements for software that is itself a medical device and for software embedded in or integral to one. Validation and final release of the device are outside the standard’s scope, even when the device is entirely software, and the standard prescribes no life cycle model. Before any lifecycle work, a manufacturer needs a quality management system that satisfies ISO 13485. A risk management process that complies with ISO 14971 must also be in place, along with a safety class of A, B or C for each software system. Clauses 5 through 9 define development, maintenance, risk management, configuration management and problem resolution processes. The edition in force is the consolidated Edition 1.1, published on 26 June 2015. Edition 1.1 combines the original IEC 62304:2006 with Amendment 1:2015. FDA lists the consolidated Edition 1.1 as recognized consensus standard 13-79 with complete recognition. A 510(k) sponsor can therefore cite it in a submission. In the EU, notified bodies expect software documentation in technical files for the Medical Device Regulation (MDR) to follow EN 62304 and scale with the safety class, according to the notified-body association Team-NB. A technical file should cite EN 62304 as a benchmark, and claim presumption of conformity only once the Commission’s harmonized standards list for the MDR names it. Software Safety Classes Set the Depth of Evidence The safety class sets how much lifecycle evidence IEC 62304 requires, through the activities Table A.1 assigns to each class. Under Clause 4.3, each software system gets one of three safety classes, based on the worst-case harm it can contribute to after external risk controls: • Class A: The software either cannot contribute to a hazardous situation or has acceptable risk after external controls. • Class B: The software can contribute to a hazardous situation involving non-serious harm. • Class C: The software can contribute to death or serious injury. Unclassified software defaults to Class C, and the highest class of any component sets the class of the whole system. Under Amendment 1, classification assumes that software will fail to behave as specified. Severity and risk controls external to the software system determine the class, and reliability arguments, coverage figures and field history have no effect on it. | Activity | Clause | Classes it applies to | | Software development planning | 5.1 | A, B, C (several planning items B and C only, one C only) | | Software requirements analysis | 5.2 | A, B, C (one item B and C only) | | Software architectural design | 5.3 | B, C (one item C only) | | Software detailed design | 5.4 | C (one item B and C) | | Software unit implementation | 5.5 | A, B, C | | Software unit verification | 5.5 | B, C, with added acceptance criteria at C | | Software integration and integration testing | 5.6 | B, C | | Software system testing | 5.7 | A, B, C | | Software release | 5.8 | A, B, C | | Configuration management and problem resolution | 8, 9 | A, B, C | Table A.1 shows that Class A still requires planning, unit implementation, system testing, configuration management and problem resolution records. Class C differs from Class B chiefly in detailed design and in the additional unit acceptance criteria it requires. Code-based (white-box) testing happens primarily at unit level, according to FDA’s software validation guidance, so system tests alone don’t provide code-based coverage. The IEC 62304 Software Development Lifecycle and the Records It Leaves IEC 62304’s development process runs from planning to release, and each stage produces a record an auditor or FDA reviewer can request. The safety class decides which records exist, and FDA’s Documentation Level, Basic or Enhanced, affects how much of them goes into a submission. Planning, Requirements and Release Apply at Every Class Planning, requirements analysis and release records are required at every class, and Class B and C add items to the plan and the requirements. The software development plan names tools, methods and coding guidelines, and for Class B and C it covers how known defects are published. Where integration and system testing are combined, the plan must say so. Teams document requirements at every class, including information technology (IT) security, networking and user interface requirements. Requirements that implement risk controls belong in the Software Requirements Specification (SRS). Each should translate readily into a verification acceptance criterion, which is the link an auditor follows from the risk file to the test record. Release documentation identifies the version under application, and notified bodies expect a list of known residual anomalies with a justification for releasing with each. A technical file should include a clearly identified safety classification with its justification, plus a traceability matrix linking requirements to protocols, reports and test data, according to Team-NB. Architecture, Design and Verification Scale With Class B and C Architecture is required for Class B and C software and identifies software items and units, specifies interfaces, and documents the requirements and prerequisites for each SOUP component. The architecture is also an input to the software risk analysis. Unit verification applies at Class B and C, and Class C adds acceptance criteria such as event sequences, fault handling, memory management and boundary conditions. Integration testing exercises data and control transfer across architecture interfaces. Together with unit verification, it shows whether lower-level and interface behavior support the system requirements. Design and Development Requirements and the Submission Trace Under the QMSR Under the Quality Management System Regulation (QMSR), § 820.10(c) requires manufacturers of class II, class III and certain class I devices, including those automated with computer software, to comply with the design and development requirements of ISO 13485. ISO 13485 sets those requirements out in Clause 7.3 and its subclauses. The QMSR has been in effect since 2 February 2026. FDA recommends tracing each identified hazard to its verified risk controls, from an SRS requirement and its tests to a user manual or training identifier. When one hazard traces to several requirements and tests, a separate document can connect the SRS, design specification, testing and identified hazards. FDA sets an Enhanced Documentation Level where failure or a flaw of any device software function could present a hazardous situation with probable risk of death or serious injury, assessed before risk controls. Basic Documentation applies when Enhanced Documentation is not appropriate, although FDA also recommends Enhanced Documentation for certain device categories, including some blood-related devices, Class III devices, and device constituent parts of combination products. FDA sets one Documentation Level for the device as a whole, while IEC 62304 classifies each software system and its items, so the two schemes don’t map one to one. A sponsor can substitute a declaration of conformity to the recognized IEC 62304 for applicable development, maintenance and configuration management documentation. Learn About the QMSR Software Risk Management Under Clause 7 and ISO 14971 Software risk management under Clause 7 starts from hazardous situations already identified in the ISO 14971 system analysis. The team identifies which software items could contribute to each situation and records their potential causes, such as SOUP failures. Severity is taken from the system risk file, and the analysis works at least at software-item level. For every documented potential cause, you define, document, implement and verify a risk control measure, often as a new requirement in the SRS. FDA ranks risk control options from design changes, through protective measures, to information for safety, in its premarket software guidance. Verification also checks whether a measure creates a new hazardous situation. For Class B and C software, the manufacturer documents four traceability links that connect system risk analysis to software implementation and verification, and the record should make each one explicit: • Hazardous situation to software item: The system risk file names the item whose failure could contribute to the situation. • Software item to software cause: The record explains how that item fails, including a SOUP failure or unexpected result. • Software cause to risk control measure: The record links the control, usually a requirement, that addresses that cause. • Risk control measure to its verification: The record cites the test or review showing the control was implemented and is effective. At every class, Clause 7.4 requires a change analysis that looks for new causes and risk controls, including for SOUP changes. Class B and C must also analyze the impact on existing controls and act on the result. After release, the change is also covered by ISO 14971 post-production activities. \[MID-PAGE CTA: Promote the datasheet “FMEA Framework for Medical Device Development” \| https://www.jamasoftware.com/datasheet/jama-software-fmea-medical-device-development-datasheet/. Button text: Get the FMEA Datasheet. Note for publishing: RM Hub, copy the button HTML from the reference template\] Software Maintenance Under Clause 6 Clause 6 of IEC 62304 is the process for changing medical device software after release. Its three activities are establishing a software maintenance plan, problem and modification analysis, and modification implementation. Every requirement in the clause applies at Class A, B and C, according to Table A.1, so you need a maintenance plan and change records even for Class A software. Problem and modification analysis starts with monitoring feedback on software released for intended use. Each problem report is then evaluated for its effect on safety and for whether the software needs to change, using the software problem resolution process. A problem can also show that a software system or software item was placed in the wrong safety class. Each change request gets an impact analysis of its effect on your company, the released software and the systems it interfaces with, and each one needs approval. Approved changes are also communicated to affected users and regulatory authorities when required. During modification implementation, you identify which Clause 5 activities the modification requires you to repeat, and you perform them. The modified software is then released through the standard’s software release activity. Risk management of software changes has its own requirements, set out in the risk management section above. Configuration management records link each change request to its relevant problem report and to its approval at every class, and the late-change walk-through below applies them to a Class C program. An auditor checking maintenance can ask for the maintenance plan, the evaluated problem reports and the linked change records. Configuration Management and Problem Resolution Through a Late Change Every late change passes through configuration management and problem resolution, which apply at every class. Configuration management identifies SOUP and every other configuration item. A controlled item changes only through an approved change request, and the team verifies, traces and logs the change in status accounting. Problem resolution produces a problem report, investigates it, advises relevant parties and evaluates trends. A late change in a Class C program means re-checking the requirement that changed, the risk control that depended on it, and every verification record built on either. For that change, an auditor expects an approved change request and a cause investigation covering process, methods, tools or code. The record then shows updated requirements and architecture, plus class-scaled regression across unit, integration and system tests through release. Archived test cases and prior verification and validation (V&V) results let you scope regression after a change. Xoran Technologies left unclear whether its regression analysis had determined which unit, integration and system-level tests to re-run after software changes, or whether code coverage matched the risk, FDA wrote in a December 2024 warning letter. Between 1992 and 1998, 192 of 242 software-related recalls came from defects introduced by changes made after the software’s initial production and distribution, according to FDA’s General Principles of Software Validation. ISO 13485 Clause 7.3.9 requires teams to review, verify or validate design changes as appropriate and approve them. New app treatments that ZIIP, Inc. added in October 2025 lacked documentation or supporting V&V even though the company’s own procedures required review for repeat V&V, FDA found in a 2026 warning letter. Pensar Medical communicated a hold on one firmware change order only verbally, with no nonconformance report, and had submitted no documented formal risk assessment for a later firmware update, the agency found that year. Controlling SOUP by Safety Class SOUP control scales by class, with identification at every class and specification and anomaly evaluation added at Class B and C. Software qualifies as SOUP when it was already developed and generally available but wasn’t developed for the device, or when it was previously developed with inadequate development records. The medical device software system as a whole cannot be claimed as SOUP, although individual software items, including previously developed internal software lacking adequate development records, may qualify as SOUP. FDA’s off-the-shelf (OTS) software guidance covers the same ground without using the term SOUP. Each SOUP item’s configuration record lists the title, manufacturer and a unique designator such as a version, release date, patch number or upgrade designation. The maintenance plan explains how the team evaluates upgrades, patches and obsolescence. Section 524B(b)(3) of the Federal Food, Drug, and Cosmetic Act requires cyber device manufacturers to provide a Software Bill of Materials (SBOM) covering commercial, open-source and off-the-shelf components. FDA asks for it in a machine-readable format in its cybersecurity guidance. An SBOM of that kind covers SOUP identification, the part of SOUP control owed at every class. At Class B and C, the architecture states each item’s functional and performance requirements for its intended use, plus the hardware and software it needs. Verification confirms that the item works as specified on that hardware and software. Where SOUP failure could cause a hazardous situation, you evaluate the supplier’s published anomaly list for the version in use and record the potential causes in the risk management file. A record that names the sources searched, the search date, the anomalies found and the hazard analysis of each lets an auditor see that the evaluation was done. Where IEC 62304 Edition 2 Stands Edition 2 isn’t published yet, and the IEC lists it as in development. Publication is forecast for October 2028, a forecast that teams shouldn’t plan around. Its second Committee Draft (CD) 62A/1761/CD circulated on 7 August 2026 with comments closing on 27 November 2026, according to IEC Technical Committee 62, Subcommittee 62A. The draft extends its scope to all health software, including software as a medical device (SaMD) and software with AI or machine learning (ML) algorithms, and is retitled to match. Conformity under the draft is assessed against what it calls a software process rigour level. Reviewers apply Edition 1.1 and its Table A.1 until the new edition is published. How Jama Connect Supports IEC 62304 Jama Connect®, a web-based requirements management and traceability platform, can hold the SOUP list and its anomaly evaluations in custom item types, with a picklist field recording each software item’s safety class. Administrators can configure those item types and the pre-built medical device Traceability Information Model (TIM) to include SOUP records, configuration items and problem reports with required links, as the TIM already does for requirements and tests. When a requirement changes late in a Class B or C program, suspect links flag every linked test and risk item for review. Coverage gap detection identifies requirements without linked verification and any other missing link the TIM requires, such as a risk control. For review and release evidence, Review Center records approvals with electronic signatures aligned to FDA’s 21 Code of Federal Regulations (CFR) Part 11. The medical device frameworks ship with pre-built risk analysis reports, so teams can analyze risk without first building report templates. Export templates aligned to regulatory submission requirements produce traceability matrices and risk management files from the linked records, which teams may organize as a Design History File (DHF) in the industry sense. Medimaps cut FDA submission preparation from over a week to a few hours.