Standard Operating Procedure (SOP)

Meta-Xceed, Inc.
September 17, 2002

Authored by: Sy J. Truong, Systems Developer

Meta-Xceed, Inc. Confidential and Proprietary

Admendment History

Date Version Amendement Description

September 17, 2002 1.0 Final version of SOP

December 17, 200 1.1 Add an SOP for the management of

SOPs

Meta-Xceed, Inc. Confidential and Proprietary

Meta-Xceed, Inc. Confidential and Proprietary
Standard Operating Procedure

Table of Contents

1. GXP Computer Systems: Test Deviation Identification and Resolution 1

1.1. Purpose 1
1.2. Definitions 1
1.3. Procedure 1

2. Policy for Computer Systems Validation 2

2.1. Purpose 2
2.2. Scope 3
2.3. Policy 3
2.4. Validation Principles 3
2.5. Responsibilities 4
2.6. Documentation 4
2.7. System-Specific Validation Documents 4
Development Documentation 4
2.8. 4
2.9. Procedure 5

3. Change Control Systems 5

3.1. Purpose 5
3.2. Scope 5
3.3. Participants 6
3.4. Initiating a Change Control (CR) 6
3.5. Approval 7
3.6. Implementation 7

4. System Development Life Cycle for Meta-Xceed 8

4.1. Purpose 8
4.2. Definitions 8
4.3. Tasks 8
4.4. SDLC Stages 9

5. Standard Operating Procedure (SOP) Management 12

5.1. Purpose 12
5.2. Scope 12

Meta-Xceed, Inc. Confidential & Proprietary

Standard Operating Procedure

5.3. Procedure 12

6. Training Methods 14

6.1. Purpose 14
6.2. Policy 14
6.3. Procedures 14

7. Software Version Control Management 15

7.1. Scope/Goals 15
7.2. Definitions 15
7.3. Process 15

8. Source Code Conventions 17

8.1. Scope 17
8.2. Definitions 17
8.3. Procedures 17

9. Storage and Maintenance of Documents 19

9.1. Purpose 19
9.2. Process 19

Meta-Xceed, Inc. Confidential & Proprietary

ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

1. Amendment History

2. GXP Computer Systems: Test Deviation

Identification and Resolution
Code: 1001 CFR: 10569
Effective Date: December 15, 1999
Approved By: Sy Truong Approved Date: Jan 19, 2000

2.1. Purpose
This SOP describes the method for identifying, resolving, and documenting deviations
encountered during validation testing of computer-related systems.

2.2. Definitions
Test: The pre-approved documentation where testing instructions are defined and
results are recorded.

Tester: Any person involved in executing tests. The tester executes tests and identifies
deviations, documents deviation(s), and performs corrective actions where appropriate.

Deviation: A deviation occurs when actual test results do not match expected results,
the test cannot be completed as written, the system does not perform as specified by
the test, or any other unexpected condition arises.

2.3. Procedure
The following procedure should be followed when a deviation occurs.
2.3.1. Identify Deviation
 Document the observed deviation at the time it is encountered, including
signature of observer and date. Describe exactly what was observed to
warrant a deviation. Assign a unique identifier to the deviation. If a single
deviation affects a number of tests, a global deviation may be used to
cover all affected tests.
 Document the root cause of the deviation (e.g., test generation error,
hardware/software bug, specification is incorrect, etc).

Meta-Xceed, Inc. Confidential & Proprietary Page 1

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

 Determine whether testing can proceed, this may involve consultation

with validation, development, and/or Quality Assurance personnel.

2.3.2. Identify Corrective Action(s)

 Document the corrective action(s) that are necessary to resolve the
deviation (e.g., test corrections, change request for hardware/software
bug, revision to specification, etc). Include any requirements for
re-testing or new testing based on corrective action(s).
 Assess the impact to requirements, specifications, hardware, software,
the current test form, and any previously executed tests.

2.3.3. Approve Corrective Action(s)

 Corrective action(s) may be approved either before or after they are
performed.

2.3.4. Perform Corrective Action(s)

 If it is determined that a hardware or software change is necessary,
initiate the appropriate change control mechanism to make the change,
and complete any re-testing.
 Document the disposition (accept/reject and rationale) of test results
affected by the deviation.
 After corrective actions are successfully completed, retain deviation
paperwork with the original test. Include verification that the corrective
action(s) has been performed.

2.3.5. Documentation
At a minimum, the following information should be documented:
 System name and test ID
 Unique identifier for the deviation (e.g., test IW-1)
 Description of deviation, signed and dated by the observer
 Explanation and root cause for deviation
 Description of corrective action, impact assessment (on other tests,
requirements, specifications, software, etc). For hardware or software
change, reference the change record number.

3. Policy for Computer Systems Validation

Code: 1002 DCR: A35854
Effective Date: December 11, 1999
Approved By: Sy Truong Approved Date: Jan 19, 2000

Meta-Xceed, Inc. Confidential & Proprietary Page 2

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

3.1. Purpose
Meta-Xceed recognizes that data is a valuable asset and that product cannot be
released to market without data of ensured integrity. This policy defines Meta-Xceed's
commitment to the validation of computer systems and provides guidance on the
principles for carrying out computer validation in accordance with the requirements of
the FDA and other regulatory agencies.

3.2. Scope
This policy is applicable to all existing and new computer systems used for GXP
purposes, and regulatory submissions. A computer system consists of computer
hardware, software, operating environment, associated data, and documentation to
perform a GXP or regulatory submission function.

3.3. Policy
Computer systems that manage data, support regulatory submissions, or control
manufacturing operations that affect the safety, efficacy, or quality of our products must
be validated. Validation of these systems must demonstrate that they were properly
developed, have been thoroughly tested, and are being maintained in a manner that
ensures they meet user requirements, are reliable, and are protected from unintended
changes.

3.4. Validation Principles

The validation effort required for a computer system is necessarily dependent upon the
size, complexity, and impact of the system and the criticality of the data or processes
managed by the system. Each system should be assessed to determine the
appropriate scope of the validation.

The validation of new computer systems must be performed using pre approved
prospective protocols. Validation documentation must be compiled into approved
summaries and maintained on file in a location where it can be retrieved for inspection
by regulatory authorities. It is important that validation summaries be complete and
stand alone packages that can be understood by qualified independent reviewers
without reliance upon specific individuals for interpretation.

The validation of new computer systems must be supported by documented evidence

that the system was developed using good system development practices. In addition,
there must be adequate procedures in place to ensure the system remains validated.

The validation of existing computer systems may require a retrospective evaluation of

the system.

Periodic evaluation of validated computer systems is required to confirm that the

system continues to be maintained in its validated state.

Meta-Xceed, Inc. Confidential & Proprietary Page 3

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

Validation of a computer system must demonstrate that ancillary hardware and

software (e.g., networks, server operating systems) were properly installed, are
adequately documented, and operate in accordance with system requirements.

3.5. Responsibilities
The management of areas with computer systems that fall within the scope of this
policy is responsible for ensuring the systems are validated in compliance with this
policy. Validation of computer systems is typically achieved using a team approach with
defined roles: Owners, Users, Developers, Quality Assurance Unit, and any necessary
support groups.

System Owners: manage the operation of systems. They identify the need for new
computer systems and are responsible for their development, validation, maintenance,
and support. They are responsible for maintaining an inventory of validated computer
systems for their area. System Owners may delegate the execution of these activities.

System Users: use the systems on a day to day basis. They provide the basis for the
functional design and support the testing and documentation effort for validation.

System Developers/Administrators: develop, test, and support the ongoing operation of

systems. They provide development, testing, and system support documentation for
validation.

Quality Assurance Unit: reviews and approves computer validation documentation.

They must be independent of the System Owner and Developer/Administrator.

3.6. Documentation
Documentation potentially required for validated computer systems falls into three
broad categories: system specific validation documents, development documentation,
and procedures. At a minimum, the validation of a computer system requires a
Validation Protocol (or Project Plan when a project involves multiple systems), which
identifies the validation testing and documentation required, and a Validation Summary
of the validation results.

3.7. System-Specific Validation Documents

Validation documents must be approved by the Quality Assurance to ensure the
validation approach is consistent with this policy and appropriate for the size and scope
of the system. System specific validation documents are listed below.

Validation Project Plan

Validation Protocol
Installation Qualification
Operational Qualification
Performance Qualification
Validation Summaries

Meta-Xceed, Inc. Confidential & Proprietary Page 4

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

3.8. Development Documentation

Development documentation provides the basis for validation testing. It is required to
maintain computer systems in a state of control throughout their lifecycle. Development
documentation potentially required is listed below.

System Development Plan

Functional/Design Requirements
System Specifications
Test Plans/Results/Reports
Vendor Evaluations
Software Quality Assurance
Plan Programming Standards
Annotated Source Code
Code Review Documents
Configuration Management Records
System Development Summary
System/User Manuals
System Technical Documentation
Training Curricula, Records, Instructor Qualifications

3.9. Procedure

Procedures and references that may be required are listed below.

System and Software Development

Prospective Validation
Retrospective Validation
Validation Test Methods
Preparation, Maintenance, and Archiving of Validation
Documents Approval Requirements
Maintenance
Security
Change Control
Periodic Review
Error Handling/Resolution
Backup and Disaster Recovery
Training

4. Change Control Systems

Code: 1003 CRF: 15406

Effective Date: December 11, 1999
Approved By: Sy Truong Approved Date: Jan 19, 2000

Meta-Xceed, Inc. Confidential & Proprietary Page 5

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

4.1. Purpose
To describe the procedures for users of Meta-Xceed computer systems to accomplish
change to their systems, under appropriate control.

4.2. Scope

This document defines change control procedures to be followed in the implementation

of modifications to:
 production application software developed or supported by Meta-Xceed on
Meta-Xceed production servers and client machines;
 environment software on Meta-Xceed production servers including, but not
limited to: operating systems, backup utilities, file share utilities, editing utilities,
file compression utilities, and version control systems;
 software on Meta-Xceed client machines including, but not limited to: operating
systems, standard desktop applications, and office automation software;
 Meta-Xceed server or client hardware;

Any installation or modification to an application, whether validated or not, on a

production server, requires the change control process.

4.3. Participants
Project Manager: The Project Manager is the senior technical person accountable for
a Meta-Xceed developed or supported application. The Project Manager is responsible
for:

 Directing the application's change control process.

 Working with the Requester, Project Sponsor, analysts, programmers, testers,
and applications architecture in preparing an Impact Analysis.
 Communicating the Change Review Board's decisions to the User, Project
Manager, and to the Requester of the CR, explaining each acceptance or
rejection.
 Ensuring all documentation is identified and updated as necessary prior to
production release (including system development life cycle documents, testing,

Meta-Xceed, Inc. Confidential & Proprietary Page 6

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

user guides, system administrator guides, and any technical or standard

operating procedures impacted by the change).
 Ensuring the change is implemented.
 Debriefing the Change Review Board on the production release.
 Signing off upon final disposition of a CR.

Requester: Requester is anyone initiating a change.

Project Sponsor: The Project Sponsor is the product user community's representative
for change control and will be the designated system/data owner. The Project Sponsor
is responsible for:

 Assisting the Project Manager in preparing the Impact Analysis.

 Identifying and directing all required updates to user generated work flow SOPs,
guidelines, and practice documents prior to production release and reporting
completion of these tasks to the Project Manager.

4.4. Initiating a Change Control (CR)

The Change Request form (CR) is the mechanism by which significant enhancements,
updates and new product implementations are requested and malfunctions are
reported. For smaller enhancements and bug fixes, the online Change Control Note
(CCNote) can be used to report the items more efficiently.

Any user or developer may generate a request. The CR form and CCNote can be
access on Meta-Xceed servers. For the CR number will only be assign after all the
initiating sections have been completed. The CCNote will have an identification
number automatically assigned to it upon request.

The CR form and CCNote consists of sections that:

 Describe the reasons, procedures and alternatives for the requested change
and identifies the type of change (bug, maintenance release, upgrade, new
install, etc.) being made
 Determine the impact of the requested change (major or minor)
 Identify the documents required for validation of the requested change
 Document approval to implement the change
 Certify all necessary activities were completed for the change.

The Project Manager determines whether the impact of the requested change is major
or minor. If it is major, an Impact Analysis is performed.

The Impact Analysis identifies how changes to the software might impact critical
business functions or validation status of systems and/or result in the loss or
interruption of operations.

4.5. Approval

Meta-Xceed, Inc. Confidential & Proprietary Page 7

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

A CR is required for all proposed changes. Documentation for minor changes will follow
the System Development Life Cycle. Documentation for major changes is defined by
the Project Manager. The validation documentation necessary for a proposed change
is dependent upon the size, complexity and impact of the system and the criticality of
the data or processes the system manages.

4.6. Implementation

The project manager completes the Implementation Plan (part of the CR form),
identifying critical milestones such as completion of validation documents before going
into production, pre requisite activities, work to be performed by other groups, etc.
Once the change is coded, tested, and documented per SDLC procedures or
deliverables stated in the MCR, the changed is implemented. The Project Manager
notifies impacted groups that the change has taken place.

The original CR is retained in the active file until final disposition. Upon final disposition,
the original CR will be filed and retained as a system development life cycle document.

System Development Life Cycle for Meta-Xceed

Code: 1004 CFR: 18251
Effective Date: December 15, 1999
Approved By: Sy Truong Approved Date: Jan 19, 2000

4.7. Purpose
This procedure describes the methodology that Meta-Xceed uses to develop validated
information systems. Meta-Xceed System Development Life Cycle is available as a
document on the Meta-Xceed servers.

4.8. Definitions
System Testing: Testing conducted on a complete, integrated system to evaluate the
system's compliance with its functional specifications.

User Acceptance Testing: Formal testing conducted to determine whether or not a

system satisfies its acceptance criteria as defined in the user requirements and to
enable the user to determine whether or not to accept the system.

Validation: The process of evaluating system during or at the end of the development
process to determine whether it satisfies specified requirements.

Project Plan: Lists outlining tasks, deliverables, resources, and timelines for a project.

Meta-Xceed, Inc. Confidential & Proprietary Page 8

\validation\SOP.doc
 ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

4.9. Tasks
Development
 Identify the need for new computerized systems.
 Provide user requirements which are the basis for the functional design.
 Participate in user acceptance testing.
 Accept the system for release into production.
 Approve the project scope and approach from the technical feasibility point of
view, adherence to standards, and appropriateness to the overall IT strategy
and architecture.
 Define system design, development, and implementation plans and schedules.
 Review system integration issues with other initiatives.
 Review technical conversion from current to new systems within implementation
plans.
 Manage system and user acceptance testing.

Quality Assurance / Validation

 Oversee the quality assurance process for the product.
 General oversight for all testing.
 Enforce validation requirements for the system.
 Oversee the change control process for the application.
 Provide oversight of validation efforts.

4.10. SDLC Stages

Summary
The system development methodology is based on a life cycle approach consisting of
the following stages:
 Initiation
 Requirements
 Design
 Development
 System Testing
 User Acceptance
 Rollout
 Production
 Retirement

Stage Completion
Each stage will not be complete until the deliverables required by that stage are
complete.

Initiation Stage
In the Initiation Stage, either Meta-Xceed or the client identifies an area where a new
system, improvements to an existing system, or changed processes would significantly
enhance productivity. A Meta-Xceed consultant works with the client to define the
business objectives of the project.

Meta-Xceed, Inc. Confidential & Proprietary Page 9

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

Requirement Stage
During the Requirements Stage, the users establish and document the needs of the
business functions. The requirements will define what the system should do. The
Validation Protocols and Plans are established in order that documented evidence that
the system has been validated by the time it is put into production.

Deliverables
 Project Plan
 User Requirements
 Validation Protocols

Design Stage
In the Design Stage, the developers prepare a functional specification which describes
how the proposed systems solution will meet user requirements. The developers then
produce a design specification which will define how the system will be constructed to
fulfill the functional specification.

Deliverables
 Governing Structure Document
 User Acceptance Test Plan
 User Acceptance Test Cases
 User Acceptance Test Case Traceability Matrix
 System Architecture Specification Document
 Functional Specification
 Rollout Plan
 Training Plan
 Project Coding Standards
 Design Specification
 System Test Plan
 Database Architecture ER Diagram

Development Stage
In the Development, the developers translate design specifications into Stage computer
programs and perform unit and integration testing on the programs.

Deliverables
 Functional Review Report
 System Test Cases
 System Test Case Traceability Matrix
 Source and Executable Code

System Testing Stage

In the System Testing Stage, the system is tested against the functional specification.

Deliverable
System Test Summary Report

Meta-Xceed, Inc. Confidential & Proprietary Page 10

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

User Acceptance Stage

In the User Acceptance Stage, the system is tested against user requirements.

Deliverable
User Acceptance Test Summary Report

Rollout Stage
In the Rollout Stage, users are trained and provided with operating procedures. The
system is installed in a QA environment and tested to ensure it operates as intended
throughout its anticipated operating range.

Deliverables
SOPs and Guidelines
Training Manuals
Training Logs
Validation Summary Report
Completed Installation Qualification/Operational Qualification Document

Production Stage
In the Production Stage, the system may experience bug fixes, enhancements, and
upgrades to maintain or increase its performance and functionality.

Deliverables
Summary Report
Change Request

Retirement Stage
In the Retirement, the system is removed from the production Stage environment and
archived.

Deliverable
Decommission Plan

Meta-Xceed, Inc. Confidential & Proprietary Page 11

\validation\SOP.doc
 ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

5. Standard Operating Procedure (SOP)

Management
Code: 1005 CFR: 18251
Effective Date: January 31, 2003
Approved By: Sy Truong Approved Date: January 31, 2003

5.1. Purpose
This procedure describes the steps taken during the management of the SOP
documents. It will describe how the documents are to be authored, updated and
maintained to ensure proper relevance in the event of changes.

5.2. Scope

This document defines procedures to be followed in the authoring and modifications to

Standard Operating Procedures (SOP). The SOP can be applied to the process of:
 production application software development,
 environment software, but not limited to: operating systems, backup utilities, file
share utilities, editing utilities, file compression utilities, and version control
systems;
 software on client machines including, but not limited to: operating systems,
standard desktop applications, and office automation software; server or client hardware.

Any procedure which has a significant affect the software development of Meta-Xceed
applications, whether validated or not, on a production server requires a standard
operating procedure to be defined.

5.3. Procedure
The following procedure should be followed when a procedure is authored.
5.3.1. Identify SOP
 Document the standard operating procedure in a way that best describe
how it is to be implemented.
 Document the scope of the procedure to ensure that it is not overstating
other procedures.
 Document the steps of procedure or definitions of the procedure.

5.3.2. Approval
 Determine if the SOP needs review and approval.
 Circulate document for review and approval.
 Incorporate review and update the documentation for final approval
5.3.3. Implementation

Meta-Xceed, Inc. Confidential & Proprietary Page 12

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

 Send updated SOP to all members which the SOP applies to for training.
 Have team members sign and hold discussions for review of the SOP if
questions arise.
5.3.4. Review Changes
 Identify changes as needs changes and update the SOP to fit the
current operating procedure. The steps of changes do not require an
authoring of a new SOP but the steps are similar to those from 5.3.1
through 5.3.3.
 Review old SOP that has not been changed on a yearly basis to ensure
that SOPs matches the way the procedures are intended.

Meta-Xceed, Inc. Confidential & Proprietary Page 13

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

6. Training Methods
Code: 1006 CFR: 18251
Effective Date: January 31, 2003
Approved By: Sy Truong Approved Date: January 31, 2003

6.1. Purpose
This SOP defines and describes the Learning and Development programs and the
training activities available. This SOP applies to all Meta-Xceed personnel.

6.2. Policy

6.2.1. All personnel in will be trained in relevant standard operating procedures

(SOPs) and guidelines (GDLs). The purpose of this training is to ensure
personnel are qualified to perform assigned tasks.

6.2.2. These same personnel will be expected to complete internal or external

training (e.g., courses, workshops, conferences, etc.) relevant to their job
expectations and to the implementation of Good Clinical Practices (GCP)
in those job tasks.

6.2.3. All personnel will document completed training activities.

6.2.4. All completed training records will be will be maintained in Meta-Xceed

central records.

6.3. Procedures
1.1.1. Core Curriculum: New employee orientation, SOP/GDL training regulatory and
compliance training, job specific, and professional development training programs.

6.3.1. Foundational Curriculum: Curriculum aligned by job function, providing

a map of programs and learning activities for employee development.

6.3.2. SOP/GDL Training: All employees will be trained on SOPs and GDLs
relevant to their job function. SOP/GDL training will be delivered in a
paper or online or formal presentation formats as appropriate.

7. Software Version Control Management

Code: 1007 CFR: 18251
Effective Date: January 31, 2003
Approved By: Sy Truong Approved Date: January 31, 2003

Meta-Xceed, Inc. Confidential & Proprietary Page 14

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

7.1. Scope/Goals
The scope of Software Version Control Management will be to implement the
configuration management and some aspects of release management for all of the
software developed by Meta-Xceed.

7.2. Definitions

Configuration management for will be defined as the ability to:

- Uniquely identify the versions of each software item.
- Identify the versions of each software item that together constitute a specific version
of a complete product.
- Control updating of a given software item including source code (such as program
code, software testing code, technical database design documents, etc) and project
documentation (eg, MS Word).

Release management will be defined as the ability to:

- Provide coordination for updating multiple products as required.
- Provide a software baseline library for each version of a product.
- Notify any and all affected groups and individuals of changes to the software
baseline library.
- Ensure all documents and source files are in place for validation.

7.3. Process
The following is the general work process of updating modules to software.

Work Process Details

Modularize software development All functions within software are developed in
modules aligned by functions. Each module is
saved to physical separate files. This can be in a
form of source code or data files.
Editing and updating files Each module can only be edited or updated by
one developer at a time. The modules therefore
are broken into small enough pieces to not clash
with multiple updates.
Document Changes All updates have to correspond to a change
control request. This is process is initiated in the
change control procedure. After changes are
implemented, comments can be added to the
change control documents.
Notify Release All software implementation are to be
notified to all users by email. Further
documentation can be entered through
the change control document during
release of any bug fixes or updated
versions.

Meta-Xceed, Inc. Confidential & Proprietary Page 15

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

8. Source Code Conventions

Code: 1008 CFR: 18251
Effective Date: January 31, 2003
Approved By: Sy Truong Approved Date: January 31, 2003

8.1. Scope
The scope of source code conventions is to specify the format and documentation
requirements for software source code development. This will ensure the quality and
legibility of source code among the development team within Meta-Xceed.

8.2. Definitions
Program Header – This is captures comments that goes at the very top of each source
code program. It is not program logic but comments that describe the program.

Section Comments – The comments describing in plain English each section within a
program.

Variables – Variables are either local temporary or permanent variables corresponding

to columns in an external database.

8.3. Procedures

Procedure Details
Starting new program All new program needs to have a standard
program header. This includes the program name,
description, input, output, author name and date.
Editing an existing Each section of logic within a program needs to
program have a section comment. This is a brief one or
two sentence describing the section. This appears
at the top of each section.

Updates the program header is needed if to reflect

edits.
Working with variables Variables names need to be direct and short. For
SAS programs, case is not important but for HTML
or Java and JavaScript, the variable starts with
lower case and has an upper case letter for the
start of each word. Variable names should be
consistent across programs.

Meta-Xceed, Inc. Confidential & Proprietary Page 16

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

Programming Format All programs are left justified with indentations

within each program section containing three
spaces. No tab are to be used. It is
recommended for programs to be under a 1000
lines if possible for modularity.

9. Storage and Maintenance of Documents

Code: 1009 CFR: 18932
Effective Date: January 31, 2003
Approved By: Sy Truong Approved Date: January 31, 2003

9.1. Purpose
This procedure describes the process of storing and maintaining documents for Meta-
Xceed. This will ensure that the latest versions of the documents are secured and
available.

9.2. Process
Storing Electronic Documents
Documents are authored in an electronic form and normally are stored as Microsoft
Word documents. The documents are stored in multiple computer servers on multiple
locations. One version will be stored at Meta-Xceed head quarters on the main server.
The second version is stored on a web server which is maintained by an internet
service provider (ISP) which Meta-Xceed contracts with. The ISP is Verio and servers
are maintained in Mountain View with additional backups in different locations through
out the United States. This will ensure that in an event that there is lost of data and
documents at one location, that the other location can be used to restore the files.

Storing Paper Documents

Paper documents to be stored in metal filing cabinets at Meta-Xceed head quarters.
These are fire resistant and are locked with key access to only administrators of
documents.

Maintaining Documents
All electronic and paper versions of documents are to be updated in a similar manner.
Old copies are placed a backup folder and the new updated versions are to be placed
in the designated folder. This ensures that the latest versions of the documents are in
the assigned folders while maintaining a history of older versions in a backup folder.

Accessing Documents
All electronic documents will be controlled by group permissions of the operating
system. On the main server within Meta-Xceed head quarters, NT groups will be set so
that appropriate read and write access are granted. Only administrators will have write
access. Similar privileges are set on the UNIX servers of the offsite mirrored locations.

Meta-Xceed, Inc. Confidential & Proprietary Page 17

\validation\SOP.doc
ClinOS v5.0 Installation InstructionsStandard Operating Procedure
Version 1.0

Meta-Xceed, Inc. Confidential & Proprietary Page 18

\validation\SOP.doc