CDISC CDASH - A Guide to Linking Clinical Data Management to Clinical Programming and Vice-versa

This article is put forward on behalf of the Quanticate CDISC Working Party and the work they have been doing on standardizing processes across the Data Management and Statistical Programming functions within Quanticate.

Introduction

As part of the recently launched Centralized Service Provision (CSP) approach to clinical data outsourcing at Quanticate, we have been looking at approaches that enable cross-functional efficiencies at a task level.  We have explored these efficiencies with the use of CDISC (Clinical Data Interchange Standards Consortium) CDASH standards when linking processes across clinical data management and clinical programming.

CDISC Study Data Tabulation Model (SDTM) standards are being used more and more as the standard format for raw data. However, these standards do not always lend themselves to data capture. At Quanticate, the Clinical Data Management and Clinical Programming teams have been working together to understand the constraints placed on Data Management by the databases they use. The CDISC Clinical Data Acquisition Standards Harmonization (CDASH) standard provided a common ground to facilitate the capture of data and understand the mapping required to SDTM.

Material / Methods

SDTM is the most stable and better understood of the CDISC Clinical Data Standards. SDTM is very prescriptive and, although there is ‘wiggle room,’ there is not as much as if you design your database from scratch. Understanding this, and developing a solution that works as a data collection and cleaning tool, can present quite a challenge. This is where the CDASH standard comes in. CDASH is designed with the end goal of the SDTM data structure and is written to support Clinical Report Form (CRF) and database design; it provides a platform to enable these data collection tools to be built in an SDTM-friendly manner. This was demonstrated when the Clinical Data Management team at Quanticate wanted to build a set of standard CRF pages and the database that would sit behind them to CDISC standards.

The SDTM standards and the CDASH Implementation Guide (IG) were reviewed and it was decided to build the domains listed in the CDASH IG as a starting point for the project. Discussions around each domain and data items in each domain ensued. These were recorded with the considerations of whether to include it/them, whether mapping to SDTM was needed, what code list to assign (using CDISC Controlled Terminology – of course) and any other comments that summarized the discussion. Other constraints such as variable name with the database had to be considered and appropriate naming and mapping conventions developed.

Process & Results

Using the CDASH standards to facilitate discussion, and keeping one eye on the SDTM IG, each domain was considered in turn. Certain domains such as ECG and Laboratory Data prompted a lot of discussion as CDASH recommends various ways of capturing those data. We decided to build pages for each scenario, and let each sponsor dictate how they wanted these pages to be defined (although still within the CDASH / SDTM standards framework as far as possible).

Recording the discussions arising for each domain variable was useful in documenting the decisions the group came to and highlighting where the CDASH and SDTM standards do not always quite meet. For example, in Adverse Events, CDASH does not use the concomitant treatment data item, whereas this is included in SDTM. The team decided to include it as, from previous experience, they had seen this question included in most CRFs they had reviewed.

There were several instances where a variable was not covered in CDASH and so Clinical Data Management were reluctant to use it. An example of this is AEPATT (pattern of Adverse Event – permissible in SDTM). This is not in the CDASH IG and therefore was not built into the standard CRF pages.

In another example, it was decided to use a vertical structure for the Vital Signs data collection page: that is to use the SDTM controlled terms for VSTESTCD as the names for the variables and create the SDTM dataset using some programming on the resultant database output. This was because Clinical Data Management found this easier to clean and validate the data using this structure. The Programmers could then devise a macro that would take whatever data items had been collected and convert them to the SDTM vertical structure of VSTESTCD, VSTEST and VSORRES.

The whole process was a rewarding iteration towards a set of standard pages and database question groups that can be used and re-used as required. Validation checks have also been built to clean the data and, again, these can be re-used.

Conclusion

We have built a set of database and CRF pages with associated validation checks that are robust enough to be re-used as required. The process consolidated the CDASH / SDTM knowledge of all those involved and prompted a lot of discussion about which data items should be included in the database design and what should be omitted for the time being.
As highlighted above, there appear to be a few gaps between the two standards (as highlighted in the AEPATT example) which require investigation and therefore justification for a variables inclusion / exclusion from the database build. The recently issued CDASH IG should go some way to addressing this.
Overall, CDASH give a common language through which to discuss the SDTM standard and the constraints Clinical Data Management work within when creating a CDASH / SDTM database.

References

SDTM Implementation Guide 3.1.1
CDASH Implementation Guide 1.0