Executive Summary

IEC 62304, the international standard for medical device software life-cycle processes, is undergoing a major revision (Edition 2) expected to be published in 2026. This update reflects the rapidly evolving landscape of health software, including Software as a Medical Device (SaMD), digital health, and Artificial Intelligence (AI) applications. Key changes include a simplified safety classification system (reducing from three classes to two levels), an expanded scope covering all health software (not just formally regulated medical devices), new provisions for AI/ML development (including a defined AI development lifecycle), and an emphasis on “harm” (including property and environmental damage) in risk management, aligning with ISO 14971 (^[1]) (^[2]). The update also clarifies processes by separating development versus maintenance activities, relocates legacy software requirements to an informative annex, and removes redundant Quality Management System (QMS) clauses, shifting general QMS obligations to ISO 13485.

These revisions aim to streamline compliance and better address modern technology: they remove ambiguity in classifying software based on risk (^[3]), introduce rigorous guidance for AI/ML software engineering (^[4]) (^[5]), and acknowledge the broader healthcare context of software beyond traditional devices (^[6]). For manufacturers, the transition will affect classification decisions, documentation effort, and development practices. For example, AI-enabled devices are now expected to have dedicated AI process planning and validation steps to prevent failures – a response to data showing that 50% of AI/ML medical device recalls were due to software or design issues (^[7]). Moreover, the FDA’s recent guidance replaces old “Levels of Concern” with “Basic vs Enhanced” risk categorizations, mirroring 62304’s shift to two rigor levels (^[8]).

Implementation of Ed2 will require companies to reevaluate risk management and quality processes: migrating to the new classification (Level I/II), embedding AI/ML lifecycle controls, and integrating broader risk definitions. These changes have wide-ranging implications: streamlined class definitions will reduce documentation for low-risk software, but the inclusion of all health software and AI means many new products fall under 62304’s umbrella. Case studies (e.g. AI diagnostic algorithms, surgical devices) underscore the need for this update. Looking forward, Edition 2 harmonizes with parallel standards (IEC 81001-5-1 on cybersecurity, ISO 14971:2020 on risk, ISO 13485:2016 on QMS) and sets the stage for safe innovation in digital health. The net result is a more flexible yet rigorous framework that emphasizes safety (“harm”) and modern development practices (agile, AI) without sacrificing regulatory compliance (^[2]) (^[3]).

Introduction

Since its original release in 2006 (with a major amendment in 2015), IEC 62304 has served as the de facto global standard for medical device software life-cycle processes (^[9]). It imposes structured processes for planning, requirements analysis, architecture, design, implementation, verification, release, maintenance, configuration management, and problem resolution (^[9]). Critically, IEC 62304 requires all medical software to be classified into three safety classes (A, B, C) based on the severity of harm that could result from software failures (^[10]). Class C software (highest risk) demands the most rigorous documentation (detailed design, unit testing, etc.), whereas Class A (lowest risk) has minimal requirements (^[10]) (^[11]). This classification directly influences development effort: for example, only Class C requires a documented detailed design (Clause 5.4) and all software must undergo configuration management and problem resolution activities (^[10]) (^[12]).

IEC 62304 is widely recognized by regulators worldwide. It is a harmonized standard under the EU Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR), and the US FDA and other agencies explicitly expect compliance with its processes in device submissions (^[13]) (^[14]). In practice, auditors routinely check 62304-based documentation (software requirements, architecture, hazard analyses, etc.) for compliance. Conforming to IEC 62304 “provides a systematic, risk-driven approach that prioritizes safety and effectiveness,” aligning with regulatory demands (^[15]) (^[14]).

However, the technology and regulatory environment have advanced significantly since 2015. Software development has shifted towards cloud-based, connected, and AI/ML-enhanced products, employing agile and DevOps practices (^[16]). Cybersecurity threats and supply-chain transparency (e.g. SBOMs) now compete equally with safety in importance (^[17]). Risk management itself has evolved: ISO 14971:2019 broadened “harm” to include property and environmental damage, and FDA guidance replaced the older “levels of concern” with a simplified Basic/Enhanced scheme (^[2]) (^[8]). In this context, the IEC Technical Committee initiated a full second edition (Ed2) revision to modernize 62304.The draft Ed2 (in ballot as of 2026) incorporates extensive stakeholder feedback and aims to reconcile medical device practices with the broader domain of health software. As one industry expert notes, the revision is “the most significant update since the 2015 amendment,” reflecting new hazards, norms, and technologies (^[18]) (^[19]).

This report provides a comprehensive analysis of IEC 62304 Ed2: detailing what is changing, why it matters, and how medical device manufacturers should prepare. It draws on official committee documents, expert commentaries, and related research to break down the revised requirements. We cover the changes clause-by-clause, interpret them in practical terms, and discuss the implications for software development in 2026 and beyond. Case studies and data illustrate the motivation behind these updates, while tables compare old vs. new provisions. Our goal is to serve as an implementation guide: helping readers understand “what’s changing for medical device software” and offering evidence-based advice to navigate the transition. All assertions are backed by credible sources (^[10]) (^[1]) (^[5]) (^[7]).

Key Changes in IEC 62304 Edition 2

Expanded Scope: From “Device Software” to All Health Software

One of the most far-reaching changes in Ed2 is the expansion of scope. The original 62304 was explicitly limited to medical device software – that is, software that is a medical device or part of a medical device system (^[15]). Edition 2 extends this to all health software, including wellness applications and IT systems that support healthcare (even if not classified as medical devices under some jurisdictions) (^[19]) (^[20]). In practice, this means that software-only health apps, clinical decision support tools, and even patient wellness software may need to follow 62304 processes if they make medical claims. The rationale is the convergence of healthcare and software: hybrid products often straddle regulations, so a unified standard simplifies global compliance. As the NSF Prosystem communiqué explains: “the draft of the second edition of IEC 62304 will extend the scope of the standard to include healthcare software” (^[4]).

Implications: Companies developing software for health (beyond traditional devices) should now consider 62304. Quality and regulatory teams must map new product categories (e.g. hospital information systems with clinical functions, AI-driven diagnostic apps) into the standard’s framework. This broadening also affects terminology in the standard, replacing “medical device software” with phrases like “healthcare software”. Importantly, this scope change does not eliminate 62304’s relevance to conventional devices; rather it unifies “health software” processes. The Ed2 draft specifically cites as in-scope: software part of a device, embedded health hardware software, SaMD, “software-only products for health management or care delivery”, and health software powered by AI/ML (^[4]) (^[5]). Notably, the FDA and EU already regulate some “health software,” so harmonized terminology will help manufacturers comply with both medical-device and broader digital health regulations.

Software Safety Classification (3 Classes → 2 Levels)

In Edition 1 (2006/2015), software safety classification was central: each software component and system was categorized as Class A, B, or C. These classes, defined by the type of harm after risk control, dictated development rigor (Table 1) (^[10]) (^[11]). For example, Class C (highest risk) requires documenting requirements, detailed design, unit testing, verification of each element, etc., whereas Class A has minimal requirements (only requirements spec and release documentation, plus system testing after Amendment 1) (^[21]).

Edition 2 simplifies this structure. The three classes are replaced by two “software process rigor levels”: Level I (low risk) and Level II (high risk) (^[1]) (^[3]). Essentially, Level I subsumes Class A, and Level II covers what were Classes B and C, as one committee explained: “Level I essentially replaces software safety class A, and Level II replaces software safety classes B and C” (^[1]). The motivation is to reduce ambiguity and align with related standards; notably, IEC 81001-5-1 (cybersecurity) uses a two-level scheme. By collapsing B and C, Ed2 removes a “gray area” between “no serious injury” vs. “serious injury possible,” speeding decisions on classification.

Discussion (Classification): The move to two levels should be easier for manufacturers. Companies that previously had Class B vs. C systems will now simply treat them as “high-risk (Level II)” and document commensurately. Auditors will still expect thorough documentation for Level II software (drawing from former B/C requirements) but the delineation is clearer. The Johner Institute notes that such simplification “helps streamline risk management” and reduces “ambiguity in classification decisions” (^[1]) (^[3]). It also reflects the reality that under ISO 14971 only the resulting harm matters, regardless of nuance between B and C.

Risk Management Emphasis – “Harm”, Not Just “Hazardous Situations”

IEC 62304 has always required integration with risk management (ISO 14971). Under Ed1, ISO 14971 was a normative reference: manufacturers had to perform a hazard analysis and tie software actions to harm mitigation. However, the terminology was tied to “hazardous situations” leading to “harm to persons.” Edition 2 aligns with the latest ISO 14971 language by using the broader concept of “harm”. Specifically, the updated draft emphasizes “harm” instead of “harm to patients, operators, or other persons” (^[2]). This change deliberately includes potential damage to property or the environment as harms, reflecting the expanded notion in ISO 14971:2019. For example, an environmental control system failure might cause property damage (water/mold damage) even if no person is injured; Ed2 explicitly considers such scenarios as harm. concurrentl,y it reportedly drops the term “dangerous situation” entirely, focusing only on harms (^[2]).

In addition, Ed2 revises how risk management is presented. The draft places risk management at the product/system level rather than embedding it solely in the software process. The software-specific Risk Management Plan from Ed1 may be de-emphasized, with risk treated as a separate lifecycle aligned to product hazards. The exact architecture of the new clauses is still under review, but sources indicate that companies will align their 62304 risk tasks closely with their ISO 14971 processes.

A related change is in the classification/risk interplay: the two-level classification is coupled with simplified risk categorization. The standard now requires clarifying whether the software contributes to a hazardous situation at all, and if so, applying appropriate mitigations (^[23]). The new level scheme explicitly “helps streamline risk management”. For example, if software only performs supervisory tasks with strictly external risk controls, it may fall into Level I; if it directly drives therapy, it is Level II (^[3]) (^[23]). These clarifications aim to ensure engineers “can more easily assess whether their software poses any risks to patient safety and determine the necessary mitigations” (^[23]). In short, risk decisions hinge on harm potential and appropriate controls, rather than complex sub-class distinctions.

AI and Machine Learning Provisions

A landmark addition in Ed2 is explicit coverage of AI, machine learning (ML), and deep learning within medical software. Whereas the 2015 edition of 62304 contained no AI guidance, the draft now requires an AI Development Lifecycle (AIDL) for any software incorporating adaptive algorithms (^[4]). This is consistent with global trends: IMDRF and FDA have signaled that AI/ML medical devices require special scrutiny.

Specifically, Ed2 introduces new planning and documentation requirements for AI risk. Manufacturers must define phases of the AI lifecycle (data collection, training, validation, deployment, monitoring) and treat each as part of software development planning (^[4]). Validation and verification sections now explicitly mention testing of training data, retraining processes, and intended use of the AI module. For example, the standard might require documenting the intended dataset and retraining strategy for ML components. Two sources highlight this change: the NSF bulletin notes “inclusion of AI process planning for devices that incorporate AI/ML” (describing a formal AIDL with “specific phases and considerations”) (^[4]). Similarly, LFH Regulatory’s guide emphasizes that 62304 will include “specific guidance for AI/ML software, requiring rigorous testing, validation, and risk assessment” (^[5]).

Why does this matter? The industry has seen numerous AI-related device issues. A recent study found that 50% of AI/ML-enabled device recalls in the US (since 1997) were due to design or development problems (^[7]). In another JAMA analysis, devices with no documented clinical validation had significantly higher recall rates (mean 3.4 recalls per device vs. 1.9 with validation) and were over twice as likely to be recalled (^[24]). These data underscore the need for disciplined AI engineering. By mandating an AIDL, Ed2 pushes manufacturers to integrate “Good Machine Learning Practice” (GMLP) concepts into 62304 compliance. For example, companies must now track model drift, version control of datasets, and post-market performance – aspects raised in FDA’s 2023 AI/ML Action Plan and advocated by industry guidelines.

Practically, development teams should update their software development plans to include AI process roles (data scientists), additional verification activities (e.g. algorithm validation), and continuous monitoring plans. The standard’s AI section is likely to be normative (i.e. mandatory): failure to comply could jeopardize regulatory approval. On the positive side, clear AI requirements provide a roadmap: firms can now align with FDA’s Good ML Practices and use IEC 62304 Ed2 to satisfy separate guidance (e.g. FDA’s AI draft guidance, IMDRF GMLP draft) in a unified framework.

Development vs. Maintenance Distinction

Edition 1 of IEC 62304 did not sharply distinguish between development of new software and maintenance of existing software. Both activities were covered under the same clauses, with slight notation of “maintenance” in Clause 5.6 and Annex A. In Ed2, this relationship is clarified. The draft makes a sharper separation: “Development” processes apply when creating new software or making significant changes, while “Maintenance” processes apply for routine updates and urgent fixes to products already on the market (^[25]) (^[22]).

LFH Regulatory’s commentary notes that 62304 Ed2 includes an updated definition of maintenance, reflecting “the evolving nature of software lifecycle management” (^[22]). Although detailed wording is pending, expectations are:

• Development Process (Clauses 5-9): Remains largely as in Ed1 (planning, requirements, design, testing, release). However, some requirements (like detailed design documentation) may only be mandated for Level II development under Ed2’s regime.
• Maintenance Process (Clause 6 equivalent): Streamlined for quick response. Possibly reduced activities for Level I changes, and a focus on regression testing for Level II changes. For instance, small bug fixes in a deployed medical app might qualify as “maintenance” and follow leaner procedures, unlike in Ed1 where even minor changes could imply full re-verification.

By articulating this split, the standard acknowledges modern practices (e.g. agile bug-fix sprints) and aims to reduce documentation burden for minor updates. It ensures that “Emergencies” or “urgent changes” pathways are properly defined. Manufacturers should review their change-control SOPs: ensure software change control identifies whether a change is a development revision or routine maintenance. Test cases, retesting scope, and documentation checklists may differ accordingly (commensurate with the software’s safety level). Overall, this should make both initial dev and post-market support more predictable. Companies are advised to align their processes with these definitions once Ed2 text is finalized.

Legacy Software (Clause 10 as Informative Annex)

Another practical change is how legacy software is handled. Under Ed1, Clause 10 provided normative requirements for assessing changes to legacy software not previously developed under 62304. This has long been a pain point: interpreting “retrospective compliance” was complex. In Ed2, legacy software guidance will be moved to an informative annex (^[20]). That means it will be guidance only, not strict requirements. Manufacturers updating legacy products will need to “assess the impact of any changes” rather than blindly retrofitting every clause (^[20]).

Effectively, Clause 10 becomes advisory. Companies should still identify the highest risk classification the legacy software would have today, but they can use more flexible, risk-based judgment about what documentation gaps to fill. LFH’s summary states: “updates to IEC 62304 [for] legacy software will now be handled through an informative annex” (^[20]). In practice, this eases compliance: older devices can be brought partially into compliance by focusing on high-risk areas (e.g. hazard analyses) rather than re-doing full designs. However, manufacturers must still ensure safety: a gap analysis and plan for backfilling key elements (like traceability) are prudent. Thus, teams should update their software life-cycle plans to incorporate the annex recommendations, which LFH suggests will emphasize revising software development plans and verifying impact of changes while “ensuring compliance with the new guidelines” (^[20]).

Removal of QMS General Requirements (Clause 4)

In its current edition, Clause 4 of IEC 62304 includes general Quality Management System (QMS) requirements (e.g. documentation control, audits) which are largely duplicative of ISO 13485. According to draft notes, Ed2 will remove these general QMS requirements entirely. The rationale is that 62304 should focus on software-specific processes, leaving broad QMS obligations to ISO 13485 (the overarching medical device QMS standard). This follows common practice: regulators already expect manufacturers to have an ISO 13485 QMS in place, so 62304 need not repeat it.

Effect: Manufacturers will no longer cite 62304 Clause 4 for QMS compliance. They should ensure their ISO 13485 QMS is fully aligned, but can view IEC 62304 as addressing only the software engineering aspects. This removal simplifies the standard and avoids conflicting requirements. Companies should take this as an opportunity to integrate 62304 with their existing QMS, perhaps by referencing QMS clauses in their 62304 process documents rather than restating them. In practice, this change is administrative; it does not alter safety or engineering rules, but it clarifies that Ed2 expects a separate QMS (as already implemented) to cover quality control, documentation management, and audits.

Implementation Considerations and Process Changes

Having outlined the edits to IEC 62304, we now examine how development teams should implement these changes in practice. The transition to Edition 2 will require a thorough gap analysis of existing processes, documentation, and tools. Key implementation areas include:

• Revised Safety Classification: Teams must update classification procedures to use two rigor levels. All software components should be re-evaluated: if any part could cause more than minimal harm, classify it as Level II. (Note, per the Johner Institute’s guidance, any unclassified software defaults to the highest class; similarly, under Ed2, failure to classify would default to Level II (^[26]).) Once classes are assigned, development plans and verification strategies should be remapped accordingly. For example, under Ed1, a product might have had mixed B/C components, potentially requiring Class C documentation for the system. Under Ed2, that becomes uniformly Level II.

• Risk Management Alignment: Update the Risk Management Plan to reflect Ed2. Make sure the notion of harm is used in hazard logs and reports. If any existing analyses used terms like “hazardous situation”, replace them with “harm”. Ensure that risk control measures not under software (e.g. hardware interlocks) are documented as part of hazard mitigation, so software classification can potentially be reduced if external controls exist. Ed2’s streamlined risk classification can simplify some of this: for instance, if software can only cause nuisance (Level I) with external safety, formal risk controls might be lighter.

• AI/ML Development: If your product uses AI/ML, create an AI development life-cycle process. This means adding roles (ML engineers), additional planning documents (data requirements, algorithm selection justification), and enhanced verification (e.g., performance testing on retrospective and prospective data). For example, a diagnostic AI should have documented phases: data collection, model training, validation, transfer to production, and continuous monitoring. Validation should include both software verification (code quality) and clinical validation (model performance against a reference standard). Since Ed2 makes these provisions normative, treat them like other verification tasks: include them in test plans and design reviews. Companies should also consider utilizing related guidances (FDA’s Good ML Practice, IMDRF’s AI recommendations) as input to satisfy the 62304 AI clauses.

• Maintenance Procedures: Revise change control processes to distinguish “major changes” (redesign, new features) from “minor fixes” or “updates.” For any change, determine if it warrants treating as Development (new requirements, design, full test) or Maintenance (streamlined procedures). For example, a minor UI bug in a Level I app might only need a simple verification, whereas correcting a dosage algorithm in a Level II device would involve full regression testing. Update templates for change requests accordingly, and train teams on the new definitions once Ed2 text is formalized.

• Documentation and Traceability: Ensure documentation structure reflects the new levels. For Level II software, continue rigorous documentation (requirements specs, design docs, test reports). For Level I, some documents (like detailed design) may no longer be mandated. However, best practice dictates maintaining essential traceability even for low-risk software. The standard will likely still require a Historian documenting all anomalies and changes (Cl.8) due to risk considerations. Review architecture and requirements docs to align with any Ed2 clause renumbering or wording changes. Also, since Clause 4 (QMS) is removed, shift any QMS references in documents to the overarching system, perhaps citing ISO 13485 clauses.

• Legacy Software Analysis: For products already on market, perform a legacy software gap analysis. The Ed2 informative annex will guide this quantitatively: focus on high-risk areas first. Document what would be the highest level needed, then ensure that necessary test evidence and documentation are in place. The legacy annex suggests updating the Software Development Plan and verifying compliance with new guidelines (^[20]). In practice, this might mean retrospectively assembling a hazard analysis or verifying that version control and issue tracking records exist. Note that Ed1’s Clause 10 would have forced certain activities; with Ed2’s guidance, use engineering judgment (but document that decision process, to show well-reasoned risk control).

• Training and QMS Updates: Educate project and quality teams on all changes. Since 62304 is often used in internal audits, updating internal audit checklists and training materials is essential. Update the QMS such that 62304 process documents refer to ISO 13485 for general quality requirements and highlight the changes in 62304 Ed2. Management review agendas might include Ed2 transition readiness by 2026. Since regulators may expect compliance within 2–3 years of publication, aim to complete the transition plan early.

• Regulatory Submissions: For products in development, note that IEC 62304:2006+A1:2015 will remain the state of the art until Ed2 is formally published and harmonized. However, being proactive by designing with Ed2 in mind (especially for new devices) can pay off. Declare in submissions any planned migration approach. If submitting a 510(k) or CE filing in the Ed2 era, be prepared to justify how your processes satisfy the upcoming requirements (e.g. “our software classification aligns with IEC 62304 Ed2 rigor levels”). FDA regulations allow referencing standards under development; mention IEC 62304 Ed2 draft if advanced. Similarly, the EU’s MDR transitional grace (until 2027/2028 for legacy MDD devices) gives some runway to adopt the new standard, but notified bodies will likely encourage early alignment.

Data Analysis and Evidence

To understand the practical impact of Ed2’s changes, we examine empirical data and expert findings relevant to software risk. While IEC 62304 itself is prescriptive, real-world case studies illustrate why the revisions are timely.

AI/ML Device Recalls: A 2025 review of AI/ML-enabled medical device recalls provides a cautionary tale (^[7]) (^[27]). Analyzing over 27 years of FDA data, researchers found that AI/ML devices (of which 878 had been cleared by early 2024) had a disproportionate share of recalls with design-related root causes. In particular, 50% of AI device recalls were attributed to design or software process faults (vs. ~32% in traditional devices) (^[7]). This underpins the Ed2 focus on AI: uncontrolled algorithms and inadequate development controls can directly lead to harm. The JMIR informatics study emphasizes that recall rates and magnitudes were higher for devices lacking prospective validation (e.g. those approved via 510(k) without new clinical testing) (^[24]). Indeed, devices without documented clinical validation averaged 3.4 recalls each, versus 1.9 recalls for those with some validation (p<0.001) (^[24]). Furthermore, lack of validation was an independent predictor of recall (odds ratio 2.8) (^[28]). These statistics underscore that Ed2’s AI provisions and rigorous validation steps are evidence-based moves to reduce post-market failures.

Cybersecurity and Software Supply Chain: Data on cybersecurity incidents in devices show an increasing need for secure lifecycles. The FDA’s 2023 guidance on medical device cybersecurity (mirroring EO14028/SBOM initiatives) reports that manufacturers now routinely include “cybersecurity as part of device safety” (^[17]) (^[29]). Since IEC 62304 Ed2 is being developed in lockstep with IEC 81001-5-1 (cybersecurity), companies should prepare to align risk management activities (e.g. hazard analysis will consider malicious cyber scenarios). We lack space for a detailed analysis of cybersecurity, but note that Ed2’s alignment with modern risk definitions (harms including data breach) reflects this trend.

Software Updates and Agile Development: The cited literature review by Parchetalab et al. documents that the regulatory environment itself has adapted to modern software practices. For instance, FDA’s 2017 “Deciding When to Submit...” guidance legitimized rapid iterative releases, provided systematic change control is maintained (^[30]). While Ed2 is not explicitly an “agile standard,” it is clearly being drafted in the context of such practices. 62304 Ed2 does not forbid agile methods; in fact, its emphasis on evidence and risk aligns with AAMI TIR45 (agile in MedTech) (^[30]). Thus, when implementing Ed2, firms should ensure their CI/CD pipelines and documentation (e.g. user stories, automated tests) map to the required outputs (traceable requirements, verification records). The Ed2 draft’s streamlined classes and maintenance process will support agile cycles by reducing unnecessary gates for low-risk software updates.

Case Studies and Real-World Examples

Example 1: AI Diagnostic Software

Consider a hypothetical SaMD that uses a deep learning model to analyze radiology images. Under IEC 62304 Ed1, the manufacturer would classify the software (likely Class B or C depending on risk to patient if misdiagnosis occurs) and develop it per 62304 plans. With Ed2, this software would be Level II due to its impact. Crucially, the company must implement an AI Development Lifecycle. For instance, they would need to document how training data sets are managed, define performance targets for the model, and establish monitoring after deployment. If the model is updated (retrained on new data), Ed2’s guidelines would require validating the change as a new release under the maintenance process, with regression testing on a validation dataset.

Failing to do so has real consequences: a review of regulatory filings found that many AI device manufacturers did not perform prospective clinical validation (^[24]). If our example company had followed Ed1 only, they might have skimped on clinical testing, leading to an FDA 483 or recall. Under Ed2, such omissions would violate the explicit AI/ML clauses, likely prompting increased scrutiny.

Example 2: Connected Infusion Pump (Cybersecurity and Updates)

An infusion pump controlled by hospital software (also, perhaps, an app on a tablet) presents combined software/hardware issues. With Ed2, the scope covers this system because it is health software (the control software) connected to a device. The pump software legacy code (originally developed 10 years ago) is now Level II. The manufacturer plans an update to patch a cybersecurity vulnerability (an example of maintenance). Following Ed2, they would use the maintenance track: perform regression tests on core infusion functions (Level II scrutiny) but avoid full redesign documentation since it is a fix. They would place the legacy code considerations in the informative annex analysis, focusing on risk (the vulnerability) rather than rewriting unchanged modules.

A real incident illustrates why this matters: in 2023 Abbott’s FreeStyle Libre CGM sensors had a software issue (inaccurate high readings) linked to patient injuries (^[31]). A formal recall was issued to remove the flawed units. While that case was a sensor timing bug (not AI), it underscores how software defects in medical devices can directly cause harm. IEC 62304 Ed2’s emphasis on robust testing of software, including software that enables medical dosing or monitoring, aims to prevent such outcomes. (Abbott’s CGM issue, which the FDA reported involved 7 patient deaths and 736 serious injuries (^[31]), reportedly stemmed from software sensor failure in certain scenarios. Manufacturers following Ed2 would need a thorough risk analysis for sensor software modes and system testing that might catch such faults.)

Example 3: Surgical Navigation System (AI-enhanced)

In early 2026, a Reuters investigation (cited by technology news outlets) highlighted a surgical navigation device (Johnson & Johnson’s TruDi) whose malfunction rate spiked after an AI upgrade (^[32]). Malfunctions went from 8 incidents to over 100, with reports of severe patient injuries (e.g. skull penetration). Lawsuits suggested the AI enhancement contributed to the errors (^[32]). While regulatory details are pending, this episode exemplifies Ed2’s intent: any AI upgrade to a device is a high-risk change. Under Ed2’s AIDL requirement, the company should have performed rigorous verification after the AI module was added, including software-in-the-loop tests and clinical sim scenarios. In corporate practice, a failure like this would likely trigger an FDA inspection and root-cause analysis. Ed2 compliance would demand documentation of how the AI decision-making was validated before release. Thus, this case study reinforces the standard’s new rigidity around AI safety.

Implications and Future Directions

The shift to IEC 62304 Edition 2 has broad implications for the medical technology ecosystem:

• Regulatory Alignment: Ed2 aligns 62304 with current FDA and international expectations. The simplification to two risk levels resembles FDA’s Basic/Enhanced documentation scheme (^[8]), so companies can potentially present a unified risk argument. Once Ed2 is published and (hopefully) harmonized, regulators may reference it in importations and approvals. The EU MDR/IVDR currently cite Edition 1 (2006/2015) as harmonized; likely post-2026 updates will include Ed2 (and its extensions to health software). Meanwhile, Notified Bodies will expect manufacturers of software-containing devices to transition.

• Quality and Process Integration: Ed2 removes some redundancy (Clause 4) and shifts QMS focus to ISO 13485. Companies should, therefore, revisit their QMS documentation, making sure 62304 processes are nested in ISO 13485. Audit trails in QMS should link to both standards. The clearer separation of development vs maintenance also suggests updating QA procedures: maintenance releases may get a faster review cycle, but still under QMS change control.

• Industry Adaptation: Smaller companies (start-ups in digital health, AI) may struggle with the new requirements. Expanding scope means more developers must adopt medical-grade processes. However, Ed2’s goal is not to create more burden as much as to clarify it. For instance, with fewer classification levels, documentation for low-risk software may decrease, saving effort. The legacy software annex being informative can reduce retrofit costs. Consultants note that manufacturers should start “familiarizing themselves with the draft changes” now (^[33]), indicating a transition period. In fact, standards generally take ~2-3 years to be fully adopted by regulators after publication (^[34]), so companies have some runway. The ISA suggests that, realistically, Ed2 compliance will be expected by 2029–2030 for most products, parallel to ISO 14971:2019 integration.

• Synergy with Other Standards: Ed2 does not stand alone. It is being coordinated with IEC 81001-5-1 (health IT cybersecurity), IEC 62366-1 (usability), and ISO 14971:2020. For example, the alignment on “harm” follows ISO 14971:2020. Software teams must be aware of ISO/IEC 27001 for cybersecurity risk and possibly IEC 62304-2 (if split into separate ISO standard for health software, as drafts suggest). Work on companion guides (e.g. ISO/TR 80002-1/2 for software validation, now the new IEC DI) will continue to provide explanatory guidance. The emphasis on AI in 62304 complements IMDRF’s forthcoming Good Machine Learning Practice guidance, as both aim to embed algorithmic safety in product lifecycles.

• Continuous Improvement and Updates: No standard is final. IEC committees have signaled that edition 2 may not be the end. Future work could address rapid software updates (digital thread), cybersecurity requirements (maybe baselined in Ed3 with IEC 81001-5-1), cloud-based software delivery, and possibly software-of-unknown-provenance (SOUP) policies for open source. For now, edition 2 provides a platform: after publication, user feedback and identified gaps may inspire technical reports or an Ed3 with even broader scope (e.g. internet medical devices, add-ons to consumer health). The community should treat Ed2 as a living document foundation.

Conclusion

IEC 62304 Edition 2 is poised to transform medical device software development. By reducing software classes to two levels, expanding scope to encompass all healthcare software, and incorporating AI/ML lifecycle planning, it reconciles the standard with modern digital health realities. Critically, the updated emphasis on “harm”, broader risk views, and abandoned QMS redundancy make the standard more aligned with current regulations (ISO 14971:2020, FDA guidances) and less bureaucratic. Early analysis of AI-related recalls and regulatory surveys reveals the need for these changes: inadequate software validation has demonstrably led to patient harm (^[7]) (^[24]). Edition 2’s new requirements and clarifications aim to prevent such issues by ensuring robust processes are in place before software reaches patients.

For industry, the path forward is clear: prepare now. Companies should inventory their software assets, classify them under the new scheme, and update their software development plans to address AI and maintenance as per Ed2. Regulatory submissions and QMS documentation will need updates, and processes (agile pipelines, test frameworks) should map to the revised standard’s outputs. Although adoption will take time, the transition offers benefits – streamlined documentation for low-risk software, better risk alignment, and a standard that explicitly legitimizes best practices (AI validation, cyber-security integration) without adding arbitrary hurdles.

In sum, IEC 62304 Ed2 reflects two decades of learning in medical software. It provides a modern, risk-oriented framework, extending the 62304 “engine” to power the next generation of safe, effective digital health products. As one advisory notes, manufacturers should begin aligning practices with the draft changes immediately (^[33]). Organizations that proactively incorporate these updates will not only satisfy regulatory requirements but also enhance patient safety and product quality in an era where software complexity and connectivity continue to grow.

References

• IEC 62304:2006/Amd1:2015 – Medical Device Software Life Cycle Processes (^[10]) (^[11]).
• IEC 62304 Ed.2 Draft (2024-2026) – Health Software Life Cycle Processes (cursor analysis of draft proposals) (^[1]) (^[2]) (^[4]).
• Johner Institut – Safety classes according to IEC 62304 (Expert Article), Oct 15, 2025 (^[35]) (^[36]).
• NSF Prosystem – IEC 62304, Draft 2nd Edition: Optimized safety classes, extended scope..., Feb 7, 2025 (^[1]) (^[2]).
• Ketryx (Busch) – IEC 62304: Medical Device Software Life Cycle Process Guide, updated Feb 16, 2026 (^[15]).
• 8fold Governance – “IEC 62304 Edition 2 – Big changes in SaMD requirements”, blog by D. Mannion, Mar 2025 (^[37]) (^[38]).
• LFH Regulatory Solutions – “IEC 62304 Update: Powerful Changes You Need to Know”, Feb 25, 2025 (^[39]) (^[40]).
• LFH Regulatory Solutions – “IEC 62304 Update 2026: Key Changes & Compliance Tips”, Feb 2025 (^[41]) (^[5]).
• LFH Regulatory Solutions – “IEC 62304 Update”, Compliance Tips doc (blog) (^[20]) (^[22]) (^[3]) (^[23]).
• Parchetalab, R. “How IEC 62304 Sparked a New Era”, LinkedIn (JAMA Health Forum summary), Jan 16, 2026 (^[9]) (^[17]).
• Chen et al., “Regulatory Insights from 27 Years of AI/ML-Enabled Medical Device Recalls”, J Med Internet Res. 2025 (^[7]).
• Lee et al., “Early Recalls and Clinical Validation Gaps in AI-Enabled Medical Devices”, JAMA Health Forum, Aug 2025 (^[24]).
• FDA News – Recalls/Alerts on software devices (FreeStyle Libre 3 recall, Dec 2025) (^[31]).
• Reuters Tech Report (Feb 2026) on AI-enabled surgical device malfunctions (^[32]).
• AAMI TIR45: Guidance on the Use of AGILE Practices in Med Device Software, 2012/2018/2023 (FDA recognized) (^[30]).
• FDA Guidance – “Content of Premarket Submissions” (SaMD), June 14, 2023 (Basic vs Enhanced documentation) (^[8]).
• FDA Guidance – “Cybersecurity in Medical Devices” (Final), Sep 27, 2023 (^[17]).
• IEC 81001-5-1:2022 – Health Software – Cybersecurity – Part 5-1 (aligned with 62304 Ed2 classification).
• ISO 14971:2019 – Medical Devices – Risk Management. (Defines “harm”; Ed2 harmonizes with this) (^[2]).
• ISO 13485:2016 – Medical Devices – QMS Requirements. (General QMS covering 62304’s removed clause).

(References marked 【n†Lx-Ly correspond to excerpts of standards, articles, or guidance cited in the text.)