Understand The Requirements For Medical Device Software Testing

Technology plays a vital role in all forms of modern healthcare, from simple personal monitoring devices like a step tracker to those in medical settings like critical care life support systems. Each requires software to enable it to run and deliver the expected service. Therefore, it is imperative that manufacturers have thorough and reliable medical device software testing in place.

It is estimated the market for such devices will be worth over US$ 455bn in 2022, and there’s the added fact that they impact the health of individuals who need to be confident they work as expected and won’t inadvertently cause harm. So, it isn’t surprising to see a regulatory regime that sets standards on how to test medical device software. 

Regulations for software testing in medical devices


There are different standards and laws for medical devices, but the most common one to consider is IEC 62304, which defines the life cycle requirements for medical device software. For a device to receive a CE mark in the EU or FDA approval in the US, and access to those regulated markets, the manufacturer has to follow these standards.

Classification of medical devices in a regulatory context

A medical device is broadly defined as any device which has a medical purpose. Within this, devices and their software are divided into three potential categories when it comes to their software:

  • Class A: No injury or damage to health is possible
  • Class B: Injury is possible but not serious
  • Class C: Death or serious injury is possible

As you would expect, the requirements are far more rigorous for a Class C device than a Class A due to the potential outcomes incorrectly functioning software may cause.

The standard covers all the steps in the development. However, looking specifically at software testing in medical devices, the sections to consider are 5.6, which covers integration and integration testing and 5.7, which is concerned with software system testing. For example, it states that you must create tests for the software for anything in Class B or C.

Ultimately, the testing aims to prove that the requirements set for the software are successful in their implementation.

For devices that will receive software updates, there is also section 7.4 to consider, which covers the risk management involved in software changes.

Other standards and regulations to take into consideration when testing software in medical devices

The IEC 62304 isn’t the only standard that you may need to consider; there is also ISO 13485, the medical device industry’s most widely used international standard for quality management.

Since safety and quality are crucial in the medical devices industry, compliance with this standard is often seen as the first step in achieving compliance with European regulatory requirements. 

IEC 60601, which covers medical electrical equipment, is also an essential standard for manufacturers of electrically operated medical devices. However, it’s usually the IEC 62304 standard that will set the software testing requirements for more complex software.

All this leads to regulation consideration, which can vary between territories. For example, in the EU, there is the Regulation (EU) 2017/745, which includes a section on software verification and validation. The good news is that you should also be undertaking the steps to meet the various regulatory frameworks by complying with the above standards.

The importance of software testing for medical device manufacturers


There’s more to an excellent medical device software testing regime than simply meeting the legal requirements. The sensitivity of the purpose of the devices means the impact of bugs can have serious consequences on the health of patients.

Undetected faults in the software can also have implications for the manufacturer. Creating trust in the market that the devices produced can be relied upon is crucial to their success, which could, in turn, impact the financial performance of the company that makes them.

This involves looking beyond the medical function of the device to practical aspects that may affect the user. For example, a GUI that functions as expected in all scenarios is essential for a good user experience. Ensuring all the code related to this has been tested can mean the difference between the device being recommended between professionals or not.

Ultimately, it’s no exaggeration to say the manufacturer's reputation can be at stake when it comes to software testing.

Automated software testing for medical devices


There’s a need and desire to test code quickly and efficiently so that the development process isn’t held up. Therefore, your testing team may be considering what would be the best medical device software testing tools for them to use.

Unveiling the advantages of test automation in medical device software testing

Unlike traditional manual testing, automated testing introduces efficiency by overseeing testing scenarios thus reducing the need for repetitive manual steps. Rather than spending inordinate amounts of time retesting everything manually, an automated testing tool can ensure tests run exactly as specified.

Companies that automated a minimum of 50% of their tests reported significant advantages in test automation. Notably: 

  • Shorter testing cycles (88&)
  • Better test coverage (71%)
  • Potential to detect bugs in the early stages of the development process (68%)

In the medical field, having confidence in the tests is essential, which the tool can help deliver. Meanwhile, the automated tests mean the testing team has more time to consider areas that require manual intervention.

For example, consider a tool like Squish, which can run cross-platform, cross-device, and cross-technology automated GUI tests. 

Code coverage in testing medical device software


It isn’t only a challenge for your testing team; developers also have needs when it comes to testing. While working on code, they need to understand when they are working in tested or untested sections. Having that information can also prompt them to create tests to ensure the regulatory requirements for testing are met.

A code coverage tool like Coco delivers precisely that. It can give feedback directly in the developer’s IDE, meaning they know the testing status of the code on which they are working. So with your medical device, your developer can be sure to exercise extra caution if they are, for example, working in an untested area. It also means a code section can’t slip through the net without being tested, as the coverage information is there for all to see.

Tools like the Axivion Suite also allow you to detect code smells, check the compliance of your software architecture, avoid technical debt to keep your software projects maintainable and expandable, and release your resources for new feature development.  

Medical device software testing tools 


Medical device software testing is something that can require more from a manufacturer than other sectors. The robust regulatory framework means some steps must be completed. However, it’s also important to look beyond those to the potential reputational damage poorly tested software can cause.

Establishing and supporting an entire testing regime that ensures full code coverage for the tests will help breed confidence in your devices. Empowering your team with the tools that can help them complete this task will make the process easier, more efficient and more reliable for all involved.

Find out more about how our QA tools can help with a free trial of Squish for GUI test automation, Coco for code coverage and Test Center for testing result management.

Comments