This is a guest blog post written by Dr. Marion Lepmets. Dr. Lepmets has an extensive academic background in medical device software development and co-authored IEC TR 80002-3, the process model for medical device software lifecycle processes. She is the CEO and co-founder of SoftComply.
When someone’s life is in your hands, you are going to be very careful with it.
That’s why the safety-critical software used in aviation systems, automotive, traffic signals, or medical devices has always relied on highly-structured software development methods like waterfall. With a heavy emphasis on design review and testing, these methods are naturally quite slow.
But, with the ever-increasing pressure to move faster, even these traditionally highly-regulated domains have been undergoing a quiet transformation to agile, cloud-based methodologies.
Regardless of your development model or toolset, there are some key issues that set the development of safety critical software apart from the majority of enterprise- or consumer-facing applications.
1) Time to market is resource- and time-consuming
Safety-critical software has to adhere to a region-specific regulatory framework. In other words, these devices are required to pass a regulatory audit prior to being placed into the market. The audit entails presenting evidence of rigorous planning and documentation, i.e. a Design Technical File and a Quality Management System (ISO 13485 for medical devices).
How to meet this challenge:
There are several international standards that provide guidance to companies regarding these regional regulations in safety-critical domains and prepare for the regulatory audits such as IEC 60601 for medical devices, ISO 26262 for vehicle functional safety, and ISO 14971 for risk management.
All of the above means that companies developing safety-critical software have to commit a lot of resources and time to adhere to the regulations in order to pass the audits and place their products on the market. This can be challenging, especially for smaller companies and those new to the requirements for developing software for regulated applications. Implementation of the required processes is considerably easier when appropriate software tools are used that help automate various regulatory aspects and that integrate with the software development environment.
2) The need for detailed, formal specifications
Safety-critical products can often be very complex and as such, they are developed by many teams or sometimes even numbers of companies working together. In order to pass regulatory audits associated with product approval, detailed specifications have to be recorded, including any changes to these specifications as well as their approval. Regulatory audits require a documented history trail, for example, a history of all the changes that were requested, approved and implemented throughout the system or device development lifecycle.
How to meet this challenge:
In order to manage the requirement specifications and the device and software risks of complex safety-critical systems, communication and collaboration between development teams needs to be smooth and transparent. This is doubly the case when there are changes in the specifications or if teams are using different development approaches.
For example, a medical device manufacturer specifies the overall requirements for the device. It then communicates the requirements of the sub-systems to the allocated software, electrical, and mechanical development teams. These teams have to work together to communicate any requirement dependencies, risks, and changes that affect the other sub-systems to enable the effective integration of the sub-systems, as well as and mitigate any foreseeable risks of the sub-systems to ensure the effectiveness and safety of the entire device.
3) A risk-driven approach to ensure that the medical devices are safe to use
Safety-critical software systems are developed within a risk-based framework: the regulatory framework requires the assessment and mitigation of all reasonably foreseeable risks prior to placing the products on the market. A risk assessment includes the determination of key hazards, risks, failure modes, and mitigations, for software where the device risks have to be linked to software items.
How to meet this challenge:
International standards like ISO 14971 provide guidance about medical device risk management and how risks have to be assessed and mitigated within the software lifecycle. Each mitigation action must be tested to verify that the mitigation works as intended and that the new mitigation action (which can often be another software item) does not introduce a new risk. If a new risk is introduced, it needs to be assessed and mitigated following the same risk management process. All risk management related activities should be documented and follow a documented plan that was set up prior to the risk assessment being performed.
Regulatory audits often require full traceability of risk management activities where the auditor checks that everything that has been built was analysed for risks and that each risk has been mitigated. This includes confirming that the mitigation action has been verified/tested and that new risks or changes to risks have also passed the same risk assessment process.
4) Formal verification and traceability
In addition to rigorous planning, requirements management, and risk assessment, safety-critical software systems are subject to a documented formal verification process.
How to meet this challenge:
This entails establishing documented verification plans that outline the overall strategy and approach to the testing of the software systems. Test cases are typically also documented with pass/fail criteria set and approved prior to the testing. Test results are typically also formally recorded, reviewed and signed off.
Regulatory audits require full traceability of software development activities whereby checks are carried out that confirm that everything that has been specified was built and that everything that was built has also been appropriately verified.
Solution overview
Most of these requirements pose serious challenges for safety-critical software systems developers. A lot of regulatory affairs tasks are still managed manually today – this may be highly error-prone and cause downstream issues in the construction of technical files for product registration and in regulatory audits.
Supporting these tasks with the use of software tools such as Jira and SoftComply’s Risk Manager is becoming best practice as such tools are integrated into the software development environment. This provides the benefits of assisting in team collaboration, product definition, and in providing the risk management and traceability that is crucial for safety-critical domain software companies.