In September of this year, the FDA plans to release guidance on the transition from the traditional concepts of Computer System Validation (CSV) to Computer System Assurance (CSA) for Manufacturing, Operations and Quality System Software. The new guidance will provide clarity on the procedure used to determine what is high-risk (and therefore what should be tested more stringently) to minimize misinterpretation.  The intent is to improve quality, reduce validation cost and time, decrease testing issues, and deliver value faster. This approach includes less emphasis on compliance, allowing manufacturers to focus on enhancing quality and patient safety, as well as implement automated systems and new technologies faster and more abundantly. A risk-based approach is nothing new.  These principles and approaches are applicable now to all regulated organizations.  So what exactly does the shift to CSA mean?

Computer System Assurance Critical Thinking 

This concept evolution centers on a risked based approach using critical thinking.  The risk determination will still be based on the software’s impact to patient safety, impact to product quality, and impact to quality system integrity.  But inspectors will focus their review on higher risk activities and the critical thinking behind the compliance methodology that was chosen. Then they will focus on assurance needs, testing activities and documentation.  They want to ensure that most of a manufacturer’s time is spent applying the right level of testing to higher-risk activities, and significantly less time spent documenting.  Common elements to consider in critical thinking:

• Is the method you are planning to use relevant to the intended use of the system?
• Is the information you are considering accurate and fact-based, versus beliefs or tribal knowledge?
• How clearly did you state your messaging?

Indirect vs. Direct Computer System Assurance

Software that doesn’t impact the product or patient safety (e.g. Document Control, Complaint Management, Lifecycle Management tools) are considered Indirect Systems.  The same rigor is not needed for the assurance of these types of systems and they require less documentation.  Systems that are used “Out of the Box” may only require a Supplier Qualification and configured software may only require ad-hoc testing.

Direct Systems (e.g. Adverse Event Reporting, Laboratory Information Management, Electronic Lab Notebooks) will require adequate testing based on risk, and expected deliverables are similar to current expectations, i.e. the riskier the application, the more testing and documentation that is required.  However, a hybrid approach could be acceptable.  Aim for better, more relevant testing. Consider what is the value of the documentation.

CSA is really just a shift in mindset from the traditional CSV approach.  Too much emphasis has been placed on validation, so this guidance is meant to swing the pendulum to assurance, or confidence that the system is delivering as required and intended. Regulatory punishment should not be the driving force behind computer system implementations, instead, it should be fear of putting a poor-quality product on the market.

So, what should I do now?

Perform an assessment of your current CSV process, and the gaps that will need to be addressed to make a transition to CSA. Define your company’s CSA Strategy and develop a transition plan to get you there.  And once your methodology is developed, consider a pilot program or project to work out the kinks.  This will likely be a culture shift for your organization.  Don’t take for granted the change management impacts associated with this transformation.  And don’t forget to train your teams on how to apply critical thinking led, risk-based approach.

Selecting a consulting partner who can support you through this transition is a great way to get started.  To learn more about our validation services, please contact us today.