We hope you'll join us for our 4/23 webinar on using data tables to apply reference ranges and AE codes in OC4. For more information and to register, visit https://register.gotowebinar.com/register/2882170018956684555

Study build planning for SAS 9.3

Hello,
I am new to this and am in the process of building a study that will be using SAS 9.3. From what I have gathered from various resources, I need to avoid partial dates, and stick with 8 character naming conventions. Since I am starting from scratch, any other advice for avoiding errors upon study completion and upload into SAS? Any advice would be greatly appreciated.
Thanks!
Mary

Comments

  • Mary,
    Please look for the post: "RE: [Users] Importing OC Data into SAS" from July. I am pasting my reply to that post below.

    Besides rules about the lengths of item_name and response_label listed in that post, I recommend a lot of testing.
    When we are starting a new study, we do several rounds of testing:
    1) once the excel eCRF spreadsheet is created, we review it to make sure all of the rules referenced in the "RE: [Users] Importing OC Data into SAS" post are met. We also make sure things are spelled correctly, and that only fields that need to be Required are set to Required (it is impossible to make an item not required without a form version change. Another note about required--we don't make anything required (or radio type) in a repeating question group, because then it would be impossible to remove the row is someone accidentally created the row...)
    In this round of testing, we also do cross-form checks. For example, if one form has a response_label/values/options text that creates the format: "YesNo" with values: 1=Yes, 2=No, and another form has the same response_label "YesNo" with different values/options: 1=No, 2=Yes, you will have the wrong format applied in one of those SAS datasets--SAS will only keep one YesNo format, and will apply it throughout the data library. We also compare group names across forms--they can't repeat within a study.
    2) After the forms are loaded into OC, we enter test data and output an .XML file containing that data. We make sure that our SAS programs can read in the data (usually the biggest hurdle), and that the data in the SAS dataset matches what we entered into OC. We make sure SAS labels and SAS formats are applied correctly, that dates are formatted correctly, etc.
    3) Once the forms are finalized and moved to production, we test again when real data are entered.
    Hope that helps. Good luck!
    -Cody
    Cody Olsen, MS Biostatistician
    Department of Pediatrics
    University of Utah
    -----------------------------------------------------------------------------------------
    Rob and other OC users,
    We use the CDISC Procedure to read XML datasets from OpenClinica into SAS. Here is an example of some SAS code that we would use:
    /*** This is a link to the .xml file ***/
    filename forms "";
    /*** This outputs a list of table names (sas dataset names) to the log window ***/
    proc cdisc model=odm read=forms formatactive=YES formatnoreplace=NO;
    odm odmversion = "1.2" odmminimumkeyset=YES longnames=YES;
    datasets;
    run;
    /*** by specifying a table name in the name= argument, this saves a dataset named temp ***/
    proc cdisc model=odm read=forms formatactive=YES formatnoreplace=NO;
    odm odmversion = "1.2" odmminimumkeyset=YES longnames=YES;
    clinicaldata out=temp name="";
    run;
    We currently use SAS 9.3. When we used SAS 9.2, CDISC required an additional installation and modification of the config file. Early versions of 9.2 also required a SAS hotfix.
    We have encountered many error messages when running the CDISC procedure, which are often vague and less-helpful for de-bugging. Some things we have had to do, to make this process work, are:
    - Although we have multiple sites entering data, we haven't been able to use an XML file with metadata for all sites. We have two work-arounds for this.
    o (1) We have manually deleted metadata about sites from the XML file prior to reading it into SAS. These 'site' sections begin with tags and include StudyName, StudyDescription, and other metadata for each site. The final edited XML file has only one section with the metadata for the events, forms, items, etc. in it. This is followed by the section.
    o (2) We use an XML file exported from a single study site, instead of the full export from all sites. This results in all of the metadata (SAS formats and labels) being imported, but only clinical data from the single site being imported. We have another process to read the clinical data into SQL server, but metadata are lost in that process. So we stack the SAS dataset (with all clinical data removed, but metadata intact) with the SQL server dataset (which has no meta data, but all of the clinical data). The result is a SAS dataset with all metadata (SAS formats and labels) and clinical data from all sites.
    - We have discovered many rules that must be followed when creating OpenClinca forms that we intend to read into SAS.
    o Item_name (SAS variable name): max length 32 characters, no spaces or special characters, cannot begin with a number or underscore.
    o Description_label (SAS label): No characters not found on key board (e.g. Cyrillic C, Beta symbol, degree symbol etc.)
    o Units: No characters not found on key board.
    o Response_label (SAS format name): max length 8 characters!; no spaces or special characters; cannot begin or end with a number; cannot be a SAS pre-defined format (e.g. MONTH, MMDDYY, etc.)
    o Response_values (SAS format stored values): must correspond to data type for variable.
    o Response_options_text (SAS format display values): No characters not found on key board; use quotation marks with caution; max length 256 for printing in SAS.
    o Group_label (SAS dataset name for groups): max 32 characters, no spaces or special characters except underscore. Must be unique for a study because this becomes the SAS dataset name for groups. This means that two forms may not have groups with the same group_label name.
    o Data_type: Partial Date items do not read into SAS without modifications to the XML file. For studies/projects with Partial Date fields, we have had to manually change the XML file as follows: Find and replace (DataType="text" SASFieldName=") with (DataType="text" Length="10" SASFieldName=").
    o These guidelines apply to any new version of a form. With new form versions, one must be careful about changing reponse_label/values/options_text. Adding new items will result in more predictable results than modifying existing items.
    As you can see, we do a lot up-front when designing the forms for a study to make sure that the data export is able to be processed by PROC CDISC into SAS. We review and check the CRF spreadsheets to make sure none of these rules are violated before we upload the CRF into OpenClinica and allow data to be entered. We also check the import process, using data from a few test patients before we release the forms to sites for clinical data entry.
    Hope that helps!
    -Cody
    Cody Olsen, MS Biostatistician
    Department of Pediatrics
    University of Utah
    -----Original Message-----
    Sent: Monday, September 23, 2013 4:17 PM
    To: [email protected]; [email protected]
    Subject: [Users] Study build planning for SAS 9.3
    Hello,
    I am new to this and am in the process of building a study that will be using SAS 9.3. From what I have gathered from various resources, I need to avoid partial dates, and stick with 8 character naming conventions. Since I am starting from scratch, any other advice for avoiding errors upon study completion and upload into SAS? Any advice would be greatly appreciated.
    Thanks!
    Mary
This discussion has been closed.