Operating system compliant with IEC 62304 and FDA?
When selecting an operating system, do medical device manufacturers have to ensure that the operating system is IEC 62304-compliant? What does the FDA say? This article…
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:
- Articles on the aspects of IEC 62304
- Articles on life-cycle activities
- Articles on the regulatory significance of IEC 62304
- 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
- standalone software that counts as a medical device (software as medical device), such as
- 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
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:
- 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.
- 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.
- 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.
- 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.
- You can also benefit from our support in documenting your software concisely, precisely, and legally compliant and preparing it for audits and tech file reviews.
- Have the IT security of your devices assessed by penetration tests.
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.
Configuration management for medical devices
Configuration management is much more than using version management tools like git or svn. This becomes clear when you look at IEC 62304 and the FDA guidance documents. In this article, you will read about
DetailsCyclomatic complexity
Cyclomatic complexity is a metric in software engineering that helps determine the complexity and, thus, the likelyhood of errors and the maintainability of code. Cyclomatic complexity is also referred to as the McCabe metric.
ISO 15223-1: Medical symbols and labels
The standard ISO 15223-1, regulates the symbols that manufacturers are permitted to/must use for labeling medical devices. In January 2022, the EU Commission harmonized EN ISO 15223-1 as one of relatively few standards under the MDR and added it to the list of harmonized standards. This alone makes it clear how relevant labeling has become. …
DetailsUnit testing and IEC 62304
In software development, unit testing refers to the testing of software units. However, there is no common understanding of This article provides clarity.
DetailsPDMS (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
DetailsVerification 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
DetailsQualification and classification of IVD software
The qualification and classification of IVD software determine how and how quickly IVD manufacturers can bring their software to market and what costs arise for “approval.” This article will help you correctly qualify and classify IVD software, thereby avoiding regulatory problems and the resulting costs and delays.
DetailsThe FDA’s cybersecurity guidance documents
Medical device cybersecurity is a focus not only for the FDA but also for other legislators and authorities, both in the US and other markets. This is understandable The USA has added requirements for cyber devices to the Food, Drug & Cosmetic Act (FD&C), and the FDA has published several guidance documents on cybersecurity, which…
DetailsSBOM: Software Bill of Materials
Laws and standards require medical device manufacturers to compile a Software Bill of Materials, the SBOM. However, standardized SBOM formats are not always sufficient to meet these requirements. In particular, medical device manufacturers who do not supply and use SBOMs for their software are no longer accepted in the market. Here are the reasons.
Details