Are you tired of discussing whether your devices are sufficiently safe with notified bodies? Then you should use safety assurance cases. Using this top-down approach, you can easily and elegantly produce documented evidence.
With an approach that complies with AAMI TIR 38, ISO/IEC 15026 and the FDA requirements, you can have the arguments on your side. Your notified body will not just be convinced of the conformity of your devices, they will also be won over by your professionalism, making authorization almost a formality.
“A safety assurance case is a structured argument supported by a body of evidence that, in turn, convincingly and completely permits the valid assumption that a device is safe and effective for a specific use in a defined use environment.”
Based on ISO 15026 and other sources
This argument requires a number of specific activities, which is why some people refer to safety assurance cases as a method.
The evidence provided in safety assurance cases consists of several components, as detailed, for example, by ISO 15026-2:
Conclusion that an reviewer (e.g., a notified body or authority) should come to.
The medical device meets the regulatory requirements.
Claim: A statement or assurance about a property of a device, system or subsystem to be demonstrated.
Claims usually relate to safety or performance.
According to ISO 15026-2, a safety assurance case has one or more top level claims. The claims are often structured hierarchically.
The medical device is safe. (Top-level claim).
The electrical hazards have been controlled. (Sub-claim).
The insulation is adequately dimensioned.
Context: Information, e.g., about the device, its use and use environment.
Assumption: Conditions that must be met, or facts that are usually accepted without further evidence being required or that are undisputed.
Intended users (e.g., with training and experience).
Leakage currents that are lower than required by IEC 60601-1 do not represent an unacceptable risk.
Evidence: Data used for the presentation of evidence or the argument.
Test results (e.g., from safety measures), observations, expert opinions, scientific principles, research results.
Argument: Reason why the evidence is suitable for substantiating the claim.
In some cases, a strategy for presenting evidence is also formulated in the safety assurance case.
Identification and control of hazards.
ISO 15026-2 also has another justification part. But this is not a justification of why a claim is correct, but a justification of why a particular claim was chosen.
The standard defines safety assurance case as follows:
“An assurance case is defined to be a quadruple of a claim c, a justification j of c, a set es of evidence and an argument g which assures c using es. “
Source ISO 15026-1, section 6.2
The regulations, in particular the general safety and performance requirements establish a lot of claims that the manufacturers have to prove.
A safety assurance case has one or more top-level claims that are what the evidence is intended to prove. Their choice requires “justification”.
Claims can be restricted by “limitations”, e.g., with regard to duration, safety or the conditions.
To demonstrate a claim, you need either exactly one argument or one or more (sub-)claims, pieces of evidence or assumptions.
Arguments must, in turn, be supported by one or more claims, pieces of evidence or assumptions.
Goal structuring notation (GSN) helps document safety assurance cases graphically. It makes it easier to provide a quick overview of the case.
The AAMI TIR 38 Medical device safety assurance case report guidance also uses this notation.
A section of a safety assurance case modeled with GSN might look like Figure 3.
Whether intentionally or not: the AAMI has made the older version of AAMI TIR 38 available for free download here.
SysML is also used as a multi-purpose modeling language for the representation of safety assurance cases.
General drawing tools, such as draw.io can be used to display all notations.
An important prerequisite for preparing a safety assurance case is having a complete intended purpose, including the intended users and the intended use environment. Because the context and some assumptions depend on it.
The article on defining intended purposes explains the aspects this document should define in order to meet the regulatory requirements.
Manufacturers have to formulate top-level claims and define a strategy for them. Some people start with one or more general claims, for example, “the medical device is safe.” Others base the top-level claims on the top-level hazards.
In the guidance document “Infusion Pumps Total Product Life Cycle”, the FDA has indirectly defined these top-level claims because the claims must be that the following problems will not arise:
Be careful: unfortunately, the FDA confuses the terms hazard, harm and cause. Burns are harm, not a hazard. It probably also means biological or chemical hazards and not contamination because an adverse reaction (harm) is not caused by contamination.
One of the tried and tested strategies is to consider that safety is guaranteed when all hazards are known and controlled.
Therefore, for the top-level claims, claims that these same hazards or hazard classes have been controlled are appropriate.
The FDA stipulates that manufacturers of infusion pumps must divide the “hazard classes” into individual hazards. Various sources must be taken into account in this risk analysis:
These lists of hazards and causes do not exist for other devices. In these cases, you can use hazard analysis methods, such as PHA, FMEA or FTA to define the hazards.
The (sub-)claims, i.e. the manufacturer's claims, are that these risks are under control or that the sources have been eliminated. Sub-claims could be:
The strategy at this level is therefore to identify and mitigate all relevant hazards.
ISO 15026-2 lists the options for proving claims. As described above, manufacturers can take two approaches:
A “library” of previously formulated arguments and checklists helps manufacturers to avoid redundant work and not to forget any arguments.
Safety assurance cases are useful and help manufacturers to structure their arguments logically and, therefore, to make it plausible to authorities and notified bodies that their devices meet the regulatory requirements.
They are also helpful for systematically evaluating the completeness and effectiveness of systematic risk mitigation measures for risks identified during development. Manufacturers should weave working with safety assurance cases into their development processes, particularly when establishing requirements and creating system architectures.
The FDA even prescribes this method for infusion pumps.
There are a lot of sources with guidance and examples available to companies who want to use safety assurance cases, including:
However, these documents are not aligned with one another. Different notations and concepts can cause confusion.
The FDA document does use any form of graphical representation, is not even consistent itself and only uses the concept of strategy implicitly. However, this guidance document provides a good checklist for manufacturers of infusion pumps – and is also mandatory for these manufacturers.
IEC 60601-1 is interesting in this context: it defines safety assurance cases for numerous hazards, without explicitly formulating them. In Annex A, the standard describes strategies and arguments.
Manufacturers should use safety cases particularly when they are a regulatory requirement or if there are no standards that are sufficiently device-specific.
The decision whether to use this method or not is also not a binary one. There is no reason why manufacturers shouldn’t create an initial “safety case” (as the German version of 15406-2 calls them) and then add others over the device's life cycle. This iterative approach of continuous improvement is highly regarded by authorities and notified bodies.
If manufacturers use safety assurance cases, they can use them as a bridge between risk management and system architecture:
The top-level claim is often one of the last sentences of the risk management report in which the manufacturer confirms that the device is safe and that its benefits outweigh the residual risks.
As the device evolves and new information is obtained from the post-market phase, manufacturers should update the safety assurance cases. This does mean additional work. But it does mean that the basis, e.g., for the post-market surveillance update report is laid, since the aim of this report is to confirm that the device is still safe and the benefits outweigh the risks.
Safety assurance cases do not mean companies no longer have to think less. On the contrary: this method requires companies to be able to think logically and following the MECE principle. Without such precise thinking, a safety assurance case will degenerate into graphics that only give the illusion of having provided evidence (for the safety of the device).
Auditors, authorities and notified bodies will spot holes in the manufacturer’s logic there faster than they will in a risk table with thousands of entries.
But this is also true for your own team: they can detect errors (including their own) quickly and then work on reasoned chains of argument. And this is the strength of the safety assurance cases.
Do you need support in creating safety assurance cases? Do you any someone to check that your arguments are complete and plausible? Then get in touch with us, for example via the contact form. The Johner Institute's team is looking forward to hearing from you!