A Standard for Exchange of Nonclinical Data Implementation Guide (SENDIG) is developed in reference to a specific SDTM model. However, the SDTM is cumulative – each new release builds on the previous model. Therefore, the models are backward compatible. The SENDIG is designed to support data typically found in single-dose general toxicology, repeat-dose general toxicology, and carcinogenicity studies, as well as respiratory and cardiovascular testing conducted during safety pharmacology studies.
Additional SENDIGs have been developed to support other study types. For example, SENDIG-DART v1.1 supports submission of data from nonclinical Developmental and Reproductive Toxicology (DART) studies and SENDIG-AR v1.0 supports the submission of data from studies conducted under the Animal Rule. In addition to models and implementation guides, conformance rules have been developed, which help to ensure that generated data structures conform to the standards. These rules aim to identify all conformance rules and case logic from the SENDIG, classifying and codifying them in a form that supports quality processes and tool development.
SEND: The Standard for Exchange of Nonclinical Data Implementation Guide (SENDIG) is based on the SDTM and guides users on the organization, structure, and format of standard nonclinical study tabulation datasets for exchange between organizations or to be submitted to a regulatory authority. The following videos introduce you to the SENDIG and the SDTM, which used together serve as a map that orients you on how your data fits into the standard.
Make standards that consider the usefulness, from creation through analysis and visualization of the data, to all stakeholders and end users (e.g., CDISC SEND team members, PHUSE SEND teams, sponsors, regulatory authorities, contract research organizations, technology service providers, data managers, biostatisticians).
Test in a real-world setting by a variety of stakeholders will assure quality and longevity of the standard and avoid unnecessary costs in implementation.
- Improves the quality of the standard
- Reduces cost of implementing the standard
Conduct a proof-of-concept (POC) pilot early, within the development team, to prove the purpose and scope of the standard. After a standard is released and vendor tools are available in some form (e.g., beta version), a fit-for-use pilot may assist in testing the usefulness of the standard and providing requirements back into the development of the standard in time to inform the next release. Consider these pilots as important but optional steps in the SEND standards development process.
Each new SEND release must include an assessment and realignment with the SDTM model and the SEND standard. It should also include an assessment and statement of incompatibilities with other standards considered applicable for the scope of the new release (e.g., define.xml).
The SDTM and other CDISC standards are continuously being improved and revised. With each new release there is an opportunity to maintain alignment with the base model for SEND (SDTM) as well as other applicable standards to maintain SEND as an implementation of the SDTM.
Each new SEND release must be assessed and realigned to the SDTM to facilitate data sharing across and within nonclinical and clinical research (e.g., ability to aggregate and analyze data across studies, tissues/systems, and classes of compounds).
Each new SEND release must include an assessment and realignment with the SDTM model and the SEND standard. It should also include an assessment and statement of relationships to other standards, including incompatibilities with standards considered applicable for the scope of the new release (e.g., define.xml). From this assessment:
- Identify with which versions of standards the new release is compatible.
- Identify any new content that should be added to either the SDTM or SENDIG.
- Document any temporary misalignment and future approach intended to address alignment issues (e.g., when a domain will be added to the SENDIG). The Known Issues section (generally part of Section 1) can be a good place to clarify this.
- Identify any cross-team topics or concepts as early as possible and submit for Global Governance Group (GGG) concept consultation.
Carefully consider a set of defined criteria for determining when to create a separate IG based on the SENDIG.
Note: Whereas SENDIG v3.0 and SENDIG v3.1 are versions of SENDIG, SENDIG-DART v1.1 and SENDIG-Animal Rule v1.0 are separate IGs based upon SENDIG.
Careful decisions based consistently on a set of criteria will avoid creating content in multiple places, possibly with redundancies, creating confusion in the user community, and leading to a lack of standardized implementations.
- Clear and easy-to-understand guides
- More efficient and accurate use of the guides by the user community
The SEND Team will first consider inclusion in SENDIG, and use the following criteria to consider whether creation of a separate IG could be beneficial:
- The endpoints are not particularly useful for general toxicology (repeat dose and carcinogenicity) studies.
- The IG audience is a different set of scientists (and can be smaller than the audience for SENDIG).
- Introductory sections would need to be written specifically for this audience’s use cases.
- One large, all-encompassing IG would become too complicated for both the SENDIG audience and the separate IG audience.
- Priorities and timing of delivering solutions can be different, based on different audiences/study types (there are different drivers). If this is considered a new implementation for the industry, a separate lG is recommended and will give regulators the ability to reference it separately if desired.
If these criteria are met, the next step is to begin to describe the “use case” that is different from the SENDIG to date. This will inform CDISC Library in the future. (CDISC Vision: One standard in CDISC Library with many use cases that each become a deliverable with domains/variables/examples to meet that specific use case).
When creating a separate IG, bear in mind the following cautions and considerations:
- We must declare which standard versions are compatible (or why not).
- We must ensure alignment of standards aligned. Whenever SENDIG is updated, it is likely that separate IGs will need to be updated. Minimally, we must evaluate compatibility across IGs with each release of SENDIG. (As mentioned above, it is an expectation of the SEND team that each release of SENDIG is realigned with the SDTM).
- With each new release of SENDIG, the team must plan to roll up separate IGs (as appropriate), and identify all variables or domains that should roll up from each separate IG for consideration in use with all SEND studies.
- Consider the complexity of data standards references in the Data Standards Catalog (e.g., 25 ICH study types, each with a supported and mandated version). On the flip side, this is functional and provides accuracy.
Separate IGs (although based upon SENDIG) will have their own version numbering and may be considered a "new" standard by regulators.
While developing a separate IG, the team should identify any domains or variables that should be considered for inclusion in SENDIG in future.
Use a standard naming convention for implementation guides that differentiate and clearly indicate the SENDIG and separate IGs based upon SENDIG.
As the scope of SEND expands over time, it is important to clearly name implementation guides so the user community can understand the subject or high-level scope of each implementation guide and the relationships between IGs.
- Creates clarity in the use of SEND guides
- Allows more efficient use of the guides
Use the following standard naming conventions for SENDIGs: Separate IGs will use the name SENDIG – nnnn, where nnnn assists in aligning the use of the guide with the International Council for Harmonisation (ICH) study type in the eCTD (electronic Common Technical Document) Module 4 Table of Contents.