SEND Implementation Wiki - SEND Fundamentals

When reading the SEND Implementation Guide, there are a few important concepts to understand from the outset.

Each SEND domain has a table that contains a list of the generally-used variables in the domain, and a description of each variable. Some variables are shared between domains (for example: USUBJID, VISITDY) and other variables are named in a way that indicates what domain it belongs to (For example: LBTEST belongs to the LB domain, BWORRES belongs to the BW domain). Those domain-specific variables are also shared across domains: variables that are the the same except for the domain designation represent the same concept. For example BWTEST, BGTEST, OMTEST, LBTEST all represent the concept of a test name, and the first two letters represent the domain the variable is in. When reading the guide, these shared variables are often represented with "--" replacing the domain abbreviation: --TEST indicates the test name variable in any domain. Therefore, while it may seem like there are a very large number of SEND variables, there is actually a much smaller number of concepts that are represented by those variables, and understanding the variables from one domain will help you understand the variables in another domain of the same type.

It is also best to read the introductory material in Section 1 through 4 of the guide in conjunction with the Domain Model descriptions in Section 5 on, so that the domain descriptions and examples can be used to understand the detail on the concepts described in the beginning of the guide.

• Specifies the structure for a dataset
• Usually endpoint-centric
• Represented by a two-letter code

A domain is a collection of variables (a.k.a., columns or fields) which describes how to layout a given type of data (usually centering around endpoints) and which, when populated for a study, manifests in a dataset. For instance, the BW (Body Weights) domain model tells you a number of fields to include when modeling body weight data, such the animal, date, result, etc. to describe each body weight record.

• A field used in a domain
• Corresponds to an SDTM column
• Usually prefixed with the domain code

A variable is a field or column used in part to describe a record for a domain. For instance, the Body Weights domain's BWDTC variable is used to describe the datetime (DTC) at which a body weight was collected. Typically, variables are prefixed with the domain 2-letter code, then followed by the SDTM column name.

The permissibility of a variable is expressed through the Core column of a domain and has the following values:

• Req (Required) - States that not only is the variable required but also must have a value for each record (no blanks)
• Exp (Expected) - States that the variable must be included but may include blanks if the variable is not applicable to the entry or there is no data available for that variable for the entry
• Perm (Permissible) - States that the variable should be included (if you have data for it) but may be left out of the dataset if there are no data to populate the variable for any entry in the dataset.

A SEND package includes a number of domain datasets (usually endpoints) and a define file (which describes the datasets provided), along with its companion transformation file.

The SENDIG notes that the following domains generally form the foundation of each SEND package: TS, TX, DM, and EX, along with at least 1 endpoint-related domain dataset (such as BW for body weights); however, the list of domains will be specific to each package and what data were collected. Below is an example set of files for a simple submission with body weights and clinical observations:

• define.xml - to describe what is in the submission, such as the columns, comments about the columns, data types, Controlled Terminology used, and so on. Refer to SEND Implementation - Define Fundamentals for more information.
• define-1-0-0.xsl - a static file which allows a visual presentation of the information in the define.xml file when opened with a browser
• ts.xpt - Trial Summary dataset, which provides high-level details about the study
• ta.xpt - Trial Arms dataset, which provides a specification of the sequence of planned treatment-related events in the study
• te.xpt - Trial Elements dataset, which provides a listing of the treatment-related events in the study used in Trial Arms
• tx.xpt - Trial Sets dataset, which provides group information
• dm.xpt - Demographics dataset, which provides a listing of the animals on study
• ex.xpt - Exposure dataset, which provides dosing information
• bw.xpt - Body Weights dataset, which provides body weight results collected on study
• cl.xpt - Clinical Observations dataset, which provides clinical observation results collected on study

Note that the files' names are lowercase in anticipation that they would be submitted in accordance with ICH guidelines.

Controlled Terminology (CT) is the standardization of terms to be used in SEND packages. CT ensures that when referring to the same base concept, everyone calls it the same thing. CT may be specified for a variable in a domain to indicate that there are specific terms that may be used for that variable. CT can be extensible (terms outside the list can be used if not present already) or not (only terms from the list allowed).

Please see the SEND Implementation - CT Fundamentals page for more information on CT, including resources and mapping considerations.

The define file (e.g., define.xml) is a companion file included with each SEND package which describes the SEND package, including such information as which datasets are present, which columns are used, which CT is used, types of the variables, comments on the variables, and so on. In other words, it provides the metadata for the package.

Please see the SEND Implementation - Define Fundamentals page for more information on the define file, including resources and tips.

There are a few variables for expressing the original and standardized results:

• --ORRES reflects your original result as collected, in whatever units under which it was collected
• --STRESC/--STRESN reflect your result in the units of your choosing (e.g., if units are standardized for reporting)

Likewise, there are variables for expressing the units of those results:

• --ORRESU reflects the units of your original result, with their Controlled Terminology preferred label
• --STRESU reflects the units of your choosing for the reported/presented result (e.g., if units are standardized for reporting), with their Controlled Terminology preferred label

It is important to point out the difference between conversion (changing units) and CT mapping (relabeling units). There are no stipulations that you convert to particular units, only that you use particular labels for the units that you used. The --ORRESU and --STRESU variables only represent a mapping or relabeling of the unit used for the result and in no way dictate any conversion required. For instance, if you have an original result of 50 mg/mL, then your --ORRES remains 50, while the --ORRESU gets relabeled to g/L (the scientifically equivalent CT-preferred label for mg/mL). Along those lines, any conversion applied to the standardized result should not be on account of the CT; it should be because you chose to report and present a different unit from what was originally collected.

These concepts are also discussed in the SENDIG in section 4.5.1.1.

The Trial Arms domain allows specification of the planned sequence of treatment (or lack of treatment) events in the study. Arms comprise a number of Trial Elements in a defined sequence.

In simple cases, Trial Arms for a study each have 2 elements: a screening element (predose, before animals are randomized) and a dosing element. For instance, the control arm would have screening and treatment with 0 mg/kg via the control, while a dosing arm would have 2 screening and X mg/kg.

As designs become more complicated, such as latin squares or reduction of dose due to toxic effects, so too do the Trial Arms, mirroring the sequence of treatment changes. The SENDIG has a number of examples of these cases.

It is important to note that specification of the study design is planned - which includes changes to treatment resulting from protocol amendments. For instance, if a dose is planned to be reduced for the high dose group due to toxic effects and is changed by an amendment, then the trial arms should reflect this (e.g., the arm would consist of a screen element, the high dose element, and now the reduced dose element).

In addition, note that Trial Arms and Trial Elements are defined only by treatment (or lack thereof), duration and sequence. Additional factors which may influence the grouping of animals into study groups, such as TK status, housing status, and so on, are not represented by arms/elements. Because of this, multiple groups may be assigned to the same arm, yet be considered separate groups for the study and its analyses. Factors of this nature are represented in Trial Sets.

The Trial Sets domain allows specification of the unique sets of animals on study that are considered separately from other sets by various factors. Dose level is generally automatically one of these factors, but housing type, TK status, and so on, can also contribute toward making different sets.

Because Trial Sets include all of the various factors that make sets of animals stand out from other sets of animals, they are usually at the granularity of groups but can sometimes be a level or two down. For instance, if a sponsor has TK animals considered to be in the same study group as the main study animals, then these may have the same group and group label, but these would be two separate sets. For examples, see the SENDIG.

Traditional preclinical studies are organized into dose groups. Due to the differences in how dose groups are used defined by different organizations and in various data collection systems, it is not possible to say definitively that group=arm or group=set. If results for all animals in a group are analyzed together and are not combined with another group for analysis, chances are your group=arm and set. If you divide the animals in a group for analysis (perhaps main animals and TK animals), then your group is likely an arm and each subset of animals is a set. If you combine groups that have the same dosing regimen for analysis, chances are your groups are sets, and the combined collection of animals is an arm.

It is important to understand the concepts behind Trial Arms and Sets when mapping your study dose groups to these concepts.

Under this method, 1 record is included for each span of time where the dosing parameters were constant. For instance, if an animal received once daily dosing with the same lot for the entire study, then you could include 1 record for the animal, comprising all dosing between the start at day 1 and end of dosing.

If any parameters change, such as the dose level or lot, then create a new record for each change, specifying the start and end of that change. This includes cases where the exposure parameters return to their original values after a period of something else, such as if a high dose group receives a reduced dose for a short period of time before returning to the high dose level. In this case, there are still 3 contiguous periods (high, reduced, then high again).

Pharmacokinetics (PK) data, sometimes also referred to as TK, are represented in SEND through the Pharmacokinetic Concentrations (PC) and Pharmacokinetic Parameters (PP) domains.

The PC domain covers concentrations. PC data are usually collected at a few set days in the study, and within each day, at multiple time points. Each concentration observed is included in this domain.

The PP domain covers the analysis parameter results derived from modeling a curve to the concentrations data. Aspects of the curve, such as Area under the Curve (AUC) or time to max concentration (t_max) are modeled in SEND as parameters in this domain, and are usually tied to the days where the concentrations were measured.

PC and PP are linked through the --RFTDTC variable, which is usually the dose. This provides an implicit link between the concentrations data and their corresponding curve results. The SENDIG provides some more complex examples.

The Comments domain provides a place for comments tied to records in other domains (most commonly, findings domains).

The most common form of comment is to a specific record in another domain. In this case the IDVAR is typically set to the associated domain's --SEQ variable. For instance, a CO record with RDOMAIN="BW", USUBJID="ABC123_101", IDVAR="BWSEQ", and IDVARVAL="163" would tell us that this comment relates to record in the BW domain for USUBJID ABC123_101 where BWSEQ is 163.

Within a domain, comments may be tied to other variables as well. For instance, a comment tied to a value in the MI domain's MISPEC column (aka tissue) could relate a tissue comment.

Comments may also be tied to the domain itself (general domain comment), or the study at a whole, also these are less typical. Examples of these cases are shown in the SENDIG.

RELREC is centered around providing a place to put objective, known relationships between information (e.g., relationships collected in the system, or implicit relationships like PP records' link to the PC records used to create them). These RELREC relationships are most commonly defined within a subject (or pool), linking specific records from one domain to other records for that same subject in another domain. Each relationship is given a RELID (Relationship ID) which identifies the relationship (e.g., all of the rows with RELID=1 are related to one another; all of the rows with RELID=2 are related to each other; etc.).

Within a relationship, contributing records are identified within a domain by way of the IDVAR (Identifying Variable) column, which states which variable in a domain we want to use to relate. For instance, if the IDVAR=BWSEQ, then we know that this relationship contains some related body weight records, which we call out by way of their BWSEQ values. In this way, each contributor to the relationship is listed, until all of the related records are represented in the RELREC.

Note that RELREC is not used for subjective, post hoc relationships used more toward analysis or interpretation (such as a Study Director later deciding during the writing of his/her results that some clinical observations might be related to some clinical pathology findings); these types of relationships are not in the scope of SEND and are more a function of analysis modeling (e.g., ADaM).

• Note that RELREC is intended to represent objective, known relationships, not arbitrary or interpretive relationships assigned post hoc at the time of the report preparation or summarization. For example, if a clinical observation is explicitly established during collection as correlated to a mass in MA, that is fair game. Likewise, the implicitly known, a priori relationship between the concentrations in PC and the PP results created from them also belongs in RELREC. However, it would not be appropriate to add an after-the-fact, interpretive RELREC relationship for the case where someone report-side decides to link a body weight with a clinical pathology test result to point out a link of interest.
• For further examples, see the SENDIG provides specific examples of RELREC usage.