📚 Part of the TILA-278 Regulatory Dossier — Reader's Guide. This article shows the live document; edits to the source appear here automatically.

---

Data Management Plan (TILA278-201)

Field	Value
Document ID	TMF-002
Version	1.0
Compound	TILA-278 (anti-TL1A antagonist / IL-22R agonist bispecific)
Standard	GCDMP / ICH E6(R3)
Confidentiality	Confidential

Trial Master File operational document for Study TILA278-201.

Change History

Version	Date	Author	Summary
1.0	2026-07-08	Clinical Operations	Initial issue

1. Introduction and Scope

1.1 Purpose

This Data Management Plan (DMP) defines the data management strategy, systems, processes, roles, and quality controls applied to Protocol TILA278-201, a Phase 2b, randomized, double-blind, placebo-controlled, parallel-group 12-week induction study of TILA-278 (a humanized IgG1 bispecific monoclonal antibody with anti-TL1A [TNFSF15] antagonist and IL-22 receptor agonist activities, administered subcutaneously) in subjects with moderate-to-severe ulcerative colitis (UC), sponsored by Virtual Biopharma Inc.

The DMP governs the full data lifecycle from electronic data capture (EDC) go-live through database lock (DBL) and delivery of CDISC-conformant submission datasets. It is a controlled document maintained in the Trial Master File (TMF) and is version-controlled; the version in force at DBL is the operative reference for this Clinical Study Report (CSR) and for Module 5 tabulation deliverables. This DMP is written to be consistent with ICH E6(R3) Good Clinical Practice, the Society for Clinical Data Management Good Clinical Data Management Practices (GCDMP), ICH E9 (statistical principles insofar as they constrain data structure), and applicable Sponsor and vendor standard operating procedures (SOPs).

1.2 Study data scope

The randomized population comprises 900 subjects allocated 1:1:1 to TILA-278 High (n=299), TILA-278 Low (n=300), and Placebo (n=301), drawn from 1,700 screened subjects, with randomization stratified by baseline modified Mayo severity and prior biologic exposure. Scheduled assessment visits occur at Weeks 0, 2, 4, 8, and 12. Data management scope encompasses eCRF (in-house captured) data, and the following externally sourced (vendor) data streams: central safety and chemistry/hematology laboratory data, anti-drug antibody (ADA)/immunogenicity data, pharmacokinetic (PK) concentration data, centrally read endoscopy (Mayo endoscopic subscore), and interactive response technology (IRT) randomization/drug-accountability data.

1.3 Roles and responsibilities

Function	Primary responsibility
Sponsor Clinical Data Management Lead	DMP ownership, oversight of CRO deliverables, DBL authorization
Lead Data Manager (CRO)	eCRF/DVP design, data review, query oversight, lock execution
Clinical Data Coordinators	Manual data review, listing review, query issuance/closure
Database Programmer	EDC build, edit-check programming, UAT, migration control
Clinical Data Standards Lead	CDASH/SDTM/Controlled Terminology governance, define.xml oversight
Medical Coder / Medical Coding Review Team (MCRT)	MedDRA and WHODrug coding and clinical adjudication of terms
Drug Safety / Pharmacovigilance (PV)	Safety database ownership, SAE reconciliation counterpart
Statistical Programming	SDTM/ADaM production, define.xml, reviewer's guides
Biostatistics	Analysis-dataset requirements, DBL readiness sign-off
External vendors (central lab, ADA, PK, endoscopy central-read, IRT)	Source data generation and transfer per data transfer specifications

Individuals fulfilling these roles and their training/qualification records are documented in the study team roster and delegation log filed in the TMF.

2. Data Management Systems and Infrastructure

2.1 EDC platform

Clinical data are captured in a validated, 21 CFR Part 11 / EU Annex 11-compliant web-based EDC system (Medidata Rave EDC, validated instance version (to be assigned)). Randomization and investigational-product accountability are managed in an integrated IRT/RTSM module, with treatment assignment held under blind and inaccessible to the study team.

The EDC and all supporting computerized systems used for GCP data (EDC, IRT, central lab LIMS transfer, coding tool, statistical computing environment) are subject to computer system validation (CSV) under a risk-based approach; validation summary reports, requirements traceability, and release authorizations are retained per vendor and Sponsor SOPs. Each system provides a secure, time-stamped, non-editable audit trail capturing the identity of the user, the prior and new value, and the reason for change for every data element after initial save; the audit trail is retained and available for inspection for the full retention period.

2.2 Access control and environments

Access is role-based, provisioned only after documented protocol/system training, and revoked promptly upon role change or study exit; the access log is reconciled periodically. Separate Build/UAT (validation) and Production environments are maintained. No production data are entered until the database has completed User Acceptance Testing (UAT) and is formally released ("go-live"). Configuration migrations after go-live are controlled through a documented change-control process with impact assessment, re-testing of affected edit checks, and re-migration verification.

3. CRF Design and Database Build

3.1 eCRF design principles

The electronic case report form (eCRF) is designed to collect only data required by the protocol and its statistical analysis plan (SAP) — the principle of collecting no data that will not be analyzed or reported. Field structures, variable naming, and codelists are aligned to CDISC CDASH to maximize downstream SDTM traceability. Design conventions include controlled dropdowns/radio selections in preference to free text, unambiguous date formats (DD-MMM-YYYY) with partial-date handling, unit-anchored numeric fields with logical range prompts at point of entry, and standardized "not done / unknown" handling to distinguish missing from negative findings.

The annotated CRF (aCRF) mapping each field to its SDTM target is produced during build and maintained under version control; it forms part of the define-package deliverable (Section 9).

3.2 eCRF module inventory (principal forms)

Domain area	Principal eCRF modules
Enrollment / disposition	Informed consent, eligibility (I/E), randomization confirmation, visit disposition, study/treatment discontinuation
Efficacy	Modified Mayo score components — stool frequency, rectal bleeding, and centrally read endoscopic subscore; partial Mayo (stool frequency, rectal bleeding) captured at interim visits
Safety	Adverse events, serious adverse events, medical/surgical history, concomitant medications, vital signs, physical examination, injection-site reaction assessment
Investigational product	SC dosing administration, accountability (via IRT), missed-dose documentation
Laboratory / biomarker	Local safety labs (as applicable), central-lab requisition linkage, pregnancy testing
Specialized collections	PK sampling record, ADA sampling record, endoscopy procedure record

3.3 Database build and UAT

The database specification, edit-check specification, and eCRF completion guidelines are authored and approved prior to build. UAT is executed against pre-defined scripts covering navigation, field behavior, dynamic form logic, derivations, and every programmed edit check using positive and negative test cases; defects are tracked to closure and the database is released only after a signed UAT summary. The eCRF Completion Guidelines are distributed to sites and referenced during site training.

4. Data Validation (Edit Checks)

4.1 Data Validation Plan

A Data Validation Plan (DVP), with an accompanying Data Validation Specification (DVS), defines all programmed and manual checks that operationalize data cleaning. Programmed (system) edit checks fire at data entry and on subsequent save to flag out-of-range, inconsistent, missing, or protocol-deviating data in real time, minimizing query cycle time. The DVP is version-controlled; approximately (to be assigned) programmed checks were implemented for TILA278-201.

4.2 Edit-check categories

Check type	Description	Representative TILA278-201 examples
Univariate / range	Value within clinical/logical bounds and required-field presence	Vital signs plausibility; modified Mayo subscore ∈ {0,1,2,3}
Cross-form / consistency	Agreement across forms at a visit	AE with action "drug discontinued" consistent with disposition/IP records
Cross-visit / longitudinal	Consistency of a subject across time	Visit dates monotonic within the Wk 0/2/4/8/12 schedule; medical-history condition not re-entered as AE
Derivation / logic	Composite endpoint integrity	Modified Mayo total = sum of components; remission logic (total ≤2 with no subscore >1) verified against captured components
Protocol / eligibility	Adherence to I/E and stratification	Eligibility criteria consistent with enrollment; stratification factors (baseline severity, prior biologic exposure) recorded and non-contradictory
External-data linkage	Presence/keys for expected vendor records	Endoscopy central-read expected where endoscopic subscore contributes; PK/ADA sample records present for scheduled draws

4.3 Manual review and data review listings

Checks not amenable to programming are addressed through periodic manual review of data-review listings (e.g., AE narratives vs. concomitant medication and dosing logic, protocol-deviation patterns, dose-relationship of injection-site reactions, and endpoint-component plausibility). Listing review responsibilities, frequency, and sign-off are defined in the DVP. A Data Review Meeting (DRM) cadence brings together data management, medical monitoring, safety, and biostatistics to review emerging data quality and blinded aggregate patterns.

4.4 Query management

Discrepancies raise queries routed to the site for resolution within EDC; the full query lifecycle (open → answered → closed/re-queried) is audit-trailed. Aging queries are escalated per defined thresholds. Data cleanliness is tracked against key performance indicators reported at each DRM.

Data management metric	Target / status at final cleaning
Median query resolution time	≤ 5 business days
Open queries at soft lock	0 protocol-critical; residual non-critical adjudicated
eCRF pages entered / verified	100% for randomized subjects
Overdue queries at DBL	0

5. Medical Coding

5.1 Dictionaries and versions

Adverse events, medical history, and indication/procedure terms are coded with MedDRA (version (to be assigned)); concomitant and prior medications are coded with WHODrug Global (version (to be assigned)). Dictionary versions are frozen for the study; a single version of each dictionary is applied to the entire dataset at DBL. Any planned up-versioning follows an impact assessment and, if performed, full re-coding with review before lock.

5.2 Coding process and conventions

Verbatim terms are auto-encoded where a validated dictionary match exists; unmatched or ambiguous terms are manually coded by trained coders and clinically adjudicated by the Medical Coding Review Team. Coding conventions (handling of multiple concepts per verbatim, splitting rules, unspecified terms, and query-to-site thresholds for uninterpretable verbatims) are documented in a Coding Guidelines document filed in the TMF. AE coding supports the Preferred Term (PT) and System Organ Class (SOC) summaries used in the CSR — for example, the frequently reported terms nasopharyngitis, headache, worsening UC, anaemia, arthralgia, upper respiratory tract infection, injection-site reaction, and nausea — and coding integrity directly underpins the safety comparisons across the High/Low/Placebo arms (≥1 TEAE in 109/131/130 subjects, respectively). A coding freeze precedes DBL and is documented as a lock prerequisite.

6. External Data Management

6.1 Data transfer governance

Each external data stream is governed by a Data Transfer Specification (DTS) / Data Transfer Agreement (DTA) executed with the vendor before first transfer, specifying file format (SAS transport or delimited), variable-level layout and controlled terminology, transfer frequency, secure transfer method, blinding constraints, and reconciliation keys (subject ID, visit, sample/accession date-time). Test transfers are validated before production transfers begin. External data are not entered by sites into the EDC; instead they are loaded/reconciled against corresponding eCRF "sample collected" records.

6.2 External data streams

Stream	Source / handling	Reconciliation basis
Central safety & chemistry/hematology labs	Central laboratory LIMS transfer with reference ranges and standardized units	eCRF collection record vs. received result; missing/extra sample resolution; anaemia and other lab-derived AEs cross-checked
ADA / immunogenicity	Central bioanalytical lab using a tiered assay (screening → confirmatory → titer), with characterization to support impact analysis on PK, efficacy, and safety appropriate to an SC bispecific IgG1 mAb	Scheduled ADA draw records vs. received results; blinded result handling
Pharmacokinetics	Central bioanalytical lab; serum TILA-278 concentrations supporting target-mediated disposition and SC exposure characterization	PK sample record vs. received concentration; deviation flags for sampling-time windows
Endoscopy central read	Independent central reader(s) scoring the Mayo endoscopic subscore from de-identified video/images, blinded to treatment, visit sequence, and site read	Procedure record in eCRF vs. central-read result; the central-read value (not the local read) feeds the modified Mayo endpoint components
IRT / RTSM	Randomization allocation (held under blind) and IP accountability	Enrollment/dosing eCRF vs. IRT transactions

6.3 External data reconciliation

Reconciliation between eCRF expectations and vendor deliveries is performed at each transfer and formally at data-cleaning milestones: expected-versus-received sample accounting, key/date alignment, duplicate detection, and orphan-record resolution. Endoscopy central-read reconciliation is emphasized because the endoscopic subscore is a determinant of the primary remission endpoint (clinical remission: modified Mayo ≤2 with no subscore >1 at Week 12); any subject with a missing or unresolvable central read is escalated and its endpoint-derivation impact documented. External-data reconciliation completion is a documented DBL prerequisite.

7. SAE Reconciliation

Serious adverse event data are captured in the clinical (EDC) database and, independently, in the pharmacovigilance safety database. A documented SAE reconciliation process compares the two sources at a defined cadence (routinely, and mandatorily before DBL). Reconciliation is performed on matched key fields including subject identifier, event verbatim/Preferred Term, onset and resolution dates, seriousness criteria, outcome (including fatal outcome), causality/relationship to IP, and action taken. Discrepancies are logged, investigated jointly by Data Management and PV, and resolved with source correction in the appropriate system; the resolution trail is retained.

For TILA278-201, all serious adverse events were reconciled prior to lock: 7 subjects reported ≥1 SAE (High 3 / Low 0 / Placebo 4), including 3 deaths (High 2 / Low 0 / Placebo 1), all assessed as unrelated to study treatment. Fatal-outcome cases receive targeted reconciliation to confirm concordance of outcome, dates, and causality across the clinical and safety databases. A signed SAE reconciliation completion statement is filed as a DBL prerequisite.

8. Data Review and Database Lock

8.1 Progressive data cleaning

Data are reviewed on an ongoing basis against the DVP, with escalating cleaning intensity toward defined milestones. A blinded data review is conducted at soft lock to confirm that all data are entered, verified, cleaned, coded, reconciled, and that outstanding queries and protocol-deviation classifications are resolved, while the treatment code remains concealed.

8.2 Lock readiness criteria

DBL prerequisite	Verification
100% eCRF entry for randomized subjects (n=900)	EDC completeness report
All edit checks and manual listings reviewed	DVP sign-off
All queries closed (0 open)	Query status report
Medical coding complete and frozen (MedDRA/WHODrug)	Coding freeze memo
External data reconciled (labs, ADA, PK, endoscopy central read, IRT)	Reconciliation completion statements
SAE reconciliation complete	PV/DM signed statement
Protocol deviations finalized and classified	Deviation log sign-off
Analysis-population flags confirmed	Biostatistics concurrence

8.3 Lock execution and unblinding control

Upon satisfaction of all prerequisites, the Sponsor Clinical Data Management Lead, Biostatistics, and Medical Monitor authorize database lock; write access is removed and the locked state is recorded with a signed DBL statement. Treatment unblinding to the analysis team occurs only after DBL, in accordance with the unblinding SOP; the randomization schedule is released to statistical programming under controlled procedures. Any post-lock data change requires a documented rationale, defined-authority approval, a controlled unlock/relock with full audit trail, and an assessment of impact on analysis datasets and results.

9. CDISC Deliverables (SDTM / ADaM)

9.1 Standards and controlled terminology

Tabulation and analysis deliverables conform to CDISC: study data are transformed to SDTM (Implementation Guide version (to be assigned)) and analysis datasets to ADaM ((to be assigned)), using a frozen CDISC Controlled Terminology package ((to be assigned)) aligned to the coding dictionary versions in Section 5. Deliverables target the FDA/ICH eCTD Study Data Technical Conformance expectations and the CDISC define.xml v2.1 metadata standard.

9.2 SDTM deliverables

SDTM datasets are produced with traceability to the aCRF and cover the domains required by the design, including but not limited to: DM, SE, SV, DS, EX, CM, AE, MH, LB, VS, PE, EG (if applicable), PC (PK concentrations), IS/ADA immunogenicity, and the disease-specific findings supporting the modified Mayo components and centrally read endoscopic subscore, plus relevant SUPPQUAL and RELREC linkages. Accompanying deliverables comprise the define.xml, the annotated CRF, and the clinical Study Data Reviewer's Guide (cSDRG).

9.3 ADaM deliverables

ADaM datasets are built from SDTM with documented one-to-one/one-to-many traceability and include ADSL (subject-level, carrying the stratification factors, treatment assignment, and population flags), a BDS efficacy dataset supporting the primary remission endpoint and the ANCOVA of LS-mean change in modified Mayo at Week 12 (e.g., High −3.36 / Low −2.76 / Placebo −1.00; difference vs. placebo High −2.36 [95% CI −2.49, −2.23] and Low −1.77 [95% CI −1.90, −1.64], both p<0.0001), an occurrence dataset for adverse events (ADAE) supporting the safety summaries, and datasets for PK/ADA and other endpoints as specified in the SAP. Deliverables include the define.xml and the ADaM Reviewer's Guide (ADRG).

9.4 Conformance and traceability

All SDTM and ADaM datasets, define.xml, and reviewer's guides pass conformance validation (Pinnacle 21 / equivalent) with documented resolution or explanation of any findings in the reviewer's guides. End-to-end traceability from source eCRF field → SDTM → ADaM → CSR table is maintained, and the complete submission data package is archived in the TMF.

10. Quality, Retention, and Archival

Data quality is managed through the risk-based CSV, the DVP, coding and reconciliation controls, and DRM oversight described above, with metrics reported throughout conduct. On DBL and delivery, the DMP, DVP/DVS, aCRF, coding guidelines, data transfer specifications, reconciliation statements, UAT and CSV documentation, audit-trail exports, and the final CDISC package are archived in the TMF and retained for the regulatory retention period. Access to the archived, read-only database and its audit trail is preserved to support regulatory inspection and any future reanalysis.