Computer system document

Design, development, and system build is normally a period of intense activity, in which a supplier will be involved in life-cycle activities and will need to provide a set of auditable design and development documentation to support the validation program. For this, the entire design and development process should be carried out to written and approved procedures, and all design, development, testing, and verification activities should be documented and approved in order to provide a level of computer system documentation that can be used to support the pharmaceutical manufacturer s life-cycle qualification activities. 

Computer system documentation means records that relate to system operation and maintenance, from high-level design documents to end-user manuals. Sidebar 11-1 illustrates some typical SLC documentation. In the software-engineering context, computer systems documentation is regarded as software. All regulatory provisions applicable to software are also applicable to its documentation. 

Computer system documents are generated during the project. These documents may be either printed material or electronic records, such as computer files, storage media, or... 

Computer system documents, which support system validation, are submitted for retention to the appropriate document control area and retained for a period at least as long as specified by the predicated regulations applicable to the system. 

Computer system documents contain the following elements. 

The completion of computer systems documentation should follow a set of predefined rules as follows ... 

This brings to mind another common problem. SOPs must be readily available in areas where GLP work is conducted. Protocols also must be accessible. Even when these documents exist only in electronic form, they must still be available, especially in the laboratory and study rooms. This means that computer systems that contain these documents must be available in the laboratory and study rooms and that all personnel who conduct work according to these SOPs must have access. The same is true for protocols and protocol changes. In cases where a merged system exists, i.e., both paper and electronic media are simultaneously in use, it is perfectly acceptable that only the electronic form is available in the laboratory areas while electronic or paper documents are available in offices. The only caveat is that a process must be in place to ensure the equivalency of the electronic and paper media. 

In order to audit effectively studies with electronically generated data, QA should create a special checklist or add electronic issues to a current checklist. The checklist should include items such as ensuring that the computer system in use is current and validated and that necessary maintenance is documented. 

FieldNotes user verification can be conducted by following the SOP written by Astrix, which can be downloaded from the Astrix Web site. The SOP contains a script that is typed into the computer system. If the printout matches the SOP script, then verification is complete. A record of this must be placed in the facility archive. This verification process takes 1 h or less. For FieldNotes, calculations are not verified at the field site since the manufacturer feels that the software developer and the sponsors have performed adequate validation of these calculations previously. This may, therefore, require a visit to the sponsor or to the manufacturer to confirm that this important step of the validation process has been completed and is adequately documented. By following the Astrix SOP, the user is simply ensuring that the program operates on their system(s). The SOP script must be typed in exactly as written in order to confirm the printout accuracy. QA must ensure that the verification documentation is properly archived. Just as with any other SOP, this SOP must be approved in writing by field site management to comply with GLP. 

Although computer equipment is used differently to other field equipment, raw data are being generated consequently, maintenance records are required. All maintenance and repairs to the computer system need to be recorded. For example, software and hardware maintenance records would include system/program updates, disk scans, and defragmentation (e.g., preventative maintenance). Repair records might include communication with the software developer about problems/bugs and steps taken to fix any software or hardware problems. Documentation must include whether the... 

For computer systems that do not require formal validation, at a minimum, user acceptance testing should be performed. This User Acceptance Testing should be outlined in a facility SOP, where the system is tested and assured to perform in the desired function effectively. The User Acceptance should be documented, and the system should be released for specific uses. 

Software and computer systems that are subject to validation must be designed using strict procedures with sufficient documentation. During the process of system design, strict controls must be in place to allow future validation success. The system designer must ensure that documentation of the system meets minimum requirements necessary to satisfy the needs of the validation team. 

Upon management s approval, the end-user requirements for the software/computer system should be identified in a formal document that includes the following ... 

The programming staff or IT department personnel should develop a software/computer system design description based upon the requirements document. This description should outline the specifics required in the system, including security... 

Test plans should include definite, measurable acceptance criteria, in addition to the amount of testing to be done. The test plan should include the data sets to be used and the detailed instructions for testing. Errors encountered during testing must be documented, including how they were discovered, their description, and any action taken to remedy the error. Errors must be remedied prior to the release of the software or computer system. Test results must be documented clearly to allow for pass/fail determinations to be made. 

Testing must be conducted in a typical end-user environment, or in a simulated end-user environment, identical with the environment where the software/computer system will be used. Documentation of testing can be recorded as raw data, such as in a logbook, and should include the parameters tested, and the results of testing. The data should be tabulated as a final report document that includes all details included in the test plan, their execution, the results, and conclusions. The final report document must be signed by appropriate personnel, reviewed as needed, and archived. Upon successful completion of testing, the software/computer system can be released for testing and use in an actual end-user environment. 

Software producers must fulfill the requirements for development, testing, and documentation. When the user is confident that these requirements have been met, and the system functions adequately to fulfill his or her needs, the user must perform validation prior to placing the software in service. An analytical laboratory is an example of an end-user that conducts testing prior to software/computer system installation. 

After SOPs have been written for the use, maintenance, and acceptability criteria for the use of the software/computer system, individual users have been fully trained and the training has been documented, the software/computer system has been fully installed, and the end-user has been validated, the software is ready for use. 

Define what computer system validation would ultimately entail in a management-approved document, such as a policy statement. 

The Association for Clinical Data Management (ACDM) and Statisticians in the Pharmaceutical Industry (PSI) publish an excellent document called Computer Systems Validation in Clinical Research A Practical Guide, which can be found at http //www.cr-csv.org/. 

In order to reflect these lead times, the concept of a timestamp is introduced. Timestamp is used in computer science documenting the system time when a certain event or transaction occurs e.g. for logging events (N.N. 2007). In the context of future inventory value planning, the time-stamp marks the period, when the first raw material has reached a certain stage in the value chain network included into a specific product. In the example illustrated in fig. 57, the raw material is processed in the same period to be converted into product 1. Therefore, all four value chain steps indexed from one to four occur in the same period and have the same time-stamp one. Conversion into product 2, however, requires additional time caused by production lead times, safety inventory and/or transportation time, that the steps indexed with five and six have a time stamp of two. The timestamp reflects that the inventory value of product 2 is not based on the raw material costs from the same period but based on the raw material costs from the previous period in order to reflect the lead time. Consequently, value chain indices and timestamps are defined for all steps and can cover multiple periods reflecting that raw materials in a global complex multi-stage value chain network can take several months, until they are sold as part of a finished product to the market. 

It makes the documents both machine-readable so that they are easily parsed and processed electronically and allows the exchange of information between computer systems. It also makes them human-readable so that they can be easily retrieved and used by the people who need them. 

IQ is the process of ensuring that the instrument is installed correctly, the documentation have been created (e.g., logbooks) or stored (e.g., instrument manuals, original software disks, etc.), and inventories have been updated (i.e., serial numbers are input into the appropriate computer systems). 

Few books attempt to cover the area of automatic chemistry. Technical papers which relate to automation have most often been presented in analytical journals dealing with the basic subject area, and the details of the automation are less well documented than the chemistry. Aspects of management, education and economics are given scant treatment despite their importance. The Journal oj Automatic Chemistry [8] was launched to fill this void in the literature and experience has shown that there is a wealth of technical experience awaiting publication. In addition, it is vital for the suppliers of automatic instrumentation and computer systems to set up adequate lines of communications with their customers. User groups are a valuable asset so that experiences, good and bad, are shared and any problems resolved. A user who becomes frustrated for lack of support or information will become a source of bad reference. A satisfied user, on the other hand, will provide valuable input which may benefit future users and assist the company in providing instruments that the user needs. 

Software—The programs, procedures, and related documentation associated with a system design and system operation. The system can be a computer system or a management system. 

Before a clinical trial starts, the use of technical aids such as IVRT, remote data entry and electronic diaries has to be considered. In Section 7.5.3.3, mention will be made of the use of electronic tracking system that provide status and monitoring reports. All these systems utilise computer systems that must be validated. Double and McKendry described computer validation as the process which documents that a computer system reproducibly performs the functions it was designed to do. The document Guidance for Industry - Computerised Systems used in Clinical Trials published by the FDA in 1999 gives clear recommendations of what is required (also see Section 7.5.4.1). 

---