US-first mapping with EU/UK wrappers: same truths, different labels

US (FDA) angle—event → evidence in minutes

US assessors often start with a CSR statement (“8 serious infections”) and drill to the listing that substantiates it. They expect literal population flags, stable filters, and derivations the reviewer can replay mentally. Listings should show analysis set, visit windows, dictionary versions, and imputation rules in titles and footnotes; define all abbreviations; and include provenance footers (program, run time, cut date, parameter file). A reviewer must never guess whether a subject is included or excluded.

EU/UK (EMA/MHRA) angle—capacity, capability, and clarity

EMA/MHRA look for the same line-of-sight but often probe alignment with registry narratives, estimand clarity, and accessibility (readable in grayscale, abbreviations expanded). They also examine governance: who approved changes to a listing model and how that change was communicated. Keep one truth and adjust labels and notes for local wrappers; the QC engine stays identical.

The core listings QC workflow: filters, columns, and logic under control

Filters that do not drift

Define filters as parameterized rules bound to a shared library. For example, “Safety Set = all randomized subjects receiving ≥1 dose” is a token used consistently across exposure, labs, and AE listings. Window rules—e.g., “baseline = last non-missing within [−7,0] days”—must be declared once and referenced everywhere. Store parameters (sets, windows, reference dates) in version control to prevent “magic numbers” in code.

Column models that can be read in one pass

Freeze column order and titles per listing family (AE, labs, conmeds, exposure, vitals). Include subject and visit identifiers early; place clinical signals (severity, seriousness, relationship, action taken, outcome) before free text. For lab listings, present analyte, units, reference ranges, baseline, change from baseline, worst grade, and flags; for ECI/AEI sets, include dictionary version and preferred term mapping. Use fixed significant figures by variable class and state rounding rules in footnotes.

Logic that anticipates the disputes

Write tie-breakers (“chronology → quality flag → earliest”) and censoring/partial-date handling into the listing footnotes, then mirror the same chain in program headers. Build small fixtures that prove behavior on edge cases (duplicates, partial dates, overlapping visits). When an inspector asks “why is this row here,” the answer should be copy-pasted from the footnote and spec—not invented on the spot.

1. Publish listing families with stable column models and permissible variants.
2. Parameterize filters and windows; no hard-coded dates or sets.
3. Declare and footnote tie-breakers, dictionary versions, and imputation rules.
4. Embed provenance footers (program path, run time, cut date, parameters).
5. Automate lint checks (missing units, illegal codes, empty columns, label drift).
6. File executed QC checklists and unit-test outputs with listings in the file system.
7. Rehearse retrieval drills and file stopwatch evidence.

Decision Matrix: choose the right listing design before it becomes a query

Document decisions where inspectors actually look

Maintain a “Listings Decision Log”: question → selected option → rationale → artifacts (SAP clause, spec snippet, unit test ID) → owner → effective date → effectiveness metric (e.g., query reduction). File under Sponsor Quality and cross-link from the listing spec and program header so the path from a row to a rule is obvious.

QC / Evidence Pack: the minimum, complete set reviewers expect

• Family-level listing specs (columns, order, types, units) with change summaries.
• Parameter files defining analysis sets, windows, and reference dates.
• Program headers with lineage tokens and algorithm/tie-breaker notes.
• Executed QC checklists (logic, filters, columns, labels, rounding, dictionary versions).
• Unit-test fixtures and golden outputs for known edges (partials, duplicates, windows).
• Provenance footers on every listing (program, timestamp, cut date, parameters).
• Define.xml pointers and reviewer guides (ADRG/SDRG) for traceability.
• Automated lint reports (missing units, illegal codes, label drift, blank columns).
• Issue tracker snapshot with root-cause tags feeding corrective actions.
• Two-click retrieval map from tiles → listing family → artifact locations in the file system.

Vendor oversight & privacy (US/EU/UK)

Qualify external programming teams to your listing standards; enforce least-privilege access; store interface logs and incident reports with listing artifacts. For subject-level listings in EU/UK, document minimization, residency, and transfer safeguards; prove masking with sample redactions and privacy review minutes.

Filters that survive re-cuts: parameterization, windows, and reference dates

Parameterize everything humans forget

Analysis sets, date cutoffs, visit windows, reference ranges, and dictionary versions all belong in parameter files under version control—not scattered constants inside macros. Run logs must print parameter values verbatim; listings must echo them in footers. If a window changes, the commit should touch the spec, the parameter file, and relevant unit tests—not a hidden line of code.

Windows and visit alignment

State allowable drift (“scheduled ±3 days”), nearest-visit rules, and how unscheduled assessments map. For time-to-event support listings (e.g., exposure, dosing), declare censoring and administrative lock rules so reviewers can match listing rows to time-to-event derivations.

Reference ranges and grading

For labs and vitals, lock unit conversions and grade tables. Include a column for normalized units and a graded flag tied to the same version used in analysis. The goal is for the listing to explain outliers in the same language as the table or figure it supports.

Column models you can read in one pass: AE, lab, conmed, exposure

AE listings

Columns: Subject, Visit/Day, Preferred Term, System Organ Class, Onset/Stop (ISO 8601), Severity, Seriousness, Relationship, Action Taken, Outcome, AESI/ECI flags, Dictionary version. Footnotes should define relationship categories, seriousness per regulation, and how missing stop dates are handled.

Lab listings

Columns: Subject, Visit/Day, Analyte (Test Code/Name), Value, Units, Normalized Units, Reference Range, Baseline, Change from Baseline, Worst Grade, Flags, Dictionary/version. Footnotes must declare unit conversions, reference source, and grading table version.

Concomitant medications

Columns: Subject, Drug Name (WHODrug mapping), Indication, Start/Stop, Dose/Unit/Route/Frequency, Ongoing, Dictionary version. Footnotes should cover partial dates and selection rules when multiple dosing records exist per visit.

Exposure/dosing

Columns: Subject, Arm, Planned vs Actual Dose, Number of Doses, Cum Dose, Dose Intensity, Deviations, Reasons. Footnotes should align definitions with CSR statements (e.g., “dose intensity ≥80%”).

Automation that prevents last-minute fixes: linting, diffs, and proofs

Visual and structural linting

Automate checks for empty columns, label mismatches, axis/scale hazards (if embedded figures exist), and illegal codes. Flag dictionary version drift and require an explicit change record with before/after counts for safety-critical families.

Program diffs with tolerances

For numeric fields, establish exact or tolerance-based diffs; for text fields, compare normalized forms (trimmed whitespace, standardized punctuation). Store diffs alongside listings and require QC sign-off when a diff exceeds threshold.

Stopwatch drills as living evidence

Quarterly, run a drill: pick ten listing facts and open the supporting spec, parameters, program, and source in under ten minutes. File the timestamps/screenshots. This trains teams to retrieve fast and proves the system works under pressure.

FAQs

What belongs in a listings QC checklist?

Scope and filters aligned to analysis sets; column model and order; units and rounding; dictionary versions; tie-breakers and imputation rules; window definitions; provenance footers; parameter echoes; lint results; executed unit tests; and change-control links. Each item must point to concrete artifacts (spec, parameters, run logs) that an inspector can open without a tour guide.

How do we keep filters from drifting between cuts?

Parameterize filters and windows in a version-controlled file; forbid hard-coded sets in macros. Require that run logs print parameter values and that listings footers echo them. A change to a set/window should update spec, parameters, and tests in one commit chain.

What’s the fastest way to prove a listing is correct during inspection?

Start from the listing footer (program path, timestamp, parameters), open the spec and parameter file, show the unit test fixture covering the row’s edge case, and—if needed—open the source record in SDTM. If you can do this in under a minute, you will avoid most follow-up queries.

Do we need different listing models for US vs EU/UK?

No. Keep one truth and adjust labels/notes for local wrappers (e.g., REC/HRA in the UK). The engine, parameters, and QC artifacts remain identical. This approach reduces drift and makes cross-region updates predictable.

How should free text be handled in PDF listings?

Use controlled wrapping, a truncation indicator with a footnote, and—when necessary—an annexed PDF for full narratives. Keep widths stable across cuts so reviewers can compare like with like. Document the rule in the spec and QC checklist.

What evidence convinces reviewers that QC is systemic, not heroic?

Versioned specs, parameter files, and unit tests; automated lint/diff outputs; stopwatch drill records; CAPA logs tied to recurring defects; and two-click retrieval maps. When these exist, inspectors see a process— not a rescue mission.