IEC 62304: Standard for medical device software

What is IEC 62304?

IEC 62304:2006 / AMD 1:2015 is the current version of the international standard that defines the software lifecycle processes for software used in medical devices. IEC 62304:2006 is considered a harmonized standard, meaning that it is recognized by the FDA and other regulatory agencies around the world.

Note that this standard applies both to Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD).

How is IEC 62304:2006 organized?

There are 9 chapters in IEC 62304. The first 4 chapters define the scope of the standard as well as references, terms, and general requirements. The following 5 chapters are as follows:

Chapter 5 – Software Development Process. This chapter is the most important to fully understand because it defines the software development planning process, including requirements analysis, design, testing, and release processes.
Chapter 6 – Software Maintenance. This chapter defines the need for a software maintenance plan, including implementation of a maintenance plan and issue analysis procedures.
Chapter 7 – Software Risk Management. Identification of hazardous situations, risk control, verification, and risk management procedures assume that an organization-level risk management plan is in place following the ISO 14971 standard.
Chapter 8 – Software Configuration Management. This includes change control and configuration status tracking.
Chapter 9 – Software Problem Resolution. This chapter addresses investigating and reporting on problems, change control processes, trend analysis, and resolution testing and verification.

IEC 62304:2006 software risk categories

IEC 62304:2006 defines three classes of risk for medical device software based on the risk of harm from a hazardous situation which the software could cause or to which it could contribute. As with risk management systems for other medical devices, the procedures, controls, and processes for medical device software should be appropriate for the level of risk posed by the software.

Class A – No injury or damage to health is possible.
Class B – Injury is possible, but not serious.
Class C – Death or serious injury is possible.

Software development and maintenance processes in IEC 62304

The software development process, as defined in Chapter 5 of this standard, lays out 8 process steps.

Software development planning (5.1)
Software requirements analysis (5.2)
Software architectural design (5.3)
Software detailed design (5.4)
Software unit implementation and verification (5.5)
Software integration and integration testing (5.6)
Software system testing (5.7)
Software release (5.8)

IEC 62304 recommended documentation

In general, the following list of deliverables is typically needed to establish conformance with IEC 62304:2006:

Software development plan - Define processes, deliverables, and development activities. The plan should include the Life Cycle Activities, Risk Management Plan, Documentation Plan, Configuration Management Plan, Change Control process, and Problem Resolution process.
Software verification plan - Describe the software test plan. Include all verification activities, such as code review, unit test and integration test plans, and the final system software verification test plan.
Software classification – Classify the software based on risk level as Class A, B, or C per definitions in the standard. Classification should also be established per market-specific requirements (ie: FDA Class I, II, or III).
Software description – High-level description of the software function, intended use, and technology used.
Software requirement specifications - Include specifications for all requirements, including functional, performance, interface, and safety requirements.
Software architecture - Include diagrams of subsystems, major components, and the interfaces between them. This can provide segregation of software entities for risk control.
Software hazards analysis - The hazard analysis should identify potential hazards and the software components that could cause them. Include mitigations that feed back into the requirements. Be sure to include OTS and wireless QoS hazard analysis where applicable.
Cybersecurity plan - Document cybersecurity controls and features, threat model, hazard analysis, and penetration testing.
Detailed design descriptions - Include specifications detailing how the software is implemented.
Off-the-shelf software list – Identify any OTS software used, including detailed information regarding source, version, and licensing.
Code unit verification - Document the unit test and code review as performed to plan.
Integration tests - Document the integration, regression, and OTS software testing performed per the plan.
System software verification protocols - Document test protocols for final device software. Include requirements tracing and show coverage of requirements (using pass/fail criteria).
Summary test report - Create a summary of all software verification per the verification and validation plan.
Trace matrix - Link system requirements to software requirements to associated design specifications and test protocols in one document (typically a spreadsheet). Include software hazards with software mitigations.
Revision level history - Document major revisions and releases made during development, including descriptions of each.
Unresolved anomalies - Document any anomalies still present and their associated risk. Include justification for release.
Software problem resolution process - Describe how reported problems are evaluated and investigated, including how change requests and any necessary regression testing will be handled.

Complying with IEC 62304

More than most other standards, IEC 62304 requires an understanding of multiple disciplines to ensure compliance. Be sure to include team members with expertise in software development, risk management, and regulatory affairs when defining processes related to this standard.

Complying with IEC 62304 is only part of what is required for market clearance for software as a medical device. In the U.S., a 510(k) submission is typically required. Read our 510(k) guide here.

‍