A Web Based Clinical Data Browser. Eric Grelak, System Solutions, Inc., Chester Springs, PA Nick Ronca, AstraZeneca, Wayne, PA

Transcription

1 A Web Based Clinical Data Browser Eric Grelak, System Solutions, Inc., Chester Springs, PA Nick Ronca, AstraZeneca, Wayne, PA ABSTRACT A problem many pharmaceutical companies have is making its clinical trial (CT) information easily accessible to authorized nonprogrammers. This situation can be greatly compounded when information is scattered over multiple platforms and legacy systems. The authors describe an n-tier application, which allows the user to access and analyze CT information. The front-end tier is a web browser providing users with a single interface to clinical trail information. Access to information is controlled such that each user receives a different list of available information depending on security privileges. The back-end tiers decide how available information should be accessed, and then retrieves the requested information using a variety of applications (ASP, SAS/IntrNet, Perl, etc.). In addition, programmers can publish their own SAS programs/web applications to the user community. INTRODUCTION AstraZeneca has undertaken a series of mergers in which each pre-merger company had their own CT programming environment. All are very similar in function but each had their differences, such as computing environment, operating system, file structures, variable and data set names. Access to CT information will become much easier in the future as work on all new studies, and some old, migrate to a new computing environment. In the meantime, information is scattered over a variety of machines having different operating systems. Similar non-web based tools existed but were closely tied to their computing environments. As long as data is stored in its original environment it is very difficult for some users to know where the data they need is located and how to actually get to that data. The authors of this paper describe how they used SAS/IntrNet with a variety of other tools to solve the above issues. In addition the Clinical Data Browser (CDB) does more than just browse CT information, it has a simple point-and-click query building tool, can perform basic univariates and frequencies, help check adverse event term-mappings or download data sets in a variety of format. Our solution to accessing dispersed data is storing, in a database table, the location of each resource and how it should be accessed. A resource is defined to the CDB as a directory. The CDB then needs to read the database, get locations and other information, and then access the resource location. User access is controlled at the study and resource level, meaning that a clinical study team can prevent another study team from viewing their data. Resource access is controlled within each study team depending on the job function of the user. These security rules determine each person s access rights and drug-study choices. In the context of this paper SAS/IntrNet and application server are one in the same. DESIGN GOALS Given the current conditions mentioned in the introduction, we had a desire to create an application independent of the CT programming environment. This means the application should be portable to other operating systems. It would not make assumptions about data set variable names, data set names, or the file structure organizing the data. Not being able to make assumptions about the data makes it much more difficult to build an application and will have an impact on how the application will be used. In addition the maintenance cost of the application will increase. We have noticed that many applications are heavily tied to their environment such that any environment change requires a retooling of the application. This can have adverse effects on the business and individuals who rely on an application to such an extent that the application prevents or slows any change the business wants to make. We did not want to create an application that was inflexible or tied to the computing environment. By removing dependence on the directory structure, variable and data set names, any change in the above would not affect the CDB. We felt the savings in any potential retooling of the CDB application would outweigh the tradeoff of a higher maintenance cost. Our number one requirement was to prevent the CDB from imposing rules on the CT programmers. The CDB would be completely independent from how CT programming is performed. In addition, a clinical team would have the last word on security by being able to prevent the CDB from getting to their study s data if they so wished. Programs were written and fine-tuned for speed while graphics were used as little as possible in the resulting web pages. Every click by the user returns information back dynamically, information is never pre-assembled; the CDB works in real-time. A major requirement was the proper enforcement of security. In order to have access to study information thru the CDB a user must be granted access. At an even finer level, the user belongs to a group, determined by their job function, which determines what information, within a study, a given user is able to access. There are various administration levels giving special users extra features. We wanted the CDB to automatically maintain a user session for a specified period of time. A session allows the creation of personal workspaces for each user. A routine was developed to create sticky sessions. This means that if a user started a session on the CDB thru their web browser, went to some other site, and then returned, their old session, if still active, would automatically be picked up again. Cookies were not used anywhere in this application. Once a session is defined, state can be maintained in this session space. Session stickiness limits the amount of sessions that SAS/IntrNet needs to manage therefore increasing performance. A general goal of this application was to ensure that additional functionality could be easily added, and that the application could scale up or down depending on usage. When possible, offload as much processing away from the application server, SAS/IntrNet. We also wanted the SAS/IntrNet programs to run

2 on both Unix and Windows platforms, as CT data is stored on both of these environments. The CDB is just as much an environment as a final application. New features are easily added and updated. Additional application servers can be added as well, something written using SAS Integration Technology components for example. The ability to allow a CT programmer to write their own SAS programs opens the door to create custom mini-applications, for the endusers, by the programming community. The types of information that the CDB must be able to access are the standard SAS types, data sets, and catalogs. In addition we wanted to give users the ability to view reports and listings created by programmers, so the CDB had to be able to handle ASCII text files. With the advent of ODS we also wanted to be able to serve PDF, RTF, and HTML documents. TIERS This application has an N-tier design (see Figure 1) composed of a client, web, database, and application servers. This happens automatically and in the background without the user having to enter a username/password. Once this occurs the application code can use the username to customize the application and perform application level security checks. Apache Apache is used to serve ASCII files, SAS Logs, programs, output, etc. SAS/IntrNet could be used to do this but we did not want to clog-up an application server with simple file serving duties. Offloading this type of processing would leave SAS/IntrNet free to process requests requiring SAS analytics, accessing catalogs, data sets, etc. A problem with viewing large files thru a web browser is that the browser becomes very unstable and slow. Printing a browser's contents often results in incorrect pagination and formatting. To solve this problem a wrapper program was created around the txt2pdf PRO software, by Sanface ( which dynamically converts ASCII output into a PDF document and sends it to the client. Txt2pdf PRO is a very nice tool that handles pagination and allows the insertion of backgrounds, of which we use to put a DRAFT on all generated PDF documents. DATABASE SERVER A database is used at the application level to store the location of resources, how to access resources, and who is able to access each resource. The database stores information associating the resource type with a specific tool built using SAS, ASP, Java, etc. For example, data directories are associated with data querying and analysis tools. Output directories are associated with file browsing and PDF conversion tools. We had originally used SAS/Share, as the database, with constraints and indexes but switched to Oracle for maintenance reasons. The structure of the database can be quite complicated. The higher maintenance costs alluded to earlier are realized in entering information into the database tables. The flexibility that a database provides will far outweigh the maintenance cost. APPLICATION SERVER - SAS/INTRNET Figure 1: Client & Server Tiers WEB SERVER Every web application requires a web server. The CDB uses two web servers at this point. IIS is used as the main site and Apache is used to handle file-browsing requests where IIS cannot reach. IIS Microsoft s IIS was chosen as the main site web server as this is the standard at AZ and is part of a cluster ensuring availability of this tier. The first step in creating a secure application is identifying the user. This is easily achieved by using the advanced security option on IIS. When this is enabled, an NTLM capable client, such as Microsoft s Internet Explorer (on NT/Windows 2000/XP) will, upon successful authentication against the NT domain, offer up the user name to the web server. Development was first started using ASP and SAS/Share. For the most part, we could browse all the same types of data, but we were isolated from the analytics. Graphics creation was slower, and most importantly, no automatic load balancing and session handling. As far as creating web applications, SAS/IntrNet offers more features than SAS/Share. A big performance improvement was gained when we moved to SAS/IntrNet. It should be noted that performance could dramatically differ depending on how SAS/IntrNet is configured. There are three types of SAS/IntrNet application services available, Pool, Socket, and Launch. Launch services can only be used if the web server and application server are on the same machine. Launch service is easier to manage but is more resource intensive as a new process is started for each user request, and lacks load balancing and session capabilities. Socket services allow the application server to reside on a different machine from the web server. A Socket service can contain single or multiple processes listening for user requests. Performance is better as the penalty to start the Socket is paid only once, on startup.

3 Pool services have the advantages of Socket service plus load balancing and easier management. Pool services require the use of an external process called the Load Manager. The Load Manager controls the Pool by handling requests from the Broker, which is installed on the web server, and routes the requests to an available non-active server in the pool. The CDB uses Pool services. user submit two requests to get to a study or take up a lot of space within the browser to navigate to this point. What we did was create a very thin bar as seen at the top of Figure 2. A drop down select control exists for both drugs and studies. After choosing a drug, the study select control is populated using DHTML with the selected drug s studies. If an application requires scalability then Pool or Socket services are your best choices. For more detailed information see the SAS/IntrNet Software documentation. One of the nice SAS/IntrNet features is load balancing. In version 8 and 8.1 we found that the Load Manager was not load balancing correctly. We noticed that all users ended up on the same SAS/IntrNet server. This presented a problem with sessions because a session ties or sticks a user to a particular SAS/IntrNet server. Since SAS/IntrNet handles requests in a serial fashion, we found our requests could become queued to a single server even though the rest of the Pool was available. SAS 8.2 fixes all of this and load balances properly by spreading users over all SAS/IntrNet servers in the pool. We noticed that the statistics data sets, on occasion, can become corrupted and will prevent PROC APPSRV from successfully executing. A routine was created that repaired any damage a data set might have. After doing this we never ran into this same problem again. If you are using the statistics option and for some reason SAS/IntrNet will not start, remove the statistics option and try again. We recommend using the PROC APPSRV statistics option to help keep an application running smoothly. The type of information that you can get out of the statistics data sets are what program runs most often and how long, on average, does it take to complete. You can use the statistics data set to find and improve slow running programs or the program that runs most frequently. After rewriting a program to make it more efficient, you can compare pre and post change execution times. You can also modify the type of information that goes into the statistics data set, as we did with the CDB to add the network ID for each user. We also found that a Pool service with the Load Manager was more stable than a Socket service without the Load Manager. We found that if a Socket service had been waiting a long time before receiving a request, it would often crash. We have not experienced this problem with the Pool service. Perhaps the use of the Load Manager, which periodically keeps in contact with the application servers, helps to keep these servers from experiencing the aforementioned problem. To keep the servers fresh a nightly restart is performed on the Load Manager and Pool. A program (SVRMGR) was written that wraps around the Broker and allows us to easily start, stop, and restart the pool and or Load Manager by using automated batch scheduling tools such as cron or Autosys. CLIENT Figure 2: Study Links After a user selects a study they are presented with a list of resources for that study as well as some information about the study (description, therapeutic area, and drug). Each user may have a different list of drugs and studies depending on access permissions. Information is organized by its type (data set, output, catalog, auxiliary program, etc). Each link, or registered information item, is assigned a certain way in which it will be processed. This enables the CDB to organize a study s data even if information is located across a variety of machines. One of the most important resources within a study are the SAS data sets, which contain clinical trial. Figure 3 displays a list of SAS data sets containing the number of observations, date modified, and data set label. When the mouse cursor is placed over a data set name a floating menu appears giving the user a list of functions that can be performed on the selected data set. Functions such as data browsing, data set and variable information, analysis such as frequencies, univariate, histograms, scatter plots, etc. CDB functionality based on information in data sets can easily be added thru additions to the floating-menus. The CDB can handle directories with mixed engine SAS data, views, and catalogs. The client in this case is Microsoft s Internet Explorer running on Windows The user does not have to sign in and does not get a logon prompt. The system automatically knows who the user is and based on that information handles authentication and user interface customization. This occurs automatically with a NT based client (NT/2000/XP). Having only a single web browser to worry about made development much easier. FEATURES We wanted to keep navigation as simple as possible. Every user needs to choose a drug and study. We did not want to have the

4 Figure 3: Data Sets One option on the hover-menus is to download a data set in a variety of formats (transport using copy or cimport, data sets version 6 or 8, csv, xml). If a user is downloading a data set, the CDB does a client operating system check to set the requirements vector by using the OUTREP data set option. We had written our own program to view the contents of data sets or views as an HTML table rather than use the DS2HTM SAS macro. This not only gave us a big performance boost but the flexibility to customize the returned web page. It should be noted that our program is customized to the environment. One of the options available while browsing a data set is to create a filter, see Figure 4. This functionality is very much the same as SAS s Where statement builder (Data -> Where menu selection from Viewtable) except that users have the option between using a basic or advanced interface, saving and loading their filters. Advanced users have the option to type in additional statements, which can be checked to ensure proper syntax. All analysis and browsing functions have the option to use the Filter-Builder to load or create subsets before moving onward. The Filter-Builder interface also allows users to load patient subsets before browsing or using any of the analytical features present in the CDB. We differentiate between a filter and subset as they can return different information depending how they are used. A subset is a unique list of patients, and is generated from a filter. In the following example a filter is created, against the demography data set, which selects all females over 5 2 and born after 1/1/1953. A user could then select the adverse event data set, load the above filter as a subset and return the adverse event data for all of the patients selected by the filter. Subsets are a way to apply a filter made from one data set on a second, even if the second data set does not contain the variables used to generate the filter. Figure 4: Filter Builder Figure 5 shows a list of static SAS generated output, the size of the file, owner, creation date, and description. The description is parsed from the header of each program. Static output can be returned within the browser as text or can be converted on-thefly into a PDF document and sent to the user. With the advent of ODS the CDB had to be able to view RTF, PDF, and HTML documents. Currently Perl CGI scripts running under the Apache web server handle file browsing. Files having the LST, LOG, and SAS extension can be displayed in a web browser, even if the user has SAS or the SAS Viewer installed on their PC. Another feature of this application gives CT programmers the ability to create their own web-based SAS programs, which we call auxiliary programs. CT programmers can also create web pages for a user to select or enter parameters to be passed to a SAS program. Any user, with the proper security permissions, can run these auxiliary programs. This enables programmers to create their own application under the CDB environment. This means that the programmer does not have to deal with security and session handling, its automatic. Additionally a user can run a program using a subset of selected patients generated by the filter-builder shown in Figure 4. CT programmers have the control to format output as they wish using ODS or they can let the CDB automatically handle web output formatting. This is very convenient as the same SAS program that generated text output, with little or no changes, can be used to generate ODS output sent to a web browser.

5 A help system is available and brings up a separate window with information about the page they are viewing. Those with a certain administrator level will see a button labeled Admin which has a host of monitoring and user tools. One such Admin feature access an LDAP directory for user information such as telephone and address, making it easier for an administrator to correspond with users. CT team leaders, once identified to the system by having a certain administration level, have the ability to display the users having access to their study. As mentioned previously, there is a maintenance cost to administer and enter data into the database tables. We have tried to decrease this cost by creating some basic administrator tools to help with this task. Some additional administration features the CDB has are accessing a LDAP server to help facilitate communicating with users. Server log parsing tools to get more information about the servers in the pool. Routines to create a mini warehouse from the statistics data sets and web server logs, and a front end to this mini warehouse. Also, previously mentioned was the SVRMGR program to help manage the pool and load manager. Figure 5: Output Custom web pages can be associated with SAS programs such that the CDB will retrieve the web page rather than run the SAS program. This allows a CT programmer to create an interface to their SAS programs. The web pages and SAS programs created by CT programmers, are not in directories defined in PROC APPSRV, all are retrieved somewhere from a file system and displayed in the browser, in the case of a HTML file or processed as in the case of a SAS program. Figure 6 shows a listing of SAS programs and a description, which is parsed from the program. As mentioned before, if the SAS program has a web page (HTML file) in the same directory, the CDB knows to retrieve the HTML file rather than run the SAS program. The two buttons at the top of Figure 6 allow the user to load patient subsets, which can be passed to these auxiliary SAS programs CONCLUSION Although the CDB is pointed at clinical data, the ideas and concepts contained in the CDB enable it to be used against any type of data. The fact that the CDB is a web application makes it very easy to access and distribute new features to the end users. There is no client side installation required The environment at AstraZeneca is Unix so the CDB mainly accesses data on this type of machine. We have ported the code to Windows giving the ability for a user to view data scattered among various machines while using the same interface. TRADEMARKS SAS, SAS/Share, SAS/IntrNet, and SAS Viewer are registered trademarks of SAS Institute Inc. in the USA and other countries. Oracle is a registered trademark of Oracle Corporation. Internet Explorer and IIS are registered trademarks of Microsoft Corporation. Autosys is a registered trademark of Computer Associates. CONTACT INFORMATION Your comments and questions are valued and encouraged. Contact the authors at: Eric Grelak System Solutions, Inc. Phone: egrelak@yahoo.com eric.grelak@astrazeneca.com Figure 6: Auxiliary Programs Nick Ronca AstraZeneca LP 725 Chesterbrook Blvd Wayne, PA Phone: nick.ronca@astrazenca.com

6