Orlando LÃ³pez is a senior consultant at McNeil Consumer Healthcare, a J&J company.

Orlando López

Data integrity ensures that information stored during pharmaceutical manufacturing is reliable and trustworthy. Electronic records (e-records) pose special data integrity challenges. Links between electronic data, raw data (i.e., the first capture of information, whether recorded on paper or electronically [1]), metadata, and records must not be compromised or broken if the data and their relationships with other data are to be valid.  

	Preserving the integrity of the raw electronic data generated by manufacturing and quality operations is crucial because these data provide the only evidence that these departments are being run and managed correctly and in a way that complies with regulations. It is the foundation for continuous process verification (CPV) and process validation. Technological controls must be in place to ensure the integrity of these data. This article discusses these controls and how they should be implemented for identification, storage, protection, retrieval, retention time, and disposition of current good manufacturing practice (cGMP) records (2).

helps to map and explain the controls that are necessary to manage data, raw data, metadata, and records (3) properly. Data access control is crucial, for example, and any changes to an e-data point can only be made by someone who has been authorized to make those changes. Failure to address even one element of the data life cycle will weaken the overall effectiveness of controls implemented for the computer system and for e-data integrity.
	

	During the data capture stage, data are collected and related actions are performed. Then, during transformation, the data are scaled and converted, and then built-in checks (summarized in European Union [EU] Annex 11-11 [4]) are performed to verify that all the data are correct after the transformation. 

	Because the data transferred during this stage move between process equipment and the computer, the interface between the two should be validated and checked periodically to ensure accuracy. The accuracy and reliability of the raw data depend not only on properly calibrated and maintained instruments and equipment, but also on the integrity of the raw data that have been recorded. When instruments and equipment cannot ensure secure data access and administration of electronic data files, collected data can be passed directly to a secure environment (typically a supervisory control and data acquisition [SCADA] system or data historian) for processing and recordkeeping.

	After the data have been transformed and used, they must be moved to a recordkeeping environment where they can be edited for as long as necessary as the data are retained. During the active phase (i.e., when data are actively being used), raw data may be cleansed periodically to correct inconsistent values after they have been used. Periodically, data must be reconciliated. Cleansing or data cleaning is performed to detect and correct corrupt or inaccurate records from a record set, table, or database. This activity must be suitably managed and documented (e.g., by establishing an audit trail). The inactive phase starts with records archival, which applies to inactive, superseded, replaced, and withdrawn data. These records must be kept to meet the data retention schedule and traceability requirements.  These records usually maintain “read” and “view” attributes.  There are exceptions, however, in which “processability” may be extended for the full life of the records through to discard. 

	In these types of operations, data that have been loaded from field sensors contain a measurable attribute of a physical entity, process, or event (5). The loaded data are recorded, becoming raw data, which are considered “original” or “source captured” (6). When multiple raw data are generated to satisfy a cGMP requirement, such raw data become a cGMP record (7). Examples of raw data in a typical manufacturing environment include:

		Analog readings (e.g., of temperature, pressure, flow rates, levels, weights, central processing unit [CPU] temperatures, mixer speeds, or fan speeds)

		Digital readings (e.g., of valves, limit switches, motors on/off, and discrete level sensors)

		Product information (e.g., IDs for product, batch, material, or raw material lot)

		Quality info (e.g., process and product limits, custom limits)

		Alarm info (e.g., out-of limits or return-to- normal signals).

	The raw data hold the content of the e-record that will reproduce the full cGMP automated activities (8). Properly recorded and managed raw data are the foundation that is required to demonstrate the product identity, strength, purity, and safety. The e-records associated with raw data demonstrate that the manufacturer’s processes meet the requirements of cGMPs, including those for process sequencing and instructions (9).

	Accurate management of data during entry or collection, storage, transmission, and processing (10,11) provides controls required for the processing and retention of loaded data, raw data, and e-records. The integrity of manufacturing raw data is a basic prerequisite to CPV, an essential part of FDA’s process validation requirements. CPV is designed to provide continual assurance that the process remains in a state of control during commercial manufacturing. The collection of information about the performance of the process will allow detection of undesired process variability so that the process remains in control.

	Identification to the cGMP records (12) and associated controls are crucial to the success of any pharmaceutical manufacturing operation. The characterization of these cGMP records usually starts with a primary design document such as a process and instrumentation drawing (P&ID). A process flow diagram (PFD) or some other form of schematic may also be used.

depicts the critical process parameters for a solid dosage form manufacturing process. Process equipment incorporates instrumentation designed to control the process and acquire data about each critical process parameter.
	

	The primary goal for controllers is that they work accurately in the intended process. The controllers are dynamically verified during the qualification of the automated cell controller. The cell controllers are typical Level 0 in the ANSI/ISA-95 and essential to ensure proper functioning of the process and product quality. The input/output (I/O) list refers to the information that comes into and goes out of the manufacturing system.

, for example, the air temperature, air volume dew point, and product temperature are the I/Os associated with a fluid bed dryer (13). Field instruments provide measurements of these values from field instruments via terminating wires in the digital system I/O processing section. After transformation, the data are transmitted to the SCADA system over the communications link.

	The first step in documenting the I/O requirements is to compile a list of all the applicable points that are referenced on the P&ID. This is necessary so that the specific signal and termination data can be associated with each point or each instrument. Alarms and reporting requirements must also be considered.

	Raw data are original records generated by means of computer systems and become the contents of an e-record. E-records storage devices record, store, or retrieve e-records from any medium, including the medium itself. This is considered a short retention environment. Design specifications or similar documents must describe the file structure(s) in which the e-records are to be stored, as well as the capacity requirements of the storage, and how the security scheme is implemented.  The file structure and security are verified/tested during the qualification.

	After the data are recorded and retained by computer storage (e.g., historian/SCADA storage), the physical and logical controls to the e-records must be in place. These controls include physical protections, stamped audit trail, data management, archival and retrieval of records. Alarms and the associated actions to the alarms are managed by the programmable logic controller (PLC). The associated alarm records are saved in the corresponding repository system at the storage device level. Physical protection is important because environmental effects can cause media to deteriorate. Copying information without changing it offers a short-term solution, ensuring that information is stored on newer media before the old media deteriorate to the point where the information can no longer be retrieved.

	To ensure data integrity during storage, any changes that have been made to an e-record must be recorded, including the previous entry, who made the change, and when the change was made (14). To reduce the risk of losing the e-records in storage and to guarantee that they will be ready for use, data must periodically be backed up. Backup data must be stored separately from the primary storage location, and at a frequency based on an analysis of risk to CGMP e-records and the capacity of the storage device.

	The efficacy of the backup and restore processes must be verified as part of the qualification process. In addition, the capacity level of the storage must be monitored. As in archived e-records, the e-records in storage need to be verified periodically for accessibility, readability, and integrity. If changes are implemented to the computer infrastructure and/or application, then it is required to ensure and test the ability to retrieve e-records.

	One critical element to consider is legal holds to the e-records, which may exist when the manufacturing company or contract manufacturer is involved in litigation. These records cannot be destroyed, even if the data retention period has expired. The regulated entity is under a legal obligation to retain all relevant, and a legal holds record system or other mechanism must be implemented to identify e-records that would be affected by a legal hold.

	In optimizing physical location requirements for the e-data, web and database servers should ideally be separated.  Database servers should be isolated from a website’s demilitarized zone (DMZ), based on security standards.  A DMZ is a physical or logical subnetwork that contains and exposes an organization’s external-facing services to a larger and untrusted network, usually the Internet. The purpose of a DMZ is to add an additional layer of security to an organization’s local area network (LAN); an external network node only has direct access to equipment in the DMZ, rather than any other part of the network (15). 

	These servers can locate them on a physically separate network segment from the web and other Internet-accessible servers that support the business. Preferably, one should partition the database server off from the web servers by a dedicated firewall. This firewall should only allow database traffic between the web server and database server. The firewall should also deny and log all traffic from any other location, or other types of traffic from the web server. Regulators, and particularly FDA, expect that data written in the storage device be saved at the time they are generated (16). As appropriate, it is the expectations of the regulatory authorities that the data written in the storage device must be saved at the time the data are generated (17).

	The protection of transient data, raw data, and e-records cover data in storage, during processing, and while in transit (18–20). The protection of transient data, raw data, and e-records may be set in two environments: transient data before reaching the historian/SCADA and raw data, as shown in 

At the PLC level, the analog data are extracted from the PLC memory, transformed (i.e., digitized, validated, normalized, and scaled) and sent to the SCADA. The data collected directly from manufacturing equipment and control signals between equipment and a data server (e.g., SCADA) may be regarded as transient and cannot be edited by reasonable means or reprocessed by the human user. Similar to the controls associated with e-records in transit, the data integrity controls for transient data are:

The outcome of this qualification provides documentary evidence that accounts for the correct implementation of integrated hardware and associated devices (21).

These built-in checks are, at first, validated. During the operational stage, the built-in checks must be periodically verified (as required by FDA 21 

Part 211.68(b) and EU Annex 11-5) (22 and 23). 

. Usually performed at the supervisory system level, accuracy checks are required for critical data that have been entered manually by authorized personnel. These critical data require input verification to prevent incorrect data entries.

	After the data are recorded and retained, physical and logical controls to the e-records must be implemented and executed. These controls include security, access authorization, backups, periodic reviews, stamped audit trails, built-in checks (required by FDA Compliance Policy Guide CPG Section 425.400), and other relevant data-management controls. The PLC manages alarms and associated actions, which are saved at the storage device level. Controls are required if  the e-records and associated raw data must be transferred from the original processing environment. After concluding the migration process, verification must be performed to ensure that the information in the original e-records has not been altered. This verified copy becomes a true or certified copy.

	Access to e-records should be ensured throughout the retention period (as required by EU Annex 11-7.1). The access to these records must be controlled to ensure the integrity of the e-records in storage. The controls associated with e-records in storage allow those individuals who depend on the e-records to correctly fulfill their job functions.

	During the Active Phase, manufacturing e-records will typically be held in the environment in which the records were initially created. In this environment, the e-records are visible to the tools that created them. Any features designed to allow them to be changed or deleted must ensure audit trails that record the reason for change or deletion, as well as other information as required by the applicable regulation. 

	Periodic (or continuous) reviews must be performed after the initial validation (as required by EU Annex 11-11) of the processing environment. These reviews check stored, backup, and archived e-records for accessibility, readability, and accuracy. They also verify the output of the backup and the accuracy of the overall audit trail, verifying the accuracy and reliability of the e-records transferred (WHO 3.2). In addition, processes for reading and managing e-records must ensure their data integrity. The infrastructure between the records in storage and the processing environment must be a controlled environment and must be qualified and checked for accuracy.

	The EU cGMPs establish that raw data supporting information in the marketing authorization (24), such as validation or stability data, should be retained while the authorization remains in force.  In some cases, periods up to 30 years’ worth of raw data must be retained. It may be considered acceptable to retire certain documentation when the data have been superseded by a full set of new data. In such cases, justification should be documented and should take into account the requirements for retention of batch documentation. The accompanying raw data should be retained for a period at least as long as the records for all batches whose release has been supported on the basis of that validation exercise.

	For a medicinal product, the batch documentation must be retained for at least one year after the expiry date of the batches to which it relates, or at least five years after the certification referred to in Article 51(3) of Directive 2001/83/EC, whichever is the longer period. At least two years of data must be retrievable in a timely manner for the purposes of regulatory inspection.

211.180(a), call for data that are part of the drug product production and control records to be retained for at least one year after the expiration date of the batch or, in the case of certain over-the-counter (OTC) drug products lacking expiration dating because they meet the criteria for exemption under 21 

211.137, for three years after distribution of the batch. As the results of the traceability requirements, the raw data will be retained as specified in 21 

	When computer systems are used instead of written documents, the manufacturer shall first validate the systems by showing that the e-records will be appropriately stored during the anticipated period of storage. E-records stored by those systems shall be made readily available in a legible form and provided upon the regulators’ request. The electronically stored e-records shall be backed up and protected against loss or damage, and audit trails shall be maintained.

	If active records are transferred to another environment, validation should include checks that data have not been altered in value and/or meaning during this migration process, as required by EU Annex 11-4.8.

	E-records that are placed in retention environments, other than the environments that were used for their original creation, should preserve the integrity of the raw data, associated e-record, and protection mechanisms used to prevent informational loss and/or corruption. Should records require modifications in retention environments, a clear audit trail of change or replacement history, including record removal, should be maintained.

	Once e-records have been placed in the retention environments, they should never be directly modified. If technical limitations require the electronic record to be modified in the retention environment, the change must have traceability to the same change in the processing environment. The inactive phase starts with records archival. These records need to be kept to meet retention schedule requirements and traceability.  These records usually maintain read/view attributes. Finally, during the deletion phase, the e-records are discarded. This is a phase of short duration and includes metadata and audit trails.

	1.  UK Medicines and Healthcare Products Regulatory Agency (MHRA), 

GXP Data Integrity Guidance and Definition

ISO 9001:2000 Quality Management Systems – Requirements, 4.2.4 Control of Records


	3. ISPE/PDA, Technical Report: Good Electronic Records Management (GERM), Collection of Felated Data Treated as a Unit. (ISPE/PDA, July 2002).
	4. European Union, 

MHRA CGMP Data Integrity Definitions and Guidance for Industry

, March 2015.
	6. ISPE/PDA, “Technical Report: Good Electronic Records Management (GERM),” July 2002.
	7. MHRA, “GxP Data Integrity Guidance and Definitions,” March 2018.
	8. FDA, 

Data Integrity and Compliance with cGMP, Q&A - Guidance for Industry 

(September 2017) (CDFA, 2017).
	10. O. López, Preface, 

Data Integrity in Pharmaceutical and Medical Devices Regulation Operations, 

pp.15 -17 (CRC Press, Boca Raton, FL, 2017).
	11. NIST SP 800-33, “Underlying Technical Models for Information Technology Security,” December 2001 (Withdrawn: August 2018).
	12. FDA, 

Guidance for Industry-Process Validation: General Principles and Practices 

Automation Systems for Control and Data Acquisition 

(ISA, 1992).
	14. A Kane, Sidebar in A. Siew, “Designing Optimized Formulations,” 

41(4) (2017).
	15. Health Canada, “Good Manufacturing Practices (GMP) Guidelines for Active Pharmaceutical Ingredients,” GUI-0104, C.02.05, Interpretation #15 (Health Canada, December 2013).
	16. B. Mitchell, “

, Section 6.14.
	20. NIST SP 800-33, “Underlying Technical Models for Information Technology Security,” December, 2001 (Withdrawn: August 2018).
	21. FDA, 

21 US Code of Federal Regulations (CFR) 

Computer Infrastructure Qualification for FDA Regulated Industries 

(PDA and DHI Publishing, LLC, 2006).
	24. EU, 

Good Manufacturing Practice Medicinal Products for Human and Veterinary Use

, Volume 4, Chapter 4: Documentation, Section 4.12.


	Vol. 43, No. 6
	June 2019
	Pages: 32–38

	When referring to this article, please cite it as O. López, “Defining and Managing Raw Manufacturing Data,” 

	Submitted: January 4, 2019
	Accepted:  January 24, 2019

Articles

Protecting the integrity of raw data is crucial to regulatory compliance and to proving that manufacturing and quality operations are being run and managed properly.

Defining and Managing Raw Manufacturing Data

To help you get up to speed with the ins and outs of the amended version of Annex 11, which will come into effect on 30 June 2011, PTE brings you two articles that take a close look at the amendments.

New Annex 11: Enabling innovation by Markus Roemer

The new Annex 11 offers the opportunity for improvement and innovation. The revisions cover the current hot topics of IT compliance management and are based in the reality of today's systems, organisational structures, IT infrastructure and applications used in the GMP world. At the beginning of the Annex, the 'Principle' section states that: "The application should be validated; IT infrastructure should be qualified." This significant addition is a new clause on IT management in general, which is very much in line with related ISPE good practice guides.

Annex 11: Progress in EU computer system guidelines by Orlando Lopez

Compared with the older version, the amended Annex 11 contains more details, but remains a concise document that still provides practical and precise specifications that can help ensure that computer systems are produced under a quality system.

Lopez examines Annex 11's Main Directive, Principle and four main clauses: Risk Management, Requirements Management, E-records Management and Validation.

Annex 11 Articles

Part I of this article, which was published in the March issue of 21 CFR Part 11: Compliance and Beyond, discussed current technologies that can be used to manage the security associated with regulatory-related electronic records. Part II reviews how electronic-based solutions can be designed to conform to the security-related requirements in 21 CFR Part 11.

The goal of an enterprise public-key infrastructure (PKI) is to protect information assets through electronic-based solutions that comprise hash algorithms, data encryption, digital certificates, message digests, digital signatures and audit logs. The key condition and solution critical to 21 CFR Part 11 are authentication and encryption, respectively. Authentication verifies a person's identity as well as the integrity of records. Encryption protects the privacy of records. Although most information transactions do not require this level of comprehensive digital trust, PKI is the best choice for ensuring compliance with Part 11 security requirements and consequently for ensuring the privacy of records.	

All electronic-based solutions should be implemented by first evaluating the security infrastructure and a user's needs. This evaluation should include analysis of the security infrastructure, maintenance, and the system's potential growth. Table I summarizes the security-related Part 11 requirements. The following is a summary of how electronic-based solutions (technological controls) may be integrated to support Part 11.	

 All operations with records should be performed in a secure environment. This requirement applies to	

Organizations can use access controls, encryption (for example, end-to-end data encryption) and hashing to protect the integrity, authentication and privacy of records, and to prevent their loss. For example, records must be protected when confidential patient data are sent to other locations. Access controls are discussed later in this article. 	

 Encryption can be used to protect records in transit between networks, including the Internet. Tools such as network diagnostics or protocol analysers can read information easily as it is transmitted. To alleviate this problem, systems such as secure sockets layer (SSL), transport layer security, or virtual private networks (VPNs) can provide the necessary management of critical data across networks. These solutions use encryption, digital signatures or digital certificates to ensure data privacy, identification of the originator of messages and verification of message integrity.	

Table I Part 11 security-related requirements and controls.*			

End-to-end data encryption with PKI technology is implemented by encrypting messages and records with a recipient's public key, thus rendering messages and records unreadable to anyone except that recipient. To encrypt messages and records, the certification authority (CA) issues distinctive digital signing certificates containing the public key assigned to a recipient. Messages and records can be decrypted only with a recipient's private key. The combination of hashing and access controls provides another opportunity to protect sensitive records.	

One alternative to sending messages and records via the Internet is through the use of Secure/Multipurpose Internet Mail Extensions (S/MIME), which is the standard for secure e-mail within PKI. It enables secure communication between two or more parties by ensuring the integrity and authenticity of a message that is given a digital signature and the confidentiality of a message if it is encrypted.	

Scheduled backups, restoration procedures, and off-site storage of media are the best practices for supporting the recovery of records. The metadata (data that describe the structure, elements, interrelationships and other characteristics of electronic records) associated with each record should also be saved. On the basis of archival requirements, the protection of records includes the consideration of the degradation rate of the electronic images and the availability of the devices and software needed to access all records.	

 Public-key certificates can be used to authenticate the identity of a user, and this identity can be used as an input to access-control decision functions. Access-control decision functions are defined through access rights lists, for example, access control lists (ACLs) with functions such as use, read, write, execute, delete, or create privileges. In Microsoft Windows 2000 (Microsoft Corporation; Redmond, Washington, USA), an ACL is a list of security protections that apply to an entire object, a set of the object's properties or an individual property of an object. Each active directory object has two associated ACLs: the discretionary access control list (DACL) and the system access control list (SACL). A DACL is a list of user accounts, groups and computers that are allowed (or denied) access to the object. A DACL is a list of access-control entries (ACEs) in which each ACE lists the permissions granted or denied to the users, groups or computers listed in the DACL. An ACE contains a security identification with a permission statement such as read access, write access or full control access. The SACL defines which events (such as file access) are audited for a user or group.	

Access controls provide the means to design a system in such a way that, for example, a supervisor can access information belonging to a group of employees without allowing everyone else on the network to access it too. In the context of Part 11, access controls are deemed an element of authority checks.	

 The importance of authentication can be expressed through the following two examples. First, IPSec servers, which are key elements in secure networks, provide the ability to protect traffic between hosts and sets of hosts within the network and check hosts on other networks. The security of an IPSec server depends on strict access controls, authentication, device checks and authority checks. Only specifically identified administrators should be able to log in to the IPSec server or change its configuration. The IPSec server should maintain an audit trail for all computer-related administrator actions. Second, to secure the exchange and integrity of records and messages, both sides - users and processes - must have their identity verified before the exchange occurs. Authentication can be implemented in varying degrees of strength, and it lays a foundation for other security services such as access controls.	

In terms of the authentication of a user or of records and messages, first a person typically enters their identification code (user ID) into the system and then authenticates their identity by providing a second piece of information that can be produced only by the person (password). There are three authentication methods: user ID and static passwords; user ID and dynamic passwords; and biometric devices.	

 Static passwords are still the cheapest, most widely used simple authentication mechanism. Although one could use stronger mechanisms than passwords (for example, one-time passwords, challenge-response mechanisms, cryptographic mechanisms, or even biometric mechanisms) to accomplish user authentication, passwords are the most common authentication mechanism and often provide adequate protection of computer resources.		

Figure 1 SSL 3.0 protocol encrypts data between the server and the browser. It also supports client authentication for access control. (Figure provided by D. Coclin, "Public Key Technology Overview," courtesy of Baltimore Technologies www.baltimore.com).			

Currently, most systems offer at least basic password management features. Such features could include	

password aging and expiration, which allows the password to have a lifetime, after which it expires and must be changed 

password history, which checks the new password to ensure that a password is not reused for the specified amount of time or the specified number of password changes 

account locking, which allows automatic locking of an account when a person fails to log into the system in the specified number of attempts 

password complexity verification, which checks the complexity of the password to verify that it provides reasonable protection against intruders who might try to break into the system by guessing the password. 

 Passwords and personal identification numbers (PINs), which are alphanumeric codes or passwords used to authenticate an identity, can provide a stronger means of authentication when they are combined with other authentication techniques. Typically, the combination involves something the person knows (for example, passwords and PINs) and something the person possesses, such as tokens. Tokens are software or hardware mechanisms that provide a person with the second piece of authenticating information. Included within this group of mechanisms are	

 As the name implies, one-time passwords are similar to traditional passwords because they are used in conjunction with a user ID, but they are limited to one-time use. The advantage of this technique is that it prevents the repetition of a compromised password. Frequently, one-time passwords are used not only in conjunction with user IDs, but also with passwords or PINs. Commonly, a small hand-held device the size of a credit card is synchronized with the target system's authentication scheme and displays a one-time password that periodically changes. To access the target system, the person enters an assigned user ID and password followed by the one-time password currently displayed on the hand-held device. This method of authentication provides additional security because the person must know the information and possess the authentication token.	

 These schemes look like one-time password generators and use a similar synchronization mechanism; however, additional user actions are required for authentication. This feature is a challenge-response exchange with a new key that is used at each log-in. 	

This feature is an increasingly popular technique for strong authentication. A party wishing to be authenticated presents a digital signing certificate. If the certified party is still trusted in the organization, then the server trusts that the party is who they claim to be. One benefit of certificate-based authentication is that the entity does not need to have an established relationship with, for example, a server before being authenticated. This attribute makes certificate-based authentication an excellent solution for online commerce.	

SSL 3.0 protocol (Figure 1) uses X.509v3-compliant digital certificates for authentication. The most common use of SSL is to authenticate a server to a person, but it can also be used to authenticate a person to a server. By authenticating a server, the person is assured communication with the correct site. SSL also signs the transmitted information so the person is assured that the information has not been changed during transit. 	

Another example of certificate-based authentication is the authentication of e-mail transport. E-mail transport can be checked against the identity of the recipient through authentication technology. Authenticating e-mail users ensures there is no fraudulent user access. Smartcards and tokens are also common methods to implement dynamic passwords and certificate-based authentication. 	

 Biometric mechanisms tend to be best suited to the enforcement of physical access rather than electronic access; that is, they do well where a human guard (or proximity sensor) might be used, but they generally do not apply to electronic access to a website. Consider that the biometric in question, for example, your fingerprint is to be used for access to a website. The attacker must capture a person's fingerprint data only once and then can replay it while masquerading as that person. The TruSecure website  provides a list of biometric devices (		

http://csrc.nist.gov/publications/nistpubs/800-7/node55.html

The most common methods of strong authentication are automatic password generators, for example, tokens and smartcards. Tokens and smartcards store information regarding a person and require a reader device. To protect against theft, a person must enter a password or PIN before this information in the token or smartcard can be accessed.	

) is an industry-standard authentication system suitable for distributed computing by means of a public network. Implemented in Windows 2000, it uses public-key encryption and hashing algorithms. Kerberos requires a certificate server that acts as a CA, managing keys and digital certificates. (A server is a computer or device on a network that manages network resources. A certificate server manages key and digital certificates.) This server maintains a database of secret keys for each entity, authenticates the identity of an entity that wishes to access network resources and generates the session's keys when two entities wish to communicate securely.	

Records must remain complete during transmission. The unauthorized manipulation of records, audit trail records and replay of transmissions will be reliably identified as errors. Records and messages authentication provides the means to evaluate the integrity of the data and message. It involves technical controls to detect unauthorized modifications to data and messages. A recipient can use three approaches to authenticate data and messages:	

encrypt records or messages using the recipient's public key

 As part of the reliability of records, audit trails refer to a journal that records modifications to the records. The person or automated processes operating on the user's behalf may perform these modifications. An audit-trail mechanism provides the capability to reconstruct the modified data and, therefore, does not obscure previously recorded data. The tracking mechanism includes a computer-generated time-stamp that indicates the time of the entry. Audit trails are computer generated and can be part of a record or a record by itself. The date and time of an audit trail should be synchronized to a trusted date-time service. 	

Controls to the audit trails include record-audit linkage. Audit trails cannot be modified and access to them will be limited to print-read only. The combination of authentication, digital certificates, encryption and ACLs provides the mechanisms to control the access to audit-trail files.	

 Time-stamping is recognized as a valuable service that supports non-repudiation of transactions. It adds integrity and trust to messages and records sent by means of a network. Accordingly, unauthorized modifications to the system clock and time drift between servers are prevented. Time drift is when two or more servers do not have identical times. The discrepancy can vary from seconds to minutes and can become extensive if left unchecked. The certificate server and client clocks must remain synchronized as closely as possible. The Kerberos-recommended maximum tolerance settings for computer clock synchronization is 5 min. Kerberos uses time-stamps to determine the validity of entities' authentication requests and to help prevent replay attacks.	

Part 11 requires that the system date and time are included as part of the audit trials and electronic signatures. The digital time-stamping service (DTS) issues a secure time-stamp - which includes the time, a hash of the digital information being time-stamped, and a time certification - that can be used for digital signatures. A message digest is produced from the record and sent to the DTS, which returns the time-stamp, as well as the date and time the time-stamp was received, with a secure signature. The signature proves that the document existed on the stated date. The document contents remain unknown to the DTS - only the digest is known. The DTS must use lengthy keys because the time-stamp may be required for many years. 	

DTS and digital certificates provide the mechanism to authenticate the source (device checks) of the time-stamp in the audit trails and electronic signatures. Access-right lists and digital certificates can be used to control access to the DTS.	

In addition to DTS, other supporting time controls include an infrastructure that supports time-stamping from a trusted time such as the co-ordinated universal time (www.datum.com/tt). This technology, which in some cases is compliant with X.509 or the Internet Engineering Task Force, is tied into a time-calibration service. Applications or computer logs may require time-stamping services on the server.	

 Authority checks ensure the correct right-of-entry to records or computer resources and can be implemented by combining ACLs and digital certificates. In one possible scenario, the person accessing a system tries to read and sign a batch record. Before executing these actions, the system verifies the access rights and the validity of the digital certificate to determine if the person is authorized to perform these operations.	

In another scenario, an operator logs into the system to perform an operation in a process area. After the operator types the user ID and password, a digital ticket is created that asks the training system to verify the operator's training record and confirm whether the area and equipment were cleaned and released for production. The system returns the appropriate authorization to perform the operation. In this example, authentication, digital certificates and access-right lists are combined to provide the necessary control to operations.	

 Part 11 defines device checks as a means to determine, as appropriate, the authentication of a server and the validity of the source of data or operational instruction. Digital certificates can be used to implement any of these verifications.	

Device checks, integrated with PKI, can be used to record and sign electronic case-report forms (e-CRFs). Using, for example, smartcards or tokens, each investigator or investigator's trial staff can log remotely into the external Web server and complete the information required by the clinical-trial protocol. Each smartcard or token can be used to identify each investigator or investigator's trial staff. Only authorized personnel are allowed access to each form. The granularity in an e-CRF can be set to each field in the form. With certificate-based authentication, the communication to the external Web server is secure. Internet Explorer, for example, uses X.509v3-compliant digital certificates to verify the identity of a person, organization, account or site. 	

 Hashing, encryption, digital signatures and cryptographic product-services families offer the right solutions to open systems as defined by Part 11. These technologies retain a high degree of information security even for information sent by means of open, insecure, but inexpensive and widely used channels.	

 An electronic-signature solution must secure electronic signatures through encrypted copy protection and make it impossible to copy, cut or paste signatures and audit trails from an approved record. This requirement helps accomplish the integrity of digitally signed records. One must consider the integrity and security of the main components of digital signatures: the PKI components. The extent to which the user is confident about the linkage between a public key and its owner depends greatly on  the user's confidence regarding the system that issued the certificate that links them.	

In addition to the system issuing digital certificates, access-control technologies and procedures, the signature-record linkage must have supporting tools to verify the integrity of this link. PKI uses hashing algorithm and keys to demonstrate the integrity of signed records. A digital signature is linked to a record by incorporating an encrypted message digest of the record into the signature itself. This link is retained for as long as the record is kept and provides the trustworthiness of electronically signed records for that period of time.	

The goal of an enterprise public-key infrastructure (PKI) is to protect information assets through electronic-based solutions that comprise hash algorithms, data encryption, digital certificates, message digests, digital signatures and audit logs. The key condition and solution critical to 21 CFR Part 11 are authentication and encryption, respectively. Authentication verifies a person's identity as well as the integrity of records. Encryption protects the privacy of records. Although most information transactions do not require this level of comprehensive digital trust, PKI is the best choice for ensuring compliance with Part 11 security requirements and consequently for ensuring the privacy of records.

Overview of Technologies Supporting Security Requirements in 21 CFR Part 11 Part II

The objective of this article is to attempt to look at the future state of computer validation principles based on current events and trends in regulations, business practices and technology. This crystal ball approach will prepare the industry for the future by establishing a current-state best-practice foundation of computer validation principles as well as improving computer validation practices.

Part I of this article was published in the March 2003 issue of 21 CFR Part 11: Compliance and Beyond. In this issue, Part II discusses the potential advances and changes that must be made for computer validation to remain innovative and relevant to the industry.	

Improving the future of computer validation infrastructure

With the increased need to conduct computer validation, there comes a need to improve the efficiency of how computer validation is performed. To have better efficiency in computer validation practices, a better infrastructure for computer validation practices is required. In addition to an existing computer validation programme that may already have been established (for example, the availability of an inventory list of the systems, a master plan on the validation status of the systems or a prioritization of how the systems are going to be validated and procedures for conducting computer validation), the following are some conceptual approaches that can be considered for building the future infrastructure (please note that these concepts are simply food for thought).				

Use of a commercial off-the-shelf (COTS) screening requirements document

The current computer validation practices for preparing a full and thorough requirements document before system purchase may hamper the effort of purchasing a system in an expedient manner. In addition, the current operational lifestyle for new systems acquisition is mainly related to the purchase of COTS software, which typically means there is an existing client base and, perhaps, some familiarity with the product. The concept of screening requirements is the use of a high-level requirements document to select a vendor, which enables a purchase order to be issued and then allows the system acquisition process to begin. Once the vendor is selected, the strategy is to work with the vendor in acquiring or developing the specifications document. The potential for developing and using a screening requirements process can only be considered for purchasing a system that meets all of the following criteria:		

a COTS system (one that is not a customized, contracted or an in-house developed system)

not a new system (that is, it is not version 1.0; there is an established, regulated client base)

a system for which the principle of functionality and operation is already known (for example, a high performance liquid chromatography system)

a similar system is already available in-house

a system for which the requirement specifications can be furnished by or co-developed with the vendor.

As with other types of software systems, a risk factor is involved in the use of this screening requirements concept. Those risks may vary from system to system, from project to project and from company to company. From a computer validation perspective, the main risk factor to be considered when using this concept is the capability of it meeting the basic objective of computer validation: providing documented evidence that provides a high degree of assurance that the system reliably and consistently does what it is designed to do. When this concept is applied, and the above criteria are met, the basic objective of computer validation can still be met. Mitigating the risk arising from this approach can be done by ensuring that the system is qualified to meet business needs (for example, through testing). Hence, incorporating and meeting business needs should be included in validating the system.	

Process for evaluating the need to do a vendor audit

This section is not intended to introduce a concept regarding how a vendor audit should be conducted, but rather to introduce the concept of determining whether there is a need to conduct a vendor audit (or the type and level of the audit). Having such a process will define a consistent approach for evaluating vendors and expedite the decision making process.				

The following are some of the questions that can be considered for this process:	

is the system COTS or custom developed (contracted out or developed in-house)?

does the system's acquisition involve the purchase of one or more than one system?

will the system be implemented at one location or multiple locations?

will the system be deployed as a standalone system or interfaced to other systems?

is the system new and recently marketed or has it already been in the market for an extended period of time?

has the purchaser had experience with this system?

has the purchaser had experience with the vendor?

will the vendor be used just for this one particular project or for future projects?

has the vendor been previously audited by your company or does the vendor have an audit on file with the Audit Repository Center?

can the vendor make high quality development validation available?

does the vendor have an established market history (is it financially stable)?

does the vendor have quality certifications?

does the system perform complex GxP functions (for example, you may not want to do an audit of a vendor for simple electronic balances)?

Other factors can also be considered and a weighting factor can be applied to each of those factors. The totalled result can be used to determine whether a vendor audit should be conducted. Having this type of process in place will expedite the process of computer validation by providing guidance as to which vendors must be audited.	

Process for accepting third party certification

In addition to considering the need for vendor audits to inspect the quality of the product, alternatives - such as third party certifications - may be evaluated. The introduction by the US Food and Drug Administration (FDA) of a systems approach to inspection may facilitate the use of third party certification to evaluate the quality of the software without performing a vendor audit. Accredited certification bodies certify the quality of a product by conducting audits performed by independent external quality assurance agencies known as third party certification bodies.39 The certification bodies use technically qualified auditors who have been specially trained and subjected to professional selection. Having this type of process in place would expedite computer validation by potentially avoiding long discussions regarding the quality of the product. Instead, the audit can concentrate on the capability of the product to meet user needs.				

It should be noted that FDA does not currently recognize any third party certifications, including ISO 9001 certification. The industry must work with FDA to provide it with a level of trust in such a scheme before it can be relied on to mitigate the validation workload. In the meantime, the PDA effort (Technical Report 32) of vendor audits and the establishment of a vendor audit package repository centre39 should be considered as a means of satisfying the supplier audit requirement.	

Availability of a corporate data dictionary

To increase the efficiency of the process for making a decision and for information availability, the need for systems integration (for example, between chromatographic systems and LIMS or between LIMS and MRP) will increase and become more prominent in the future.		

To anticipate this need, one has to consider the development of a corporate data dictionary standard (for example, establishing standard definitions for terms such as sample, item code and unit of measurement, and creating a naming convention for products or data elements that will be shared between the computer systems). Building the data dictionary can be started whenever a new system is deployed or from the existing systems through the collection of data dictionary items from those systems. The collected data dictionary items from the various systems can then be compiled and cleaned (that is, eliminating redundancies and selecting a primary data item preference) to provide a controlled version of the data dictionary. When another system is being considered for deployment or acquisition, the data dictionary can be used to assess whether the data elements already exist in the dictionary or a new element must be introduced to the library. This data dictionary can also be used to support requirements development and will be an aid to system or vendor selection. For example, the data dictionary can help determine the complexity of integrating or interfacing new and existing systems.	

Simplifying the computer validation approach

Currently, almost all instruments or equipment being purchased contain a microprocessor, even those as simple as a pH meter. The level of validation (or qualification) of a simple microprocessor-based system does not always require the same level of validation effort that a more complex system requires. Hence, a simple conceptual process for determining the level of validation (or qualification) effort is needed. This concept is based on the premise that the level of validation (or qualification) can be categorized as needing either calibration, qualification or validation. For example, laboratory instruments or equipment that meet all of the following criteria can be categorized as needing calibration only:				

equipment or instruments in a COTS system

instruments or equipment not attached to an external computer or PC

if software is embedded in the equipment or instrument and only the vendor can load or change the software

no data are retained or stored by the equipment or instrument other than the current data analysis measurement

no data can be stored and retrieved, changed and stored again

the equipment or instrument is of the standalone type and not interfaced or integrated to other systems (if it is interfaced or integrated to other systems, then the total integrated or interfaced system must be considered when determining the level of validation or qualification).

After calibration, qualification must also be performed if the following factors are required to operate or use the equipment or instrument:	

calibration must be run whenever a sample analysis is performed (calibration is not the periodic type of calibration or performed on a preventive maintenance schedule)

final output (or result) of the equipment or instrument requires data processing or calculation based on the input of another sample or other data parameters obtained during the analysis of that additional sample

the equipment, instrument controls, monitors switches or other functions that are needed for that equipment to operate.

For an instrument or equipment that does not fall into these categories (that is, calibration or calibration 1 qualification), then validation is required. The level of validation can then be divided, based on whether the system is a custom-developed or a COTS system. For the custom system, a vendor audit, design specifications, programming standards and a source code walk-through and review may have to be considered and included as part of the validation activities. For COTS packages, much of this work will have already been done by the vendor (and verified through an audit). The criteria described above offer a conceptual depiction of the types of issues that must be considered when attempting to determine an appropriate level for validation activities.	

Validation data and test sets retention for regression data analysis

Part I of this article was published in the March 2003 issue of 21 CFR Part 11: Compliance and Beyond. In this issue, Part II discusses the potential advances and changes that must be made for computer validation to remain innovative and relevant to the industry.

The Future State of Computer Validation, Part II: Increasing the Efficiency of Computer Validation Practices

Current security technologies and associated infrastructures are designed to protect information assets and satisfy 21 CFR Part 11 requirements for integrity and privacy of records using authentication and encryption methods.

Overview of Technologies Supporting Security Requirements in 21 CFR Part 11, Part II

A combination of security technologies, infrastructures, and cryptographic product-services families can help companies satisfy the requirements of 21 CFR Part 11.