Guiding Principles

"Guiding Principles" describe a broad philosophy of beliefs and values to direct an organization's operations, goals and strategies. CDISC's Guiding Principles address high-level "Organization Principles" as well as detailed "Standards Development Principles" to foster the global adoption of standards that clear the way for more meaningful and efficient research that has greater impact on global health.

Guiding Principles - Hierarchy - Transparent
  • At the highest level of guiding principles, CDISC has outlined important Organizational Principles that emphasize our values and broadly set direction for all of our work efforts.
  • The Standards Development High-Level Principles are more specific actionable principles that span all our standards development teams and are aligned with and supportive of the Organizational Principles.
  • Based upon the Organizational Principles and Standards Development High-Level Principles, each CDISC foundational team has developed additional high-level principles specific to their team, the Team High-Level Principles.
  • In addition, a set of Standards Design Principles have been initiated to guide consistency across the SDTM family of standards and to support all stakeholders, ensuring independent implementations achieve the same modeling result.

Organizational Guiding Principles

  • Develop standards of the highest quality that allow all researchers to leverage and share information from individuals and studies around the world.
  • Facilitate the ability for implementers of CDISC standards to effectively structure and analyze data so that it is easily interpreted, understood, and navigated by regulatory reviewers.
  • Ensure the standards are developed in a manner that emphasizes content, structure and quality, transcending implementation strategy and platform.
  • Convene a global, multidisciplinary, cross-functional community of members, volunteers and stakeholders from across the research spectrum to develop consensus-based standards.
  • Collaborate, and partner with, fellow thought leaders and organizations on key initiatives to foster efforts to advance standards and semantics.
  • Accomplish CDISC goals without promoting any individual vendor or organization.

Standards Development Guiding Principles

Statement:

Consider the needs of stakeholders at all levels and functions (e.g., data creation, cleaning, analysis and review).

Rationale:

Standards are only effective if adopted, and standards are only adopted if the adopters recognize a benefit.

Key Benefits:

When standards development carefully considers the needs of the users, promotion of the final standard is simplified. Stakeholders readily see the advantages and ideally will promote the standard to others.

Statement:

Obtain project approvals from appropriate CDISC governing body(bodies); understand how the project fits within the technical roadmap and existing CDISC standards.

Rationale:

Resources are finite, therefore efforts must be coordinated and organized.

Key Benefits:

Adherence will:

  • Prevent duplication or overlap of effort.

  • Prevent development of conflicting standards.

  • Ensure the use of volunteer resources is optimized.

Statement:

The standards we produce are truly approved models. They are effective when adherence by all stakeholders produces comparable results.

Rationale:

To be effective, a standard must not be ambiguous.

Key Benefits:

Benefits of clear and unambiguous standards are:

  • Data are quickly understood by all parties when all parties understand CDISC standards.
  • Data are shared easily between any combinations of stakeholders who understand our products.
  • When users understand our products, data from any/all sources (e.g., academia, preclinical, clinical, post-marketing, patients) are easily combined and analyzed.

These benefits result in treatments that are:

  • developed more quickly, with less cost
  • less expensive in the marketplace
  • more effective and/or better tolerated
  • approved and marketed sooner
Statement:

Stakeholders require stable CDISC standards.

Rationale:

Change is time consuming and costly. CDISC standards should be mature upon release, meet stakeholder needs, and reflect consensus decision-making of the team to increase stability.

Key Benefits:

Stable standards will:

  • Increase value
  • Increase satisfaction
  • Improve integration of data
  • Decrease documentation and training overhead
Statement:

CDISC standards should include features that are necessary and easy to use.

Rationale:

Stakeholders need:

  • CDISC standards that support transfer and semantic interoperability of scientific content
  • CDISC standards documentation that are easily learned, understood, implemented, navigated, and satisfying to use
  • CDISC standards development processes that are easily learned, efficiently use volunteer time, ensure errors are minimized and/or recoverable, and satisfy participants
Key Benefits:

Standards that provide necessary features and are easy to use will

  • Increase value
  • Increase satisfaction
  • Improve support
Statement:

Ensure that all projects are defined as to deliver value to stakeholders.

Rationale:

CDISC is charged with developing standards that benefit all stakeholders.

Key Benefits:

By focusing on delivering value, we ensure that our products will facilitate the exchange of clinical data between stakeholders, speed the drug development process, and support delivery of effective drugs to patients.

Statement:

Preserve and adhere to established models and associated semantics.

Rationale:

Without conceptual integrity, there is no standard.

Key Benefits:

By enforcing conceptual integrity, we ensure consistency and stability of the standards, and deliver a "gold standard" for trial and healthcare data.

Statement:

Each project will define timing, end goals, and final deliverables, within an approved timeframe in a charter. Charters are approved by the appropriate governing body.

Rationale:

Because of the changing nature of clinical science and continued learning and harmonization, standards are developed in increments and versions to ensure quality, harmonization, and deliverability within a reasonable timeline.

Key Benefits:

Manageable workloads allow for quality and harmonization with other standards and deliverability.

Statement:

Position decision making at the lowest responsibility level.

Rationale:

Use as little governance as possible; burdensome governance stifles innovation and slows progress. Teams are empowered to address governance issues within the CDISC governance framework.

Key Benefits:

Right-size governance increases

  • Effectiveness, engagement, productivity
  • Team member satisfaction
Statement:

Standards governance should ensure alignment of initiatives with organizational goals to create value for implementers. CDISC standards governance should be responsive to the community, efficient, and focused on quality, and provide clear decision-making pathways.

Rationale:

Standards governance provides a framework for project management with clear decision-making and escalation pathways, including to create an environment for agile development.

Key Benefits:

Nimble governance results in

  • A transparent development process that ensures wide input and review.
Statement:

CDISC has an escalation policy that is used only when all avenues to resolve an issue within a team have been exhausted. The decision of the escalation committee is binding and will not be revisited unless significant additional information not previously considered comes to light.

Rationale:

Teams are empowered to resolve issues. However, occasional instances may arise where the team reaches an impasse. The escalation process is in place to mediate issues, as a last recourse.

Key Benefits:

Escalation process is necessary to:

  • Ensure the development process advances by breaking impasses
  • Support transparency and the Be Clear principle

Team Level Guiding Principles

ADaM

Statement:

ADaM standards are developed to align with analysis needs, enable analysis-ready datasets, and support the needs of reviewers, including traceability back to SDTM.

Rationale:

Study analysis reporting should not need to change in order to be represented in ADaM. Reviewer needs should also be met using ADaM standards.

Key Benefits:
  • Enables the standards to be broadly adopted
  • Allows reproduction of analysis results
  • Allows re-use of programs and automation of metadata-driven processes
Statement:

ADaM develops clear, consistent, and predictable analysis dataset standards that can be clearly understood and readily implemented.

Rationale:

Consistency and predictability in the data standard aid in both development and the review process.

Key Benefits:
  • Eases implementation of the ADaM standard
  • Fosters communication between users of ADaM datasets
Actions you can take:

Include rules/validation checks as part of development

Statement:

ADaM sets the standard for both data and metadata.

Rationale:

Clear communication can be achieved by readable metadata.

Key Benefits:
  • Aids in clear and unambiguous communication.
  • Allows for representation in CDISC Library
Statement:

ADaM standards are developed with the expectation of SDTM data as the source and Define-XML as the standard for delivering metadata.

Rationale:

SDTM, ADaM, and Define-XML are all parts of the CDISC standard.

Key Benefits:
  • Enables standards to work together.
  • Supports traceability across the CDISC standards
Statement:

ADaM deliverables are determined and prioritized based on a blend of considerations, including addressing the most commonly occurring analysis needs, regulatory guidance, other CDISC initiatives and developments, and team members’ interest.

Rationale:

Deliver what industry needs and we have the skill set to create.

Key Benefits:

Provides solutions that are broadly applicable, taking advantage of interest.

CDASH

Statement:

CDASHIG metadata will be developed using the same Observation Classes and Domains as SDTMIG.

Rationale:

Using the same domain names for collection and tabulation builds in high-level traceability and gives implementers the opportunity to automate some SDTMIG dataset creation.

Key Benefits:

Regulatory reviewers appreciate traceability. Implementers appreciate efficiency and the ability to automate.

Statement:

When concepts are related but not identical, or when values are not identical (except for case), the names will be similar and shall indicate a degree of relatedness. For example, substance use duration may be collected using the CDASHIG variables SUCDUR and SUCDURU with the respective values of "5" and "YEARS", but submitted as SUDUR = "P5Y". 

Rationale:

Using the same variable name for data collection and data tabulation allows implementers to directly populate identical collection and tabulation variables.  

Key Benefits:

Efficiency and clear traceability.

Statement:

When developing the standard, consider the needs of all stakeholders (e.g., clinical team members, sites, clinical data managers, SDTM programmers, statisticians and statistical programmers) and balance the needs of each. 

Rationale:

CDISC develops standards that benefit all stakeholders. Decisions made in developing CDASH must weigh the cost-benefit ratio for all stakeholders.

Key Benefits:
  • Optimizing CDASH for all stakeholders supports wider adoption.
  • Weighing all viewpoints helps to respond to inquiries from stakeholder representatives during public review and beyond.
Statement:

CDASH will share value lists with SDTM controlled terminology codelists, using the CDISC Submission Values as much as possible, or synonyms where the CDISC Submission Values are not practical for data collection.

Rationale:

Using the same (or synonymous) values for data collection and submission results in greater transparency, traceability, and efficiency.

Key Benefits:

Efficiency and clear traceability.

Statement:

CDASH creates standardized questions that match the CDASH definition of the variable.

Rationale:

The basis for semantic interoperability is that every time we use the variable/question it means the same thing.

Key Benefits:

Semantic interoperability allows us to combine data across studies and get a meaningful result, and also makes data useful outside the context of a single study.

Controlled Terminology

Statement:

Terminology development process should ensure that the principles within CDISC models and guides are upheld.

Rationale:

Domain models and guides influence and inform terminology team decision making. CDISC terminology is developed based on the meaning and use of domains and variables, as outlined in implementation and user guides. These guides give each terminology team a starter set of scoping rules in order to identify appropriate terms for a given codelist.

Key Benefits:
  • Helps maintain integrity of the appropriate implementation of the domain model and decreases the chance of overloading variable meaning
  • Leads to consistency within and across CDISC terminology products
  • Supports the consistent representation of data within variable
Actions you can take:

Terminology team members should understand the meaning and use of CDISC models, domains, variables, and guides.

Statement:

CDISC terminology analysis should inform the development of new domains, variables, and guides.

Rationale:

When new domains, guides, or variables are being developed, it is best practice to engage terminology early in the process, as terminology considerations may influence standards development.

Key Benefits:

Ensures that new domains, guides or examples are consistently and accurately generated according to standards development timelines

Actions you can take:

Terminology team members should be aware of new standards development and ensure terminology representation on these development teams. Terminology team members should communicate concerns to the standards development team leads.

Statement:

Be mindful of the impact of terminology changes to the user community.

Rationale:

Some terminology changes are costly or disruptive for end users, although some change is necessary as the science changes. Terms and codelists are shared across multiple terminology teams within CDISC.

Key Benefits:

Minimizes unnecessary or unproductive changes to terminology.

Actions you can take:

Terminology teams should assess the value added for any proposed change to existing controlled terminology and be mindful of the cost of change implementation and version management to end users. Terminology teams need to identify other CDISC stakeholders affected by a change and recognize the additional impact for a cross-team change. The team will solicit feedback from these additional teams before a final decision is made.

Statement:

Terminology changes should be communicated, and stakeholder input taken into consideration, before publication of production terminology.

Rationale:

Dictionary management is time and resource intensive. It is helpful to communicate intended changes to all stakeholders well in advance to support timely implementation of terminology changes.

Key Benefits:

Early and transparent communication between stakeholders and terminology teams during the entire terminology development lifecycle ensures stability of published terminology, facilitating adoption and consistent implementation.

Actions you can take:

Terminology team decisions will be available in team working documents located on the CDISC wiki. Webinars will be given to summarize all changes being proposed within each package. All terminology products will go through public review. Stakeholders can comment on all terminology in public review and all stakeholder comments are visible to the public. Denied requests are publicly accessible with reason for rejection.

Statement:

Consider terminology reuse before new development.

Rationale:

Terminology development is resource intensive. The definition of a term should be context independent. Reusing existing CDISC terminology and other terminologies from standards development organizations is appropriate and encouraged.

Key Benefits:

Reuse of existing terminology, where applicable and appropriate, is less resource intensive and decreases development costs. Reuse promotes semantic alignment, regardless of use or context. This also ensures we avoid duplication which, in turn, makes terminology development more efficient.

Actions you can take:

Refer to the latest version of CDISC terminology whenever requesting or creating new terminology. Consider previously developed source terms and definitions from regulatory authorities and standards development organizations.

Statement:

Make consistent decisions when developing terminology and consider precedent-setting aspects before making final decisions.

Rationale:

Consistent decision making during the terminology process leads to consistent usage and granularity of terms.

Key Benefits:
  • Consistency within and across CDISC codelists and terminology products ensures the production of high-quality terminology.
  • Decisions made by different teams are consistent when aligned to a set of shared rules and principles.
Actions you can take:

Follow published terminology principles, rules, and best practices. Assess whether additional rule sets are necessary and develop these as needed. Transform identified precedents into published rules. Be mindful of setting additional precedents.

Statement:

Proactively meet the emerging needs of CDISC teams and users.

Rationale:

A prospective and responsive approach to regulatory and data exchange needs facilitates consistent data and earlier standards adoption.

Key Benefits:
  • Early development of terminology resources enhances consistency in terminology use across different stakeholders.
  • Proactive terminology management enhances quality across the data lifecycle.
Actions you can take:

Be informed of standards development activities within CDISC to identify and support terminology development opportunities. Create and maintain supplemental terminology products (e.g., rule sets, value level metadata, denied request dispositions). Correct errors promptly.

Data Exchange

Statement:

Supporting automation for implementation of CDISC Foundational standards is a fundamental requirement for Data Exchange Standards development.

Rationale:

From the beginning, the Data Exchange Standards have been harmonized with CDISC Foundational standards.

Key Benefits:

Reduces cost and improves efficiency for CDISC implementers.

Statement:

Data Exchanges Standards should reuse XML components from the ODM and other CDISC extensions when usage is aligned with the semantics.

Rationale:

The ODM has already been aligned with BRIDG.

Key Benefits:

Parsimonious models are more efficient.

Statement:

The Data Exchange Standards are developed following an agile development process.

Rationale:

Agile is widely recognized as a software development best practice.

Key Benefits:
  • New versions are more frequent and with fewer changes.
  • Effort for adopting a new version will be less.
  • New versions reflect most urgent needs identified by implementers.
Statement:

Define as much of the standard through the XML Schema as possible.

Rationale:

Leverage XML technology as much as possible. This may include related technologies like Json.

Key Benefits:

Enables implementers to leverage widely available low-cost tools and encourages collaboration with organizations working with other health care/biomedical science standards.

Statement:

Ensure our Data Exchange Standards are clearly documented.

Rationale:

Many programmers will need to implement XML Technology standards without attending a training class.

Key Benefits:

The quality of documents following the Data Exchange Standards will be consistent. This is important for encouraging new implementations.

SDTMIG

Statement:

Coordinate across standards teams and within SDS. Refer to guiding priniciples, published models, implementation guides (IGs), and therapeutic area user guides (TAUGs) when debating how to model data.

Rationale:

Decision consistency during consultation and development leads to the production of higher quality products. Inconsistent decision making leads to incorrect usage or inconsistent use of standards. This, in turn, leads to confusion within the user community.

Key Benefits:
  • Ensures consistency across IGs, conformance rules, and TAUGs
  • Facilitates alignment of decisions made by different foundation and therapeutic area teams
Actions you can take:

Follow published rules; be mindful of precedent setting.

Statement:

Provide timely support for developing new projects and when teams approach SDS for consultation.

Rationale:

Timely support during consultation and development leads to the production of higher quality products.

Key Benefits:

Allows predictability and alignment with project timelines and publications.

Actions you can take:
  • Be accountable to complete support steps for given projects and consultation.
  • Read pre-reads as available for full-team meeting.
  • Bear in mind time provided for a topic of discussion.
  • Determine short- and long-term solutions as needed.
  • Form subteams as needed to address issues, but set goals and time limits for the decisions to be made.
Statement:

Coordinate across standards teams and within SDS. Be mindful of the impact of changes to the SDTM and SDTMIG and other CDISC standards.

Rationale:

Changes and updates may affect the work of implementers. Significant alterations to the SDTM and SDTMIG used by multiple user communities should be communicated to all stakeholders.

Key Benefits:
  • Decreases the amount of changes the user community has to implement
  • Decreases the cost in time and money of versioning
  • Decreases the introduction of errors within company standards
  • Minimizes unnecessary or unproductive changes
Actions you can take:
  • Bear in mind the processes in place for requesting new domains or changes to the standard. 
  • Refer to the SDS Decision Tree for the appropriate steps to follow when considering new activities (e.g, an idea, a new project or proposal).
  • Change requesters should always check the most recent model, IG, and non-standard variable registry before submitting change requests.
  • Change requesters should check with the appropriate foundational teams to determine impact. Feedback should be solicited from all foundational teams.

SEND

Statement:

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).

Rationale:

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. 

Key Benefits:
  • Improves the quality of the standard
  • Reduces cost of implementing the standard
Actions you can take:

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.

Statement:

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).

Rationale:

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.

Key Benefits:

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).

Actions you can take:

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.
Statement:

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.

Rationale:

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.

Key Benefits:
  • Clear and easy-to-understand guides
  • More efficient and accurate use of the guides by the user community
Actions you can take:

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:

  1. The endpoints are not particularly useful for general toxicology (repeat dose and carcinogenicity) studies.
  2. The IG audience is a different set of scientists (and can be smaller than the audience for SENDIG).
  3. Introductory sections would need to be written specifically for this audience’s use cases.
  4. One large, all-encompassing IG would become too complicated for both the SENDIG audience and the separate IG audience.
  5. 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:

  1. We must declare which standard versions are compatible (or why not).
  2. 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). 
  3. 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.
  4. 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.

Notes:

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.

Statement:

Use a standard naming convention for implementation guides that differentiate and clearly indicate the SENDIG and separate IGs based upon SENDIG.

Rationale:

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.

Key Benefits:
  • Creates clarity in the use of SEND guides
  • Allows more efficient use of the guides
Actions you can take:

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.

Dataset-JSON

Digital Data Flow

Standards Design Principles for SDTM

Statement:

For domains based on a general observation class, determining the SDTM class is the most important modeling decision point. Identifying the appropriate domain is dependent on understanding the general observation class.

Rationale:

The SDTM is a metadata model and SDTMIG domains classified as Interventions, Events, Findings, or Findings About are instantiations of an SDTM general observation class.

Key Benefits:
  • Consistent representation of concepts in all domains in the same general observation class
    • Users who become familiar with the SDTM root variable definitions understand a variable's meaning in SDTMIG domains.
    • SDTMIG domains based on the same SDTM general observation class can be combined to look across topics (e.g., Medical History, Adverse Events, Clinical Events).
  • Data repositories based on the conceptual model support warehousing standard and custom domains.
  • Efficient creation of new or custom domains based on an SDTM general observation class
  • Data represented in a custom domain can be easily migrated to a newly published domain of the same general observation class.
Statement:

Every variable must have a clear definition to achieve structural standardization.

Rationale:

To be effective, concept definitions must not be ambiguous.

Key Benefits:
  • A stakeholder who becomes familiar with the SDTM root variables and their definitions should understand their meaning in all IG domains.
    • Implementers of IG domains know which variables to use.
    • Users of IG domains know where to find data.
  • Users of standardized study data should be able to find data without having to understand study-specific data collections or conventions.
Statement:

Every data element (i.e., clinical study data element, nonclinical endpoint) should have a clear definition to achieve semantic standardization.

  • A clinical study data element is a single observation associated with a subject in a clinical study. A data element in an eCRF represents the smallest unit of observation captured for a subject in a clinical investigation (C142437). Examples include birth date, white blood cell count, pain severity measure, and other clinical observations made and documented during a study.
  • A nonclinical endpoint is a defined variable intended to reflect an outcome of interest that is analyzed to address a particular research question.
Rationale:

To be effective, concept definitions must not be ambiguous.

Key Benefits:
  • A stakeholder who becomes familiar with CDISC Controlled Terminology should understand the meaning of a value within a record.
    • Implementers of IG domains know what values to represent.
    • Users of IG domains know what values they will find in the data.
Statement:

A defined concept (i.e., clinical study data element, nonclinical endpoint) should be represented in the same domain.

Rationale:

Consistency and predictability in the data representation aid in both the development and the review process.

Key Benefits:
  • Data are easy to find using SDTMIG domain definitions, assumptions, and examples.
  • Users of standardized study data should be able to find data without having to understand study-specific data collections or conventions.
Statement:

SDTM domains represent collected or received data that have been standardized to facilitate review and reporting. Standardization must not change the original meaning of the data.

Rationale:

Review is easier and more meaningful when data are in standardized format.

Key Benefits:
  • Facilitates comparison of data collected in different formats
  • Supports simple analyses using SDTM datasets
Statement:

Be mindful of the impact of modeling changes to the user community. Minimize unnecessary or unproductive changes.

Rationale:

Change is costly and disruptive for end users, though some changes are necessary to correct an error/problem or to evolve the standard.

Key Benefits:
  • Supports design stability and usefulness