What Is Software IEC 62304?
IEC 62304 assessment examines whether the development, maintenance and risk management of medical device software conform to the life-cycle processes prescribed by the standard. This is not a product test but a PROCESS and DOCUMENTATION assessment: it is evaluated not by running the software itself, but through evidence of the process that produced it.
Purpose of Software IEC 62304
The purpose is to show that the software has been developed with the rigour appropriate to its safety class, and that software-related risks are managed systematically.
Which Products Is Software IEC 62304 Applied To?
- Embedded medical device software
- Software as a Medical Device (SaMD)
- Mobile health applications (if qualifying as a medical device)
- Image processing and decision support software
- Device control and monitoring software
In Which Sectors Is Software IEC 62304 Used?
Standards Related to Software IEC 62304
- IEC 62304medical device software lifecycle processes test
- ISO 14971
- IEC 62366-1usability engineering in medical devices test
- IEC 82304-1
- ISO 13485medical device quality management system test
- ISO 11607end product sterile barrier packaging test
Software IEC 62304 Conditions
- Software safety class
- A, B or C; determined according to the harm the software failure could cause, and directly changes the rigour of process required
- SOUP management
- Software components of unknown provenance (SOUP) are identified and their risks are assessed
- Risk linkage
- Carried out integrated with the ISO 14971 risk management process
Equipment for Software IEC 62304
- Document and record review (technical assessment)
- Review of configuration-management and traceability tools
- Assessment of test records and coverage reports
Sample Requirements for Software IEC 62304
- Software development plan and life-cycle definition
- Software requirements and architectural design documents
- Risk management file (ISO 14971)
- SOUP inventory and assessments
- Verification test plan, records and traceability matrix
- Configuration-management and problem-resolution records
Duration of Software IEC 62304
Several weeks, depending on the document scope and the software safety class.
Software IEC 62304 Procedure
- 1The software safety class is determined and its rationale is reviewed.
- 2The software development plan and process definitions are assessed.
- 3Requirements analysis and architectural design documents are reviewed.
- 4Detailed design and unit implementation records are reviewed.
- 5Integration and system test records are assessed.
- 6The traceability matrix is verified from requirement to test.
- 7The SOUP inventory and risk assessments are reviewed.
- 8Maintenance, configuration-management and problem-resolution processes are assessed.
Software IEC 62304 Acceptance Criteria
The acceptance criterion is that all processes required by the software safety class have been applied and evidenced. Some processes are not required for Class A, while for Class C all processes, including detailed design and unit verification, are mandatory.
Evaluation of Results
The assessment is evidence-based: the existence of a process definition is not enough; a record that it was applied is required. Gaps in the traceability chain are the most common finding.
Software IEC 62304 Report
- Software description, version and safety class
- Applied standard and its edition
- Conformity assessment by process
- Traceability-review findings
- SOUP assessment
- Findings and recommendations
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 authorisationsRelated Regulations
- MDR (EU) 2017/745
- IVDR (EU) 2017/746
- ISO 13485
Medikal Cihaz Testleri — What Does This Testing Field Cover?
The section below describes the field that the Software IEC 62304 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 IEC 62304
Who determines the software safety class?
The manufacturer determines and justifies it. The class is assigned according to the harm the software failure could cause after risk-control measures are taken into account: A if injury is not possible, B if non-serious injury is possible, C if death or serious injury is possible. The classification is documented in the risk file.
What is SOUP, and why is it important?
Software of Unknown Provenance — off-the-shelf software components (libraries, operating system, open-source modules) whose development process is not documented per IEC 62304. Their functional and performance requirements must be defined, known anomalies assessed, and their risks managed.
Can I obtain an IEC 62304 certificate?
A separate 'IEC 62304 certificate' is not issued for software. Conformity is assessed by the notified body within the device's CE conformity assessment. What can be obtained from an independent body is a preparatory conformity assessment report.