How to accelerate adoption of FDA’s Computer Software Assurance

This blog is the first of a three-part series focused on FDA’s Computer Software Assurance (CSA). It explains how to accelerate CSA adoption.

What exactly is CSA?

There are two primary things CSA delivers: First, CSA flips traditional validation from upside-down to a new way of thinking that’s right-side up. Second, CSA charts a path through a critical thinking process to ensure appropriate, risk-based, least burdensome validation.

Flipping the paradigm right-side up

With traditional CSV, too much focus is on documentation. The amount of time and effort put into documentation consumes significant resources and sacrifices critical thinking. CSA inverted this upside-down way of thinking whereby focus is placed first on critical thinking, then assurance needs, then finally testing and documentation.

Figure 1 – The old CSV way

Figure 2 – The new CSA way

Charting a CSA path through a critical thinking process

Figure 3 – How to CSA(SOURCE: Cisco Vincenty, FDA Case for Quality Program Manager (FDA))

Identify Intended Use

The new CSA approach starts with identifying intended use. Here it’s determined if a system, feature, operation, or function directly impacts device safety, device quality, or quality system integrity.


ACCELERATE
ValGenesis’ VLMS accelerates
Critical Thinking
using System Assessment functionality to
identify the intended use


Determine Risk-based approach

The next step in the CSA process is to determine a risk-based approach, focusing in on safety and quality, specifically high-risk areas that may require the most rigorous assurance effort and objective evidence, which is complete, extensive validation and ensure the high-risk features, functions, or operations reliably perform as intended.


ValGenesis’ VLMS accelerates
Risk Assessments
with risk assessment functionality at
System level and Requirement level


Methods and Activities

Where CSA value shines bright is with leveraging a vendor documentation, ad-hoc testing, and automated testing; this is a risk-based, least burdensome approach. The biggest payoff is with medium and low risk features where little or no rigorous effort is required. Validation cycles are further accelerated by validation leveraging automation, iterative methodologies (e.g., Agile), along with continuous monitoring and verification. In other words, digitize validation and go paperless.


ValGenesis’ VLMS accelerates
Methods and Activities
 using patented
Requirements Traceability Matrix (RTM),
Frameworks, and
Test Functions


Appropriate Record

Complete validation with a high degree of rigor is necessary for high-risk. For medium risk, less rigor can be applied. For low risk, little or no validation may be required. If it is in fact low, there should be no impact in the event of failure. If there is a negative consequence for a low-risk failure, then the risk assessment was inaccurate or the process is flawed.


VLMS accelerates
Appropriate Record
with
Electronic Execution and Deviation Management
to create and maintain validated state and records


Change Control is necessary to ensure changes to features, functions, or operations follow the CSA process. This maintains the system in its appropriate state (e.g., “Validated”).


VLMS accelerates
Appropriate Record Change Control
through
Change Management and
 Periodic Schedule
to maintain appropriate validated state
on a continuous basis


Change the culture and process by igniting teams

Culture must change from a compliance-centric mindset to quality focused culture. This will be discussed in more detail in the next blog.

Next up…

Changing compliance-centric mindsets
(blog 2 of 3)

Stay tuned!


Resources

https://www.greenlight.guru/blog/fda-computer-system-software-validation

About the Author

Steve Thompson

Director Industry Solutions of ValGenesis

Steve has worked in the life science industry for over 20 years and has experience working for Fortune 50 and start-up pharma, biotech, and medical device companies. As Director of Industry Solutions for ValGenesis, Inc., he helps the life science customers realize the benefits of applied advanced technologies. He is knowledgeable of internal and domestic GxP regulations, was certified as a Parenteral Drug Association auditor and has audited hundreds of companies globally. He’s on the Editorial Advisory Board for the Institute of Validation Technology (IVT), faculty member for Knowledge Exchange Network (KENX), a published author and frequent speaker at conferences

Feedback

3 thoughts on “FDAs Computer Software Assurance (CSA) – Part 1 of 3

  1. Hi Steve,

    Well articulated info, but scope of the CSA is not clear from the write up. It is applicable only for “ manufacturers, including combination products manufacturers, who have established 21CFR 820 quality systems” Which is less than 10% of the bio pharmaceuticals industry. The reason for update is current FDA document on software validation is very old and not covering requirements of part-11 and other predicate rules requirements. Thanks

    • Great comment! You are correct. CSA is currently coming from FDA’s Center for Devices and Radiological Health (CDRH).
      However, you can leverage CSA even though it’s guidance and, in fact, the guidance has not officially been released.
      I did this before when I was Director Computer Quality Assurance. Here’s my rationale:

      CSA is based upon a Least Burdensome (1997), Risk-Based Approach (2002), which is what FDA has been encouraging for a long time.
      “FDA continues to make progress under the Pharmaceutical Quality for the 21st Century – A Risked Based Approach formally known as Pharmaceutical CGMP Initiative for the 21st Century – a Risk Based Approach. This Initiative, introduced by FDA in 2002, was intended to modernize FDA’s regulation of pharmaceutical quality for veterinary and human drugs and select human biological products such as vaccines. ” — Pharmaceutical Quality for the 21st Century A Risk-Based Approach Progress Report

      21 CFR 820, Quality System Regulation / Medical Device Good Manufacturing Practices — As is evident in the title, this regulation is for medical device. However, many companies (non-Medical Device) still incorporate 820 practices / principles in their quality system. For example, I worked for a virtual clinical trial company (primarily GCP and non-medical device, also not a Software as a Medical Device). At the time we included 820 in our QMS and referred to it in policy and procedure. We applied 820 operating in the spirit of the law. This last point “sprit of the law” is important. Just like applying 820 in the spirit of the law, you can also apply CSA in spirit. After all, it’s coming from the FDA.
      Applying a Risk Based Approach (RBA) is important. This should be incorporated and articulated in your QMS policy / SOP(s).
      Once made effective (approved), the policy / SOP(s) must be followed, as you know. If you’re audited or inspected, then a review of your RBA may be conducted.
      Then an assessment of your RBA practice, as proven in documented evidence, will substantiate the fact that you: a) have a RBA and follow a scientific method; and, b) you have trained individuals and they prove adherence in documentation.
      Now, there’s no guarantee that an auditor/inspector will agree with your practice and they my make observations or findings during the assessment. But this is difficult to enforce especially when you have a good practice.
      Your company can decide to push back or update your procedure(s) to make improvements based upon auditor/inspector feedback.
      I can only speak from my own experience as an auditor for a major biotech company, and having audited hundreds of companies world-wide. If I encountered the scenario above the I most likely would not issue a finding. But that’s me and you’ll have to weigh the pros and cons from your own perspective.
      CSA, using a RBA, will result in applying appropriate rigor for high and medium (optional) risk systems. If a system is truly low risk then, even if an issue happens, there will be no impact. If there is impact then the risk process is flawed or the system wasn’t appropriately assessed. Corrective action can be taken to remedy: a) reassess and possibly revalidate system; or, b) update procedure(s) to resolve the issue with the process.
      CSA encourages ad-hoc and even automated testing. This should be applied appropriately. For example:
      A low risk system may include only these, or maybe even no formal validation at all. (possibly verification or qualification)
      A medium risk may include a combination, and maybe additional formalized testing for higher risk requirements (combination of verification, qualification, and some validation)
      A high risk system should include the most rigor and a complete validation effort (i.e., VP, URS, FRS, DS, IQ, OQ, PQ, VSR, and RTM), specifically capital “V” Validation.
      You have my contact information below. If you have additional comments, please don’t hesitate to reply, or propose a time to discuss the above.

      Thanks again for your comment.

      Much appreciated,

      Steve

      • I have worked with CSA approach for many years. Root cause if documentation overload, according to me, is not the triangle rotation. It is the choice of communication policy in the Validation Project. If you choose email, Microsoft Office for risk analysis, Traceability, you end up in version confusion, communication risk, traceability stress, pain, and the project is delayed, immensely. So, to avoid that risk, avoid using “Office” for these kinds of activities, since it will kill your project, and that will feel like “Documentation Pain”, but it is “Communication Pain”, and “Traceability Stress”, and difficulties in gaining consensus with suppliers, between QA, Validation, Process, etc. Here a tool like ValGenesis, with relief the burden of this, in the Validation Process. Other tools, in conjunction with ValGenesis, and that will be a dream project. I will get in contact with ValGenesis today, to partner up.

Leave a Comment