Regulatory Open Forum

 View Only
  • 1.  ISO 14971:2019 vs "Safety Assurance Case"

    This message was posted by a user wishing to remain anonymous
    Posted 17-Nov-2021 17:06
    This message was posted by a user wishing to remain anonymous

    In the past, I've seen references to documenting a "Safety Assurance Case" (e.g. Risk Traceability Summary that Edwin Bills who posts here as written). Does the 2019 version of ISO 14971 get close to that? We're working on a technology where we might want to provide solid risk documentation. We had thought of asking regulators if we need a safety assurance case or can just use 14971. But then I read that it might be more convincing to write it up as a Safety Assurance Case, though it will be more work. So I wanted to ask how different is it from the 2019 version of 14971.

  • 2.  RE: ISO 14971:2019 vs "Safety Assurance Case"

    Posted 17-Nov-2021 17:37

    Creating and maintaining a Safety Assurance Case is an FDA requirement for certain infusion pumps (by Product Code). I believe this is the only product type for which FDA requires a Safety Assurance Case.

    This arose because there had been some problems with infusion pumps and some people believed that the risk management system at the time (ISO 14971:2007) was not robust enough to help prevent the observed problems. There was a time when FDA considered extending the Safety Assurance Case to all devices or, perhaps, to only other high risk devices. I don't believe there are any current plans in this area.

    My recommendation is to use ISO 14971:2019 and do not create a Safety Assurance Case unless the pre-market submission requires it. ISO 14971:2019 is robust enough to help identify the identify risks, identify risk reductions, and implement them in the design. However, this implies following the standard, which doesn't always happen. I don't believe a Safety Assurance Case will provide a safer device than a correctly conducted ISO 14971:2019 approach.

    While Ed Bills can speak for himself, when he raises traceability, I believe he refers to ISO 14971:2019, 4.5 Risk management file which says, "For the particular medical device being considered, the manufacturer shall establish and maintain a risk management file. In addition to the requirements of other clauses of this document, the risk management file shall provide traceability for each identified hazard to:
    - the risk analysis;
    - the risk evaluation;
    - the implementation and verification of the risk control measures; and
    - the results of the evaluation of the residual risks".

    This is not a requirement for a Safety Assurance Case, but rather a requirement for records to follow each identified hazard through the major elements of the standard.

    Dan O'Leary CQA, CQE
    Swanzey NH
    United States

  • 3.  RE: ISO 14971:2019 vs "Safety Assurance Case"

    Posted 18-Nov-2021 03:38
    Hello Anon,

    I agree with Dan the Safety Assurance Case from US FDA has come out of the infusion pump dilemmas (the published Guidance document) and issues which plague a professional device which has now evolved into home use.  Indeed FDA has "left the door open" to expect this type of approach for other high risk devices as well especially for devices which are needed for clinical applications, but have continued issues or concerns for safety.  Safety assurance case approach are often used in software applications or software in medical devices, reference ISO/IEC 15026.  As an international standard this is used in other industries as well for generating supporting evidence for integrity of software systems providing safe products.  There is nothing wrong with using Safety Assurance Case though it is not risk management - ISO 14971 is a framework for risk management processes (bottom up, top down, residual risk, post market), whereas Safety Assurance Case is a top-down approach with assumptions all hazards are known and controlled - thus needing to do ISO 14971 first.  The best standard to read through if you want to perform Safety Assurance Case is AAMI TIR 38.  From my own personal experience, I see companies doing Safety Assurance Case more from a liability perspective than doing a prospective claims/risk/intended use activity; these are done to support the device is safe when there are legal implications.  And developing Safety Assurance Cases are definitely more work as there are linkages to many other aspects such as claims, benefits, life cycle approach, and much more integrated design change methodology (though could argue this is all in ISO 14971 too).

    Richard Vincins RAC
    Vice President Global Regulatory Affairs

  • 4.  RE: ISO 14971:2019 vs "Safety Assurance Case"

    Posted 18-Nov-2021 05:59

    Both Dan and Richard are correct, Safety Assurance Case is expected for infusion pumps as described in the Infusion Pumps Total Product Lifecycle guidance (issued Dec 2, 2014); additionally, AAMI TIR 38 is a consensus recognized standard by CDRH and applies to the device product codes listed on its recognition page. I'll also note that a Safety Assurance Case is generally expected for combination products that are pre-filled infusion systems, such as on-body delivery systems.

    Again, solid points have been made regarding more typical risk management approaches (i.e. those described in ISO 24971 guidance accompanying 14971 vs. Safety Assurance Case (SAC), although I'll note that SAC is theoretically more of a different way of presenting the data than a different approach to risk management altogether. There are also specialized firms with dedicated software one can utilize for developing and maintaining SACs since it is a more difficult approach to document than with off-the-shelf type tools (i.e. spreadsheets), particularly for complex systems/devices.

    Jonathan Amaya-Hodges
    Sr. Principal Consultant
    Suttons Creek, Inc.
    United States

  • 5.  RE: ISO 14971:2019 vs "Safety Assurance Case"

    Posted 18-Nov-2021 08:34
    Dan is correct in his post.  A Safety Assurance Case is only required by FDA for infusion pump submissions.  It has been some time since this requirement was established, during a period of problems across the category, not just one manufacturer.  I know of no other regulatory authority that requires the use of Safety Assurance Case for medical devices.

    While Safety Assurance Case is a good risk tool, it is complex and has not gained favor in the medical device industry.  At the time it was established, Fubin Wu, wrote extensively on the topic and had a software product that incorporated the use of this tool.  It was never listed in the tools discussed in ISO TR 24971 because there was not the demand for reference describing it.

    ISO 14971:2019 is still based on the same elements that were in the 2000 edition, the process has not changed.  What has improved is the information on how to implement the process, such as that in ISO TR 24971:2020.  With over 20 years experience in the standard, the industry has started to use it as intended.  There are still many cases where companies implement the standard, not as a safety standard, but only to "check the box".  The standard and the process described is intended to improve safety for patients and users and the public as well, through its requirements on risks to property and environment.  Cybersecurity and data security is now required to be covered, for instance.

    I start my training classes with recommending that risk management is performed as though the members of the risk management team will be the first patients to receive the device.  It is the attitude that the risk management team has that will drive the proper implementation of the standard.  Of course management has a big influence on attitude (witness the Boeing 737MAX issue a couple of years ago).  Putting extreme cost and time pressures on the development team can have a big impact on proper risk management which will take time and effort.

    Edwin Bills MEd, CQA, RAC, BSc, CQE, ASQ
    Principal Consultant
    Overland Park KS
    United States
    elb@edwinbillsconsultant.comPrincipal Consultant