Chapter 6
How the records of Chapters 3 and 4 move through time: the order in which trial data is allowed to exist, the states a trial, a subject, a visit and a submission pass through, the monitoring rhythm that watches them, and the dossiers they finally feed.
The earlier chapters treated clinical trial data as shapes: a trial registration object, a subject with visits, an adverse event with its MedDRA code and seriousness flags. Shapes alone do not make a trial. A laboratory value is only admissible if the subject had consented before the blood was drawn; a randomization is only valid if the subject was eligible and the trial was open; a database can only be locked when every serious case has been processed. In other words, clinical data has a protocol in the networking sense as well as the clinical one: a set of ordering rules that decide which message may follow which.
WIA-BIO-010 v1.0 speaks to this layer in three places. §5.5 and §9 describe safety monitoring and stopping rules, §6 lists the regulatory dossiers for the United States, the European Union and Japan together with ICH-GCP essential documents, and the TypeScript types encode four status vocabularies: TrialStatus, the enrollment status of PatientEnrollment, the visit status of PatientVisit and the status of RegulatorySubmission. What v1.0 does not provide is the transition logic between those states. The reference SDK creates records in their first state (planned, enrolled, draft) and never moves them; of the ten error codes it declares, the only one it actually throws is B005 for statistical inputs. This chapter therefore does two jobs: it explains the lifecycle that the standard presupposes, and it proposes the transition tables and guards an implementer has to write, marking clearly which parts are the book's proposal rather than normative text.
A single-country, two-arm drug trial passes through the same sequence regardless of indication. Each step produces records that the next step depends on, and each step has a gate that should be checked by software rather than by memory.
The direction matters. Data may be corrected after it is entered, with an audit trail, but the order of events it describes cannot be rearranged: a consent date later than the first procedure is a finding, not a typo to be quietly edited. For that reason, the gates below compare dates carried in the records rather than the order in which the records happened to reach the database.
| Step | Record produced | WIA-BIO-010 carrier | Gate before the next step | Error code if the gate fails |
|---|---|---|---|---|
| 1 Registration | Trial record, protocol version | §7.1 object / ClinicalTrial | Ethics approval and authorization on file | B009 (proposed use) |
| 2 Consent | Signed ICF, version, date | consentDate only | Consent dated on or before first procedure | B006 |
| 3 Enrollment | Subject identifier, demographics | PatientEnrollment | Trial in recruiting; eligibility confirmed | B001 / B003 |
| 4 Randomization | Arm, strata, randomization number | Randomization | Subject enrolled, consent valid | B006 / B002 |
| 5 Visits | Visit data | PatientVisit, collectPatientData | Subject in an active state; visit day inside window | B002 / B008 |
| 6 AE capture | AE record, coding, grade, causality | AdverseEvent | Serious cases processed within their clocks | B004 |
| 7 Safety review | Review minutes, DSMB recommendation | Not modelled in v1.0 | Recommendation recorded before status change | — |
| 8 Database lock | Lock record, final coding versions | Not modelled in v1.0 | No open queries, no unreported serious cases | B004 / B003 |
| 9 Tabulation | SDTM, ADaM datasets | SDTMRecord | Traceability checks pass | B003 |
| 10 Submission | Dossier record | RegulatorySubmission | Required components present | B009 |
Two rows stand out. Steps 7 and 8, safety review and database lock, are events that every regulator will ask about, yet v1.0 has no object for either. An implementation needs at least a decision record (who reviewed what data, when, and what was recommended) and a lock record (timestamp, the dictionary versions frozen at lock, the person who authorized it). The error code column also shows that B007–B010, which the SDK added beyond the six codes in spec §8.4, are useful once an implementer attaches them to concrete gates. The table uses B009 "regulatory non-compliance" for missing approvals; that is the book's proposed use, since neither the spec nor the SDK says when B009 is raised.
A status field without transition rules is a free-text field with a restricted alphabet. Any code path can write completed over planned, and nothing in the record shows how the value got there. The remedy is conventional: define the allowed transitions explicitly, check the guard conditions at each one, and write every transition to the audit trail with the reason. The four vocabularies in types.ts are sufficient to do this, with a few interpretive choices that are spelled out below.
TrialStatus is 'planned' | 'recruiting' | 'active' | 'suspended' | 'completed' | 'terminated'. The spec never defines the difference between recruiting and active. The reading adopted here follows common registry practice (ClinicalTrials.gov, for instance, distinguishes "Recruiting" from "Active, not recruiting"): recruiting means subjects are being enrolled; active means enrollment has closed while treatment and follow-up continue. suspended is a temporary halt, whether imposed by the sponsor, an ethics committee or a regulator (a clinical hold, in US terms). completed means the trial ended as planned; terminated means it ended early for any reason. Both are terminal.
Enrollment status runs enrolled → randomized → active → completed, with withdrawn reachable from every non-terminal state. active is best read as "has started study treatment", which separates subjects who were randomized but never dosed; that distinction matters for defining the safety population. Note what the vocabulary lacks: there is no screened or screen-failed. Screening failures still need to be counted for the CONSORT-style flow of a trial report, so they should be kept in a separate screening log or in the SDTM DS (disposition) domain rather than forced into withdrawn, which would inflate the dropout figure used in Chapter 2's sample-size inflation.
Visit status is 'scheduled' | 'completed' | 'missed' | 'unscheduled'. A scheduled visit moves once, to completed or missed; an unscheduled visit is created directly in its final form (typically after an AE or an abnormal result). Submission status is draft → submitted → under-review → approved | rejected; in practice regulators also request additional information during review, which the vocabulary does not represent, so implementations tend to keep the correspondence log outside this field.
suspended can return to the state it came from. The transitions are the book's reading of types.ts; v1.0 does not define them.| Transition | Guard condition | Error on failure |
|---|---|---|
trial planned → recruiting | Ethics approval and regulatory authorization recorded; protocol version fixed | B009 |
trial recruiting → active | Enrollment closed (target reached or recruitment ended by decision) | B003 |
trial → suspended / back | Decision record with reason; resumption needs the same approvals as the original start | B009 |
trial active → completed | Last subject's last visit done; no unreported serious cases; database locked | B004 / B003 |
subject enrolled → randomized | Consent dated on or before randomization; eligibility confirmed; trial recruiting | B006 / B003 |
| any data write for a subject | Subject exists and is not in a state that forbids new data | B002 |
subject → withdrawn | Reason and date recorded; decision on use of data already collected documented | B003 |
visit scheduled → completed | Visit day inside window, or deviation raised | B008 (recorded, not blocking) |
submission draft → submitted | Required components for the agency and type present | B009 |
Two design choices hide in this table. First, B008 is recorded, not thrown: a visit outside its window is a real event that happened, and refusing to store it would lose data. The visit is saved and a deviation is raised against it. Second, withdrawal does not delete anything. A subject who withdraws consent for further participation has not necessarily withdrawn permission to use data already collected, and regulations generally require keeping it; what changes is that no new data may be written, which is exactly the B002 guard.
The following TypeScript encodes the trial and subject tables. It imports the error class and codes that the package exports through its types subpath; the function bodies are the book's code, not part of @wia/bio-010.
import { ClinicalTrialError, ClinicalTrialErrorCode as E } from '@wia/bio-010/types';
import type { TrialStatus } from '@wia/bio-010/types';
type EnrollmentStatus = 'enrolled' | 'randomized' | 'active' | 'withdrawn' | 'completed';
const TRIAL_NEXT: Record<TrialStatus, TrialStatus[]> = {
planned: ['recruiting', 'terminated'],
recruiting: ['active', 'suspended', 'terminated'],
active: ['suspended', 'completed', 'terminated'],
suspended: ['recruiting', 'active', 'terminated'],
completed: [],
terminated: [],
};
const SUBJECT_NEXT: Record<EnrollmentStatus, EnrollmentStatus[]> = {
enrolled: ['randomized', 'withdrawn'],
randomized: ['active', 'withdrawn'],
active: ['completed', 'withdrawn'],
withdrawn: [],
completed: [],
};
interface TrialContext {
ethicsApproval?: string; // ISO date of IRB/EC approval
regulatoryAuthorization?: string; // ISO date of authorization
openSeriousCasesUnreported: number;
}
export function moveTrial(from: TrialStatus, to: TrialStatus, ctx: TrialContext): TrialStatus {
if (!TRIAL_NEXT[from].includes(to)) {
throw new ClinicalTrialError(E.VALIDATION_FAILURE, `Illegal trial transition ${from} -> ${to}`);
}
if (to === 'recruiting' && (!ctx.ethicsApproval || !ctx.regulatoryAuthorization)) {
throw new ClinicalTrialError(E.REGULATORY_NONCOMPLIANCE,
'Recruitment needs ethics approval and regulatory authorization on file');
}
if (to === 'completed' && ctx.openSeriousCasesUnreported > 0) {
throw new ClinicalTrialError(E.SAE_NOT_REPORTED,
`${ctx.openSeriousCasesUnreported} serious case(s) still unreported`);
}
return to;
}
export function moveSubject(from: EnrollmentStatus, to: EnrollmentStatus,
s: { consentDate?: string; eventDate: string }): EnrollmentStatus {
if (!SUBJECT_NEXT[from].includes(to)) {
throw new ClinicalTrialError(E.PATIENT_NOT_ENROLLED, `Illegal subject transition ${from} -> ${to}`);
}
// ISO dates compare correctly as strings
if (to === 'randomized' && (!s.consentDate || s.consentDate > s.eventDate)) {
throw new ClinicalTrialError(E.MISSING_CONSENT, 'No valid consent dated on or before randomization');
}
return to;
}Five calls exercise the guards: opening recruitment with only an ethics approval, reopening a completed trial, completing a trial with one unreported serious case, randomizing a subject whose consent is dated the day after randomization, and the same subject with a correct consent date. The output is:
fail B009 Recruitment needs ethics approval and regulatory authorization on file
fail B003 Illegal trial transition completed -> active
fail B004 1 serious case(s) still unreported
fail B006 No valid consent dated on or before randomization
ok randomizedIn production the function would also append an audit entry (old value, new value, user, timestamp, reason) inside the same database transaction as the status update, so that a status can never change without a trace. Chapter 7 develops the audit record itself.
PatientVisit carries two optional integers: visitWindow, commented as "days from baseline", and visitDay, "actual visit day". The comment makes visitWindow look like a target day rather than a window, and the type has no field for the tolerance. A usable schedule needs three numbers per planned visit: the target study day and the permitted days before and after it. In SDTM these belong to the trial design: the TV (Trial Visits) domain describes planned visits and their start and end rules, and the SV (Subject Visits) domain records the visits that actually took place. Implementers are well advised to keep the schedule in a table of that shape and to treat visitWindow only as the target day.
The day count itself needs a convention, and the SDTM one is the safest to adopt everywhere: the reference start date (usually first dose or randomization, as defined in the protocol) is Day 1, the day before it is Day −1, and there is no Day 0. A visit "at Week 12" therefore has target Day 85, not 84, because 84 days have elapsed since Day 1. Off-by-one mistakes here are among the most common causes of spurious deviations.
For illustration, take a subject whose reference start date is 3 March 2025 and a protocol that allows ±7 days around the Week 12 visit. Target Day 85 falls on 26 May 2025, and the window runs from Day 78 to Day 92 (19 May to 2 June 2025). The function below computes the study day and classifies the visit.
interface ScheduleEntry { visitName: string; targetDay: number; before: number; after: number }
// SDTM-style study day: Day 1 = reference start date, no Day 0
function studyDay(refStart: string, date: string): number {
const diff = (Date.parse(date) - Date.parse(refStart)) / 86_400_000;
return diff >= 0 ? diff + 1 : diff;
}
function classifyVisit(e: ScheduleEntry, refStart: string, visitDate: string) {
const day = studyDay(refStart, visitDate);
const lo = e.targetDay - e.before, hi = e.targetDay + e.after;
const inWindow = day >= lo && day <= hi;
return { visitName: e.visitName, visitDay: day, window: `${lo}-${hi}`,
deviation: inWindow ? null : { code: 'B008', daysOutside: day < lo ? day - lo : day - hi } };
}
const week12: ScheduleEntry = { visitName: 'Week 12', targetDay: 85, before: 7, after: 7 };
for (const d of ['2025-05-26', '2025-05-30', '2025-06-06']) {
console.log(JSON.stringify(classifyVisit(week12, '2025-03-03', d)));
}{"visitName":"Week 12","visitDay":85,"window":"78-92","deviation":null}
{"visitName":"Week 12","visitDay":89,"window":"78-92","deviation":null}
{"visitName":"Week 12","visitDay":96,"window":"78-92","deviation":{"code":"B008","daysOutside":4}}The third visit is stored with visitDay: 96 and a deviation four days late. The date parsing relies on date-only ISO strings being read as UTC midnight, which is what JavaScript does; if timestamps with local times are ever passed in, they must be reduced to the local calendar date of the site first, or a visit late in the evening can shift by a day.
A protocol deviation is any departure from the approved protocol: a visit out of window, a missed assessment, a dose given outside the specified range, a subject enrolled who did not meet an eligibility criterion, a procedure done before consent. Spec §9.2 lists "protocol deviation tracking" under real-time monitoring, and the SDK reserves B008 PROTOCOL_DEVIATION for it, but neither defines a deviation record. A minimal one contains the subject, the visit or date, a category, a description, whether it is classified as important (likely to affect data reliability or subject safety), the date identified, and the corrective and preventive action. The distinction between important and other deviations is the one that ends up in the clinical study report, so it should be assigned by a person according to a written plan, not inferred from the category. A deviation detected automatically, like the late visit above, starts life as a candidate and is confirmed or dismissed in review.
Deviations also feed back into analysis. The per-protocol population of Chapter 2 is defined by excluding subjects with important deviations, so the classification has to be complete and frozen before database lock and before unblinding, otherwise the choice of who is excluded could be influenced by knowing who received which treatment.
Spec §9.2 defines four continuous checks: vital-sign alerts at more than 2 SD "from normal", laboratory alerts at CTCAE Grade 3 or higher, immediate SAE notification, and protocol deviation tracking. They sit at different levels of precision.
VITAL_SIGNS_RANGES gives normal ranges (for example, systolic BP 90–140 mmHg), not means and SDs, so the rule cannot be implemented from the package alone. An implementer must choose and document one definition. A defensible default is a deviation from the subject's own baseline, which accounts for patients who are hypertensive at entry, combined with absolute clinical thresholds set by the medical monitor.A real-time alert is a request for human attention, not a decision. Every alert therefore needs an owner, an acknowledgement time and a disposition (for example "clinically not significant", "AE recorded", "query raised"), and those three fields are what an inspector will sample.
| Cadence (spec §9.2) | Typical reviewer | Input data | Output record |
|---|---|---|---|
| Weekly — SAE review | Sponsor safety physician, medical monitor | New and updated serious cases, coding, causality, expectedness | Case assessments; expedited reports where required |
| Monthly — safety data review | Study team (usually blinded) | AE listings by SOC/PT, lab shifts, vital-sign trends, deviations | Review minutes, signals for follow-up |
| Quarterly — DSMB meeting | Independent DSMB | Unblinded or partially unblinded tables prepared by an independent statistician | Recommendation: continue, modify, pause or stop |
| Annually — regulatory safety report | Sponsor pharmacovigilance | Cumulative safety across the development programme | Annual report, e.g. the ICH E2F Development Safety Update Report (DSUR) or the US IND annual report |
The frequencies are the spec's defaults. A protocol may justify others: a small Phase I trial may review cohort by cohort, while a long outcomes trial with a slowly accruing event may have its DSMB meet twice a year. What must not vary is that the cadence is written down before the trial begins and that each review leaves a dated record.
Spec §5.5 adds three event-driven triggers for DSMB review: enrollment milestones at 25 %, 50 % and 75 %, pre-specified time points, and a breach of an SAE threshold. For the §7.1 example trial with 600 planned subjects, the milestones fall at the 150th, 300th and 450th subject enrolled. Two cautions apply. First, "enrolled" should be counted by the randomization date, not by record creation date, so late data entry does not delay a meeting. Second, if any of these reviews includes a formal efficacy comparison, it is an interim analysis in the sense of Chapter 2 and must be accounted for in the α spending; a safety-only review of unblinded data is still possible, but the charter must say which kind of review each trigger initiates.
Independence is the reason a DSMB exists. Its members do not run the trial, the unblinded reports are prepared by a statistician outside the study team, and the sponsor sees recommendations, not comparative data. A software implementation supports this by keeping the unblinded outputs in a separately permissioned area and logging every access.
Safety. Spec §9.3 states three conditions: stop if the probability that the experimental treatment is worse than control exceeds 0.95, if the SAE rate exceeds a pre-specified threshold, or if the benefit–risk balance is unfavourable. §5.5 expresses the first as "P(treatment safer than control | data) < 0.05". For a continuous posterior the two statements are the same condition seen from opposite sides; implementers should nevertheless choose one wording and one definition of "worse" (a higher rate of which events?) and write it in the DSMB charter.
Efficacy. Stopping early for benefit uses a group-sequential boundary. §5.5 names O'Brien–Fleming. As Chapter 2 showed, the spec's list of nominal levels for three looks is not internally consistent; for three equally spaced looks with overall two-sided α = 0.05, the O'Brien–Fleming nominal levels are about 0.0005, 0.014 and 0.045, and those are the figures to use.
Futility. §9.3 gives conditional power below 20 % and a Bayesian predictive probability of success below 10 %. These thresholds are common conventions, not regulatory requirements. Because futility stopping only ever reduces the chance of a positive result, it does not inflate type I error, but a binding futility rule (one the sponsor commits to follow) does affect the efficacy boundaries and must be declared as such in the statistical analysis plan.
To see what the 0.95 rule means in numbers, consider an illustrative interim look with 100 subjects per arm. Model each arm's SAE probability with a uniform Beta(1, 1) prior, so that after observing x events in 100 subjects the posterior is Beta(1 + x, 101 − x). The quantity the rule needs is P(pE > pC | data), which can be estimated by drawing from both posteriors and counting how often the experimental draw is larger. With four million draws per arm:
| SAEs experimental / control (n = 100 each) | P(experimental worse | data) | Rule at 0.95 |
|---|---|---|
| 10 / 5 | ≈ 0.90 | Not crossed |
| 12 / 5 | ≈ 0.96 | Crossed |
| 15 / 5 | ≈ 0.99 | Crossed |
Two lessons follow. The rule is sensitive near the threshold: two additional events move the result across it, which is why the charter should require that a crossing prompts review rather than automatic termination. And the answer depends on the prior and on which events are counted; a different prior or an event definition restricted to treatment-related SAEs would give different numbers. The prior, the event definition and the look schedule belong in the charter before any unblinded data is seen.
A DSMB recommends; the sponsor decides. The sponsor may accept, modify or, rarely and with documented justification, decline a recommendation. Ethics committees and regulators must be informed of a suspension or early termination, and in many jurisdictions within a fixed period; investigators must inform their subjects and arrange follow-up. In data terms each decision produces a chain of records: the DSMB recommendation (date, data cut-off, rule triggered, recommendation), the sponsor decision (who, when, rationale), the resulting trial status change (active → suspended or → terminated, with the decision record as its reason), and the notifications sent.
{
"decisionId": "DSMB-2025-03",
"trialId": "NCT12345678",
"dataCutoff": "2025-09-30",
"meetingDate": "2025-10-14",
"trigger": "enrollment-50-percent",
"rulesEvaluated": [
{ "rule": "safety-posterior", "threshold": 0.95, "value": 0.90, "crossed": false },
{ "rule": "futility-conditional-power", "threshold": 0.20, "value": 0.41, "crossed": false }
],
"recommendation": "continue-unchanged",
"sponsorDecision": { "decision": "accepted", "by": "sponsor-medical-lead", "date": "2025-10-16" },
"statusChange": null
}The record above is an illustrative extension, not a v1.0 object; all values in it are invented for the example. Its point is structural: a status change without a linked decision record, or a decision record whose rules and thresholds differ from those in the charter, is the kind of inconsistency that audits find first.
Spec §6 lists the dossiers for three regions and the ICH-GCP essential documents. The SDK models a submission as a RegulatorySubmission record with an agency (FDA, EMA, PMDA, NMPA, MHRA, OTHER), a format (CDISC, eCTD, NeeS, SEND), a type (IND, NDA, BLA, CTA, MAA, OTHER), the list of included datasets and a status. generateSubmission returns such a record in draft and builds nothing; the CLI's generate-submission command only prints text. Both are bookkeeping for a dossier that must be assembled by other tools. Note also that the format values mix levels: eCTD and NeeS are dossier formats, whereas CDISC SDTM/ADaM and SEND are dataset standards that travel inside an eCTD. A record typically needs both, which the single field cannot express.
An Investigational New Drug application is required before a new drug is given to humans in a US trial. Spec §6.1 lists its components in the order of 21 CFR 312.23: the cover sheet (Form FDA 1571), a table of contents, an introductory statement and general investigational plan, the investigator's brochure, the clinical protocol, chemistry, manufacturing and controls information, pharmacology and toxicology information, and previous human experience. Under 21 CFR 312.40 a trial may begin 30 days after FDA receives the IND unless FDA imposes a clinical hold earlier, which is the regulatory counterpart of the suspended status above. After the trials, a New Drug Application (or a Biologics License Application for biologics) presents the evidence for approval, and it is organized as a Common Technical Document.
| CTD module | Content | Where WIA-BIO-010 data ends up |
|---|---|---|
| Module 1 | Regional administrative information and prescribing information (not part of the harmonized CTD proper) | Forms, labelling; no trial datasets |
| Module 2 | CTD summaries: quality overall summary, nonclinical and clinical overviews and summaries | Clinical summaries of efficacy and safety draw on ADaM results |
| Module 3 | Quality (chemistry, manufacturing and controls) | None |
| Module 4 | Nonclinical study reports | SEND datasets for animal studies, outside this standard's scope |
| Module 5 | Clinical study reports and related information | Clinical study reports, SDTM and ADaM datasets with define.xml and reviewer guides |
Spec §6.2 describes the EU application as a Clinical Trial Application with a EudraCT number and an Investigational Medicinal Product Dossier (IMPD) covering quality, non-clinical and clinical information. That describes the regime under the former Clinical Trials Directive. Under Regulation (EU) No 536/2014, which now applies to EU trials, applications are submitted through the Clinical Trials Information System (CTIS), which replaced EudraCT for new trials. The application is assessed in two parts: Part I, the scientific and product-related aspects assessed jointly by the member states concerned, and Part II, national and ethical aspects such as informed consent and site suitability, assessed by each member state. The IMPD remains part of the Part I dossier. The trial record therefore needs a field for the EU trial number issued by CTIS; the old EudraCT number remains relevant only for trials that started under the previous rules.
For Japan, spec §6.3 lists a Clinical Trial Notification with basic, quality, non-clinical and clinical information and a risk management plan. The notification is filed with the regulatory authority, and PMDA carries out the review; the precise content should be confirmed against current PMDA guidance, because the spec's list is a summary rather than a regulatory checklist. The SDK's agency list also includes China's NMPA and the UK's MHRA, for which v1.0 gives no content at all. For Korean readers, the analogous step is approval of the clinical trial plan by the Ministry of Food and Drug Safety (식약처) under the Korean GCP rules; this chapter mentions it for orientation only, since v1.0 does not address it.
Essential documents are those that, individually and together, allow the conduct of a trial and the quality of its data to be evaluated. ICH E6(R2) listed them by stage in its section 8; the revision E6(R3), finalized in 2025, keeps the concept as essential records but applies it in a more risk-proportionate way. Spec §6.4 gives a short stage-based list, which the table below extends slightly and links to the records of this book. Together these documents make up the trial master file (TMF) at the sponsor and the investigator site file at each site.
| Trial stage | Essential documents (spec §6.4 and common practice) | Link to the data protocol |
|---|---|---|
| Before initiation | Protocol and amendments; investigator's brochure; ethics committee approval; regulatory authorization; approved ICF versions; randomization and code-break procedures | Gate for planned → recruiting; protocol and ICF versions referenced by every later record |
| During the trial | Source documents; completed CRFs; SAE reports; monitoring visit reports; deviation log; DSMB recommendations; audit certificates where audits occur | Visit data, AE records, decision records, audit trail |
| After completion | Final clinical study report; documentation of the statistical analysis; database lock record; treatment allocation and decoding documentation; notification of trial end | Lock record, SDTM/ADaM, RegulatorySubmission |
The practical consequence for software is that each item in the table needs a place to live and a date, and the status gates of section 6.2 should check them. A trial should not be able to leave planned while the ethics approval document is missing from the TMF index, and a submission should not leave draft while the lock record is absent.
| Check | Basis | What "done" looks like |
|---|---|---|
| Transition tables for trial, subject, visit and submission status | types.ts status unions | Every status change goes through one function with an allowed-transition table |
| Guards attached to error codes | Spec §8.4, SDK B001–B010 | B002, B004, B006, B008, B009 each raised at a named gate |
| Consent checked against dates, not arrival order | Spec §9.1, B006 | No randomization or data write before the consent date |
| Visit schedule with target day and window | visitWindow, visitDay, SDTM TV/SV | Study day computed with no Day 0; out-of-window visits stored and flagged |
| Deviation record with important/other classification | Spec §9.2, B008 | Classification complete before database lock |
| Documented definitions for real-time alerts | Spec §9.2 | The "2 SD" reference chosen and written in the safety plan |
| DSMB charter with triggers, rules, priors | Spec §5.5, §9.3 | Recommendation and sponsor decision records linked to status changes |
| Correct efficacy boundaries | Chapter 2, §5.5 | O'Brien–Fleming nominal levels ≈0.0005/0.014/0.045 for three looks |
| Submission record distinguishes dossier format from dataset standard | RegulatorySubmission | eCTD plus SDTM/ADaM recorded separately |
| EU trials recorded under CTIS | Regulation (EU) No 536/2014 | EU trial number field; EudraCT only for legacy trials |
Known gaps in the v1.0 reference material (lifecycle and submission)
planned, subjects as enrolled and submissions as draft and offers no way to move them.enrollPatient accepts any consentDate, including a missing or future one.recruiting and active are not defined in the spec; there is no screening or screen-failure state.visitWindow is documented as days from baseline and has no tolerance fields; the study-day convention is not stated.generateSubmission and the CLI's generate-submission produce no dossier; format mixes dossier formats and dataset standards.With the lifecycle in place, the pieces of the book can be put together into a working system. Chapter 7 does that: it takes the five components required by spec §8.1, wires the SDK into them, and adds what the reference code leaves out, namely persistence, the Part 11 audit trail, edit checks and access control.