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.

Parameterization of software

Leave a comment

The parameterization of software – in this context, we can also talk about customizing or configuring software – often leads to discussion, e.g., regarding responsibilities and the differentiation to in-house production. This article gives manufacturers and their customers important advice on what to look out for when parameterizing software and how to avoid the usual pitfalls.

Details