Discover TÜV-certified GoogleTest with Agentic AI for C/C++ testing! Get the Details »
Whitepaper
Want a quick overview before you dive in? Start below.
Medical device software development faces increasing complexity with regulatory burdens around code coverage testing. FDA 510(k) guidance mandates code coverage metrics for Class II and Class III devices, though requirements vary by classification.
Automated testing solutions like Parasoft C/C++test and Parasoft DTP measure code coverage automatically and integrate with modern SDLC processes, reducing risk and increasing confidence in device safety. These tools help teams meet FDA recommendations and ease regulatory documentation preparation, with Europe increasingly relying on U.S. FDA standards as medical product development becomes globalized.
Most of us have been beneficiaries of medical devices—from common blood pressure cuffs to inexpensive pulse oximeters available at local pharmacies, from clinician-operated CT scanners to MRI machines. All are subject to U.S. government regulation through the FDA.
Device classification depends on the intended use of the device, and upon indications for use. In addition, classification is risk based, that is, the risk the device poses to the patient and/or the user is a major factor in the class it is assigned. Class I includes devices with the lowest risk and Class III includes those with the greatest risk. As indicated above all classes of devices [are] subject to General Controls. General Controls are the baseline requirements of the Food, Drug and Cosmetic (FD&C) Act that apply to all medical devices, Class I, II, and III.al Equivalence in Premarket Notification 510(k).
Most medical devices require FDA 510(k) premarket notification or simple registration if exempt. However, if a device is implanted or presents a "potential unreasonable risk of illness or injury," it’s likely a Class III device requiring premarket approval (PMA). New innovative devices without previous examples ("predicate devices") are automatically Class III but may qualify for the De Novo process instead of PMA. Just 10% of FDA-regulated devices are Class III, but they’re the ones most associated with higher risk.
The classification used by the FDA is largely based on risk. All electrical devices follow the IEC-60601 standard for electrical safety, but increasingly medical devices contain significant software.
The software standard most associated with the FDA process is IEC 62304. It outlines the software development lifecycle for medical devices, expressing activities and tasks necessary for safe design and maintenance. Software can be an embedded or integral part of the device, or the software itself may be a medical device.
IEC 62304 specifies requirements for software as a subset of requirements for a programmable electrical medical system (PEMS). Software is clearly a part of the verification process for the FDA, from the specification of software requirements to the integration of software items into a software system.
No one would be very pleased if medical devices or equipment caused pain and suffering or life threatening conditions. Sometimes they do, despite the best efforts of designers, engineers, programmers, product managers, compliance officers, and everyone else involved in complex designs.
Classifications have changed over the years—telehealth used to be Class II but has been relaxed to Class I in many cases. Conversely, security guidance has been strengthened due to IoT botnet takeover threats.
There are at least two reasons for wanting to reduce risk:
Increasingly, more functionality is being delivered by software in modern medical devices, from connection to the internet to storage and analysis of data. Development of hardware use cases now must include software use cases, and in many instances, the number of combinations and permutations grows quite large.
How can we be sure we have test cases for all conditions? Measuring how much of the software code is really tested is the job of code coverage tools. FMEA manual process tools only get you so far. If a piece of software is untested, it is to be untrusted. This could potentially result in unsafe and insecure medical devices.
The FDA 510(k) process requires IEC 62304 be implemented, which mandates the following processes: software development, software maintenance, problem resolution, risk management, and configuration management.
In the face of ever-increasing complexity and new computer languages and technologies, the importance of automating as much of the development and testing process as possible is key to improving quality.
One of the key factors in this is testing. The struggle in testing is to write test cases that exercise not only common paths, but also edge cases. As mentioned before, the FDA considers verification to be crucial.
The rules for FDA Class II clearance for market and FDA Class III are hard to figure out because the FDA has not updated its guidance in quite a few years. They don’t mandate the actual software development lifecycle, but they do mandate risk management. And they point to an IEC standard to do so.
What is sometimes missing is an understanding of the role that code coverage analysis tools can play. Code coverage analysis is an aid to producing test data, automating analytics, and automating some of the reporting for the state of the medical DUT (device under test). It’s also a way to assure the FDA, as well as yourselves, that all the critical paths and edge conditions have been tested.
You would think that the FDA would issue clear rules regarding what kinds of analysis and especially code coverage is required for Class II and Class III devices, but sadly they don’t. They offer a fairly old "General Principles of Software Validation," describing principles for validating medical device software, as well as the software used to design, develop, or manufacture medical devices. If you build a medical device or medical equipment, you must adhere to this document’s requirements and guidelines. Products that get classified as Class II or Class III also need to have rigorous design, development, testing, change management, and risk analysis design controls in place.
If your software is used (incorporated into) a product, it has to be validated. If the software is the entire product itself, of course you need to show in your 510(k) submission how it was validated. Surprisingly, software used in the creation of the software must also be validated, which is why it is important to select compiler tool chains and adjacent tools that are certified for use in the development of safety-critical systems. The Parasoft C/C++test and C/C++test CT products are TÜV SÜD certified.
Best practices as explained by the FDA include:
Not only are there obvious wins in increasing the confidence level of medical devices, but there are other benefits. For example, during development the code coverage tool can monitor which pieces of code were introduced but not tested. Monitoring changes to the code base over time increases visibility into the product.
Not only will it give the FDA confidence in your product, therefore increasing the likelihood of Clearance for Market or Approval, but it also reduces the load on development, quality, compliance, and other functions. This is the right thing to do—a "yes, we should do this to improve efficiency and reduce costs" move.
There’s no substitute for adopting automated software testing solutions that have been used in the safety-critical space before. This is where Parasoft comes in. The embedded software in a large number of medical devices, medical equipment, and other safety-required applications has been tested by Parasoft C/C++test. This fully integrated testing solution for C/C++ software development and Parasoft DTP are certified by TÜV SÜD ensuring that these products have been tested according to IEC 62304 for both host-based and embedded target applications. Therefore, complying with the requirements of national, regional, and international regulations for functional safety.
By putting in place a powerful automated testing and analytic reporting solution, software developers in test (SDETs) don’t have to rely on labor consuming and error prone manual approaches. Instead, they can focus on their core development activities and increase the depth and scope of their testing to deliver high-quality software. Supporting FDA requirements and easy to use, a solution like C/C++test employs static and dynamic testing while DTP manages progress towards compliance through a central reporting and analytics dashboard.
Automating unit test case generation is ideal for medical device testing when using an Agile methodology like scrum and DevOps because one of the requirements is that development engineers write unit test cases. As part of the build process and before code is checked in, C/C++test automatically runs unit test cases to make sure the code is free from regressions and other bugs. In addition, with a drop-down set of configurable options available, Parasoft collects required code coverage metrics.
Teams can also run Parasoft solutions from both an integrated development environments (IDE) as well as from the command line or shell. Find the full list of supported tool chains here.
C/C++test green highlighted code coverage and code coverage options.
Teams can view actionable analytics in any browser. DTP consolidates testing results in intelligent dashboards and detailed reports.
Parasoft DTP complete code coverage dashboard.
Code coverage tools like those from Parasoft can be integrated into a continuous integration/continuous delivery pipeline so that the solution does most of the heavy lifting. Since medical devices are increasingly the target of attacks, the stresses placed on development and engineering teams trying to climb on board the DevOps train and now being told to also consider DevSecOps, are enormous.
Fortunately, Parasoft’s ability to run in any number of IDEs and/or from the command line means integration is already provided and requires little to no configuration.
Parasoft’s solutions can test applications running on the following:
If your medical device is FDA Class III, though it requires more effort, it’s recommended to test on the target hardware because the standards are so much higher for Class III. Class II can be argued as acceptable to run on the host.
Here are five steps toward approaching implementation.
Ready to dive deeper?
