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.

Content

On this page, you will find:

  1. Articles on the aspects of IEC 62304
  2. Articles on life-cycle activities
  3. Articles on the regulatory significance of IEC 62304
  4. Advice on where and how to get help with implementation

* 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

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

b) Regulatory context

Qualification and classification

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

Particular requirements for software

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:

Chapter 5.2: Requirements

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

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
Hint

Medical devices that are and contain software and that have external interfaces such as USB or ethernet as subject to IT security requirements. Please note the requlatory requirements related to IT security.

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.

4. Support with IEC 62304

Benefit from the support of the Johner Institute:

  • Do you still have questions about standards-compliant software development? Then, take advantage of the free micro-consulting.
  • In the compact seminar on medical software, you will acquire the prescribed competencies. You will learn about and fulfill the statutory requirements for software development.
  • The Medical Device University uses video training to show you how to create lean, IEC 62304-compliant documentation step by step. A complete set of templates takes a lot of work off your hands.

Contact us right away so that we can discuss the next steps together. This will ensure that your “approval” is a success and that your devices are quickly launched on the market.


PDMS (Patient Data Management System): What you should consider from a regulatory perspective

PDMS stands for patient data management system. These clinical information systems are typically used in hospitals, especially in departments that treat patients in intensive care. PMDS are experiencing a new boom in Germany as a result of the funding provided by the Hospital Future Act (Krankenhaus-Zukunftsgesetz, KHZG). This article provides 1. PMDS: Functionalities and requirements Patient data management systems (PDMS)…

Details

Verification and validation: Differences and definitions

What is the difference between verification and validation, and how are these terms defined? Even standards and regulations use the terms incorrectly or misleadingly. This article 1. Verification a) Definition This definition does not explain what type of “requirements” need to be confirmed by verification. Limiting these requirements to product or component requirements is recommended to avoid…

Details

Level of Concern and Documentation Level: What the FDA wants to achieve with it

1. Documentation Level: End of Level of Concern On June 14, 2023, the FDA released the guidance document Content of Premarket Submissions for Device Software Functions. This document replaces the guidance document introducing the Level of Concern and only distinguishes between two classes. a) Determination of the classes The FDA no longer defines three “Level…

Details

Software maintenance: How to avoid typical audit pitfalls

Software maintenance is the phase in which software is further developed, e.g., with the objective of According to the FDA, 79% of all bugs occur during software maintenance. Accordingly, some regulations address this topic. Regulatory requirements for software maintenance Requirements of the Medical Device Regulation MDR (2017/745) The Medical Device Regulation requires medical device manufacturers…

Details