IEC 62304 compliant medical software development

Developing software compliant with IEC 62304 differs from building a regular one, primarily due to the regulatory requirements. This article explores the medical software development process, common challenges, and practical solutions. You’ll also learn how the regulations ensure patients ' safety and the quality of the software.

TL;DR

Developing software compliant with IEC 62304 differs from building a regular one, primarily due to the regulatory requirements. This article explores the medical software development process, common challenges, and practical solutions. You’ll also learn how the regulations ensure patients ' safety and the quality of the software.

A few words before we start...

Early engagement with the standard and a deep understanding of regulatory requirements is essential for successful development.

IEC 62304 is an internationally recognised quality standard that defines life cycle requirements for medical device software. In our previous article, you can become familiar with its characteristics and requirements.

Of course, IEC 62304 is only a part of all the regulations that apply to you for medical software, which you can read about in our MDR blog. But let's move on to the IEC 62304 requirements themselves.

This section required some technical terms. If you’re not a tech person yourself, we advise you to ask for some guidance from your colleague or get in touch with us for a broader explanation.

What’s the difference between IEC 62304 compliant software and “regular” software development?

What does “regular” software mean to us?

It’s a typical software used in various industries that don’t require certification, while a "non-regular" for us is medical software compliant with IEC 62304, specifically designed for healthcare applications, adhering to regulatory standards to ensure safety and effectiveness in a medical context.

This article can also benefit you if your software complies with ISO 13485 requirements, but you need compliance with IEC 62304 and seek information on how to achieve it.

The main difference between IEC 62304 compliant software development and "regular" software development lies in following the specific requirements of the standard.

There is no easy answer to this question. It mainly depends on the “regular” process of software development. For agile processes implementing modern good practices and focused on high quality and documentation, additional requirements from IEC 62304 are relatively small and create a small overhead. Most are related to risk analysis, SOUPs, and configuration management.

The problem comes when a process is focused only on economic or quick development (like developing a Proof of Concept, developing lean startup style MVP, etc.). We can expect large overhead in these approaches, which may significantly extend the time (and cost) necessary for developing a project.

Putting it simply - the earlier you implement all requirements, and the more thoroughly you make your first steps, you will save yourself a huge amount of time, money and stress.

We’ve been inquired by a couple of software creators who asked us to save their software at the very late stage of development. The thing is, if you want to comply once the software is already developed, there is no other way than going POINT BY POINT with every single requirement for each regulation and standard. Can you imagine the nightmare?

The number of practices within the standard has a reason - it guarantees the safety and effectiveness of the medical software creation.

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

The wide adoption of IEC 62304 by regulators worldwide emphasises the importance of familiarity with the standard for future compliance.

The software development process under IEC 62304 involves transforming design input into output while ensuring regulatory compliance. In simple terms, under IEC 62304, the process of developing software ensures that design ideas turn into actual software, which is done in a way that follows regulatory rules and standards. Compliance includes several stages and requires clearly defined Intended Use, traceability, documentation, and testing. Verification is crucial as it ensures that what you planned for (input) aligns correctly with what you actually get (output).

IEC 62304 specifies requirements for each stage of the software development process that the manufacturers should follow:

• Planning: establishing a software development plan based on the scope of project and safety classification.

• Requirements analysis: It should document functionality, security, user interface and many other requirements, for example, choice of code language.

• Architecture design and detailed design: documenting software architecture according to its class (check in this article), defining the use of SOUPS (explained below in this blogpost) and developing detailed designs for proper implementation.

• Unit implementation and verification: establishing a software unit verification process and acceptance criteria.

• Integration and integration testing: testing the software following the integration plan. Important - the testing records should be maintained.

• System testing: establishing software system test requirements, procedures, and criteria.

• Release: completing verification processes and preventing corruption or unauthorised changes.

• Software management process: systematic monitoring and maintaining software throughout its lifecycle to ensure it meets its objectives effectively.

• Configuration management: controlling software changes throughout its life cycle, ensuring proper documentation, and reviewing and approving modifications.

• Risk management: identifying potential software development and usage risks, assessing their severity, and implementing appropriate mitigation measures.

• Problem-solving: investigating problems and their causes, implementing corrective and preventive actions, and addressing issues arising during software development or post-market release.

Ready-to-use frameworks and libraries (SOUP) within IEC 62304-compliant software

Modern software development relies on frameworks and libraries. For most of them, we don’t have information regarding their development and validation processes. Such elements are described as SOUP (Software of Unknown Provenance). In many cases, they are necessary in medical or healthcare software development.

The good news is IEC 62304 made allowance to use them both. However, the IEC 62304 places specific requirements and controls on using SOUP to ensure the safety and effectiveness of the overall medical device software.

For example, the manufacturer should identify some information about each of SOUP’s:

• All SOUP components used in their software

• Components' version

• Supplier, and potential SOUP limitations

• Assess the potential risks associated with the use of SOUP

• Establish procedures for managing and updating SOUP components

These procedures help verify that the SOUP components function correctly within the medical device software and meet the required quality and safety standards, ensuring the final product's overall safety and effectiveness.

Agile or waterfall? Integrating IEC 62304 into the Software Development Process

Some manufacturers willing to build software compliant with IEC 62304 believe that the waterfall model is the development methodology to go for, but IEC 62304 can be implemented and integrated with various software development methodologies, including agile methodologies such as Scrum or Kanban. The choice of development methodology depends on the specific needs and requirements of the organisation and the nature of the medical software being developed.

To successfully integrate agile methodologies with IEC 62304, the manufacturers should remember to:

• update input requirements in the documentation throughout the project

• verify and validate activities within agile iterations

• balance documentation needs with the agility of the development process

• ensure the presence of regulatory and quality experts within the team

How do we do it at Revolve? - IEC 62304

Creating an efficient and modern software development process compliant with MDR, IEC 62304, and other important standards took us about two years. It has improved with every project we have implemented. To make a quality process that incorporates all standards takes a long time, so you should evaluate what’s more profitable for you.

A stable process allows us to minimise the overhead and reduce the risk of problems during and after certification. With our multidisciplinary software development and regulatory affairs team, we help our clients from the beginning of product design through software development and their certification process to further maintenance.

This is why we exist. We believe that any medical software can benefit from the experience of a development partner that takes care of your product's safety, standards, quality and usability.

What are the common challenges associated with IEC 62304 compliance, and how to overcome them?

While producing medical software, you may face some challenges during the development process due to the precise requirements of the IEC 62304 standard. However, we have a solution for each of them. Don’t worry, and remember they have a good reason to exist - to ensure the patient’s safety and the quality of their therapy.

So, what are the solutions?

Common challenges and solutions while implementing compliance with IEC 62304:

• One more time, the most critical and common problem is the introduction of IEC 62304 into the project after or during software development. The entire standard is about the software development process, not only the result of that development. Implement it early.
  
  

• Remember to follow global medical regulations, such as the MDR and numerous controls that follow them to prove the safety and quality of the products. Also, complying with IEC 62304 means a lot of data analysis and documentation that needs to be fulfilled. Our advice is to stay organised in terms of paperwork.
  
  

• Not only the final product but every stage of the software development cycle must comply with IEC 62304 norms, which means that you should always have the requirements at the back of their heads.
  
  

• The cost of IEC 62304 development is quite significant, considering the expenses of hiring a cross-functional team - and the time needed for software development and its documentation according to the processes described in the mentioned standard. If you have a well-thought-out project plan, it will help you avoid unnecessary costs. Moreover, if the final product prioritises patient welfare and is quality-based, it becomes another factor contributing to the production cost. The return on investment (ROI) is then realised over time.
  
  

• In addition to the standard team members, like developers, technical specialists, and QA engineers, the software development team should also include medical regulation experts. Then, a team will cooperate and communicate effectively to achieve the best results and combine interdisciplinary knowledge.
  
  

• Another common mistake is not assessing the risk elements mitigated by the software vital for complying with IEC 62304 requirements to address patient safety. So make sure to define processes for the Software Development Life Cycle clearly.
  
  

• Moreover, the manufacturers should consider that the time to develop software compliant with IEC 62304 depends on numerous factors. One of them is the SaMD or SiMD safety class and the different requirements imposed by IEC 62304 for each class.

Class A software poses the lowest risk, with no potential for injury or harm to health, so developing such software may require less strict requirements, resulting in shorter production time compared to higher classes (e.g. software implementation and its test planning is required only for class B and C).

Let us know what you think. Are you more for taking all possible risks but designing your medical software development process in-house, or do you prefer to focus on other areas of your product development and use the experience of an outsourced medical software provider? We’re always curious about your opinions!