Software Lifecycle – IEC 62304

What Is Software Life Cycle — IEC 62304?

IEC 62304 is the standard defining the development and maintenance processes for medical device software. Its subject is not a laboratory test but the assessment of process and documentation. Software is classified into safety class A, B or C according to the harm it could cause the patient; the required process and records deepen as the class rises.

Purpose of Software Life Cycle — IEC 62304

The purpose is to show the software was developed through a planned, traceable and verified process. For devices where software errors can have clinical consequences, this process is the fundamental basis of product safety.

Which Products Is Software Life Cycle — IEC 62304 Applied To?

Embedded medical device software
Software as a Medical Device (SaMD)
Mobile health applications
Image processing and decision support software
Device configuration and monitoring software

In Which Sectors Is Software Life Cycle — IEC 62304 Used?

Medical DevicePharmaceuticalsHealthcareBiotechnologySoftware

Standards Related to Software Life Cycle — IEC 62304

IEC 62304medical device software lifecycle processes test

Software Life Cycle — IEC 62304 Conditions

Safety class: A, B or C, according to the harm the software could cause
Subject of assessment: Development plan, requirements analysis, architecture, unit and integration verification, version management
SOUP: Identification and risk assessment of software of unknown provenance
Maintenance: Problem resolution, change control and post-market processes

Equipment for Software Life Cycle — IEC 62304

Document and record review environment
Version control and traceability tools
Test recording and reporting systems
Static and dynamic code analysis tools (where applicable)

Sample Requirements for Software Life Cycle — IEC 62304

The software development plan and requirements documents must be provided.
Architectural design and interface definitions must be shared.
Verification and validation records must be complete.
The SOUP list and its associated risk assessment must be provided.
Version and configuration records must be traceable.

Duration of Software Life Cycle — IEC 62304

Assessment duration depends on the software's safety class and the maturity of the documentation. Incomplete traceability is the most common cause of delay.

Software Life Cycle — IEC 62304 Procedure

1The software's intended use and safety class are determined.
2The software development plan is reviewed.
3Traceability between requirements, architecture and design records is verified.
4Unit, integration and system verification records are reviewed.
5SOUP components and their risks are assessed.
6Maintenance and change control processes are reviewed.
7Findings are reported.

Software Life Cycle — IEC 62304 Acceptance Criteria

The acceptance criterion is selected from the relevant section of the standard according to the device's contact type (surface, externally communicating, implant), contact duration and intended use. The assessment relies not on a single test result but on the biological evaluation plan carried out under ISO 10993-1; this page therefore gives no fixed limit.

Evaluation of Results

The assessment relies on whether the process covers all activities the standard requires for the relevant class and on the traceability of records. For class B and C software, architectural design and unit verification records are additionally required.

Software Life Cycle — IEC 62304 Report

Device identification, model and lot number, if any
Device contact type, duration and intended use
Standard and section applied
Extraction or sample preparation conditions
Cell line, test system or test rig used
Controls and their results
Observations, measurement results and assessment
A statement that the result applies only to the specimen submitted for testing

Accreditation

EUROLAB holds internationally recognised accreditation obtained from accreditation bodies party to the IAF and ILAC multilateral recognition arrangements, under ISO/IEC 17025 for laboratory testing, ISO/IEC 17020 for inspection and surveillance, and ISO/IEC 17021-1 and ISO/IEC 17065 for system and product certification. This chain ensures the reports and certificates issued are accepted worldwide.

Whether this test can be offered within accredited scope depends on your product and the standard applied; since accreditation is method-based, the scope is confirmed in writing at the quotation stage.

Scope and authorisations

Related Regulations

EU 2017/745 Medical Device Regulation (MDR)
Medical Device Regulation (Türkiye)
ISO 14971 (risk management for medical devices)
ISO 13485 (medical devices — quality management system)

Medikal Cihaz Testleri — What Does This Testing Field Cover?

The section below describes the field that the Software Life Cycle test belongs to; the conditions and acceptance criteria of this particular test are given in the sections above. The scope specific to your product is confirmed in writing at the quotation stage.

Medical device testing shows that a device is safe for the patient and the user and maintains its intended performance. In this family safety is not only about avoiding harm; a device failing to perform its expected function is also treated as a risk. A monitor missing an alarm or a pump delivering the wrong dose is directly a patient safety event.

At the centre of the field is RISK MANAGEMENT, and this is what sets medical apart from other sectors. The risk management process run under ISO 14971 also determines which tests are required. The test list is not copied from a table of standards; it is derived and justified from the device's intended use, the nature and duration of patient contact, the use environment and foreseeable misuse.

Assessment consists of several separate bodies of work, each with its own set of standards. Biocompatibility runs through the ISO 10993 series, electrical device safety through the IEC 60601 series, sterilisation through ISO 11135/11137/17665, packaging through ISO 11607, software through IEC 62304 and usability through IEC 62366. The quality system (ISO 13485) is the framework that binds these together.

Which tests are required is determined by the device's CLASS and its MODE OF CONTACT WITH THE BODY. A product in brief contact with skin and an implant entering the bloodstream do not go through the same test set; the scope is set by a biological evaluation plan prepared under ISO 10993-1. That plan justifies in writing which endpoints are required and why the others are not.

Packaging and sterilisation are taken as seriously as the device itself in this field. For a sterile device the packaging is not a transport container but the barrier that maintains sterility; if the barrier is breached, the device is no longer sterile. Packaging processes are therefore validated and shelf life is supported by real-time ageing data.

For devices containing software, assessment shifts from testing towards PROCESS assurance. IEC 62304 defines which development and verification steps must be followed according to the safety class of the software; the evidence is the traceability of the development process. Testing software does not make it safe — the process record does.

The clinical side is a separate column of the technical file. Test reports show that the device is technically safe; clinical evaluation establishes that the device delivers the intended clinical benefit and that the benefit-risk balance is acceptable. Neither replaces the other.

Method groups in this field

Biocompatibility
Cytotoxicity, irritation, skin sensitisation, systemic toxicity, haemocompatibility, genotoxicity and local effects after implantation. The required endpoints are set by the ISO 10993-1 plan.
Electrical device safety
IEC 60601-1 basic safety and essential performance; EMC, alarm, usability and environmental requirements through the collateral standards.
Sterilisation validation
Validation of sterilisation processes by ethylene oxide, radiation or moist heat; bioburden and sterility assurance level studies.
Packaging
Integrity of the sterile barrier system, seal strength, distribution simulation and shelf-life studies.
Microbiological tests
Bioburden determination, sterility testing, bacterial endotoxin and, where required, carrier validation studies.
Software and usability
IEC 62304 life cycle evidence and use-error focused evaluation under IEC 62366.

Commonly confused in this field

Cytotoxicity alone is not evidence of biocompatibility; the required set of endpoints is determined and justified according to ISO 10993-1.
An ISO 13485 certificate does not confer CE marking; classification under the MDR, the technical file and the notified body process run separately.
Accelerated ageing does not replace real-time ageing; a shelf life claim is supported by real-time data.
A change of material (supplier, pigment, sterilisation method) may require the biological evaluation to be repeated; it is not a silent change.
An assessment made without the collateral and particular standards for IEC 60601-1 is incomplete; which -1-x and -2-x standards were applied must appear in the report.
In vitro diagnostic devices fall under the IVDR rather than the MDR, and laboratory equipment is often on the IEC 61010-1 side.

Which decisions these results support

MDR/IVDR technical file and notified body assessment
Completing the biological evaluation plan
Sterilisation and packaging validation
Determining shelf life and storage conditions
Determining the scope of reassessment after a design change

Related Tests

Frequently Asked Questions About Software Life Cycle — IEC 62304

How is the safety class determined?

By the harm the software could cause on failure. Software with no possibility of harm is class A, non-serious injury B, and death or serious injury C. Classification is justified through the risk management file.

Can open-source libraries be used?

Yes, but they must be identified as SOUP, their versions pinned, and their known defects included in the risk assessment.