PART 11 REVIEW:
Part 11 establishes the criteria under which electronic records and electronic signatures are considered as equivalent to paper records and handwritten signatures executed on paper. The rule applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted under any records requirements set forth in FDA regulations.
In order for organizations to comply with Part 11, requirements of authenticity, integrity, and confidentiality of the records and signatures must be met. Any computer system utilizing electronic records and signatures must be validated according to generally accepted industry standards associated with a Software Development Life Cycle (SDLC) to ensure its accuracy, reliability, consistent intended performance, and ability to discern invalid or altered records.
Several checks must be built into a Part 11 compliant system including:
- System checks that enforce the sequencing of events, where required
- Authority checks that determine who has access to the system and at what level
- Device checks that determine the validity of sources of data being entered into a system
The system must also be able to independently generate audit trails that describe who accessed the system and what operations were performed during any given period. The audit trails must be secured, computer-generated, time-stamped, not obscure previously recorded data, identify the person making the change, include original and changed data, and be available for review and copy by FDA. Audit trail documentation thus generated is required to be retained for a period at least as long as that required for the subject electronic records, either pursuant to a predicate rule or to the organization’s own records retention policy.
Part 11 also sets forth requirements for electronic signatures. Each electronic signature used within an organization must be unique to an individual and not reused or assigned to another. The identity of the individual must be verified by the organization (e.g., via birth certificate, driver’s license, passport) before assigning the individual an electronic signature. The organization must also certify in writing to FDA that they intend to use their electronic signature as the legally binding equivalent of their handwritten signatures. This certification must be submitted to FDA in paper form.
As a result of industry feedback, FDA modified its position on Part 11 in 2003. With streamlined enforcement and restricted interpretation by FDA, organizations must still comply with predicate rules regarding validation, audit trails, retention, copying, and legacy systems. The primary change in FDA guidance involves risk assessments performed in each of these areas. The new emphasis upon a riskbased approach places the onus on industry to identify the risks and to determine appropriate actions.
Organizations should have written procedures for identifying, specifying, and documenting the risk assessment techniques and risk mitigation methodologies to be used during the design and development of computer controlled systems. The intent is to detect potential design flaws (i.e., possibilities of failure that could cause harm to personnel, the subject system, or the environment) and to enable manufacturers to correct these failures before a product is commercially released.
It is beneficial to first determine which requirements have potential risks associated with them. Then the potential risk and possible cause should be identified. As an example, risk severity, likelihood, and its ability to be detected can be quantified. Risk severity could be rated from negligible to high with associated sequential numbers and criteria for each. Risk likelihood could be rated from improbable to frequent and so forth. The results from these types of ratings can be used to calculate a risk index that would then be the basis of a risk mitigation plan.
MDT SUPPORT OF REGULATED INDUSTRIES
Programmable Logic Controllers (PLCs) are the backbone of automated manufacturing in the pharmaceutical, biotechnology, and medical device industry. With AutoSave, MDT has a substantial history as a world leader in automation change management supporting the most comprehensive range of PLC devices and editors. These devices are programmable and rely on digital programs that define their functionality and operation. The programs are stored electronically in the device and on backup electronic media. For this reason they are considered electronic records and fall under the requirements imposed by 21 CFR Part 11. Methods for conventional office records tracking and change control would not be sufficient for records associated with programmable devices.
It is not uncommon to find that PLCs are supplied by a variety of manufacturers where each brand comes with a unique set of program development and device management tools. Add to this the many legacy systems installed in an operating plant and one begins to understand the enormity of the change control and program archiving problem.
The program files represent the result of hundreds of worker hours. If a device fails or a program is lost, the inability to restore the last known working version can result in substantial economic loss in the form of production down-time.
The AutoSave server stores all programs for access during crisis situations. The server is solely responsible for system security and privilege control, archiving versions and ancestors, managing program files, and creating audit trails for historical tracking.
For each PLC connected to the network, the AutoSave Server records:
- The type of device
- Where the device is located on the network
- The type of software that is used to program the device
- Who is authorized to access that device and the changes they are authorized to make.
- Previous copies or ancestors of the production copies. Multiple previous versions may be archived.
- Master copies or named versions of the programs
When a user wishes to work with a specific PLC, AutoSave works with the client in the following sequence:
- Technician logs in and requests the right to work on the network by entering a user name and password.
- The AutoSave server reviews the user’s privileges and the AutoSave client displays the devices and programs the user is authorized to access. User requests a device and control program and AutoSave server grants access and downloads the required files. The files are marked at the server as being locked and checked-out. Requests by other clients to access those files will be denied.
- AutoSave client then starts the programming editor application required to work with the selected device and then connects to the offline or online PLC through the field network.
- The user then works offline or online with the selected PLC, making the required modifications.
- The user then annotates the change record, including a mandatory record of the reason for the modification.
- Together with the modification record, the new copy of the program file is uploaded from the client to the server. The server automatically moves the previous version to the ancestor files and saves the new version as the current version. The server then writes the audit trail for the user’s session.
- The AutoSave server then sends an email to the individuals who need to be advised that a change was made. Typically these will be sent to responsible individuals in Engineering, Production, QC, and Validation.
To read more about how automation change management features align with requirements set forth by the FDA, please fill out the form below to have this white paper emailed to you in its entirety: