U.S. Food and Drug Administration

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."


Summary of Requirements
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 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 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):

  • time.nist.gov
    
  • ntp2.usno.navy.mil
    
  • 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 additional 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.

  1. 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.

     Reference Clock
     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.

     Alert Thresholds
     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.

     ---

  2. 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.

  3. 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.

  4. 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 retrieved 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 demonstrate on-demand that any particular machine was synchronized, with what source, and with what accuracy.

     Domain Time II Server and 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.

     Required Configuration Changes to Audit Server
     

     ---

     See Audit Server documentation for configuration details.