Steps in CSA

 

Data Integrity App

Steps in CSA

 

The CSA process can be described in below broad steps:


    1. Identify the software’s intended use. The CSA approach starts with identifying intended use of the software or software feature.

If the system directly impacts patient safety, device quality, or quality system integrity, then it would be considered a direct system (e.g., software within the device, electronic device history, adverse event reporting, etc.). If it does not, then it would be considered an indirect system (e.g., lifecycle management software).

 

    1. Prioritize risk and determine your approach. This is where you use critical thinking to develop a validation methodology appropriate to the risk of the system.

 

The FDA knows that you will have the best insights into how risk is introduced into your products and where it matters, and they expect you to have an element of understanding and control about your product and processes.

 

You’ll want to be able to tell your story to an auditor by explaining in detail where risk is being introduced. 


For validation purposes, it will be important to delineate where the system in question could introduce risk, versus what is a process risk, and use critical thinking to calculate the risk impact of the system or system feature on patient safety and product quality.

 

Note that a “low risk” designation for a system is only accurate if the system’s failure has no impact on patient safety and product quality. If failure has an impact, then the risk assessment is inaccurate.

 

    1. Leverage vendor documentation where possible. Audit your software vendors. If they have quality documentation and validation in place, it can be used for medium and low risk features.

You don’t need to perform rigorous validation procedures and extensive documentation for out-of-the-box software that’s already been validated by the software vendor.

 

    1. Conduct testing activities based on determined risk level. For high-risk (direct) software and features, extensive validation activities (scripted testing) and documentation will still be necessary.

At a minimum, validation activities in this instance will include a test objective for the test script, a step-by-step test procedure, expected results, a pass/fail designation, along with thorough documentation.

 

For medium risk features, vendor documentation or unscripted testing (a test objective and a pass/fail, but no step-by-step test procedure) can often suffice.

 

For indirect systems that do not affect patient safety or product quality, vendor documentation, or in some instances little to no validation at all can be sufficient.

 

 

 

5.    focusing on quality, not compliance.

 

“Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives.” William A. Foster.

 

CSA was born out of the need to reclaim the quality-centric mindset lost in the industry’s typical CSV approach of gathering documentary evidence for auditors.

But focusing too much on regulatory requirements and compliance can cause (and has caused) life sciences professionals to lose sight of quality.

One of the main findings of the FDA's Case for Quality initiative was that the industry's heightened focus on meeting regulatory requirements versus adopting best quality practices could actually jeopardize patient safety.

The document-centric, compliance-based approach impedes the use of risk-based critical thinking in the validation process.

It also discourages investment in digital technologies that dramatically streamline validation efforts, leading to reduced project costs and faster time to market.

Regulators and leading CSV subject matter experts (SMEs) recognize this and envision CSA will bridge the gap between technology and compliance.

 


 “Trust but Verify “ Ronald Reagan

 

Across the internet, there are millions of resources are available which provide information about Everything.

 

If you found all content under one roof then it will save your time, effort & you will more concentrated on your important activity.

Data Integrity App


 

Our Data integrity app will helpful for understanding what Data integrity & CSV really means & How 21 CFR Part 11, EU Annex 11 & other regulatory guidelines affects in pharmaceutical Industry.

 

Data Integrity App Include 

- Basic Data Integrity Concepts

- ERES & Its Requirement

- CSV & Its best practices 

- Mock Inspection and General Q&A

- Checklist for inspection

- Inspection Readiness

- Useful SOP’s

- Stay Regulatory Compliant.

 

“Stay One Step Ahead in Pharma IT Compliance” 


Data Integrity App Link:


https://play.google.com/store/apps/details?id=com.innovativeapps.dataintegrity

 

Try our "Data Integrity" app which helps you to better understand current regulatory agencies thinking on Data Integrity & CSV.


 

 

 

 

 

 

 

 

 

Comments

Post a Comment

Popular posts from this blog

Need of Computer System Assurance

Image
Data Integrity App   Why is the FDA making this change? Over the last decade, innovation and technology has emerged with tremendous speed and brought the industrial revolution (Industry 4.0) through smart manufacturing and automations. The Pharmaceutical industry has adopted most of the technological innovations such as Artificial Intelligence and Machine learning, Big Data & Analytics, cloud computing, Robotic Process Automation, 3D Printing, Virtual Reality and Augmented Reality, IoT (Internet of Things) and Tele radiology, etc. which is now known as Pharma 4.0. The traditional computerized system validation process was conceptualized prior to this technology evolution and being updated to some extent but is not able to cope up with industry expectations. The lack of expertise, understanding of the technology and over thinking makes the traditional computerized system validation process as prolonged activity. Too much work is done for fear of regulatory punishment i...
Read more

Industry Common CSV Pain Points

Image
Data Integrity App Industry Common CSV Pain Points USFDA and Industry working group of Computer System Assurance (CSA) identified the common pain points of the industry in implementation of new technologies with traditional CSV methodology I Deterrent to pursuing automation:  The volume of documentation and complex process of computerized system validation deter the rate of investment (ROI) on implementation of new technologies and automation. II. Gathering evidence for auditors:  The lack of knowledge and understanding on the regulatory expectations on CSV forced the industry to collect the evidence for each function in the computer system beyond the intended scope to please the auditors. This process of gathering the evidence doubles the CSV process implementation time. III. Duplication of vendor efforts at client sites:   The failure in exploring the product and supplier maturity and inexperience in communication with vendor results in customer to repeat the ac...
Read more

Current approach to Computer System Validation (CSV)

Image
  Data Integrity App The focus of current CSV processes is producing accurate and approved documentation to present information to auditors. Auditors, such as the FDA, require evidence and records, therefore the CSV methodology inspires a compliance-mindset rather than an innovative one. As such, existing CSV methodology results in manufacturers spending around 80% of their time producing documentation and only 20% of their time doing actual testing of the software. CSV has morphed into an activity that is being done primarily to secure evidence for auditors, rather than to assure the quality of systems being validated. The current CSV approach is seen as: Deterrent to pursuing automation time, cost, use of automated testing tools, documentation generation etc Regulatory burden (e.g., Data integrity) as an excuse for resisting progress; meanwhile, other regulated and nonregulated industries have moved forward and adopted frameworks for modern testing. All software...
Read more