More and more medical devices depend on software. Therefore the number of reports about problems caused by software is rising dramatically (BfArM 2007). It is necessary to develop software which is error free and safe from the beginning as well as to consider all risks and hazards.
A structured and traceable development is essential, because even the smallest mistake during the development of medical devices can result in fatal consequences. For the software development there are no safety instructions and the software for medical devices can be a very complex system. The Assurance Case is used to structure and divide this complex system in parts that are easier to handle.
The Assurance Case is a documented line of evidence method which uses a convincing and valid argument to proof the accumulation of critical claims by significant evidences.
The structured argumentation and evidence support the reliability of the main claim: e.g. „The device is safe”. If the main claim refers to the safety of the device (like in the given example) the Assurance Case can be called Safety Case.
Assurance Cases were initially used in the nuclear technology, aerospace engineering and the defense industry where they are mainly used as Safety Cases.
The Assurance Case is sub-divided in three main categories which are characterized by symbols:
The claims have to be in a specific context, which can be in relation to the environment, application, behavior, risks or hazards.
The main claim: „The device is safe“, is on the top level. Sub-claims which are built hierarchically can characterize the claim further and have to be argued and proven as well.
Arguments are the link between claim and proof. There are three kinds of arguments:
- Deterministic: predetermined rules are applied for a true/false claim (e.g. demonstration of a safety requirement, formal proof or exhaustive test of the logic).
- Probabilistic: quantitative statistical reasoning in order to establish a numerical level (e.g. reliability testing, mean time to failure).
- Qualitative: observation of rules that have an indirect link to the desired feature (e.g. staff skills and experience, compliance with QMS standards).
Evidence can be based on product analysis, on development processes and reliability testing for a new design, field experience for an established design or product review.
Assurance Cases are illustrated as diagrams with specific symbols. Like mentioned above, every symbol is assigned to a certain level. This graphical illustration is called Goal Structuring Notation (GSN) (T. Kelly, 1998). Thereby goal is used simultaneous for claim. In its simplest form the Assurance Case consists of the three main levels:
The advantage over other procedure models is its easy traceability due to the graphical illustration. This kind of graphical demonstration can refer to the principle of the software modeling language UML (unified modeling language) or SysML (system modeling language) respectively. UML is a standardized graphic modeling language which is used for graphic construction and specification of software-parts, but also other types of systems can be represented. Notations which are language elements that are demonstrated as symbols are used.
An advanced modeling language for more general systems is SysML, which is more flexible and variable in its appearance than UML. It can be used for analysis, specification, verification and validation of many systems.
Next figure shows an example of a typical structure of an Assurance Case:
Assurance Case application for medical devices
In the field of medical technology the Assurance Case has been developed for generic infusion pumps (GIP) (Figure 3). GIPs belong to the risk class II and III, depending on their usage. Therefore they have very high security and safety requirements. In the US alone, 56.000 incident reports on infusion pumps have been reported between January 2005 and December 2009. 1% of those reports resulted in loss of life (FDA, 2010). Due to this enormous error rate the FDA has chosen the Assurance Case as a process model in order to minimize the risk and afford better safety quality.
The FDA report “510(k) Working Group- Preliminary Report and Recommendations” released in August 2010, advices the use of the Assurance Case for premarket notification (510(k)) by the FDA division CDRH (Center for Devices and Radiological Health). 510(k) is an approval regulation for risk class II products, which have to be tested by a premarket review before market launch. The CDRH expects a better traceability of the development and safety examination due to application of the Assurance Cases and therefore a faster approval time. In the case of infusion pumps belonging to class II all risks and hazards as well as safety implementation have been described and demonstrated for Assurance Cases.
For other medical devices the CDRH has to determine the conditions how to develop the Assurance Case and what is needed to guarantee a good comparability and simplified management.
The guidelines have to contain detailed product descriptions of all medical devices with requested approvals and also user descriptions. Furthermore, all modifications since the first release have to be described again. Additional the CDRH has to tutor its reviewers and managers for evaluation of Assurance Cases.
This shows some of the challenges for the introduction of Assurance Cases. The Assurance Case refers to very complex systems and the demonstration of evidence is very work-intensive. Further it is hard to generalize or reuse the case for different medical devices.
The creation of the Assurance Cases and its handling is very labor- and time intensive, but on the other hand safety and elimination of errors are the greatest challenges and should have highest priority. It has to be considered that recalls and error reports are not only cost intensive, but also cause damage of the company’s image.
Assurance Cases are an efficient process model, which in the future can speed up the process of approval and assure highest safety standards at the same time.
INVENSITY would like to support and advice you in introduction and implementation of Assurance Cases for your medical device and questions on functional safety.
Example of an Assurance Case
The claim described on the top level is: The GIP is safe for the patient (C1). A strategy that results from this assumption could be to argue all risks and hazards (S1). This strategy can be considered in different contexts, for example: risks due to user errors by programming (Ct1, Ct4) or wrong application to patients (Ct2, Ct3). Due to the different sub-claims and contexts, more and more specific sub-claims (C18-21) can be considered.
On the second level the GIP is categorized in different hazards: operational hazard, environment hazards, electrical hazards, hardware hazards, software hazards, mechanical hazards, biological and chemicals hazards as well as use hazards. Those categories divide in more detailed sub-claims. All sub-claims have to be proven (E1-14). The evidence can be performed in different ways: user testing (E14), description of behavior if critical situation occurs (E13) or it can be addressed to documentation (E3).