This is the fourth in a series of posts where we answer questions from our recent webinar. Below, we’ve summarized the regulatory expectations and our top insights.

Not Submitted Annotations

For any information that is on the CRF but not mapped to SDTM, annotate the page and/or field with "NOT SUBMITTED."

• Even if a permissible variable with a null value across the entire dataset is dropped from the dataset, still annotate the variable with "NOT SUBMITTED."
• Conversely, if the variable is kept in the dataset, we recommend adding any possible values that could have been collected on the CRF to the codelist in the define.xml.

If your CRF contains EDC annotations on it, you should still annotate it.

• Do not annotate it as "NOT SUBMITTED" or leave it blank.
• A CRF with both SDTM and EDC annotations can confuse reviewers, so make every effort to avoid this. When possible, obtain a CRF without EDC annotations.

Reviewer's Guide

We recommend annotating all variables where clinical data were planned to be collected, even for permissible variables.

• SDTMIG v3.3 recommends keeping variables in the dataset that were planned to be collected, even if all values are null. (Similarly, add any expected values to the define.xml codelist, even if they were never collected.)
• Previously, keeping or dropping null permissible variables was left to sponsor discretion.

To avoid impeding the review process, document in the cSDRG Section 3.3 that no data was collected.

• Per the cSDRG completion guidelines, cSDRG Section 3.3 must have a table to describe any data collection fields on the CRF that were not submitted and the reason why.
• Table information should be limited to clinical study data and presented clearly for the reviewer. It should not contain CRF fields used for operational purposes or to trigger creation of other page(s).
• If the table is not necessary, delete the table but not the section.

For further information, visit the official PhUSE website for the latest cSDRG Template and the cSDRG Completion Guidelines.

Define: Origin Column

Only variables that are collected on the CRF should have an origin of "CRF."

• It’s not true that every variable annotated in the aCRF should have an origin of "CRF." Some Assigned variables on the CRF are commonly annotated to provide additional clarity, but these variables should still have an origin of “Assigned” in the define.xml, not "CRF."
• Also, select "CRF," not "Derived," as the origin for variables that have basic transformations done in SDTM, such as date formatting or changing case. E.g., a date that is collected as ddmmyyyy, but put into SDTM as YYYY-MM-DD.
• If you annotate --CAT variables on the aCRF, the correct origin is “CRF” if the value of --CAT is exactly as printed on the CRF. Otherwise, it should be "Assigned."
  • If the --CAT variable is set to a value in quotes, but that is not how it is printed on the CRF, then the origin is "Assigned." E.g., LBACT="CHEMISTRY," with the origin of the LBCAT variable set to "Assigned."

More to Come

We hope these items give you a confident default for your workflow. For further reading, see our white paper. And please check back as we continue this series of posts!