Adverse Event Tables: SOC and PT Reporting

Introduction

Adverse event tables are among the most frequently reviewed outputs in a clinical study. They appear in statistical analysis plans, tables/listings/ figures specifications, clinical study reports, submission packages, and safety reviews.

A typical safety summary is organized using the Medical Dictionary for Regulatory Activities (MedDRA). Events are commonly presented first at the System Organ Class (SOC) level and then at the Preferred Term (PT) level.

The challenge is that an adverse event dataset contains event records, whereas the headline percentage in an AE table is usually a number of subjects who experienced at least one event in the specified category.

The MedDRA Hierarchy

MedDRA organizes medical concepts through a hierarchical structure. For routine clinical trial safety tables, the levels most relevant to AE reporting are the System Organ Class (SOC), High Level Group Term (HLGT), High Level Term (HLT), and Preferred Term (PT).

The PT is generally the most recognizable row-level concept in a standard SOC/PT AE table. Each PT belongs to a defined hierarchy, allowing related PTs to be grouped under an SOC.

What Is a Treatment-Emergent Adverse Event?

Before building the table, the analysis population must be defined. A common safety analysis is based on treatment-emergent adverse events (TEAEs).

Conceptually, a TEAE is an adverse event that starts or worsens after the relevant treatment exposure begins, according to the study's prespecified algorithm.

The exact definition matters. For example, a protocol or SAP may distinguish between events that were present before first dose, events that started after first dose, and pre-existing events that increased in severity after treatment. The analysis specification—not an informal assumption—should determine which records enter the TEAE table.

The Denominator

Most AE tables report both a count and a percentage. For treatment group \(g\), let \(N_g\) be the number of subjects in the specified safety analysis set.

If \(n_{gj}\) subjects in treatment group \(g\) experience AE category \(j\), the percentage is:

The denominator should correspond to the population defined for the table. In many randomized trials this is the number of subjects in the safety set for the treatment group. However, the SAP may specify a different population or special denominator rules for particular analyses.

Subjects, Not Events, Are Usually Counted

Suppose Subject 101 has headache recorded three times. If all three records map to the same PT and meet the analysis criteria, the standard subject-level PT count is still one.

Mathematically, define an indicator for subject \(i\) and AE category \(j\):

Then the number of subjects with category \(j\) in treatment group \(g\) is:

This is the fundamental reason that a simple frequency of AE records can produce incorrect table results.

SOC Counts and PT Counts Are Different

A subject can experience multiple PTs within one SOC. The subject therefore counts once for each applicable PT, but also counts once for the SOC.

For example, if one subject experiences nausea and vomiting, both mapped to a Gastrointestinal disorders SOC, the subject contributes one to the nausea PT, one to the vomiting PT, and one to the Gastrointestinal disorders SOC.

This means the PT percentages within an SOC do not generally add to the SOC percentage. Likewise, PT percentages across different SOCs cannot be summed to obtain an overall percentage.

A Standard SOC/PT Table Structure

A common safety table has one treatment column per study arm. Each row contains a subject count and percentage, often displayed as n (%).

Ordering SOCs and PTs

The table shell should specify how SOCs and PTs are ordered. A common approach is to order SOCs using the standard MedDRA convention and PTs within an SOC according to a prespecified rule such as descending frequency, alphabetic order, or another study-defined convention.

The important point is not that one ordering method is universally required. The important point is that the ordering rule is explicit, reproducible, and consistent between the production dataset and the QC dataset.

Overall AE Reporting

The overall TEAE row is not obtained by adding the SOC counts. A subject who experiences events in several SOCs must still count only once in the overall row.

If subject-level indicators for the SOCs are \(I_{i1},\ldots,I_{iK}\), the overall indicator is the union:

Equivalently, a subject is counted once if at least one qualifying TEAE is present, regardless of how many SOCs or PTs are represented.

Worked Example: Start With the Raw AE Records

Consider a small study with two treatment groups. The following records are illustrative and are intentionally small enough to inspect by hand.

Step 1: Determine the Subject-Level PT Counts

Subject 001 has two headache records, but contributes only one subject to the Headache PT count. Subject 004 has two nausea records, but contributes only one subject to the Nausea PT count.

Step 2: Determine the SOC Counts

For Gastrointestinal disorders, Placebo has Subject 002 and Drug A has Subjects 004 and 006. Therefore the SOC counts are 1 and 2, respectively.

For Nervous system disorders, Placebo has Subjects 001 and 003, while Drug A has Subjects 005 and 007. Therefore the SOC counts are 2 and 2.

Step 3: Determine the Overall TEAE Count

Placebo has Subjects 001, 002, and 003 with at least one qualifying TEAE. Therefore the overall count is 3.

Drug A has Subjects 004, 005, 006, and 007 with at least one qualifying TEAE. Therefore the overall count is 4.

Notice that the Drug A SOC counts are 2 + 2 = 4 in this small example only because the two SOC groups happen to contain different subjects. In a real study, a subject may experience events in several SOCs, so summing SOC counts would generally overcount the overall number of subjects.

Step 4: Add Percentages

If each treatment group contains 10 subjects, the overall TEAE percentages are 40.0% for Drug A and 30.0% for Placebo. For the Drug A Gastrointestinal Disorders SOC, the percentage is 20.0%; for Nervous system disorders it is 20.0%.

Severity: Mild, Moderate, and Severe

AE tables often include separate summaries by severity. The categories may be Mild, Moderate, and Severe, or another prespecified scale.

The key question is what to do when one subject has repeated occurrences of a PT at different severities. A common subject-level approach is to assign the subject to the maximum observed severity for that PT, so that a subject with Mild and Moderate headache contributes once to the Moderate headache category rather than once to both.

For subject \(i\) and PT \(j\), a simple maximum-severity rule can be represented as:

where the severity categories have first been mapped to an ordered scale such as Mild < Moderate < Severe. This mathematical representation is illustrative; the actual study rule may differ.

Seriousness Is Not the Same as Severity

One of the most important AE reporting distinctions is between severity and seriousness.

Severity describes the intensity of an event, whereas seriousness is a regulatory classification based on defined criteria. A severe event is not necessarily a serious adverse event, and a serious adverse event is not necessarily severe.

Serious Adverse Events

A standard safety package may include a dedicated table for serious adverse events (SAEs). The analysis population and counting principle remain important: the table generally summarizes the number of subjects with at least one qualifying SAE in each SOC/PT category.

A subject with multiple serious events contributing to the same PT should not be counted multiple times in the standard subject-level summary.

Treatment Relatedness

Another common dimension is investigator-assessed relationship to study treatment. The table may report all TEAEs, related TEAEs, or events by a set of relatedness categories depending on the analysis specification.

For a binary relatedness summary, a subject is generally counted once in the PT if the subject has at least one qualifying event meeting the relatedness criterion. The exact algorithm for multiple events should follow the SAP.

Displaying Only Selected PTs

Not every table displays every PT. Common shells include all observed PTs, PTs above a prespecified frequency threshold, or selected medically important categories.

For a frequency threshold of \(c\%\), one possible rule is to display a PT if its incidence in at least one treatment group reaches the threshold:

Other rules are possible. For example, the SAP may define the threshold using the active-treatment group only, the pooled population, or the overall study population. The threshold must therefore be documented rather than inferred from the final output.

When a PT Is Rare

A rare PT may have a percentage such as 1.0% in one treatment group and 0.0% in another. It should not be discarded merely because its percentage is small if the table specification requires all observed events or all clinically important events to be shown.

This is especially important for safety review: a low-frequency event may be clinically meaningful even when it is not numerically prominent.

Common AE Table Columns

The exact columns depend on the table objective, but common summary dimensions include:

Example of a Final SOC/PT Table

Using the worked example above, suppose there are 10 subjects in each arm. A simplified final table could look like this:

The final table should normally follow the exact display convention specified for the study. For example, zero counts might be displayed as 0, 0.0%, or 0 (0.0%), depending on the shell.

Programming Logic

The programming task can be viewed as a sequence of transformations from the analysis-ready AE records to subject-level indicators and then to displayed counts and percentages.

Illustrative R Implementation

The following example uses generic variable names. They are illustrative and should be replaced with the actual variables in the analysis dataset.

# Example variables:
# USUBJID = subject identifier
# TRT01A  = treatment group
# TEAEFL  = treatment-emergent flag
# AESOC   = MedDRA SOC
# AEPT    = MedDRA PT

teae <- ae |>
  dplyr::filter(TEAEFL == "Y")

# Subject-level PT counts
pt_counts <- teae |>
  dplyr::distinct(USUBJID, TRT01A, AESOC, AEPT) |>
  dplyr::count(TRT01A, AESOC, AEPT, name = "n")

# Subject-level SOC counts
soc_counts <- teae |>
  dplyr::distinct(USUBJID, TRT01A, AESOC) |>
  dplyr::count(TRT01A, AESOC, name = "n")

# Overall TEAE count
overall <- teae |>
  dplyr::distinct(USUBJID, TRT01A) |>
  dplyr::count(TRT01A, name = "n")

The critical operation is distinct(). It changes the unit from event records to unique subject/category combinations before the count is performed.

Illustrative SAS Implementation

A similar approach can be implemented in SAS by sorting and removing duplicate subject/category combinations before counting them.

/* Illustrative variable names only */
data teae;
  set ae;
  where TEAEFL = "Y";
run;

proc sort data=teae out=pt_subjects nodupkey;
  by TRT01A USUBJID AESOC AEPT;
run;

proc freq data=pt_subjects;
  tables TRT01A*AESOC*AEPT / norow nocol nopercent;
run;

proc sort data=teae out=soc_subjects nodupkey;
  by TRT01A USUBJID AESOC;
run;

proc freq data=soc_subjects;
  tables TRT01A*AESOC / norow nocol nopercent;
run;

In production programming, the final output usually requires additional steps for denominators, formatting, ordering, zero cells, threshold rules, and shell assembly. The important statistical principle remains the same: count subjects at the requested category level.

ADaM and Analysis Dataset Considerations

The AE analysis dataset should provide the variables needed to reproduce the analysis definition. Depending on the study, these may include subject identifier, treatment variables, event dates, treatment-emergence indicators, MedDRA SOC/PT variables, severity, seriousness, relatedness, and other analysis flags.

The exact variable names depend on the sponsor's ADaM implementation and study specifications. A tutorial example should therefore be treated as conceptual rather than as a universal variable naming standard.

MedDRA Version Control

MedDRA is versioned. The terminology version used for coding and analysis should be documented and controlled throughout the reporting process.

Changing the terminology version can change terminology assignments, hierarchical placement, or available coding concepts. Therefore, production and QC datasets must not silently mix terminology versions.

Quality Control Checks

A strong QC process tests both the statistical derivation and the presentation of the table.

Independent Reconciliation

One of the strongest QC approaches is to derive key counts independently. For example, a primary programmer can generate the production table while a QC programmer independently creates subject-level SOC/PT counts and compares the results.

For a table cell, the reconciliation target is the subject set itself, not just the final number. If the production program reports \(n=12\), the QC process should be capable of identifying the 12 subjects that generated the count.

Common Mistakes

1. Counting AE Records Instead of Subjects

This is the classic error. A subject with five headache records must not become five subjects in a standard incidence table.

2. Summing PTs to Obtain an SOC Percentage

A subject can experience multiple PTs in one SOC, so PT counts are not mutually exclusive. Their percentages should not be summed.

3. Summing SOCs to Obtain Overall Incidence

Subjects can experience events across several SOCs. The overall incidence must be calculated from the union of subjects with at least one qualifying event.

4. Confusing Severity With Seriousness

A severe event is not automatically a serious adverse event. These are separate concepts and should be analyzed using their respective definitions.

5. Using the Wrong Denominator

The denominator must match the analysis population specified for the table. Using randomized subjects when the table calls for safety subjects can produce incorrect percentages even if the numerators are correct.

6. Letting the Code Decide the Analysis Rule

Rules such as treatment emergence, maximum severity, relatedness, and display thresholds should be specified before programming. Code should implement the rule rather than define it implicitly.

7. Mixing MedDRA Versions

A terminology mismatch between production and QC can produce apparently mysterious discrepancies in SOC/PT assignments. The terminology version should be explicitly controlled.

A Practical SOC/PT Reporting Workflow

What Should Be Specified in the SAP?

The statistical analysis plan should provide enough detail that an independent programmer can reproduce the table without guessing.

• Safety analysis population
• Treatment-emergent adverse event definition
• MedDRA version
• SOC and PT display levels
• SOC ordering convention
• PT ordering convention
• Subject-level counting rule
• Handling of repeated events
• Severity classification and multiple-severity rule
• Serious adverse event definition and analysis rule
• Treatment-relatedness definition and analysis rule
• Frequency thresholds, if any
• Denominator definition
• Percentage rounding and display rules
• Handling of missing or partial data
• Footnotes and special population rules

Worked Example Summary

The logic of an SOC/PT incidence table can be summarized compactly:

Key Takeaway

A high-quality adverse event table is not simply a frequency report. It is a carefully specified subject-level incidence analysis built on a controlled safety population, a prespecified treatment-emergence rule, standardized MedDRA terminology, and explicit rules for repeated events and special safety categories.

The most important mental model is: start with qualifying event records, convert them to subject-level indicators for each SOC/PT category, calculate the correct denominators, and only then build the formatted table.

References

International Council for Harmonisation (ICH). MedDRA: Medical Dictionary for Regulatory Activities.

International Council for Harmonisation (ICH). E2A: Clinical Safety Data Management: Definitions and Standards for Expedited Reporting.

U.S. Food and Drug Administration. Guidance for Industry: E3 Structure and Content of Clinical Study Reports.

International Council for Harmonisation (ICH). E9 Statistical Principles for Clinical Trials.