Software & IEC 62304

IEC 62304 is a European harmonized* standard for “medical device software.” It is entitled “Medical device software – Software life-cycle processes” and sets minimum requirements for processes such as the development and maintenance of software.

^* IEC 62304 was harmonized under the MDD and IVDD and is meanwhile harmonized under the MDR and IVDR.

1. Articles on the aspects of IEC 62304

a) Scope of application

IEC 62304 is applicable for

• standalone software that counts as a medical device (software as medical device), such as
  • mobile medical apps or
  • clinical information systems, and
• software that is part of a medical device (software in a medical device).

Because IEC 82304-1 references the standard, IEC 62304 is even relevant for health software.

b) Regulatory context

Qualification and classification

• Qualification and classification of software according to MDR: medical device yes/no and risk classes according to Annex VIII
• Qualification and classification of software according to IVDR
• Class I software (MDR)
• Classification according to MDR (especially rule 11)

Please also note the articles on life-cycle activities under point 2.

Particular requirements for software

• General requirements of the MDR
• General requirements of the IVDR
• UDI requirements of the MDR (for standalone software)
• Clinical evaluation of software
• Regulatory requirements for IT security
• MDCG guidelines e.g., the MDCG 2019-11 and the MDCG 2023-4

c) Concepts of the standard

• Software safety class
• SOUP (Software of Unknown Provenance)
• Probabilities of errors
• Validation, in particular, validation of the device and validation of the tools

2. Articles on life-cycle activities

The following articles are grouped according to the chapters of IEC 62304.

Chapter 5.1: Design and development planning

The first requirement of the standard is to create a design and development plan. These articles are worth reading in this context:

• What are life-cycle processes?
• Agile development (e.g., according to scrum) and other development processes, such as the V-model
• Differentiation between design and development planning and the development process
• Difference between quality assurance and tests

Chapter 5.2: Requirements

The manufacturer must derive the software requirements from the requirements of the device or the stakeholder requirements.

• Deriving the software requirements from the customer (and other stakeholder) requirements
• Interaction with quality characteristics in accordance with ISO 25010

Chapters 5.3 and 5.4: Architecture

In the architecture, the manufacturer determines the “blueprint.”

• Standards-compliant documentation of the architecture and interfaces
• Requirements for the development of components
• Detailed design for software

Chapters 5.5 to 5.7: Implementation and verification

The software must then be implemented and verified in accordance with the architecture. Validation is not covered by IEC 62304 but by IEC 82304-1.

• Tips for code reviews (chapter 5.5)
• Requirements for testing, e.g., for
  • Unit tests (chapter 5.5),
  • Integration tests (chapter 5.6),
  • Regression tests and system tests (section 5.7)
• Notes on coding guidelines and static code analysis

Chapter 5.8: Release

Development and maintenance conclude with the release, which should not be confused with the product release:

• Software release, a widespread misunderstanding

Further requirements and processes of the standard

• Dealing with changes (software maintenance and bug fixes)
• Software configuration management
• Design changes

3. Regulatory significance of IEC 62304

a) Proof of GSPR (MDR/IVDR)

In Annex I, the MDR and IVDR medical device regulations formulate the so-called “General Safety and Performance Requirements” (GSPR).

One of these requirements is that “For devices that incorporate software or for software that are devices in themselves,” the

“software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.”

This is a statutory requirement. A breach of this can be punished with fines and imprisonment as defined in national laws such as the German MDCG.

Manufacturers of medical devices should demonstrate conformity with these requirements by complying with harmonized standards.

The IEC 62304 standard is the standard specifically harmonized for life-cycle processes. Another standard is IEC 82304-1.

b) “Consensus Standard” of the FDA

The FDA recognizes IEC 62304 as a “Consensus Standard,” but it does not expect conformity with this standard. However, the authority does have comparable requirements in its guidelines on software validation, for example.

c) IEC 62304 certification

Some test centers offer “certification according to IEC 62304”. Manufacturers should be aware of the limitations of these certifications:

1. A certification does not have such a high value, especially if the testing facility is not accredited for this certification. This is because anyone could issue such a certificate.
2. IEC 62304 is a process standard, not a product standard. Therefore, an inspection must assess the process conformity and not the device conformity. Thus, the certificate does not say too much about the product quality.
3. The claim made by some testing bodies that certification helps to save time during testing is incomprehensible. Manufacturers can save time through test automation and suitable tools and procedures. However, certification does not reduce the testing effort.
4. As part of certification in accordance with ISO 13485, which is carried out by accredited bodies, auditors have to indirectly test conformity with IEC 62304 anyway, at least with spot checks.

The Johner Institute does not generally advise against certification in accordance with IEC 62304. But everyone should be aware of the “probative value” of these certificates.