IEC 62304:2006 – software life cycle processes explained

Ensuring the highest safety standards and minimising risk related to medical device failure are the two pillars of medical device software development. These areas are regulated by three standards: ISO 14971, ISO 13485 that we’ll focus on next time, and IEC 62304, which is the focal point of this article.

Without further ado, I pass the floor to Krzysztof Minicki, our Director of Healthcare and Life Sciences, who will guide you through the requirements of IEC 62304 and its implementation.

Do you want to know how to apply IEC 62304 to conduct a legacy software gap analysis? Read this article >>> How to implement a legacy software gap analysis as required by IEC 62304-2015?

What is IEC 62304?

IEC 62304 is an international standard that specifies requirements for the development and life cycle of software as a medical device and software within medical devices. The goal of IEC 62304 is to ensure that software is safely implemented, fully functional and maintained throughout its life cycle, also after it’s placed on the market. It describes safety classification for medical software depending on the level of risk it poses to end users, patients and persons operating the device.

IEC 62304 was issued in 2006, thus its full name is IEC 62304:2006. The standard was slightly changed in 2015 to adjust it to the MDD that was in force at the time. An appendix was added, which specifies the safety requirements for legacy software that was released before the current standards and regulations were in force. IEC 62304 with the appendix is also known as IEC 62304:2006+AMD1:2015. Currently work is proceeding apace on adjusting the standard to the EU MDR.

Is IEC 62304 mandatory?

IEC 62304 is not mandatory, however, it’s recommended that organizations who develop medical device software follow its requirements. IEC 62304, together with ISO 13485 and ISO 14971 include the basic requirements that every medical software development company should adhere to in terms of ensuring the highest safety standards for their products.

Does the FDA require IEC 62304?

IEC 62304 is harmonised by the U.S. and recognized by the FDA, therefore it can, but doesn’t have to, be followed by medical software development companies.

What are the safety classifications for software systems as per IEC 62304?

IEC 62304 gives software development companies a series of guidelines on how to approach the identification and management of risks associated, for example, with software failure, which could affect a patient or device operator. Based on the medical device risk classification, the standard indicates certain risk control measures, which must be implemented throughout the software’s life cycle.

IEC 62304 describes three basic safety classes for software:

• class A: if the software cannot cause any harm,

• class B: if the software can cause minor harm or injury, which doesn’t lead to long-lasting or permanent health damage,
• class C: if the software can cause serious health damage, severe injuries or even death.

This scale allows for accurate identification and adjustment of processes associated with the safety of medical software development at all stages: from planning, through coding, to release and maintenance.

Keep in mind, that the above classes are strictly related to software. Medical devices are classified according to the EU MDR in EU or country-specific requirments

IEC 62304 determines safety requirements applicable to each class. Class A comes with the fewest requirements since it poses no risk to human health or life. Requirements applicable to classes B and C are very similar. The difference between class A and classes B and C is vast in both the implementation as well as the overall cost.

One more important thing to keep in mind is that when conducting the classification, we should also take into consideration a scenario when the software may not be working properly, may be unavailable or hacked. Would it pose any risk to the end users in a such case?

How to conduct a safety classification as per IEC 62304?

When conducting the classification, we should always assume the worst-case scenario when a hazardous situation may happen.

The first thing that must be determined is whether a hazardous situation is a result of software failure. If no, then software qualifies for class A.

If yes, we can move to the next step and evaluate the effectiveness of risk control measures external to the software. It may turn out that such measures could reduce the probability that a software failure will cause harm or might lower the severity of such harm.

Next, we have to determine if software failure results in unacceptable risk. If no, then class software qualifies for class A. If yes, then we shall assess the severity of a possible injury. If it’s a non-serious injury, then our medical device software qualifies for class B. If a failure may cause serious harm or even death, then it’s in class C.

The safety classification algorithm can be found in section 4.3 of IEC 62304.

Software decomposition under IEC 62304

IEC 62304 allows for a decomposition of software components, so they can be qualified to different classes, on condition that you maintain proper separation and isolation.

For example, if your software is by definition classified as a high-risk class C, you can try to decompose it into separate components. They need to be isolated in terms of architecture and functionalities. As a result, it may turn out that certain components have a lower risk class and this, in turn, decreases the overall costs of medical software development. If you don’t know how to make such decomposition or have some doubts, we can engage our team and help you.

Agile vs IEC 62304

IEC 62304 doesn’t dictate any specific development strategy model. Although the way it’s written may suggest a waterfall model, table B.1 in Appendix B shows examples of various development strategies, including the incremental strategy as well as the evolutionary strategy, aka agile. Spyrosoft has implemented fully Agile approach for our medical device software delivery. We can provide you in a short time frame solution shorting time to market with full transparency during development.

In other words, it means that any development strategy can be used as long as the technical documentation is consistent with the development processes and in line with IEC 62304.

Let’s now move on to how the software development process and its documentation should look like according to IEC 62304.

What are the requirements for the software development process under IEC 62304?

The software development process according to IEC 62304 can be summed up as transforming design input into design output. By design output, we understand business and functional requirements, together with the Intended Use. Design output is what has been created from design input in accordance with the requirements of IEC 62304. Validation, in simple terms, is checking if the input corresponds to the output.

To achieve proper design output, IEC 62304 specifies detailed requirements for each stage of the software development process:

IEC 62304 requires manufacturers to establish a software development plan according to the scope, magnitude, and software safety classification of the software they will be developing. The plan should be kept up-to-date.

Software requirements should document the functional and capability requirements, such as the purpose of software or code language, but also the security requirements, risk control measures, interfaces between the software system and other systems, and many more detailed in section 5.2.2 of IEC 62304.

IEC 62304 requires manufacturers to document the software architecture according to its class. Also, the SOUPs, which is the regulatory name for third-party software or that is either part of our medical device software or supports the development process, should be listed together with the requirements they should fulfil and the results of their verification. This is especially important as a preventive measure to minimise the risk of hackers or unauthorized persons accessing the software and posing danger to end users.

According to IEC 62304, the software shall be subdivided into software units, for which a detailed design should be developed, so as it can be correctly implemented.

A manufacturer is required to establish a software unit verification process and acceptance criteria for each software unit.

IEC 62304 requires manufacturers to have an integration plan, according to which the integration of system units into software items or software systems shall be done. Also, manufacturers shall include the records of testing and verification.

According to IEC 62304, manufacturers shall establish requirements, procedures and criteria for software system tests. The results of such tests should also be included in the documentation.

Before the software is released a manufacturer is required to ensure that all verification processes were completed and any possible problems were documented. Also, it’s the manufacturer’s duty to ensure that the software was released without any corruption or unauthorized changes.

Additionally, according to the traceability requirement of IEC 62304, the manufacturers are required to prove that all the system and software requirements, as well as risk control measures included in the documentation, were correctly implemented, tested and verified. Special attention must be paid to ensure that the appropriate risk control measures for each class are in place throughout the whole software development life cycle.

IEC 62304 includes also the requirements for software maintenance, risk management, software configuration management and problem resolution processes. We’ll cover them in the next sections.

What are the requirements for the software maintenance process under IEC 62304?

The standard requires manufacturers to prepare a software maintenance plan, establish the processes and procedures for analysing problems and modifications as well as implementing the changes.

Also, IEC 62304 specifies separate requirements concerning monitoring, documenting and evaluating user feedback. Identified problems should be recorded as problem reports, which include the evaluation of how they may affect the safety of medical device software. Manufacturers are also required to have a problem resolution process in place to address any such problems.

For a more detailed list of requirements regarding the software maintenance process, see section 6 of IEC 62304.

What are the requirements for the risk management process under IEC 62304?

Manufacturers ought to analyse software in terms of contribution to hazardous situations, identify such software items and document potential causes, for example, software defects, foreseeable misuses or faulty and unexpected operation of SOUPs.

Therefore, a manufacturer shall regularly analyse changes to the medical device software, including SOUPs, that might contribute to hazardous situations and determine if any additional risk control measures are required.

Additionally, for each case when a software item might contribute to a hazardous situation, the manufacturer shall determine and document proper risk control measures in accordance with ISO 14971, for example, make it impossible to use certain software features if a specific condition is not met. The implementation of each new risk control measure shall be verified and the results shall be documented.

A manufacturer is also required to document the traceability of any identified software hazard.

For a more detailed list of requirements for the risk management process, see section 7 of IEC 62304.

What are the requirements for the software configuration management process under IEC 62304?

Medical software manufacturers are required to establish means to identify configuration items, or in other words, create a software configuration plan. The plan shall include the types and versions of configuration items with SOUPs identified separately. All configuration items and their versions that comprise the software system configuration shall be documented.

The IEC 62304 standard also includes the requirements regarding how to approve, implement and verify changes to configuration items as well as requires that manufacturers shall maintain records for traceability of every change.

For a more detailed list of requirements regarding the software configuration management process, see section 8 of IEC 62304.

What are the requirements for the software problem resolution process under IEC 62304?

Under IEC 62304, a manufacturer shall prepare a problem report for every problem detected in the medical device software (on production). Such report must include information on how a problem affected the performance, safety or security of software (statement of criticality) as well as other information that may be useful in resolving the problem.

Each problem shall be investigated to find its cause and identify possible problem trends. A medical software manufacturer shall also evaluate how relevant the problem was to software’s safety using the risk management process. The results of the investigation must be documented, and a change request must be created for every action necessary to fix the problem. Once the problem is resolved, a manufacturer shall verify the resolution, check if adverse trends were reversed and close the problem report if applicable.

One of the last requirements in this section refers to testing documentation contents, which should include, among other things, the anomalies found, information on which version was tested, test tools as well as identification of a tester.

One more important point to mention is that the manufacturer is obliged to communicate the problem to all relevant parties, including the end users and authority bodies as well as maintain records of any problem report together with its resolution and verification for future reference.

Looking for a medical software development partner who adheres to the highest safety standards?

IEC 62304 is one of the pillars of our Integrated Quality Management System, which has been recently audited and will be certified soon.

Our team of quality and regulatory engineers is experienced in building safe medical device software compliant with IEC 62304 and can also help you with the safety classification or decomposition of your software.

Use the contact form below to book a consultation or discuss your medical device software project with Krzysztof.