Vitalis Therapeutics Inc. — Clinical data management for the VitaFlow (VTX-401) pivotal program: the four transformations between a site record and a submission dataset, EDC design, medical coding and why the dictionary version is a fact about the data, the reconciliations, and the ten-step database lock sequence.
1,340
Edit checks
18k
Queries raised
6 days
Median close
0
Open SAE discrepancies
Contents
1. Four Transformations
A reviewer at the agency analyzes a dataset. A nurse at a site wrote something in a clinical record. Between those two things sit four transformations, and the credibility of the entire clinical package depends on each one being traceable in both directions.
| Stage | What it is | Note |
|---|---|---|
| Source | The clinical record at the site | The original observation. Everything downstream is a copy or a derivation. |
| eCRF / EDC | Site staff transcribe into the electronic case report form | First transformation. Edit checks fire here, at the point of entry. |
| Clinical database | The consolidated, cleaned, queried dataset | Where queries are raised and resolved, and where external data is merged in. |
| SDTM | Study Data Tabulation Model — standardized observation data | A CDISC standard. The agency requires it so a reviewer can navigate any sponsor's data the same way. |
| ADaM | Analysis Data Model — analysis-ready derived datasets | One row per analysis record, with every derivation traceable back to SDTM. |
| Tables, listings, figures | The output the CSR and the submission present | Four transformations from what the nurse wrote down. Each one must be traceable in both directions. |
The submission does not contain the trial's data. It contains a derivation of a derivation of a
transcription of it.
That is not a criticism — it is unavoidable and it is why standards exist. What matters is that a reviewer can take any number in a table, walk it back through ADaM to SDTM to the clinical database to the eCRF, and land on a source record at a site. That path is what the pre-approval inspection tests when it picks a figure from Module 3 and asks to see where it came from.
That is not a criticism — it is unavoidable and it is why standards exist. What matters is that a reviewer can take any number in a table, walk it back through ADaM to SDTM to the clinical database to the eCRF, and land on a source record at a site. That path is what the pre-approval inspection tests when it picks a figure from Module 3 and asks to see where it came from.
The standardization is not for the sponsor's convenience. SDTM and ADaM exist so that a reviewer can navigate any sponsor's data the same way — and so the agency can re-run the analysis independently rather than taking the sponsor's word for the result.
2. The Database Itself
| Element | Standard | Why |
|---|---|---|
| Edit checks | Fire at entry: range, logic, cross-form consistency | A check at entry costs seconds. The same error found at lock costs a query cycle across 231 sites. |
| Required versus optional fields | Deliberate, not maximal | Every mandatory field is a field a site must complete before saving. Over-specifying generates protocol deviations rather than better data. |
| User roles and access | Role-based, reviewed periodically | 21 CFR Part 11 requirement. |
| Audit trail | Every change: who, what, when, and why | Unalterable, and reviewed rather than merely enabled. |
| Mid-study updates | Version-controlled, with migration of existing data | A protocol amendment usually means an eCRF change, and changing a live database with 1,684 participants in it is its own risk event. |
| Measure | Value |
|---|---|
| eCRF pages per participant | 112 |
| Programmed edit checks | 1,340 |
| Queries raised to date | 18,400 |
| Queries per participant | 10.9 |
| Median query close time | 6 days |
| Open queries | 412 |
1,340 edit checks is a design decision, not a quality metric, and more is not
better.
A check that fires at data entry costs a coordinator seconds. The same error found at database lock costs a query, a site response, a re-review and a re-lock decision — multiplied across 214 sites.
But an over-checked eCRF generates friction at every visit, slows entry, and pushes sites toward workarounds. The discipline is checking what would change an analysis, not everything that could conceivably be inconsistent — the same judgment the risk-based monitoring model applies to verification.
A check that fires at data entry costs a coordinator seconds. The same error found at database lock costs a query, a site response, a re-review and a re-lock decision — multiplied across 214 sites.
But an over-checked eCRF generates friction at every visit, slows entry, and pushes sites toward workarounds. The discipline is checking what would change an analysis, not everything that could conceivably be inconsistent — the same judgment the risk-based monitoring model applies to verification.
3. Medical Coding
Investigators record adverse events in their own words. Analysis requires those words mapped to a controlled hierarchy.
| Dictionary | Covers | Version | Note |
|---|---|---|---|
| MedDRA | Adverse events and medical history | v27.0 | Standardizes free text into a hierarchy. The dictionary version matters: the same verbatim term can map to a different preferred term in a later release, which changes what the safety tables say. |
| WHO Drug Global | Concomitant medications | March 2028 | Determines what counts as a prohibited concomitant medication. |
The dictionary version is a fact about the data, not about the software.
The same verbatim term — “stomach upset” — can map to one preferred term in MedDRA v26 and a different one in v27. Change the version and the safety tables change, without a single new event occurring.
That is why the version is stated in the plan, fixed for the analysis, and recorded in the submission. A safety database recoded mid-analysis to a newer dictionary has not been improved. It has been made non-comparable with everything already reported.
The same verbatim term — “stomach upset” — can map to one preferred term in MedDRA v26 and a different one in v27. Change the version and the safety tables change, without a single new event occurring.
That is why the version is stated in the plan, fixed for the analysis, and recorded in the submission. A safety database recoded mid-analysis to a newer dictionary has not been improved. It has been made non-comparable with everything already reported.
Coding is medically reviewed rather than clerically applied. Whether “abdominal discomfort” and “epigastric pain” roll up to the same preferred term determines whether the GI-attributed discontinuation rate at the heart of this program's differentiation thesis is one number or two.
4. Reconciliation
| Reconciliation | Between | Note |
|---|---|---|
| External laboratory data | Kestrel Laboratories → clinical database | Volumes are large and transfers are automated. Reconciled on participant, visit and sample identifiers. |
| Serious adverse events | Safety database ↔ clinical database | The reconciliation that matters most. The same events, entered by different people into different systems at different times, must agree before lock. |
| Randomization / IRT | Interactive response technology → clinical database | Treatment assignment and kit allocation. |
| Electronic patient-reported outcomes | ePRO vendor → clinical database | |
| Central adjudication | CV endpoint committee → clinical database | Adjudicated MACE for the CR-02 sub-study. |
Serious adverse event reconciliation is the one that finds real problems, and the reason is
structural.
An SAE exists in two systems. It enters the safety database through pharmacovigilance, on the 24-hour clock set out in the Safety Reporting Plan, entered by a safety scientist from the investigator's report. It enters the clinical database through the eCRF, entered by a site coordinator, often days later.
Same event. Different people, different systems, different moments. Before lock they must agree — on the event, its dates, its seriousness criterion, its outcome and its causality.
An SAE exists in two systems. It enters the safety database through pharmacovigilance, on the 24-hour clock set out in the Safety Reporting Plan, entered by a safety scientist from the investigator's report. It enters the clinical database through the eCRF, entered by a site coordinator, often days later.
Same event. Different people, different systems, different moments. Before lock they must agree — on the event, its dates, its seriousness criterion, its outcome and its causality.
This program has found 17 discrepancies across 214 serious adverse events, with 0 open. Most were date or outcome mismatches. Each one was a case where two records of the same event disagreed — and where, without reconciliation, the submission would have carried whichever version happened to be in the dataset the tables were built from.
A discrepancy count of zero would be the concerning result. Two systems populated
independently by different people will differ; finding none across two hundred cases suggests the
reconciliation is not being done at the level of detail that would reveal differences. This is the
same reasoning the Process Validation Plan applies to a
PPQ campaign with no recorded deviations.
5. Database Lock
Lock is the moment the dataset stops changing. It is irreversible by design, and the sequence that precedes it is not negotiable.
| Step | Detail | |
|---|---|---|
| 1 | All data entered | Last participant visit through to final eCRF completion |
| 2 | All queries resolved | No open queries of any severity |
| 3 | External data reconciled | Lab, IRT, ePRO, adjudication |
| 4 | SAE reconciliation complete | Safety and clinical databases agree, case by case |
| 5 | Medical coding complete and approved | MedDRA and WHO Drug, medically reviewed |
| 6 | Protocol deviations classified | Major versus minor, per pre-specified criteria |
| 7 | Blind data review meeting | Analysis populations assigned while still blinded — who is in the FAS, who is excluded from per-protocol, all decided without knowing treatment assignment |
| 8 | SAP signed | Per the Statistical Analysis Plan |
| 9 | Database lock authorized and executed | Write access removed |
| 10 | Unblinding | And only now |
Read steps 7 through 10 together — they are the integrity of the entire trial in four
lines.
The blind data review meeting assigns analysis populations while everyone is still blinded. Who is in the full analysis set, who is excluded from per-protocol, which deviations are major — all decided without anyone knowing which arm a participant was in.
Then the SAP is signed. Then the database is locked. Only then does anyone unblind.
Reverse any two of those and the trial's result becomes unfalsifiable. Assign populations after unblinding and you are choosing who counts based on how they did. Sign the analysis plan after lock and you are choosing the method that produced the answer you wanted.
The blind data review meeting assigns analysis populations while everyone is still blinded. Who is in the full analysis set, who is excluded from per-protocol, which deviations are major — all decided without anyone knowing which arm a participant was in.
Then the SAP is signed. Then the database is locked. Only then does anyone unblind.
Reverse any two of those and the trial's result becomes unfalsifiable. Assign populations after unblinding and you are choosing who counts based on how they did. Sign the analysis plan after lock and you are choosing the method that produced the answer you wanted.
The Statistical Analysis Plan records the same dependency from the statistical side. It appears in both documents because it is the point at which two functions hand off — and hand-offs are where sequence rules get lost.
6. What Goes to the Agency
| Deliverable | What it is |
|---|---|
| SDTM datasets | Standardized observation data, one domain per data type |
| ADaM datasets | Analysis-ready, with every derived variable documented |
| define.xml | Machine-readable metadata — what every variable is, how it was derived, and which SDTM source it came from. The map a reviewer navigates by. |
| Reviewer's guides | Study data and analysis data reviewer's guides: the narrative explaining anything a reviewer would otherwise have to ask about. |
| Analysis programs | On request, so the agency can reproduce the derivation |
define.xml is the deliverable programs under-resource and reviewers rely on most. It is not
documentation about the datasets; it is how the datasets are read. A reviewer opens it to
find out what a variable means and how it was derived, and a weak or incomplete define.xml
produces information requests that consume review time the program does not control.
This is the same asymmetry as the review log describes: the sponsor cannot make a review go faster, but it can make one go slower — and shipping data a reviewer cannot navigate is one of the reliable ways to do it.
This is the same asymmetry as the review log describes: the sponsor cannot make a review go faster, but it can make one go slower — and shipping data a reviewer cannot navigate is one of the reliable ways to do it.
7. What the Program Manager Owns
| Contribution | In this program |
|---|---|
| Protecting the lock sequence | Ten steps, and the temptation under schedule pressure is always to run two in parallel. Steps 7–10 in particular cannot overlap. |
| Holding SAE reconciliation as a milestone, not a task | 17 discrepancies found here. It gates lock, and it involves two functions who report to different people. |
| Resourcing define.xml and the reviewer's guides | Invisible until a reviewer cannot navigate the data, then expensive. |
| Treating a mid-study eCRF change as a risk event | Amending a live database holding 1,684 participants is not a configuration change. |
| Not confusing query volume with data quality | 18,400 queries is a function of how many checks were programmed, not of how good the data is. |
One of those metrics is misread more often than any other in status reporting. A falling query rate can
mean the data is cleaner or that fewer checks are firing. A rising one can mean sites are
struggling or that a new edit check was deployed.
The number that carries information is median query close time — currently 6 days. That measures whether sites are responsive and whether the queries make sense to them, which is what a program can actually act on.
The number that carries information is median query close time — currently 6 days. That measures whether sites are responsive and whether the queries make sense to them, which is what a program can actually act on.