There are 3 general approaches to create the SDTM datasets:

1. BUILD the SDTM entirely in the CDMS,
2. Build the SDTM entirely on the “back-end” in SAS,
3. or take a hybrid approach and build the SDTM partially in the CDMS and partially in SAS.

BUILD THE SDTM ENTIRELY IN THE CDMS:

It is possible to build the SDTM entirely within the CDMS. If the CDMS allows for broad structural control of the UNDERLYING database, then you could build your eCRF or CRF based clinical database to SDTM standards.

ADVANTAGES:

• Your “raw” database is equivalent to your SDTM which provides the most elegant solution.
• Your clinical data management staff will be able to converse with endusers/sponsors about the data easily since your clinical data manager and the und-user/sponsor will both be looking at SDTM datasets.
• As soon as the CDMS database is built, the SDTM datasets are available.

Disadvantages:

• This approach may be cost prohibitive. Forcing the CDMS to create the SDTM structures may simply be too cumbersome to do efficiently.

• Forcing the CDMS to adapt to the SDTM may cause problems with the operation of the CDMS which could reduce data quality.

BUILD THE SDTM ENTIRELY ON THE “BACK-END” IN SAS

Assuming that SAS is not your CDMS solution, another approach is to take the clinical data from your CDMS and manipulate it into the SDTM with SAS programming.

Advantages:

• The great flexibility of SAS will let you transform any proprietary CDMS structure into the SDTM. You do not have to work around the rigid constraints of the CDMS.
• Changes could be made to the SDTM conversion without disturbing clinical data management processes.
• The CDMS is allowed to do what it does best which is to enter, manage, and clean data.

Disadvantages:

• There would be additional cost to transform the data from your typical CDMS structure into the SDTM.Specifications, programming, and validation of the SAS programming transformation would be REQUIRED.

• Once the CDMS database is up, there would then be a subsequent delay while the SDTM is created in SAS.This delay would SLOW down the production of analysis datasets and reporting. This assumes that you follow the linear progression of CDMS ->

SDTM -> analysis datasets (ADaM).

• Since the SDTM is a derivation of the “raw” data, there could be errors in translation from the “raw” CDMS data to the SDTM.

• Your clinical data management staff may be at a disadvantage when speaking with end-users/sponsors about the data since the data manager will likely be looking at the CDMS data and the sponsor will see SDTM data.

BUILD THE SDTM USING A HYBRID APPROACH

Again, assuming that SAS is not your CDMS solution, you could build some of the SDTM within the confines of the CDMS and do the rest of the work inSAS. There are things that could be done easily in the CDMS such as naming data tables the same as SDTM domains, using SDTM variable names in the CTMS, and performing simple derivations (such as age) in the CDMS. More complex SDTM derivations and manipulations can then be performed in SAS.

Advantages:

• The changes to the CDMS are easy to implement.
• The SDTM conversions to be done in SAS are manageable and much can be automated.

Disadvantages:

• There would still be some additional cost needed to transform the data from the SDTM-like CDMS structure into the SDTM. Specifications, programming, and validation of the transformation would be required.
• There would be some delay while the SDTM-like CDMS data is converted to the SDTM.
• Your clinical data management staff may still have a slight disadvantage

when speaking with endusers/ sponsors about the data since the clinical data manager will be looking at the SDTM-like data and the sponsor will see the true SDTM data. 

There are 3 general approaches to create the SDTM datasets:

BUILD THE SDTM ENTIRELY IN THE CDMS:

It is possible to build the SDTM entirely within the CDMS. If the CDMS allows for broad structural control of the underlying database, then you could build your eCRF or CRF based clinical database to SDTM standards.

Advantages:

Disadvantages:

• This approach may be cost prohibitive. Forcing the CDMS to create the SDTM structures may simply be too cumbersome to do efficiently.

• Forcing the CDMS to adapt to the SDTM may cause problems with the operation of the CDMS which could reduce data quality.

BUILD THE SDTM ENTIRELY ON THE “BACK-END” IN SAS

Assuming that SAS is not your CDMS solution, another approach is to take the clinical data from your CDMS and manipulate it into the SDTM with SAS programming.

Advantages:

Disadvantages:

• There would be additional cost to transform the data from your typical CDMS structure into the SDTM.Specifications, programming, and validation of the SAS programming transformation would be required.

• Once the CDMS database is up, there would then be a subsequent delay while the SDTM is created in SAS.This delay would slow down the production of analysis datasets and reporting. This assumes that you follow the linear progression of CDMS ->

SDTM -> analysis datasets (ADaM).

• Since the SDTM is a derivation of the “raw” data, there could be errors in translation from the “raw” CDMS data to the SDTM.

• Your clinical data management staff may be at a disadvantage when speaking with end-users/sponsors about the data since the data manager will likely be looking at the CDMS data and the sponsor will see SDTM data.

BUILD THE SDTM USING A HYBRID APPROACH

Again, assuming that SAS is not your CDMS solution, you could build some of the SDTM within the confines of the CDMS and do the rest of the work inSAS. There are things that could be done easily in the CDMS such as naming data tables the same as SDTM domains, using SDTM variable names in the CTMS, and performing simple derivations (such as age) in the CDMS. More complex SDTM derivations and manipulations can then be performed in SAS.

Advantages:

Disadvantages:

when speaking with endusers/ sponsors about the data since the clinical data manager will be looking at the SDTM-like data and the sponsor will see the true SDTM data.