ClinOS v5:
System Development Life Cycle
Installation Instructionsfor Meta-Xceed, Inc.
Medical Affairs Information TechnologyMeta-Xceed, Inc.
September July 3117, 20032
Authored by: Sy J. Truong, Consulting Systems Developer
Version 1.0
GenentechMeta-Xceed, Inc. Confidential and Proprietary
ClinOS v5.0 Installation InstructionsSystem Development Life Cycle Version 1.0
Table of Contents
1.Overview of Work Practice
2.Scope Identification
2.1Details of Documents
2.2.Validation Levels
1.Amendment History1
2.References1
3.Overview1
4.ClinOS v5.0 Windows Installation1
5.ClinOS v5.0 UNIX Installation2
GenentechMeta-Xceed, Inc. Confidential & Proprietary
ClinOS v5.0 Installation InstructionsSystem Development Life Cycle Version 1.0
1.Amendment History
Date / Doc.Version /
Amendement Description
9/17/2002 / 1.0 / Original Draft
2.References
SOPs and guidelines are currently being developed within in the Biostatistics department.
ClinOSv3 Administrator Training
ClinOSv4 User Training
ClinOSv4 Reference Guide
3.1.Overview of Work PracticeOverview
CThis document defines the Meta-Xceed’s approach to the development, validation, and documentation of applications (multiple-use, non-modifiable software), used to perform analyses and produce reports that are governed by Good Clinical Practices.linOS version 5.0 consists of a series of SAS macros designed to organize and optimize the analysis and reporting of clinical data. It is designed to work on UNIX (Sun OS 5.6) and PC Windows. The following installation instructions for UNIX and Windows documented below as separate installation processes.
4.ClinOS v5.0 Windows Installation
The following steps are to be performed on Windows PC. The prerequisites for this machine include:
The machine is running Windows 9x or higher. This includes NT, 2000 and XP.
SAS 8.2 is currently installed
The installer has access to create and update the directory c:\clinos
The installer has access to update the SAS configuration file sasv8.cfg located in the SASROOT directory
Once the location of SASROOT has been identified and all the prerequisites have been met, apply the following steps.
1.From the windows desktop, click on the menu: Start Run… \\Mafiles\bdm\Statistical Programming\ClinOS\Version 5\installer
2.Double click on the file: Install_ClinOS_v5.exe
3.Review the following Welcome screen and click the Next button.
4.If the SAS configuration file is not located at: c:\sas, you may be presented with the dialog box:
Click the OK button. Otherwise skip to step 6.
5.Enter the proper path to the location of SASROOT. An example is shown here:
Click OK.
6.Files are copied to the C:\clinos directory and the sasv8.cfg is updated. The “Finished” dialog box will then be shown:
Click on the Close button.
Installation is complete. Configuration options of the ClinOS system can be viewed here:
5.2.Scope IdentificationClinOS v5.0 UNIX Installation
The Chance Request (CR) and related Change Control Notes (CCnotes) TS.O.P. 1510.018 provide the basis for requesting approval for a software change, including introduction of new software, and for identifying the scope of SDLC, validation, and documentation necessary to perform the change.
If this is for a client, someone within the appropriate departments of the client is identified as the system owner or sponsor; this is typically a senior or management-level person involved in the system's use. After discussion with the system owner regarding what is needed, a member of the client’s group enters fills out a CR and a enhancement note to indicate what software change is being requested and submitted. The information will be emailed to the appropriate team members. After discussion between Meta-Xceed’s Software/QA and the system users, a decision is made to promote this as a change control item through the use of CCnotes. Depending on the level of change, the appropriate documentation and testing will be performed.
Some or all of the following documentation items are needed. On rare occasions, additional documents may be needed. he following steps are to be performed by a UNIX administrator on a SunOS server. The prerequisites for the installation include:
- User Requirements
- Functional Specifications
- Validation Project Plan
- Validation Protocol
- Installation Qualification
- Operational Qualification
- Performance Qualification
- Validation Summary Report
- Programmers' Guide
- Users' Guide
- User Training
The machine is running SunOS version 5.6.
SAS 8.2 is currently installed
The installer has access to create and update the ClinOS root directory. An example of this is:
/usr/local/biostat/clinos/clinos_dev/v5.0
The installer has access to update the SAS configuration file sasv8.cfg located in the SASROOT directory
Once the location of SASROOT has been identified and all the prerequisites have been met, apply the following steps.
1.Create the ClinOS root directory. An example is:
/usr/local/biostat/clinos/clinos_dev/v5.0
2.Copy the clinos5.tar file into this directory from MAFiles source location located at:
\\Mafiles\bdm\Statistical Programming\ClinOS\Version 5\installer
to the ClinOS root.
3.Uncompress this file by typing the UNIX command:
tar –xfv clinos5.tar
4.Verify that the following folders are created:
clinos_data
clinos_globals
clinos_tools
codelib
5.Verify the existence of the following files:
clinos_data/config.sas7bdat
clinos_globals/global_config.sas
clinos_tools/autoexec.sas
clinos_tools/autoexec_drug.template
clinos_tools/autoexec_study.template
clinos_tools/autoexec_task.template
clinos_tools/titles.sas
clinos_tools/titles_task.template
codelib/config.sas
codelib/dateback.sas
codelib/getchild.sas
codelib/gettitle.sas
codelib/init.sas
codelib/levadm.sas
codelib/locate.sas
codelib/logeval.sas
codelib/mtitle.sas
codelib/pagenum.sas
codelib/prtsetup.sas
codelib/retire.sas
codelib/sample_config.sas
codelib/setpath.sas
codelib/setup.sas
codelib/snapshot.sas
6.Edit the SASROOT/autoexec.sas
Add these lines defining where ClinOS v5 will store its data:
/* Set ClinOS data libname */
7. libname clinosdt “/usr/local/biostat/clinos/clinos_dev/v5.0/clinos_data”;
Add these lines to the SASROOT/sasv8.cfg for the SASAUTOS so that it recognizes the location of the new macros:
-SET SASAUTOS (
"/usr/local/biostat/clinos/clinos_dev/v5.0/codelib"
Edit the SASROOT/autoexec.sas
You have completed installing all the necessary files. You may want to refer to the configuration options of the ClinOS system at:
Appendix A: Installation Checklist
Items in italics represent commands to be inserted or edited during installation procedure.
# / Description / Comments / Initial/Date
1. / Log onto UNIX server with the administration account with proper privileges.
2. / Create the ClinOS root directory. An example is:
/usr/local/biostat/clinos/clinos_dev/v5.0
3. / Update the privileges to this directory so that it can only be read by users. For example:
chmod 755 /usr/local/biostat/clinos/clinos_dev/v5.0
4. / ftp the source file clinos.tar on MAFILES to UNIX server. The source file is located on MAFILES at: \\Mafiles\bdm\Statistical Programming\ClinOS\Version 5\installer
5. / Apply the uncompress command:
tar -xfv clinos5.tar
6. / Verify that the following folders are created
clinos_data
clinos_globals
clinos_tools
7. / Verify the existence of the following files:
clinos_data/config.sas7bdat
clinos_globals/global_config.sas
clinos_tools/autoexec.sas
clinos_tools/autoexec_drug.template
clinos_tools/autoexec_study.template
clinos_tools/autoexec_task.template
clinos_tools/titles.sas
clinos_tools/titles_task.template
codelib/config.sas
codelib/dateback.sas
codelib/getchild.sas
codelib/gettitle.sas
codelib/init.sas
codelib/levadm.sas
codelib/locate.sas
codelib/logeval.sas
codelib/mtitle.sas
codelib/pagenum.sas
codelib/prtsetup.sas
codelib/retire.sas
codelib/sample_config.sas
codelib/setpath.sas
codelib/setup.sas
codelib/snapshot.sas
8. / Edit the SASROOT/autoexec.sas
Add a line defining where ClinOS v5 will store its data. A sample would look like:
/* Set ClinOS data libname */
libname clinosdt “/usr/local/biostat/clinos/clinos_dev/v5.0/clinos_data”;
9. / Add a line to the SASROOT/sasv8.cfg so that it recognizes the location of the new macros. For example:
-SET SASAUTOS ( "/usr/local/biostat/clinos/clinos_dev/v5.0/codelib"
10. / Edit the configuration file located at:
codelib/sample_config.sas
11. / Ensure that all the paths reflect the installed configuration. Refer to the documentation to understand the meaning of the parameters located at:
/groups/Magi/projects/clinos/
12. / Submit this program with the default SAS version 8.2 command such as:
sas8 sample_config.sas
13. / Review the log file sample_config.log to verify that the configurations are applied and that the ClinOS macro %config is working.
Installation Excecuted by: ______
Signature: ______Date: ______
2.1Details of Documents
For clarity and ease of searching, some of the documents required are often combined. Below are descriptions of the major combined documents that typically pertain to an application development effort.
2.1.1.User Requirement
This document specifies what the users need from the system; for example, purpose of the application, need for concurrent use, security required, specific deliverables needed from the system.
2.1.2.Functional Specifications
This document identifies how the system will achieve each specified user requirement. It is typically more technical than the User Requirements. For example, if a user requirement is ensuring that only staff assigned to a particular clinical project have access to certain data, the functional specifications will state how that type of security will be accomplished.
2.1.3.Validation Project Plan
Validation Project Plan is needed if there are multiple systems involved, such as a simultaneous upgrade of SAS, ClinOS, etc.... This plan is generally short, with most of the information residing in the individual validation protocols, which are generated for each involved system. This plan describes the testing and documentation strategy for the project, including a description of the products being upgraded or installed, their development, use, maintenance, and relationship.
2.1.4.Validation Protocol
The validation protocol describes in detail how the system will be validated. It addresses the intended uses and users of the software, developers and maintainers of the software, reasons for upgrade or installation, software security, and software integration points.
Details of the tests that will be performed can exist in one or more of these three potential protocol sections: Installation Qualification, Operational Qualification, and Performance Qualification. Which of these parts are required depends on the nature of the system.
2.1.4.1.Installation Qualification (IQ)
This section addresses how installation will be performed and documented and is generally required in any department-level validation effort. For commercial software, installation instructions and test samples are often provided. For custom software, installation instructions must be drafted.
2.1.4.2.Operational Qualification (OQ)
This section addresses how testing of basic software functionality and components will be performed. Specific test cases must be itemized. For GUI systems, it mentions what the user will do and how the system will respond; for batch systems, it indicates what is being tested, the source data, the program(s) being run against it, the expected results, and the locations of all of these items.
2.1.4.3.Performance Qualification (PQ)
This section addresses the functioning of software that will be run by the users to accomplish their jobs. Specific test cases must be itemized. For GUI systems, it mentions what the user will do and how the system will respond; for batch systems, it indicates what is being tested, the source data, the program(s) being run against it, the expected results, and the locations of all of these items.
2.1.5.Validation Summary Report
Every Validation Protocol should have a corresponding Validation Summary Report. If there are several systems involved in an effort covered by a Project Plan and each system has its own Validation Protocol, then each system should have its own Validation Summary Report as well.
The Validation Summary Report should itemize all tests run, their results, and user acceptance comments and signatures. It should also summarize the test results according to pass/fail status and seriousness of any failures. Some failures are not critical and may be due to poor testing methods rather than to actual software failures; others may be due to insignificant software failures that could be addressed through training and/or documentation; still others may require re-coding and re-testing. All identified failures must be itemized and described as to what failed, how significant it was, and how it will be addressed. This itemization must be signed by the system owner or their designee.
2.1.6.Programmers' Guide
To provide clarity regarding how the application functions and to facilitate efficiency of future upgrades, a programmers' guide should be written for every custom-developed application. This should include the software modules used (e.g., base SAS, SQL*NET), their source company if applicable, their interaction, and their location.
2.1.7.Users' Guide
To facilitate proper use of the application, a users' guide should be developed to explain the purpose of the software and to provide details on how to use it and whom to contact for support. If appropriate, the guide can include a concise tip sheet for handy referral.
2.1.8.User Training
For complicated software, providing in-person user training is warranted. It is often appropriate to create training tools in addition to the user manual, but not necessary.
2.2.Validation Levels
There are three levels of application software validation. The extent of validation and documentation needed decreases with the extent of the change.
2.2.1.Major Change
Major efforts are those involving significant changes to existing software used, such as a full numeric upgrade of SAS, ClinOS, or installation/development of a complicated system. In general, a major effort would include all or most of the documents itemized in the CR section above.
2.2.2.Minor Change
Minor efforts involve changes in the high decimal range of a version number that do not have significant effects on the software used. A minor effort might dispense with PQ and possibly User Requirements or Functional Requirements.
2.2.3.Patch
Patches involve either changes in the low decimal range of a version number or no change in version number at all and have very minor effects on the software. A patch may involve only application of the patch, its documentation in the CCnotes and an email to the users to be on the alert for any inappropriate software functioning for a specified period of time.
GenentechMeta-Xceed, Inc. Confidential & ProprietaryPage 1
\\Mafiles\BDM\Statistical Programming\ClinOS\Version 5\docs\clinOS v5 I\validation\ Meta-Xceed SDLC.docnstallation Instruction.doc