Let me establish the scenario: Our hypothetical LIMS software is a closed system called Squirrelly LIMS (patent pending) and our user, Sue, is in charge of record keeping for instrument cleaning, a job that she enjoys very much. Of course, everyone in the company knows that Sue's job satisfies 21 CFR §211.68(a) and 211.182, which qualifies Sue for additional stock options and rounds of "For She's a Jolly Good Fellow" at company picnics. Fortunately for Sue, Squirrelly's vendor overreacted at the end of the last millennium so Squirrelly was upgraded to include scheduled instrument self-cleaning while running off a gas generator (it's a very robust LIMS) whose output can automatically be sent Sue's email address. Sue's plan is to receive the self-cleaning results via email, print the entire email as a "true copy" according to 211.180(d), initial and date (just to be thorough), and retain the hardcopy for a period specified by 211.180(a). Life is good until Sue's boss finds out about the plan and puts the kibosh on the whole email thing, since IT has not validated the Microsoft Exchange server and the Internet is rumored to be lurking with vicious woodsmen called "The Hackers."

In defense of the boss, I concede that these emails represent "records" as defined by 21 CFR §11.30/11.1: "text...in a digital form that is...distributed by a computer system," and that "this part applies to records that are created...or transmitted, under any records requirements." Since we've already identified that Sue's job satisfies 211.68(a), that means that she's fulfilling a predicate rule, and her emails must be Part 11 compliant.

Since I like Sue, I really want to help her out, so let's look at some ways an email might fail Part 11 compliance so we can address each of them:

1. Sue's emails might get lost when the "I Love You " worm takes out IT's email servers. This pertains to 211.10(a), which requires reliability.
2. The results in Sue's email might get modified when the "I Love You" worm attempts to add a malicious payload. This pertains to 211.10(a), which requires accuracy and the ability to discern altered records.
3. While the email servers are being reconstructed, Sue's emails may be temporarily re-routed through IT's gaming servers in the back room. This pertains to 211.10(a), which requires system validation to ensure accurate and consistent performance (for something other than fragging virtual opponents).
4. After reconstructing the email servers, IT may inadvertently start sending Sue's email to another individual that lacks the education or training do Sue's job. This pertains to 211.10 and 211.10(i), which requires that a person executing a task is qualified and that records can be kept confidential.

To summarize, we're dealing with issues of reliability, accuracy, consistent and controlled performance, and confidentiality. In order to analyze possible solutions, let's group failures 2 and 4, and failures 1 and 3.

Both accuracy and confidentiality can be addressed using encryption on the email server and client. Verisign, a world leader in digital certificates, offers options for both individual and corporate environments. PGP, a world leader in encryption technology, also provides solutions for individual and corporate environments. Regardless of which product is chosen the basic technology is the same: When the email is sent, it is encrypted using Sue's public digital certificate, which renders the contents of the email unreadable to humans and computers without a secret decoder ring. When the email is received, Sue provides her private key - typically a password or a private digital certificate file - which allows her to open and read the contents of the email. She can also use the encryption software to let her know if a single character of data has been modified since the time it was sent to the time it was opened. Further, email encryption software typically does not allow the modification of data after being received, so even venerable Sue cannot modify the email by accident. Of course, since we've introduced additional software into the system, we also introduce more validation testing.

Solving possible reliability failures, especially when those failures can occur on systems that have not been validated, may be more complex. Let's be objective and ask what seems to be an obvious question, "Does a closed system need to have every computer system validated." The answer is no. The Part 11 Scope and Application guidance document gives an example in section C.1, "validation would not be important for a word processor used only to generate SOPs." However, that same section also instructs "that your decision to validate computerized systems... [should] take into account the impact those systems have on your ability to meet predicate rule requirements." Well, that cinches it; since Sue's job helps her company fulfill a requirement from section 211, her email solution must be validated.

Sue has three options: bring all of IT's email services under the umbrella of the her validation group (I should be hearing hysterical laughter about now), attempt to coerce IT to start operating its email systems under the auspices of Part 11 (more hysterical laughter), or treat the entire email system as an open system. The first two options I'm going to discard as impractical (okay, ridiculous), so let's look at what remains.

Title 21 Part 11.30 specifies that an open system be 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." Further, such controls shall include "additional measures such as document encryption." Whoo Hoo! Sue does the happy dance. Since we've already chosen to implement document encryption to solve accuracy and confidentiality, the same encryption can be used to solve the potential failures of reliability and controlled performance as long as we explicitly define the email notification system as an open system.

At this point, I do a lot of gesticulating: developers dash around installing this and that, technical writers scurry to create validation plans and performance testing procedures for emails sent over the open network to Sue's office desktop, and Viola!, Sue has an email notification system that is reliable, accurate, confidential, consistent, and provides controlled performance as an open system under federal guidelines. Now, you may think to yourself, "That's all fine and good, Jeff, but you never really solved potential failures #1 and 2; the 'I Love You' worm may still destroy Sue's records and take out IT's email servers." Sadly, true. Fortunately, neither CFR parts 211 or 11 require a system to be perfect, it requires that systems be controlled and perform satisfactorily. If the system can be tested to assure consistent and accurate performance, and if that performance can be documented, then Sue's boss will be satisfied, and company picnics will again sing her praise.