IEC 62304 is the process standard for the lifecycle of software in medical devices. It does not specify product requirements, but rather the activities that a manufacturer must plan, implement, and document to ensure that software can be considered safely developed and maintained. It is applicable to standalone software that is itself a medical device, and to software as a component of a product. Regulation (EU) 2017/745, Annex I, Section 17.2, requires that software be developed and manufactured according to the state of the art, taking into account the principles of software lifecycle, risk management including information security, and verification and validation. IEC 62304 is the established reference for this demonstration of compliance.
Safety Classes A, B, and C
The standard assigns a safety class to each software system. Class A applies if no contribution to a hazardous situation is possible or if the resulting risk is acceptable after external risk control measures. Class B applies if a non-serious injury is possible, and Class C if death or serious injury is possible. The decisive factor is the worst-case harm, assuming software failure and ineffective external measures; the probability of error must not be considered as a mitigating factor. Risk control outside the software, for example in hardware, can reduce the class by one level. A finer classification is possible for individual software elements if the separation is justified.
The Software Development Process
Chapter 5 of the standard divides development into planning, requirements analysis, architectural design, detailed design, implementation and verification of software units, integration and integration testing, system testing, and release. The development plan defines processes, standards, methods, tools, and the deliverables to be created. The scope of activities depends on the safety class: a documented detailed design of individual units is only required from Class B upwards, and the requirements for verification depth and traceability increase towards Class C. Traceability from system requirements through architecture and units to tests and identified risks is consistently required.
Maintenance, Configuration Management, and Problem Resolution
The lifecycle does not end with release. Chapter 6 requires a maintenance plan in which feedback is evaluated, changes are controlled and implemented, and their impact on risks and verification is assessed. Chapter 8 requires configuration management with identified configuration items, change control, and configuration status reports, ensuring that every delivered version remains reproducible. Chapter 9 regulates the problem resolution process: recording and evaluating problems, root cause analysis, deciding on measures, verifying the correction, providing feedback to affected parties, and checking whether a reporting obligation under vigilance regulations is triggered. Chapter 7 interlinks software activities with risk management.
Software of Unknown Provenance and Third-Party Components
Third-party components, referred to in the standard as Software of Unknown Provenance (SOUP), are not developed according to IEC 62304 but are part of the product. The manufacturer must identify them, at least by name, manufacturer, and unique version designation, and define functional and performance requirements as well as the necessary hardware and software environment for each component. Published anomaly lists must be evaluated for relevance to safety, and a procedure for updates must be maintained. For open-source libraries, this includes ongoing monitoring of known vulnerabilities, because a defect in a third-party component has the same consequences as one’s own.
Distinction from ISO 14971, IEC 62366, and Classification
IEC 62304 does not replace any of the related standards. ISO 14971 provides the risk management system on which Chapter 7 builds; the safety class is a parameter of process control and not the result of the risk assessment itself. IEC 62366-1 covers usability, i.e., operating errors and the user interface, which IEC 62304 does not address. ISO 13485 provides the framework for the quality management system, and IEC 81001-5-1 supplements security activities in the lifecycle. Separate from all this is the regulatory risk class of the product according to Annex VIII, particularly Rule 11, for which MDCG 2019-11 explains the qualification and classification of software. Safety class and risk class are independent parameters.
Relevance for clinical trials
If software-based functionality is investigated in a clinical trial, the version to be tested must be uniquely determined and controlled throughout the study duration. Configuration management determines which software version was used at which center and when; without this assignment, efficacy and safety data cannot be evaluated. Changes during the study are therefore not purely a development issue, but a study plan issue: they require an assessment of the impact on endpoints, risk analysis, and verification, and if necessary, a change notification to the authority and ethics committee.
Conversely, the study provides input data for the lifecycle. Malfunctions and operational problems identified during trial operation feed into the problem resolution process and the assessment of whether a serious incident or a safety corrective action has occurred. Data collection instruments must therefore systematically record technical anomalies and distinguish them from clinical events. Full-service CROs like Mediconomics support manufacturers in linking the study plan and version control, in evaluating study-related software changes, in recording technical incidents, and in medical writing for clinical evaluation and study documentation.
Frequently Asked Questions (FAQ)
How is the safety class determined?
Based on the worst possible harm in case of software failure, without mitigating consideration of the probability of error and assuming that external measures fail. Effective risk control outside the software can reduce the class by one level.
Does the safety class correspond to the risk class according to the MDR?
No. Safety classes A, B, or C control the scope of lifecycle processes. Risk classes I to III according to Annex VIII determine the conformity assessment pathway. Both are determined separately.
Does open-source software require special treatment?
Yes, as Software of Unknown Provenance. This requires identification with version, defined requirements, evaluation of known anomalies and vulnerabilities, and a controlled approach to updates.
Regulatory References
- Regulation (EU) 2017/745, Annex I, Section 17 – Requirements for programmable systems and software
- IEC 62304 – Medical device software – Software life cycle processes, Chapters 4 to 9
- ISO 14971 – Application of risk management to medical devices
- IEC 62366-1 – Application of usability to medical devices
- MDCG 2019-11 – Qualification and classification of software
