Source: http://www.greyware.com/software/domaintime/instructions/quickstart/regulatory-fda.asp
Timestamp: 2013-05-26 04:50:00
Document Index: 601258392

Matched Legal Cases: ['art 11', 'art 11', 'art 11', 'art 11', 'art 11', 'art 11', 'art 11', 'art 11', 'art 11', 'art 11', 'art 11', 'art 11']

Domain Time II Installation: Regulatory Compliance with FDA 21 CFR Part 11 Time Stamp Regulations
Home Products Store Downloads Customer Service Search Log in or Create an account now -- FREE! Domain Time II > Instructions > Quickstart > Regulatory Compliance - FDA 21 CFR Part 11
Documentation\Installation\Regulatory Compliance\FDA 21 CFR Part 11
The U.S. Federal Drug Administration (FDA) has has adopted wide-ranging regulations governing activities in the life sciences industry.
Among these are regulations regarding the use of electronic records and electronic signatures, contained in 21 CFR Part 11 of the Federal Register.
Note: The Domain Time II documentation includes useful baseline information for use in "black box" testing for use on your validated systems. See Resource Impact Statement for more info.
Implicit in these regulations is the expectation that systems used in producing electronic records or signatures must have the correct date and time so that time stamps produced are correct and verifiable. Extracts of the applicable sections of the Rule, current FDA Guidance to Industry memos, as well as relevant commentary from private industry that help define the time stamp requirements follow.
21 CFR Part 11 Final Rule, March 20, 1997 Section 11.10 Controls for closed systems specifies:
"(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. Such audit trail documentation shall be retained for a period at least as long as that required to for the subject electronic records and shall be available for agency review and copying."
Draft Guidance for Industry on Part 11, Electronic Records, Electronic Signatures - Scope and Application:
Section III. C. 2. Audit Trail
"Even if there are no predicate rule requirements to document, for example, date, time, or sequence of events in a particular instance, it may nonetheless be important to have audit trails or other physical, logical, or procedural security measures to ensure the trustworthiness and reliability of the records."
Draft Guidance for Industry: Computerized Systems Used in Clinical Trials:
IV. Standard Operating Procedures, Data Entry, Section B. Electronic Signatures
"2. Personnel who create, modify, or delete electronic records should not be able to modify the audit trails."
"5. Audit trails should be created incrementally, in chronological order, and in a manner that does not allow new audit trail information to overwrite existing data in violation of �11.10(e)."
IV. Standard Operating Procedures, Data Entry, Section C. Date/Time Stamps
"1. Controls should be in place to ensure that the system's date and time are correct."
"2. The ability to change the date or time should be limited to authorized personnel and such personnel should be notified if a system date or time discrepancy is detected. Changes to date or time should be documented."
Four basic requirements regarding time synchronization for FDA regulatory purposes can be derived from the above: Time and Date on Systems Must Be Correct
Standard best practices to ensure the time and date on all computer clocks is correct is to verify they are reliably synchronized to a commonly used time standard, such as provided by the National Institute of Standards and Technology (NIST) or United States Naval Observatory (USNO) atomic clocks, or Stratum 1 time sources such as GPS receivers.
Ability to Change the System Clock Must Be Restricted
Users must not be allowed to change the time on systems at will.
Alerts to System Date/Time Discrepancies Must Be Generated
Administrators must be notified immediately of problems with the time on systems.
An Audit Trail to Demonstrate the Validity of Time Stamps Must Be Maintained
The accuracy of the date/time used to produce time stamps is integral to proving the trustworthiness and reliability of all electronic records and signatures. Non-modifiable records of the the generation of time stamps (including the time synchronization process) are essential.
How to Use Domain Time II to comply with the FDA 21 CFR Part 11 Requirements
Domain Time II meets or exceeds all of the guidance and directives detailed above. Properly configured,
Domain Time will allow you to easily comply with all current and proposed requirements to assure the validity of the date and time of time stamps and related audit requirements.
Domain Time II is designed specifically to provide both accurate time synchronization and a complete history of that synchronization. Each Domain Time II time sync component (Servers and Clients) have the ability to keep detailed logs and statistics of their own activity - and, critically, to report that information automatically to monitoring and auditing systems when requested.
This diagram shows the basic structure of the Domain Time II system, showing how time synchronization and audit data collection are handled.
Configuring for compliance
These are the steps necessary to use Domain Time II to assist in compliance with FDA 21 CFR Part 11:
Requirement: Time and Date on Systems Must Be Correct
Solution: Configure Domain Time II to provide accurate time sync to all clocks
Domain Time II, when installed according to the instructions found on the Recommended Configurations page of the Domain Time II documentation, will meet the FDA 21 CFR Part 11 requirements for time synchronization. However, there are a few additional configuration considerations beyond the standard recommend installation instructions for FDA 21 CFR Part 11 compliance.
Required Configuration Change
Set the Domain Time II Master to use NIST, USNO, or other reliable Stratum 1 system as its time source: Use the Time Sources tab page of the Domain Time II Server Control Panel Applet to include any of the following entries in the Sources fields (in any order):
The IP address or DNS name of a Stratum 1 source, such as GPS receiver
Requirement: Ability to Change the System Clock Must Be Restricted
Solution: Domain Time II Server and Clients have a function called Clock Change Monitor that prevents users without administrative rights from changing the time on their systems. This function is enabled by default. No additonal configuration is necessary.
Requirement: Alerts to System Date/Time Discrepancies Must Be Generated
Solution: Use Domain Time II Audit Server (see below) or Monitor Service
to provide alerts when time variance on systems exceeds the thresholds you set.
Requirement: An Audit Trail to Demonstrate the Validity of Time Stamps Must Be Maintained
Solution: Use Domain Time II Audit Server to collect and preserve tamper-proof audit records
Domain Time II has exceptional built-in functionality to easily and automatically provide an audit trail of time synchronization. The following steps will provide unimpeachable records of the state of time synchronization. You will know exactly when your changed, why, when, and with whom they synchronized.
Set Reference Clock and System Alerts.
Domain Time II Audit Server has the capability to generate alerts when any monitored system's variance from a reference clock exceeds a threshold you set. Warning entries of these events are also included in the logs.
Audit Server can compare the sampled time of any audited machine to a reference clock. The reference clock's time is used to calculate certain variances and alerts. By default, Audit Server automatically locates the nearest Domain Time II Server to use as its reference clock. Since OATS specifies that variances by shown in relation to NIST, the reference clock setting must be changed.
Audit Server has the ability to generate an alert if the time variance on any system exceeds a particular threshold.
The OATS-specified requirement is that the log for any machine drifts outside 3 seconds from NIST time should include a notice to that effect. Audit Server will automatically add a warning to the log when any machine exceeds the Any machine time off by... setting on the Audit Server Alerts & Logs tab page.
Required Configuration Changes to Audit Server
Set the Reference Clock to NIST: Go to Audit Server's Advanced tab and change the Reference Clock setting to use time.nist.gov (note, you must have the NTP port 123 UDP open on your firewall to allow Monitor to contact the NIST time server). Set the Alert Threshold: On Audit Server's Alerts & Logs, make sure the Any machine time off by setting is set to 3 seconds.
Set Audit Record Collection and Retention Options
Use Domain Time II to collect audit data and archive as necessary.
The Domain Time II Audit Server automatically collects detailed time synchronization data from the network. Data can be kept in local storage for the required three year period, or archived off to permanent offline storage as necessary. Document procedures
Use Domain Time II documentation as necessary to write your procedures and as a baseline for your "black box" system validation testing.
Domain Time II is thoroughly documented, and the behavior of the Domain Time II system and each time component and how it synchronizes is detailed in the Technical Information and Configuration and sections of the online documentation. These documents can be used to provide any level of detail of the system operation for compiling your documented procedures.
In particular, the Resource Impact Statement contains a great deal of useful material as a starting point for "black box" testing of Domain Time II for use on your validated systems.
Optional: Keep Detailed Logs of every time a clock is synchronized and the results of that synchronization
Use Domain Time II Audit Server to collect the synchronization logs of all machines.
See the Audit Server documentation for details on configuring and using Audit Server. Domain Time II Audit Server is capable of collecting a log of time sync activity from Domain Time II components into a central location for easy analysis and archiving. Information retreived includes when a sync occurred and with whom the component synced, and amount the clock was corrected. Log retention is configurable to match archival schedules.
Audit Server also keeps an audit record which can be used to demontrate on-demand that any particular machine was synchronized, with what source, and with what accuracy. Domain Time II Server and Full Client also keep a local log that includes not only time sync events, but all other events activity and events by the component. These logs can be manually collected and archived to meet the log retention requirements,
however doing so is typically much more complex than using Audit Server to do so, and results in significantly larger log files to be archived. In most cases, using Audit Server to collect sync logs is optimal.
See Discovery documentation for details on these steps.
Add all broadcast subnets: If you want Audit Server to use broadcasts to discover machines to audit, enter the broadcast addresses for all subnets on your network where Domain Time II components are deployed to the Broadcast Addresses section of the Advanced tab page. Collect Machine Lists from all Domain Time II Servers: If you want to automatically contact all machines that synchronize with Domain Time II Server, enable the and enter all Domain Time II Servers to be contacted to the Servers... dialog.
Manually Enter Other Machines:Use the Audit Server Audit List tab to manually enter any machines not automatically discovered by the methods above.
Enable Central Log Collection: Use the Discovery tab page of Domain Time II Audit Server to collect Time Synchronzation logs. Choose retention settings that correspond with your archival processes to ensure that all logs are transferred to archival storage before being deleted from the Audit Server.
21 CFR Part 11 Final Rule, March 20, 1997
Draft Guidance for Industry on Part 11, Electronic Records, Electronic Signatures -Scope and Application, February 2003
Guidance for Industry: General Principles of Software Validation;Final Guidance for Industry and FDA Staff, January 11, 2002
Guidance for Industry: Computerized Systems Used in Clinical Trials, April 1999
This document is provided for informational and planning purposes only. The information using in compiling this document was obtained from publically available sources and no representation is made as to the accuracy of the information, nor as to the accuracy of any reading or interpretation thereof. No warranty is made or implied regarding the the usefulness,or suitability of this information for a particular purpose. Further, Greyware Automation Products, Inc. is not liable for any damages, real or
consequential, arising from use of this information.