Note: this is a recording of a LinkedIn audio event with Kieran McKeever. The article below highlights key insights from the discussion.
In the Life Sciences industry, the term Quality conjures up images of a complex system of procedures, work instructions and excessive documentation. If it isn’t documented, it didn’t happen, is a frequently repeated phrase in the industry! This is primarily driven by heavy emphasis on regulatory compliance, which is generally checked by a review of documentation in an audit or inspection.
When it comes to Computer System Validation (CSV)1, this compliance-focused mindset has resulted in a heavy burden for software testing and documentation even in applications that do not directly impact product quality or patient safety. As a result, the industry has been slow to adopt the latest technology in computer and automated data processing systems that can help improve quality and safety of medicinal products and medical devices. Further, changes to currently validated systems becomes a herculean task due to perceived documentation requirements for regulatory compliance.
The new buzzword in the regulatory world is Computer System Assurance (CSA), which emphasizes a risk-based approach to software testing to establish confidence that the software is fit for its intended use. The focus is on Quality2, and not on testing for the sake of testing and documentation.
It is interesting to note that the FDA seems to have realized a need to emphasize a risk-based approach in a newly issued draft guidance3 related to software used as part of production or the quality system. It appears that the Agency’s original intent of encouraging a risk-based approach in the 2002 CSV guidance (see note 1 below) did not lead to the desired industry practice.
FDA realizes that technology is evolving fast. In the age of artificial intelligence and machine learning (AI/ML), the regulatory framework and its enforcement must facilitate a more iterative and agile approach for validation of computer software, especially when used as part of production or the quality system.
Keeping Quality simple means we have to apply critical thinking to focus on what matters the most to our stakeholders.
Don’t ever forget, after all we do in the business, there is a person like you and me who needs that medicine or medical device we make.
Risk-based thinking is another side of the same coin. This involves applying a risk-based approach to software testing and appropriately adjusting the extent and formality of testing. When a software failure has the potential to directly impact product quality or patient safety, more rigorous scripted testing should be performed. In other situations, less rigorous unscripted testing may be acceptable. This risk-based approach should be clearly described in procedures and work instructions.
We need to have procedures and work instructions written for the benefit of people who do the work, not for the benefit of auditors.
Risk-based approach sounds simple, but it requires competence in risk management including good planning. It is time for us to take a step back and get out of a compliance-focused mindset.
Listen to the recording of our conversation above to learn more.
About Kieran McKeever
Kieran McKeever is the Director and Principal at Aoire Limited, a Quality Management consultancy, where he guides leaders to keep Quality simple by applying critical thinking. Kieran has over 30 years of experience in the Life Sciences industry providing guidance and support on quality risk management, computer system validation, data integrity and process improvement.
About Let’s Talk Risk with Dr. Naveen Agarwal
Let’s Talk Risk with Dr. Naveen Agarwal is a weekly live audio event on LinkedIn, where we talk about risk management related topics in a casual, informal way. Join us at 11:00 am EST every Friday on LinkedIn.
Disclaimer
Information and insights presented in this article are for educational purposes only. Views expressed by all speakers are their own and do not reflect those of their respective organizations.
In the context of a medical device, the FDA considers software validation to be “confirmation by examination and provision of objective evidence that software specifications conform to user-needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled” (FDA Guidance: General Principles of Software Validation, issued January 11, 2002)
FDA’s Software Validation Guidance (see above) recommends that “software quality assurance” focus on preventing the introduction of defects into the software development process, and it encourages use of a risk-based approach for establishing confidence that software is fit for its intended use.
FDA draft guidance: Computer Software Assurance for Production and Quality System Software
Share this post