Computer Systems Validation is a requirement all Life Sciences teams are familiar with (although some changes are coming to this, which we will cover in an upcoming series). It’s a practice that must be executed and well documented in addition to standard application and systems best practices. For most teams, these FDA regulations and the processes utilized to meet them have acted as a roadblock for modernizing their SDLC methodologies, but it’s also made it difficult to fully embrace Agile or DevOps oriented solutions.
It’s understandable as compliance comes first and foremost and the consequences of deviating from compliance can be severe. However, this has bred somewhat of a very fear driven risk aversion, leading to bloated processes in order to adhere to FDA requirements.
The regulations basically require that any applications or systems that have the potential to impact patient safety must be validated prior to entry into production, as well as remain in a validated state through its lifecycle. These validation requirements are meant to ensure that a system and process for utilization of said system are operating securely, reliably, accurately and consistently for their intended use. When you look at it, these goals are really just best practices and outcomes that any software team should be looking to achieve.
The difference here is that the FDA imposes regulations that assure that procedures are being adhered to. This requires that a number of steps be taken on the part of the regulated team:
- Creation of a validation plan
- Definition of processes and SOP’s relating to a specific application or system
- Training against defined SOP’s
- Defined system specifications
- Detailed testing plan
Again, all of this is just good practices, but where it gets more complicated for FDA regulated organizations is the where level of documentation that needs to be generated, maintained and readily accessible comes into the picture.
At each of these steps, multiple levels of review and approval (or rejection, if warranted) need to be undertaken. To verify those steps have been followed, signatures need to be captured before the next phase in the process can get underway. In the early days, this meant large documents filled with data were being passed around from person to person getting wet signatures applied. Those documents would then be stored in binders at some location or another waiting for the inevitable day when the FDA would initiate and audit. The proper documentation must then be supplied to verify that all validation plans, SOPs, training requirements, specifications and testing were properly and adequately adhered to.
As we’ve previously discussed, these requirements gave way to processes that really limited the tools that Life Sciences teams utilize, or at least limited the way in which they were utilized. The advent of things like 21 CFR Part 11, which allow for the use of electronic signatures on electronic records, helped move things in the right direction, but much like the tools that teams use in a regulated environment, they are not maximizing the potential benefits it allows.
The current state of things for most teams is 21 CFR Part 11 has been grafted on to processes that are not ideal for utilizing solutions like Jira, and electronic signatures still need to be embraced in conjunction with better process implementation. Failing to do so will continue to result in teams falling short of achieving Agile, not maximizing the investments they have made in Agile focused tools and inhibiting their ability to achieve Agile workflows.
Check out a webinar we did on enabling Jira for Agile GxP here.
Jason Secola is the Support Sales Manager at Tx3 Services and has been with the company since 2016. Jason began working with the larger portion of the existing Tx3 team dating back to 2007 when he got his first start in the world of application testing and later began a focus on testing in a regulated environment.
He currently resides near Sacramento, CA.