🎤 Carolyn Troiano | 📅 Recording Available | 🕒 90 Minutes
In this webinar, we will explore the best practices and strategic approach for evaluating computer systems used in the conduct FDA-regulated activities and determining the level of potential risk, should they fail, on data integrity, process and product quality, and consumer/patient safety. We will walk through the System Development Life Cycle (SDLC) approach to validation, based on risk assessment, and will also discuss 21 CFR Part 11 and data integrity, and the importance of managing electronic records and signatures appropriately.
We will also walk through the entire set of essential policies and procedures, as well as other supporting documentation and activities that must be developed and followed to ensure compliance. We will provide an overview of practices to prepare for an FDA inspection, and will also touch on the importance of auditing vendors of computer system hardware, software, tools and utilities, and services.
Finally, we will provide an overview of industry best practices, with a focus on data integrity and risk assessment, that can be leveraged to assist in all your GxP work.
Subject Background:
Computer system validation has been regulated by FDA for more than 30 years, as it relates to systems used in the manufacturing, testing and distribution of a product in the pharmaceutical, biotechnology, medical device or other FDA-regulated industries. The FDA requirements ensure thorough planning, implementation, integration, testing and management of computer systems used to collect, analyze and/or report data.
Electronic records and electronic signatures (ER/ES) came into play through guidelines established by FDA in 1997, and disseminated through 21 CFR Part 11. This code describes the basic requirements for validating and documenting ER/ES capability in systems used in an FDA-regulated environment.
In the early 2000s, FDA recognized they could not inspect every computer system at every regulated company and placed the onus on industry to begin assessing all regulated computer systems based on risk. The level of potential risk, should the system fail to operate properly, needed to be the basis for each company’s approach to developing a validation approach and rationale as part of the planning process. System size, complexity, business criticality, GAMP 5 category and risk rating are the five key components for determining the scope and robustness of testing required to ensure data integrity and product safety.
FDA’s recent focus on data integrity during computer system validation inspections and audits has brought this issue to the forefront of importance for compliance of systems used in regulated industries. These include all systems that “touch” product, meaning they are used to create, collect, analyze, manage, transfer and report data regulated by FDA. All structured data, including databases, and unstructured data, including documents, spreadsheets, presentations, images, audio and video files, amongst others, must be managed and maintained with integrity throughout their entire life cycle.
In particular, industry citations have increased as they relate to areas of Part 11 and data integrity. At the heart of these, is the ability to ensure that no original record is obscured, or is destroyed before the retention period has ended. The best way to preserve database records, those that are uniformly structured, is to place an audit trail on the file. The audit trail will create a new record every time a record is updated, including the old value, new value, date, time, person who authentically performed the modification to the record, and the reason for the change.
Companies are not aligning well with the Part 11 and data integrity requirements, and while many use audit trails, these are not always managed appropriately. In some cases, FDA has found that the audit trail was deactivated for a period of time, but this was not documented, or it was modified or deleted. Without this protection, it’s virtually impossible to follow the life cycle for any record from creation to disposition at the end of the retention period.
In some cases, audit trails exist, but do not require the user to enter a reason for a change to a record. This is a challenge when trying to reconstruct what happened, and not having the reason brings into question the validity of the record.
Some legacy stand-alone systems that include software loaded onto a local device, instrument, or piece of equipment do not have audit trail capability. This is not a valid reason for ignoring Part 11 and data integrity requirements. If no technical control is available, such as an audit trail, then a procedural control must be in place. In the case of a stand-alone system, the user would have to maintain a log of all changes made, and this could be done using a bound laboratory notebook or log book, or using Excel or some other means of tracking this information.
Not only do these companies risk being out of compliance, but they are not able to perform analysis and trending on the records to identify the reason behind changes. If it’s a consistent reason, it may be due to a training deficiency or have some other cause that should receive action.
Areas Covered in the Session: