The article has been updated successfully.Implementing E3 applications in environments regulated by FDA CFR Title 21
1) Overview
Background
In 1991, members of the pharmaceutical industry met with the United States Food and Drug Administration, (FDA), to determine how they could accommodate paperless record systems under the current good manufacturing practice (CGMP) regulations in parts 210 and 211. FDA created a Task Force on Electronic Identification/Signatures to develop a uniform approach by which the agency could accept electronic signatures and records in all program areas.
The final rule provides criteria under which FDA will consider electronic records to be equivalent to paper records, and electronic signatures equivalent to traditional and written signatures. Part 11 (CFR 21 Part 11) applies to any paper records required by statute or agency regulations and supersedes any existing paper record requirements by providing that electronic records may be used in lieu of paper records. Electronic signatures which meet the requirements of the rule will be considered to be equivalent to full handwritten signatures, initials, and other general signings required by agency regulations.
FDA CFR 21 Part 11 Requirements Summary
The requirements show the need for a secure control system to include user login, automatic logout after no user activity and procedures to ensure that the users who perform the actions on the system are both the authorized user and not an imposter. A closed system or a runtime only system is a means of securing the control system as it only allows authorized users to access and apply changes to the system.
The other major part of the requirements involves the tracking of logged data and system changes. When changes are made by a user that is required to be signed, the records can be stored electronically if the user enters their password or uses a suitable biometric device. Data that is logged and stored has to have valid timestamp and be secure, which includes a full audit trail log of any changes that are made to the data along with backup and restore procedures.
Document Purpose
This document is a guide to how to configure Elipse E3 to meet each requirement of CFR 21 Part 11. Elipse E3 can be implemented to meet these requirements, but it is important to understand that it is not Elipse E3 that is validated, but rather the process implemented. Therefore, the system must still undergo the proper FDA validations to meet the requirements, including both documentation and training.
The guidelines on how to implement Elipse E3 to comply with CFR 21 Part 11 are explained in follow chapters. We provide step by step instructions for each for the relevant subpart sections B and C of the CFR 21 Part 11, followed by an Elipse comment (signaled as the examples below) and, when applied, a comment for an implementation guideline.
§ CFR 21 Document Text
A text into this fontface represents a relevant extract from CFR 21 Part 11 document.
Comments
A text signaled as follows represents the comments from Elipse about the determined subject:
(Commands) These sections refer to sections involving the issuing of operational commands.
(Data Logging) These sections refer to the data that needs to be logged.
(E3) These sections involve deploying Elipse E3 for the Server or Viewer consoles.
(ElipseX) These sections refer to areas where Elipse E3 libraries (ElipseX) will assist in developing a solution.
(FDA) The FDA has requirements regarding procedures that have to be in place to be able to obtain "CFR 21 Part 11" certification from the FDA. These requirements do not directly involve the E3 implementation.
(Security) These sections refer to system security, both Elipse E3 and/or Windows security.
2) FDA CFR 21 Part 11 commented
Subpart B – Electronic Records
§ 11.10 Controls for closed systems. Persons who use closed systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, when appropriate, the confidentiality of electronic records, and to ensure that the signer cannot readily repudiate the signed record as not genuine. Such procedures and controls shall include the following:
PS: Closed system is an environment in which system access is controlled by persons who are responsible for the content of electronic records that are on the system.
(E3) For a closed system implementation, it's recommended to use a E3 Server only license (without E3 Studio) and also use the Windows NT/XP/2000/2003 security to control access to the application files. It is a customers responsibility to ensure there are procedures to control access to the system and its files.
Although a person can only edit an Elipse E3 file (PRJ, LIB, etc.) with a specific authorization inside the development tool E3 Studio, these files are not default write-protected. So, whenever possible, file edit security into PRJ or LIB files should be applied. (See next section for protection example inside E3 Studio).
(a) Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.
(FDA) It is the customers responsibility to ensure the systems undergo the proper FDA validation procedure.
(b) The ability to generate accurate and complete copies of records in both human readable and electronic form suitable for inspection, review, and copying by the agency. Persons should contact the agency if there are any questions regarding the ability of the agency to perform such review and copying of the electronic records.
(Data Logging) The electronic records should be logged to a secure relational database. The application developer shall never include routines or SQL statements into application that could delete or destroy records, but rather add new records if an authorized change is required. All logged records should include the user's security identifier and be secure. For that, the developer needs to include at the E3 AlarmServer database definition the field ActorID. For other Audit Trail information, E3 logs automatically all operations. To accomplish this, we suggest using one of the Databases supported at this moment by E3 (MSDE, MS SQL or Oracle), and use the Database security to grant access to application database and tables only for a specific user (specific login and password), that should be informed inside E3's Database Server object (saved into E3 PRJ files). The use of Access MDB is not recommended, but depending on circumstances, it can be used for testing purposes, applying security for users and the MDB file itself inside Windows. Human readable reports should be setup to display the data logged to the secure relational database and are available to be copied by the FDA. Use the E3 Reports tool to create the reports you need, exporting data to formats like HTML, Acrobat PDF and Microsoft Excel XLS.
(c) Protection of records to enable their accurate and ready retrieval throughout the records retention period.
(FDA) (E3) Data logged to the secure relational database should be kept for the appropriate retention period and protected via security. This is defined in E3 inside AlarmServer, Historic, and Domain configuration dialogs. Alternatively, suitable secure backup and restore procedures should be used.
(d) Limiting system access to unauthorized individuals.
(Security) Elipse E3 security should be used to limit users to areas that they have the appropriate authorization level to access. Elipse E3 should be set up to logout a user after a time with no user activity. Unsuccessful logins should be monitored.
(e) Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying.
(Data Logging) All E3 standard Data Logging operations always include time stamping and never modifies or deletes records, unless if programmatically inserted by developer personnel. Although, if such operation is required, a specific operation sequence can be generated to call a electronic signature, storing the operation at the audit trail logs, informing essentially who did what, wrote what, and when. When using multiple stations, a time broadcast procedure should be used to keep all stations clocks synchronized.
(f) Use of operational system checks to enforce permitted sequencing of steps and events, as appropriate. The agency advises that the purpose of performing operational checks is to ensure that operations (such as manufacturing production steps and signings to indicate initiation or completion of those steps) are not executed outside of the predefined order established by the operating organization.
(ElipseX) Elipse E3 should be configured to ensure users follow a permitted sequence of steps when operating the system. The use of ElipseX objects is recommended to ensure users follow the same steps during a process over the entire system.
(g) Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand.
(Security) Elipse E3 security should be used to limit users to areas that they have the appropriate authorization level to access including operation and data logs. Extra safety instructions include:
- E3 Viewer should be set up to logout a user after a time with no user activity.
- New passwords should be checked to confirm they have a minimum length.
- Unsuccessful logins should be monitored.
(h) Use of device (e.g., terminal) checks to determine, as appropriate, the validity of the source of data input or operational instruction.
(Commands) Operational commands should be confirmed along with E3 Viewer terminal location and user's area to check the validity of an operational command.
(ElipseX) The use of ElipseX objects can be useful to add extra safety to these operations.
(i) Determination that persons who develop, maintain, or use electronic record/electronic signature systems have the education, training, and experience to perform their assigned tasks.
(FDA) It is the customer's responsibility to ensure users undergo the appropriate training to ensure correct system operation.
(j) The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures, in order to deter record and signature falsification.
(FDA) It is the customer’s responsibility to ensure suitable policies are in place to allow the use of electronic signatures by the FDA.
(k) Use of appropriate controls over systems documentation including:
(1) Adequate controls over the distribution of, access to, and use of documentation for system operation and maintenance.
(2) Revision and change control procedures to maintain an audit trail that documents time-sequenced development and modification of systems documentation.
(FDA) Product Manuals are available in PDF format on the Elipse E3 CD. All documentation should be controlled in regards to distribution, access and use. Change control procedures should be in place for system documentation.
§ 11.30 Controls for open systems.
Persons who use open systems to create, modify, maintain, or transmit electronic records shall employ procedures and controls designed to ensure the authenticity, integrity, and, as appropriate, the confidentiality of electronic records from the point of their creation to the point of their receipt. Such procedures and controls shall include those identified in § 11.10, as appropriate, and additional measures such as document encryption and use of appropriate digital signature standards to ensure, as necessary under the circumstances, record authenticity, integrity, and confidentiality.
(FDA) It is the customer's responsibility to implement procedures and controls to provide secure applications and data handling in open systems.
§ 11.50 Signature manifestations.
(a) Signed electronic records shall contain information associated with the signing that clearly indicates all of the following:
(1) The printed name of the signer;
(2) The date and time when the signature was executed; and
(3) The meaning (such as review, approval, responsibility, or authorship) associated with the signature.
(b) The items identified in paragraphs (a)(1), (a)(2), and (a)(3) of this section shall be subject to the same controls as for electronic records and shall be included as part of any human readable form of the electronic record (such as electronic display or printout).
(Data Logging) All logged, audit and other electronic data is required to contain the actual username, date and time, and the reason for the operation. All these fields are already part of the audit trail database and electronic signature procedures in Elipse E3, but they need to be included at Filed List for the AlarmServer or any other History files.
Human readable reports should be setup to display the data logged to the secure relational database and are available to be copied by the FDA.
§ 11.70 Signature/record linking.
Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means.
(Data Logging) All logged, audit and other electronic data should contain the security identifier or username (if username is unique between users) that is linked to the operation performed.
E3 security should be used to limit users to areas that they have the appropriate authorization level to access including operation and data logs.
The agency agrees that the word "link" would offer persons greater flexibility in implementing the intent of this provision and in associating the names of individuals with their identification codes/passwords without actually recording the passwords themselves in electronic records.
Subpart C – Electronic Signatures
§ 11.100 General requirements.
(a) Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else.
(Security) This is a standard E3 feature, not allowing the same signature to be used by more than one person.
(b) Before an organization establishes, assigns, certifies, or otherwise sanctions an individual's electronic signature, or any element of such electronic signature, the organization shall verify the identity of the individual.
(FDA) It is the customer's responsibility to ensure that procedures are in place to verify the identity of individuals within the system.
(c) Persons using electronic signatures shall, prior to or at the time of such use, certify to the agency that the electronic signatures in their system, used on or after August 20, 1997, are intended to be the legally binding equivalent of traditional handwritten signatures.
(1) The certification shall be submitted in paper form and signed with a traditional handwritten signature, to the Office of Regional Operations (HFC–100), 5600 Fishers Lane, Rockville, MD 20857.
(2) Persons using electronic signatures shall, upon agency request, provide additional certification or testimony that a specific electronic signature is the legally binding equivalent of the signer's handwritten signature.
(FDA) It is the customer's responsibility to ensure systems undergo the proper FDA validation procedure.
§ 11.200 Electronic signature components and controls.
(a) Electronic signatures that are not based upon biometrics shall:
(1) Employ at least two distinct identification components such as an identification code and password.
(i) When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual.
(ii) When an individual executes one or more signings not performed during a single, continuous period of controlled system access, each signing shall be executed using all of the electronic signature components.
(Security) E3 security should be used which will provide a username and password for each user. For a user to login to the system, they will be required to use both their username and password to gain access. Subsequent system data entries should require only the password entered by the user (this is the signature component that is known only to, and usable by, the user).
Elipse E3 should be set up to logout a user after a time with no user activity and procedures should be used to ensure that users do not leave the terminal unattended during their session.
(2) Be used only by their genuine owners; and
(3) Be administered and executed to ensure that attempted use of an individual's electronic signature by anyone other than its genuine owner requires collaboration of two or more individuals.
(b) Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by anyone other than their genuine owners.
(FDA) It is the customer's responsibility to ensure that electronic signatures are only used by the owner of that signature (login), it is, Elipse E3 cannot assure that the person typing an username and password is exactly the same person.
The agency advises that the intent of the collaboration provision is to require that the components of a non-biometric electronic signature cannot be used by one individual without the prior knowledge of a second individual. One type of situation the agency seeks to prevent is the use of a component such as a card or token that a person may leave unattended. If an individual must collaborate with another individual by disclosing a password, the risks of betrayal and disclosure are greatly increased and this helps to deter such actions.
(FDA) Procedures are required to ensure that attempted use of someone’s electronic signature requires the collaboration of two or more people. If biometrics is used for electronic signatures, then procedures should ensure that they are only be used by the owner of that signature
§ 11.300 Controls for identification codes/passwords.
Persons who use electronic signatures based upon use of identification codes in combination with passwords shall employ controls to ensure their security and integrity. Such controls shall include:
(a) Maintaining the uniqueness of each combined identification code and password, such that no two individuals have the same combination of identification code and password. (Security) This is an E3 standard feature.
(b) Ensuring that identification code and password issuances are periodically checked, recalled, or revised (e.g., to cover such events as password aging).
(Security) Password aging should be used.
(c) Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards, and other devices that bear or generate identification code or password information, and to issue temporary or permanent replacements using suitable, rigorous controls.
(FDA) It is the customer's responsibility to ensure secure handling and control of usernames and passwords.
(d) Use of transaction safeguards to prevent unauthorized use of passwords and/or identification codes, and to detect and report in an immediate and urgent manner any attempts at their unauthorized use to the system security unit, and, as appropriate, to organizational management.
(Security) Unsuccessful logins should be monitored and appropriate steps should be in place to alert management.
(e) Initial and periodic testing of devices, such as tokens or cards, that bear or generate identification code or password information to ensure that they function properly and have not been altered in an unauthorized manner.
(FDA) It is the customer's responsibility to implement procedures to ensure devices are functioning properly and that they have not been altered.
3) E3 Implementation Details
Protecting Elipse E3 Project and Library Files
This operation is intended to be used to protect application files (PRJ and LIB) to unauthorized access. The restriction can be applied for editing (Studio Protection) and/or runtime (Execution Protection).
Picture 1 – Setting studio and execution protection
Defining Database Use and Safety
All E3 information and Data Logging is inserted into one or more Databases. For that, you need to setup into the Domain at least one DBServer object (linked to any supported DBMS, such as Oracle, SQL Server etc.), with a specific username and login. Inside the database, E3 will store several tables, including: Alarm Tables; History and E3 Storage Tables; Formula Tables; User Tables; Audit Trail Tables; and Backup Tables.
Picture 2 – Configuration for DBServer
Adjusting Table Depth and Backup Politics
During History, Alarm, Storage or Audit Trail setup, you'll be asked to define the table depth and backup politics, as shown below.
Picture 3 – Configuring AlarmServer properties
Defining Domain Security
Through the Domain Security options you can define all standard user safety policies, such as expiration, account blocking, minimum password length, and so on.
Picture 4 – Defining domain security options
Creating Users and Groups
Through the Domain – Users option, you can define users and groups for the system. For each user or group you can define or apply the security policies, like expiration, account settings, etc.
Picture 5 – Adding a new user
Picture 6 – Setting group policies
Picture 7 – Setting user permissions for domains
Picture 8 - Setting user permissions for alarms
Picture 9 - Setting user permissions for screens
Defining Audit Trail Configurations and Message Logs
You can specify and set up the system events recording in Domain Configuration – Events Recording options.
Picture 10 – Enabling system events recording
The log messages can be customized in the Event Editor, as well.
Picture 11 – Customizing event messages
Electronic Signatures
This window appears whenever the ESign function is called, allowing the autentication of specific operations.
Picture 12 – Electronic signature dialog
ElipseX Examples using ESign and TrackEvent methods
Generic example
| If Application.IsUserMemberOfGroup("OPERATORS") Then If Application.ESign(Param1, Param2,Param3) = True Then Do_Something Application.TrackEvent "Tag IO.Inputs.I001 changed to 1" End If End If |
Writing a value into a tag
| Sub Button1_Click() Dim Tag, User, Comment Set Tag = Application.GetObject("IO.Inputs.I001") If Application.ESign(Tag.PathName,, "Value Change", Tag.Value, 1, User, Comment) Then If Tag.WriteEx 1 Then Application.TrackEvent "Tag IO.Inputs.I001 changed to 1" End If End If End Sub |
Typing directly in a setpoint
| Sub Setpoint1_Validate(BOOL Cancel) Dim User, Comment Cancel = Application.ESign (Name, , "Value Change", Tag.Value, 1, User, Comment) If Cancel Then Application.TrackEvent "Tag X changed to " & Value End If End Sub |
Inactivity Logout
The inactivity configuration is performed exclusively at the Viewer object. At the Viewer dialog, set the inactivity time (in minutes). To logout the user automatically, you need to insert a small script at the OnInactive event.
| Sub Viewer_OnInactive() Logout(0) MsgBox "You were logged of due to inactivity timeout." End Sub |
4) Conclusion
We believe at this moment Elipse E3 can attend to any kind of process validation against the CFR 21 Part 11. Anyway, new implementations will be released soon, as we will publish new updates of this article. Some of the new features:
- Control of the N last used passwords for each user, so when a password is aged, the user should insert a new one, different from the last N ones he/she had already used.
- Public control of versioning of PRJ and LIB files.
