SAS Programmers Need to Know Regulations?
Validation was introduced to the FDA in the mid 1970s but it is very much alive and relevant in today’s drug development environment. The recent recall of Merck’s Vioxx in September of 2004 after a study linked it to increase heart attack and stroke demonstrates the importance as to to why we need careful scrutiny from our regulatory review of the drug approval process in order to prevent such disasters. The need for validation is affirmed in the more recent event in July 2007 when the FDA concluded that GlaxoSmithKline’s type 2 diabetes drug Avandia increases heart attack risk. Ideally, the FDA would be proactive in deciding on regulations that would prevent dangerous drug recall after many deaths due to drugs that has been proven to be harmful. However, historically, the FDA has been reactive in proposing precautionary procedures such as validation. The early proposals for validation were in direct response to problems with sterility as it involves the production of parenteral products. Validation procedure then spread to other processes as it evolved to the guidelines in 1987 in "Establishing documented evidence that provides a high degree of assurance that a specific process will consistently produce a product meeting its pre-determined specifications and quality attributes.".
Although validation permeates all aspects of drug development ranging from manufacturing to computer systems, in the world of analytics and the use of SAS, computer system validation regulation has a direct impacts. The FDA published in 1983 the guide to for Computerised Systems in Pharmaceutical Processing. This developed into a regulation 21 CFR Part 11 for rules on the use of electronic records, electronic signatures in 1997.
There are many provisions to the guidelines but one of the core themes is defined as the “Confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled”. This means that for any software developed, it needs to be predetermined from requirements in a consisted and expected manner. This structured approach is intended to have computer system function as intended from its design. In a validated system, you would define all the requirements and functional specifications first and then test and verify that the software function according to these requirements. In most cases this process works well with drug development but can pose many challenges in an environment of data exploration where the end result is not always predefined. The data exploratory nature of SAS is very well suited for data analysis but often create challenges when working within the confines of a structured validated environment.
The SAS System is a comprehensive set of tools but it is only one component within a larger system used to perform data management, analysis and reporting of clinical trials data. Validation can only be effective if it is treated as a whole within an entire process. Even if you are developing a single program that reads one table from a relational database and then generate one report that goes into an electronic submission, your single program has a significant impact and therefore is interconnected to a larger system. There are different inherit risks associated with each program. The level of risks pertaining to your use of SAS has a direct correlation with the scope of your validation effort. It is therefore important to perform a risk assessment to determine the appropriate level of validation efforts applied to each component. All the components of your computer system will need to function according to to specification with a appropriate level of validation for the whole system to function consistently with integrity.
SAS Validation Examples
The tools used to develop SAS programs, such as display manager or text editors, are further examples of the ad hoc nature of SAS programming. Display manager gives some structure, but it is designed for data exploration. Software development tools for other languages allow for the programmer to manage the source code as it relates to other programs and data in organized units such as projects. However, SAS programs are plain text files that any user can edit with any text editor of their choice. In a similar way, display manager leaves the programs stored on disk as text files and do not enforce any other structure upon these files.
Similar to validating the SAS System itself, SAS programs need an organized methodology and approach for validation. One of the first steps in validating SAS programs is to have a test plan. The test plan is derived from a list of functional specifications. The functional specifications are, in turn, driven by the list of requirements. This is an interrelated set of documents that drive the process.
The level of detail of documentation for validation depends on the complexity of the set of programs being validated. The following levels distinguish the types of SAS programs.
Although validation permeates all aspects of drug development ranging from manufacturing to computer systems, in the world of analytics and the use of SAS, computer system validation regulation has a direct impacts. The FDA published in 1983 the guide to for Computerised Systems in Pharmaceutical Processing. This developed into a regulation 21 CFR Part 11 for rules on the use of electronic records, electronic signatures in 1997.
There are many provisions to the guidelines but one of the core themes is defined as the “Confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled”. This means that for any software developed, it needs to be predetermined from requirements in a consisted and expected manner. This structured approach is intended to have computer system function as intended from its design. In a validated system, you would define all the requirements and functional specifications first and then test and verify that the software function according to these requirements. In most cases this process works well with drug development but can pose many challenges in an environment of data exploration where the end result is not always predefined. The data exploratory nature of SAS is very well suited for data analysis but often create challenges when working within the confines of a structured validated environment.
The SAS System is a comprehensive set of tools but it is only one component within a larger system used to perform data management, analysis and reporting of clinical trials data. Validation can only be effective if it is treated as a whole within an entire process. Even if you are developing a single program that reads one table from a relational database and then generate one report that goes into an electronic submission, your single program has a significant impact and therefore is interconnected to a larger system. There are different inherit risks associated with each program. The level of risks pertaining to your use of SAS has a direct correlation with the scope of your validation effort. It is therefore important to perform a risk assessment to determine the appropriate level of validation efforts applied to each component. All the components of your computer system will need to function according to to specification with a appropriate level of validation for the whole system to function consistently with integrity.
SAS Validation Examples
The tools used to develop SAS programs, such as display manager or text editors, are further examples of the ad hoc nature of SAS programming. Display manager gives some structure, but it is designed for data exploration. Software development tools for other languages allow for the programmer to manage the source code as it relates to other programs and data in organized units such as projects. However, SAS programs are plain text files that any user can edit with any text editor of their choice. In a similar way, display manager leaves the programs stored on disk as text files and do not enforce any other structure upon these files.
Similar to validating the SAS System itself, SAS programs need an organized methodology and approach for validation. One of the first steps in validating SAS programs is to have a test plan. The test plan is derived from a list of functional specifications. The functional specifications are, in turn, driven by the list of requirements. This is an interrelated set of documents that drive the process.
The level of detail of documentation for validation depends on the complexity of the set of programs being validated. The following levels distinguish the types of SAS programs.
- Exploratory - These are random sets of programs developed by programmers and statisticians to test out a hypothesis. They are not included in the final analysis or part of a submission.
- Stand Alone - These programs are developed to generate specific reports or analysis files. They may be driver programs that call other macros, but these driver programs are not used multiple times.
- Multi-Use - These are usually macro code or standard code segments that are used multiple times in more than one analysis. They can be stored in a global library where multiple users can access them.
more to come in book I am working on "Becoming a SAS Programmer in Pharmaceutical Industry"...
Comments
Post a Comment