1

Getting so Much when Reviewing Data with Touch

Sy Truong, Meta-Xceed, Inc., Fremont, CA

ABSTRACT

Data reporting with SAS in the form of data listings for summary tables are becoming antiquated in the era of multi-touch tablet and mobile computing. SAS is a very powerful analytical tool and traditionally has a robust set of reporting tools. However, ODS is showing its age as people are finding other ways of accessing and reviewing their data in addition to a desktop computer or on hard copy. As users shift from sitting at our desk towards reviewing clinical data on mobile devices, we need a new SAS option, or perhaps a "PROC MOBILE". This paper presents a novel approach towards summarizing data into a format suitable for mobile consumption. It takes advantage of the multi-touch interface of tablets such as the iPad and provides users with an intuitive method for navigating and reviewing clinical data. It shows a new method where users can easily transform their data into an XML format that is read as input into an iPad app named ClinTouch. More tablet computers are now being purchased compared to laptop and desktop computers. Rather than scrounging through paper or PDF reports, this paper presents an innovative new way of efficiently reviewing clinical trials data.

INTRODUCTION

SAS has many data visualization tools. Even during its early main frame implementation of SAS/Graph, there has been a visual representation of data. Although this project did not necessarily share any original code with the original SAS/Graph output, its roots can be traced back to when the output looked similar to this example.

The reason that the graph is displayed in this manner was due to the fact that it was printed on a dot matrix printer that only had alphanumeric characters as a method of display. At that time, there was no other way of rendering

2

graphical charts displaying different data values such as in a bar chart. The need to display data more visually for this project was born from data that was originally published on websites which leveraged upon SAS/Graph output. The following example shows HTML output generated from SAS/Graph with the image generated as a GIF file.

As compared to its earlier predecessor, this graph is vastly improved with color bars rendered in a simulated three dimensional cylinder, rather than a flat bar. It is also more interactive since there are hyperlinks which the user can click on to drill down to more details graphs or data listings. This HTML graph worked well when the user was on a desktop computer with a keyboard and mouse. However, it did not function optimally when being viewed on a multi-touch screen of an iPad. On the iPad, it had to be viewed through a web browser such as Safari and did not take advantage of the native iOS multi touch environment. The navigation was fair but it performed rather awkwardly. For instance, it had no way of receiving pushed notification when the graph has been updated. Push notification is a common feature within iOS and other mobile operating systems where the user is notified either through a popup or a red numbered icon indicating that there are updates to be viewed. When HTML graphs were originally developed for this project, it was met with a discouraging unenthusiastic response. Due to the lack of user acceptance, this method of viewing through web browser on a tablet was ruled out. The HTML viewing user experience on a tablet was short lived. After just a few views, they would either give up or went back to their desktop and viewed the same HTML report on their desktop work stations. The next step was to explore visual graphical output solutions that were native iPad apps developed from SAS. The hope was that it will deliver native iOS user experience while leveraging the SAS code and programming experience which the user were familiar with on the server. Among the tools evaluated includes: SAS Mobile BI iPad app and JMP iPad app. Example screens for these tools can be seen here:

3

Since these are actual iPad apps, they did resolve some of the issues compared to the web browser method. The navigation and use of multi-touch was more responsive with a native application. However, it did not take advantage of all the features of iOS such as the push notification mentioned above. In addition, there were other challenges which were difficult to overcome for this particular project. These challenges are summarized here.

1. Additional Software – The SAS Mobile BI required additional SAS BI suite of software on the server which

was not available to this project. The JMP solution also required an entirely new set of JMP tools which was not available for this project. This project was limited to BASE SAS and did not have many of SAS BI modules available.

2. Support and Administration - The team members that were assigned to this project were SAS

programmers. They were familiar with writing SAS program scripts, but were new to using tools for BI such as SAS Management Console. The implementation of the BI tools would require the additional support staff to administer SAS BI and/or JMP.

3. Bottom Line – The budget for this project was limited and it boiled down to cost. There was some budget

for development but no additional budget for the two points above including additional software, support and administration costs.

Once the above project considerations were evaluated, this excluded the above options. The final charter for this project was to develop a method of presenting data in a visually compelling way, but not too overly complex or difficult to use and deploy. These were intended to be viewed by data managers and research associates. The reports were not intended for statisticians who may have more statistical sophistication requiring certain types of graphs. Based upon these user requirements, the iPad StockTouch app was reviewed and deemed to have some of the qualities needed for the requirements for this project. It was easy to use, intuitive, and took full advantage of the multi-touch iPad environment. The only thing it lacked was that it was intended for financial stock data and not used with clinical data. Besides this crucial requirement, it presented financial information quite elegantly and effectively. When the user first open the app, the first view, referred to as level one, shows nine different sectors of stocks including categories such as: Technology, Financial, Healthcare, etc…

4

This is a global view that helps the user quickly compare different industry and see which one is doing better compared to the others. The squares with shades of green indicate the amount of positive change while different shades of red illustrate declines. The drill down to a particular industry such as Technology can be accomplished by tapping on anywhere inside the square region or pinching with two fingers.

This zooms into a new view or level two that displays the top 100 stocks within the technology sector and their changes. Similar to all of its screens, the user can pinch or tap on one of the individual squares to drill down to detail

5

information pertaining to that individual stock. Within seconds, the user can gain a good understanding of how the market is doing. This became the model for how this project was to be implemented. The code name for it then became “ClinTouch” which was analogous to the “StockTouch”. The obvious difference is that the data will be clinical data rather than financial stock data. The challenge was to figure out an easy and secure way for users to upload their clinical data to a secure server and the same visual display similar to StockTouch will be made available. The process starts with the users who created the SAS datasets. These users are referred to as data stewards. They consisted of SAS programmers and Biostatisticians. The task of uploading the clinical data was applied by the data stewards so the process was catered to meet the requirements of these users. The next section in this paper will describes the steps taken to accomplish this objective.

PREPARING CLINICAL DATA FOR MOBILE

ClinTouch expects your data to be in standard CDISC SDTM datasets. These are commonly saved as two characters named dataset including examples such as: Adverse Event (AE), Demographics (DM) and Vital Signs (VS). The datasets are originally created on a SAS application server residing within the organization. The datasets are then converted into XML format and then uploaded to a secure web server. The iPad app then downloads this data after the user authenticates. Once the data is downloaded, the user can then view this data even in they are in airplane mode. The data flow diagram which illustrates this is shown below.

SAS Application Server Secure Web Server ClinTouch iPad App

This upload process is applied by the clinical data stewards who are usually very experienced SAS and use it as one of their main tools. Because of this, two SAS macros are used to upload the data. The first one is a SAS macro named %clinuser. This macro will sets up and configure the user who will be downloading the data on their iPads. The partial documentation for this is shown here: %clinuser (username=User Name,

param=Configuration Parameter,

value=Configuration Value

);

Where Is Type... And represents...

username C (required) The unique user name. This can be an email address or a unique text value with no spaces or special characters.

param C (required) The configuration of a user includes specified parameter types. Valid parameters are listed below. The short name is what is specified but a description is listed to clarify.

1. Organization - The name of your organization or company. 2. Password - The current user password needed to access the

data. 3. Read - The value of this is "Yes". It will allow the user to read

the data but not share the data. 4. Share - The value for this is "Yes". This will allow the user to

both read and then share with others. 5. Add - This will add a new user. In this case, the value will be the

6

password for the user.

6. Remove - This will remove an existing user. In this case, the value will be the password for the user.

value C (required) This contains the values corresponding to the parameters specified. Some values can only be "Yes/No" while other parameter values can be open text up to 40 characters.

This macro can be called multiple times to set configuration options for each user. It manages the information by inserting rows into a dataset as a way of managing user permissions and settings. Example calls would look like:

*** Set up a New User ***;

%clinuser(username=sytruong,

param=Add,

value=mypassword);

%clinuser(username=sytruong,

param=Organization,

value=My Company);

%clinuser(username=sytruong,

param=Share,

value=Yes);

%clinuser(username=sytruong,

param=Password,

value=newpassword);

*** Remove example user ***;

%clinuser(username=sytruong,

param=Remove,

value=mypassword);

Once the user has been established on the SAS server, the next step is to start to upload data. This is accomplished through the %clinload macro. This will convert the existing SAS datasets into an XML format used by the iPad app. The data is uploaded to a secure server where it will be stored inside a mySQL database. The partial documentation to this macro is shown here: %clinload (dataset=SAS Dataset,

username=User Name);

Where Is Type... And represents...

dataset C (required) This is a two level library and dataset name. The dataset name needs to be in CDISC two character format. An example value would be: INLIB.AE

username C (required) This is a user name that has been registered to the server. A user can be registered through the macro %clinuser.

ClinTouch algorithm has been applied to CDISC SDTM datasets since many organizations are applying this standard. This macro assumes that the user has already been setup through the %clinuser macro. The upload will rely on the configuration of the %clinuser to authenticate before uploading. An example upload call is shown here:

*** Upload AE dataset ***;

%clinload(dataset=INLIB.AE,

usernamm=struong);

This macro verifies user and then uploaded the specified dataset to the correct location according to the profile defined in %clinuser. The macros accomplish the secure data upload using a SAS filename with URL access method. An example is shown here:

7

*** Create a Filename to the remote secure server ***;

filename clintouch url

'https://meta-x.com/clintouch/upload.php?file=data01.xml'

user='struong' prompt;

The process of writing an XML file from SAS is trivial. However, the process of uploading this to the secured server requires a few more options which are slightly different. These are intended to add security to the data which will be described in more detail in the next section. The options that are unique to this steps are described below:

1. URL – The URL option allows for the SAS program to write a file to a remote web server. This is different than

the common local file system. 2. User – A valid user name is defined on the web server. This means that this user name has to be previously

defined on the server before the user can upload. 3. Prompt – The password can be inserted directly into the SAS program but that would not be very secure. An

alternative is to use the prompt. When the program is executed, the user is prompted to enter their password. These options allow the SAS program to securely generate the XML file directly on the remote web server.

SECURED CLINICAL CLOUD DATA

Data security was required to be implemented through the entire process for ClinTouch. This was particularly important during the data transfer between machines. From the data flow above, additional measures had to be applied during each step of the transfer. STEP 1 – Secure SAS Application Server

The SAS programs that upload the data to the web server apply several layers of security. Some of the elements were touched upon in the sample FILENAME statement mentioned in the previous section. The security three layers include the following:

1. SSL Encryption – The use of the HTTPS protocol utilizes a secure socket encryption layer. This means that

the XML file is encrypted before it is uploaded between the SAS machine and the ClinTouch web server. 2. Web Authentification – The file on the web server is user and password protected. The user would need an

account and passes this user name and password through the FILENAME option and when prompted. 3. mySQL Database – This is inserted in a mySQL database through the use of a PHP script. The user needs

to have access to the database in order to upload the data. These layers of security ensure that only the user with the correct permissions will be able to upload to their specified user account on the server. The iPad user will also be presented with an additional log in account information before they can view the uploaded data. The section of code that applies these security measures are shown below:

*** Transfer Data from SAS Server to Web Server ***;

filename dupload url

'https://www.meta-

x.com/clintouch/uploadata.php?user=sy.truong&org=MXI&filename=abc.xml'

lrecl=1000

prompt;

One of the ways to not have the password revealed in the SAS log is to apply the “prompt” options which allow the user to enter the password during execution while masking it in the log. This is prompted when the SAS program is executing:

8

Even though It prompts the user name and then the password from the SAS program, it was originally defined on the web server. STEP 2 – Secure Web Server

When the data is transferred from the SAS server to the Web Server, it uses https which encrypts the data being transferred using a secure socket layer. This helps with the security during transfer. The programs that process the data and the storing of the data needs to be secured on the Web Server itself. The web server used for this project is Apache and a file named .htaccess created to lock the folder access is created with the following code:

## AuthName "the protected directory"

AuthType Basic

AuthUserFile "/usr/home/ www/htdocs/clintouch/.htpasswd"

Require valid-user

## end basic auth

All the PHP scripts used to upload the data is therefore secured. The SAS program that uses the “prompt” option mentioned above will pass the authenticating user name and password to the web server. The valid users that has been authorized and configured by the web server would then have access to upload data to the secure directory. The PHP scripts on the web server handle the upload to the mySQL database. The code segment to perform this task is shown here:

<?php

/* Define connection string to the mySQL database */

$con = mysql_connect("localhost","adminuser","AdminPassword");

/* Check if the connection is valid */

if (!$con)

{

die('ERROR: Cannot access the database: ' . mysql_error());

}

...

This code will log onto the SQL database with the correct user name and password. This is stored inside the program logic but the program is locked from viewing from the .htaccess described above protects the password and only allow the database administrators and developers to access these scripts. If the data tables stored on mySQL were to be created and updated by users through their own logic, a Access Control List (ACL) would need to be implemented. However, in this implementation, all scripts developed to handle the upload of the data to be delivered to the iPad are fully controlled by the ClinTouch developers and database administrators. Due to this level of control, the data tables are made available to these PHP scripts and no additional ACL are implemented. STEP 3 – Secure iPad

The iPad downloads the data from the web server in a similar way that the SAS servers access the web server. It is accomplished through the standard HTTP protocol much in the same way a web browser accesses the web server. The difference is that the programming language that is used to communicate to the web server is a different language with different syntax. In this example, it utilizes Objective-C which is Apples variant on the C programming language used to develop iOS apps such as the ClinTouch for iPad. The following example is the code use to read

9

the data through the help of a PHP script on the server. NSString *str=[NSString stringWithFormat:@"https://meta-

x.com/clintouch/getxml.php?user=%@&pass=%@" ,username,password]; NSLog(@"%@",str);

NSMutableURLRequest *request = [[NSMutableURLRequest alloc] initWithURL: [NSURL URLWithString:str]];

[request setHTTPMethod: @"GET"]; NSString *authStr = [NSString stringWithFormat:@"%@:%@",

@"clintouch", @"ClinTouch123"]; NSData *authData = [authStr dataUsingEncoding:NSUTF8StringEncoding];

NSString *authValue = [NSString stringWithFormat:@"Basic %@", [authData base64Encoding]];

[request setValue:authValue forHTTPHeaderField:@"Authorization"];

NSURLResponse *response; NSError *error;

NSData *returnData = [NSURLConnection sendSynchronousRequest: request returningResponse:&response error:&error];

NSString *returnDataString1 = [[NSString alloc] initWithData:returnData encoding: NSUTF8StringEncoding]; If you are familiar with how the HTTP works, it has different methods of requesting data from another server. Two of the common ways is POST and GET. The method that was used on the SAS program is POST which is intended to submit data to the server. As the name suggest, the program on the iPad performs a GET which request and “get” the data from the web server. The programming language of Objective-C is compiled and the executable binary that the users download to the iPad does not reveal the source code. This adds a layer of security in that the user can not parse through the code from within the App to try to reverse engineer and access the data. The XML data is converted into a array and stored in memory. Due to the compiled nature of the programming logic, the user cannot easily access this data. The program also has the option of expiring the data so it will automatically deletes the data downloaded from the website after a specified number of days. It is analogous to the Mission Impossible movies in that the message will self destruct after it is used.

10

In this example “Settings” screen, the duration is set to 19 days. This means that after nineteen days after the data was originally downloaded, it will be deleted from the iPad and no longer available to the user. The user has the option of downloading the latest version of the data found on the server. The multiple layers of security applied in all three steps as described above ensure that the data being transferred from one machine to another is secured. This starts from the SAS programmer on the server and follows all the way to the user reviewing the data on the iPad.

OPTIMALAL DATA VISUALIZATION ON TABLET

As analogous to the StockTouch app, the newly developed ClinTouch app reads the XML file that is produced from the SAS program and displays the data visually in three different levels. The first level is a bird’s eye view of the data. The example shown below is a view of Adverse Event data group by body systems.

Each body system in this example is labeled on the upper right of each of the nine sections. These represent the top nine body systems which contain adverse event information. There may be other body systems which contain very few adverse events and thus not included in this view. The preferred adverse event terms are displayed in very small text intentionally since this is only intended to provide a high level view with the option to drill down. The view is designed to distinguish the adverse event by different shades of colors as shown in this example:

11

The different shades can be applied by the user on the server side during the XML file creation. In this example, the frequency of the adverse events has been partitioned into evenly distributed buckets with the highest count shown in red while adverse events with less frequency appearing in green. The colors have different shades to distinguish different degrees within each color. In this screen, the shades include:

1. Light Red 2. Medium Red 3. Dark Red 4. Light Green 5. Medium Green 6. Dark Green

The human eye can only distinguish a certain amount of different colors to make informative inferences based on these distinctions. The above grid only shows six different shades but it could have been applied with more. There is a point of diminishing return since more shades does not add value to the reviewer since they start to be visually overloaded and can no longer draw meaning from the shades. This is particularly true when applied to the categorical data that is collected. In the above example, the colors are based upon frequency counts of adverse events. However, this could have been applied to other categorical variables for adverse event data. Other examples include:

Adverse Event Severity Relationship to AE Serious AE

Mild Not Related Yes

Moderate Possibly Related No

Severe Probably Related

Related

If these criteria were used for the color shading, the number of categories would be less than six so the use of six colors will cover most meaningful categorical analysis. The user can pinch or tap on a portion of the display on level one and it will drill down to level two showing one of the nine sectors. An example of the adverse event category “Respiratory”, it will drill down to a level displaying the following:

12

On level two, it takes one out of the nine sections from level one and then enlarges it to display on the entire screen. On level two, each cell contains text that can be more legible as compared to level one. There are two parts of the text being displayed. The top label is bolded and is shorter with the “…” indicating that there is more to the entire text. The second text description is displayed underneath the label is smaller and can fit more text. In this example the top text is the preferred adverse event term. The text below displays the adverse event severity followed by a number representing the number of occurrence or frequency count of the adverse event. The dataset actually only had 24 adverse event but the XML was mocked up for to illustrate the view duplicating the last term. The user can view further detail by tapping on a particular cell or pinching upon the view and it will zoom into one particular cell. In that case, the entire screen can display information about that adverse event. This level three can be used to display a data listing or a SAS/Graph output displayed in a similar way that the predecessor output produced in the HTML report. The distinction is that the user can navigate to this data point on level three with much more precision based upon the three levels with the use of colors and grid navigation.

13

SHARING DATA

Communicating data effectively requires context. This means that the person sending the message has to describe the data in words, yet those words describe the dataset or data points within the context of the communication. This can be challenging when the dataset is large with many different metadata relating to each data point. The ClinTouch approach accomplishes effective communication by allowing the user to communicate when reviewing the data on any level as described above. The reviewer initiates the communication by taping on the camera icon on the lower right to capture a screenshot of the current view. The name of the dataset is automatically pasted into the label of the email subject while the app also allows the user to annotate using their finger to draw red lines indicating what data point is of interest.

Additional text can be added to the email as this send directly to a data manager or statistician needed to clarify on a data point. The requirements from the users which drove this communication method included the following.

1. Data Context – The ability to communicate information as it is contextually related to the dataset or data point

of interest.

2. Ease of Use – The user can leverage their understanding of other communication tools such as composing an

email or a drawing tool for annotation.

14

3. Communication Infrastructure – There are many different

communication protocols and email was determined to be the most universal that already exist, so there is no additional infrastructure that needed to be developed.

The use of the above communication method placed on every screen of the system accomplished effective communication without requiring additional overhead from the server setup or from the user learning having to learn a different way of messaging.

CONCLUSION

Communicating effectively through visual and graphical representation has been in existence as far as pre history times. The tools that are available to enable the communicator to express himself more effectively has changed. Viewing the dot matrix printout of SAS output of bar graphs can be as arcane as cave paintings in the post PC era with ubiquitous multi-touch mobile devices. Data visualization on a mobile device such as an iPad is a very unique and method of reviewing data compared to traditional reports from SAS ODS output. This requires a different and new SAS technique, leveraging the ground breaking multi-touch interface while taking advantage of existing communication methods such as email. This paper presents a new method and approach by combining the use of Mobile Computing to allow clinicians, statisticians and SAS programmers a expedited way of deriving clinically significant conclusions to clinical data.

CONTACT INFORMATION

Your comments and questions are valued and encouraged. Contact the author at:

Name: Sy Truong Enterprise: Meta-Xceed, Inc. Address: 42978 Osgood Rd City, State ZIP: Fremont, CA 94539 Work Phone: 510-979-9333 Fax: 510-440-8301 E-mail: sy.truong@meta-x.com Web: http://meta-x.com

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 trademarks of their respective companies.