Bioequivalence and Bioavailability Forum

Hi WhiteCoatWriter,

❝ […] if it is possible to perform CDISC datasets (SDTM and ADAM) on R while the final product is expected to be in .XPT format.

Why not?

❝ While the regulatory doesn't specify software or the means, …

Correct. The FDA nowhere mandates SAS or recommends any particular software. E.g., Certara provides the Phoenix CDISC Navigator for import/export in Phoenix/WinNonlin.

❝ … it mandates that the final output is in .XPT format (which is SAS format).

Correct. Though there is hope to move towards XML. Abstract:

At the FDA's request, a CDISC-sponsored group has developed an XML-based replacement for the SAS version 5 transport files that are currently used to send case report tabulations clinical trials data to the FDA. Limitations of version 5 transport files such as 8 character variable names, 40 character labels for variables, a 200 character limit for character data, an idiosyncratic representation for dates and times, and sparse built-in metadata stored with the data have become noticeable and troublesome as such limitations have disappeared from other software used in clinical data management. CDISC has developed the more flexible XML-based Operational Data Model (ODM). ODM provides XML analogs to "forms" and "fields" and it has built-in support for extensive metadata. ODM does not specify names for clinical domains (i.e., adverse events, medical history) or data fields. CDISC's Submissions Data Standards (SDS) specifies a structure and metadata for clinical domains and data fields. ODM, by design, provides an excellent XML format for clinical trials data with the SDS-specified structure and metadata. This ODM/SDS combination is the basis for the XML replacement for version 5 transport files in regulatory submissions.

(My emphases. I know, the document is 15 (!) years old.)

❝ I want to understand, if there will be any issues/challenged in executing and submitting datasets generated using R?

None – if the code is validated… You have to start with the package SASxport, which you have to validate first. Though you can dump the functions to inspect the code (in the R-console type e.g., write.xport) I suggest to get the source from CRAN. Much easier. Then write your own code to modify the data (rename fields, change formats, etc.). At the end it would be a good idea to check whether your file can be imported into other software. If you don’t have SAS, opt for a trial license of Phoenix or a demo of Stat/Transfer (I paid USD 295 in 2014 for v12; the current v14 comes for USD 349).

If you are an experienced R-coder, consider writing a package (see here and there). The community will love you.