You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Determining whether a product faithfully implements a standard or specification is essential to creating robust, interoperable solutions. 




Data Collection


The following guidelines should be followed to ensure implementation of CDASH compliant CRFs

GuidelineDescription
1Core designations must be followed.
  • All Highly Recommended and applicable Recommended/Conditional fields must be present in the CRF and/or operational database. Match language in metadata description
2CDISC Controlled Terminology must be used. 
  • Specified controlled terminology must be used to collect the data in the CRF. All codelists displayed in the CRF must use or directly map to the current published CDISC CT submission values, when it is available. Subsets of published CT, such as those provided in CDASH terminology, can be used.
3Best practices for CRF design must be followed. 
4The wording of CRF questions should be standardized. 
  • Specified Question Text or Prompts must be used to ask the question.
5CDASHIG variable naming conventions should be used in the operational database. 

  1. Use a consistent syntax that includes the root variable name and/or controlled terminology, and any other standardized concepts that are needed to support efficient mapping of the collected value to SDTM datasets. The goals are to have beginning-to-end traceability of the variable name from the data capture system to the SDTM datasets, and to support automating electronic data capture (EDC) set-up and downstream processes.

    1. It is recognized that (particularly in an EDC system) the variable name of a data collection field, as well as the name in the underlying database, may have various “system” components that become part of the item’s identifier. EDC systems, prior to exporting data in a defined format, may require the variable name to include such database “references” as the EDC page name, the item “group” name, or perhaps a combination.

    2. In cases where the data collection is done in a denormalized way, appropriate CDISC CT must be used when it is available.

      1. For example, when collecting vital signs results in a denormalized eCRF, the variable names can be created by using terms from the Vital Signs Test Code codelist. For example, temperature result can be collected in a variable called TEMP or TEMP_VSORRES; systolic blood pressure result can be collected in a variable called SYSBP or SYSBP_VSORRES. When a particular system’s constraints limit the variable name to 8 characters, a similar, consistent implementation that preserves either the normalized root variable (e.g., ORRES) or the controlled terminology (e.g., --TESTCD value) should be implemented.

      2. Other variable patterns that intentionally connect the data collection variable to the target SDTMIG variable are also acceptable.  For example, targetDataset_targetVariable[_optionalTopic] is acceptable. Examples of this pattern include DM_AGE, DM_AGEU, VS_VSORRES_TEMP, VS_VSORRESU_TEMP, SUPPAE_QVAL_AEDIS.

    3. Whereas all CDASHIG defined variable names are 8 characters or fewer to accommodate SDTM limits on variable names, QNAMs, and --TESTCDs, the maximum length of a variable name that may be implemented is determined by the data management system used, not by CDASH. 

    4. When collecting data in a horizontal manner, to facilitate transformation to SDTM datasets, when possible it is recommended to create denormalized CDASH variables in the data collection system by incorporating the SDTMIG variable name target and/or the controlled terminology (e.g., --TESTCD) as part of the CDASH variable names. The domain-level metadata labeled as "Horizontal-Generic" in the Implementation Options column of the CDASHIG metadata tables are examples of how to implement this. There is no conformance requirement implied by these examples.

6
  1. Data output by the operational database into an SDTMIG variable should require no additional processing if the CDASHIG and SDTMIG variable names are the same. 
  1. An SDTM data programmer should be able to assume that data in an SDTMIG variable is SDTMIG-compliant. Minimal processing (e.g., changing case) does not affect conformance. This helps to ensure a quality deliverable, even if the programmer is unfamiliar with data capture practices.
7Validated questionnaires, ratings, or scales must present the questions and reply choices in the manner in which these were validated. 
  1. his must be followed to maintain the validity of a validated instrument. (See Section 8.3.12, QRS - Questionnaires, Ratings, and Scales).
    1. In some cases, this may result in CRFs that do not conform to CDASH best practices; however, restructuring these questionnaires should not be done because it could invalidate them.
    2. The use of such questionnaires in their native format should not be considered to affect conformance to CDASH.

Implementers must determine what additional data fields to add to address study-specific and therapeutic area requirements, and applicable regulatory and business practices. See Section 3.4, How to Create New Data Collection Fields When No CDASHIG Field Has Been Defined, for more information on how to create data collection fields that have not already been described in this implementation guide.


Data Tabulation

From SDTMIG

Conformance with the SDTMIG domain models is minimally indicated by:

  • Following the complete metadata structure for data domains
  • Following SDTMIG domain models wherever applicable
  • Using SDTM-specified standard domain names and prefixes where applicable
  • Using SDTM-specified standard variable names
  • Using SDTM-specified data types for all variables
  • Following SDTM-specified controlled terminology and format guidelines for variables, when provided
  • Including all collected and relevant derived data in one of the standard domains, special-purpose datasets, or general observation class structures
  • Including all Required and Expected variables as columns in standard domains, and ensuring that all Required variables are populated
  • Ensuring that each record in a dataset includes the appropriate Identifier and Timing variables, as well as a Topic variable
  • Conforming to all business rules described in the CDISC Notes column and general and domain-specific assumptions


Conformance with the SENDIG domain models is minimally indicated by:

  • Following the complete metadata structure for data domains
  • Following SENDIG domain models wherever applicable
  • Using SENDIG-specified standard domain names and prefixes per controlled terminology
  • Using SENDIG-specified standard variable names
  • Using SENDIG-defined variable labels for all standard domains
  • Using SDTM-specified data types for all variables
  • Following SDTM/SEND-specified controlled terminology and format guidelines for variables when provided
  • Including all collected and relevant derived data in one of the standard domains, special-purpose datasets, or general-observation class structures
  • Including all required and expected variables as columns in standard domains, and ensuring that all required variables are populated
  • Ensuring that each record in a dataset includes the appropriate identifier and timing variables as well as a topic variable
  • Conforming to all business rules described in the CDISC Notes column and general and domain-specific assumptions
  • Ensuring that the datasets are in SAS v5 transport file format or other transport file format required by a regulatory agency



Data Analysis


  • No labels