Modular processing for Prep-to-research analysis- interfacing XML, SAS and Microsoft Excel David C. Tabano, Kaiser Permanente, Denver, CO

Transcription

1 Modular processing for Prep-to-research analysis- interfacing XML, SAS and Microsoft Excel David C. Tabano, Kaiser Permanente, Denver, CO ABSTRACT Healthcare research is often preceded by a prep-to-research (PTR) phase, or probing available data sources for a breadth and depth of information sufficient to pursue particular study aims. This process involves investigators and analysts working together iteratively through queries, summary statistics and power analyses, which often yields new queries and analyses. The PTR process can thus be lengthy and cumbersome as investigators present queries that require extensive and unique coding on the part of the analyst, and may not necessarily generate the desired results from a lack of articulated parameter guidelines. PTR can become even more challenging in multi-site research environments, where multiple sites are queried for preliminary analysis, each with different programmers and dataset nuances. The ability of investigators to clearly propose analytic questions to analysts and programmers is paramount to developing distributed code and query processing across distributed research networks sharing a common data model. This paper attempts to mitigate this process with additional tools for analysis. The methods presented support the use query generating tools found in XML syntax, and query development in the form of modular, parameterized SAS code using SAS macros and DATA Step Hash Objects, exporting results into a user-friendly Microsoft Excel workbook. The combination of both back-end and front-end processes in readily available software allows for improved transferability of PTR queries across sites in a multi-site, common data model research environment. The goal of this paper is to provide Analysts and programmers with the means to interface more efficiently with investigators and researchers in the PTR process by providing a more formal and defined method for investigators to submit queries to their analysts. INTRODCUTION Preparing for research involves development of a hypothesis and gathering preliminary data to support a formal analysis of the hypothesis. The PTR phase can consist of data sampling from prior research, exploratory analysis of sample databases and data mining, but the end result is to generate data cohorts for which power analyses can be conducted to validate the use of data for hypothesis testing. In healthcare research, PTR is formally defined at the beginning of the study through the researcher s governing body to ensure Protected Health Information (PHI) is safeguarded under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy and Security Rules. HIPAA governs all medical data and is designed to protect patients from unauthorized disclosure of their health data. PHI is patient-level data of any kind, mental health-related data, and data related to sensitive populations including the elderly and patients of particular disease states. While the interpretation of HIPAA varies by study design, governance at a research site, and state and local legislation (which can be more stringent than federal HIPAA laws), PTR is typically approached from a minimal necessary viewpoint of the data, avoiding results or analysis that produce sensitive data or PHI of any kind if possible. PTR rarely returns individual, patient-level data for analysis- instead, crosstabs are generated based on population demographics, comorbidities, etc. with counts that can be used for power analysis and summary statistics. PTR in a Distributed Research Network (DRN) is traditionally performed in one of three ways- 1. The lead site programmer writes a distributed code based on knowledge of other sites and distributes the program to site programmers to run and return results. 2. The lead site programmer writes a program for their own site data and extrapolates parameters (orders of magnitude) to estimate returns from other sites. 3. The lead site programmer writes out the study parameters and guidelines for PTR and distributes the guidelines to each participating sites programmers, who will write code and return results based on these guidelines and their knowledge of their own data. Each of these methods has benefits and disadvantages when performing PTR. The first method s value is contingent on the lead site programmer s knowledge of both their own site s data nuances and every other site s data, as the lead programmer is charged with writing a PTR query that will successfully run at each site. This first method is best suited for DRNs that share a common data model across sites, where each site s data is structured and formatted in the same way. The second method is easier for a programmer to accomplish as it requires writing one query against their own data. This method can generate bias, however, based on the prevalence and outcomes of disease states in each site s population, the sample size of the population itself (the smaller the population, the less reliable the rates of particular disease state may be), as well as sample bias from coding and data nuances at each site. The third method for PTR requires no additional programming from the lead site programmer and eliminates the bias from calculating 1

2 extrapolated rates for other sites, but it is subject to multiple interpretations of the study parameters and is contingent on each site s programmer s knowledge of their data and SAS programming expertise. In short, while PTR analysis often generates nothing more than simple counts of patients with particular disease states and outcomes, generating valid results and correctly aggregating the data across a DRN can be difficult. MEHTODS FOR PTR SAS programmers can mitigate the variability of the PTR analysis within a DRN by automating the PTR wherever possible. Code used for prior studies capturing similar disease states or building similar cohorts can be recycled and reused in new programs. Returning results in acceptable formats (crosstabs, PROC FREQ, etc.) to investigators can be streamlined into output commands using macros and other automated functionality. Maintaining a database of known data nuances across sites within a DRN helps programmers identify and track issues, allowing for more efficient code development. Several DRN already employ these techniques in some capacity. The Cancer Research Network (CRN) 1 and Cardiovascular Research Network 2 (CVRN) have created web portals where programmers within each DRN can provide information on their site s data, access code libraries and share coding and processing techniques for studies within the DRN. PopMedNet TM3, an umbrella for several DRNs, has constructed web portals for sharing information on the network s sites data and study aims and progress. PopMedNet TM also provides a DataMart Client for transporting data securely within its network, and has web-based query tools that generate PTR parameters for queries at the sites in the DRN. All of these DRNs have two key elements that help minimize bias in PTR for their studies. First, each of these DRNs adhere to their own common data models; that is, each site within a DRN builds their datasets in the same structure (variable names and formats, source data (where applicable), variable identification, etc.). By using a common data model, both investigators and programmers have a better understanding of what data are available at each site within the DRN and can more easily write code to pull data from each site without relying as heavily on local programming expertise. Second, each of the aforementioned DRNs have created web-based forums that allow programmers to share SAS code for analyzing and manipulating their DRN data. Sharing ready-made code, whether simple scripts that perform merges or joins across datasets or complicated macros that process data in a routine way, gives programmers more freedom to modularize their SAS code when developing programs for PTR or more sophisticated analysis. Sharing information on the development of the common data models and programming techniques for each DRN allow programmers to work across sites in creating/updating their data in a more efficient manner. STRUCTURED PTR ANALYSIS One of the DRNs under PopMedNet TM is the Scalable Partnering Network for Comparative Effectiveness Research 4 (SPAN), which is a study designed to implement an innovative, sustainable, distributed data network with enhanced capabilities to support comparative effectiveness research (CER). One of the goals of the study is to create a more efficient way to perform PTR in a DRN environment. The solution was to create a menu-driven user interface to conduct simple queries against multi-site data for CER, generating simple counts for preliminary analyses, power analyses and general PTR. The SPAN query tool differs from other query engines in that the tool was created to fit the underlying data, as opposed to modeling the data to the functionality of the tool. Because the query tool is a webbased platform, the tool generates an.xml parameter file to its DRN, which is translated into macros by a SAS program that runs a series of modular code (macros in a particular code structure) based on the parameters. The 1 The Cancer Research Network is an NCI-funded consortium of 14 integrated healthcare systems across the United States that conducts innovative programs of research on cancer prevention, detection, treatment, long-term care, surveillance, and survivorship. The vision of the CRN is to increase the effectiveness of preventive, curative and supportive interventions for major cancers, through a program of collaborative research that spans the natural history of major cancers among diverse populations and health systems. 2 The Cardiovascular Research Network (CVRN), funded for 5 years by the National Heart, Lung, and Blood Institute (NHLBI), is a national collaborative and resource that will leverage expertise, populations, and data sources from a consortium of 14 geographically diverse health plans (7.6 million members) in the United States with integrated research divisions. 3 The PopMedNet TM application was developed under Contract No from the Agency for Healthcare Research and Quality, US Department of Health and Human Services as part of the Developing Evidence to Inform Decisions about Effectiveness (DEcIDE) program, awarded to the DEcIDE centers at the HMO Research Network Center for Education and Research on Therapeutics (HMORN CERT) and the University of Pennsylvania. The Food and Drug Administration s Mini-Sentinel project (Contract No. HHSF I) provided additional support. 4 Funded under Contract No. R01HS (Scalable PArtnering Network for Comparative Effectiveness Research [SPAN]) from the Agency for Healthcare Research and Quality, US Department of Health and Human Services as part of the American Recovery and Reinvestment Act, awarded to Kaiser Foundation Research Institute on behalf of Kaiser Permanente Colorado Institute for Health Research and network sites. PI: Matthew F. Daley, M.D. 2

3 program then generates reports which are output into a Microsoft Excel workbook. The SAS program itself is static; the.xml parameter file is variable. The structure of the query tool allows users to perform PTR against multiple sites, querying patient-level data in a common data model while returning de-identified, aggregate counts of patients with particular disease states and outcomes. The design of the SPAN query tool is indicative to the PTR process. The construction of a query is built to reflect logic of building a cohort, based on an observation period, index variable and other inclusion and exclusion criteria. The flow diagrams are example of the query tool design. A cohort for PTR consists of selecting the following- 1) An Observation Period, or period in which an event in a patient s medical history has taken place. 2) An Index Event, the variable that reflects the event/exposure of interest which each patient must have to be included in the cohort (cohort of patients with hypertension, for example, may have define an Index Event as the first record of an ICD-9 diagnoses code of within the observation period). The Index Event represents the key variable for the construction of a cohort, defined by a common event within an observation period. 3) A corresponding Index Date, or date in which the event/exposure took place. This date must lie within the observation period. 4) For HMO sites, enrollment criteria can be selected to further refine the cohort. Enrollment represents the history of the patient within a particular health service provider network. Enrollment can be very important in PTR in that it can be used as a proxy for patient records over time. It can be beneficial to account for enrollment (or to omit patients without a sufficient enrollment span prior or post a given event/exposure) during PTR to obtain more accurate measures of the cohort population. For example, a study requiring detailed medical history of a patient population may want to include enrollment parameters in a PTR analysis to increase the probability that the cohort will have sufficient enrollment for chart review for reference during the study. Patients with long enrollment periods both before and after an event/exposure will likely have more data available on their medical history for investigators to use in more formal analysis following the PTR phase of a study. 3

4 5) Inclusion criteria are additional, optional events/exposures investigators may wish to include in a PTR to further refine the cohort. Inclusion criteria are used in addition to the initial inclusion criteria query variable that patients must have in order to be included in the final cohort. 6) Exclusion criteria are additional, optional events/exposures investigators may wish to include in a PTR to further refine the cohort. Patients with an exposure to an exclusionary variable are omitted from the cohort. 7) Finally, once the PTR has been successfully defined, investigators will select Data Marts (sites within the DRN) to submit the query. The SPAN query tool limits flexibility of more robust, free-form queries in favor of simplicity for easier use and more rapid query response. The underlying SAS processing to generate any given query, while static, is considerably complex in order to accommodate the many options available within the query mechanism itself. The next sections briefly describe the input parameters, namely the.xml and associated.map files, as well as how they are read into SAS for processing. XML and SAS Extensible Markup Language (XML) is a language developed to allow data and its associated formats to be read by different software types. XML is hierarchical and in a textual format and is the primary means in which data is shipped over the internet. XML data can be read by many different software programs, from MS Excel to SAS. Because of the embedded metadata describing the format of the data in an.xml file, XML an transport both the data itself and the appropriate code to instruct other software how to read, interpret and display the data. There are several sources that available to users wishing to learn more about XML, its construction and implementation. This paper will assume users are familiar with the basic functionality of XML with the next few examples. Below is an example of an XML parameter file from the SPAN query tool. The parameters of the query are presented in the elements represented in black. Broadly, the query contains metadata on the query itself (query name and type, submitter address) an observation period begin and end date, flags for continuous enrollment, an index variable of an ICD-9 diagnoses of Diabetes or Diabetes Mellitus among patients 20 years old or older. The query requests two crosstab reports- a count of patients by Year, Race and Gender, and report by the Index Variable categories from the ICD9 diagnoses list, Year and Age, stratified by 10-year increments. 4

5 Query Metadata Enrollment Criteria Observation Period Index Event/Exposure Variable Age Exclusion Criteria Report 0 Report 1 Report 2 Report 3 Report 4 SAS XML MAPPER SAS has developed add-on software to mitigate XML into a schema that can be easily translated into by SAS into datasets. The XML Mapper (available in SAS 9.2 and above, or can be downloaded from the SAS Support website reads XML files and generates a SAS.map file that works as a schema between XML and SAS. XML Mapper displays the XML file, XML Map and other files in a graphical form, making interpretation easier for users unfamiliar with the XML code. The following screenshots are an example of the SAS XML Mapper. The window on the left contains the open XML parameter file in the XML Mapper session. The window on the right holds the parameter Map schema created by XML mapper from the XML file. The window at the bottom contains the actual code from the XML Map file from the window on the right. 5

6 Query Metadata Observation Period Enrollment Criteria Index Event/Exposure Variable Age Exclusion Criteria Reports XML Mapper can automatically create a XML Map from the XML file opened in the window on the left by clicking the green XML Mapper button at the ribbon on the top left of the screen. The XML Map appears in a graphical tree chart in the window on the right. The chart contains specific mapping information to be read into SAS with the accompanying XML file. The mappings provide naming conventions (should users want to change the name of a particular parameter automatically upon import into SAS), which can be found under the Properties tab at the top of the window. 6

7 Additionally, the mapping provides a means for users to format of parameters being imported into SAS. The Format tab allows users to adjust the format of parameters being imported from the XML file, including length of the field and SAS format and informat structure. The syntax for these formats can be seen in the bottom window under the XML Map tab. This window displays the code that makes up the XML Map schema read by SAS, including data descriptions, formats and informats. Note that the syntax also describes the how the XML file will be structured in SAS (column names represent a variable in a dataset, for example). 7

8 The XMLMAP syntax accounts for multiple query options that can be generated at the XML file. In the case of SPAN, the Index Event/Variable can be represented by ICD-9 Diagnoses, ICD-9 and CPT Procedure or Prescription Drug generic name categories. These subcategories must be accounted for in the XMLMAP syntax to ensure the.map file can transform any and all query parameters from the XML file. Like XML syntax, the XMLMAP syntax follows the hierarchical data design, where a table can contain one of several possible variable names and formats. The XMLMAP code below shows how the Index Variable table, defined first, contains multiple definitions for each possible exposure group for a given query. Each exposure group, defined as a subcategory under the Index Variable table, is a possible parameter than can appear in any single query. For example, a query containing an ICD-9 diagnosis of hypertension will contain a variable of index_code value of dx, which will correspond with the diagnosis formatting in the.map schema. 8

9 Index Variable formatting Index Event subcategory Diagnosis formatting Index Event subcategory Diagnosis code formatting Index Event subcategory Procedure formatting Index Event subcategory Procedure code formatting A completed XMLMAP can be opened in XML Mapper and viewed graphically. Note that the map in the viewer, like the code used to create it, should contain every possible category and subcategory for each query option, even though a given XML parameter file will only contain a specific set of parameters (one Index Variable exposure per query). 9

10 Index Variable formatting Once the XMLMAP is complete, it can be saved and used to import the XML files it is mapped to. A LIBNAME XML statement invokes the SAS XML engine and can create a library mapping to.xml data, and the XMLMAP option allows for the.map file to be mapped with the import so that the XML file is read by SAS correctly. After the library XML is defined, the XML parameter data can be viewed in the SAS explorer window like any other SAS dataset in a defined library. For reading and manipulating the data, it is recommended to import the data into the WORK library following assigning a library. MODULAR SAS CODE AND PROCESSING PTR REQUESTS USING SAS Writing programs in modules gives SAS programmers greater flexibility in using fewer programs (or fewer edits to programs) to handle a wide array of PTR requests. This paper defines modular SAS code as simply a means of 10

11 organizing SAS code through the use of macro programs and macro parameters to account for different steps in the query process. Rather than writing long programs in a series of DATA steps, modular programming puts the DATA step processing into macros that can be modified and moved as a block within the SAS program itself. Modular SAS programming allows programmers to write code in a sequence to accomplish more in a single program without having to code an entirely new program from scratch, or heavily edit an old program, for a new PTR request. Programs that build upon one another in steps to generate queries based on ordinal conditionals can make coding PTR for studies with different parameters but similar query structures much more efficient. The following flow diagram broadly defines how modular SAS code is used in the SPAN DRN for processing PTR requests. The code uses macros defined in both an imported STD_Vars.sas program (read into the program using a %Include statement), an import of the XML parameter file and accompanying XMLMAP file, and several macros in %STEP1-3 for the actual PTR query processing and aggregation of the exposure group. Finally, a %REPORTS macro is used to process the requested reports for output back to the investigator. Import XML, Parameterize into macros Import Parameters PROC FORMAT options %Import Identify Observation Period, Index Variable and Enrollment Criteria Process PTR Query Process cohort for additional Inclusion/Exclusion Criteria %PTR_Processing Count patients by Index Variable, Year, Inclusion Criteria (if any) and patient demographics (age, gender, race, etc) Summarize, Aggregate Cohort Process tables by Report&i macros %Summarize Export Reprots into MS Excel Reports and Query Reciept %Export The first step to the modular SAS program is importing the parameters from the XML parameter file into a format that can be used readily throughout the remainder of the program. One of the easiest ways to manipulate parameters in SAS programming is by transforming them into macro variables. The DATA _NULL_ statement below is an example of how to accomplish this for the metadata in the imported XML parameter file. Since the metadata for the query (name, type, submitter , and observation and enrollment periods) are all contained in a single dataset, the DATA _NULL_ command can read each of these variables into macro variables for processing through the remainder of the program. Additionally, the Index_Variable dataset, which contains the parameter flag for which exposure group is being analyzed in the PTR query, can be read into a macro variable &index_code. 11

12 Formatting the output of the PTR query can be perfomed at any point in the program. Using PROC FORMAT, aggregation for reporting can be accomplished easily. The following two examples use PROC FORMAT to code for 5-, 10-, and 20-year age groupings. Additionally, the PROC FORMAT Value Count statement controls aggregate counts of patients for low cell sizes 5 by changing values less than or equal to 6 as the value HIDDEN in the data. The next step to modular SAS programming is to perform the actual analysis, using the parameters available. The following screenshot is an example of Index Variable processing for an ICD-9 diagnosis exposure group. Like the XMLMAP syntax, the modular SAS code is written to account for the many possible XML parameters being passed over to the program. Note that this section of the macro begins with a conditional for the &index_code macro. This section of code accounts for sets the macro will perform if &index_code resolves to Dx. The %PTR_Processing macro also contains conditional statements for the other possible &index_code resolutions. By taking the time to code a system that accounts for all the possible parameters being passed over for the PTR analysis, users can rapidly process many more PTR requests without having to start new programs or modify existing ones.the code uses HASH Objects for joining several datasets together, which greatly increases processing DATA step commands by allowing SAS to index datasets on identified keys using temporary CPU space. 5 HIPAA requirements include protecting small patient populations, as these small counts often reflect particular disease states or a particularly-defined cohort that has the potential to be extrapolated back to individuals. Using the VALUE COUNT statement is a great way to avoid potentially releasing low cell counts from any final aggregations. 12

13 Following the identification of the Index Variable, the code selects the list of ICD-9 diagnosis codes and turns them into a macro &index_dx, The entire block of codes are flanked by - each individual ICD-9 code is separated by a and a, using the CATS syntax within the PROC SQL statement From the example above, the DATA step processes HASH objects through a series of embedded sub statements. The KEEP statement identifies the variables to be retained from the HASH processing. Section 1 identifies the first HASH object (a) and labels the variables to be used for the dataset s key (the variable that will be indexed during the HASH processing) and variables to be pulled from the dataset to the final dataset step1. Section 2 performs a second HASH identification (b) on a second dataset, identifying both the key (which is also the common field for the join between the multiple datasets in the DATA step) and variables for inclusion. Section 3 processes HASH objects a and b, which creates a temporary (for this DATA step only) key in each object for faster processing for the remainder of the DATA step. Section 3 also adds the variables identified as data from each of the HASH objects to the DATA step. Section 4 processes the table to which the hash objects will be appended, in this case the & diagnoses dataset. Finally, section 5 processes the conditional statements to complete the first portion of the query, identifying the index_code (exposure) and corresponding date, observation period begin and end dates, and enrollment criteria. The call missing statements identify which HASH object s variables to be included in the merge of the three datasets. EXPORTING RESULTS TO MICROSOFT EXCEL Modular SAS programming can also grant greater flexibility in compiling results without additional manipulation, particularly in instances where the audience of the results may not have access to SAS or has a preference for the format they wish to have their results presented. The following code is an example of two different ways to export SAS datasets into a Microsoft Excel workbook. Both methods are used to account for site variation of SAS versioning. The first export method, prefaced with the conditional macro to run for sites under the &sitecode = NW identifier, uses the excel LIBNAME engine to export the SAS datasets reports 0-4 (report_a_&i) for the WORK library 13

14 into the MYXLS library, identified by the location in quotations C:temp\output\&SiteCode._&QUERY_NAME Results.xls. The macro runs through the %DO loop for &i reports, importing each report into a separate sheet in the &SiteCode._&QUERY_NAME Results.xls workbook being populated. The macro then reads the query receipt dataset, or the dataset containing all of the originally-imported parameter macros, into another sheet in the workbook. The second export method, which accounts for sites other than NW, uses the SAS ODS Tagsets engine to export SAS datasets into an excel workbook. Using ODS Tagsets gives programmers greater flexibility in the format and view of the data in excel with the STYLE= options. The resulting workbook, however, will have the same basic structure as the workbook exported from the LIBNAME EXCEL statement. The following screenshot shows an example of an excel report generated from the ODS Tagsets engine. 14

15 CONCLUSION PTR is a useful tool for preliminary analysis of data and forming hypotheses for formal research. Healthcare research is often preceded by a PTR phase in which cohort populations can be studied for frequencies, summary statistics and power analysis, but the iterative nature of PTR between investigators leading the research and analysts performing the queries that drive the research can be a dubious task without a formal, mutually-understandable structure. Interpreting PTR requests can be challenging for programmers working with investigators with limited knowledge of the underlying data or SAS programming. The PTR process can become iterative between programmers and investigators as they work to translate the study questions into SAS code to generate valid results. One method to get around this translation is to incorporate a parameter file with specific definitions into the PTR process. Terminology that defines an index event or patient enrollment span or an output report can help programmers and investigators remain on the same page as they work through a PTR. This paper presented a means for importing data from XML formats, read into SAS and queried in a modular program designed for efficient processing of data across a DRN environment. While the methods presented here represent one of several ways analysts and programmers can process PTR requests, the goal of this paper was give its audience an understanding of a tested process that accounts for variation across sites in the DRN, provides simple code to account for HIPAA regulations by protecting against the distribution of PHI, and has generated sufficient results in a real-time environment. REFERENCES DelGobbo, Vincent, From SAS to Excel via XML SAS Institute Inc., Cary, NC Dorfman, Paul and Vyverman, Koen, Data Step Hash Objects as Programming Tools Proceedings from the Thirtieth Annual SAS Users Group International Conference, paper 030, Lafler, Kirk Paul An Introduction to SAS Hash Programming Techniques, Proceedings from the Nineteenth 15

16 Annual Southeast SAS Users Group, Paper BB-08, Martell, Carol, SAS XML Mapper to the Rescue, SAS Global Forum 2008, paper 099 Palmer, Michael, XML in the DATA Step, Proceedings from the Twenty-Ninth Annual SAS Users Group International Conference, paper 036, CONTACT INFORMATION Your comments and questions are valued and encouraged. Contact the author at: David C. Tabano Kaiser Permanente 2550 S. Parker Rd., Suite 300 Aurora, CO (303) (work) (303) (fax) 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. 16