Memo of Meeting

Date: June 14, 2001

Location: 1350 Piccard Drive

Rockville, MD

Subject: ProPackData Electronic Recordkeeping System

Representing ProPackData Corporation, Cary North Carolina:

Representing the Food and Drug Administration,

The meeting was requested by Propack Data to discuss the firm’s electronic recordkeeping software in the context of 21 CFR Part 11.

At the start of the meeting we explained that FDA does not formally review, approve or disapprove of products and services that enable people to meet FDA regulations, and that our comments should not be taken as FDA review, approval or disapproval of the Propack Data products.

The firm’s representatives explained that their software, the PMX system, has part 11 functionality and they wanted our input as to their interpretation of the regulations. The representatives gave us a brief presentation, following the attached PowerPoint slides.

The representatives explained that ProPack Data is based in Germany, with branches in the U.S., France, Italy, and the U.K. About 85% of the firm’s customers are pharmaceutical producers, many based in the U.S.; the firm also has customers in the food and biotechnology industries. The firm’s core product, PMX integrates activities in product research, production, and quality control. The representatives gave us a broad overview of the product architecture, key modules, and how it interacts with other applications such as Oracle and SAP. PMX operates on Windows NT, Unix and Oracle platforms.

During the meeting we discussed the firm’s approach to software validation. The representatives explained their two step approach that includes pre-validation of a standard package and validation of the customer’s system. Program modules are included in the customer’s system per the customer’s requirements; functionality is mapped to program modules, dependencies among modules are taken into consideration, and test plans are developed. Validation documentation and customer test scripts are developed, including interfaces to customers’ other systems. Design qualification documentation is held under third party escrow, although documentation of installation, operation and performance qualification is provided. The firm accepts customer audits and participates in the PDA software vendor qualification program (Technical Report 32.)

We reviewed several part 11 technical requirements and how the firm intended to have its software meet them. These include authority checks, audit trails, sequencing checks, archiving, electronic copies of electronic records, electronic signature manifestation, electronic signature components and controls for identification codes used together with passwords.

With respect to electronic copies of electronic records, the system generates Adobe PDF files. We commented that to be suitable for our use electronic copies need to be in a format that permits us to process (e.g., search and sort) information. Thus, a PDF file of a table or spreadsheet would not meet this need, although a word searchable text file may meet this requirement.

Electronic records are archived in electronic form; PDF is used for long term storage. We commented that, here too, archived records need to be in a form that permits content to be processed and electronic signatures to be verified. The representatives commented that to their knowledge none of their customers has, in fact, exercised the software option that compresses the archive to an unprocessable form.

Regarding access restrictions, the representatives explained that the software provides for configurable access according to user profiles.

Concerning password security, the system requires a password length of at least six characters, at least one of which must be a number or a special character. The program also allows system managers to restrict password reuse and configure password expiration periods. In addition, the program is structured such that system administrators do not know user passwords.

System lockouts during periods of end user inactivity can be configured and failed log in attempts are recorded. However, the system does not report in an urgent manner, attempts at system compromise; instead, security personnel must review a log to determine potential threats. If logs are not reviewed frequently enough, a security breech could go undetected for a period of time. The representatives explained that in future revisions of the program they will include a feature to send an e-mail message to designated security personnel when such events occur.

Regarding audit trails, the program provides for time stamped automatic recording of operator actions that create, delete or modify an electronic record. Altered information is preserved in separate fields. The audit trail identifies operators by their log in names. A field provides for recording the reason for a change. We commented that part 11 does not require the audit trail to record the reason why a record was changed, although a predicate regulation may require recording that information in the trailed record itself. The representatives explained that prior to software delivery, end users may specify that the audit trail be deactivated for certain fields; de-activation would be "hard coded" and thus end users could not reactivate the audit trail. We objected to this practice, and explained that it would be too easy for a customer to inadvertently turn off audit trailing for a field that, per FDA requirements, must be audit trailed. The representatives said that the list of non-audit trailed fields would be included in the end user’s functional list. Electronic copies of audit trails are exportable in PDF format; we commented that, as explained above, this may not be acceptable if information in the audit trail could not be processed.

We discussed changes to electronic records and suggested that an auditor should not have to comb through a separate audit trail to determine if and how an electronic record was altered. We commented that there should be some flag or indication of change in the trailed record itself.

The program allows managers to configure and enforce event sequencing, so that, for example, elements in a pharmaceutical batch production record are completed in the proscribed order.

Manifestations of electronic signatures include the signer’s printed name, date and time of signing and the meaning of the signature. The meaning is either explicitly stated or inferred from the record’s content.

Electronic signature to record linkage is attained through the database structure.

The meeting concluded after about two hours.

DOC ID: ProPackDataMemo of Meeting061401d.doc

P. Motise 07/11/01

cc: HFA-224

HFC-200

FDA Meeting Attendees

Part 11 Guidance Dockets