Username : | |
Password : | |
| Register | |
GAMP: Your Administrator and Administrators for Instruments
Data integrity cannot be achieved without good system administration. The administrator (“admin” for short) provides the oversight of systems to assure they remain controlled, and as a result, critical data is protected from unauthorized creation, deletion or modification.
SYSADMIN ACTIONS
Although it can vary, the admin often is responsible for implementing access controls and configuration controls. The admin often reviews records for unapproved access attempts and failed transfers of information. In short, they guard the system. Their work is critical to preserving controls that ensure data integrity.
POTENTIAL CONFLICTS ABOUND
Like any oversight function, objectivity is needed for an effective admin—it is their duty to defend the system and its data. Therefore, an admin with close friends in a business team is a problem for conflicts of interest. If someone needs access today for a priority project—but their training is not complete—the team might feel pressured to ask for a “special exception”. Now the admin has a conflict: either be a team player or be an admin. Procedural controls may not be properly observed when the admin has to sit every day with the people making the request and those people can influence performance reviews as well.
The organization must set up the admin for success. The admin should ideally sit in an area close by—easily accessible—but not with the team that uses the system. In a small firm lacking dedicated resources, someone from a different group can manage the system(s): someone in Group A is admin for Group B, and vice versa.
Another issue is the admin who also can perform business actions on the system. This is a conflict—how can you be system guardian when acting as a user? Admittedly, some COTS systems are designed to allow the admin to go anywhere within the application. You can only limit admin actions for these systems with procedural controls and training. Some systems can be configured to prevent the admin from executing business functions on the system. If available, this should be done to eliminate one potential data integrity gap.
CONFIGURATION FLAWS
Several Warning Letters list defects in system configuration as a data integrity gap(1). The person typically responsible for managing the configuration is the admin. Most critically, they manage the audit trail for post-collection modification/processing of raw data. It is essential that an admin periodically review the system configuration to assure that it provides a complete record of testing, as required by predicate rule regulations. Since COTS software packages can vary widely with regard to configuration management, diligence and good documentation are necessary to assure that a configuration remains compliant throughout its useful life. The reward is a system that functions as intended, able to detect aberrant activities that place data integrity at risk.
In summary: (1) The system administrator should be independent of the supported business area to eliminate potential conflicts of interest; (2) If possible, the system should be configured to prevent the administrator from performing business activities; (3) Verify that audit trails are enabled—especially audit trail activities that involve changes/calculations related to raw data after its collection.
Reference
(1) Example FDA Warning Letters include Micro Labs Ltd (Jan 2015), Posh Chemicals (Aug 2013), USV Ltd (Feb 2014), Wockardt Ltd (Jul 2013), Novacyl Wuxi Pharmaceutical Company (Dec 2014).
Previously we discussed the importance of selecting the right person as your administrator to assure objectivity and conformance to procedures in practice. This blog continues with another potential issue for instruments with attached PC controlling software: the administrator who is also a user. This includes COTS software designed so the administrator has access to all capabilities of the software—a “super user”.
This brings two issues:
- The administrator can create/modify an account AND use it to do anything to test data that is permitted by the software
- The administrator may have access to functions for which they lack education or training
Issue #1 can be problematic for most systems. Anytime an administrator can create an account, give it access rights, then use it to access test data using the software (or even the operating system), there is potential for data corruption. The primary defense is selecting an administrator with no personal interest in the users or system-generated data—they can be objective, as discussed in the Your Administrator blog post.
Issue #2 is problematic when software gives an administrator access to testing functions and this access cannot be disabled. The only recourse is procedural control and training — “thou shall not use these functions”—along with periodic checks to verify the administrator is not performing unauthorized actions. Another approach is to create two accounts for this person – one as the administrator and another as a user. Neither of these is as effective as technical controls – prevention is better than detection. It is strongly advised that you NOT select a person with technical knowledge of the instrument as your administrator —this puts the administrator in a potential conflict of interest where they could be pressured to use their access to change test data. If the administrator cannot be trusted to protect data integrity, then can anything from the instrument be trusted?
To avoid these issues, stop! Stop purchasing instruments that give an administrator access to testing functions. If you already own one, use all of the capabilities provided in the software to restrict the administrator’s access to any features beyond account management (and possibly configuration controls) and limit the administrator to account management in your instrument setup, your procedures and training materials.
Pick your administrator carefully—they protect the integrity of your electronic records.
Source: ISPE Blog