Building a Powerful Clinical Decision Support System Using SAS/IntrNet

Transcription

1 Paper AD15 Building a Powerful Clinical Decision Support System Using SAS/IntrNet Nick Pászty, XOMA (US) LLC, Berkeley, CA ABSTRACT Simply put, SAS/IntrNet is very clever at providing flexibility to do essentially one thing: web-enable your SAS data. This paper will present some helpful strategies and techniques we used to develop a Clinical Decision Support System (CDSS). Considerations relating to navigation, data presentation, cross study standardization, browser versus file system output destinations and use metrics are presented. In addition to the SAS language, integral technologies like DHTML and JavaScript will be briefly discussed. INTRODUCTION Our CDSS system is a SAS/IntrNet based application that contains the following 7 menu selections through which reports and data can be run and accessed. 1) The Ad Hoc menu renders an interface through which ad hoc queries can be requested and run. 2) The Efficacy menu renders an interface through which study specific efficacy reports can be run. 3) The Safety menu renders an interface through which standard safety summary reports and listings can be run. These include adverse event, annual report, concomitant medication, demographic, disposition, drug safety, exposure, lab test plot and summary, mortality, PD plot and summary, screening, vital sign plot and summary reports and listings. 4) The CSR menu renders an interface through which study specific documentation like the Protocol and Statistical Analysis Plan files can be accessed as well as a web-enable Table of Contents (TOC) interface from which pre-defined reports can be run. 5) The Sites menu renders an interface through which standard and study specific patient enrollment and site information reports can be run. 6) The Xplore menu renders an interface through which study specific analysis, raw and multidimensional data sets can be listed and downloaded into Excel. The Xplore component is a SAS/IntrNet out-of-the-box functionality that has been slightly altered to fit the CDSS architecture. 7) The Data Review menu renders an interface through which study specific case books and other data collected in the clinic such as images can be viewed. In addition, data integrity and edit check reports can be accessed and dynamic patient profiles, data set contents and data distribution and univariate reports can be run. A large part of being able to do what the title of this paper states is having a powerful set of standards in place that include standard directory structures and standard programming practices. The goal of this paper however is to neither be-labor that concept nor to describe how we implemented our standards. Instead, the goal here is to share some of our experiences related to the front end development of our application. In addition, I will describe some of the behind the scenes concepts that are central to the purpose of developing this kind of application in the first place. The paper is organized into the following sections. 1. Technology Essentials. There are some fundamental truths that are held to be self-evident. So as to level the playing field, a few basic concepts need to be understood. 2. Navigation. One of the most critical elements of an online application is its usability, which relates directly to navigation. I chose to use DHMTL menus as our springboard to standard cross-study access and a simple HTML frameset that maintains access to study specific menus while simultaneously presenting a data-dashboard and standard forms used to render reports. 3. Rendering the Interface and Reports. A useful approach to rendering an interface should consider authoring by way of data driven implementation over authoring by static means. I chose to use a file system, data set attribute and data driven interface implementation to facilitate cross study standardization. 4. Browser vs. File System Output. One might typically think that the output destination of a SAS/IntrNet application is a web browser fair enough, makes sense. My feeling on that is that it is only a small part of the goal. There is no reason why the same programs that render output to the _webout filename can not be used to generate output to the file system with accompanying logs a practice that adheres to typical file system programming and auditing requirements. 5. Use Metrics. If you build a system but do not have the means to measure how it is being used then it is difficult to make any decisions on how to improve it for maximizing user experience. Through customizing my web server log file configuration I can render reports through SAS/IntrNet to facilitate reporting site usage metrics that reflect the architecture of the system.

2 1. TECHNOLOGY ESSENTIALS i. ABOUT THE COMMON GATEWAY INTERFACE (CGI) SAS/IntrNet uses CGI technology, which means that it works by interfacing with information servers such as web servers to execute a program that returns output based on a dynamic query. The components of the query are in the form of a series of variables and values referred to as key/value or name/value pairs I prefer the latter. A Uniform Resource Locator (URL) containing name/value pairs passed to the SAS/IntrNet CGI broker script may look something like this: hostnm=server.corp.com&name1=alfred&name2=e. The CGI relevant parts of the URL start to the right of the?. Each name/value pair is separated by an &. In the SAS/IntrNet world, the value to the left of the equal sign becomes the name of a global macro variable and the value to the right becomes that macro variable s value. So in the example above, the hello.sas program can resolve the &hostnm, &name1 and &name2 macro variables to the values server.corp.com, Alfred and E. respectively. In an HTML page that contains a form, the form action attributes are values that make up the CGI portion of the SAS/IntrNet URL. For example, the following SAS statements author hidden form field objects that make up part of the SAS/IntrNet URL. put "<form action=' put "<input type='hidden' name='_service' value='default'>"; put "<input type='hidden' name='_debug' value='&debug'>"; put "<input type='hidden' name='_program' value=' demosp.hello.sas'>"; put "<input type='hidden' name='hostnm' value='&hostnm'>"; put "<input type='hidden' name='name1' value='&name1'>"; put "<input type='hidden' name='name2' value='&name2'>"; The names of the form objects (input boxes, select lists, radio buttons etc.) can be used as global macro variables in the program referenced in the URL. This elegant functionality is what makes SAS/IntrNet very easy to use for web enabling your SAS data the rest however is up to you. ii. ABOUT SAS/INTRNET, HTML AND JAVASCRIPT Contrary to what I occasionally hear, HTML is not a programming language, it is simply a formatting language and is nothing more than ASCII text typically saved in a *.htm or *.html file. This characteristic makes it easy to write a SAS program that renders HTML by using data _null_ and put statements. The reserved filename, _webout is used to direct the HTML to a web browser rather than to a file. If the following SAS code was stored in a program whose name was hello.sas (as in the URL above), it would author an HTML page with the greeting Hello there Alfred E.! in green bold face Arial font and push it directly back to the web browser that called the program via the CGI broker through the example link above. file _webout; put <html> ; put <head> ; put <title>demo HTML Page</title> ; put </head> ; put <body> ; put <table> ; put <tr> ; put <td><font face= arial size= 2 color= green ><b>hello there &name1 &name2!</b></font></td> ; put </tr> ; put </table> ; put </body> ; put </html> ; More complex program snippets that render HTML are presented in section 3. below but this example should serve to get the basic concept across. In agreement with what I typically hear, JavaScript is a programming language but as a scripting language, is also nothing more than ASCII text. This makes it easy to write a SAS program that authors JavaScript by using data _null_ and put statements. For my purposes, I write JavaScript into the HTML head tag and I have chosen one of these scripts to present in the JavaScript section below. 2. NAVIGATION i. DHMTL I have too often heard that SAS/IntrNet applications produce dynamic HTML (DHTML) reports. DHMTL has nothing whatsoever to do with what SAS/IntrNet is typically used for that is returning the results of a dynamic query in the form of a report displayed in a web browser. The report might be rendered in any one of the ODS output formats but will for the most part never be DHTML. DHTML is implemented through JavaScript and it is a layer of HTML that is rendered

3 dynamically as a result of some user event executed on an object that is defined in the static HTML. The CDSS uses DHTML menus as the starting point navigation utility because of its flexibility and ease of implementation. There are several DHTML sources on the Internet but my favorite is dynamicdrive.com. It provides a fine selection of free DHTML menuing scripts and more so don t re-invent the wheel just make sure to include the source information when you use their code. ii. HTML FRAMES The CDSS is implemented using a classic upper-lower type frameset. This layout format creates an easy way to maintain a persistent menu in the upper frame and dynamically render content in the lower frame such as forms and reports. The example below is my cdss_frame.sas program and it renders a home page for any protocol that has been defined to the CDSS. file _webout; put "<html>"; put "<frameset rows='130,*' framespacing='0' border='0' frameborder='0'>"; put "<frame name='cdss_menu' scrolling='no' noresize target='cdss_main'"; put "src=' %nrstr(&_program)=cdssbin.cdss_menu.sas"; put %nrstr(&hostnm)=&hostnm%nrstr(&lprot)=&lprot%nrstr(&uprot)=&uprot'>"; put "<frame name='cdss_main' scrolling='auto'"; put "src=' %nrstr(&_program)=cdssbin.cdss_home.sas"; put"%nrstr(&hostnm)=&hostnm%nrstr(&lprot)=&lprot%nrstr(&uprot)=&uprot'>"; put " <noframes>"; put " <body>"; put " <p>this page uses frames, but your browser does not support them.</p>"; put " </body>"; put "</noframes>"; put "</frameset>"; put "</html>"; As you can see from the code, the frames are actually populated by content that is rendered by two other programs called through SAS/IntrNet URLs. These two programs make use of the &hostnm, &lprot and &uprot macro variables to produce the following study specific interface included as Figure 1. Figure 1

4 Though it is not apparent, the menu is in a separate upper frame and will persist as selections are made from it. The data dashboard is in the lower frame and will be replaced by whatever content is generated as a result of selecting the different menu items. This architecture facilitates consistent cross study navigation that maximizes usability and minimizes confusion. iii. iv. HELP FEATURE It is very useful to be able to offer an easy access help feature when doing so facilitates user/application interaction. My help system is accessible through small hyperlinked images like this one. I use a simple JavaScript to popup a window that contains relevant help information for example on box plot or shift table interpretation or on how to fill in a form if free text is allowed. How to format a subject list that can be used to subset a listing to only include certain subjects is a fine example of the latter. All the popup screens are invoked by one JavaScript function that is written into the HTML <head> tag by a SAS program. I won t include it here because it is too long, but me if you would like it. RE-AUTHORING A FORM It is very useful to be able to re-author a form based on a user selection in that form. For example, you would want to present different form objects if a user selected a shift table lab report vs. a markedly abnormal lab report. My favorite example of this however is to be able to change the _debug value in the SAS/IntrNet URL so that debugging is made very simple on a development server. In the example URL I included in section 1. i. you can see that all my programs can reference the &hostnm macro variable. This makes it easy to do different things on different servers. By having a form select object named debug and using the following JavaScript, I can change the value of the _debug value from 0 (don t debug) to 131 (debug) without touching the original SAS program that rendered the HTML page containing the form. <script language="javascript"> function reauthordebug(selind) { //--Evaluate the selected form field value and modify the _debug value accordingly. if (selind==0) {newurl=' er.corp.com&lprot=protocol&uprot=protocol&protocol=protocol&debug=0'} else {if(selind==131) {newurl=' rver.corp.com&lprot=protocol&uprot=protocol&protocol=protocol&debug=131'};}; //--If the new location value is not blank then replace the location with the new URL. if (newurl!= '') { location.replace(newurl); } } </script> The JavaScript function is called by creating the debug select object tag like this. put <select size='1' onchange='reauthordebug(this.options[selectedindex].value)' name='debug'> ; put <option value='0' selected>no</option> ; put <option value='131'>yes</option> ; put </select> ; Some additional coding I do for user feedback is to have the appropriate option selected when the HTML page is reauthored. This is done by adding the selected attribute to the appropriate option as in the value= 0 option above. If the user had selected Yes, then the selected attribute would be applied to the value= 131 option of this select object. The debug select object is only rendered when the &hostnm macro variable resolves to my development server but the same functionality of maintaining the selected option(s) is very important when you choose to enhance any interface with re-author functionality. 3. RENDERING THE INTERFACE AND REPORTS Though there is a basic amount of non-changing HTML that the CDSS interface relies on, the functional objects are either rendered through information retrieved from the file system, from data set attributes or from data. This implementation allows the CDSS to render dynamic interface objects to provide flexible cross study standardization. If you need to pass macro variables and their values from one program to the next then the hidden input type form object is a reasonable technique to use. The CDSS reporting architecture is supported by a pair of programs for a given report type. One is a program that renders the HTML form through which a query can be built and the other is a selector program to which the form hands the query. For example the demographics report is generated by a user selecting values from a form rendered by the demographics_form.sas program which hands the query selections to the demographics_selector.sas program which in turn calls the selected program to run a report based on the given query. The form programs all contain some degree of data driven rendering and selector programs are either auto generated or a static SAS program with dynamic functionality that allows more than one reporting program to be run for a given report type. The laboratory plots form included as Figure 2, contains some static, some data set attribute driven, some data driven and some hidden form field objects. The flexibility inherent to this architecture supports seamless cross study standardization.

5 Figure 2 i. DATA IMPLEMENTATION Data are used to render the functional objects in the interface such as select boxes. The Ad Hoc interface functionality serves as a good example. The challenge here is that I do not know how many ad hoc requests there will be or when the programs might be completed so I need to build a select box with dynamically generated option values for the interface. When an ad hoc report is requested through the interface, the request is stored as an entry in a SAS data set. The following code will render a select box containing ad hoc request titles based on title values in the data set. * sort data set before rendering select list; proc sort data=&lprot.d.clin_pgm_reqs out= clin_pgm_reqs; by request_title; Data _null_; File _webout; put "<select size='1' name='adhoc_report'>"; put "<option value=0>select an Ad Hoc Report</option>"; set clin_pgm_reqs (keep=request_title) end=lastobs; file _webout; put "<option value="_n_">"request_title"</option>"; if lastobs then do; put "</select></font></td>"; end; When a selection is made, the option value is passed to the selector program where it is resolved as the value of the adhoc_report macro variable s value. An array described in the next section handles the request and runs the selected ad hoc program. There are many applications for data driven rendering but this example should serve to get the basic concept across on how to begin the <select> tag, how to populate it with options and then finally close the tag.

6 ii. iii. FILE SYSTEM IMPLEMENTATION Information pulled from the file system such as the existence of specifically named files is used to auto generate code. This functionality is dependent on our standards and would be impossible without them. All ad hoc programs for example are named using the prefix adhoc_. The challenge is to be able to auto generate code that is executed in the selector programs. The following array is auto generated by the SAS program that builds the ad hoc HTML form and is used to handle requests coming from that form. The &adhoc_report macro variable is created by the CGI broker because the ad hoc HTML form contains a select object whose name is adhoc_report. The relationship is incestuous but it works beautifully even under heavy traffic. length ahr 8; ahr=&adhoc_report; array ahprogs [*] $200 ah1 ah2 ah3 ( 'adhoc_acr_20_50_and_70_topline_summary.sas', 'adhoc_acr_20_all_components.sas', 'adhoc_acr_20_joint_counts_alone.sas'); do i=1 to dim(ahprogs); if i=ahr then do; call symput("ahprog",ahprogs[i]); end; end; %inc "/cdm/sasdev/&lprot/sasprog/autoexec.sas"; %inc "/cdm/sasdev/&lprot/sasprog/&ahprog"; DATA SET ATTRIBUTE IMPLEMENTATION Data set attributes such as the existence of a variable or the number of observations in a data set are used to render the interface. I have chosen to use this implementation sparingly because I think that a standardized interface where the user expects to see certain objects creates a less confusing experience than a wildly changing one. An example of where this implementation is useful is the conditional rendering of treatment group selection. If a study only has one treatment group then it seems pointless to render a select object with only one option. To be able to conditionally render HTML but maintain the cross study standardization, I have to use a hidden form object to automatically pass the treatment group variable into the program if only one treatment group exists. First I have to find out how many treatment groups I have and this can easily be done using proc contents. libname colgrp "$&uprot/anldata"; proc contents data=colgrp._patpop noprint out=colgrp (keep=name label where=((index(upcase(name),'tgrp')))); %* assign a value to the global macro variable that controls conditional form page processing; dsid=open('colgrp'); nobs=attrn(dsid,'nobs'); call symput('colgrp',trim(left(put(nobs,8.)))); dsid=close(dsid); By testing the value of the colgrp macro variable that represents how many treatment groups are defined to a study, I can either dynamically render a select object with as many treatment group selections as the study has by using the same strategy as that discussed in section i. above or I can author a hidden form field to pass a required macro variable to the reporting program when the study only has one defined treatment group. put "<input type='hidden' name='colgrp' value='tgrp'>"; iv. RENDERING REPORTS We standardized our reports using proc report output to PDF, RTF and Excel and SAS/Graph device= and target= values of sasprtc for PDF and png for RTF. Custom styles created with proc template are used to minimize any reformatting required by the technical writers as they incorporate our reports into the Clinical Study Report (CSR). I also chose to render certain reports with dynamic drill down capability for accessing subject level data from a summary report. There are required statements for rendering PDF, RTF and Excel and SAS/Graph output through the _webout file handle. Here are examples of how to accomplish that.

7 PDF %let rv = %sysfunc(appsrv_header(content-type,application/pdf)); ods pdf notoc body=_webout style=cdss.cdss_style; RTF %let rv = %sysfunc(appsrv_header(content-type,application/msword)); ods rtf body=_webout style=cdss.fsf_style; Excel %let rv = %sysfunc(appsrv_header(content-disposition,attachment%nrstr(;) filename=&pgmname..xls)); ods html body=_webout style=cdss.fsf_style; Note: The html is rendered using well defined table, row and column tags that are easily read and converted into rows and columns in an Excel spread sheet. SAS/Graph The same ODS directives will work for SAS/Graph output but you will need to specify the device and target values mentioned above in your goptions statement. I use the following code inside proc report to implement dynamic drill down capability. The dynamic drill down string is created by resolving macro variables that are carried through the SAS/IntrNet URL described in the examples above. urlstring=' &_program=' "&lprot" 'p.patprof_l.sas&hostnm=server.pharma.com &lprot=' "&lprot" '&uprot=' "&uprot" '&odsfmt=' "&odsfmt" '&subjid=' c&i; To implement this drill down using the urlstring value, I use a call define statement in proc report. call define(_col_,"url",urlstring); Because of the name/value pair nature of the urlstring variable, the drill down will work across studies as a standard implementation. The one disadvantage to this architecture is that navigation is undesirably impacted. When using the back button to return to the summary page from the subject level page, the original report is re-rendered and therefore slows the user experience. I was hoping to find a way to embed JavaScript into the URL to create a pop-up window containing the subject level data that could be closed to return to the summary page but that apparently is not an available option when using a call define statement with the URL attribute name. I implemented a null report functionality that renders a lack of data notification report to indicate that no records match the particular dynamic query. This is an important user-friendly functionality that is easily implemented by testing the number of records that exist in the analysis data set after it has been subsetted by applying the user defined query. There are several methods one can use to test the number of records in a SAS data set of which the attrn function is my favorite. See section 3. iii for an example. I also implemented a concatenation condition that forces IE to display very small PDF files. This addresses a known bug where under certain version combinations of IE and Acrobat very small PDF files will not display. To circumvent the bug, I add records to the analysis data set used by proc report if that data set contains fewer than 10 observations. The following code introduces the ODS escape character and how to use in-line formatting to add 20 blank records to a small PDF file whose source is a data set containing fewer than 10 observations. * define an escape character for ODS; ods escapechar='#'; file print; _blank="#s={foreground=white background=white}" '' "#S={}"; do i = 1 to 20; put _blank; end; You can refer to Brian T. Schellenberger s paper, Presentation-Quality Tabular Output via ODS, for numerous useful examples on how to use ODS styles. His paper is easily accessible by searching from for the title. 4. BROWSER V.S. FILE SYSTEM OUTPUT Though having an online system like the CDSS is very useful for web reporting, it is really only a small part of the goal of the application. I wanted to be able to use the same reporting programs that render output via _webout to support the in text and after text tables used in a CSR. By leveraging the CDSS reporting programs and implementing the file system functionality we have been able to produce between 60 and 90 percent of our CSR safety related content. In order to do this, I had to design around the following two challenges.

8 i. LOG AND OUTPUT FILES I had to create functionality that would create a log file as part of the audit typically required when running a SAS program on the file system. I also had to create some functionality that would create a pdf and rtf file stored on the file system accessible by our technical writers who compile the CSR. Both of these challenges were handled through the same strategy. First the CDSS reporting programs had to be intelligent to the point of being able to know if they were being run in the SAS/IntrNet environment or on the file system. This is quite easily done through testing for the existence of a unique macro variable generated by our SAS/IntrNet environment. If the macro variable exists then the program sends the output to the web browser via _webout and if not, it calls two macros that create the log and output file pathing and names. The core functionality of the macros is to be able to generate macro variables from name/value pairs that I send in to the execution of the program during batch processing. ii. BATCH PROCESSING THE CDSS REPORT PROGRAMS The sysparm macro variable is used to create the name/value pairs that the reporting program expects to receive through the HTML interface. Here are two example calls that exist in a program that can have any number of these kinds of calls to the reporting programs. The program name that contains these calls is always called cdss_2_fs.sas which is meant to indicate that the programs contain calls to the CDSS programs to direct them to write to the file system. The following call produces SAS log, PDF and RTF files containing the demographics report for all subjects with columns representing the different treatment groups defined in variable tgrp for protocol1 whose names are the concatenation of the sysparm values. The result is the generation of files with these names: demog_all_tgrp.log, demog_all_tgrp.pdf and demog_all_tgrp.rtf. x "sas /cdm/sasapps/sse/sasprog/demog.sas -sysparm 'protocol=protocol1 prognm=demog patpop=all colgrp=tgrp by_group=none' -nolog -noprint"; The following call produces SAS log, PDF and RTF files containing the report of all adverse events summarizing body system and preferred term by race for subjects evaluable for safety with columns representing the different treatment groups defined in variable tgrp for protocol1 whose names are the concatenation of the sysparm values. The result is the generation of files with these names: ae_evsafe_tgrp_race2_all_prefer.log, ae_evsafe_tgrp_race2_all_prefer.pdf and ae_evsafe_tgrp_race2_all_prefer.rtf. x "sas /cdm/sasapps/sse/sasprog/ae.sas -sysparm 'protocol=protocol1 prognm=ae patpop=evsafe colgrp=tgrp by_group=race2 aetype=all sumtype=prefer' -nolog -noprint"; iii. USING THE CDSS_2_FS.SAS PROGRAM AS A NAME/VALUE PAIR DATA SOURCE We can not only use the cdss_2_fs.sas program to push name/value pairs into our standard programs but we can also parse it to produce name/value pairs that can be inserted into a reconstructed SAS/IntrNet URL. This is what we do to create the web-enabled TOC interface included as Figure 3. Figure 3

9 By clicking on hyperlinked table numbers, the report defined in the Statistical Analysis Plan can be generated via a SAS/IntrNet hyperlink that was re-constructed by dynamically parsing the sysparm values found in the cdss_2_fs.sas program. This enhances the user experience in that the system supports two ways to access reports for any given study. For users who are interested in data exploration, the system provides forms from which many different reports can be rendered by modifying the selected values in the available form field objects. For those users who would prefer running the exact report that they would otherwise see in the CSR, the system provides a direct access web-enabled TOC. The following data step snippet contains some of the essential code that begins the process of re-constructing the necessary URL. The process is not unlike that which is used to create the urlstring value in the call define example above in section 3. iv. %* once it is established that the file exists, read the cdss_2_fs.sas into a data set; filename cdss2fs pipe "more /cdm/&lprot/sasprog/cdss_2_fs.sas"; data cdss2fs; infile cdss2fs truncover; input ln $250.; %* only keep records that contain the system parameter values; if (index(ln,'-sysparm') and index(ln,'*')=0); %* create name value pair string from system parameter values; attrib toc_name_values1 length=$250 label='toc Name Value Pairs 4 PGMNAME' toc_name_values2 length=$250 label='toc Name Value Pairs 4 URL'; toc_name_values1=translate(substr(compress(ln,"'"),index(ln,'prognm=')+6),'&',' '); toc_name_values2=trim(left(scan(toc_name_values1,1,'&'))) '.sas&' substr(toc_name_values1,index(toc_name_values1,'&')+1); %* create variable that contains all necessary cgi parameters; attrib cdss_name_values length=$500 label='cdss Name Value Pairs'; cdss_name_values=" %nrstr(&hostnm)=&hostnm%nrstr(&uprot)=&uprot%nrstr(&lprot)=&lprot %nrstr(&protocol)=&uprot%nrstr(&odsfmt)=pdf%nrstr(&_program)=ssebinp." toc_name_values2 ; Once these hyperlinks are created as variable values in a data set, they can easily be applied to HTML statements to render the web-enabled TOC page in a data _null_ using the _webout filename and put statements as we have seen in the previous sections. 5. USE METRICS It seems a little short sighted to build a web-enabled application and not design for use metrics analysis. In order to do this properly, you need to configure your web server log files so that the relevant fields are captured for analysis. Here is my log file directive from my httpd.conf file that captures all the relevant fields necessary to run reasonable analysis given the context of our network. LogFormat "%h %l %u %t \"%r\" %>s %b \"%{cookie}n\" \"%{Referer}i\"" combined_ngp. The focus of this paper is not to go into a detailed explanation of non-sas technologies so for further understanding on web server configuration visit apache.org and search for LogFormat. Web server log files are text files that contain the http requests sent back to the web server from the browser and as such are easy to read with SAS. The benefit of writing SAS programs that generate use metrics is that you can pinpoint the most heavily used parts of your system and focus enhancements accordingly. Depending on your network and or application authentication design, you can even run analyses on how individuals are using your system. To organize my web server log files, I implemented a script that roles the log files daily, making them available for parsing with my SAS program. The core functionality of parsing web server log files is through the user friendly string functions such as index, scan and substr. Because the CDSS is a cross study system, I chose to create my use metrics drill down by first creating a chart of use over time and hyperlinking the legend to drill down into use metrics for a given study. The drill down produces a report for each of the seven CDSS areas as well as including what form selections were made most frequently. The best advice I can give for creating these kinds of reports is to use the examples in the online doc for SAS/Graph and couple that with what you may have learned in this paper on how to build a SAS/IntrNet hyperlink dynamically to generate reports. CONCLUSION SAS/IntrNet is a fantastically flexible tool whose only limitation may be your imagination and creativity. The really tough part is in the implementation of standards in support of scalable cross study functionality and integration of SAS/IntrNet driven systems into your workflow. There are several technologies that I have not touched on like XML that will become central to Clinical systems as electronic submission standards become better defined. ODS does include an XML output destination however so I plan on including that aspect into subsequent version of the CDSS.

10 REFERENCES SAS OnlineDoc, Version Eight, Copyright (c) 1999 SAS Institute Inc., Cary, NC, USA. All rights reserved. All rights reserved ACKNOWLEDGEMENTS I would like to thank Sun Sook Kim for her guidance in developing the CDSS reporting specifications and Mei Lu for her expertise in Clinical Trial Programming. Without their contributions, CDSS interface concepts presented in this paper would have simply been the carriage without the horse. CONTACT INFORMATION You can contact me at: paszty@xoma.com SAS and all the rest of the SAS stuff 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. Some restrictions apply, void where prohibited what me worry, me got SAS.