Sanji Bhal talks to Karim Kassam (Senior Director, Technical & Scientific Services)
As the number of conversations we’re having with scientists in validated environments increases year over year, we have found that a number of common misconceptions exist. Many arise because previous deployments of software accompanied the installation of new hardware, e.g., the software to run the shiny new LC/MS instrument, or have involved informatics systems that are intimately integrated across the development workflow and are the source of data and reports submitted directly to regulatory authorities, e.g., LIMS.
Over the last few months I’ve thought we must be able to bust these myths once and for all, and perhaps also provide a resource for people looking for clear answers. So, I cornered Karim to help get myth busting. Below we clear up some of the grey areas that seem to have become industry myths that we commonly find ourselves correcting.
Myth #1—the vendor supplies validated software out-of-the-box
The FDA defines validation as ‘confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses in their environment’. As a result software purchased for use in a validated environment must be validated in the user’s environment within their intended workflow and as outlined in their organization’s standard operating procedures (SOPs). The system, in total, must be validated—meaning that each part involved in the intended use (i.e., each software package or each software module from each package) must be validated along with any interactions between one software package and another. Validation typically requires installation qualification (IQ), operational qualification (OQ), and performance qualification (PQ) documentation to ensure that software specifications conform to the user’s needs. In some cases, the user may choose to audit the software vendor to confirm that they have a quality management system (QMS) and process to ensure quality.
In some cases vendors may advertise ‘validated’ or ‘pre-validated’ systems where the customer can validate the system as is (e.g. software to run an analytical instrument) as long as no configuration/customization is carried out. Even in these cases the equipment must be validated in the user’s environment according to their workflow but the process may be streamlined with readily available documentation.
Myth #2—software validation is performed by the vendor
While vendors can assist in the validation process, by providing documentation and technical assistance for IQ, OQ, and PQ, it is the responsibility of the user to validate that the system meets their requirements. Vendors may offer validation services that range from consultation for validation and compliance, supplying appropriate documentation, or being more actively involved in the validation process.
Read more about how ACD/Labs assists with validation of our software in your environment here.
Myth #3—software used in a GxP environment must be CFR21 Part 11 compliant
Software requirements for Good Laboratory Practices (GLP), Good Manufacturing Practices (GMP), and Good Clinical Practice (GCP) require the following:
- An audit trail at the point in time when a record is first saved to durable media
- The audit trail must contain the date and time stamp of the change, the description of the change, the reason for the change and the name of the person making that change.
- The audit trail must not obscure previous values—so both the old value and the new value for a given parameter must be recorded.
- Specific user accounts
- Forward compatibility of all files generated by the software
- All records, including audit trail records, must be protected from tampering.
GxP compliance of software requires validation as discussed earlier, and CFR 21 Part 11 requires compliance with the established rules (i.e., GxP).
CFR 21 Part 11 functionality for software is only necessary when data generated by the software system is submitted electronically in regulatory FDA filings. In this case, software must then also include electronic signatures in addition to GxP requirements.
We hope you found this to be a useful and clear discussion of compliance and validation of software. You can find information about how ACD/Labs supports validation and compliance here.
Please use the comments section to expand the discussion with your expertise and experience or to ask further questions.