IEC 62304: what it is, who needs it, and how conformance works

What is IEC 62304?

IEC 62304 is the international standard for the processes used to develop and maintain medical device software, whether the software is the device or runs inside one. It sets what is planned, documented, verified and kept under control from requirements to retirement, scaled by a safety class. Manufacturers conform to it, and no regulator certifies against it.

The current text is IEC 62304:2006 with Amendment 1:2015, which added legacy software and reworked the safety classification. It is the state of the art a notified body expects under the EU MDR, though not a harmonised standard under it, and is recognised by the FDA as a consensus standard, so conformance is checked at CE marking and in a premarket submission.

Who needs IEC 62304?

Manufacturers of software that is itself a medical device, from a diagnostic algorithm to a mobile app, for the EU, the US and the MDSAP markets

Manufacturers of a hardware device that contains software, from embedded firmware to the control software on an instrument

Companies maintaining software already on the market, including legacy software written before the standard applied, and the contract developers who write software for any of them

The standard becomes urgent when the notified body asks for the software safety classification and its rationale, when the FDA reviewer requests the software documentation for a submission, or when a sprint ships a change nobody treated as a design change.

What IEC 62304 asks for, process by process

Clause 4 sets the ground: a quality management system, risk management to ISO 14971 and a safety class for each software system. Clauses 5 to 9 are the five processes the class scales.

Planning, requirements analysis, architectural design, detailed design, unit implementation and verification, integration and integration testing, system testing and release with the known residual anomalies listed (5.1 to 5.8)

A maintenance plan, analysis of every problem report and modification request for its effect on safety, and modifications made through the development process they touch (6.1 to 6.3)

Analysis of how the software could contribute to a hazardous situation, the risk control measures the software implements, verification of those measures, and risk management of every software change (7.1 to 7.4)

Identification of every configuration item including third-party software, change control with approval before implementation, and status accounting of what has changed (8.1 to 8.3)

A process for every problem report, from record and investigation through change request, verification and analysis of trends (9.1 to 9.8)

Safety classes

Every software system is assigned a class from the harm it could contribute to, after risk control measures outside the software are counted.

Software that cannot contribute to a hazardous situation, or whose resulting risk is acceptable after risk controls outside the software. Planning, requirements, release, maintenance, configuration management, problem resolution and the safety analysis of every change apply

Software that can contribute to non-serious injury. Adds architectural design and its verification, unit verification and acceptance criteria, integration and system testing, plus the software risk management process

Software that can contribute to death or serious injury. Adds detailed design, additional unit acceptance criteria and segregation in the architecture for risk control

How IEC 62304 conformance works

1. Classify the software

Work out what the software could contribute to a hazardous situation, count the risk controls outside the software, and assign class A, B or C with the rationale written down. The class decides how much of the rest applies.

2. Plan the lifecycle and write the requirements

The development plan names the processes, tools and deliverables the class calls for, and the software requirements trace to the system requirements and to the risk control measures the software implements.

3. Design, build and verify by class

Architecture, detailed design where the class requires it, unit verification, integration testing and system testing, each with the records the plan named and each test traced to the requirement it proves.

4. Release

Verify the release, list and evaluate the residual anomalies, identify the version, and place the software documentation in the technical documentation the notified body or the FDA reviewer reads.

5. Maintain

Every problem report and modification request goes through the maintenance, risk and configuration processes, the classification is revisited when a change touches a risk control, and the records stay current for the surveillance audit and the next submission.

IEC 62304 IN QUALIO

Qualio traces software requirements and their tests from your repos to the device risk file, so a software change is a design change like any other

Qualio reads requirements from Jira or Azure DevOps, tests from TestRail, Xray or Zephyr and code from GitHub or GitLab as they are, and rebuilds the traceability to the ISO 14971 risk file as the work changes. It maps IEC 62304 clause by clause to those records, reassesses when one changes and recommends a fix for any gap. At release, you export the software documentation at its approved versions.

Software requirements for clause 5 traced to the risk control measures they implement and the tests that verify them, with the trace rebuilt as the backlog changes

A software modification for clauses 6 and 8 raised as a change control from the change itself, with Copilot drafting it and your team approving it before anything ships

Problem reports for clause 9 run as events linked to the software version they were found in, each linked to the CAPA that closed it

The software documentation section of the technical documentation compiled from the approved requirements, tests and release records, for the 510(k) and the MDR file

Standards that apply alongside IEC 62304

Medical devicesISO 13485: The quality management system IEC 62304 assumes in clause 4.1, with the software lifecycle running inside its design and development controls at clause 7.3
Medical devicesISO 14971: The risk management process clause 4.2 requires, which the software risk analysis in clause 7 feeds and draws from
Product submissionsFDA 510(k): The submission whose software documentation section is built from the 62304 records, at the Basic or Enhanced documentation level the sponsor determines under the FDA's 2023 software guidance
Medical devicesEU MDR: The regulation under which a notified body reads the software lifecycle evidence in the technical documentation, with IEC 62304 as the state of the art
Medical devicesFDA QMSR: The rule the FDA inspects the design controls under, which the software development records in clause 5 are part of

Simbiosys

SimBioSys is the developer of an innovative software as medical device (SaMD) platform to revolutionize 'computational oncology'.

Read the Simbiosys story

“The traceability view and gap analysis help us ensure everything is accounted for from a design control perspective.”

Eric KlumperChief Quality Officer, Black Fur Medical

Guides and webinars for IEC 62304

Datasheet

SaMD quality management software datasheet

Guide

Ultimate guide to medical device design controls

Webinar

Qualio webinar recording: what to expect in the next revision of IEC 62304

Questions about IEC 62304

What is IEC 62304?

IEC 62304 is the international standard for the processes used to develop and maintain medical device software, covering software that is a device on its own and software inside a hardware device. It defines development, maintenance, risk management, configuration management and problem resolution processes, scaled by a safety class of A, B or C.

Is IEC 62304 mandatory?

Not as a law in itself. A notified body expects conformance or an equivalent justification as the state of the art under the EU MDR, and the FDA recognises it as a consensus standard a submission can declare conformance to. In practice a device with software reaches either market with IEC 62304 records behind it.

What are the IEC 62304 software safety classes?

Class A is software that cannot contribute to a hazardous situation, or whose resulting risk is acceptable after risk controls outside the software. Class B can contribute to non-serious injury. Class C can contribute to death or serious injury. The class is assigned per software system, with the rationale documented, and it decides how many of the standard's clauses apply.

Can you get IEC 62304 certified?

No. There is no regulator or accreditation scheme that certifies against IEC 62304. Conformance is declared by the manufacturer and checked by others: the ISO 13485 registrar at clause 7.3, the notified body in the technical documentation and the FDA in the software documentation. A test house can issue a conformity assessment report, which reviewers read as evidence.

Does IEC 62304 apply to software as a medical device and to mobile apps?

Yes, where the software is itself a medical device under the MDR or the FDA's definition. The standard applies to the software lifecycle whether the device is a diagnostic algorithm, an app or firmware in an instrument. IEC 82304-1 adds product-level requirements for health software that runs on general computing platforms, and the two are used together.

Can we add IEC 62304 to the standards we already run in Qualio?

Yes. Add it from the library and Qualio assesses the software requirements, tests, risk file and procedures you already hold against every clause, beside ISO 13485 and ISO 14971 if you run those too. Requirements the standards share count once, and the first assessment lists what is covered and what the class still needs.

When is the next release?

Bring the release date and your backlog, wherever it lives. We will show you requirements traced from your repos to the risk file, and IEC 62304 assessed against them clause by clause.

Book a demo Get started

Less time on documentation. More time on the device.