Therapeutic Area User Guides (TAUGs)

Introduction

Clinical trials generate data that are partly generic and partly highly specific to the disease, indication, intervention, and assessments being studied.

The generic portion is handled by the CDISC Foundational Standards. These standards provide common structures and terminology for representing clinical-trial data.

But a foundational model cannot fully describe every specialized concept that appears in every disease area.

A lung-cancer study, for example, may need to represent disease-specific tumor characteristics, staging concepts, response assessments, biomarkers, imaging assessments, or other specialized clinical concepts.

A Parkinson's disease study may require a completely different collection of disease-specific concepts.

This is where Therapeutic Area User Guides, commonly called TAUGs, become important.

What Is a TAUG?

A Therapeutic Area User Guide is a CDISC standards document that explains how CDISC standards can be applied to data associated with a specific disease area or therapeutic area.

CDISC describes TAUGs as extensions of the Foundational Standards that represent data pertaining to specific disease areas.

The guides can contain disease-specific metadata, examples, and guidance for implementing CDISC standards, including use cases associated with regulatory submissions.

The important word is extension.

A TAUG is not a replacement for the foundational implementation guides.

Instead, it answers questions such as:

• How should this disease-specific concept be represented?
• Which existing CDISC domain is appropriate?
• Which variables are relevant?
• Which controlled terminology concepts should be used?
• How should a specialized assessment be represented?
• What might the corresponding annotated CRF look like?
• How can the resulting data be represented consistently across studies?

TAUGs in the CDISC Standards Ecosystem

A useful mental model is to think of the CDISC standards ecosystem as a set of layers.

What Problem Do TAUGs Solve?

Without therapeutic-area guidance, different organizations may model the same clinical concept in substantially different ways.

Imagine that three sponsors conduct trials in the same disease.

Sponsor A might place a disease-specific assessment into one domain. Sponsor B might use a different domain. Sponsor C might create a custom structure.

Even if all three approaches appear technically reasonable, inconsistent representation makes downstream comparison, reuse, review, and regulatory assessment more difficult.

TAUGs provide a common reference point.

TAUG Does Not Mean "Study-Specific Data Collection Plan"

One of the most important distinctions for new CDISC programmers is that TAUGs describe how data can be represented.

They do not independently determine:

• Which endpoints a study must collect
• Which assessments a protocol must perform
• Which visits must occur
• Which treatment schedule should be used
• Which statistical hypothesis should be tested
• Which clinical decision rule should be used

Those decisions belong to the clinical development program, protocol, statistical analysis plan, data-management specifications, and other study-specific documents.

TAUGs Are Not Standalone Standards

A common beginner mistake is to open a TAUG and attempt to use it as if it were a complete SDTM Implementation Guide.

That is not the intended workflow.

A TAUG assumes that the implementer understands the foundational standards on which the guide is built.

For example, a TAUG may show that a particular disease assessment belongs in an existing SDTM domain.

The TAUG may explain the disease-specific concept and show an example.

But the implementer still needs to understand the underlying SDTM domain structure, variable rules, controlled terminology, and applicable implementation-guide requirements.

The Relationship Between a TAUG and SDTM

SDTM provides the general framework for representing standardized clinical study data.

A TAUG provides additional context for a therapeutic area.

For example, suppose a disease-specific assessment generates:

Subject
Assessment Date
Assessment Name
Assessment Result
Assessment Category
Assessment Method

The TAUG may explain how those concepts correspond to an SDTM domain and variables.

The implementation process therefore looks conceptually like:

The TAUG helps bridge the gap between clinical meaning and standardized representation.

The Relationship Between a TAUG and CDASH

CDASH addresses the collection side of clinical-trial data.

A TAUG may provide disease-specific collection examples, including annotated CRFs or CDASH metadata.

This can help a study team understand how a clinical concept collected on a CRF can eventually become standardized SDTM data.

The TAUG can provide disease-specific guidance across that pathway.

The Relationship Between a TAUG and ADaM

Some TAUGs include ADaM guidance or examples.

This is particularly useful when a therapeutic area has recurring analysis concepts that benefit from standardized implementation patterns.

For example, a TAUG may illustrate how a disease-specific assessment can feed an analysis dataset.

However, a TAUG does not eliminate the need for study-specific ADaM derivations.

The analysis dataset still needs to support the actual statistical analyses specified for the study.

Controlled Terminology and TAUGs

Controlled Terminology is another important component.

Disease-specific concepts often require standardized codelists or valid values.

A TAUG may identify terminology relevant to the therapeutic area and show how the concepts are used in examples.

This is important because a dataset can be structurally correct while still containing inconsistent terminology.

For example, a study should not casually alternate among:

Progressed
Progression
PD
Disease Progression
Progressive Disease

when the applicable CDISC terminology defines a controlled value for the concept.

Concept Maps

One of the most useful TAUG concepts is the concept map.

A concept map helps connect a clinical idea with its associated metadata and standardized representation.

Why Concept Maps Matter

A concept map is useful because clinical terminology and dataset terminology are not always identical.

A clinician may think in terms of:

Tumor response assessment

while the data model may require a much more explicit representation:

Domain
Test
Category
Method
Result
Result Unit
Date
Evaluator

The concept map helps maintain semantic continuity across those representations.

TAUG Metadata

TAUG metadata can include information such as:

• Concept names
• Definitions
• Synonyms
• Variables
• Controlled terminology
• Domain relationships
• Collection guidance
• Examples
• Situational context
• Implementation notes

For a programmer, the metadata is often more valuable than simply copying an example record.

Annotated CRFs in TAUGs

Some TAUGs provide annotated case report forms, or aCRFs.

An annotated CRF connects collected clinical fields with their intended standardized representation.

Conceptually:

This can be extremely useful during study-startup activities.

For example, a programmer can examine a TAUG aCRF and identify:

• Which CRF field represents the clinical concept
• Which domain is expected to receive the data
• Which variable captures the value
• Which variables provide qualifiers
• Which terminology applies

TAUGs and Study CRF Design

TAUG guidance can influence CRF design, but it should not be interpreted as a mandate to collect every concept shown in the guide.

Suppose a TAUG shows ten disease-specific concepts.

The protocol may only require six of them.

The remaining concepts should not automatically be added to the CRF merely because they appear in the TAUG.

How to Read a TAUG

A practical reading sequence is:

Published TAUG Coverage

CDISC maintains a broad collection of published therapeutic-area guides.

Examples span oncology, infectious diseases, neurology, cardiovascular disease, endocrine disorders, respiratory disease, autoimmune disorders, mental health, rare diseases and other areas.

The exact set of published guides and their versions changes over time, so implementation teams should always verify the current CDISC publication status before beginning a standards-mapping exercise.

TAUGs Are Not Limited to Oncology

Because many CDISC examples encountered by programmers involve oncology, it is easy to assume that TAUGs are primarily an oncology resource.

They are not.

TAUGs exist across numerous therapeutic areas.

This is important for organizations developing reusable standards libraries. A robust standards framework should allow disease-specific extensions without hard-coding assumptions from one therapeutic area into every study.

TAUGs and Disease-Specific Assessments

Disease-specific assessments are often where TAUG guidance becomes most valuable.

Consider a generic assessment:

Assessment
Result
Date

A therapeutic-area implementation may need additional information:

Assessment
Assessment Category
Assessment Method
Body System
Location
Result
Result Unit
Evaluator
Date
Disease-Specific Context

The TAUG helps clarify which concepts are relevant and how they relate to the standard model.

Example: Disease Assessment to SDTM

Imagine a study collects a disease-specific severity score.

A simplified implementation might look conceptually like:

The exact domain and variable assignments depend on the assessment and the applicable implementation guide.

This is precisely why the TAUG should be read together with the underlying SDTM documentation.

TAUG Examples Are Situational

A TAUG example may represent a particular clinical scenario.

For example:

Subject 001
Disease Assessment
Baseline
Positive

This does not mean that every study should create an identical record.

The actual study may have:

• Different timing
• Different assessment methods
• Different categories
• Different applicable variables
• Different terminology
• Additional qualifiers

The correct question is therefore:

rather than:

TAUGs and Custom Domains

One recurring implementation question is whether a disease-specific concept requires a custom domain.

A TAUG can help determine whether the concept fits within an existing standardized domain or structure.

The preferred approach is generally to use an existing standard structure when the concept can be represented appropriately.

Creating custom structures prematurely can introduce unnecessary complexity.

TAUGs and Supplemental Qualifiers

Some disease-specific information may be represented using supplemental qualifier structures when the underlying concept does not fit cleanly into the standard variables.

However, supplemental qualifiers should not become a dumping ground for anything that is difficult to model.

The implementer should first evaluate:

• Whether an existing standard variable applies
• Whether an appropriate domain exists
• Whether the TAUG provides a modeling example
• Whether the implementation guide provides a relevant rule
• Whether the information is genuinely supplemental

TAUGs and Non-Standard Variables

A TAUG example may occasionally expose concepts that require careful consideration because they are not represented by standard variables in the same way as common observations.

The programmer should distinguish:

• Standard variable use
• Permitted variable use in a specific context
• Supplemental qualifier use
• Custom variables
• Custom domains

These decisions should be based on the applicable version of the standards, not simply on the existence of a field in a historical TAUG example.

TA Specifications

An especially important concept for experienced CDISC programmers is the TA Specification.

TA Specifications help address how TAUG examples relate to different versions of SDTM and SDTM Implementation Guides.

This matters because a TAUG example may have been developed against one version of the foundational standards while a current study is using another version.

Why Versioning Is a Major TAUG Issue

Suppose a TAUG was originally developed against:

while a new study uses:

Variables, domains, terminology, rules, or modeling expectations may have changed.

Therefore:

The example must be interpreted in the context of the current standards baseline.

A Practical Version-Control Workflow

TAUGs and Public Review

CDISC develops standards through formal development processes that can include public review.

Public review is important because implementers can identify ambiguities, missing concepts, modeling problems, or practical implementation issues.

CDISC also publishes public-review comments and resolutions for applicable standards.

For organizations implementing standards at scale, reviewing those materials can provide useful context about why a particular modeling decision was made.

TAUG Development and CFAST

Many therapeutic-area standards have historically been developed through the Coalition for Accelerating Standards and Therapies (CFAST) initiative and associated CDISC standards-development processes.

The development process brings together stakeholders from areas such as:

• Pharmaceutical companies
• Biotechnology organizations
• Clinical researchers
• Regulatory organizations
• Standards experts
• Patient and disease-area organizations
• Clinical data experts

The objective is to develop a shared representation of disease-specific clinical concepts.

From Clinical Concept to TAUG

What a TAUG May Contain

The exact structure varies by guide and version, but a TAUG may include components such as:

TAUG vs. Implementation Guide

TAUG vs. Protocol

TAUG vs. SAP

The distinction becomes particularly important for statistical programmers.

The TAUG can explain how an assessment is represented.

The SAP explains how that assessment is used analytically.

For example:

The two documents therefore solve different problems.

TAUGs and Traceability

TAUGs can support traceability by clarifying the relationship between clinical concepts and standardized variables.

A useful conceptual chain is:

The TAUG can provide guidance at the beginning and middle portions of this chain.

The final analysis traceability still needs to be established for the specific study.

Example Traceability Chain

The TAUG helps ensure that the clinical concept remains semantically consistent while it moves through these layers.

TAUGs and Statistical Programmers

Statistical programmers often encounter TAUGs during SDTM and ADaM implementation.

The most valuable skills are not memorizing individual examples.

Instead, programmers should learn to:

• Identify the underlying clinical concept.
• Locate the relevant TAUG section.
• Understand the metadata.
• Identify the applicable SDTM domain.
• Review variables and qualifiers.
• Check controlled terminology.
• Check the standards version.
• Compare the TAUG example with the actual study data.
• Document deviations or study-specific decisions.

TAUG Implementation Is a Mapping Exercise

A useful way to think about implementation is:

The TAUG is therefore not a programming specification by itself.

It is a key source of standards knowledge that informs the programming specification.

A Practical Mapping Example

Suppose source data contain:

PATIENT = 101
ASSESSMENT = Disease Severity
DATE = 2026-01-15
SCORE = 17
UNIT = points

The programmer should not immediately write a data step or R transformation.

First identify:

1. What clinical concept does the field represent?
2. Which TAUG section discusses that concept?
3. Which CDISC domain is appropriate?
4. Which variable represents the assessment?
5. Which variable represents the result?
6. Is "points" an applicable unit?
7. Does controlled terminology apply?
8. What is the correct timing variable?
9. Are additional qualifiers required?

Only after these questions are resolved should the production mapping be implemented.

TAUGs and Data Standards Specifications

A sponsor's study-level standards specification may translate TAUG guidance into explicit programming rules.

For example:

Source Field
    ↓
Clinical Concept
    ↓
TAUG Section
    ↓
SDTM Domain
    ↓
SDTM Variable
    ↓
Controlled Terminology
    ↓
Derivation Rule
    ↓
QC Rule

This is often a more useful artifact for production programming than the TAUG alone.

TAUGs and Pinnacle 21

TAUGs and validation tools solve different problems.

A conformance-validation tool can identify issues such as:

• Invalid variable names
• Unexpected values
• Structural inconsistencies
• Controlled-terminology problems
• Missing required metadata

But validation does not necessarily prove that the study modeled the clinical concept correctly.

TAUGs and Pinnacle 21: Complementary Roles

TAUGs and Define-XML

Define-XML documents metadata describing the submitted datasets.

A TAUG can inform the underlying modeling decisions, while Define-XML communicates the resulting metadata.

Conceptually:

The final Define-XML content must describe the actual study datasets rather than simply reproduce the TAUG example.

TAUGs and ADaM Derivations

A TAUG may show an analysis concept, but the actual ADaM implementation needs to follow the study's analysis requirements.

For example, a disease-specific assessment may be represented in SDTM and then transformed into an ADaM parameter.

SDTM Observation
      ↓
Parameter Selection
      ↓
Baseline Selection
      ↓
Post-Baseline Selection
      ↓
Change Derivation
      ↓
Analysis Population
      ↓
ADaM Parameter

The TAUG can help establish what the clinical concept means. The SAP determines how that concept is used for the actual analysis.

TAUGs Do Not Replace the SAP

This distinction is worth emphasizing.

Suppose a TAUG contains a disease-specific response assessment.

It does not automatically define:

• The primary endpoint
• The analysis population
• The estimand
• The censoring rule
• The missing-data method
• The statistical model
• The multiplicity strategy

Those are study-specific statistical decisions.

Common TAUG Implementation Mistakes

1. Treating the TAUG as a replacement for SDTMIG. The TAUG extends the foundational standards; it does not eliminate them.
2. Copying TAUG examples directly into production code. Examples illustrate modeling patterns and must be adapted to actual study data.
3. Ignoring standards versioning. Historical TAUG examples may have been developed against different versions of SDTM or SDTMIG.
4. Collecting every TAUG concept. A TAUG does not define the study's data-collection requirements.
5. Using a disease-specific concept without checking terminology. Controlled terminology should be reviewed for applicable concepts.
6. Assuming a TAUG determines the analysis. TAUG guidance and SAP requirements solve different problems.
7. Ignoring the clinical definition. A variable mapping can be syntactically valid but semantically incorrect.
8. Failing to document study-specific decisions. Departures from examples should have an understandable rationale.
9. Using a historical TAUG without checking current guidance. Standards evolve.
10. Assuming automated validation proves correct implementation. Conformance checks cannot replace clinical and standards review.

The "TAUG First" Mistake

Another subtle mistake is using the TAUG before understanding the foundational model.

A programmer might see:

Domain = X
Variable = Y
Value = Z

and assume the mapping is self-explanatory.

Without understanding the underlying SDTM rules, however, the programmer may miss:

• Variable role
• Variable type
• Timing conventions
• Identifier variables
• Qualifier relationships
• Controlled terminology
• Domain-level rules

A TAUG is most effective when read as an extension of foundational CDISC knowledge.

A Better Reading Strategy for Programmers

For experienced statistical programmers, a practical reading strategy is:

TAUGs and Metadata Reuse

One major benefit of TAUGs is the opportunity for reusable metadata.

An organization can maintain a standards library containing:

• Therapeutic-area concepts
• Standard domain mappings
• Controlled terminology
• Common derivations
• Common CRF annotations
• Validation rules
• Reusable programming components

The TAUG then becomes one authoritative input into that library.

Building a Therapeutic-Area Standards Library

A mature standards organization might organize reusable content as:

CDISC Foundational Standards
│
├── CDASH
├── SDTM
├── ADaM
├── Controlled Terminology
└── Define-XML
        │
        ├── Oncology
        │   ├── Breast Cancer
        │   ├── Lung Cancer
        │   ├── Colorectal Cancer
        │   └── Prostate Cancer
        │
        ├── Neurology
        │   ├── Alzheimer's
        │   ├── Parkinson's
        │   └── Multiple Sclerosis
        │
        └── Infectious Disease
            ├── HIV
            ├── Hepatitis C
            └── Tuberculosis

This allows the organization to reuse standard components while retaining therapeutic-area-specific extensions.

TAUGs and Standardization Governance

Large organizations should establish governance around TAUG implementation.

A standards committee may need to decide:

• Which TAUG version is approved for use
• Which foundational standards version is paired with it
• Which deviations are allowed
• How local extensions are documented
• How controlled terminology is maintained
• How standards updates are evaluated
• How reusable code is versioned

Without governance, two studies within the same organization may interpret the same TAUG differently.

TAUG Version Control

A useful study-level standards inventory might contain:

This inventory becomes especially important during long studies in which standards versions can change between study startup and submission.

TAUGs and Regulatory Submission Preparation

TAUGs can contribute to regulatory submission standardization because they encourage consistent representation of disease-specific information.

However, a regulatory submission should be based on the applicable regulatory data standards and the sponsor's approved study implementation.

The TAUG is therefore best understood as one component of the standards implementation process rather than as a regulatory submission checklist.

TAUGs and FDA / PMDA Testing

TA Specifications are particularly relevant because they can support testing and compatibility across versions of CDISC standards used by regulatory agencies.

This is one reason version awareness matters so much when implementing a TAUG.

The implementation team should distinguish:

• The original TAUG publication
• The foundational standards versions referenced by that publication
• Current study standards
• Applicable TA Specifications
• Current regulatory technical-conformance expectations

TAUGs and Cross-Study Data Pooling

One of the major strategic benefits of standardized therapeutic-area modeling is improved reuse.

Suppose five studies collect the same disease-specific assessment.

If each study uses a different representation, pooling requires substantial mapping work.

If all studies follow a consistent TAUG-informed implementation, the pooled representation can be substantially more consistent.

This is particularly valuable for integrated summaries, long-term safety analyses, disease registries, and evidence-generation programs.

TAUGs and Data Review

Clinical data reviewers can also benefit from TAUG-informed standardization.

When disease-specific concepts have predictable structures and terminology, reviewers can more easily understand:

• What a record represents
• Which assessment generated it
• Which variables describe the assessment
• How the assessment relates to the disease
• How the concept feeds downstream analysis

TAUGs and Traceability Across Teams

A strong TAUG implementation creates a shared vocabulary between:

• Clinicians
• Data managers
• Statistical programmers
• Biostatisticians
• Standards programmers
• Regulatory submission teams
• Clinical data reviewers

Instead of discussing only variable names, teams can discuss the underlying clinical concept.

A Complete TAUG Implementation Workflow

Example Study-Level TAUG Mapping Table

A practical standards specification might contain a table such as the following.

TAUG Review Checklist for Programmers

What Should You Never Assume From a TAUG?

There are several assumptions that should be avoided.

TAUGs and the Statistical Programmer's Decision Tree

Advanced Point: TAUG Guidance Is Semantic, Not Merely Structural

A sophisticated understanding of TAUGs requires recognizing that the value of a TAUG is not simply the domain mapping.

The more important question is often:

Once the semantic definition is clear, the appropriate representation becomes much easier to determine.

For example, two source fields may both contain numbers.

FIELD_A = 17
FIELD_B = 17

But one could represent a disease severity score while the other represents a laboratory result.

Their identical numeric format does not make them interchangeable.

Advanced Point: Same Concept, Different Study Context

A TAUG concept may appear in multiple study contexts.

For example, an assessment could be collected:

• At screening
• At baseline
• During treatment
• At an unscheduled visit
• At end of treatment
• During follow-up

The underlying concept is the same, but timing and study context can change the resulting records.

This is another reason TAUG examples should be interpreted rather than copied.

Advanced Point: TAUGs and Longitudinal Data

Many therapeutic-area concepts are inherently longitudinal.

A disease assessment may produce:

where \(Y_{it}\) is the patient's assessment at time \(t\).

The TAUG helps standardize the representation of those observations.

The downstream ADaM implementation may then derive:

or:

The TAUG itself does not necessarily define the final statistical derivation. That remains a study-specific analytical decision.

Advanced Point: TAUGs and Reusable Programming

A well-designed standards library can turn recurring TAUG patterns into reusable code.

For example:

TAUG Concept
    ↓
Metadata Specification
    ↓
Reusable Mapping Function
    ↓
Study-Specific Parameters
    ↓
Production Dataset

This can reduce repetitive programming and improve consistency across studies.

However, reusable code should be driven by stable modeling principles rather than hard-coded assumptions from a single TAUG example.

Advanced Point: TAUGs and Study Metadata

The same therapeutic-area metadata can potentially inform multiple study artifacts.

TAUGs and Submission Traceability

For submission-focused programming, the TAUG can help establish why a particular clinical concept was modeled in a particular way.

A traceability record might therefore contain:

Source CRF Field
        ↓
TAUG Concept
        ↓
SDTM Domain.Variable
        ↓
ADaM Parameter
        ↓
TLF
        ↓
Submission Metadata

This provides a more defensible implementation history than relying on individual programmer interpretation.

When a TAUG Does Not Cover Your Concept

Not every clinical concept will appear in a TAUG.

If the study contains a concept that is not covered, the correct response is not necessarily to create a custom solution immediately.

Instead:

1. Review the relevant foundational implementation guide.
2. Search the CDISC standards for similar concepts.
3. Determine whether another therapeutic-area guide contains a relevant modeling pattern.
4. Review controlled terminology.
5. Evaluate whether the concept fits an existing domain.
6. Document the modeling decision.
7. Consider whether standards feedback is appropriate.

TAUGs and Cross-Therapeutic-Area Concepts

Some concepts appear across many disease areas.

Examples can include:

• Vital signs
• Laboratory measurements
• Adverse events
• Concomitant medications
• Medical history
• Exposure
• Demographics

A TAUG should not cause a programmer to reinvent the representation of a generic concept that is already well defined by the foundational standards.

TAUGs and Domain Selection

One of the most practical uses of a TAUG is helping programmers understand domain selection.

A simplified decision process is:

TAUGs and Quality by Design

Using standardized therapeutic-area concepts early in study design can reduce downstream transformation work.

For example:

This is one reason TAUG knowledge is useful not only for programmers but also for clinical data managers and study designers.

TAUG Implementation in an SDTM Programming Team

A practical team workflow might look like:

TAUGs and Standards Review Meetings

A productive standards review meeting should avoid starting with:

Instead start with:

Then determine:

1. What the concept means.
2. Whether the TAUG addresses it.
3. Which foundational standard applies.
4. Which variables represent it.
5. Which terminology applies.
6. What study-specific assumptions are required.

This approach produces better standards decisions.

Common TAUG Quality-Control Questions

TAUGs and the Difference Between "Valid" and "Correct"

This distinction is fundamental to CDISC implementation.

A dataset can be:

without being:

For example, a record may use a valid domain and valid variable names while misrepresenting the clinical meaning of the source data.

TAUGs help reduce that risk by providing semantic and disease-specific context.

TAUGs in the Overall Clinical Data Lifecycle

Practical TAUG Study-Startup Checklist

Practical TAUG Programming Checklist

Common Questions About TAUGs

Does every therapeutic area have a TAUG?

No.

CDISC maintains published guides across many therapeutic areas, but coverage changes over time and not every possible disease or indication necessarily has a published TAUG.

Does a TAUG replace SDTMIG?

No.

The TAUG extends the foundational standards and should be interpreted together with the applicable implementation guides.

Does a TAUG tell me what data to collect?

Not by itself.

The protocol and clinical requirements determine what should be collected. The TAUG helps standardize applicable concepts.

Can I copy a TAUG example directly?

Usually, no.

Examples should be interpreted in their clinical and standards context and adapted to the actual study.

Can a TAUG define my ADaM derivation?

It may provide useful ADaM guidance or examples where applicable, but the study's analysis requirements and SAP ultimately determine the required analysis derivations.

What if the TAUG and the current SDTMIG appear inconsistent?

Check the versions first.

Then review applicable TA Specifications and current CDISC guidance before making a study-specific implementation decision.

The Most Important TAUG Concept

The most important idea is that a TAUG is a bridge between generic CDISC standards and therapeutic-area-specific clinical meaning.

The foundational standards provide the common language.

The TAUG adds disease-specific vocabulary and implementation context.

The study protocol determines what the study actually collects.

The SAP determines how collected information is analyzed.

The programmer connects these pieces into a consistent implementation.

Putting Everything Together

Consider the following complete workflow.

Key Takeaways

References

Clinical Data Interchange Standards Consortium (CDISC). Therapeutic Areas — Published User Guides. CDISC.

Clinical Data Interchange Standards Consortium (CDISC). Therapeutic Area User Guides and disease-area standards documentation.

Clinical Data Interchange Standards Consortium (CDISC). CDISC Foundational Standards, including CDASH, SDTM, ADaM and Controlled Terminology.

Clinical Data Interchange Standards Consortium (CDISC). Standard and Therapeutic Area Versions documentation.

Clinical Data Interchange Standards Consortium (CDISC). TAUG development and public-review documentation.

Clinical Data Interchange Standards Consortium (CDISC). Examples of published Therapeutic Area User Guides, including Rare Diseases, Colorectal Cancer, HIV, PTSD, Vaccines and other therapeutic areas.