Medical software · lifecycle evidence · risk control
IEC 62304 – the pivotal standard for medical device software
Code is only one layer of the product
IEC 62304 makes the decisions behind medical software visible. It connects requirements, architecture, risks, tests, releases and changes into one controlled lifecycle.
Enter the lifecycle ↓Safety class
Ano injury Bnon-serious injury Cdeath or serious injuryRequirements
purpose · functions · controlsArchitecture
items · interfaces · segregationImplementation
units · reviews · configurationVerification
tests · results · traceabilityRelease
baseline · anomalies · approvalMaintenance
problems · changes · regressionThe regulatory value
IEC 62304 turns engineering work into reviewable evidence
Explain
What the software is intended to do and how its architecture supports that purpose.
Control
How failures, changes, configurations and unresolved anomalies are managed.
Demonstrate
How requirements and risk controls lead to objective verification evidence.
01
Why IEC 62304 matters #
Medical software may have no moving parts, sterile packaging or physical materials. Yet behind a seemingly simple interface lies a tightly connected system of requirements, algorithms, data flows, risk controls, tests, configurations and updates. If those elements are not controlled, even well-written code can become an unsafe medical device.
IEC 62304 provides the framework for bringing that system under control.
Officially titled “Medical device software – Software life cycle processes,” the standard defines processes, activities and tasks for developing and maintaining medical device software. It applies both to software embedded in a medical device and to software that is itself a medical device. The current consolidated edition is IEC 62304:2006+A1:2015.
The standard does not tell manufacturers what medical claims they may make, how to classify their product under the MDR or IVDR, or whether the clinical evidence is sufficient. Its role is different. It requires the manufacturer to show that the software was developed, released, maintained and changed through a controlled and risk-based process.
IEC 62304 controls the software lifecycle. It does not replace the complete regulatory evaluation of the medical device.
02
Two disciplines meet in one standard #
IEC 62304 sits at the meeting point of two professional worlds.
Architecture
Source code
Version control
Defect tracking
Regression testing
62304
Risk acceptability
Quality records
CAPA
Vigilance
Technical documentation
Software engineers are familiar with architecture, source code, version control, defect tracking, integration testing and release management. They may be less familiar with regulatory concepts such as risk acceptability, vigilance, CAPA and controlled technical documentation.
Medical-device professionals understand quality systems, risk management and conformity assessment. They may be less comfortable with software decomposition, configuration items, regression testing, unresolved anomalies and software of unknown provenance.
IEC 62304 connects these worlds. It turns engineering work into regulatory evidence and regulatory expectations into concrete development activities. This is also why implementation cannot be delegated entirely to either the regulatory team or the developers.
03
The evidence chain behind the software #
The core principle of IEC 62304 is straightforward. The manufacturer should be able to explain what the software is intended to do, what could go wrong, how the system was designed to control those risks, how the controls were tested, which version was released and how future problems and changes will be managed.
Purpose
Medical functionRequirements
Specified behaviourRisk controls
Implemented measuresVerification
Objective evidenceRelease
Known configurationMaintenance
Controlled changeIntended purpose and system requirements lead to software requirements. Software requirements influence architecture and detailed design. Identified risks lead to risk-control measures. Those measures become requirements that must be implemented and verified. Test results must refer back to the relevant requirements. The released configuration must correspond exactly to the version described by the evidence.
If one link is missing, the technical documentation for the medical software may contain many files while still failing to demonstrate control.
04
Software safety classification #
IEC 62304 assigns the software system a safety class of A, B or C. This classification determines which lifecycle activities and documentation requirements apply.
No injury
Failure of the software cannot result in injury or damage to health.
Baseline lifecycle controlsNon-serious injury
Software failure could result in an injury that is not serious.
Additional design and verification evidenceDeath or serious injury
Software failure could result in death or serious injury.
Most extensive lifecycle evidenceSoftware safety class A, B or C
Regulatory device class
It is important not to confuse the IEC 62304 safety classes with MDR classes I, IIa, IIb and III or IVDR classes A, B, C and D. They are separate classification systems addressing different questions.
The relevant distinction is the severity of harm that could result from software failure, not whether the software causes harm directly or indirectly. The classification rationale should be connected to the product’s risk-management process.
If the manufacturer relies on risk controls outside the software when assigning the class, those controls and their effectiveness must be clearly documented. A safety class should never be selected merely because it reduces the amount of required work.
05
What the manufacturer must control #
Software development planning
The manufacturer defines how the software will be developed, verified, released and maintained. The plan identifies responsibilities, activities, procedures, deliverables, configuration controls and links to risk management.
The plan should reflect the real development model. Agile development can be compatible with IEC 62304 when requirements, risks, reviews, testing, changes and releases remain controlled and traceable.
Software requirements
Requirements describe what the system must do and under which conditions it must operate. They may address functionality, inputs, outputs, interfaces, data handling, performance, alarms, security, usability and risk controls.
Vague requirements create vague tests. Safety-related requirements should be traceable to the hazards and risk-control measures from which they originate.
Architecture and detailed design
The architecture explains how the system is divided into items and how those items interact. It identifies interfaces, dependencies, data flows, segregation measures and components whose failure may affect safety.
For higher safety classes, the standard expects increasing detail about software items and units. The purpose is to make the safety-relevant structure understandable and reviewable, not to document code line by line.
Implementation and verification
Implementation follows approved requirements and design. Verification demonstrates that each development output satisfies its input requirements.
Testing may include unit, integration, system, interface and regression testing. Persuasive evidence identifies the requirement, tested configuration, acceptance criteria, result and disposition of deviations.
Configuration management
The manufacturer must identify the regulated version, source-code baseline, third-party components, build environment, documentation, test evidence and unresolved anomalies.
For cloud-based products, configuration management may also cover server-side components, APIs, infrastructure dependencies, models, datasets and services that can change independently of the user-facing application.
Problem resolution
A problem report should not disappear when a developer closes a ticket. The manufacturer evaluates its safety relevance, determines whether corrective action is needed, assesses the effect of any change, performs appropriate regression testing and retains the records.
Not every anomaly must necessarily be corrected before release. Unresolved anomalies must still be documented, evaluated and justified.
Software maintenance
The lifecycle continues after release. Maintenance includes evaluating feedback, analysing problems, implementing changes, verifying modifications and releasing updated configurations.
IEC 62304 supports this process, but it does not replace the complete post-market surveillance system required by the MDR or IVDR.
06
IEC 62304 works inside a larger system #
IEC 62304 is powerful because it focuses closely on the software lifecycle. That focus also means it cannot stand alone.
Quality-management framework
Medical-device risk management
Software lifecycle processes
Usability engineering
Clinical or performance evidence
Cybersecurity throughout the lifecycle
ISO 13485 provides the broader quality-management framework in which responsibilities, document control, supplier management, CAPA and other organisational processes operate.
ISO 14971 provides the medical-device risk-management process. IEC 62304 connects software activities to that process but does not replace it.
IEC 62366-1 addresses usability engineering. A function can be technically correct and still create risk if users misinterpret an output, overlook an alert or select the wrong patient.
IEC 62304 helps control development, maintenance and changes, but it does not provide a complete cybersecurity framework. Security architecture, threat modelling, vulnerability management, secure updates and post-market monitoring require additional attention. MDRC discusses these elements in its guidance on cybersecurity for medical software.
Clinical evaluation under the MDR or performance evaluation under the IVDR remains a separate requirement. Software that has been developed perfectly can still lack sufficient evidence that its output is clinically or diagnostically meaningful.
07
What IEC 62304 does not cover #
The limits of the standard are as important as its requirements.
Development process
Maintenance process
Software risk linkage
Configuration management
Problem resolution
Device qualification and classification
Final product validation and release
Clinical or performance evaluation
Complete usability and cybersecurity evidence
MDR or IVDR conformity assessment
The IEC itself states that IEC 62304 does not cover final validation and final release of the medical device, even when the device consists entirely of software. The manufacturer must therefore integrate the software lifecycle into a broader product-development and validation process.
IEC 62304 does not determine whether software qualifies as a medical device, which regulation applies or which MDR or IVDR risk class is appropriate. Those decisions follow from the software’s intended purpose and regulatory characteristics. See the MDRC explanation of whether software is a medical device or an accessory.
It also does not establish the sufficiency of clinical evidence, replace usability engineering, complete the cybersecurity file or satisfy every requirement of technical documentation. An IEC 62304 compliance statement cannot, on its own, demonstrate conformity with the MDR or IVDR.
08
IEC 62304 and CE marking #
The MDR and IVDR require software to be developed and manufactured according to the state of the art, taking account of lifecycle principles, risk management, information security, verification and validation. IEC 62304 offers a recognised structure for generating much of this evidence.
Using a standard remains voluntary. Under EU rules, a presumption of conformity applies only where the reference to a harmonised standard has been published in the Official Journal of the European Union, and only for the regulatory requirements covered by that standard. This distinction is explained in the European Commission’s guidance on standardisation for medical devices.
Compliance with IEC 62304 can strengthen the manufacturer’s conformity argument, but it does not automatically result in CE marking or approval by a Notified Body.
The complete route still requires correct qualification and classification, technical documentation, risk management, a quality-management system, usability engineering, cybersecurity, clinical evaluation or performance evaluation, post-market surveillance and, where required, conformity assessment by a Notified Body.
09
The most common implementation mistake #
One of the most common failures is treating IEC 62304 as a documentation exercise performed after development is complete.
Teams then try to reconstruct requirements from completed code, connect test results to requirements that did not exist when the tests were written and justify architectural decisions that were never formally recorded.
Reconstructed requirements
Unclear design decisions
Orphaned test results
Weak change history
Planned requirements
Recorded architecture
Traceable verification
Controlled releases
The first approach creates documents, but it rarely creates convincing traceability. IEC 62304 works best when it shapes development from the beginning. Documentation should emerge from controlled engineering activities rather than being written later to create the appearance of control.
10
The bottom line #
IEC 62304 is not simply a standard about writing software documents. It is a framework for making the safety of medical software explainable.
It requires the manufacturer to demonstrate how the software was planned, designed, implemented, verified, released, maintained and changed. It turns invisible development decisions into reviewable evidence and connects the software lifecycle to medical-device risk management.
The standard does not replace MDR or IVDR compliance, and it does not grant CE marking. What it does is provide one of the strongest foundations for showing that medical software was not merely coded until it appeared to work, but developed as a controlled medical product whose risks, versions and changes remain understood throughout its lifecycle.
For manufacturers pursuing CE marking for medical software, that distinction can determine whether the technical documentation merely looks complete or can withstand serious regulatory scrutiny.
The real outcome
A lifecycle that remains understandable after the original developers have moved on
Strong IEC 62304 implementation creates more than an audit trail. It gives the manufacturer a reliable way to understand the effect of a defect, assess a proposed change and release the next version without losing control of the medical product.
That is where software engineering becomes regulatory evidence.
Software lifecycle compliance
Need to turn your development process into a defensible IEC 62304 evidence system?
Discuss your software lifecycle ↗From the knowledge centre
