Focus on Quality — Validation of Spectrometry Software: Importance of Accurate Date and Time Stamps

When you write up your observations and notes in a traditional laboratory notebook, there are a number of features that help to ensure data integrity. The notebook pages are numbered sequentially and they are bound together. Therefore, if a page is removed, it is obvious immediately. When recording observations in the notebook, the order of the write-up is important and is enforced by the sequential or linear pagination of the notebook. The author signs and dates the recorded information and this is witnessed by a second person, who signs and also dates when they reviewed the work. Note that it is not usual to time and date signatures in a laboratory notebook.

R.D. McDowall

Working in an Electronic Environment

In converting from paper to electronic work, there is not the same linear sequence that occurs in the paper world as the records generated are based around the application software operation. The workflow of the computerized system will define the way that the software works, but users can do many things within this. For example, a data system for a spectrometer can be used to set up the data acquisition parameters, acquire data from the sample, and then process the data to produce results. However, once data have been acquired, a user can review, interpret, and process a spectrum several times before a result is finally accepted. Because of the speed of computers, there is a need to record both the time and the date of any event in the system, typically down to a faction of a second.

The files and results (both electronic records) produced by a computerized system usually will not be arranged in the linear sequence seen in the laboratory notebook. If you are unlucky, they will be stored in directory structures, which might mean you have to employ file-naming conventions to organize the data. If you are lucky, the system is organized via a database and most of this work is done for you behind the scenes. To capture all creations, modifications, and deletions to data there is an audit trail that acts as the mortar linking all the bricks together to build up the time sequence of events.

However, fundamental to the operation of the software application and the audit trail is an accurate and precise time and date stamp. Without this it will not be possible to:

• Link a time and date stamp to any electronic record (for example, file creation, records modification, and so forth)

• Build up a logical sequence of events

• Establish the integrity of records and actions

Importance of Accurate Time and Date Stamps

It cannot be emphasized enough that an accurate and controlled time and date stamp is the cornerstone of data integrity within the laboratory and throughout the organization. Without it, you have a situation where you cannot trust anything generated by any computer. ISO Standard 17799 (1) on Information Management Security in section 9.7.3 discusses Clock Synchronization:

"The correct setting of computer clocks is important to ensure the accuracy of audit logs, which may be required for investigations or as evidence in legal or disciplinary cases. Inaccurate audit logs may hinder such investigations and damage the credibility of such evidence.

Where a computer or communications device has the capability to operate a real-time clock, it should be set to an agreed standard, e.g. Universal Coordinated Time (UCT) or local standard time.

As some clocks are known to drift with time, there should be a procedure that checks for and corrects any significant variation."

This is not a pharmaceutical or healthcare regulation but a general standard for any computerized system operating in any organization. You do this because it is good business sense to do so, not because the regulations say you should. Moreover, in a research environment where spectrometry data supports a patent registration, accurate time and data stamps are important to establish priority in the event of a competing patent application.

Everyone Believes Computers, Don't They?

Of course, there is a generally accepted view that when something is performed by computer it must be true simply because the computer says so. In 1990, the U.S. Environmental Protection Agency (EPA) commissioned a report by Hamilton Booz Allen to investigate computer practices by environmental laboratories that reported data to the Agency (2). The use of a third party was significant, as strict anonymity was promised to all contributors — when you see some of the results and working practices in this report, you'll know why. Dubious is one word to describe them; fraudulent is another. As we are concerned with time and date here, we'll focus on just a single feature – time traveling; analysts found that they could travel in time, although it was limited to hours and minutes.

There are some EPA analyses where time is a critical issue: the sample must be taken and delivered to the laboratory within 6 h. If the sample arrives after this time it must be rejected and a new one taken. However, in a laboratory with a laboratory information system (LIMS) used for sample reception, it is a relatively simple task for a system manager to flip the clock back a few minutes. When the sample was received using the LIMS, though, the time of sample receipt was within the 6-h time window allowed by the EPA. If inspected, the computer says so and must therefore be right.

21 CFR 11 and FDA Guidance Documents

The FDA also is interested in time stamps for the same reasons that ISO is: to ensure that any data and electronic records generated by any computerized system such as a spectrometer data system are trustworthy and reliable. Time stamps have been on the periphery of the regulation since the publication of 21 CFR 11 in 1997 (3). Originally, in the preamble to the 1997 regulation, there was a note that time should be local to where the signer was. However, this gave rise to a little problem for systems working across time zones — it was technically impossible. The time stamp for data originates at the server where the data are stored rather than at the client where the data is generated. If the server is located in a different country, you get a different date and time stamp compared to where you are located.

In a draft Guidance issued in 2001 (4), the FDA changed their stance and stated that systems have to be implemented with a clear understanding of where the time stamp is located. In 2003, in the Part 11 Scope and Application guidance, the FDA stated as a footnote:

"Although we withdrew the draft guidance on time stamps, our current thinking has not changed in that when using time stamps for systems that span different time zones, we do not expect you to record the signer's local time. When using time stamps, they should be implemented with a clear understanding of the time zone reference used. In such instances, system documentation should explain time zone references as well as zone acronyms or other naming conventions" (5).

If time and date stamps are so fundamental to data integrity, you might ask, why then is this not a fundamental part of the Part 11 regulation? When the FDA issues the new draft Part 11 — possibly sometime this year or next — perhaps time stamps will be raised from a footnote to an integral part of the regulation.

FDA Guidance on Time Stamps

The FDA issued a draft guidance for industry on time stamps (4) in March 2002 and then withdrew it in February 2003. Notwithstanding the withdrawal, this guidance has good useful information and the key points and discussions for spectrometer applications are:

• The time stamp needs to be accurate to "within a minute;" this is best interpreted as ± 1 min.

• The location of the time stamp must be defined. For a system working on one site, this is not an issue and is pretty self-evident. However, if you share data between sites in different time zones, then this is critical. Knowing how the system handles times is the key issue here. In the final version of the Part 11 Scope and Application guidance, there is a footnote that confirms that the FDA still wants the location of the time stamp to be defined (5).

The guidance makes no reference to summer and winter daylight savings or to leap years. Typically, these changes will be managed by the operating system, which requires an accurate time and date stamp setting and you might want to check that these have occurred the next working day after the event.

Issues for Time and Date Stamps

Because it is fundamental to electronic record integrity regardless of the laboratory you are working in, we need to consider the following issue with time and date stamps:

• Accuracy of the time stamp

• Format of the time stamp

• Identification of the time zone and the impact of a data system working across different time zones

• Unambiguous date format

• How is the time and date checked? This can be a combination of procedural and technical means. In addition, who is authorized to make changes to the date and time, and, as a corollary, who is not allowed to make changes to the time?

Time and Date Stamps and Their Format

If presented with a date of 05/09/04, what does this mean? It depends where in the world you are and what date format you use. This date could have three meanings:

1. September 4, 2005 (based upon an ISO standard for date and time that starts with the largest part, the year, and works down)

2. September 5, 2004 (based upon a European use of date abbreviations)

3. May 9, 2004 (based upon an American date format)

An unambiguous date format therefore is required, especially in multinational companies where U.S. and European scientists are working. Personally, I prefer the U.S. military date format (DD MMM YYYY), which means that there is no possibility of confusing the day and month because the month is spelled out, as in 04 SEP 2005. Another alternative is to implement long date formats in the operating system and software application. Here the date format is presented as September 04 2005.

Format of the time stamp is another issue that should be considered. There are a number of possibilities, and sometimes the seconds can be recorded to 1/100th of a second. Do you use a 12- or 24-h clock to record the hours in the time portion of the stamp? Regardless of your approach, the time and date format must be documented in your user requirements specifications (6).

Time stamps for standalone systems.

Time stamps for standalone spectrometry systems probably are best set and maintained manually. Although there are technology options, they will be relatively expensive to implement on a number of individual workstations. Therefore, you'll need a manual procedure with records to show that the time stamp has been checked and maintained against a standard time source (for example, a speaking clock or another reliable time source). How often you will need to check the time stamp will vary. As a suggestion, start on a monthly basis for the first six months, then review how accurate the time stamp has been over this period and whether you have needed to adjust the clock. You then can lessen the frequency if necessary on the basis of experience. You will need to maintain a log of who checked the computer clock, the computer time, the standard time, and whether any adjustment was made. This approach can be a waste of time and resources, especially when coupled with the need to manually backup individual systems. Ideally, all standalone systems should be networked to ensure that time stamps are maintained from a single source within the network.

Time stamps for networked systems.

This is by far the easier and preferred option for setting and maintaining time stamps. Within your IT network, a server provides the time stamps for all other severs and workstations. At a minimum, each time a user logs on to the network from a workstation, the time stamp is updated automatically. The operating system also can be set up to update the timestamp during the time that a workstation is logged on (for example, hourly, if required).

Trusted time sources are available to check and correct the network clock automatically; this can occur in a number of ways:

• Network Time Protocol (NTP), in which the time server accesses a time source on the Internet.

• Time sources from the National Observatories of some countries (for example, the U.S. Naval Observatory has atomic clocks in Denver and Washington; there is the Frankfurt atomic clock for Europe; and the U.K. has a source at Rugby).

• Global positioning satellite (GPS) systems also can provide a universal coordinated time signal that can be used with the appropriate equipment to provide a check of server time.

The time signal then is interpreted by the operating system to the local time zone and any daylight saving that has been implemented. Suggested checks of the time setting could be limited in these cases to seeing whether daylight savings, if implemented, has occurred every spring and autumn and if leap years have been incorporated every four years.

Validation Issues for Time and Date

Some of the issues surrounding date and time that you must consider when you are validating a spectrometer data system are:

• Define the time zone and format and date format in a user requirements specification (URS) or equivalent document. Include in this the time zone reference such as EST: Eastern Standard Time or GMT: Greenwich Mean Time.

• You also should note if the operating system is enabled for automatic summer and winter time daylight saving. There is a slight problem here for global systems operating between North America and Europe. Daylight saving is the same in the autumn when the clocks go back; however, there is a week difference when they go forward: Europe goes forward at the end of March and North America does this a week later in early April.

• The specifications for the system should state how the time is set and a procedure should say if is checked either automatically via a trusted third party or by an operator. Even for clocks that are linked to trusted third parties, there should be an occasional check to ensure that all is in order. But who can do this should be defined and how the check is recorded and documented.

Summary

Time and date are important elements of data integrity for all spectrometry laboratories, and having accurate and reliable date stamps will give confidence in data and their integrity produced by a system.

R.D. McDowall is principal of McDowall Consulting and director of R.D. McDowall Limited, and "Questions of Quality" column editor for LCGC Europe, Spectroscopy's sister magazine. Address correspondence to him at 73 Murray Avenue, Bromley, Kent, BR1 3DJ, UK.

References

1. International Standards Organisation, ISO Standard 17799: Information Management Security, Geneva, 2000.

2. H.B. Allen, Computer Working Practices in Environmental Laboratories, 1990.

3. U.S. Food and Drug Administration, Federal Register 62, 13430 (1997).

4. U.S. Food and Drug Administration, Withdrawn Guidance for Industry: 21 CFR Part 11; Electronic Records; Electronic Signatures Time Stamps, 2002.

5. U.S. Food and Drug Administration, Guidance for Industry: 21 CFR Part 11; Electronic Records; Electronic Signatures Part 11 Scope and Application, 2003.

6. R.D. McDowall, Validation of Chromatography Data Systems (Royal Society of Chemistry, Cambridge, 2005). ?