INTRODUCTION:
The IEC/ISO 62304 standard defines a risk and quality driven software development process for medical device software. The standard emerged from a recognition that software plays a significant role in medical devices and that software quality and risk management are essential to developing safe software. Medical devices are expected to be developed with good engineering practices (under the umbrella of a Good Manufacturing Process). Software development tools, and static analysis tools in particular, are part of good software engineering practice and help medical device manufacturers achieve safe and reliable software.
Related:
- The ROI of Static Analysis in Safety-Critical Software Development
- Federal Drug Administration (FDA) Recommends Static Analysis for Medical Devices
- FDA Uses GrammaTech to Analyze Recalled Medical Devices
Applicability to Medical Device Software
Although the standard 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:
- 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:
5.5.4 Additional SOFTWARE UNIT acceptance criteria
When present in the design, the MANUFACTURER shall include additional acceptance criteria as appropriate for:
a) proper event sequence;
b) data and control flow;
c) planned resource allocation;
d) fault handling (error definition, isolation, and recovery);
e) initialisation of variables;
f) self-diagnostics;
g) memory management and memory overflows; and
h) 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.
Helping with Certification
In previous posts, I’ve outlined the benefits of static analysis for safety-critical software development. The same benefits apply here for medical devices and projects working to IEC 62304, but to summarize, static analysis augments dynamic analysis and rigorous testing 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 certification 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.
The Significance of SOUP
The standard calls out SOUP (typically third-party and commercial software) and how it should be handled in medical device software. Section 7.1.2 (part of the risk-management process) details, “The MANUFACTURER shall identify potential causes of the SOFTWARE ITEM identified above contributing to a hazardous situation .. failure or unexpected results from SOUP.”
Section B.1.2 Field of Application states, “It is assumed that through proper performance of MEDICAL DEVICE RISK MANAGEMENT, the MANUFACTURER would understand the component and recognize that it includes SOUP. Effectively, a medical device manufacturer needs to understand and manage the risks of using SOUP. Retroactively unit testing third-party source is difficult and for binary products it’s nearly impossible.
Static analysis tools can analyze source and binary products and provide reports on quality and security that feed into the risk management and testing processes.
CONCLUSION:
Although the IEC 62034 standard doesn’t explicitly call for static analysis tools, there are very compelling reasons to support their use. The ability to support and enhance testing and acceptance processes and the analysis of SOUP means better quality, safety, and security for medical software.
Interested in reading more on IEC 62034? Check our our guide on “New Approaches Needed for Medical Device Software Development” here:
{{cta(‘9f0ef01d-c1c5-4a2c-8669-4c2ee6d548d8’)}}
