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<\/p>\n\n\n\n
Some activities are essential to a quality software development process: <\/p>\n\n\n\n
\u2022 Specification<\/strong> of software safety requirements that can be unambiguously implemented. <\/p>\n\n\n\n \u2022 Verification<\/strong> of these safety requirements, regardless of how they are implemented. <\/p>\n\n\n\n \u2022 Complete documentation<\/strong> of the design that explicitly describes the dataflow, timing, exception handling, etc. <\/p>\n\n\n\n \u2022 Implementation<\/strong> of the software based on requirements, architecture, and design, and review of code by manual and\/or automated means. <\/p>\n\n\n\n \u2022 Testing<\/strong> the software units individually, and once the modules are integrated, tested together.<\/p>\n\n\n\n However, beyond the essentials, what makes a high-quality developmental process? \u2013The Three Basic Tenets <\/strong><\/p>\n\n\n\n #1: Say what you do <\/strong><\/p>\n\n\n\n The developmental process must state how and when each activity will be performed, the tools used, and the expected outcomes, etc. <\/p>\n\n\n\n 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. <\/p>\n\n\n\n #2: Do what you say <\/strong><\/p>\n\n\n\n After you\u2019ve documented your processes, it\u2019s important that the development, verification, quality, and testing teams follow those processes. <\/p>\n\n\n\n Training is important, but so is auditing. If you aren\u2019t tracking adherence to the processes, you can\u2019t claim conformance to the painstakingly created high quality development process.<\/p>\n\n\n\n #3: Be able to show a 3rd party that you did the first two tenets<\/strong> <\/p>\n\n\n\n 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. <\/p>\n\n\n\n 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\u2019d do. <\/p>\n\n\n\n Will following these tenets automatically mean that you\u2019re fully conformant to IEC 62304 (or any other safety standard)? \u2015Not 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\u2019re doing to the standard rather than requiring an immediate update to the processes. <\/p>\n\n\n\n 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. <\/p>\n\n\n\n But, What About SOUP?<\/strong> <\/p>\n\n\n\n What about other software that may not have been developed to the IEC 62304 standard? Does that mean you can\u2019t use them? \u2015You can, but it\u2019s 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. <\/p>\n\n\n\n Often, the complexity of risk management pushes manufacturers into using a commercially available Linux such as Siemens\u00ae 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:\u00a0<\/p>\n\n\n\n \u2022 Functional and performance requirements <\/p>\n\n\n\n \u2022 Hardware and software requirements <\/p>\n\n\n\n \u2022 How upgrades, bug fixes, and patches will be managed<\/p>\n\n\n\n \u2022 How anomalies will be handled\u2013Can you find them? If so, can you interpret them and fix them as needed?<\/p>\n\n\n\n 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.<\/p>\n\n\n\n As a thought leader, it is vital that you drive this thinking throughout your organization. It\u2019s 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.<\/p>\n\n\n\n