The Role of Static Analysis in the EU Medical Devices Regulation (MDR)

The move to digitization and automation is happening in the medical industry as it is in others – almost every medical device requires software. Wireless connectivity is becoming increasingly important in order to exchange data or connect sensors increasing the probability of security risks.

The positive aspects of this shift to connectivity is better monitoring of patient vitals and statistics, new therapeutic approaches and more precise diagnoses. However, this comes with several downsides such as increased risks from software or hardware failures, potential vulnerabilities to attacks, and ultimately, endangerment to life and limb of patients. The benefits are worth the extra effort needed to mitigate these risks. Rather than giving up on these benefits, the goal must be to make the software as safe and reliable as possible. Ultimately, the regulations for medical devices are aimed precisely at managing and reducing the impact of these risks.

EU Medical Devices Regulation

The Medical Devices Regulation EU 2017/745 (MDR), with the end of the transitional period for the implementation as of May 26, 2020, the requirements will be significantly tightened again. These new regulations impact both software requirements and workflows for embedded developers.

There are basically two scopes for standards and regulations: One is the quality assurance in development and the other is quality management throughout the lifecycle of a product, from concept to end of life. The MDR makes it clear that the latter is the required scope:

For devices that incorporate software or for software that are devices in themselves, the software shall be developed and manufactured in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation.- (MDR 2017/745 section 17.1)

The fact that new developments in the medical field must meet higher quality standards is made obvious by the fact that the quality control of products already on the market has been poor. Improvements are needed to prevent patient injuries. It’s also important for standards to take into account that software-based or even software-only products undergo significant changes over their lifetime. For example, by integrating new functions via an update or even if software library used in development is replaced by a newer version. Upgrades and updates alone are a significant source of concern which can render a hitherto problem-free system vulnerable — even updates with bug fixes themselves may contain new bugs.

Minimize risks to patients

For software developers, four standards form the foundation of the requirements of MDR:

• EN 60601-1 – Medical Electrical Equipment – Part 1- General Requirements for basic safety and essential performance
• IEC 62304 – Medical device software – Software lifecycle processes
• IEC 82304 – Health software – General requirements for product safety
• ISO 14971 – Medical devices — Application of risk management to medical devices

The foundation for medical device safety is outlined in EN 60601-1, the basic standard for medical electrical equipment. It requires these devices to be developed and manufactured in such a way that they are “first-fail-safe” meaning that no first fault of the system shall render further use of the device unsafe.

The basic assumption of the generic functional safety standards like IEC 61508 for electrical, electronic and programmable electronic systems start with the assumption that it is not possible to produce mass-produced products that are entirely safe to use at an economically justifiable expense over the entire service life. Instead, the goal of these standards is to minimize the number of errors and minimize the risk to users. Medical devices must justify the overall risk to the patient in order to be approved for use unlike automobiles, for example, which despite modern technology, have an inherent risk when used.

Verification and validation

IEC 62304 requires, in Section 5.5.2, that the medical device manufacturer establish a Software Unit Verification Process. More precisely, the process must introduce a strategy, methods and procedures to check every piece of code for formal correctness and accuracy. In addition, the software must be validated and tested to see if it provides the required function. However, it becomes clear that the authors of IEC 62304 were more concerned with medical software as part of an embedded systems rather than separate application software. The standard makes few statements about the validation of the software alone. To address medical or health software, the missing guidelines for application software are now covered by IEC 82304.

IEC 82304 explicitly applies to stand-alone software and is not limited to medical products in the strict sense, but also applies to products that generally pursue an improvement in individual health. In many parts, IEC 82304 explicitly refers to IEC 62304, so both frameworks essentially overlap. For quality management guidelines to be used throughout the life cycle, for example, IEC 82304 refers to IEC 62304. The new standard is also dedicated to the validation of software alone, something that plays less significance in IEC 62304. IEC 82304 addresses the widespread criticism of the lack of concrete guidance on how software can be validated in IEC 62304. The good thing is that tools and processes in place to support medical device software can be leveraged for stand-alone medical software as well.

Drawbacks of Traditional Functional Testing

Testing is crucial for validation, proving the software meets its purpose, mostly it’s functional requirements. However, in the case of verification, classic testing has two drawbacks:

1. Executable code and real or simulated target environments must be available which is difficult to achieve at very early stages of the development process.
2. Testing can only find errors if three conditions are met simultaneously:
   1. The test case must execute the portion of the code with the fault,
   2. The error must lead to an error condition, and
   3. The error condition must lead to a deviation of the result from the expected result.

In order to find errors in code more reliably, static code analysis is an established technique. In some safety-critical areas, such as aviation, static analysis is enshrined in the standards.

Static Analysis

In static code analysis, the code is examined using a model, known as an Intermediate Representation (IR) which describes the control and data flows and algorithms are used to traverse this model during the analysis. All control and data flows are considered during analysis which means errors can be detected that might be missed in typical testing techniques. Examples of complex errors that advanced static analysis tools can discover include buffer overruns or null pointer dereferences which may lead to insecure access to data sources. Static analysis tools are also capable of ensuring conformance to industry coding standards and corporate programming guidelines.

Advanced commercial static analysis tools like GrammaTech CodeSonar give the developer insight and tools to help detect and fix safety, security and quality issues. In addition, the tool generates comprehensive reports, which simplify documentation requirements during audits. Another unique feature of CodeSonar is binary code analysis which means object files, libraries and even third-party binary products can be analyzed. This is useful in managing the software supply chain of third-party applications, middleware and operating systems — increasingly being used in embedded development.

Applicability of Static Analysis to Medical Device Software

Although IEC 62304 (on which MDR relies on for medical device software development) doesn’t call out specific development tools, it does indicate the need for rigorous testing, acceptance criteria, and traceability. Performing these functions without tools isn’t practical given the scope of most medical device software projects. For example, (excerpts from the standard):

• Section 5.5.2 of IEC 62304 requires a software unit verification process: The MANUFACTURER shall establish strategies, methods and procedures for verifying each SOFTWARE UNIT.
• Section 5.5.3 requires: The MANUFACTURER shall establish acceptance criteria for SOFTWARE UNITS prior to integration into larger SOFTWARE ITEMS as appropriate, and ensure that SOFTWARE UNITS meet acceptance criteria…does the software code conform to programming procedures or coding standards?
• Section 5.5.4 provides additional acceptance criteria:
  • When present in the design, the MANUFACTURER shall include additional acceptance criteria as appropriate for:

   

  1. proper event sequence;
  2. data and control flow; 

  3. planned resource allocation; 

  4. fault handling (error definition, isolation, and recovery);
  5. initialisation of variables; 

  6. self-diagnostics; 

  7. memory management and memory overflows; and 

  8. boundary conditions. 


Many of these acceptance criteria are well suited to static analysis. In fact, the case for static analysis is so strong, the FDA has used GrammaTech CodeSonar to analyze medical device software to evaluate the quality of the source code following a series of infusion pump failures.

Accelerating Medical Device Development and Standards Compliance

Static analysis tools offer support for rigorous testing and documentation required for pre-market approval in the following ways:

• Static analysis finds bugs that coverage-based testing techniques miss: Unit testing is often measured by the level of coverage, such as statement and decision coverage. Although rigorous, there are defects that make it through this type of testing that static analysis tools can discover. 
• Static analysis detects defects early: Preventing defects from occurring at the developer’s desktop is the ideal situation — it saves money in testing and remediation that increases as a project progresses. 
• Static analysis can handle SOUP: Software of Unknown Pedigree/Provenance (SOUP) requires special handling in medical device software, and good static analysis tools are capable of evaluating the quality and security of third-party and commercial off the shelf software (including binary-only executables and libraries).
• Static analysis accelerates documentation, traceability and testing evidence: Documenting the results of software unit acceptance is critical to proving compliance to certification standards. Static analysis tools have rich reporting features to help support certification requirements.

Summary

The numerous standards for medical products cause significant costs for medical device manufacturers. With the new MDR guidelines they may increase in order to meet the stricter standards, as risk assessment requires more scrutiny in order to reduce the classification of a device. Advanced static code analysis significantly simplifies the verification of software. Errors are detected early and can be fixed with less effort, before the integration into the software build, at the developer’s development environment. Static analysis provides both faster time-to-market and higher code quality – and ultimately, both aspects benefit the patient’s health.

---

Interested in learning more? Read our guide on “Using Static Analysis for Overlapping Safety and Security Requirements for Medical Devices”

{{cta(’77d4b926-0c3e-40f7-bb8e-197a3917a865′)}}