Chapter 1
A clinical trial is an experiment on people. Its output is not the new medicine itself but evidence about that medicine, and that evidence exists only as data. This chapter explains where clinical trial data comes from, which design decisions shape it before the first subject is enrolled, who is responsible for it along the way, and how the WIA-BIO-010 v1.0 standard and this book are organized around it.
Every clinical trial starts as a document, the protocol. The protocol states the question the trial will answer, who may take part, what each subject will receive, which measurements will be made at which visits, what the primary endpoint is and how it will be analysed. From that point on, the trial is a long chain of transformations. A nurse or investigator records an observation on a case report form (CRF), usually inside an electronic data capture (EDC) system. The data manager cleans it through edit checks and queries. The database is locked. Statistical programmers convert the raw records into standard tabulation datasets and then into analysis datasets. Statisticians produce tables, listings and figures. The sponsor writes a clinical study report and assembles a regulatory submission. A regulator reviews it and, if the evidence is convincing, approves the product.
Every link in that chain is a place where meaning can be lost. Three failure patterns recur so often that almost every data manager can tell a story about each of them.
None of these failures requires bad intent. They come from the absence of an agreed structure for what a trial record is, what it must contain and how it moves from one stage to the next. That is the gap a data standard fills. WIA-BIO-010 v1.0 describes its own scope in §1.2 as covering:
The list is broad, and it is worth being clear about what kind of standard this is. WIA-BIO-010 does not replace the established industry standards for clinical data. It leans on them: CDISC CDASH for how data is collected, CDISC SDTM and ADaM for how it is tabulated and analysed, MedDRA for coding medical terms, CTCAE for grading toxicity and ICH Good Clinical Practice as the ethical and quality frame. What it adds is a compact set of JSON data models, a TypeScript SDK that implements them, a command-line demonstration tool, a set of validation rules and error codes, and a statement of the statistical and safety conventions a conforming system should follow. Throughout this book we treat the external standards as authoritative for their own domains and use WIA-BIO-010 as the glue that ties them into one implementable system.
Drug development is conventionally divided into four phases. The phases are not a legal requirement to run exactly four trials; they are a way of organizing the questions that must be answered, roughly in the order in which it becomes safe and sensible to ask them. Spec §2 describes each phase, and the SDK encodes the same division in its TrialPhase type ('I' | 'II' | 'III' | 'IV').
The first trials in humans ask whether the product can be given safely and at what dose. The spec lists the key outputs as the maximum tolerated dose (MTD), pharmacokinetics (PK — what the body does to the drug) and pharmacodynamics (PD — what the drug does to the body). Primary assessments are dose-limiting toxicity (DLT), the frequency and severity of adverse events, and absorption, distribution, metabolism and excretion (ADME). Phase I studies of many drugs enrol healthy volunteers; for cytotoxic cancer therapies, where exposing healthy people would be unethical, subjects are patients who have exhausted other options. Dose escalation is the characteristic design problem of this phase, and section 1.4 walks through the most familiar rule.
Once a tolerable dose range is known, Phase II asks whether the product shows enough activity in patients with the target condition to justify a large confirmatory trial, and which dose should go forward. Endpoints are often shorter-term or surrogate measures — tumour response, a change in a biomarker, a symptom score — because the aim is to decide, not yet to prove. The spec names single-arm trials, randomized Phase II, Simon's two-stage design and adaptive designs as typical options, and it frames futility as a predictive question: how likely is a Phase III trial to succeed given what Phase II has shown? Section 1.5 returns to these designs.
Phase III is where the claim is proven. The spec's statistical requirements for this phase are the ones every regulator recognizes: a pre-specified primary endpoint, control of the type I error rate (α = 0.05, two-sided, in the usual case), adequate statistical power (at least 80 %), and an intention-to-treat primary analysis. The spec's "regulatory thresholds" add that efficacy is judged on the primary endpoint, safety through a benefit–risk assessment, and quality through GCP compliance. Everything in Chapter 2 — sample size, power, testing, multiplicity, interim analyses — exists to make a Phase III result credible.
Approval is based on a limited number of patients followed for a limited time. Rare adverse reactions, long-term effects and performance in populations excluded from the pivotal trials only become visible when the product is used widely. Phase IV covers post-marketing studies and surveillance, increasingly using real-world evidence (RWE) drawn from routine care data. The spec lists rare adverse event detection, long-term efficacy and comparative effectiveness as its main activities.
| Phase | Primary purpose | Typical population | Key endpoints and outputs | Statistical focus |
|---|---|---|---|---|
| I | Safety, tolerability, dose finding | Healthy volunteers, or patients when exposure of healthy people is unethical | DLT, MTD, PK/PD parameters, ADME, AE frequency | Dose-escalation rules; descriptive safety summaries |
| II | Efficacy signal, dose selection, further safety | Patients with the target condition | Response rate, biomarker or surrogate change, common AEs | Go/no-go decisions; futility; estimation of effect size for Phase III |
| III | Confirmation of efficacy and safety | Larger, more representative patient population, usually randomized against a control | Pre-specified primary endpoint, secondary endpoints, safety profile, quality of life | α control, power ≥ 80 %, ITT analysis, multiplicity, interim monitoring |
| IV | Long-term and real-world safety and effectiveness | Patients treated in routine practice after approval | Rare AEs, long-term outcomes, comparative effectiveness | Signal detection; observational methods and bias control |
The data a trial produces is shaped by design choices made long before the first visit. A data manager who does not understand these choices will build a database that cannot answer the protocol's question. The following terms appear in every protocol and in every later chapter of this book.
Randomization assigns subjects to treatment arms by a chance mechanism, so that known and unknown factors that affect the outcome are, on average, balanced between arms. It is what allows a difference in outcome to be attributed to the treatment. Simple randomization (a coin toss per subject) can produce noticeably unequal arm sizes in small trials, so most trials use permuted blocks: within each block of, say, four assignments, exactly two go to each arm. The block size is an illustration here; protocols usually conceal it or vary it so that site staff cannot predict the next assignment.
Stratification performs randomization separately within subgroups defined by strong prognostic factors — for example baseline HbA1c above or below a cut-off, or study site — so that each arm receives a similar mix. Stratification factors must be recorded exactly as used, because the primary analysis is normally adjusted for them. In WIA-BIO-010 the Randomization object carries the assignment date, the treatment, an optional randomizationNumber, an optional arm and a free-form stratification map of factor name to level.
Blinding (or masking) keeps the treatment assignment hidden from those who could be influenced by it. In an open-label trial everyone knows; in a single-blind trial the subject does not; in a double-blind trial neither the subject nor the investigators and assessors know. Blinding protects the measurement of outcomes, especially subjective ones such as pain scores. It is distinct from allocation concealment, which protects the moment of assignment: the person enrolling a subject must not know which arm the next subject will receive, or they could, consciously or not, steer particular patients towards it. Concealment is possible even in open-label trials; blinding is not always possible even when concealment is perfect.
A randomized trial compares the experimental treatment with a control: placebo, standard of care, an active comparator or a different dose. What is being tested determines how the hypotheses are written.
The intention-to-treat (ITT) principle analyses every randomized subject in the arm to which they were randomized, regardless of whether they took the treatment, switched or dropped out. It preserves the balance that randomization created and answers the practical question "what happens if we decide to give this treatment?". The per-protocol (PP) population keeps only subjects who followed the protocol closely enough, without major deviations. PP estimates are more exposed to bias, because the reasons for deviating are rarely random, but they matter as a sensitivity analysis — and in non-inferiority trials particularly, because sloppy conduct tends to make two arms look alike, which flatters a non-inferiority claim under ITT. Many protocols also define a full analysis set that approximates ITT with a few justified exclusions. For the data model the consequence is simple: population flags are derived, not collected, and the database must retain every randomized subject.
Spec §1.4 lists LOCF (last observation carried forward) among its core terms. LOCF fills a missing later value with the subject's last recorded value. It was once common because it is easy, but it assumes that nothing would have changed after dropout, it understates variability, and depending on the disease course it can bias results in either direction. Regulatory thinking has moved away from it: the ICH E9(R1) addendum on estimands (2019) asks sponsors to state in advance how intercurrent events such as treatment discontinuation or rescue medication are handled, and to choose missing-data methods — mixed models for repeated measures, multiple imputation and principled sensitivity analyses — that match that estimand. This book mentions LOCF because the spec does, not as a recommendation.
The README lists adaptive and basket/umbrella trials among the intended use cases. An adaptive design allows pre-planned modifications at interim analyses — dropping an arm, re-estimating the sample size, enriching a subgroup, or moving seamlessly from Phase II to Phase III — without undermining the type I error. A basket trial tests one therapy across several diseases that share a molecular feature. An umbrella trial tests several therapies within one disease, each matched to a biomarker-defined subgroup. A platform trial keeps a master protocol open and adds or removes arms over time. All of them place heavy demands on data systems: arm definitions change during the trial, and every analysis must know which version of the design was in force when each subject was randomized.
ClinicalTrial type records phase, status, primaryEndpoint, optional secondaryEndpoints, sampleSize and an optional protocolVersion; the Randomization type records the arm and stratification. There is no field for blinding, control type, hypothesis type (superiority or non-inferiority) or adaptive features. Implementers should keep these in the protocol metadata managed by the registration module (spec §8.1) and reference them by protocolVersion, rather than inventing ad hoc fields on subject records.
The dose-escalation problem is easy to state. Several pre-defined dose levels are available. Too low a dose will not work; too high a dose will cause unacceptable toxicity. Subjects must be treated in small groups, starting low, and each group's experience decides what happens to the next. Spec §2.1 gives the classic answer, the 3+3 design, as the statistical consideration for Phase I:
The spec's wording ("If ≥2/3 DLT → stop, previous dose is MTD") covers the first cohort explicitly; the six-subject case follows from the same logic and is stated in step 4 above. A common refinement, which the protocol should spell out, is that the level declared as MTD must itself have been tested in six subjects. If escalation stopped immediately after a level that had only three subjects with 0/3, three more are treated at that level before it is declared the MTD.
Consider an illustrative first-in-human study with four planned dose levels. The following sequence is invented for teaching; it is not data from any trial.
| Cohort | Dose level | Treated at level (cumulative) | DLTs at level (cumulative) | Decision |
|---|---|---|---|---|
| 1 | 1 | 3 | 0 | 0/3 → escalate to level 2 |
| 2 | 2 | 3 | 1 | 1/3 → expand level 2 to six |
| 3 | 2 | 6 | 1 | 1/6 → escalate to level 3 |
| 4 | 3 | 3 | 2 | 2/3 → stop; MTD = level 2 |
Twelve subjects were treated. Level 2 is declared the MTD, and because it was already expanded to six subjects no further cohort is needed. Level 4 was never reached. The decision rule is simple enough to express in a few lines of code, which is also a good way to make sure the protocol and the software agree:
type Decision = 'ESCALATE' | 'EXPAND' | 'STOP';
// 3+3 rule of WIA-BIO-010 spec §2.1, six-subject branch made explicit
function threePlusThree(treated: number, dlts: number): Decision {
if (treated === 3) {
if (dlts === 0) return 'ESCALATE';
if (dlts === 1) return 'EXPAND';
return 'STOP'; // 2 or 3 of 3
}
if (treated === 6) {
return dlts <= 1 ? 'ESCALATE' : 'STOP'; // 2 or more of 6 stops
}
throw new Error('the 3+3 rule evaluates cohorts of 3 or 6 only');
}
// Illustrative sequence from Table 1-2 (not real trial data)
const cohorts = [
{ level: 1, treated: 3, dlts: 0 },
{ level: 2, treated: 3, dlts: 1 },
{ level: 2, treated: 6, dlts: 1 },
{ level: 3, treated: 3, dlts: 2 },
];
for (const c of cohorts) {
console.log(`level ${c.level}: ${c.dlts}/${c.treated} -> ${threePlusThree(c.treated, c.dlts)}`);
}Expected output:
level 1: 0/3 -> ESCALATE
level 2: 1/3 -> EXPAND
level 2: 1/6 -> ESCALATE
level 3: 2/3 -> STOPThe 3+3 rule is transparent and needs no statistical software at the bedside, which explains its long popularity. Its weaknesses are equally well known. It is conservative: many subjects are treated at doses well below the eventual MTD, where benefit is unlikely. It treats few subjects at the MTD itself, so the toxicity rate at the recommended dose is estimated very imprecisely — with six subjects, one DLT is compatible with a wide range of true rates. It has no memory: each decision uses only the current level's cohort and ignores what was learned at other levels. And it does not target a stated toxicity rate. Model-based and model-assisted designs such as the continual reassessment method (CRM) and Bayesian optimal interval (BOIN) designs address these points and are increasingly used; a WIA-BIO-010 implementation should therefore store cohort-level dose, DLT counts and decision records generically, not hard-code the 3+3 rule as the only escalation logic.
For the data model, the practical lesson is that the DLT definition and the DLT assessment window are protocol-level concepts. Whether an adverse event counts as a DLT depends on its grade, its timing relative to the first dose and its relationship to the drug — all of which are captured in the adverse event record discussed in Chapter 4. The dose-escalation decision is a derived fact that must be traceable back to those records.
Phase II is about decisions under uncertainty: is there enough signal to justify the cost and risk of Phase III? The designs listed in spec §2.2 each answer that question in a different way.
All subjects receive the experimental treatment, and the observed response rate is compared with a historical benchmark: if the true response rate were no better than what existing therapy achieves, would we expect to see this many responders? Single-arm trials are small and fast, and in oncology they are common. Their weakness is the benchmark itself. Historical rates come from different patients, different times and different assessment practices, so a difference may reflect selection rather than treatment.
Randomizing against a control or between doses removes much of that bias at the price of a larger sample. Randomized Phase II trials are usually not powered to show a definitive difference; they are designed to select — the better of several doses or regimens — or to screen, using a relaxed α so that promising treatments are not discarded too early. The results are then re-tested in Phase III.
Simon's two-stage design is a single-arm design with an early stop for futility. The investigator specifies a response rate that would be uninteresting (p0), a rate that would be worth pursuing (p1), and the acceptable error rates. The design then yields four numbers: the first-stage sample size n1, a first-stage threshold r1, the total sample size n and a final threshold r. If r1 or fewer responses are seen among the first n1 subjects, the trial stops; otherwise enrolment continues to n, and the treatment is considered promising if more than r responses are observed in total. Two variants are common: the optimal design minimizes the expected sample size if the treatment is uninteresting, and the minimax design minimizes the maximum sample size. The thresholds must come from the design calculation in the protocol; they are not chosen after seeing data.
The spec describes Phase II futility as P(success in Phase III | Phase II data) < threshold → stop. This is a Bayesian predictive probability: given the data observed so far and a prior, how likely is it that a future trial, or the completion of this one, will reach its success criterion? If that probability falls below a pre-set threshold, continuing is unlikely to be worthwhile. The spec does not fix the threshold, and neither does this book at this point; Chapter 2 discusses the conventions used for interim futility decisions and Chapter 6 shows how stopping rules are documented. What matters for data design is that futility analyses are only as good as the timeliness and completeness of the data at the interim cut-off.
Clinical trial data passes through many hands, and each role carries distinct responsibilities that the data system must reflect in its access rights and audit trail. The international frame for these responsibilities is ICH Good Clinical Practice (GCP), guideline E6. The spec's reference list cites the E6(R2) revision; the ICH adopted E6(R3) in 2025, which puts more emphasis on risk-based quality management and on the fitness of computerized systems. Chapter 8 comes back to what that change means for implementers.
| Role | Core responsibility | Relationship to the data |
|---|---|---|
| Sponsor | Initiates, manages and finances the trial; holds overall responsibility for quality and for regulatory submissions | Owns the trial database, the statistical analysis and the submission; responsible for expedited safety reporting |
| Contract research organization (CRO) | Carries out sponsor duties that have been delegated to it by contract (monitoring, data management, biostatistics and others) | Often operates the EDC and produces SDTM/ADaM datasets; the sponsor remains accountable |
| Principal investigator (PI) and site team | Conducts the trial at a site, obtains informed consent, cares for subjects | Creates source documents and CRF entries; answers data queries; reports AEs and SAEs to the sponsor |
| IRB / ethics committee | Independently reviews and approves the protocol, consent documents and amendments; protects subjects' rights and safety | Receives safety information and amendments; its approvals are essential documents |
| Data safety monitoring board (DSMB) | Independent experts who review accumulating safety and, where planned, efficacy data during the trial | Sees unblinded interim data prepared by an independent statistician; recommends continuation, modification or stopping |
| Monitor (clinical research associate) | Checks on the sponsor's behalf that the trial follows the protocol and GCP | Verifies CRF entries against source documents; raises findings and queries |
| Regulator | Authorizes trials and approves products; inspects sponsors and sites | Receives applications, safety reports and final submissions; may inspect any record |
The regulators named in spec §1.2 are the U.S. Food and Drug Administration (FDA), the European Medicines Agency (EMA) and Japan's Pharmaceuticals and Medical Devices Agency (PMDA). In the European Union, trial authorization itself is handled by the national competent authorities of the member states under the Clinical Trials Regulation (EU) No 536/2014, through the Clinical Trials Information System (CTIS), which replaced the older EudraCT-based process. Chapter 6 covers the submission procedures of each region.
For readers working in Korea, the same roles map onto a domestic framework. The Ministry of Food and Drug Safety (MFDS, 식약처) approves clinical trial plans for investigational medicinal products, and the Korean Good Clinical Practice (KGCP) rules set out sponsor, investigator and IRB duties in line with ICH-GCP. Trials are commonly registered in the Clinical Research Information Service (CRIS) run by the Korea Disease Control and Prevention Agency, or in ClinicalTrials.gov when they are multinational. This book mentions the Korean system only as context; WIA-BIO-010 itself does not define country-specific rules, and local requirements must always be checked against the current regulations.
One consequence of this division of roles deserves emphasis. Registration identifiers such as ClinicalTrials.gov NCT numbers are assigned by the registry, not by the sponsor's software. The ClinicalTrial.id field in the SDK is documented as "e.g., NCT number", and Chapter 5 shows that the SDK's own registerTrial generates a placeholder in that format. A production system must store the registry-assigned number when it is issued and never present a self-generated one as a registration.
The standard is published as a small repository. Its parts differ in authority and maturity, and readers should know which is which before relying on any of them.
| Path | Contents | How this book treats it |
|---|---|---|
spec/WIA-BIO-010-v1.0.md | The normative specification, version 1.0.0: §1–§10 and Appendix A (worked calculations) | The primary source. Where it contains arithmetic or citation errors, the book says so and gives the corrected value |
README.md | Summary of the spec: phase table, formulas, SDK and CLI examples, WIA integration list, use cases | Secondary; some examples do not run as written (Chapter 5) |
api/typescript/src/types.ts, index.ts | The @wia/bio-010 SDK (version 1.0.0): data types, constants, the ClinicalTrialSDK class and standalone functions | The reference implementation of the data models; its heuristics and defects are documented in Chapters 5 and 8 |
cli/wia-bio-010.sh | A shell script with commands such as register-trial, report-ae, calc-sample-size and generate-submission | A demonstration printer only — not a calculation, conformance or submission tool |
simulator/ | A generic interactive page template | Contains no clinical-trial logic; not used as a trial or power simulator |
spec/PHASE-1…4-*.md | Four template files carrying a different standard ID and unrelated content | Not part of this standard; not cited |
The spec defines eight abbreviations. They are used throughout the book with the meanings below.
| Term | Meaning | Main chapters |
|---|---|---|
| ICF | Informed consent form: the document through which a subject agrees to take part after being informed of the trial's purpose, procedures, risks and rights | 6, 7 |
| CRF | Case report form: the protocol-defined record of each subject's data, today almost always electronic | 3, 7 |
| EDC | Electronic data capture: the computerized system in which CRF data is entered, validated and queried | 7 |
| AE | Adverse event: any untoward medical occurrence in a subject, whether or not related to the treatment | 4 |
| SAE | Serious adverse event: an AE meeting regulatory seriousness criteria such as death, a life-threatening event or hospitalization | 4, 6 |
| ITT | Intention-to-treat: analysis of all randomized subjects in their assigned arms | 2, 3 |
| PP | Per-protocol: analysis restricted to subjects without major protocol deviations | 2, 3 |
| LOCF | Last observation carried forward: a simple, now discouraged, imputation method for missing values | 1, 2 |
The book follows the logical order of the data rather than the order of the spec. Table 1-6 shows where each part of the specification is discussed.
| Spec section | Topic | Chapter |
|---|---|---|
| §1 | Purpose, scope, philosophy, terminology | 1 |
| §2 | Clinical trial phases, 3+3, Phase II designs | 1 (Phase III requirements also in 2) |
| §3.1–§3.3 | CDISC CDASH, SDTM, ADaM | 3 |
| §3.4 | EDC requirements and validation | 7 |
| §4 | Sample size, power, testing, intervals, multiplicity, interim analysis | 2 |
| §5.1–§5.4 | MedDRA, severity grading, causality, SAEs | 4 |
| §5.5 | Safety monitoring | 6 |
| §6 | FDA, EMA, PMDA and ICH-GCP requirements | 6 |
| §7.1–§7.2 | Trial registration and patient data models | 3 |
| §7.3 | Adverse event data model | 4 |
| §8.1, §8.3 | Required components, validation rules | 7, 8 |
| §8.2, §8.4 | API interface, error codes | 5, 8 |
| §9.1 | Patient protection and consent | 7 |
| §9.2–§9.3 | Safety monitoring cadence, stopping rules | 6 |
| §10 | References and cited standard versions | Throughout; version notes in 8 |
| Appendix A | Worked sample-size and relative-risk calculations | 2, 8 |
@wia/bio-010 SDK and the CLI, including their known defects.Before moving on, a reader responsible for a WIA-BIO-010 implementation should be able to confirm each of the following for their own project.
| # | Check | Why it matters |
|---|---|---|
| 1 | The trial's phase is recorded with the TrialPhase values I–IV, and the protocol version in force is referenced | Phase and protocol version determine which rules and analyses apply |
| 2 | Design attributes not covered by the v1.0 types (blinding, control type, superiority or non-inferiority, adaptive features) are held in protocol metadata | Analyses and monitoring depend on them; subject records should not improvise them |
| 3 | Stratification factors are stored exactly as used at randomization | The primary analysis is usually adjusted for them |
| 4 | Every randomized subject remains in the database, whatever their later status | ITT analysis requires it |
| 5 | For Phase I, cohort dose, DLT counts and escalation decisions are traceable to AE records | Escalation decisions must be reconstructable |
| 6 | Access rights and audit trails distinguish sponsor, CRO, site, monitor and DSMB roles | GCP assigns different responsibilities, and unblinded data must reach only those entitled to it |
| 7 | Registry identifiers are stored as issued by the registry, never generated locally | A self-generated "NCT" string is not a registration |
| 8 | The team knows which repository parts are normative and which are demonstrations | The CLI, the simulator page and the PHASE files must not be used as evidence of conformance |
ClinicalTrial type cannot express, and say where you would record them.