Welcome to the knowledge base of Frequently Asked Questions regarding SEND.

This page contains answers for a wealth of questions, primarily geared toward those beginning or going through their initial implementation.

If this is your first time visiting the page and are brand new to SEND, consider checking out the SEND Fundamentals set of pagees, which provides some basics on concepts and how they work together.
If you already know the basics, and are looking for a question, check out the table of contents on the right, or a "find on page" (Ctrl+F) for a keyword (e.g., "ts.xpt" or "derived" or "ORRESU")
If you can't find the answer you are looking for, ask on the SEND Implementation Forum
Check out and watch the SEND Implementation News page for updates regarding SEND guide versions, FDA news, etc.

Note: The content of this page was prepared by PHUSE working group and SEND team members and should not be considered as official FDA responses. This content exists to concisely summarize answers that are usually available across/within other documents or pages, to provide implementers with quick, unofficial, and useful answers to their questions.

Table of Contents

Basics

What is SEND?
SEND, or the Standard for Exchange of Nonclinical Data, is an implementation of the CDISC Standard Data Tabulation Model (SDTM) which specifies a way to present nonclinical data in a consistent format.

Timing/Regulatory

When Was SEND Released?

Document	Release Date	Note
SENDIG (SEND Implementation Guide)
SENDIG 3.1	2016-06-27	First supported by CDER in Q3 2017
SENDIG 3.0	2011-07	First supported by CDER in Q4 2011
SENDIG DART (SEND Implementation Guide for Developmental and Reproductive Toxicology)
Document	Release Date	Note
SENDIG DART 1.1	2017-12-11	Awaiting CDER notification of support

NOTE: please see the When Is SEND Mandatory? question below for information regarding when any of the above are required, with the Data Standards Catalog being the official resource and guidance.

When Is SEND Mandatory?

The FDA submission requirement depends on when the study starts, the type of submission, and where in the eCTD it would go.

See the following sections below:

Submission Types and Study Start Timing - this section covers timing with regard to submission types and study start dates
eCTD Sections - this section covers which sections of the eCTD apply
Documents - for supporting documentation for above

Part 1: Submission Types and Study Start Timing

Each version of the SENDIG also has its own specific window of when it may first be used and when it may last be used (aka sunset). The definitive list of supported/mandated versions is maintained by the FDA in the FDA Data Standards Catalog (which provides links to relevant guidance, etc.):

This is your first stop for understanding required dates for published standards, including CDER vs CBER. submission types, start and ends of versions, and so on.

Since SEND has already been required since at least 2017-12-17 (INDs) and 2016-12-17 (NDAs), as to the question of "when do I first need to be SEND-ready", the answer is "now".

Note: dates for other versions, updates, etc. follow a different implementation timeline (notably, removing the distinction between IND and NDA/BLA after SENDIG 3.1); please see the "When new study types or versions of the SEND Implementation Guide are brought online, when will they be required?" question below.

Note:

Since studies included in an IND are nearly always included in the subsequent NDA, many organizations prepare to have SEND for all studies intended for an NDA or IND submission that started on or after the 2016-12-17 date
These milestones apply to each study individually. Some submissions may span many years; for these, only studies that start after the dates above are mandated to be in SEND.
That said, the preference is that where feasible, all repeat dose, single dose and carcinogenicity studies would be submitted with SEND datasets even if not technically required, since it can improve the review process.
Any questions can always be sent to cder-edata@fda.hhs.gov or cber-edata@fda.hhs.gov.

Examples:

NDA submitted to CDER before 2016-12-17 - does not need to be submitted in SEND format (although it is preferred)
NDA submitted to CDER after 2016-12-17 - needs any studies which started after 2016-12-17 to be submitted in SEND. The other studies in the submission do not need to be submitted in SEND format (although it is preferred)
IND submitted to CDER before 2017-12-17 - does not need to be submitted in SEND format (although it is preferred)
IND submitted to CDER after 2017-12-17 - needs any studies which started after 2017-12-17 to be submitted in SEND. The other studies in the submission do not need to be submitted in SEND format (although it is preferred)

Part 2: eCTD Sections

The Electronic Common Technical Document (eCTD) page (which can be reached from the Study Data Standards page as well) has several resources for submission, including the Technical Rejection Criteria for Study Data.

This is the definitive source for which sections of the eCTD are applicable for submission of data (including SEND datasets). Currently this is specified as WILL APPLY and WILL NOT APPLY.

The Electronic Common Technical Document Specification (eCTD) including the full list of possible sections in which a study may be submitted can be found in the ICH eCTD Specification

Part 3: Supporting Documents

These requirements to produce SEND datasets for FDA hinge around the following documents:

The Food and Drug Administration Safety and Innovation Act (FDASIA), effective the 1st of October, 2012, including the fifth authorization of the Prescription Drug User Fee Act (PDUFA V). (Note that electronic format for submissions is addressed in FDASIA Sec 1136 which amended Sec 745A of 21 U.S.C. 379k)
The “Guidance for Industry ‐ Providing Regulatory Submissions in Electronic Format ‐ Submissions Under Section 745A(a) of the Federal Food, Drug, and Cosmetic Act” (aka "final guidance"), which was finalized December 18, 2014.
The “Guidance for Industry ‐ Providing Regulatory Submissions in Electronic Format ‐ Standardized Study Data” (aka "eStudy Data guidance"), which was finalized December 18, 2014.

For more information, see the following FDA pages:

The Japanese Pharmaceuticals and Medical Devices Agency (PMDA) is working to adopt CDISC standards including SEND. At the April 2014 CDISC Europe Interchange, plans were presented for adoption at some point after FY2017. For more information see the following PMDA page:

Advanced Review with Electronic Data Promotion Group

Timing for New Versions / Study Types / CT

When new study types or versions of the SEND Implementation Guide are brought online, when will they be required?
When will Safety Pharm be required?
When will Respiratory and Cardiovascular be required?
When will Repro be required?
When is SENDIG 3.1 required?
How long is SENDIG 3.0 valid?

(Note: this pertains to updates made after the initial SEND requirement laid out in the previous question, e.g., IG updates, new study types, etc.)

After new standards or updates are published, pending an evaluation by CDER, CDER will add the standard to the Study Data Standards Resources page with a timeframe for requirement. The timeframe for these will be at least 12 months after the standard/version is added to the page, and will apply only to new studies. It is expected that larger scale additions (such as completely new subject areas) will have a longer timeframe for Sponsors to implement and ramp up before it becomes required.

Note:

To get updates (highly recommended), click the "Sign up for email updates" link at the top of the Study Data Standards Resources page.
At any given time, within a class of submission (e.g., NDA vs IND), only one version of a document will be officially required. For instance, as soon as SENDIG 3.1 becomes required for NDAs, SENDIG 3.0 is obsolete for NDAs.
For studies which started when an older version was required (compared to what is required at the time of submission), sponsors have the option to submit with the newer version. For example, say a chronic starts before the 3.1 requirement date, but by the time the study finalizes, 3.1 is now the required version for studies that start. In this example, the Sponsor may choose to submit the study in 3.1 (instead of the 3.0 as technically required).
As of 2018-01-23 (per FDA-2017-N-6879), any updates will follow a schedule as follows after the first Transition Date after inclusion on the Study Data Standards page (with Transition Date=the next March 15th after Study Data Standards inclusion date):
- Updates: 12 months after Transition Date
- New Standards: 24 months after Transition Date

Example - below gives an example of a standards update and the resulting requirement date...

2018-08-10: a revision to a standard is published by CDISC in 2018-08-10
2018-09-04: it completes review by CDER and is added to the Study Data Standards Resources page
2019-03-15: Transition Date, since this is the first March 15th after Study Data Standards inclusion
2020-03-15: requirement starts

Then...

Up to 2018-08-10 (CDISC publish): Sponsors have the opportunity to be a part of the development and public comment periods on the new standard/version leading up to the publish from CDISC, and can anticipate CDER adding it to the Study Data Standards Resources page soon.
From 2018-09-04 (Study Data Standards inclusion) to requirement date (2020-03-15): sponsors have this time to gear up implementation for the updated version.
For a new submission submitted to CDER before 2020-03-15, studies within do not need to adhere to the new standard, although it is encouraged/preferred
For a new submission submitted to CDER after 2020-03-15, studies within the submission which started after 2020-03-15 need to adhere to the new standard. The other studies in the submission which started before 2020-03-15 are not required to be submitted according to the new standard, although it is encouraged/preferred

When will new Controlled Terminology be required?
New CT will be required for studies "within a reasonable timeframe" from the new CT's release date. What is "reasonable" is open to interpretation, but we recommend keeping within a year of the CT's release date when packaging a study.

Note that this stipulation applies to CT active at the time of the creation of the SEND package for the study. For instance, if a SEND package is created for a study in 2013 and not submitted until 2017, the CT to which it must adhere is the CT active at the time of the packaging (e.g., 2013 or shortly before it). There is no requirement to retroactively update past studies with CT that comes out after finalization.

Visit the SEND CT page to get the most recent CT.

When can SEND replace TUMOR.XPT in FDA submissions?
The intent is to phase out tumor.xpt in the future, in that it can be generated from a SEND package. However, it is currently still active. As always, consult the Technical Conformance Guide (as referenced in the Study Data Standards page) to see what is or isn't required.

Submission Questions

What applies to SEND

How do I know whether SEND is mandatory for any given endpoint?
Do I need to include data for unmodeled endpoints?
Is endpoint ___ required for a study type that isn't required?
For an endpoint to be required, it must meet two criteria to be considered mandatory for FDA submissions:

The study type is one explicitly called out in the FDA Study Data Standards
The endpoint is one that is currently covered/modeled by the domains in the SEND Implementation Guide

In other words:

If the endpoints are not currently modeled, it doesn’t matter if it happens to be under the right study type – it doesn’t have a hard requirement.
If the study type is not one asked for, then it doesn’t matter if it happens to be a modeled endpoint – it doesn’t have a hard requirement.

However, this is purely speaking to what is mandatory. The FDA has stated on numerous occasions that they still would prefer to receive data for both of the above exceptions (e.g., via custom domains or to have packages for non-required study types if they have fitting domains). Please contact cder-edata@fda.hhs.gov or cber-edata@fda.hhs.gov for additional advice about such a submission.

Is SEND mandatory for study types that were not piloted?
For example, if there is a safety pharm study with body weights, will the body weights need to be submitted?
The Study Data Standards page provides current expectations/recommendations. Note that while typical study types will be piloted, but a study type need not be piloted to be specified by the Study Data Standards page to be mandatory.
However, electronic submissions of data are encouraged, even when the study type is not yet mandatory. Please contact cder-edata@fda.hhs.gov or cber-edata@fda.hhs.gov for additional advice about such a submission.

For studies I submit with SEND datasets, what is the FDA's recommendation for including non-SEND datasets? (e.g., custom domains)
Is it required to submit data not modeled in a domain yet?
Generally speaking, from the industry side, it is not considered valuable to provide custom domains, given the issues with nonstandardized data (nonstandard format; can't use across organizations, etc.). Additional domains not part of SENDIG would still be present in individual tabulations (e.g., PDF) for submission coverage purposes.
However, in general, this is encouraged by the FDA. Please contact cder-edata@fda.hhs.gov or cber-edata@fda.hhs.gov for additional advice about such a submission.

What exactly needs to be included in a complete SEND package that is ready to submit to the FDA?
See the FDA Test Submission site for more information on getting started.
A typical package includes:

The basic minimums specified in the SENDIG (usually TS, TX, TA, TE, SE, DM, EX)
Whatever endpoints you reported which have a domain in SEND
The define file (usually define.xml)
An nSDRG (Nonclinical Study Data Reviewer's Guide)

In addition, for the submission, the following are generally needed:

A cover letter (e.g., summarizing what's in the submission, reiterating some of the information provided when initiating the submission process, etc.; see FDA site / contact FDA for more information)

Technical Rejection Criteria

As a reminder, the Technical Rejection Criteria are available on the eCTD resources page.

When do the Technical Rejection Criteria go into effect?
As of writing this (2019-06-17), it is not yet officially in effect. In theory, it will be 30 days after publish on the FDA Study Data Standards page (or potentially, the eCTD page).

Which TSPARMCDs are required by FDA?
Just TSPARMCD=STSTDTC is explicitly required (for legacy studies under covered study types, e.g., single dose, carc, etc.). All other studies should have a full TS.

There are new variables added in the base SDTM after the SENDIG was published. Will FDA accept submissions with these not included?
There were several variables added in SDTM v1.3, e.g., TSVALNF, TSVALCD, TSVCDREF, and TSVCDVER. Will FDA accept submissions with these not included?
If it is for legacy data submission, you don’t need to include those variables for TS. For data submissions, please create TS according to the IG you use.

Is the TS.xpt file for studies that start before 2016-12-17 required beginning on 2016-12-17?
edata responded 2018-01 to individual organizations that the short version TS is not required for nonclinical studies unless XPT files are provided. However, the Technical Rejection Criteria document has not yet been updated to reflect this change.

As to officially posted policy, if you submit SEND after 2016-12-17, TS is required (see "When is it ok to include a simplified vs full TS?" question for more details). For legacy cases (e.g., only the report), then only the short version TS is required (single row TS; no DM or Define). All other studies should have a full TS.

The Technical Rejection Criteria can be found on the eCTD page. On this page is a TRC Self-Check Worksheet you can follow to check what you need.

GLP vs Non-GLP

Does SEND cover non-GLP studies?
Short answer is yes. Whether SEND is required is irrespective of whether the study is GLP or Non-GLP. So, if this type of study would be SEND-applicable if it were GLP, then it's also applicable for it as non-GLP.

Does 21 CFR Part 11 apply?
Short answer is yes. It is a critical component of GLP Validation, and there are plenty of cases where GLP Validation applies to SEND datasets.

Minimum requirements wise, it is per study and case that would dictate whether GLP Validation (and 21 CFR Part 11) apply (e.g., if used for pre-final purposes to affect study decisions, etc.).

Many choose to validate the software producing all datasets (with 21 CFR Part 11 coverage inherent) even if used for a mixture of cases, as the intent to use them may vary, and it's easier to validate the single process.

Protocol, Report, QA, QC Impact

How will my study reports from a CRO change when SEND files are used?
For the near future, they will not likely change. However, it is a longer term goal for the SEND datasets to eventually replace the individual tabulated datasets. The main body of the study report, the summary tables and other appendices would remain in their current format, though.

Should SEND be listed in the Protocol or treated only as a contract deliverable?
We recommend SEND be listed in the Protocol to ensure that the endeavor is resourced properly and that expectations are set and met.

Please see the Handling of SEND in Study Documentation page for more details and discussion around this question.

Should SEND datasets be sent through QA review?
Depends on whether they are bound by GLP.

Please see the Handling of SEND in Study Documentation page for more details and discussion around this question.

What QC should be applied to SEND datasets?
Depends on whether they are bound by GLP.

Please see the Handling of SEND in Study Documentation page for more details and discussion around this question.

Will the study director's signature on the report also indicate accountability for the SEND datasets?
Depends on whether they are bound by GLP.

Please see the Handling of SEND in Study Documentation page for more details and discussion around this question.

What documentation is required for SEND datasets created retrospectively (after report finalization)?
Depends on whether they are bound by GLP.

Please see the Handling of SEND in Study Documentation page for more details and discussion around this question.

nSDRG

What is an nSDRG? Must one be sent with each SEND package?

An nSDRG is a document which is meant to aid the reader in understanding the SEND dataset in the context of the study report. The Technical Conformance Guide published by the FDA states that it "...is recommended as an integral part of a standards-compliant study data submission."

What is the proper format of an nSDRG? Does it need to contain anything specific?
While the content and format of an nSDRG are not mandated, the FDA has provided some expectations (and link to template) in the Technical Conformance Guide.

nSDRG: Describing Conformance Issues - Section 5

What kinds of information do Reviewers find useful in this section?
The information in this section has the most value to the Office of Computational Science’s (OCS) Data Loading and KickStart teams. Also, Business Rule errors are very important to the statistical reviewers in the Office of Biostatistics (OB) for the submission of carcinogenicity studies. Nonclinical reviewers will also find value in Business Rule errors related to carcinogenicity studies (e.g., BR FDAB072).

Do you expect that explanations of issues in section 5, when impacting data content are referenced or further explained in the dataset explanations (section 4.2)?
Yes, any issues referenced in Section 4.2 should be referenced in greater detail in Section 5. Please also state that there is additional information in Section 5 when listing the issue in Section 4.2.

Are there some examples of what has been seen in nsdrg and considered “too technical”? (in messages or explanations of validation issues.)
There is no information that is considered too technical for use by OCS. OCS staff will use the information provided to help with some aspect of the review. It is best to provide as much specific information as possible rather than boilerplate language.

Should all validation issues be described in this section, including those determined to be “false”? (false = errors or warnings that result from bugs in Pinnacle 21 Community or other validators that may be used. Some examples of common rule breaks that are false in nature: Errors: DD0059, DD0028, DD0024, DD0064. Warnings: FDAN037, FDAN169, FDAN212, FDAN218, FDAN341, DD0029, PCO497.)
All issues identified by the tool used, regardless of whether it is “false”, should be identified by the sponsor in Section 5.

Are there particular domains which need special consideration regarding the handling of conformance issues (such as MI and Tumor data – where there are a lot (14) of business rules)?
Yes, there are times when cross domain checks cannot be automated, or specific Business Rules do not have automated checks. The Business Rules should not be ignored for these non automated checks. For carcinogenicity studies, these non-automated checks against 14 Business Rules should be performed manually with any errors noted in Section 5. For other types of studies, if a sponsor is confident that the process used to create the SEND datasets aligns with these non-automated rules by establishing that multiple datasets have no errors, manual checking of each dataset is not required.

Do people who do “data loading” use the nSDRG?
Yes, if a Data Management and/or Data Loading teams have trouble loading the data, the nSDRG is one of the first places the teams will look for additional information on conformance issues.

Is the FDA tracking validation rule violations by quantity and/or rule ID?
OCS staff is tracking validator rule violations by quantity but are not tracking the specific rule ID associated with them.

Are trends emerging to suggest certain rules could be either A) impractical for companies to adhere to, or B) too vague in meaning. For example, high variety of explanations could indicate wide misunderstanding of the rule or its application.
The FDA noted several common error trends in datasets submitted by sponsors. The FDA clarifies how to correct the errors in industry meetings and other public forums as well as updates the Technical Conformance Guide (TCG) to ensure the FDA’s needs are met

Working with SEND Files

Using Files, File Formats

What's in a SEND Package? What is a SEND File? What is a SEND dataset?
A SEND package consists of a number of dataset files (in XPT format, a.k.a., SAS v5 Transport format) and a define.xml file (which provides information about what's in the datasets).

If I receive a SEND file (i.e. from a CRO), how do I open it/view my data?
How do I open XPT files?
To open XPT files, you have a few options:

Download and use the free Universal Xpt File Viewer (Open Source). This was previously known as the SAS Viewer, so if you have the SAS Viewer tool, that works in the same way. Note that this tool is very limited in features.
Open in SAS using the XPORT libname option, e.g.:
libname MyLib XPORT "C:\test.xpt"
data test;
set MyLib.test;
...
Open in R

When opened, they appear similarly to Excel workbooks.

Various other vendors have products that will allow you to view SEND datasets as well. These tend to be more robust in visualization/analysis capabilities and enabling of review.

How can I create a ts.xpt file with the Study Start Date?
The nonclinical script group has prepared an R script to help do this. It is available from https://github.com/phuse-org/phuse-scripts/tree/master/contributed/Nonclinical/R/CreatingXPT . To run this script, you will first need to obtain R and confirm you can use it to read an XPT file. Once you are successful with that, do the following

Open a command prompt and enter the command: java -version
If java is installed the version number should be displayed. If it isn't displayed, install java. If you have a 64-bit installation of R you also need a 64-bit installation of java.
Copy the files from the aforementioned github folder to "c:\temp\r testing".
Create an empty sub-folder named "C:\Temp\r testing\xpt output".
Launch RGui
Run the script by selecting the menu options "File" -> "Source R code..." and selecting the file "c:\temp\r testing\CreateTsXPT.R"
Confirm you have xpt files in the appropriate sub-folders of the "xpt output" folder.
Modify the Excel file and/or script as needed to get the results you need.

What should the catalog (dataset) name be for the SAS Transport files?
The catalog (dataset) name should be the same as the name of the xpt file. For example, a SAS transport file named BG.XPT should have a catalog name BG.

Will the XPT files be replaced with something easier to work with, like XML?
Yes. Please see the "When will the XPT files be replaced with XML?" question further below under the SEND Future section.

Are there publicly available sample SEND datasets?

Here is a list of places to obtain sample datasets:

The PHUSE GitHub has a number of example datasets available: https://github.com/phuse-org/phuse-scripts/tree/master/data/send
Contact submit@instem.com with a subject line of “Send me SEND” to get an FDA validated SEND dataset for an example 28 day toxicity study
Go to SENDDataSet.org to download an FDA validated multi-organizational SEND dataset.
Many CROs have sample datasets they can provide to evaluate their capabilities or prepare for your own implementation

There are also many examples in the SENDIG of domain records.

What to Include in a SEND Dataset or SEND Package?

Should I include all variables shown in the implementation tables in my dataset?
The "Core" column in the SEND implementation guide defines for each variable whether you must include the variable in your dataset. You must include all variables that are listed as Req (a.k.a., required, meaning not nullable) and Exp (a.k.a. expected, meaning with or without data, but should have a good reason if not populated). Include variables listed as Perm (a.k.a., permissible, meaning can be excluded from the dataset if you do not collect it) if you have data to report in them in the domain dataset. Note that a few variables listed as permissible are either/or (e.g., AGE and AGETXT in DM); in these cases, you are expected to provide at least one of two, although they are defined as permissible because either is acceptable. Such a case will be noted in the CDISC notes for the variable(s) and/or the assumptions for the domain.

Should I include pretest/stock animals in a SEND dataset?
The animals included in a SEND dataset should be consistent with the animals included in your study data report. Generally this means including pretest/stock animals if they have been assigned to a test treatment group and have study data collected.

What study types can/should I use SEND for or include in my SEND package?
As far as can, the domains modeled in SEND can be applied to any study that has them (SEND covers many standard endpoints), although study types not yet piloted may have some endpoints not yet covered.
As far as should, per the SENDIG, section 1.1: "This version of the SENDIG is designed to support single-dose general toxicology, repeat-dose general toxicology, and carcinogenicity studies." These are the types of studies covered in the CDER pilot. A pilot is open with the CVM group, and pilot plans are being discussed for CBER and other FDA divisions. Additional study types are currently being modeled (repro, safety pharm), during which pilots will be conducted, and updates to the SENDIG to include those study types will be completed. However, note that the domains modeled in SEND can be applied to any study that has them as SEND covers many standard endpoints, although study types not yet piloted may have some endpoints not yet covered.

Working with CROs

What Should I Ask My CRO?
A number of considerations arise when initiating a conversation with another organization around SEND file production. The SEND between Organizations page has an extensive "Points to Consider" question list to help smooth this process.

Working with Multiple Files/Studies/Versions

Should the SENDIG and/or CT version used be the same for all studies in a submission?
Not necessarily. The only requirements are that the same SENDIG/CT version be used within a study, and that the version is what is (reasonably) up-to-date as of the creation of the package. Especially with submissions spanning many years, it is very possible for there to be different SENDIG versions across studies as well as different versions of CT. The only expectation per the draft guidance is that the versions used at the time of creation are current within a reasonable timeframe (what is "reasonable" is being formulated and is expected to be stipulated in the final guidance).

What do I need to do when collating datasets for a domain?
For instance, when two independent labs contribute lab test data toward LB...
In some cases, pieces of a domain may come from different sources, such as different labs or different systems. When bringing the data together into a single dataset for the domain, here are some things to keep in mind:

--SEQ may need to be re-sequenced so that no two rows have the same value within an animal
- And if you do, RELREC records based on --SEQ values may also need to be updated in the same way
--NAM may need to be populated to distinguish between labs performing the testing

How is versioning handled for different versions of a SEND package for a study?
When providing interim datasets, do you provide deltas or full loads?
First, SEND packages are technically only considered valid or complete when they contain all data - there no specifications on providing partial data (e.g., deltas between versions). Subsequent versions of a package (version 2, 3, etc.) would be cumulative from past versions, including the existing data and any data collected since the last package.

In a number of operational cases, it is necessary or useful to be able to tie together records between a current version and the version prior, such as for the detection of deltas. There are a couple options for this:

To definitively identify a record as being the same record across versions of a package, use the RECID variable (invariant record ID), new in SENDIG 3.1. Values might typically source from internal database IDs for the source records which do not change over time. If this is feasible to provide, this is preferable, since it then gives the consuming organization a definitive way to detect which records are new vs updated vs removed.
If the consuming body(-ies) is not interested in figuring out deltas, you could just submit the new version of the package in its entirety.

Miscellaneous

Are calculated results reported in SEND?
Depends on the meaning of "calculated results".

Derived endpoints, like body weight gains, etc. are reported in SEND if you would have included those results in your individual tabulations in the submission.
Statistics, like descriptive statistics (mean, standard deviation/standard error, N, etc.) do not apply even if they may be present on those tables.

Why are there entries in SEND files such as body weight gains and organ weight ratios, when that information can be derived from information in other SEND files?
BG and the relative organ weights in OM were added because they are used in most submissions as individually reported endpoints (and SEND is focused on the individual animal data). Including them as separate endpoints removes any ambiguity or duplicated calculation on the reviewers' part. In the future, these endpoints may be removed as analysis modeling matures for nonclinical data (e.g., through ADaM).

How do I manage unscheduled data (i.e., data collected in an unscheduled interval)?
For unscheduled findings, leave the VISITDY (the planned study day) blank. TPT and TPTNUM values would also be null.

How do I indicate derived records?
When should I use --DRVFL?
What is --DRVFL used for?
Can I use --DRVFL to indicate any derived records?
There are two flavours of derived to consider.

When the record in the dataset is derived from other records in the dataset, then (and only then) you can use the --DRVFL variable to delineate between the derived record and the ones going into the derivation (one example could include blood pressure readings, where the result record is picked or averaged from 3 constituent readings, and so the flag serves to indicate which is the derived record (and in this case, the one to keep). It cannot be used if the record was derived from information outside the dataset; this constraint means is it has limited use.
When the value is calculated through a calculation, algorithm, etc. from data often outside the dataset, then this status can be indicated via the define file (i.e., whether the test was collected, derived, etc.).

SENDIG 3.1 and beyond describes this in more detail.

Controlled Terminology (CT)

For more information on Controlled Terminology, check out the SEND Implementation - CT Fundamentals page.

SEND Implementation FAQ

Basics

Timing/Regulatory

When Was SEND Released?

Part 1: Submission Types and Study Start Timing

Part 2: eCTD Sections

Part 3: Supporting Documents

Timing for New Versions / Study Types / CT

Submission Questions

What applies to SEND

Other FDA Questions

Technical Rejection Criteria

GLP vs Non-GLP

Protocol, Report, QA, QC Impact

nSDRG

Working with SEND Files

Using Files, File Formats

Working with CROs

Working with Multiple Files/Studies/Versions

Miscellaneous

Controlled Terminology (CT)