Safety Software Development Process and IEC 62304 Compliance
While the need, use, or device may be disparate, safety software development has common themes across industries. IEC 62304 does not specify the development process for software; it instead defers to other standards, namely IEC 61508-3
Some activities are essential to a quality software development process:
• Specification of software safety requirements that can be unambiguously implemented.
• Verification of these safety requirements, regardless of how they are implemented.
• Complete documentation of the design that explicitly describes the dataflow, timing, exception handling, etc.
• Implementation of the software based on requirements, architecture, and design, and review of code by manual and/or automated means.
• Testing the software units individually, and once the modules are integrated, tested together.
However, beyond the essentials, what makes a high-quality developmental process? –The Three Basic Tenets
#1: Say what you do
The developmental process must state how and when each activity will be performed, the tools used, and the expected outcomes, etc.
International standards such as ISO 9001 and ISO 13485 (medical specific) describe in detail the considerations required for the creation of high-quality processes, but the decisions of what to consider is up to the needs of the specific product and organization. Of course, once you go to the trouble of documenting this, it is important to train your staff on how development will occur, and this training has to be on a regular, on-going basis.
#2: Do what you say
After you’ve documented your processes, it’s important that the development, verification, quality, and testing teams follow those processes.
Training is important, but so is auditing. If you aren’t tracking adherence to the processes, you can’t claim conformance to the painstakingly created high quality development process.
#3: Be able to show a 3rd party that you did the first two tenets
When constructing your quality system, consider that you will likely be audited by external agents, whether these are customers, 3rd party certifiers, or other parts of your organization. These auditors will not understand your processes but whether your development was done in alignment with the other two tenets.
To be able to show this, you need to make certain that the result of each step leaves some collection of artifacts that shows that you did what you said you’d do.
Will following these tenets automatically mean that you’re fully conformant to IEC 62304 (or any other safety standard)? ―Not necessarily. But, if your organization makes a best effort in defining the processes in accordance with the standard, then most auditors/certifiers will work with you to map what you’re doing to the standard rather than requiring an immediate update to the processes.
From a security standpoint, these tenets are vital to the creation of secure software. Once a solid safety process is in place, expanding that process to ensure security is straight-forward.
But, What About SOUP?
What about other software that may not have been developed to the IEC 62304 standard? Does that mean you can’t use them? ―You can, but it’s all about managing risks. Any software can be used in a medical device as long as the risk of using the software is mitigated. Of course, the higher quality, better maintained, and better understood the software is, the more likely that the risks of using the software can be mitigated.
Often, the complexity of risk management pushes manufacturers into using a commercially available Linux such as Siemens® Embedded Sokol Omni OS or Sokol Flex OS. But, whether or not a commercial product is used, several aspects of the Linux in question must be considered, including:
• Functional and performance requirements
• Hardware and software requirements
• How upgrades, bug fixes, and patches will be managed
• How anomalies will be handled–Can you find them? If so, can you interpret them and fix them as needed?
Over the next decade, the management of security threats will become ubiquitously important to manufacturers of devices in all marketplaces, but especially vital in the medical device marketplace. Fortunately, the same thought process (and many of the same methodologies) that are part of the safety lifecycle can be re-applied to the security life cycle.
As a thought leader, it is vital that you drive this thinking throughout your organization. It’s a challenge that should be relished. Those who best solve the issues and concerns of customers and the public about industrial espionage and cyber-terrorism will have a significant competitive advantage for the foreseeable future.
Learn more about Siemens Embedded Software for Medical Devices
