Download Designing and Building an Administrative Model for the SAS® Drug Development Tool

NESUG 2006
Posters
Designing and Building an Administrative Model for SAS Drug Development Tool
Margaret M. Coughlin, Merck Research Laboratories, North Wales, PA
ABSTRACT
Regulated industries such as pharmaceuticals require specific functionalities of computer systems such as audit
trials, version control and restricted access for users. The SAS Drug Development (SDD) repository provides
these required functionalities in a manner which allows the SDD licensee to customize them to their work processes. Thus, the design and implementation of an administrative model for SDD is an important consideration for
potential licensees of the product. In this paper, one administrative model is proposed to help manage and organize clinical trials analysis and reporting within the SDD tool.
INTRODUCTION
Computer systems used to manage and report on electronic information used in clinical trials are required to comply with U.S. government regulation 21 CFR Part 11. This regulation requires that access to electronic clinical
information is restricted to those who need it to perform their job role. Additionally, the ability to trace changes to
electronic clinical information is required. SAS programs, datasets, results and logs are electronic information
used in clinical trials that fall under this regulation. SAS Drug Development provides compliance tools that allow
it’s licensees to enable these requirements. Login credentials, version control, audit trials, and access groups are
some of the tools that can be utilized.
The focus of the paper will be on controlled access for users of SDD. Controlled access to data, programming
areas and results ideally are functionally based on the users role in clinical trials analysis and reporting. Thus,
work processes serve to guide the design of an administrative model to manage and organize clinical trials analysis and reporting. Work processes can be represented in a logical manner in the design of a standard directory
structure which facilitates the tasks. SDD allows licensees to create and organize their own directory structures
and access groups to fit their needs. In the next few sections of this paper the implementation of an administrative model which achieves controlled access by modeling work processes will be presented.
DESIGN OF ADMINISTRATIVE MODEL
Within the SDD environment, administration of restricted user access beyond initial login is best achieved through
access groups applied to directories (container objects within SDD). The rationale for the use of access groups is
to provide more efficient administration than would be possible by granting access individually to each user. Similarly, the application of these access groups to directories provides more efficient administration than would be
possible by granting access to each individual file contained in the directory. This means that careful thought
should be given to the organization of directories since they drive the SDD administrative model.
A project can be thought of as the basic high level organizational unit that a uniform set of subdirectories originate
from. In this pharmaceutical example, project refers to all studies associated with a specific compound. In order
to maintain an administrative model that can be easily extended to new projects, it is important to organize directories in the same manner for each project and to apply directory naming conventions consistently.
In designing the directory structure for your projects, an important consideration is the work processes of each
role that will utilize the SDD repository. For purposes of this paper the scope of these activities covered by clinical trials analysis and reporting will include creation of analysis datasets and programs for safety and efficacy reporting, exploratory analysis, generation of reports and analysis results, creation of submission deliverables Items
8, 11, and 12, and assembly of deliverables into clinical study reports and marketing applications. Phase I, II and
III clinical trials in humans are the studies focused on. Statisticians, programmers and clinical personnel are the
main roles involved with these activities within SDD.
The next section will provide details on a proposed directory structure that organizes the work processes and input to these activities described above. Moreover this organization serves to facilitate managing user access.
1
NESUG 2006
Posters
DIRECTORY STRUCTURE OVERVIEW
Based on the standard set of regulatory deliverables and user roles described in the previous section, it is possible to create a logical directory structure that is reusable for each project. Logically clinical trials analysis, reporting and filing activities may be best organized by protocol within each compound. Since personnel with different
roles may be involved with analysis, reporting and filing activities, it is recommended that these staff have separate work directories for their protocol tasks. Additionally, for items that are input to or facilitate analysis and reporting, it may be helpful to place them in separate directories. Clinical data is an example of an input to statistical analysis and reporting. A SAS macro library is an example of something that facilitates both statistical analysis and reporting. Keeping the data and macro library separate from the statistical analysis and reporting directories will avoid replication of the information under each area. This is desirable from the standpoint of maintenance considerations involved with keeping the replicated information in synch in each directory where it is duplicated. Figure 1 gives an overview of this structure.
SDD
|___ „ Compound1
|___ „ Reporting
|___ „ Protocol001
|___ „ Protocol002
|___ „ ….
|___ „ Statistical-analysis
|___ „ Protocol001
|___ „ Protocol002
|___ „ ….
|___ „ Esubmission
|___ „ Protocol001
|___ „ Protocol002
|___ „ ….
|___ „ Data
|___ „ Protocol001
|___ „ Protocol002
|___ „ ….….
|___ „ Clinical-tables
|___ „ Protocol001
|___ „ Protocol002
|___ „ ….
|___ „ Compound2
|___ ….
|___ „ Macrolibrary
Figure 1 - Overview of directory structure
The description, associated task and user role of each directory is explained as follows:
Directory name
Description
Task
Personnel / role / access
Reporting
Safety and Efficacy programs and
analysis datasets for regulatory reports
Efficacy and exploratory analysis programs
Items 8 and 11 datasets and define
documents, Item 12 eCRFs
Source clinical study data
Programming
Programmer (read/write)
Statistical analysis
Statistician (read/write)
Programming and documentation
Read only retrieval
Programmer
/
Statistician
(read/write)
Programmer / Statistician /
Clinician (read)
Clinician (read)
Programmer (read/write)
Statisticalanalysis
Esubmission
Data
Clinical-tables
Efficacy and Safety tables for regulatory
reports
Macrolibrary
SAS macros used by all projects
Retrieval by clinician, statistician
Written by programmer
Programming and statistical
analysis
2
Programmer (read/write)
Statistician (read)
NESUG 2006
Posters
Figure 2 - Directory descriptions
This directory model assumes that programmers and statisticians have distinct activities that are part of their job.
However, depending upon project resourcing, it is possible that one person may perform the activities of both the
programmer and statistician, for example. In that case, the standard directory structure depicted would not need
change. Someone performing dual activities can be granted access to all the work areas needed through the
administrative model access groups. This flexibility allows for a logical directory structure that is reusable for
each project no matter who is performing the activities.
A standardized approach to organizing work in a reusable directory structure provides consistency from project to
project. This benefit allow staff to move rapidly from project to project since they can easily locate files and data.
Moreover, a standard directory structure allows access groups to provide access consistency within and among
projects and activities. The next section will provide details on proposed access groups.
ACCESS GROUPS OVERVIEW
Generally, access groups are populated with individuals who perform the same functional roles. Programmers,
statisticians, clinicians and security administrators are examples of functional roles. In order to restrict access to
specific projects or other work areas, access groups are applied to individual directories within a standard structure. Generally, each directory found below the directory to which a access group has been applied inherits the
access characteristics of it’s parent. If an individual is not assigned to a specific access group, then that individual will not be able to see the directory or any directories below to which that access group has been applied.
Several different types of access groups are helpful in administering SDD which are explained as follows:
Access group
High level directory access:
Administrator group
Macro library maintenance group
Macro library access group
Project level directory access:
Project level access group
Activity level groups within a project
Description
Typical membership
Manage access for entire SDD
Maintain macros in library
View / copy macros in library
1 or 2 administrators
1 or 2 programmers
All programmers and statisticians
View high level project directory
Access activity directories to perform tasks
Programmer, Statistician, Clinician
Varies by role
Figure 3 - Access group descriptions
Access groups applied to high level directories serve one of 2 functions. They exist to provide either management capabilities or read access to directory and subdirectory contents. An administrator group which is applied
at the root level directory of SDD allows security administrators to manage directory access for the entire SDD
repository. A macro library maintenance group applied to a high level macro library directory used by multiple
projects allows assigned staff to manage the macro library contents. Finally, a macro library access group allows
programmers and statisticians read access to a departmental macro library.
Access groups applied to project directories provide one of 2 types of access. The project level access group
provides the ability to view the compound level directory for a specific project. This access group is applied to the
compound level directory so that no subdirectories are visible or accessible. Activity level access groups provide
the ability to view and access specific subdirectories beneath the compound level directory. Membership in one or
more of the activity level subdirectories such as, reporting, statistical-analysis, or clinical-tables means that the
individual will be able to see and access the respective activity directory and all subdirectories. These access
groups are applied to each of these subdirectories found beneath the compound level directory. For example,
someone with membership in the compound1 project level access group, and subsequent statistical-analysis,
data and clinical-tables access groups will see the following directories in SDD:
3
NESUG 2006
Posters
SDD
|___ „ Compound1
|___ „ Statistical-analysis
|___ „ Protocol001
|___ „ Protocol002
|___ „ ….
|___ „ Data
|___ „ Protocol001
|___ „ Protocol002
|___ „ ….….
|___ „ Clinical-tables
|___ „ Protocol001
|___ „ Protocol002
|___ „ ….
Figure 4 - Access group directory view example
Figure 4 illustrates that SDD access groups not only limit access to the contents of certain directories, but limit the
visibility of these directories. The only individuals who are able to see the entire SDD directory structure are the
security administrators. In the next section, we’ll turn to the specifics of project access groups.
ACCESS GROUPS SPECIFICS
For each project, it is recommended that a standard set of access groups are created within SDD. It is helpful if
these project access groups follow a standard naming convention for ease of administration. In this example,
each project access group reflects either a job role (programmer, statistician, clinician), input to a task performed
(data), or an activity associated with the project (esubmission deliverable generation). Using this information as
part of the access group name in conjunction with the project name serves as metadata to help identify the directories to which the groups are applied and determine appropriate membership for the groups. The access group
naming convention, directory it is applied to, members and access for each access group is explained as follows:
Group name
Directories
Members
Access
Project
Project-programmer
SDD\project
SDD\project\Reporting
SDD\project\Clinical-tables
SDD\project\Statistical-analysis
SDD\project\Clinical-tables
SDD\project\Clinical-tables
SDD\project\Esubmission
SDD\project\Data
Programmer, Statistician, Clinician
Programmer
Read
Read,write,delete
Read,write,delete
Read,write,delete
Read
Read
Read,write,delete
Read
Project-statistician
Project-clinician
Project-esubmission
Project-data
Statistician
Clinician
Programmer
Programmer, Statistician
Figure 5 - Project standard access groups
Access groups can be applied to multiple directories and may assign different types of access for each specific
directory. For example, the project-programmer access group provides access to 2 directories: one the Reporting
directory where safety and efficacy programming is performed, the other the Clinical-tables directory where safety
and efficacy tables are stored for retrieval by the clinician and statistician to aid in writing regulatory reports.
SDD provides 4 different access levels: read, write, delete and manage. Access is customizable by the SDD administrator and some users. Manage access allows for management of the permissions and access groups assigned to a directory. This access will be discussed in the special access groups section next.
SPECIAL ACCESS GROUPS
Certain situations such as interim analysis necessitate special access groups to meet the need to restrict access
to a very limited number of staff. In this situation a special access group is created ad hoc and applied to the pro4
NESUG 2006
Posters
tocol level directory relevant to the interim analysis. For example, a statistician involved in interim analysis for
Protocol 001 of Compound 1 would need restricted access to the Statistical-analysis, Data and Clinical-tables
directories as follows:
SDD
|___ „ Compound1
|___ „ Statistical-analysis
|___ „ Protocol001
|___ „ Data
|___ „ Protocol001
|___ „ Clinical-tables
|___ „ Protocol001
Figure 6 - Special access group directory example
Group name
Directories
Members
Access
Project-protocol001-statistician
SDD\project\Statistical-analysis\protocol001
SDD\project\Clinical-tables\protocol001
SDD\project\\Data\ protocol001
Statistician
Read,write,manage,delete
Read,write,manage,delete
Read, manage
Figure 7 - Special access group example
Here the administrator would set up the special access group, assign the statistician to the group and apply it to
the directories where restricted access is needed. As a final step administrator and project team access to these
directories is shut off. This is accomplished by the manage access type assigned to each folder which gives the
statistician the ability to manage access groups assigned to the directories. As noted earlier a general administrator group is applied to the entire SDD repository at the root directory. With manage access, the statistician is
able to turn off access for the administrator group to these folders. Similarly, the statistician turns off access for
the standard project access groups to these directories. SDD provides the capability for users to customize access restrictions to specific folders on an ad hoc basis to meet the needs of special circumstances.
CONCLUSIONS
The SDD access model proposed in this paper is based on a standard directory structure that represents a consistent work process for clinical trials analysis and reporting from project to project. This paper suggests that a
standard organizational structure for project directories and application of standard project access groups will facilitate the ease of administration of controlled user access within SDD. Additionally, standard naming conventions for directories and access groups help provide a self documenting access model for your projects.
While SAS Drug Development was written to address specific regulatory requirements of the pharmaceutical industry, the concepts presented here may be applicable to other industries where restricted access is important.
REFERENCES:
Handelsman, David. SAS Drug Development Vision and Roadmap. SAS Institute, Inc., January 2006
Reap, Chuck. “A Regulatory Compliant Process for Developing SAS-Based Reports,” Proceedings of the Thirtieth
Annual SAS Users Group International Conference.
SAS Drug Development Version 3.2 Documentation, SAS Institute, Inc., February 2006
5
NESUG 2006
Posters
SAS Drug Development Version 3.0 Training: Administration, SAS Institute, Inc., February 2005
ACKNOWLEDGMENTS
SAS® and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS
Institute Inc. in the USA and other countries. ® indicates USA registration. Other brand and product names are
registered trademarks or trademarks of their respective companies.
CONTACT INFORMATION
Your comments and questions are valued and encouraged. Contact the author at:
Margaret M. Coughlin, MPH, MS
Merck Research Laboratories
P.O. Box 1000, UG1D-88
North Wales, PA 19454-1099
Phone: (267) 305-6813
Fax:
(267) 305-6474
Email: [email protected]
6