IEC 62304 Software Lifecycle

IEC 62304 establishes a software lifecycle framework

IEC 62304 defines lifecycle processes, activities and tasks for medical-device software. It applies when software is itself a medical device and when software is embedded in or forms an integral part of a medical device.

The standard tells the manufacturer what software-development and maintenance controls must be established. It does not prescribe a programming language, development model, architecture, test tool or specific document template. The organisation can use iterative, incremental or sequential methods provided the required activities, controls and objective evidence are present.

IEC 62304 does not cover validation and final release of the complete medical device—even where the device consists entirely of software. Those conclusions depend on the wider design-control, risk-management, usability, clinical or performance and regulatory processes explained in MTL-104 — Design Controls and Technical Documentation.

The five connected process groups

These processes are not separate departments or document folders. A problem report may trigger risk analysis, requirements change, implementation, regression testing, configuration updates and a maintenance release. The value lies in the connections.

Software safety classification determines the required rigour

The manufacturer assigns each software system a safety class based on the possible harm that could result if the software contributes to a hazardous situation. Unless a rationale supports a lower class, the initial assumption is Class C.

For classification, teams should not use an optimistic probability of software failure to argue that severe harm is unlikely. The analysis asks what harm could result if the relevant software behaviour occurs and whether adequate controls external to that software prevent or reduce the possible harm.

Software safety class is not the same as EU MDR or IVDR regulatory class, and it is not the same as the FDA's Basic or Enhanced documentation level. Each classification answers a different question and needs its own rationale.

Plan the software work around the actual system

The software-development plan describes how the lifecycle will be performed for the device and kept current as the project changes. It should coordinate the software team with system engineering, risk management, usability, cybersecurity, verification, suppliers and release management.

• Lifecycle model, activities, deliverables, responsibilities and interfaces.
• Software safety classification and the activities applicable to each software item.
• Standards, methods, tools, coding practices and acceptance criteria.
• Requirements, architecture, design, implementation, integration and test strategy.
• Traceability, configuration management and problem-resolution arrangements.
• SOUP selection, qualification, anomaly assessment and monitoring.
• Software risk-management and cybersecurity interfaces.
• Verification independence where required by the QMS or risk.
• Release, maintenance, update and end-of-support arrangements.

A generic procedure is not a project plan. The plan should identify the actual software system, repositories, build environment, test levels, evidence, suppliers, responsibilities and release route.

Software requirements must support design and objective testing

Software requirements are derived from system requirements, intended purpose, interfaces, risk controls, usability, security, data, performance and applicable regulatory or product standards. MTL-103 — User Needs and Design Inputs explains how these sources become approved, testable design inputs.

Requirements should identify their source and verification method. Bidirectional traceability should show that every applicable system requirement and software risk control is implemented and tested, while also exposing software features or tests that have no approved basis.

Architecture makes safety behaviour understandable

The software architecture identifies software items, their responsibilities, interfaces and dependencies. It should show how requirements and risk controls are allocated and how the system behaves under normal, degraded and fault conditions.

• Define the boundary between software, hardware, users and external services.
• Identify software items, SOUP, platforms, operating systems and communication paths.
• Show control flow, data flow, states, timing and concurrency where safety depends on them.
• Allocate risk controls and identify assumptions about other system elements.
• Describe fault detection, containment, recovery and safe-state behaviour.
• Identify security boundaries, privileges, trust relationships and update mechanisms.
• Control interfaces precisely enough for independent implementation and verification.

Segregation can allow software items to have different safety classes, but drawing boxes is not sufficient. The architecture must demonstrate that one item cannot adversely affect another in a way that defeats the classification rationale. Shared memory, processors, operating systems, communication resources and common services all need consideration.

Detailed design, units and implementation

For the applicable safety class, detailed design refines architectural items into software units that can be implemented and verified. The level of detail should be sufficient for the code and its expected behaviour to be reviewed, tested and maintained.

Implementation should follow defined methods and coding practices. Unit verification may combine reviews, static analysis, automated tests, analysis and other methods appropriate to the language, technology, risk and design. Results need objective acceptance criteria and controlled records—not merely evidence that a tool ran.

Integration testing and software-system testing answer different questions

Integration brings software units and items together according to a planned sequence. Integration testing focuses on interfaces and interactions: data exchange, control flow, timing, resources, error propagation and behaviour across item boundaries.

Software-system testing demonstrates that the integrated software meets its approved software requirements. Tests should include normal operation, boundary conditions, foreseeable misuse, abnormal inputs, fault conditions, risk controls and recovery behaviour where applicable.

• Identify the precise software, hardware, data and environment configuration tested.
• Trace tests to software requirements and risk controls.
• Use pre-defined expected results and objective acceptance criteria.
• Control simulators, test tools, test data, stubs and automated test software.
• Record actual results, deviations, anomalies and resulting decisions.
• Assess regression scope using the changed items, interfaces, risks and previous evidence.
• Do not treat code coverage as a substitute for requirements and risk-based test design.

Release is a controlled technical decision

Before release, software verification must be complete to the planned extent, residual anomalies must be evaluated, and the released configuration must be identifiable and reproducible. The software should be archived with the records and tools needed to support the required retention and maintenance period.

A software release record does not by itself authorise release of the medical device. The complete device must still satisfy validation, risk, clinical or performance, manufacturing and regulatory release requirements.

Maintenance is planned lifecycle work—not emergency coding

The maintenance process receives feedback, problem reports, support information, vulnerability findings, platform changes and requested modifications. Each item is analysed for its effect on the released software, product requirements, risk, security, usability, regulatory status and installed devices.

Approved modifications are implemented using the relevant development-process activities. The effort can be proportionate, but requirements, design, code, verification, configuration and release records must remain coherent. Distribution and installation arrangements should ensure that the intended version reaches the intended devices and that failures can be detected and recovered.

End of support also requires control. The manufacturer should understand component support dates, operating-system changes, vulnerability handling, field population, rollback capability, data migration and the consequences of devices that cannot be updated.

Configuration management and problem resolution protect the evidence

Configuration management is not simply using Git. A source repository does not automatically control requirements, SOUP, build environments, test assets, released binaries, device compatibility or field deployment.

SOUP needs deliberate selection and lifecycle control

Software of Unknown Provenance—commonly called SOUP—is software already developed and generally available that was not developed for incorporation into the medical device, or for which adequate development-process records are unavailable.

• Identify the SOUP item, supplier, exact version and role in the architecture.
• Define the functional, performance, safety and security requirements it must satisfy.
• Review available documentation, provenance, support, licences and known anomalies.
• Evaluate failure modes and possible contributions to hazardous situations.
• Provide controls around the component where its internal evidence is insufficient.
• Verify integration and the behaviour on which the medical device depends.
• Monitor new versions, vulnerabilities, end-of-support information and field experience.
• Assess and control every update rather than inheriting supplier release decisions.

Open-source software is not automatically SOUP, and commercial software is not automatically well controlled. The decisive issue is whether the manufacturer has adequate lifecycle evidence and control for the intended medical-device use.

Software risk management is part of device risk management

IEC 62304 connects software activities to the manufacturer's ISO 14971 process. Software analysis identifies causes, events and behaviours that can contribute to hazardous situations; risk controls become requirements and architecture; verification demonstrates their implementation and effectiveness.

MTL-302 — ISO 14971 Risk Management explains the complete device risk-management process. Software teams should avoid turning every defect into a separate “software hazard”. The useful chain remains hazard, sequence of events, hazardous situation and harm, with software behaviour described accurately within that chain.

IEC 62304 alone is not a complete cybersecurity lifecycle. Connected devices also need security-risk management, secure development, threat modelling, security requirements, vulnerability monitoring and secure update controls. Applicable sources may include IEC 81001-5-1, current FDA cybersecurity guidance and MDCG cybersecurity guidance.

Iterative and automated delivery can comply

IEC 62304 does not require waterfall development. Teams may use Scrum, Kanban, continuous integration, automated testing and frequent internal builds. Compliance depends on controlling the lifecycle outputs and decisions—not on adopting particular ceremony names.

• Maintain approved product and software requirements outside transient backlog wording.
• Keep architecture current as implementation and interfaces evolve.
• Apply definition-of-done criteria that include risk, traceability, review and verification.
• Control automated pipelines, tools, dependencies, test assets and build environments.
• Distinguish a deployable build from an approved medical-device release.
• Retain objective evidence for the exact configuration released.
• Assess changes and regression scope continuously rather than at the end of a release train.

Worked example: analyser control software

Consider an IVD analyser containing a Linux application and separate controller firmware. The Linux application manages workflows, results, users and communication. The controller firmware operates measurement hardware, heating, stirring and safety monitoring.

The software architecture defines the two binaries, their protocol, responsibilities, states and failure behaviour. Requirements specify that loss of communication allows only the current safe physical step to complete before motion stops, followed by automatic reconnection and controller self-test.

Risk analysis considers incorrect assay parameters, timing or measurement data; loss or duplication of commands; controller failure; stale results; database corruption; unauthorised changes and unsafe recovery. Controls are allocated across independent controller limits, application checks, protocol integrity, audit records and user-visible fault handling.

Each binary has its own version and verification evidence, while the released system identifies the approved combination. Integration testing challenges communication loss, timing, concurrency, restart and incompatible versions. Maintenance analysis then determines whether a change to either binary affects the interface, risks, regression scope, supported combinations or device validation.

Common misconceptions