Validation of IT systems is a requirement by both the FDA 21 CFR QSR regulations and the ISO 13485 standard. The 2016 version of this ISO standard has been aligned with QSR and extends the validation scope with IT systems used in the Quality Management System, such as training, CAPA, and complaint handling systems. This addition could significantly increase the validation effort for your organization to keep your IT systems compliant with these validation requirements. A good reason to explore 5 practical ways to streamline your IT system validation and save effort and resources. This is part 1 of a series of blog posts and reveals the first 2 practical ways!
Define clear intended use and IT system scope
Per definition, an IT system can only be validated for its defined intended use. Here is where it all starts! Without a very clear understanding of what the IT system is supposed to do in supporting or controlling your regulated processes, validation is a wasted effort. An example: sometimes it is questioned if a spreadsheet system requires validation. The answer is: only its application and depending on its intended use. If a spreadsheet is managing and storing CAPA or complaint records as a source of truth, most likely this application is subject to validation. If the spreadsheet is being used for project management in a development project, most likely not. If the spreadsheet reports on QMS KPI’s, it depends what is being done with this information, for instance, what decisions are being taken based on this spreadsheet impacting product quality, safety or compliance. Carefully defining the intended use of the IT system may exclude several IT systems from your to-do list for validation. The magic question is: could the IT system impact product quality or safety or does it manage data considered as QMS quality records?
In some cases, IT systems support both regulated and non-regulated processes. This is often the case with ERP-like systems. Obviously, the non-regulatory use can be scoped out for validation and this often reduces the technical scope of your IT system to validate, for example by excluding certain modules or components. A prerequisite is that the IT system can be sufficiently decomposed so that these modules or component can be clearly separated. The message is: clearly define the IT system with its functional boundaries in scope for validation.
Defining clearly the intended use and IT system scope and boundaries helps you to focus your validation effort on the IT (sub-) systems that really require validation.
Apply a risk-based and critical thinking approach
A risk-based and critical thinking approach to validation is propagated by both ISO - as documented in ISO/TR 80002-2:2017, and FDA – as a recently started initiative to streamline non-product Computerized System Validation. As part of the risk-based approach, the focus on validation is strongly put on the critical functions of the IT system that impose risks impacting the safety or quality of the products. As part of the critical thinking approach, the IT system is considered as a total environment including software, technical and administrative controls, users etc. supporting a regulated process. This implies, for instance, that the risks associated with the software might be mitigated by controls outside the software part, but as part of the supported regulated process. For example, established manual procedural controls applied after the use of the software reducing the overall risk level and hence the level of validation effort. Other factors to be considered in a critical thinking approach are complexity, type, and pedigree of the IT system. These factors influence the confidence level of the IT system and hence drive the validation effort to be applied. For example, an established commercial-of-the-shelf (COTS) IT system in use for many years on the medical device market may most likely need a lower level of scrutiny in validation than a new, innovative, in-house developed IT system.
Another example of this approach is that only critical functions typically require full “scripted” testing with pre-defined and approved testing protocols. For less critical functions “ad-hoc” or “unscripted” testing might be sufficient in most cases, reducing significantly the test effort involved!
Applying a risk-based and critical thinking approach helps you to focus your validation effort on the functions that impose risks on the products and taking into consideration various factors as part of the total IT system. This prevents a “one-size-fits-all” approach to IT system validation but scales the validation effort proportionate to the risks associated with the application of the IT system in the regulated process.
In part 2 of these blog series, two other practical ways will be disclosed: embed validation in your software development lifecycle and improve organizational capability maturity.
Henk-Willem