The following software is required prior to attending the class. Some of the software will be supplied by the instructor while others is required on the student's machine.
- Windows XP
- Internet Explorer or Mozilla Firefox
- Microsoft Office: Word and Excel
- SAS version 8.12 or higher
Sy Truong is the cofounder and president of MXI (Meta-Xceed, Inc.) since 1997. MXI provides software solutions within the Pharmaceutical Industry specializing
in CDISC data standards, SAS validation, electronic submission, data analysis and reporting. Sy is one of the committee members of the Bay Area SAS User Group (www.basas.com). He is a frequent contributor and presenter
at PharmaSUG, WUSS, and SUGI conferences. He's currently writing a book for SAS Publishing entitled
Becoming a SAS Clinical Trials Programmer.
Validation of a SAS system most commonly occurs during an upgrade from an older version of SAS or moving to a new platform. The examples used in this
course include migrating from SAS 8.2 to SAS 9.1.3 and moving from a legacy operating system to the windows platform. In either case, similar validation challenges are confronted. It is recommended that you first acquire a global view of the system and identify the architecture. Only after gaining this perspective would it be useful to then zoom in on individual components. This allows you to access the scope and interconnectedness of each component so that your validation efforts are balanced and thorough. Once the architecture is clearly understood, the requirements and functional specifications of each component are documented. These functional specifications then drive the validation testing.
It is important to follow these steps in a systematic and orderly fashion since they are interdependent. Documentation of each step in the validation process is also essential in capturing and proving that the validation effort was done properly. Besides documenting each step, it is also important to capture the traceability of each validation task. For each test case that is performed, there is an associated functional specification which then is connected to the requirements for a particular component of the system as a whole. The map or traceability matrix that ties all these validation components together is pivotal to an auditor. Proper documentation will make the difference between a successful validation audit and a complete failure.