Welcome back to our series on Static & Dynamic Analysis, including Unit Testing. Our previous post provided a brief introduction to static analysis, what it is, and how it has developed. Today we’re going to look at guidances, standards, and best practices for static analysis with respect to software development for medical devices.
Coding rules and guidelines exist to ensure that software is:
· Safe - usable without causing harm – especially critical in the medical field, where code that supports functions that would typically be innocuous could have a ripple effect impacting patient safety
· Secure - not able to be hacked
· Reliable -the device functions as it should, every time
· Testable- ability to be tested at the code level.
· Maintainable – applicable even as the codebase grows. We saw an example of unmaintainable code with the Toyota acceleration issue. When Toyota analyzed their dysfunctional code, they found that it had become unmanageably complex over years of continuous development with insufficient checks and oversight.
· Portable - the functionality is the same in varying environments and can be used on multiple systems
Using established coding standards:
· Ensures compliance with ISO (the International Standards Organization), which is required for most major medical device markets
· Guarantees consistent code quality – no matter when or who writes the code
· Secures the software right from project start
· Reduces costs by speeding up time-to-market through reduced variability and uncertainty, as well as by decreasing overhead for post-market support
Following the regulations makes the code easy to review and debug, allowing for secure software to be developed more quickly and with greater assurance, increasing premarket development speed and decreasing the amount of patching necessary to fix issues or concerns post-market.
Even though IEC 62304, the ISO guidance on software development for medical devices, does not explicitly include static analysis as part of its direction, the FDA premarket guidance now specifically calls out secure static analysis testing. Other regulatory bodies such as those in the EU, Canada, and Australia are also catching up on requiring static analysis. Noncompliance exposes not only your business but also your potential patients to significant risk or harm.
Functional Standards define the minimum operational requirements of a system, and it’s components. In the medical device industry, these are typically related to functional safety as it is a safety-critical sector. Examples of these are shown below:
· IEC 61508 – “Functional Safety of electrical/electronic/programmable electronic safety-related systems”
· IEC 62061 – “Safety of machinery: Functional safety of electrical, electronic and programmable electronic control systems”
· ISO/IEC TS 17961 – “Information Technology – programming languages, their environments, and system software interfaces”; security coding rules.
Coding Standards are a collection of coding rules, guidelines, and best practices to improve the safety, quality, and security of the implementation. These may also include guidelines on coding style. Examples of these are shown below:
· MISRA (Motor Industry Software Reliability Association) - one of the most popular coding standards. The original version (1998) emphasized safety, quality, and reliability, but it was revised in 2012 to include Static Analysis for Secure Testing (SAST) based on CERT C.
· CERT C by SEI (Software Engineering Institute) - created in 2008 specifically for security, using ISO 17961 as its baseline, and geared specifically for SAST. Its latest revision was published in 2016
CERT C and MISRA 2012 have some areas of overlap, but because of their different emphases, our best practice recommendation is to integrate CERT C with MISRA 2012 and apply them both.
In general, static analysis should be performed each time code is compiled and committed or pushed, prior to any formal code review, and before unit testing. It should become a habit to perform static analysis on a regular cadence throughout each project. The pattern then reinforces coding best practices, so that it becomes easier to remember the critical rules and apply them while developing. The result is not only a cleaner code base and a more reliable product but a faster, more efficient development cycle.
Next time, we’ll introduce dynamic analysis and dive into unit testing. If you’d rather not wait, click here to download our free white paper!