5 Tips for Static & Dynamic Analysis in Medical Device Software

Cybersecurity is a strong FDA focus with specific requirements around static and dynamic code analysis. As a result, it’s important for engineers to automate these practices and integrate them into existing development workflows.

For companies that develop and deliver safety- and security-critical software for medical devices, implementing static and dynamic code analysis practices and deploying them on projects ranging from relatively simple blood glucose meters to more complex systems such as infusion pumps, patient monitors, and lung ventilation units is integral to the process. This post covers static vs dynamic code analysis in medical device software and shares practical tips and best practices.

Introduction to Medical Device Software Risk Analysis

Medical devices are an essential part of the modern healthcare system. The World Health Organization (WHO) estimates that there are about 2 million medical devices worldwide. Given the evolution of artificial intelligence (AI), machine learning (ML), and the Internet of things (IoT), modern medical devices have become more connected than ever, increasing their level of complexity and use cases.

With the growing integration of technology in medical practice, medical devices increasingly rely on software to perform some key functions. For instance, medical devices can do things, such as analyze medical images and provide diagnostic support, deploy smart implants with sensors that communicate with desktop or mobile devices, and perform robotic surgical procedures, among other things. While medical device software has advanced the field of medicine, it leaves us with some risks that must be carefully managed.

Medical device software risks can come from various sources, including coding errors, hardware malfunctions, user errors, and so on. These risks can potentially cause harm to patients, healthcare professionals, or anyone who comes in contact with the device.
In addition to the above risks, cybersecurity risks surround these devices as they collect, store, process and transmit medical data. Hence, regulatory bodies like Food and Drug Administration (FDA) are there to regulate the manufacturing and deployment of medical device software. However, to know if your medical device software complies with these regulatory standards, conducting a thorough medical device software risk analysis is vital before using them.

What Is Medical Device Software Risk Analysis?

Before discussing medical device software risk analysis, let’s look at risk. In the most basic definition, risk is the possibility of loss or injury. Medical device software risk analysis is the process of testing medical device software to identify, evaluate and mitigate the risks associated with them. It also involves testing the software’s intended use, functionality, and potential hazards to patients or operators using some risk management benchmarks.

For medical device manufacturers, risk analysis is an essential component of the medical device software development process. It’s an essential requirement that helps medical device manufacturers to meet regulatory standards.

The primary goal of medical device software risk analysis is to ensure the software is safe and effective, not just for medical use, but also to ensure that these devices are not susceptible to cyber attacks and result in a significant data breach.

Why Is Medical Device Software Risk Analysis Important?

Imagine putting a car on the road without checking some of the critical parts like the brake system, airbag, lights, suspension, and steering systems. Ignoring these checks could increase the probability of having a car accident. The same goes for deploying medical device software without subjecting it to risk analysis.

Medical device software risk analysis is crucial for ensuring patient safety and reducing the potential occurrence of medical hazards and security breaches on patients’ medical records.

Furthermore, regulatory agencies such as the FDA require medical device manufacturers to perform risk analysis on their medical device software before they can be approved for consumer use. Failure to comply with regulatory requirements can cause delays in device approval or lead to recalls.

In other words, risk analysis can also help manufacturers identify opportunities to improve device safety, security, and usability, potentially leading to increased sales and market share.

The Regulatory Framework for Medical Device Software Risk Analysis

Medical device software development is regulated by various regulatory bodies such as the FDA and European Medical Device Regulation (MDR).

As a regulatory agency, the FDA ensures the safety, efficiency, and security of human and veterinary drugs, biological products, medical devices, food supplies, cosmetics, and other products. The FDA’s mission is to protect and promote public health by regulating and supervising the development, manufacturing, marketing, and distribution of these products.

Similarly, ISO 13485 is a globally recognized standard that outlines the requirements for quality in the medical device industry. This standard offers practical guidelines for manufacturers to implement business and technical practices to ensure that all medical devices meet regulatory compliance and customer needs.

By adopting the best practices and processes outlined in ISO 13485, manufacturers can streamline their operations, lower costs, manage risks, increase productivity, and continuously improve their products and services.

There is also IEC 62304, which is a set of international standards that provides guidelines for the development, maintenance, and risk management of medical device software. The framework outlines the requirements that must be met to ensure that software used in medical devices is safe, reliable, and meets acceptable standards. IEC 62304 specifies software development processes, documentation requirements verification and validation procedures.

These regulatory frameworks are designed to serve as standards for conducting risk analysis on medical devices. Therefore, compliance with them is essential for obtaining regulatory approval for developing medical device software and demonstrating a manufacturer’s commitment to excellence and ability to deliver high-quality products.

For medical device software manufacturers to comply with these regulations, software testing processes are often required to check for programming errors, coding standard violations, syntax violations, insecure configurations, and the like. This is where static code analysis and dynamic analysis come in.

Static Code Analysis

Static analysis is a practice of automatically checking compliance with well-known coding guidelines (MISRA, CERT, AUTOSAR, JSF) and detecting potential bugs such as null pointer dereferencing, division by zero, and buffer overflows. Modern static analysis tools also complement the traditional code review practice by reducing manual effort by at least 30%.

In most cases, the first run of a static analysis tool against your current code will show thousands of errors. Some medical device development teams have encountered even 20,000+ on the first run. This can be incredibly overwhelming. It seems like it would take years to fix all of them. Here are some expert tips to cope with the problem.

Tip #1: The Compiler Is Your Friend

Disciplined development teams usually compile with –Wall and –Werror (in GCC), or /Wall /WX (in Visual Studio) or using similar options in other compilers. Fixing compiler warnings is an easy and inexpensive way to prepare for static analysis execution. Reviewing the output of your compiler in a “paranoid” mode can reduce the overall volume of static analysis violations.

While having fixed all compiler warnings is a good thing, there are many projects where using just a compiler will not be enough and isn’t an acceptable option for compliance reasons.

After draining your compiler dry, use static analysis tools that are meant to dig much deeper into the code and give you a lot more hints.

Tip #2: Adopt Static Analysis Early in the Process

If you’re currently developing medical device software, then you should be prepared to address the question of an automated static code analysis practice. Static analysis is almost guaranteed to be a subject of discussion during an internal/external audit or even a premarket submission.

The key is to deploy the tool in such a way that development does not lose velocity while focusing on improving quality, and doesn’t have to deal with tool idiosyncrasies and noise. This is a balancing act, requiring practice and expertise. What you might find is that while discovering the root cause of the reported errors, you are likely to find out that many of them are easy to fix.

Here are a few examples from a static analysis report that are easy to fix with simple script or well-trained interns.

1. Call of clear functions in destructors.
   1. Destructor ‘~CTitle’ should not call function ‘clear_’ that is not in try context
   2. Destructor ‘~THelper’ should not call function ‘removeModule’ that is not in try context
2. Check for NULL.
   1. “pMP” may possibly be null
   2. “((NPage*)this)->pSysCfg_” may possibly be null
3. Possibly declaration in the wrong section.
   1. Data members ‘D_FILE_1’ is declared as ‘public’
4. Non-constant arguments.
   1. String literal “MCollection” is passed to function ‘FixedBlockHeap’ as pointer to non-const object

Many violations on existing code you can set aside and deal with them when you have downtime. However, it’s important to NOT introduce new violations, known as technical debt, as you develop code. For example, Parasoft C/C++test has features that allow engineers to filter the noise and focus on fixing the most critical recent static analysis violations.

Dynamic Analysis

While static analysis interprets the source code as text and makes all conclusions based on parser output without executing a single instruction, dynamic application security testing or DAST provides a different perspective on the code. It examines the running code, showing the code coverage, sufficiency, and quality of unit tests, memory leaks, and other potential weakness problems.

Tip #3: Be Flexible With Your Runtime Environment

The term “embedded” covers a lot of devices from 8-bit MCU with kilobytes of RAM and flash to 64-bit multicore CPU with gigabytes of RAM and high-speed SSD. In case the device’s daily operation requires minimal memory and processing power, manufacturers are likely to opt for hardware geared only towards its needs, addressing size, weight, or cost constraints.

Although they usually leave some capacity for software updates and maintenance, it may still be insufficient when it comes to the dynamic analysis tool instrumenting the software, as the process will require a huge amount of RAM compared to normal operation mode and storage space to collect test and code coverage results.

Therefore, when the amount of memory on the device is too low to run testing and collect code coverage, the target platform may not be suitable for collecting code coverage for unit and integration testing.

If your main target platform is not supported out of the box, search for valid alternatives. There could be a sister platform with more interfaces and memory being supported by a dynamic analysis tool so you can use it for unit and some integration testing. Another alternative is to use hardware simulators, which run ARM Fast Models and QEMU.

While running testing on target platform is the most desirable, many times teams opt out to perform unit and some application integration tests on the developer’s workstation, such as Linux, Mac, Windows, to benefit from a faster development cycle and a larger number of tools available for general development platforms. In that case, you’ll need to port your embedded code to compile with a host compiler, which might present some challenges.

There are plenty of compilers, build tools, frameworks, and methods to run them. Dynamic analysis tools support some common build techniques with internal presumptions on how developers might apply them. Therefore, even if the code is portable, most likely the project team will need additional time to align settings of a dynamic analysis tool depending on how the project’s build system works.

All efforts are highly recommended to be estimated in advance to pick up the best approach for future development and support in the long-term perspective.

Tip #4: Don’t Overly Rely on Autogenerated Test Cases

Modern dynamic analysis tools automatically generate sets of unit tests to increase code coverage. But tools are just tools. They’re agnostic of various scenarios of how the production code is intended to be used, especially when you’re trying to increase code coverage and cross a border between pure unit tests and integration tests. You will still have to manually update the generated unit tests and even write new ones because only you know what the code is intended to do when it comes to positive and negative test results.

A set of selected files in a critical area can have automatically generated unit tests covered in a range from 40% up to 100% for each file. But on average, for the whole project, numbers may vary from 25% to 60%.

In addition, autogenerated unit tests using only source code as input can often run perfectly on buggy code. Auto generation should be used as a good way to start the process of unit testing. The process of creating test cases manually improves the quality of the code because it forces additional code review and provides a different vantage point on the design.

Tip #5: Don’t Underestimate the Effort of Tool Qualification & Validation

The FDA requires any tool used during formal development to be validated for intended use to ensure it performs expected actions and produces the right results. Usually, this is a special test protocol called IUV (intended use validation).

Industry-leading vendors of static and dynamic analysis tools help produce necessary procedures and documentation, which is extremely helpful to minimize your efforts. Parasoft’s solutions are especially valuable because it automates a large part of the process. The same as with any other generic package, you might want to reserve some of your efforts to review and adjust documents in order to sync them with your own QMS procedures. For example, Parasoft’s Tool Qualification Kit provides a set of test cases to be executed on your environment to validate the static and dynamic analysis capabilities.

5 Tips Recap

Treat compiler warnings as errors. Warnings can become errors later for the newer version of the same compiler. Warnings often mean that the compiler does something implicitly.

1. Run static analysis tools early in the project and fix issues as they appear.
2. Keep code portable. Even if you don’t plan to port your product to another platform, this might be an option in the future. On the other hand, this will also help keep your code clean, maintainable, and readable which is always good for review and further support.
3. Do not overly rely on autogenerated test cases to improve code quality.
4. Do not underestimate the need and the effort to validate the tool for its intended use.

Risk Management in Medical Device Software Development

When developing software for medical devices, managing risks is a critical component of the process. Medical device software is often complex and must function within strict benchmarks to ensure the safety, security, and efficiency of medical devices. As a result, it’s essential to identify, analyze, and mitigate potential risks that could arise during the development process.

• Effective risk management in medical device software development involves a number of different activities. These might include:
• Identifying potential hazards and risks associated with the device and its software.
• Evaluating the likelihood and severity of the risks.
• Implementing risk controls to mitigate or eliminate risks.
• Monitoring the effectiveness of those controls over time.

In addition, risk management in medical device software development also requires a deep understanding of the level of harm a defect in medical software can cause. This can be done through risk indexing, which categorizes risks according to their severity level.
In the context of medical device software, establishing a risk index helps to determine risk management indicators, such as the required level of testing, verification and validation that should be performed on the software before it is released for use. It can also help set the tone for continuous testing, monitoring, and maintenance that may be required to ensure the software’s continued safety and effectiveness.

The Importance of Risk Management in Medical Device Software Development

Effective risk management is critical in the development of medical device software. Even minor errors or oversights can have severe consequences for patients in the healthcare sector. Consequently, it’s essential to identify and mitigate potential risks as early as possible in the development process.

Below are some of the reasons why risk management is important in medical device software development:

• Ensures patient safety. Medical device software failures can lead to health hazards. Effective risk management helps identify potential risks and mitigate them before they cause harm to patients.
• Ensures regulatory compliance. Medical device software development is subject to regulatory requirements set by regulatory bodies like FDA and EU MDR. Compliance with these regulations is essential to avoid penalties and reduce the likelihood of product recall. It can also save medical device manufacturers from being held liable for any harm caused by their products, saving them from legal and financial consequences.
• Saves time and money. Effective risk management can help reduce the time and cost of dealing with product issues and legal actions. Identifying risks early in the software development life cycle can prevent issues from arising later and prevent delays in product time to market.
• Boosts reputation. No medical device manufacturer would want to risk having a poor reputation, as a dented reputation can affect the chances of success. Effective risk management helps demonstrate that the manufacturer is committed to patient safety and product quality, which can enhance a company’s reputation.

Key Elements of Risk Management in Medical Device Software Development

Conducting risk management in medical device software development can be complicated. However, there are key elements that can serve as a guide to medical device software developers and quality assurance testers. Here are five of them.

1. Start with risk identification. The first step in risk management is identifying potential risks associated with the medical device software development process. This can be done through a thorough analysis of the software design, development, and testing process. Potential risks can include software malfunctions, data security breaches, and hardware failures.
2. Conduct a risk assessment. Once risks have been identified, the next step is to assess the severity and likelihood of each risk. This involves considering factors such as the severity of the risk, the likelihood of the risk occurring, and its potential consequences.
3. Develop risk mitigation and control measures. At this point, the aim is to develop risk mitigation strategies to reduce or eliminate identified risks. This can include redesigning the software, implementing safety features, or providing user training. The developers could also develop risk control measures to minimize or eliminate the identified risks by taking actions such as redesigning the software, implementing additional safety features, or developing user manuals and training programs for the device.
4. Monitor the risks. Monitoring the potential risks in medical device software should be a continuum. This means that even after risk mitigation and control strategies have been put in place, it’s crucial to continue monitoring risks throughout the software development life cycle. This can involve ongoing testing and evaluation of the software to ensure that it continues to function as intended and does not pose any new risks.
5. Document the risks. It’s important to document all risk management activities, including risk assessments, risk mitigation strategies, and ongoing monitoring. This documentation is critical for demonstrating compliance with regulatory requirements and ensuring that risks are effectively managed throughout the software development process.

Summary

Risk management is a crucial aspect of medical device software development. Subjecting medical devices to static and dynamic analysis are two of the best ways to assess risks in medical device software.

With static and dynamic analysis, medical device software developers can identify potential risks early, prevent harm to patients, ensure regulatory compliance, save time, and build software that’s less vulnerable to cyber attacks.

Fortunately, Parasoft offers a comprehensive set of software test automation solutions that support various best practices for medical device testing in C/C++, Java, and .NET applications. These tools have been proven to enhance the safety, reliability, and user experience of medical device software.

“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.