This document describes how to use the LabVIEW Datalogging and Supervisory Control (DSC) module to develop an application that is compliant with the FDA 21 CFR Part 11 regulation, which covers electronic signatures and electronic records. In the past, most data gathering was done by hand, and the FDA required that these documents contain the written signature of the person that generated it. Now, almost all data is recorded on computers. The 21 CFR Part 11 regulation delineates how data should be stored electronically and how electronic signatures should be applied to this data. The complete regulation is available to view at www.fda.gov.
In addition, you can download from the NI Developer Zone detailed instructions on programming a 21 CFR Part 11-compliant application and a complete LabVIEW example, 21 CFR Part 11 Application Example that complies with the 21 CFR Part 11 requirements.
With LabVIEW and the DSC module, you can easily create applications that are compliant with FDA regulation 21 CFR Part 11. LabVIEW is a graphical development environment with built-in functionality for data acquisition, instrument control, measurement analysis, and data presentation. LabVIEW provides the flexibility of a powerful programming language without the complexity of traditional development environments. The DSC module is an add-on module for the LabVIEW development environment that offers data management tools, such as easy-to-use I/O configuration for high-channel-count applications, automatic data logging, full alarm management, event logging, and real-time and historical trending. Also, with easy networking, a networked real-time database for distributed logging, built-in security, and OPC connectivity, you can use the DSC module to get your application up and running easily and quickly.
LabVIEW and the DSC module are not 21 CFR Part 11-compliant applications but are design tools you can use to create 21 CFR Part 11-compliant applications. This document discusses how you use the DSC module to create an application that is compliant with the 21 CFR Part 11 regulation. Each relevant section of the 21 CFR Part 11 regulation is listed below, followed by a detailed description on how to meet this requirement using the DSC module.
(a) 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 questions regarding the ability of the agency to perform such review and copying of the electronic records.
The DSC module writes all its records to an SQL-compliant historical database. You can make SQL queries from various software applications, such as Access and Excel, and present the data from these applications. Refer to the tutorial, "Accessing Citadel Data from Other Software," from the NI Developer Zone on ni.com/devzone for information about how to query the database. In addition to presenting the data from one of these applications, you can use Measurement & Automation Explorer (MAX) to view the historical data.
(b) Protection of records to enable their accurate and ready retrieval throughout the records retention period.
The DSC module historical database protects the records from being altered or modified. You can make SQL queries to view the data, but you cannot change the data. In addition, to prevent data loss, you must ensure that the file directory in which the database resides is kept intact by using a variety of security software, including the native security available with most Windows operating systems.
(c) Limiting system access to authorized individuals.
The DSC module is password protected. You can limit system actions to individuals with specified user names and passwords. Also, a user with administrator access must log in to be able to access the User Account Manager, which controls the access of all users. You also can programmatically restrict use of the applications to users who are logged into the system.
(d) 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 copy.
With the DSC module, you specify which information you want to log to the database. Data you write to the database includes a timestamp. Changes to the value you log to the database do not overwrite previous values. The database records the new value as a change in the value, to ensure the integrity of the audit trail. You can keep the historical data and its corresponding audit trail as long as you want, limited only by disk space.
(e) 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.
The DSC module has a login feature that developers can use to limit access to any feature of the application. The login can cover anything inside the DSC module application. The operating system or another security program needs to protect anything outside of the LabVIEW environment. For example, you can use the Windows login to protect your files.
(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.
You can programmatically get the printed name of the signer and log this information to the database.
(2) The date and time the signature was executed.
The date and time is attached to all data logged to the database.
(3) The meaning (such as review, approval, responsibility, or authorship) associated with the signature.
You can design the application so that when a user applies an electronic signature, he/she must choose the meaning of the signature from a list, such as review, approval, responsibility, or authorship. The DSC module can write these meanings to the database 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 or printout).
All the information in part (a) of this section is written to the database. Therefore, you can use SQL queries or MAX to retrieve it in the same way you can retrieve all other data written to the database.
(a) Each electronic signature shall be unique to one individual and shall not be reused by, or reassigned to, anyone else.
The DSC module currently permits only unique logins. If you disable all accounts after they expire, you can ensure no duplication or reuse of the account names.
(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.
The DSC module has a sign-in that requires a user name and password. You can invoke the sign-in programmatically in your application.
(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 by, the individual.
You can programmatically invoke the DSC module login to require a user to provide user name and password before granting access to the system. You also can get the user name programmatically, so you can require a user name for a subsequent signing.
(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.
The DSC module includes a function to programmatically log out a user. In addition, you can design your application so that a user clicks a button to log out if he/she needs to leave the system. The DSC module also has an automatic logout feature. You can configure a time period of inactivity after which the user is automatically signed out to ensure that the system is vulnerable only for the amount of time you set. Once users sign out, they must provide their user name and password to access the system again.
(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.
Along with unique login names, the DSC module includes a feature to disable a user account after a specified number of consecutive failed login attempts. The administrator can specify how many consecutive failed login attempts will lock out a user name. Once the account is disabled, users cannot use that account to access the system until an administrator enables the account again.
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.
The DSC module requires unique user names.
(b) Ensuring that identification code and password issuances are periodically checked, recalled, or revised.
With the DSC module, the administrator sets the amount of time a password is valid. After this time period, the user account is disabled until the administrator changes the password.
(c) Following loss management procedures to electronically deauthorize lost, stolen, missing, or otherwise potentially compromised tokens, cards or password information, and to issue temporary or permanent replacements using suitable, rigorous controls.
Although it is ultimately the responsibility of the developer to implement procedures to ensure that this regulation is met, the DSC module provides you with some tools to help. The locking out of user names that fail consecutive logins can help to identify a compromised user name. Also, the administrator can deactivate any user name and can add a new temporary user name and password if necessary.
(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.
The user lockout feature after a specified number of consecutive failed logins is a safeguard against unauthorized access to the system. In addition to this feature, you can log any failed login in a system file that the administrator can monitor to be notified of the failed events.
Related Links: