Study Lifecycle Monitor — Field Guide

1What this is — and what it is not

The Study Lifecycle Monitor (Study_Lifecycle_Monitor.html) is an at-a-glance operational console for a biostatistician watching a portfolio of early-phase studies at the program / operational level. It answers one practical question across all eight studies at once: which studies are slipping on the things biostatistics owns — milestones, data readiness, TLF production, and double-programming — and which one deserves my attention first this week?

Who it is for

The intended user is the biostatistician (or biostatistics lead) coordinating deliverables across multiple concurrent studies. It is built for triage and conversation: open it before a portfolio stand-up, scan the KPI strip and heatmap, click into the one or two studies that are red, and walk in already knowing where the operational pressure is. Every score it shows is computed from operational metadata only and is fully transparent — the exact formulas and thresholds are printed inside the dashboard itself.

What it is — and what it is not

This is the operational / program complement to the participant-safety dashboard, TRIALMON_Dashboard.html. The two cover different worlds and do not overlap:

Layout, top to bottom

The page reads as a single top-to-bottom triage flow. A header carries the Biostatistics Operations badge, the SIMULATED DEMO DATA badge, and a study-focus selector that drives every per-study panel. Below it:

1. KPI strip — six portfolio counters (active studies, at-risk, on-watch, open queries, average deliverables complete, next DB lock).
2. Portfolio health heatmap — a study × dimension RAG matrix (Timeline, Data, TLF, Resource), sorted worst-first; click any cell to drill in.
3. Operational early-warning signals — the ranked list of fired alerts, red-first (top nine shown).
4. Portfolio trend — an 8-week two-line trend (open queries vs. TLFs finalized) across all studies, each line on its own scale.
5. Selected-study panels — milestone track, data readiness, TLF production funnel, and the full-width deliverables pipeline, all driven by the focused study.
6. Study roster — a sortable table of all eight studies; click a row for the detail modal.

A per-study detail modal opens from either a heatmap cell or a roster row, and a footer repeats the honesty and governance disclaimer.

The portfolio is deliberately seeded so one study, CP-108, is forced into an at-risk Reporting state (DB lock past due, TLF production far behind, milestones overdue). That study becomes the initial focus when the page loads, so you land on a worked at-risk example rather than an empty calm — useful when demonstrating the console or learning its panels.

2Quick start — a 5-minute weekly review

This is the fastest defensible way to read Study_Lifecycle_Monitor.html once a week. The dashboard is decision-support, not autopilot: it ranks where your operational attention should go, but a human decides every action. Work the steps top-to-bottom — each one narrows the portfolio from "all 8 studies" down to "the one I act on first."

The 5-minute loop

What "done" looks like

After the loop you should have: the count of at-risk and on-watch studies, the worst study and its driving dimension, the specific signal(s) behind it, the validated source you'll query for authoritative numbers, and one written action with an owner. In the seeded demo, CP-108 is deliberately forced at risk (Reporting phase, DB lock 24 days overdue, ~10% of TLFs finalized, milestones past due), so it rises to the top row of the heatmap and is the default focus — a good worked example to practice the loop on.

3The data model & the SIMULATED banner

Everything you see in Study_Lifecycle_Monitor.html is generated from a single deterministic seed at page load. There is no server, no file read, and no network call. The portfolio is built once, scored once, and rendered. This section explains exactly what that synthetic portfolio contains, why it looks the way it does, and how each made-up field maps to a real source so you can read the dashboard correctly and brief others without overclaiming.

The SIMULATED banner — three places, one promise

The honesty disclosure is repeated in three locations so it cannot be missed on a screenshot or a printout:

• Header badge — an amber SIMULATED DEMO DATA pill next to the title (alongside the Biostatistics Operations badge).
• Footer (#foot) — the full disclaimer: self-contained, offline, SIMULATED DEMO DATA (seeded, reproducible) — not real study data; operational monitoring only (no PHI, no participant-level data, no reported clinical numbers; reported values always come from validated tools); transparent operational scoring — no predictive model and no experimental components.
• README — the same statement plus the "Deliberately excluded" list.

The per-study modal repeats a fourth, narrower version of the promise in its provenance note: "Operational fields only — no PHI, no participant-level or reported clinical values."

The seed and the PRNG

The portfolio is driven by a small splitmix-style 32-bit pseudo-random generator. One line creates it and three helpers wrap it:

Because the seed is fixed at 20260621 (the build date, 2026-06-21, read as an integer), every reload produces the identical portfolio: same study list, same scores, same signals, same heatmap. This is what "reproducible" means here — two people on two machines see exactly the same demo. TODAY is likewise frozen to 2026-06-21, so all the day-count math (days-to-DB-lock, overdue milestones) is stable rather than drifting with the wall clock.

How many studies, and how they are built

The portfolio is exactly 8 studies, generated in a loop (for i in 0..7: genStudy(i)) and given sequential ids CP-101 through CP-108 (101 + i). Each genStudy(i) call returns one canonical study object — the same shape consumed by every panel and by the go-live adapter. The KPI strip's "Active studies" counter is simply STUDIES.length, which is why it reads 8.

The four phases and phase-conditioned realism

Every study sits in one of four lifecycle phases:

The index i spreads studies roughly evenly across phases, with a 30% chance of nudging one phase later — so the eight studies cover the whole protocol-to-CSR span rather than clustering. The point of phase is that it conditions almost every other field, so the demo behaves like a real portfolio instead of uniform noise. The engine first draws a hidden lifecycle-progress fraction prog (0 to 1) from a phase-specific band, and then derives the visible metrics from it:

Milestones are likewise derived from prog: a base date of TODAY − (prog*240 + 30) days, offsets [0,18,35,150,185,215,250] for the seven keys (Protocol, SAP, FPFV, LPLV, DBL, TLFs, CSR), each marked done if its date has passed (with 92% reliability), wip if due within the next 14 days, risk if past due and not done, else todo. A study with prog > 0.9 force-completes its first five milestones. daysToDBL is then computed straight from the DBL milestone's date — which is what every "days to DB lock" readout and the DB-lock-pressure scoring term consume.

The deliberately at-risk study: CP-108

A demo of an operational monitor is useless if nothing is ever red. So after the eight studies are generated, the last one — CP-108 (STUDIES[7]) — is deliberately forced into a clearly at-risk state. This is a hard-coded override, not a draw of the RNG:

This profile is a textbook crisis: a study past its DB-lock date, deep into Reporting, with only 10% of TLFs finalized, double-programming behind, and two overdue milestones. It deliberately exercises the red end of several rules at once:

• Heatmap — CP-108's Timeline, TLF, and Resource cells go red, lifting its overall risk above all peers.
• Early-warning signals — it fires "TLF production behind" (10% finalized while in Reporting, red), "Double-programming lag" (42%, amber), and "Milestone overdue" (TLFs, CSR past due, red). Note it does not fire "DB lock at risk": that signal only triggers when daysToDBL is positive (an upcoming lock), and CP-108's lock date is already in the past (−24).
• KPI strip — it is the study counted in "At risk," turning that cell red.

Because the dashboard's initial focus (SEL) is set to the study with the highest overall score after sorting, the forcing also guarantees the app opens focused on CP-108 — every selected-study panel (milestone track, data readiness, TLF funnel, deliverables, modal) lands on the crisis study first, which is exactly what you want a triage tool to do.

What each synthetic field maps to in reality

The fiction is structured so that going live is a field-for-field swap — the synthetic generator and the real-data adapter return the identical study object shape. Each panel already documents its real source (the modal's "Where these numbers would come from" note states it explicitly). The mapping is:

All of these are read-only operational metadata — counts, percentages, dates, statuses. None of them is a participant-level record or a reportable clinical value, by design. The wiring section walks through loadPortfolio(), the async stub that replaces genStudy with reads from those five sources.

Using the data model in practice

4KPI strip

The KPI strip is the top row of Study_Lifecycle_Monitor.html — six counters that summarize the entire portfolio (all 8 studies, CP-101 through CP-108) in one glance before you read any panel below it. Each counter shows a large value over a small label. Four of the six are color-coded green/amber/red; two are neutral counts. Nothing here is study-specific — the strip ignores the focus selector and always aggregates across the whole portfolio. Read it left to right as a triage: how many studies, how many in trouble, how heavy is the data-cleaning load, how far along is the work, and what is the next hard deadline.

The six counters

How the risk bands behind two of the counters are defined

"At risk" and "On watch" both key off each study's overall risk score, so the same threshold ladder used everywhere on the dashboard governs these two counters.

Because the bands are mutually exclusive, a study is counted in exactly one of "At risk" or "On watch" (or neither, if green). The two counters never double-count the same study.

Working the strip

5Portfolio RAG heatmap & the scoring model

The #heat panel is the heart of Study_Lifecycle_Monitor.html: a study-by-dimension RAG matrix that compresses every study in the portfolio into four colored scores plus an overall. It is the first place to look each morning and the launch pad for every drill-in. This section explains exactly what each cell means, the arithmetic behind it, and — critically — what the colors do and do not entitle you to conclude.

How to read the matrix

Each row is one study (label = s.id, e.g. CP-104; hover for the full s.name). Rows are sorted by overall risk descending, so the study most in need of attention sits at the top. Each of the four columns is a scored dimension:

• Timeline — milestone slippage and pressure from the approaching database lock.
• Data — open-query burden, data-cleaning completeness, and source-data verification, amplified near DB lock.
• TLF — how far the table/listing/figure pipeline is from finalized, weighted by reporting proximity.
• Resource — independent double-programming progress and open programming discrepancies.

Every cell shows Math.round(s.sc[dim]) — an integer 0–100 — painted by the same RAG rule used everywhere in the dashboard:

Higher is worse: the score is a risk number, not a completion percentage. A green Timeline cell of 8 means little slippage; a red Data cell of 74 means the query/clean/SDV picture is poor with the lock bearing down. The inline collapsible note directly under the heatmap quotes these same thresholds (<33 green / 33–66 watch / >66 at risk) so the model is never hidden from the reader.

The four sub-scores, input by input

Every dimension is built from named operational inputs and then passed through clamp(...), which bounds the result to [0,100]. The exact formulas are reproduced from the dashboard's scoring object below. Two shared multipliers appear repeatedly:

Timeline

Inputs: count of milestones whose status is 'risk' (overdue and not done), plus dblPressure(s).

Each overdue milestone adds 22 points; the DB-lock proximity term contributes up to 45. So a single overdue milestone with a lock more than 60 days out scores 22 + .2×45 ≈ 31 (green), while two overdue milestones at/after the lock date scores 44 + 45 = 89 (red).

Data

Inputs: s.data.openQ, s.data.cleanPct, s.data.sdvPct, and dblPressure(s).

Open queries saturate their 45-point contribution at 120 open queries; incomplete cleaning and incomplete SDV add up to 30 and 25 respectively. The whole bracket is then scaled by lock pressure — the identical data picture reads materially worse in a study days from lock than one in early Conduct.

TLF

Inputs: s.tlf.finalized, s.tlf.planned, repPressure(s).

The fraction not yet finalized drives the raw score; reporting proximity scales it. A study with 10% of TLFs finalized in Reporting (repPressure = 1) scores 90 × 1.1 = 99 (red); the same 10% in Startup (repPressure = .1) scores 90 × 0.38 ≈ 34 (amber) — early studies aren't punished for not having finalized outputs yet.

Resource

Inputs: s.prog.dblProgPct (double-programmed %), s.prog.discrep (open discrepancies), repPressure(s).

Lagging independent (double) programming contributes up to 55 unconditionally; open discrepancies add up to 45 but only matter as reporting nears, via repPressure.

The overall score

The matrix sort key and the KPI/roster risk swatch all come from a single weighted blend of the four dimensions:

Timeline carries the most weight, Data and TLF nearly as much, Resource the least. The same green/amber/red thresholds apply to overall, which is what defines the portfolio counters: At risk = studies with overall > 66, On watch = 33 < overall ≤ 66.

Click-to-drill

The heatmap is the primary navigation surface. Clicking any cell does three things at once: it sets SEL to that study, opens the per-study modal (#modal) focused on the clicked dimension (the modal subline shows focus: dim), and re-renders the selected-study panels — Milestone track, Data readiness, TLF funnel, Deliverables pipeline — to that study. So a red Data cell is one click from the open-query sparkline and days-to-DB-lock line that explain it.

Where the inputs come from at go-live

In the demo every input is synthetic, but the data adapter maps each one to a read-only operational source: milestones and phase from CTMS; openQ, qtrend, cleanPct, sdvPct, daysToDBL from the EDC; the TLF funnel counts from the TLF program tracker; deliverables from the Protocol→CSR register; and dblProgPct/discrep from programming metadata. Only operational metadata crosses — no PHI, no participant-level data, no reported clinical values.

6Operational early-warning signals

The Operational early-warning signals panel (#signals) is the dashboard's triage list. It scans all eight studies in the portfolio, fires any signal whose trigger condition is met, then ranks the results red-first and shows the top nine. Each row carries a severity pip (red r or amber a), the study id that owns it (who), a short title (t), and a detail message (m). When nothing crosses threshold you see the empty state: "No operational signals above threshold."

There are exactly five signal types. They are deliberately distinct: a DB-lock signal is about the lock date colliding with open data, a query-backlog signal is about the trend regardless of lock date, the two TLF/programming signals are about output readiness near reporting, and the milestone signal is about a date that has simply passed. A single study can fire several at once — that is informative, not redundant.

The five signals at a glance

How the signals relate to the scores

Signals are discrete fired alerts; the heatmap dimension scores are continuous risk levels. They draw on overlapping inputs but answer different questions. A study can carry a high Timeline score (driven by overdue*22 + dblPressure*45) while only the milestone signal has actually fired; conversely a query trend can fire "Query backlog rising" before the Data score crosses 66. Use the signal list to know what to act on now and the heatmap to know which study is heaviest overall.

Working the panel: a triage pass

For participant-safety signals (DLT triggers, lab trajectories, AE patterns), this panel is silent by design — that is the role of the companion TRIALMON_Dashboard.html. The Study Lifecycle Monitor (Study_Lifecycle_Monitor.html) watches deliverables, data readiness, TLF production, and milestones only.

7Milestone track

The Milestone track panel (#ms, with the heading #msTitle) is the selected study's lifecycle timeline. It draws the seven standard milestones in left-to-right order as a row of colored dots, each labelled with its key and its date. The panel title shows the selected study id and its current phase (for example, CP-104 — Conduct). It is driven entirely by the currently selected study (SEL), which you change from the heatmap, the roster, or the header study-focus selector.

The seven milestones, in order

The sequence is fixed (the MS_KEYS list) and is the same for every study. Each step renders its key (m.k) and its date (m.d, formatted YYYY-MM-DD):

1. Protocol — protocol finalized/approved. The lifecycle's first gate.
2. SAP — Statistical Analysis Plan signed off.
3. FPFV — First Participant First Visit (enrollment opens).
4. LPLV — Last Participant Last Visit (enrollment/visits complete).
5. DBL — Database Lock. This is the pivot milestone: its date also drives daysToDBL, the data-readiness clock, and the Timeline dimension's lock pressure.
6. TLFs — Tables, Listings, and Figures finalized.
7. CSR — Clinical Study Report. The final lifecycle gate.

How each dot is colored (status)

Every milestone carries a status (m.s) that maps to a dot color class. Read the dots left to right; you should see green giving way to a single blue "you are here" marker, then panel-gray for work still ahead. A red dot anywhere is the thing to act on.

Reading slippage: on-track vs at-risk vs overdue

"On track" is the absence of red plus a clean left-to-right progression: a green run, exactly one blue wip marker at the current front, then gray todo dots. You read slippage from where the red appears and how far right the green has reached:

• A red dot early in the sequence (e.g. SAP or FPFV) means a foundational gate is overdue — everything downstream inherits that delay.
• A red dot at DBL is the most consequential: it means the lock date has passed unmet, which also drives daysToDBL ≤ 0 and pushes the Timeline dimension toward red.
• Red at TLFs and/or CSR means reporting deliverables are past due — pair this with the TLF production funnel and deliverables pipeline to see how far behind output really is.
• If a wip (blue) dot sits to the left of a green done dot, that is an out-of-order signal worth questioning with the study team.

How to use this panel

8Data readiness

The Data readiness panel (#data) summarizes the database-cleaning state of the selected study in four rows: a clean % bar, an SDV % bar, an open-query sparkline with a current count, and a one-line days-to-DB-lock status. Together these answer one operational question: is this database on track to lock clean and on time? Switch the selected study with the header focus select, a heatmap cell, or a roster row.

Clean % bar

Clean % (d.cleanPct) is the share of the database judged clean — entered, edit-checked, and free of open issues. It is shown as a filled bar whose width equals the percentage and whose color is inverted: the panel colors the bar by ragColor((1-cleanPct)*100), so the bar is the RAG color of how much is not clean.

Read the color, not just the length: a 60%-clean bar is amber (40% unclean), and only at roughly 67% clean and above does it turn green. The number printed to the right is the raw clean %.

SDV % bar

SDV % (d.sdvPct) is source-data-verification coverage — the share of data verified against source. Same bar idea, but with a stricter color rule: ragColor((1-sdvPct)*120). The ×120 multiplier (vs ×100 for clean) means SDV must be higher than clean % to reach the same color band.

Open-query sparkline and count

The Open queries row shows two things: an 8-week sparkline of d.qtrend and the current count d.openQ. By construction qtrend[7] equals the current openQ, so the rightmost point of the line is today; the line reads oldest (left) → newest (right), one point per week.

The count turns amber when openQ > 40 (otherwise muted). For interpreting the shape: a line trending down toward the right is a database closing out; a line trending up is a growing backlog. A rising backlog is also caught independently by the Query backlog rising early-warning signal, which fires when the net change over the last three weeks qtrend[7] - qtrend[4] > 10 (red if > 25).

Days to DB lock

The status line reports the gap between today and the DBL milestone (s.daysToDBL, derived from the DBL milestone date). It reads "N days to DB lock" when DBL is in the future, and otherwise "DB lock not scheduled" (Startup) or "DB lock reached" (date passed). It is colored amber only when 0 < daysToDBL < 21 — i.e. lock is within three weeks; otherwise it is muted.

How the four fields interact

None of these rows is decisive on its own — readiness is the combination of cleaning state and time pressure. The dashboard encodes exactly that interaction in the Data dimension score, which multiplies the cleaning gaps by proximity to lock (dblPressure):

Two readings of this formula:

• Same gaps, different timing. A given open-query backlog and unclean fraction count for far more when DBL is days away than when it is months away — the (0.5 + 0.6*dblPressure) factor roughly doubles the score as lock approaches. A messy database is tolerable early and alarming late.
• Worst case: low clean % close to DBL. High (1-cleanPct) and high (1-sdvPct) multiplied by a near-1 dblPressure drive the Data score toward red, and Data carries 0.28 weight in the overall risk score — so this single situation can push the whole study to At risk.

9TLF production funnel

The TLF production funnel panel (#funnel) shows, for the currently selected study, how its tables, listings, and figures move through production from planning to sign-off. It is a four-stage funnel of horizontal meter bars, each scaled against the number of Planned outputs so you can read attrition between stages at a glance. To populate it for a study, set the header study-focus <select> (#studySel), click a heatmap cell, or click a roster row — all three set SEL and re-render this panel.

The four stages

The funnel walks the standard output-production path. Each meter's width is 100 * value / planned, and the fill is a blue gradient (#2b6cb0 → #4ea8ff):

Reading a healthy vs. bottlenecked funnel

Because every bar is scaled to planned, a healthy study shows four bars stepping down gently — each stage slightly shorter than the one above it, with Finalized not far behind Programmed. A bottleneck appears as a cliff: one bar is much shorter than the bar immediately above it, marking the stage where work is piling up.

• Many Programmed but few QC-passed (Programmed bar long, QC passed bar abruptly short): a QC bottleneck. Production is outrunning independent QC capacity — outputs are written but not getting reconciled/verified.
• QC-passed but few Finalized (QC passed long, Finalized short): a sign-off bottleneck. Verified outputs are waiting on review/approval, not on programming.
• Planned but little Programmed (only the top bar is long): production has not really started — expected early in a study, a concern late in one.

How the funnel drives the TLF risk dimension and signals

The funnel's counts feed the TLF heatmap dimension. The score is weighted by reporting proximity, so the same finalized fraction is benign early and serious late:

Two early-warning signals fire directly off funnel-related counts, and only when the study is near reporting (repPressure(s) ≥ .6, i.e. phase is Reporting or DB Lock):

Worked reference: the forced at-risk study

The demo deliberately forces CP-108 into an at-risk reporting state, which makes its funnel the textbook QC/sign-off bottleneck. Its counts are programmed = 0.45 × planned, qcd = 0.22 × planned, finalized = 0.10 × planned, with dblProgPct = 42 and phase = Reporting. Read top-to-bottom, the bars fall 100 → 45 → 22 → 10: production already lags, QC roughly halves what was programmed, and almost nothing is signed off — while the study is in Reporting. Because finalized/planned = 0.10 < .35 with repPressure = 1, the "TLF production behind" signal fires red, and dblProgPct = 42 < 60 fires the amber "Double-programming lag" signal. This is the pattern to recognize: a steep cliff at the QC stage on a study that is out of runway.

Upstream production assets

The funnel is the monitoring view; the outputs themselves come from the standardized TLF program template libraries that supply the production code for each shell — the SAS TLF pseudocode/template library and the parallel R (pharmaverse) TLF template library. Those libraries are organized per design (parallel, crossover, single-sequence, SAD, MAD) and are the assets that move counts from Planned into Programmed; the dashboard simply tallies their progress through QC and sign-off via the TLF program tracker.

10Deliverables pipeline by phase

The Deliverables pipeline panel (#deliv) is the dashboard's program-management lens: for the selected study it shows how many deliverables are done versus total in each of four lifecycle phases. It is a scaled echo of the Protocol-to-CSR deliverables register, so reading it well means reading the shape of the whole study lifecycle, not just a single bar. This section also covers the two portfolio-level readouts that aggregate deliverables across all eight studies: the Avg deliverables complete KPI and the Portfolio trend, plus how to find the crunch points.

What the panel shows

The card is full-width and holds one bar per phase, in lifecycle order. The four phase keys (s.deliv) are fixed:

• Startup — Protocol, SAP, CRF/eCRF design, randomization spec, analysis-dataset specs and the early planning deliverables.
• Conduct — deliverables produced while the study is enrolling and running: data-management plan execution, interim/DSMB outputs, ongoing programming specs.
• Analysis — the analysis-stage deliverables: ADaM datasets, the bulk of the TLF program, derivations and define documentation.
• Reporting — the closeout deliverables: final TLFs, statistical report inputs and CSR contributions.

For each phase the bar is rendered as follows:

Note the color polarity: the RAG color is driven by the incomplete fraction. A phase that is mostly finished (high done/total) yields a small (1 − ratio)×90 value and reads green; a phase that is barely started reads red. The ×90 factor means a phase has to be almost untouched (roughly under 27% complete) before it tips red, and below about 63% complete before it goes amber — phases that are well underway stay green.

How to read it phase-by-phase

The synthetic generator deliberately lags later phases behind earlier ones: each phase's completion is pulled down by its position in the lifecycle (an increasing per-phase lag term plus a stage-weight divisor and small noise), so Startup tracks closest to the study's overall progress while Reporting trails furthest. The expected, healthy picture for a study still in its early-to-middle life is therefore a left-to-right downward staircase: Startup fullest, Reporting emptiest. That is normal and not by itself a problem.

Per-phase deliverable counts (register scale)

The four phases are sized from a fixed register so the demo mirrors the 136-item Protocol→CSR register at scale. Totals per phase are fixed:

The done count for each phase is min(total, round(total × clamp₀₁(prog / weight − index×0.15 + noise))), where prog is the study's overall lifecycle progress (0..1), index is the phase position (Startup 0 → Reporting 3), clamp₀₁ bounds the completion fraction to [0, 1], and noise = rf(−0.05, 0.05). The combination of the divisor and the increasing index×0.15 lag term is what pushes later phases down relative to prog. Because Analysis is the largest bucket (34) and sits mid-lifecycle, it is usually the phase that signals the analysis-readiness squeeze before DB lock — watch it climb as prog rises.

Reading overall portfolio progress

Two readouts roll deliverables up to the whole portfolio.

Avg deliverables complete (KPI strip, #kpis) is the headline number:

This averages each study's overall deliverable completion (summing done and total across all four phases first, then taking the ratio), then averages those eight study-level percentages. Because it pools all phases, a portfolio dominated by early-phase studies will read lower even when every individual study is on track — interpret it together with the phase mix in the roster, not as a standalone grade.

Portfolio trend (#trend) plots the cumulative TLFs finalized line (blue, #4ea8ff) alongside the open-queries line (amber, #e6b450) across 8 weeks. The deliverables register itself is not trended week-by-week; the finalized-TLF line is the closest proxy for reporting-deliverable velocity. The legend shows current values q[7] and f[7] (newest week).

Finding the crunch points

A crunch point is a study whose remaining deliverable load is concentrated in a phase that is due now. Use this workflow:

How this ties to scoring

The deliverables panel is descriptive — it is not a direct input to the four risk dimensions. The TLF and Resource dimensions are driven by the TLF program tracker and programming metadata (finalized/planned, double-programmed %, open discrepancies), not by the register counts. So the deliverables bars give you the program-management context behind a study's risk score without double-counting it. When a study scores red on Timeline or TLF, the deliverables pipeline tells you which lifecycle phase is carrying the unfinished work.

Where the numbers come from

In the demo every deliverable count is SIMULATED, generated deterministically from the seed rng(20260621) and reproducible run to run. At go-live the panel is fed read-only by the Protocol→CSR deliverables register via deliverablesRegister(s.id), returning {phase: {done, total}} for Startup / Conduct / Analysis / Reporting; only operational metadata crosses — no participant-level data.

For participant-safety signals — clinical and laboratory monitoring at the participant level — use the companion TRIALMON_Dashboard.html. This Study Lifecycle Monitor (Study_Lifecycle_Monitor.html) is the operational/program complement: it watches deliverables, data readiness, TLF production and milestones, not participant-level clinical signals.

11Study roster & the drill-down modal

The Study roster (#tbl) and the per-study detail modal (#modal / #modalBox) are the bottom of the funnel: the heatmap and signal panels tell you which study and which dimension deserves attention, the roster lets you triage all eight studies in one sortable table, and the modal gives you the full per-study picture before you act. This section covers how to sort and triage the roster, exactly what the modal shows, and the recommended drill-down path from a colored cell or fired signal to a defensible operational decision.

The roster table: columns and what each one tells you

The roster lists all eight studies (CP-101 through CP-108) with nine columns. It opens sorted by overall risk descending (sortKey='overall', sortDir=-1), so the most at-risk study sits at the top on load — in the demo that is the deliberately forced at-risk study CP-108.

Sorting and triage

Click any column header to sort by that column; clicking the same header again toggles the direction (if(sortKey===k) sortDir*=-1; else { sortKey=k; sortDir=-1; }). Use the columns as a triage lens rather than reading rows top-to-bottom:

• Risk (default) — start here. Reds first, ordered worst-to-best, gives you the portfolio's escalation queue in one glance.
• Open Q — sort descending to find the studies driving the portfolio query backlog; amber cells (>40) jump out.
• TLF final — sort ascending to surface reporting-phase studies whose output production is lagging.
• Phase — group Reporting and DB Lock studies together, since those are where TLF and double-programming pressure bite hardest.
• Lead — group by owner when you are preparing a per-lead status conversation.

Opening the modal: entry points

The same modal opens from two places, and the entry point changes what the header tells you:

• From a roster row — click any row. The modal opens on that study with no dimension focus.
• From a heatmap cell — click a cell. This sets SEL to that study, re-renders the selected-study panels (milestones, data readiness, TLF funnel, deliverables), and opens the modal with a focus dimension noted in the header subline (e.g. focus: Data), telling you which column's color sent you there.

You can also set the selected study from the #studySel dropdown in the header bar, which re-renders all selected-study panels but does not open the modal.

What the modal shows for a single study

The modal (#modalBox) has three parts: a header, an eight-tile key-value grid, and a provenance note.

Header. id — name on the top line; a subline reading design · phase · Lead owner, with · focus: dim appended if you arrived from a heatmap cell.

Eight KV tiles — the full operational snapshot in one view:

Provenance note ("Where these numbers would come from") is always open and maps each block to its real source: milestones → CTMS; enrollment, queries, clean, SDV → EDC; the TLF funnel → the TLF program tracker; deliverables → the Protocol→CSR register.

Close the modal with the × button or by clicking the backdrop.

Recommended drill-down workflow

12Portfolio trend panel

The Portfolio trend panel (#trend) is the only panel that shows direction of travel for the whole portfolio rather than a single snapshot. Where the KPI strip and heatmap tell you where you are right now, this panel tells you which way the portfolio is moving over the last 8 weeks. It plots two lines on a single SVG canvas: portfolio-wide open queries (amber) and cumulative TLFs finalized (blue). You read it to answer one question fast: is the operational load building or draining?

What the two lines are

• Open queries (amber, #e6b450) — for each week w, q[w] is the sum across all 8 studies of that study's weekly query level (s.data.qtrend[w]). This is a real back-cast series: each study carries an 8-week query trend ending at its current open-query count (qtrend[7] = openQ), and the panel sums them week-by-week. Down is good — the portfolio is closing more queries than it opens.
• TLFs finalized (blue, #4ea8ff) — f[w] is a cumulative count of finalized TLFs across studies. Up is good — output is being produced and signed off.

How to read direction and momentum

Two independent scales: each line is normalized to its own maximum within the canvas (viewBox 0 0 1000 150, pad 26). The lines are not on a shared y-axis, so do not compare their heights to each other — never read "the lines crossed" as meaningful. Read each line only against its own earlier points. Points are plotted left (oldest) to right (newest), one per week. The legend prints the two current values, q[7] and f[7].

Reading the four shapes

What a wrong-direction or flat trend should prompt

This panel does not name the culprit study — it is portfolio-summed. When the amber line rises or refuses to fall, treat it as a pointer into the rest of the dashboard:

1. Go to the signals panel (#signals). A rising portfolio query line almost always corresponds to one or more "Query backlog rising" signals, each tagged with a study id (who) and the net growth over the last 3 weeks. Red there means q[7]−q[4] > 25 for that study.
2. Open the heatmap Data cells. Sort is by overall risk; scan the Data column for amber/red. Click a cell to open the per-study modal focused on Data.
3. In the modal, read the open-query sparkline and days-to-DB-lock line. A backlog rising into a near DB lock is the "DB lock at risk" condition (daysToDBL>0 && <21 && openQ>15).
4. If the blue line is flat/low near reporting, check "TLF production behind" and "Double-programming lag" signals and the per-study TLF funnel.

13Wiring it to live data

Out of the box, Study_Lifecycle_Monitor.html is fully self-contained: it generates all eight studies (CP-101 through CP-108) from a seeded pseudo-random generator, rng(20260621), so every reviewer sees the identical green/amber/red spread. Every number on the screen is SIMULATED DEMO DATA. This section explains the single seam where you swap that synthetic generator for your real operational systems — the DATA ADAPTER — and documents exactly which read-only source feeds each panel and field.

The one seam: loadPortfolio()

The whole dashboard reads from one array, STUDIES. In demo mode that array is built by calling genStudy(i) eight times. The DATA ADAPTER comment block holds an async stub, loadPortfolio(), whose only job is to return that same array of study objects — same field names, same shape — but populated from your live systems instead of the generator. Go-live is a one-line swap:

Because every panel already reads the canonical study-object shape that genStudy returns, you do not touch any panel code. You only implement the four source readers and the merge function inside loadPortfolio().

Four read-only sources, one merge

The adapter pulls from four operational systems and merges their fields into the demo's field names. Each reader is keyed by study id so the dashboard stays organized per study:

• ctmsStudies() — CTMS: returns id, phase, the seven milestones (Protocol..CSR with dates and status), enrolled/target, and sites.
• edcMetrics(s.id) — EDC: returns openQ, qtrend[8], cleanPct, sdvPct, daysToDBL.
• tlfTrackerCounts(s.id) — TLF program tracker: returns planned, programmed, qcd, finalized.
• deliverablesRegister(s.id) — Protocol→CSR deliverables register: returns {phase:{done,total}} for Startup/Conduct/Analysis/Reporting.

A small merge helper, mapToModel(e, t, d), folds the EDC, TLF, and deliverables payloads onto the CTMS skeleton and produces the canonical study object the panels expect.

Which source feeds each panel

This is the authoritative mapping. Build your readers to deliver exactly these fields and every panel lights up correctly.

What must NOT cross the seam

The adapter carries operational metadata only. The fields above are counts, percentages, dates, and statuses — never the underlying clinical record.

Implementation steps

Sanity checks after wiring

• The KPI strip reconciles to your sources: Open queries (portfolio) equals the sum of each study's EDC openQ; Active studies equals your live study count.
• The TLF funnel never shows a later stage exceeding an earlier one — confirm finalized ≤ qcd ≤ programmed ≤ planned coming out of the tracker.
• The Timeline dimension responds to real milestone status: any milestone past its date and not done should surface a red dot on the milestone track and fire the "Milestone overdue" signal.
• daysToDBL derives from the live DBL milestone date, so the "DB lock at risk" signal and the Next-DB-lock KPI both move with CTMS.

14Governance, guardrails & the two-dashboard split

This dashboard (Study_Lifecycle_Monitor.html) is built around a small set of non-negotiable guardrails. They are not decoration: they decide what the tool is allowed to show, where its numbers may come from, who is allowed to act on them, and why it sits in its own lane rather than overlapping the participant-safety dashboard. Read this section before you put any output in front of a lead, a sponsor, or an inspector.

The five non-negotiables

1. Operations-only. The dashboard watches deliverables, data readiness, TLF production, milestones, and programming throughput. It never ingests PHI, never holds participant-level rows (no USUBJID/SUBJID records), and never displays reported or regulated clinical values.
2. Reported numbers come only from validated tools. Any number that lands in a CSR, a TLF, or a submission is produced and signed off in a validated environment (for example Phoenix WinNonlin for NCA/PK, Pinnacle 21 for conformance, the EDC/CTMS of record). This dashboard restates operational metadata about those deliverables — counts, percentages, dates — never the regulated results themselves.
3. Transparent scoring — no black box. Every risk score is a published arithmetic formula with stated thresholds. The exact dimension formulas and the RAG cut-points are printed inside the dashboard itself (the collapsible note under the heatmap) and in the README. There is no predictive model and no learned weighting to audit.
4. Humans decide. The tool ranks, flags, and routes attention. It does not approve a database lock, accept a query backlog, or sign off a TLF. Every signal is a prompt for a person to look, not an action.
5. Simulated demo data, clearly labeled. The shipped portfolio is seeded synthetic data, badged SIMULATED DEMO DATA in the header, footer, and README, and reproducible from the fixed seed. None of it is real study data.

What "operations-only" rules out

The boundary is concrete. The following never cross into this dashboard, even via the live data adapter:

• PHI or any directly or indirectly identifying participant information.
• Participant-level records of any kind (one row per participant, per visit, or per event).
• Reported clinical numbers — efficacy estimates, PK parameters, safety incidences, anything that would appear in a TLF or CSR result.
• Unblinded treatment information.

What does cross is read-only operational metadata: study phase, milestone dates and statuses, enrolled/target counts, site counts, open-query counts and their weekly trend, clean and SDV percentages, days to DB lock, TLF stage counts, deliverable done/total tallies, and double-programming percentage with open-discrepancy count. These are program-management facts about the conduct of the work, not clinical observations from it.

Transparent scoring: the formulas are on the wall

Because there is no model to trust, the scoring must be legible. Each study carries four dimension scores plus a weighted overall, all clamped to [0,100]. The collapsible note under the heatmap quotes them; they are reproduced here so you can reconcile any cell by hand.

Two consequences are worth internalizing as a user. First, the overall weighting leans on Timeline and Data (0.30 + 0.28 = 58% of the score), so a study can turn red on schedule and data pressure even with TLF and Resource quiet — that is intended for a program lens. Second, both the Data and TLF dimensions are amplified by phase pressure, so the same raw open-query count or finalized fraction scores higher as a study approaches DB lock or enters Reporting. When a score moves and the raw inputs did not, check whether the study changed phase or its days-to-DB-lock crossed a pressure band.

The deliberate two-dashboard split

This is a conscious separation of concerns, not a gap. There are two dashboards and they do not overlap:

The README states the relationship plainly: this Study Lifecycle Monitor is the operational/program complement to TRIALMON. If you are asking "is the work on track to be delivered, locked, and reported?" you are on the right dashboard. If you are asking "is a participant or the population showing a safety signal?" that question belongs to TRIALMON, and nothing here is designed or governed to answer it.

Deliberately excluded

The README lists what was kept out by design, and the footer repeats the core of it. This is standard, defensible operational monitoring only:

• No predictive model and no experimental engine of any kind.
• No research-work-in-progress or manuscript-specific methods — none of the author's personal-research constructs are present anywhere in this tool.
• No participant-level data, no PHI, no reported clinical numbers.

The footer states it for the record: self-contained, offline · SIMULATED DEMO DATA (seeded, reproducible) — not real study data. Operational monitoring only: no PHI, no participant-level data, no reported clinical numbers; reported values always come from validated tools. Transparent operational scoring — no predictive model and no experimental components.

Going live without breaking the guardrails

When the synthetic generator is replaced by real feeds, the governance posture must survive the swap. Follow this sequence.