CDASH is positioned as a standard to collect data to provide traceability from data collection to SDTM. It comes with recommendations for data collection for 16 common data domains, such as demographics and adverse events. The documentation includes examples for CDASH implementation in 3 popular EDC systems including Medidata’s Rave and Oracle’s Inform.
Latest CDASH version 1.1 was released in 2011 with its implementation examples and user guide released later in the year and in 2012. Whereas latest SDTM IG version 3.2 was released in 2013. SDTM IG’s are associated with corresponding model versions, e.g. SDTM IG 3.2 is associated with SDTM model version 1.4. More details about this linkage can be found here.
Potential benefits of CDASH are:
– Efficient data collection and monitoring
– Faster study-setup
– Easier SDTM conversion
– Standardized data collection
– Reduced effort in training
Due to these potential advantages our team decided to use CDASH as a starting point for designing the forms. For someone new to CRF design and EDC systems, CDASH documentation helps in understanding some of the basic principles of CRF design for the common data domains.
After incorporating the basic fields for some of the common domains, we started to realize limitations of CDASH. First, the fields and domains provided in CDASH are not adequate. Instead SDTM has a lot more comprehensive set of domains and fields. Also, CDASH field naming is mostly same as SDTM. This often led us directly to SDTM to design the fields. CDASH does not comes along with generalized model like SDTM, seriously limiting its application.
Next challenge is to make the EDC systems to name and store the fields with desired naming and terminology standards. Often EDC systems creates multiple variables with different suffixes for a single entered field. E.g. extra fields for coded values and field status may be present. Different EDC systems have different field naming and handling conventions, especially for date variables. Also, generally EDC systems have limitations around sharing the field names across forms which sometimes make it hard to reuse best CDISC based field names. CDASH standard doesn’t try to address these issues.
Finally, CDASH does not address the challenges around data normalization. Many domains in CDISC present data in normalized structure. E.g. one record is needed in vital signs domain (VS) per measurement. Whereas, Data collection in CRFs is generally in flat structure. i.e. CRFs are designed to collect all vital sign measurements done together in a single record.
On the surface, it seems CDASH fills the gap between the EDC and SDTM. After our closer experience with CDASH, we realized it is much easier to directly refer SDTM model for the CRF design wherever possible. CDASH does provide some useful pointers for data collection such as for trigger questions and date components, which are absent in SDTM. But SDTM model provides a lot more comprehensive set of data collection domains, fields, conventions, and terminology. Although EDC systems cannot generate proper SDTM package directly, SDTM friendly CRF design does bring the benefits that CDASH can achieve. By directly using SDTM model for designing CRFs, we can skip the learning and maintenance of yet another CDISC standard and its alignment with SDTM.
We at Nimble Clinical Research design CRFs and corresponding data exports such that these are SDTM friendly. This reduces our SDTM creation effort and allows us to generate draft SDTM data package along with define.xml as early as within a week after start of data collection.
Your request has been submitted successfully.
Thanks for contacting us. We will get back as soon as we can!
CDASH is positioned as a standard to collect data to provide traceability from data collection to SDTM. It comes with recommendations for data collection for 16 common data domains, such as demographics and adverse events. The documentation includes examples for CDASH implementation in 3 popular EDC systems including Medidata’s Rave and Oracle’s Inform.
Latest CDASH version 1.1 was released in 2011 with its implementation examples and user guide released later in the year and in 2012. Whereas latest SDTM IG version 3.2 was released in 2013. SDTM IG’s are associated with corresponding model versions, e.g. SDTM IG 3.2 is associated with SDTM model version 1.4. More details about this linkage can be found here.
Potential benefits of CDASH are:
– Efficient data collection and monitoring
– Faster study-setup
– Easier SDTM conversion
– Standardized data collection
– Reduced effort in training
Due to these potential advantages our team decided to use CDASH as a starting point for designing the forms. For someone new to CRF design and EDC systems, CDASH documentation helps in understanding some of the basic principles of CRF design for the common data domains.
After incorporating the basic fields for some of the common domains, we started to realize limitations of CDASH. First, the fields and domains provided in CDASH are not adequate. Instead SDTM has a lot more comprehensive set of domains and fields. Also, CDASH field naming is mostly same as SDTM. This often led us directly to SDTM to design the fields. CDASH does not comes along with generalized model like SDTM, seriously limiting its application.
Next challenge is to make the EDC systems to name and store the fields with desired naming and terminology standards. Often EDC systems creates multiple variables with different suffixes for a single entered field. E.g. extra fields for coded values and field status may be present. Different EDC systems have different field naming and handling conventions, especially for date variables. Also, generally EDC systems have limitations around sharing the field names across forms which sometimes make it hard to reuse best CDISC based field names. CDASH standard doesn’t try to address these issues.
Finally, CDASH does not address the challenges around data normalization. Many domains in CDISC present data in normalized structure. E.g. one record is needed in vital signs domain (VS) per measurement. Whereas, Data collection in CRFs is generally in flat structure. i.e. CRFs are designed to collect all vital sign measurements done together in a single record.
On the surface, it seems CDASH fills the gap between the EDC and SDTM. After our closer experience with CDASH, we realized it is much easier to directly refer SDTM model for the CRF design wherever possible. CDASH does provide some useful pointers for data collection such as for trigger questions and date components, which are absent in SDTM. But SDTM model provides a lot more comprehensive set of data collection domains, fields, conventions, and terminology. Although EDC systems cannot generate proper SDTM package directly, SDTM friendly CRF design does bring the benefits that CDASH can achieve. By directly using SDTM model for designing CRFs, we can skip the learning and maintenance of yet another CDISC standard and its alignment with SDTM.
We at Nimble Clinical Research design CRFs and corresponding data exports such that these are SDTM friendly. This reduces our SDTM creation effort and allows us to generate draft SDTM data package along with define.xml as early as within a week after start of data collection.