According to the US Food and Drug Administration (FDA), “ensuring data integrity is an important component of industry’s responsibility to ensure the safety, efficacy and quality of drugs” *1 and in recent years the FDA has found increasingly more violations involving data integrity. Because data integrity is a too broad of a topic to deal with in a single blog we will focus on one specific aspect of it: data integrity for systems that use shared user accounts. Furthermore, we will focus on addressing the requirement that data must be retained as “original records”, “true copies” or “other accurate reproductions of the original records” (“reliable and accurate data”).*1
The FDA defines data integrity as:
”The completeness, consistency and accuracy of data. Complete, consistent and accurate data should be attributable, legible, contemporaneously, recorded, original or a true copy and accurate (ALCOA)”. *1
During development or production of pharmaceutical products it is important that all used data is correct, available, accessible by authorized user only, and therefore can be relied on in decision-making. To achieve this, data integrity must be ensured.
If data integrity cannot be ensured, than the possibility exists that the produced /developed products do not meet the quality requirements and/or do not work as intended. Or worse, the pharmaceutical product may have properties that have a negative effect on patients’ health. This is why regulatory authorities are currently focusing on data integrity.
Thus, the importance of reducing your data integrity risks, and ensuring controls are correctly implemented and appropriately managed throughout the entire record life cycle is very clear.
Data integrity while using shared user accounts is a difficult one. Shared user accounts could be an Operating System (OS) - or application user account that are not specific for one user, but are used by more instead.
Some computerized systems are used with shared user OS accounts e.g. because the application software must be running 24/7, other software is only working when it is run with an administrator account (this is a user account with all possible user rights) or an account with elevated rights (more user rights than a normal locked down user). This results in increased data integrity (and security) risks. Using such a computerized system gives the users the possibility to (accidentally or deliberately) alter or delete data stored on local hard drives.
Furthermore, if someone is logged in with a shared user account it is not registered which specific user it is. If a user is editing data, it is only logged that that shared user account did the editing, and not which actual user. So it cannot be checked who was the one responsible. Therefore, measures must be taken to avoid this.
One of the measures to implement is to install security software that is designed to limit the rights of the users on the computerized system, while the rights of the application software stay the same.
The security software acts as a ”point-police man” between the operating system (Windows) and the application software regulating the users and the application software, so to speak. With this security software, it is possible to:
Set the rights of the application software:
Set the user rights
How the security software enforces the rules to meet compliance can be configured too:
To illustrate this theory pretend you’re using application software (DataPro900) that is run under a shared OS user account with elevated user rights. The steps taken to configure the security software would be:
When the system is rebooted after this configuration, the following start-up screen is presented:
As you can see the system is completely locked down, only the DataPro900 application software and File Manager can be started.
The security software has an interface that makes configuration rather straightforward, you just have to tick or untick the options you want to set for the software. The interface has several screens where you can set the different options you want to use for your software. This security software stores its configuration in HTML language. The main advantage of the use of the interface is that no prior knowledge of HTML is required to configure the software.
Ofcourse, knowledge of the application software and the system it is run on is needed because this knowledge is needed to guarantee the best possible protection when using this security software.
For an example of one of the interface screens, see the picture below.
In the case described above it is possible to make computerized systems with shared user accounts more secure, reliable and compliant with GxP regulations, when using security software.
Data integrity is maintained because users have “reliable and accurate” *1 data to work with, which cannot be altered from outside the software application or the File Explorer.
Shared user accounts need to be assessed on a per system basis. E.g. The above procedure will not completely fix the problem when the application software uses shared accounts, like accounts based on roles (e.g. Analyst, Study Director, Lab Administrator). Then the application software itself is not compliant and that cannot be fixed by installing the security software. The advice then is to investigate new application software and make sure it has all functionality before taking it into use. At Xendo we developed and use standard lists to check if systems comply with 21 CFR Part 11 and Annex 11 for this purpose. Ideally, when starting from a green field, infrastructure and application should both be assessed before deciding upon a computerized system to use.
*1 FDA Data Integrity and Compliance With CGMP Guidance for Industry DRAFT GUIDANCE