Within this guide
Medical device product software
- Embedded firmware and control software
- Standalone software as a medical device
- Software items and interfaces within a device
- Development and post-release maintenance
Start with the boundary
What IEC 62304 addresses
IEC 62304 provides a lifecycle-process framework for software that is itself a medical device or forms an embedded or integral part of one. It should be used with the official licensed standard, the applicable regulatory framework, ISO 14971 risk management, ISO 13485 quality-system processes, and the organization’s approved procedures.
Assess separately
Non-product computerized systems
- Electronic QMS, LIMS, MES, ERP, and training systems
- Spreadsheets and validation lifecycle tools
- Production and quality-system software under applicable CSV/CSA requirements
- Final medical-device validation and jurisdiction-specific obligations
Risk-proportionate lifecycle
Software safety classification
Classification is tied to potential harm and the risk-control architecture—not source-code size, technical novelty, or team effort. Apply the official classification rules through the approved risk process.
| Class | Practical interpretation | Generalized example | Evidence implication |
|---|---|---|---|
| A | Software failure cannot contribute to a hazardous situation that could result in injury or damage to health. | A software item with no safety-related contribution under the documented architecture. | Perform applicable lifecycle work with rigor suited to the function and documented classification. |
| B | Software failure can contribute to a hazardous situation that could result in non-serious injury. | Monitoring or control software where credible failure has limited harm under the risk controls. | Use stronger design, interface, risk-control, integration, and verification evidence. |
| C | Software failure can contribute to death or serious injury. | Therapy delivery, safety-critical robotic motion, or another critical control function. | Apply high rigor to requirements, architecture, detailed design, unit work, traceability, fault testing, and anomalies. |
These descriptions are practitioner summaries. Use the exact definitions and classification method in the official standard.
Interactive practitioner reference
IEC 62304 requirements explorer
Search the guide, then open a clause area to review its practical meaning, actions, examples, evidence, and software-assurance connection.
Primary referenceIEC Webstore record
Showing 15 of 15 lifecycle areas.
Software development process
8 areas5.1Software development planningIs the lifecycle planned for the software, its safety class, and the evidence needed?
Plain-language interpretation
What this means in practice
Plan how requirements, design, implementation, verification, integration, release, maintenance, configuration management, and problem resolution will work together. The plan should identify responsibilities, lifecycle activities, interfaces, and records rather than exist as a generic template.
Practitioner actions
- Choose and document the lifecycle model and deliverables.
- Record the software safety classification and activities that apply.
- Define responsibilities, reviews, verification methods, configuration management, and problem resolution.
- Keep the plan current when scope, architecture, risk, or suppliers change.
Typical evidence
- Approved software development plan
- Responsibility and review matrix
- Verification strategy and traceability approach
- Configuration-management and problem-resolution plans
Applied examples
How the requirement can appear in a real system
- A robotic-surgery controller plan connects motion-control requirements, independent safety monitoring, bench integration, and system verification.
- A software-as-a-medical-device plan connects iterative releases with clinical-performance, cybersecurity, and deployment evidence.
Example status: Generalized learning examples; not records from a specific organization or project.
5.2Software requirements analysisAre requirements complete, testable, traceable, and connected to risk controls?
Plain-language interpretation
What this means in practice
Translate system needs, intended use, risk controls, interfaces, performance, data, alarms, security, and abnormal behavior into testable software requirements. Requirements should make the expected result and failure response clear.
Practitioner actions
- Define functional, performance, interface, data, alarm, security, and risk-control requirements.
- Include boundary, invalid-input, degraded-mode, and error-handling behavior.
- Provide objective acceptance criteria and traceability to system needs and risk controls.
- Review ambiguity, conflict, completeness, and feasibility before implementation.
Typical evidence
- Controlled software requirements
- Requirements review record
- System-to-software traceability
- Risk-control-to-requirement mapping
Applied examples
How the requirement can appear in a real system
- An infusion-pump requirement defines the permitted rate range, rounding, invalid-entry response, alarm behavior, and acceptance criteria.
- A robotic system requirement defines a motion boundary and the independent response when the limit is approached.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
Requirements tools, issue trackers, and repositories used to create or approve lifecycle records need controls proportionate to their role and failure impact.
5.3Software architectural designDoes the architecture show items, interfaces, allocation, and risk-control independence?
Plain-language interpretation
What this means in practice
Describe how software items interact, where requirements and risk controls are allocated, and how data and control flow across boundaries. Architecture is the basis for integration, segregation, fault handling, and third-party software assessment.
Practitioner actions
- Identify software items, external interfaces, data flows, control flows, and dependencies.
- Allocate requirements and risk controls to architectural elements.
- Define segregation or independence where one element monitors another.
- Identify software of unknown provenance and supporting platforms.
Typical evidence
- Approved architecture diagrams
- Interface specifications
- Requirement and risk-control allocation
- Design-review records and third-party software inventory
Applied examples
How the requirement can appear in a real system
- A robotic system separates user interface, motion controller, safety monitor, sensor interface, and event recording.
- A cloud medical application maps client, application programming interface, algorithm service, database, identity provider, and monitoring.
Example status: Generalized learning examples; not records from a specific organization or project.
5.4Software detailed designIs critical internal logic sufficiently defined for implementation and verification?
Plain-language interpretation
What this means in practice
Describe the internal behavior of software units at the level needed to implement and verify them reliably. Critical algorithms, states, transitions, interfaces, limits, precision, and error handling should not be left implicit in source code.
Practitioner actions
- Define algorithms, states, transitions, data structures, interfaces, calculations, and error responses.
- Give higher-risk units enough design detail to support independent review and focused verification.
- Maintain alignment with architecture, requirements, and risk controls.
- Review updates when implementation reveals a design change.
Typical evidence
- Detailed design specifications
- State and sequence diagrams
- Algorithm descriptions
- Design reviews and traceability
Applied examples
How the requirement can appear in a real system
- A Class C control unit includes a state machine for permitted motion, stop conditions, watchdog behavior, and recovery.
- A medical calculation specifies units, precision, rounding, overflow, missing-data, and out-of-range behavior.
Example status: Generalized learning examples; not records from a specific organization or project.
5.5Software unit implementation and verificationAre software units implemented under control and verified against their design?
Plain-language interpretation
What this means in practice
Use appropriate coding practices, review, static analysis, and unit testing to demonstrate that units implement the design and handle important boundaries and errors. The rigor should reflect the safety class, function, complexity, and credible failure.
Practitioner actions
- Apply controlled coding, source review, and version-control practices.
- Define risk-based unit-test cases, including boundary, negative, and abnormal conditions.
- Use static analysis where it can detect relevant defects.
- Record and assess anomalies rather than treating pass rate or code coverage as the conclusion.
Typical evidence
- Controlled source and build records
- Code-review records
- Static-analysis results and dispositions
- Unit-test cases, results, and anomaly records
Applied examples
How the requirement can appear in a real system
- An embedded controller unit is checked for range limits, timing, invalid sensor values, overflow, and safe-state transition.
- A dosage-calculation unit is tested at minimum, maximum, rounding, missing-data, and unit-conversion boundaries.
Example status: Generalized learning examples; not records from a specific organization or project.
5.6Software integration and integration testingAre interfaces and failure propagation verified as software items are combined?
Plain-language interpretation
What this means in practice
Integrate software items in a controlled sequence and verify the interfaces, data mapping, timing, state behavior, error handling, and risk controls that exist between components.
Practitioner actions
- Plan the integration sequence and expected intermediate configurations.
- Verify interface contracts, data mapping, timing, fault propagation, recovery, and cross-component risk controls.
- Use representative components, simulators, and test environments with controlled limitations.
- Investigate and resolve integration anomalies.
Typical evidence
- Integration plan and build identification
- Interface and integration test results
- Environment and simulator records
- Defect investigations and retest evidence
Applied examples
How the requirement can appear in a real system
- A robotic system verifies communication among console, motion controller, safety monitor, and sensor interfaces during normal and fault conditions.
- A cloud application verifies identity, application programming interface, algorithm, database, queue, and audit-event interactions.
Example status: Generalized learning examples; not records from a specific organization or project.
5.7Software system testingDoes testing demonstrate the integrated software satisfies its requirements?
Plain-language interpretation
What this means in practice
Verify the complete integrated software against approved requirements in representative configurations. Testing should cover normal use, important negative and boundary conditions, fault response, risk controls, and unresolved anomalies.
Practitioner actions
- Trace each applicable software requirement to suitable verification evidence.
- Test end-to-end workflows, error handling, boundary conditions, recovery, and risk controls.
- Control hardware, operating system, configuration, data, and test-tool versions.
- Assess unresolved anomalies for safety, intended use, release, and disclosure.
Typical evidence
- Approved system-test specification
- Executed results and deviations
- Requirements-to-test traceability
- Anomaly assessment and system-test summary
Applied examples
How the requirement can appear in a real system
- A connected medical application is tested through loss and restoration of connectivity, duplicate messages, stale data, and user recovery.
- A therapy controller is tested for valid delivery, invalid parameters, sensor fault, alarm, stop, restart, and retained event history.
Example status: Generalized learning examples; not records from a specific organization or project.
5.8Software releaseIs the released configuration complete, identified, assessed, approved, and reproducible?
Plain-language interpretation
What this means in practice
Release software only after required lifecycle activities are complete, unresolved anomalies are assessed, the exact configuration is identified, and the evidence supports the intended release decision.
Practitioner actions
- Confirm planned reviews, verification, risk-control activities, and records are complete.
- Assess unresolved anomalies and residual risk.
- Identify and archive the approved software, configuration, build inputs, and supporting records.
- Obtain accountable release approval and communicate known limitations.
Typical evidence
- Release checklist and approval
- Build and version identification
- Verification and risk summaries
- Known-anomaly list and released baseline
Applied examples
How the requirement can appear in a real system
- A firmware release identifies application, bootloader, device configuration, compiler, build pipeline, and approved anomaly list.
- A cloud medical-software release identifies service versions, algorithm, infrastructure configuration, database migration, and deployment approval.
Example status: Generalized learning examples; not records from a specific organization or project.
Software maintenance process
2 areas6.1Software maintenance processDoes post-release maintenance preserve lifecycle control?
Plain-language interpretation
What this means in practice
Use a defined process to receive feedback, assess problems and proposed changes, update affected lifecycle records, perform regression testing, control releases, and monitor the fielded software.
Practitioner actions
- Define maintenance intake, prioritization, analysis, implementation, verification, release, and communication.
- Assess effects on requirements, architecture, risk controls, cybersecurity, interoperability, and labeling.
- Select regression testing based on affected functions and interfaces.
- Update baselines and lifecycle records after approved changes.
Typical evidence
- Maintenance procedure and service records
- Change requests and impact assessments
- Regression strategy and results
- Risk updates and approved release records
Applied examples
How the requirement can appear in a real system
- A field connectivity issue is assessed for delayed clinical information, retry behavior, user visibility, and data reconciliation.
- A robotic motor-control patch triggers safety analysis, focused unit testing, hardware integration, system regression, and controlled release.
Example status: Generalized learning examples; not records from a specific organization or project.
6.2Problem and modification analysisIs each problem or modification analyzed before selecting the correction?
Plain-language interpretation
What this means in practice
Characterize the reported behavior, determine whether it can contribute to a hazardous situation, identify affected items and records, and define an appropriately verified correction.
Practitioner actions
- Reproduce or otherwise characterize the problem and affected configurations.
- Assess safety, regulatory, security, data, and intended-use impact.
- Identify affected requirements, architecture, risk controls, code, tests, and documentation.
- Define correction, verification, communication, and field-action needs.
Typical evidence
- Problem report and investigation
- Safety and change-impact assessment
- Correction and verification plan
- Communication, closure, and traceability records
Applied examples
How the requirement can appear in a real system
- A rare input sequence yields an incorrect medical-software result; the analysis traces data validation, calculation state, user visibility, and affected records.
- A watchdog reset interrupts therapy; the analysis covers timing, safe state, alarm, recovery, event log, and affected versions.
Example status: Generalized learning examples; not records from a specific organization or project.
Software risk management
2 areas7.1Software contribution to hazardous situationsAre software functions connected to hazards, causes, sequences, and controls?
Plain-language interpretation
What this means in practice
Integrate software lifecycle work with medical-device risk management. Show how software behavior can contribute to hazardous situations and how risk controls are allocated, implemented, verified, and maintained.
Practitioner actions
- Identify software-related causes and sequences that can contribute to hazardous situations.
- Connect hazards to requirements, architecture, design, interfaces, and risk controls.
- Consider normal use, reasonably foreseeable misuse, faults, and combinations of failures.
- Reassess risk after problems, changes, new information, or control modifications.
Typical evidence
- ISO 14971 risk-management records
- Software hazard or failure analysis
- Risk-control requirements and architecture
- Traceability to verification evidence
Applied examples
How the requirement can appear in a real system
- Unintended robotic motion is traced from command handling and sensor input through motion control, independent monitoring, mechanical constraints, and user response.
- An infusion calculation error is traced from entered concentration through unit conversion, dose computation, display, confirmation, and delivery control.
Example status: Generalized learning examples; not records from a specific organization or project.
Software assurance connection
Apply the requirement to the supported process
IEC 62304 lifecycle records should connect to the organization’s ISO 14971 risk-management process rather than form a separate software-only risk file.
7.2Risk-control implementation and verificationCan the organization show that software risk controls are implemented and effective?
Plain-language interpretation
What this means in practice
Allocate each software risk control to specific requirements and design elements, then verify it under the conditions in which the control must work—including relevant faults and dependencies.
Practitioner actions
- Specify control behavior, limits, response time, independence, and failure response.
- Trace each control through requirement, architecture, implementation, and verification.
- Verify preventive and detective controls in normal and fault conditions.
- Assess whether changes weaken, bypass, or invalidate a control.
Typical evidence
- Risk-control requirements
- Architecture and detailed design
- Unit, integration, and system test results
- End-to-end risk-control traceability
Applied examples
How the requirement can appear in a real system
- An independent motion monitor stops a robotic actuator when commanded and measured position differ beyond a defined limit.
- A medical application rejects invalid clinical input, identifies the error to the user, prevents calculation, and retains the event as required.
Example status: Generalized learning examples; not records from a specific organization or project.
Configuration management and problem resolution
3 areas8.1Configuration identification and controlCan every released software configuration and dependency be identified and reproduced?
Plain-language interpretation
What this means in practice
Identify the software items, versions, third-party components, build inputs, configuration data, and records needed to know what was tested and released. Control changes and preserve reproducible baselines.
Practitioner actions
- Define configuration items and naming or version rules.
- Control source, requirements, design, tests, tools, build scripts, configuration, and release artifacts.
- Record third-party and software-of-unknown-provenance versions.
- Create and archive approved baselines that can be reconstructed.
Typical evidence
- Configuration-management plan
- Controlled repositories and access records
- Baseline and build records
- Third-party software inventory and released bill of materials
Applied examples
How the requirement can appear in a real system
- An embedded baseline includes firmware, bootloader, device configuration, compiler, libraries, test equipment, and release package.
- A cloud baseline includes application services, model, application programming interfaces, infrastructure-as-code, database schema, feature flags, and operating configuration.
Example status: Generalized learning examples; not records from a specific organization or project.
8.2Change controlAre changes justified, assessed, approved, verified, and included in a new controlled baseline?
Plain-language interpretation
What this means in practice
Control the reason, scope, approval, implementation, verification, and release of software changes. Change impact should cover requirements, design, risk, cybersecurity, interfaces, testing, labeling, and fielded configurations as relevant.
Practitioner actions
- Describe the change and affected software items and versions.
- Assess lifecycle, safety, security, data, interface, and regulatory impact.
- Approve the implementation and regression strategy before release.
- Update affected records and establish the new baseline.
Typical evidence
- Approved change request
- Impact and risk assessment
- Implementation and review records
- Regression results and updated baseline
Applied examples
How the requirement can appear in a real system
- An alarm-logic change is assessed for requirements, timing, displayed message, audible output, event history, user response, and regression.
- A library upgrade is assessed for changed behavior, known vulnerabilities, interfaces, build compatibility, licensing, and test coverage.
Example status: Generalized learning examples; not records from a specific organization or project.
9.1Problem reporting and resolutionAre software problems investigated, risk-assessed, corrected, verified, and closed with traceability?
Plain-language interpretation
What this means in practice
Maintain a controlled path from problem detection through investigation, safety and regulatory assessment, root cause, correction, verification, communication, and closure. A closed ticket should show why the result is acceptable.
Practitioner actions
- Capture the problem, affected versions, detection source, reproducibility, and observed impact.
- Assess safety, reportability, cybersecurity, data, and field consequences.
- Determine root cause or document justified limits in the investigation.
- Verify the correction and any compensating controls before closure.
Typical evidence
- Problem report and triage
- Investigation and root-cause record
- Risk and regulatory assessment
- Correction, verification, communication, and closure records
Applied examples
How the requirement can appear in a real system
- An unauthorized state transition is traced through requirements, state logic, event conditions, risk controls, affected versions, and correction testing.
- A field display freeze is assessed for whether therapy continues, what the user sees, alarm behavior, recovery, event history, and communication.
Example status: Generalized learning examples; not records from a specific organization or project.
Software of unknown provenance
SOUP and third-party software
Third-party origin does not remove lifecycle responsibility. Control the actual component used, the device role it performs, what is known and unknown about it, and how changes are monitored.
- 01
Identify
Name the component, exact version, source, license, dependencies, and released configuration.
- 02
Define use
Explain the function, interfaces, data, failure contribution, and reliance within the device.
- 03
Review evidence
Evaluate supplier information, known anomalies, service history, vulnerabilities, and available verification.
- 04
Control risk
Specify architectural, operational, monitoring, and verification controls for important failures.
- 05
Maintain
Monitor new versions, anomalies, vulnerabilities, supplier notices, obsolescence, and replacement triggers.
Choose the right assurance framework
IEC 62304 and CSV/CSA are related, not interchangeable
| Dimension | IEC 62304 lifecycle | CSV / CSA for non-product software |
|---|---|---|
| Primary scope | Software that is a medical device or part of a medical device. | Computerized systems supporting production, laboratory, quality, business, or regulated records and decisions. |
| Examples | Embedded control, firmware, software as a medical device, robotic control, medical application. | eQMS, manufacturing execution system, laboratory system, enterprise system, spreadsheet, validation tool. |
| Risk lens | Medical-device safety and software contribution to hazardous situations, integrated with ISO 14971. | Product quality, patient safety, data integrity, regulatory process, record, and decision impact. |
| Lifecycle | Development, maintenance, risk management, configuration management, and problem resolution. | Intended use, requirements, supplier evidence, validation, release, operation, change, periodic review, and retirement. |
| Testing | Software-class and risk-informed unit, integration, system, risk-control, regression, and release evidence. | Risk-based scripted, unscripted, exploratory, automated, supplier, procedural, and operational evidence. |
A connected medical-device program may need both: IEC 62304 for product software and CSV/CSA for the development, QMS, manufacturing, laboratory, and service systems that support it.
End-to-end application
Robotic surgical motion-algorithm change
This generalized example demonstrates the reasoning path; it is not a completed project, validation record, or research result.
- Change definitionDefine the revised motion behavior near a mechanical limit, affected software items, configurations, and intended benefit.
- RequirementsUpdate limits, timing, commanded response, safe-state behavior, alarms, event recording, and acceptance criteria.
- ArchitectureConfirm allocation among motion controller, sensor input, independent monitor, mechanical constraint, user interface, and recorder.
- Risk managementReassess hazardous sequences, independence, common-cause failures, user response, and residual risk with ISO 14971.
- Implementation and unit evidenceReview changed code and test boundary, precision, timing, invalid input, state transition, and failure behavior.
- IntegrationChallenge controller, sensors, safety monitor, actuator, event log, and user feedback under normal and fault conditions.
- System and regressionVerify intended motion and safety behavior in representative configurations and run targeted regression on affected and dependent functions.
- Release and baselineAssess anomalies, complete traceability, identify the exact configuration, approve release, and preserve a reproducible baseline.
- Post-release controlMonitor complaints, service data, safety signals, cybersecurity information, and relevant performance or anomaly trends.
Review challenge
Common implementation mistakes
Checklist-only implementation
Connect each lifecycle activity to intended software behavior, safety class, credible failure, risk control, and evidence.
Classifying by complexity
Determine safety classification through potential harm and the risk-control architecture using the official rules.
Keeping software risk separate
Integrate software contribution, risk controls, verification, and change with ISO 14971 risk management.
Using unit coverage as proof
Use coverage as one diagnostic measure; retain integration and system evidence for complete behavior.
Uncontrolled third-party software
Identify the exact component, version, role, known anomalies, safety impact, controls, and update triggers.
Architecture that no longer matches
Update architectural decisions when interfaces, services, safety controls, or deployment change.
Closing a problem without safety analysis
Document the safety and regulatory assessment even when the correction appears technically small.
Treating a library update as routine
Assess behavior, vulnerabilities, interfaces, build compatibility, regression, and the released baseline.
Confusing product software with CSV
Use IEC 62304 for medical-device software lifecycle; separately assess production and QMS software under applicable CSV/CSA obligations.
Release readiness
Practitioner checklist
- 1
Software is within IEC 62304 scope and the applicable edition is identified.
- 2
Safety classification and its rationale are documented using the official rules.
- 3
Development and maintenance activities are planned and owned.
- 4
Requirements are testable and traceable to system needs and risk controls.
- 5
Architecture identifies software items, interfaces, allocation, segregation, and third-party software.
- 6
Critical design and unit-verification evidence is proportionate to safety and complexity.
- 7
Integration and system testing cover interfaces, boundaries, errors, faults, and risk controls.
- 8
Release identifies the exact configuration and assesses unresolved anomalies.
- 9
Maintenance and modification analysis preserve lifecycle control after release.
- 10
Software risk work is integrated with ISO 14971.
- 11
Baselines and changes are reproducible and controlled.
- 12
Problems remain traceable from report through risk assessment, correction, verification, and closure.
Primary references
Sources and related standards
- IEC 62304:2006+AMD1:2015 CSVOfficial IEC Webstore record; consult a licensed copy for normative requirements.
- ISO 14971:2019Medical-device risk-management standard record.
- ISO 13485:2016 practical guideQuality-management-system context for medical devices.
Revision history
| Version | Date | Change |
|---|---|---|
| 1.0 | 13 September 2026 | Initial practitioner guide based on the supplied CSVtoCSA content pack; source status and links reviewed. |