Tag Archives: CDISC express

Project Plan: CDISC Implementation

CDISC standards have been in development for many years. There are now methodologies and technologies that would make the transformation of non-standard data into CDISC-compliance with ease. Clinical trials have evolved and become more complex and this requires a new set of skills outside of clinical research – Project Management.

As with many projects, CDISC is a huge undertake. It requires resources, technology and knowledge-transfer. The industry (FDA for example) has been working on standardization for years but on September 2013, it became official, in which the FDA released a ‘Position Statement‘.

So what is CDISC? We can say that it is way of naming convention for XPT files, or field names naming conventions or rules for handling unusual data. Currently, there are two main components of CDISC: SDTM (Study Data Tabulation Model) and aDAM (Analysis Data Model).

As a project manager and with the right tool, you can look to a single source project information to manage the project through its life-cycle – from planning, through execution, to completion.

1) Define Scope: This is where you’re tested on everything that has to do with getting a project up and running: what’s in the charter, developing the preliminary scope, understanding what your stakeholders need, and how your organization handles projects.

The scope document is a form of a requirement document which will help you identify the goals for this project. It can also be used as a communication method to other managers and team members to set the appropriate level of expectations.

The project scope management plan is a really important tool in your project. You need to make sure that what you’re delivering matches what you wrote down in the scope statement.

2) Define Tasks: we now need to document all the tasks that are required in implementing and transforming your data to CDISC.

Project Tasks  (Work packages) Estimates (work unit)
Initial data standards review 27
Data Integrity review 17
Create transformation models 35

The work breakdown structure (wbs) provides the foundation for defining work as it relates to project objectives. The scope of work in terms of deliverables and to facilitate communication between the project manager and stakeholders throughout the life of the project. Hence, even though, preliminary at first, it is a key input to other project management processes and deliverables.

3) Project Plan: Once we completed the initiation phase (preliminary estimates), we need to create a project plan assigning resources to project and schedule those tasks. Project schedules can be presented in many ways, including simple lists, bar charts with dates, and network logic diagrams with dates, to name just a few. A sample of the project plan is shown below:

project plan sample
image from Meta‐Xceed paper about CDISC

4) Validation Step: Remember 21 CFR Part 11 compliance for Computer Systems Validation? The risk management effort is not a one-time activity on the project. Uncertainty is directly associated with the change being produced by a project. The following lists some of the tasks that are performed as it pertains to validation.

  • Risk Assessment: Different organizations have different approaches towards validation of programs. This is partly due to varying interpretations of the regulations and also  due to how different managers and organizations function. Assess the level of validation that needs to take place.
  • Test Plan: In accordance with the project plan and, if not, to determine how to address any deviation. Test planning is essential in:  ensuring testing identifies and reveals as many errors as possible and to acceptable levels of quality.

test plan-cdisc

  • Summary Results: This is all the findings documented during testing.

An effective risk management process involves first identifying and defining risk factors that could affect the various stages of the CDISC implementation process as well as specific aspects of the project. riskplan

5) Transformation Specification: Dataset transformation is a process in which a set of source datasets and its variables are changed to  meet new standard requirements. Some changes will occur during this step: For example, variable name must be 8 chars long. The variable label must not be more than 40 chars in length. Combining values from multiple sources (datasets) into on variable.

6) Applying Transformation: This is done according to specification however, this document is active during the duration of a project and can change. There are now many tools available to help with this tasks as it could be time consuming and resource intensive to update the source code (SAS) manually. Transdata, CDISCXpres, SAS CDIDefine-it; just to name a few.

7) Verification Reports: The validation test plan will detail the specific test cases that need to be implemented  to ensure quality of the transformation. For example, a common report is the “Duplicate Variable” report.

8) Special Purpose Domain: CDISC has several special purpose domains: CO (comments), RELREC (related records or relationship between two datasets) and SUPPQUAL (supplemental qualifiers for non-standards variables).

9) Data Definition Documentation: In order to understand what all the variables are and how they are derived, we need a annotation document. This is the document that will be included during data submission. SAS PROC CONTENTS can help in the generation of this type of metadata documentation. The last step in the project plan for CDISC implementation is to generate the documentation in either PDF  or XML format.

CDISC has established data standards to speed-up data review and FDA is now suggesting that soon this will become the norm. Pharmaceuticals, bio-technologies companies and many sponsors within clinical research are now better equipped to improve CDISC implementation.

Need SAS programmers? RA eClinica can help provide resources in-house / off-shore to facilitate FDA review by supporting CDISC mapping, SDTM validation tool, data conversion and CDASH compliant eCRFs.

Disclaimer: The legal entity on this blog is registered as Doing Business As (DBA) – Trade Name – Fictitious Name – Assumed Name as “GAMBOA”.


A New Way to Collect Data – CDASH

There is a general consensus that the old paper-based data management tools and processes were inefficient and should be optimized. Electronic Data Capture has transformed the process of clinical trials data collection from a paper-based Case Report Form (CRF) process (paper-based) to an electronic-based CRF process (edc process).

In an attempt to optimize the process of collecting and cleaning clinical data, the Clinical Data Interchange Standards Consortium (CDISC), has developed standards that span the research spectrum from preclinical through postmarketing studies, including regulatory submission. These standards primarily focus on definitions of electronic data, the mechanisms for transmitting them, and, to a limited degree, related documents, such as the protocol.

Clinical Data Acquisition Standards Harmonization (CDASH)

The newest CDISC standard, and the one that will have the most visible impact on investigative sites and data managers, is Clinical Data Acquisition Standards Harmonization (CDASH).

As its name suggests, CDASH defines the data in paper and electronic CRFs.

Although it is compatible with CDISC’s standard for regulatory submission (SDTM), CDASH is optimized for data captured from subject visits, so some mapping between the standards is required. In addition to standardizing questions, CDASH also references CDISC’s Controlled Terminology standard, a compilation of code lists that allows answers to be standardized as well.

Example: Demographics (DM)

Description/definition variable name Format
Date of Birth* BRTHDTC dd MMM yyyy
Sex** SEX $2
Race RACE 2
Country COUNTRY $3

*CDASH recommends collecting the complete date of birth, but recognizes that in some cases only BIRTHYR and BIRTHMO are feasible.

* *This document lists four options for the collection of Sex: Male, Female, Unknown and Undifferentiated (M|F|U|UN). CDASH allows for a subset of these codelists to be used, and it is typical to only add the options for Male or Female.

The common variables: STUDYID, SITEID or SITENO, SUBJID, USUBJID, and INVID that are all SDTM variables with the exception of SITEID which can be used to collect a Site ID for a particular study, then mapped to SITEID for SDTM.

Common timing variables are VISIT, VISITNUM, VISDAT and VISTIM where VISDAT and VISTIM are mapped to the SDTM –DTM variable.

Note: Certain variables are populated using the Controlled Terminology approach. The COUNTRY codes are populated using ISO3166 standards codes from country code list. This is typically not collected but populated using controlled terminology.

Each variable is defined as:

  • Highly Recommended: A data collection field that should be on the CRF (e.g., a regulatory requirement).
  • Recommended/Conditional: A data collection field that should be collected on the CRF for specific cases or to address TA requirements (may be recorded elsewhere in the CRF or from other data collection sources).
  • Optional: A data collection field that is available for use if needed

The CDASH and CDICS specifications are available on the CDICS website free of charge. There are several tool available to help you during the mapping process from CDASH to SDTM. For example, you could use Base SAS, SDTM-ETL or CDISC Express to easily map clinical data to SDTM.

In general you need to know CDISC standards and have a good knowledge of data collection, processing and analysis.

With the shift in focus of data entry, getting everyone comfortable with using a particular EDC system is a critical task for study sponsors looking to help improve the inefficiencies of the clinical trial data collection process. Certainly the tools are available that can be used to help clinical trial personnel adapt to new processes and enjoy better productivity.

Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica Open Source and Oracle Clinical.