Creating and Modifying Files

A best practice recommendation is that you do not (permanently) modify framework autocall macros or global standards library files, but instead modify copies of the files. This allows seamless updates to those files provided by SAS without concern about overwriting or losing your changes.

Each sample driver module sets a &studyRootPath macro variable to point to the root path of the sample study SAS supplies for each standard. This macro enables you to point to your own study root path by resetting the value of this macro variable. You might instead prefer to use explicit paths in your SASReferences data set and not use &studyRootPath at all.

The sample drivers assume a study folder hierarchy like that of the sample study, but this hierarchy is not required. If you have another organization for your study, you might need to make other changes to the paths specified in your driver module.

Each supported standard might define study metadata differently. The SAS representation of the 32 standard CDISC SDTM 3.1.2 domains differs from the SAS representation of the three types of tables supported in CDISC ADaM 2.1.

Most users have metadata about their studies in some form and file format other than that used by the SAS Clinical Standards Toolkit. You have to convert or map some of that metadata into the source_study, source_tables, and source_columns format specified in the sample study metadata folder (such as the sample study library directory/cdisc-adam-2.1-1.5/sascstdemodata/metadata directory). Some standards provide sample code that supports this task. For CDISC ADaM, look at the create_sourcemetadata.sas sample driver module as an example.

Yes. The initial values are based on the sample data associated with each standard. Your study data almost certainly differs. For CDISC SDTM and CDISC ADaM, your domains and analysis data sets reflect your study protocol. Some checks might not apply to some of your domains because your implementation of that domain might deviate from other domains from the same class (such as Findings).

Be aware that tableScope and columnScope wildcarding is a convenience, and you can instead explicitly reference a specific table or column in any check invocation.

See “Validation Check Metadata: Validation Master” in Chapter 6, “Validation,” in the SAS Clinical Standards Toolkit: User's Guide.

Yes. You can add checks to any SAS Clinical Standards Toolkit standard that supports validation. Each check is defined as a set of metadata (in the validation_master data set found in the global standards library directory/standards/standard/validation/control directory) and a message to be used when an error is detected (in the messages data set found in the global standards library directory/standards/standard/messages directory).

For each new check, you must create the check metadata to conform to the validation_master template and an associated message to conform to the messages data set metadata structure.

For more information about check metadata and the available SAS Clinical Standards Toolkit validation check macros, see Chapter 6, “Validation,” in the SAS Clinical Standards Toolkit: User's Guide.

The SAS Clinical Standards Toolkit permits the use of any set of controlled terminology or any coding dictionaries. Generally, controlled terminology is defined to the SAS Clinical Standards Toolkit as SAS format catalogs; coding dictionaries as SAS data sets. Either format is valid.

The SASReferences data set is used to document these format catalogs and coding dictionaries, and to facilitate run-time references to these reference input sources. In the SAS Clinical Standards Toolkit sample drivers, a SASReferences type=fmtsearch record points to each SAS format catalog (and allows specification of a reference order for like-named formats), and a type=referencecterm record points to each specific coding dictionary to be referenced. The format search path is set with the call to the cstutil_processsetup macro.

For more information about using controlled terminology in validation processes, see “Special Topic: Using Alternative Controlled Terminologies” in Chapter 6, “Validation,” in the SAS Clinical Standards Toolkit: User's Guide.

The sample SDTM SASReferences data set offers an example of referencing the MedDRA dictionary. The type=referencecterm record points to a folder (which can be anywhere) that can contain a MedDRA data set (using any name).

The SDTM validation check (SDTM0451) provided by SAS that compares AEDECOD to MedDRA preferred terms expects that the MedDRA data set contains the column PT_NAME. If your data set uses other column names, see If I Disagree with or Choose to Modify the Codelogic of a Specific Validation Check, What Needs to Be Done?.

See “Building a Validation Process” in Chapter 6, “Validation,” in the SAS Clinical Standards Toolkit: User's Guide.

The SAS Clinical Standards Toolkit uses the macro crtdds_write to create a define.xml file. This macro has the optional parameter _cstCreateDisplayStyleSheet that determines two things:

If you set this macro parameter to 1, the macro looks in the provided SASReferences file for a record with a type/subtype of referencexml/stylesheet and uses that file.

By default, the crtdds_write macro creates a style sheet reference in the define.xml file and copies a style sheet in the same folder as the define.xml file. This default style sheet, define1-0-0.xsl, is copied from the global standards library directory/standards/cdisc-crtdds-1.0/stylesheet directory and is identical to the style sheet that was originally made available by CDISC as part of the first release of the define.xml file.

See “Writing XML Files” in Chapter 8, “XML-Based Standards,” in the SAS Clinical Standards Toolkit: User's Guide.

Although it is not common to associate a style sheet with an ODM XML file, the SAS Clinical Standards Toolkit allows this. To do this, you must call the macro odm_write with macro parameter cstCreateDisplayStyleSheet=1 and also add a record to the SASReferences file with type/subtype of referencexml/stylesheet pointing to the style sheet to be used.

See the online macro API reference material regarding ODM.

When the SAS Clinical Standards Toolkit creates a define.xml file, it converts the information from a SAS data set representation of the CRT-DDS model into XML. For CDISC CRT-DDS 1.0, this means that 39 data sets (such as ItemDefs) are the source for creating the define.xml element and attribute structure. The content of these 39 data sets can be derived in part from other standards (such as CDISC SDTM).

You can directly maintain these 39 data sets so that you can add additional data that needs to be part of the define.xml. To be able to maintain these 39 data sets, you must be familiar with the structure of these data sets and the relationships among these data sets. For example, to add Value Level Metadata to the define.xml, add rows to four data sets: itemdefs, valuelists, valuelistitemrefs, and itemvaluelistrefs.

See the online API reference material regarding CRT-DDS 1.0 SAS data sets and “Writing XML Files” in Chapter 8, “XML-Based Standards,” in the SAS Clinical Standards Toolkit: User's Guide.

When the SAS Clinical Standards Toolkit creates an ODM XML file, it converts the information from a SAS data set representation of the ODM model into XML. For CDISC ODM 1.3.1, this means that 76 data sets (such as ItemDefs) are the source for creating the ODM XML element and attribute structure.

You can directly maintain these 76 data sets so that you can add data that needs to be part of the ODM XML file. To be able to maintain these 76 data sets, you must be familiar with the structure of these data sets and the relationships among these data sets.

Normally, you would not use SAS to create an ODM XML file, because it is assumed that there is a workflow in which a data collection and management system exports metadata definitions and data content in the form of a transactional or snapshot ODM XML file. When SAS is used to create an ODM XML file, the initial SAS representation of the ODM model can be created by using one of the following methods:

See “Writing XML Files” in Chapter 8, “XML-Based Standards,” in the SAS Clinical Standards Toolkit: User's Guide.

The SAS Clinical Standards Toolkit autocall path is set by default to SASAUTOS, which includes the SAS Clinical Standards Toolkit framework macros found in the !sasroot\cstframework\sasmacro directory (Microsoft Windows) or in the !sasroot/sasautos directory (UNIX).

A macro library is defined for each standard in the global standards library. (See Where Do the Framework and Standard-Specific Macros Reside?.) In the SASReferences data set, one or more records with type=autocall can be used to reset the SAS autocall path, where the order column specifies the order each macro library is to be referenced. You can use the same strategy to reference any user-defined macro libraries, even if those libraries are not associated with a specific standard.

See Chapter 5, “SASReferences File,” in the SAS Clinical Standards Toolkit: User's Guide.

No. However, the SAS Clinical Standards Toolkit has adopted this method to define and document the input and output file and library references, to build the macro autocall, and to format search paths for each SAS Clinical Standards Toolkit process. Although you can perform all library and file allocations and set SAS system options yourself, it is highly recommended that you use the SASReferences approach.

See Chapter 5, “SASReferences File,” in the SAS Clinical Standards Toolkit: User's Guide.

No. However, doing so standardizes your approach to creating and documenting global macro variables.

See “Properties” in Chapter 3, “Metadata File Descriptions,” in the SAS Clinical Standards Toolkit: User's Guide.