Clinical Data Operational Readiness Framework

1. Why percent complete is not enough

Trackers usually report how many datasets, tables, listings and figures are written or validated. That count is useful for workload, but it is a weak signal of milestone readiness for three reasons.

• The remaining work is not average work. The last outputs are often the ones waiting on a decision, a data transfer or a specification change. Ten percent of the count can hold most of the schedule risk.
• Completion counts ignore dependencies the team does not control. An open analysis decision or a late external transfer can stop a lock even when every program is written.
• "Complete" is rarely defined by evidence. A program that runs is not the same as an output that has been independently checked, reviewed and accepted.

CDRN keeps completion counts visible but does not use them to decide readiness. Readiness is decided by open dependencies, their dates and the evidence that closes them. The illustrative scenario shows a study at 87 percent complete that is not ready.

2. Operational readiness versus deliverable completion

3. The seven dimensions

1. Role. The accountability lens: who decides, who implements, who reviews and who accepts. The same milestone produces different responsibilities for Statistical Programming, Biostatistics, Data Management, Regulatory, Clinical, Safety and Submission Operations.
2. Milestone. The event that changes the operating state, such as database lock, a dry run or interim, a health authority request, study startup, a late change, a submission or a safety update.
3. Target date. The date the milestone must be met. Every other date in the plan is set backward from it.
4. Deliverable. What is actually in scope: SDTM, ADaM and TLFs, integrated analyses, define.xml and reviewer guides, figures, or a response package.
5. Dependencies. Inputs, decisions, data transfers, access, reviews or handoffs that must happen first.
6. Risk. Failure modes that could affect quality, timing, traceability, interpretation or acceptance.
7. Evidence. The record that shows an item is closed, rather than merely worked on.

The output is an action plan: dated, owned actions with collaborators, linked risks and the evidence that will close each one.

4. Dependency relationships

A dependency is written so that someone can act on it: what is needed, from whom, by when, and what it unblocks. CDRN uses three relationship types.

• Finish-to-start. Work cannot start until the input exists (for example, ADaM derivation after the analysis decision).
• Input-to-review. A review cannot be meaningful until the reviewed item is stable (for example, independent QC after the specification is frozen).
• Shared resource. Two items compete for the same people or system window (for example, two studies needing the same QC programmers in the same week).

Every gating dependency gets a latest acceptable date (rule CDRN-R1): the target date minus the time needed for the work that must follow it. In the Navigator, generated steps are linked as a simple chain in which each step depends on the previous one (rule N5). The Workspace shows a soft gate: you can still record progress on a step whose predecessor is open, but the plan is flagged.

5. Risk classification

• Blocking. If unresolved by its latest acceptable date, the milestone cannot be met as planned. In the Navigator you log these as "blocker".
• Watch. Could affect the milestone but still has time, or has less than two days of buffer before its latest acceptable date. Logged as "watch".
• Clear. Resolved, or committed with at least two days of buffer.

The classification describes the effect on the milestone, not how hard the problem is technically.

6. Action prioritization

Open actions are ordered by these keys, in order:

1. Blocking items before watch items.
2. Earlier latest acceptable date first.
3. Items that unblock more downstream work first.
4. Items needing a decision from another function before items the team can do alone, because decisions take longer to obtain.

The Navigator applies the first two keys through its date ordering and critical flags; the last two are judgment calls for the planner.

7. Completion evidence

An item is closed only when its evidence exists (rule CDRN-R6). Typical evidence: a signed decision log entry, a data receipt and reconciliation record, an independent QC record, a validation report with findings dispositioned, a review sign-off, a package inventory, or a documented and approved exception. Evidence should be proportionate to the milestone and kept in sponsor-controlled systems, not on this website.

8. Escalation triggers

Escalate (rule CDRN-R5) when any of these is true:

• A blocking dependency has no committed resolution date before its latest acceptable date.
• Today is within two days of a blocking item's latest acceptable date and it is still open.
• Capacity demand exceeds available capacity for the remaining window (rule CDRN-R3).
• The Workspace signal is NOT READY (a critical action is blocked or overdue, or the target date has passed with open work).

An escalation states the item, the date it must be resolved by, two or three options with their consequences, a recommendation, and the decision needed by a named date. It goes to the person who can decide, not to everyone.

9. Rules and algorithms used by the application

All rules below are deterministic: the same inputs always give the same result. The parameters in them (step fractions, the two-day buffer, the capacity thresholds, the seven-day final window) are heuristics drawn from the author's practice. They have not been calibrated or validated.

CDRN decision rules

CDRN-R1 to R6 drive the illustrative scenario exactly as written above.

Navigator plan generation

Workspace readiness signal

Other tools

Readiness Intelligence maps a generalized signal to affected artifacts, functions, actions and closure evidence using fixed scenario tables; its impact level and score are illustrative weightings. The Scenario Simulator and Capacity Estimator cite a rule ID for every finding; their rules and the plan for testing them are in the validation protocol.

10. Worked examples

Database lock in two weeks

Programming is 87 percent complete; three ADaM decisions are open, a laboratory transfer is late and QC capacity is short. Applying R1 to R4 gives three Blocking items and a status of Not ready. Securing a decision date, a transfer date and one more QC programmer moves the status to Conditionally ready. Step through it interactively.

Health authority request with a 10-day response window

The request asks for a re-analysis in a subgroup. Dependencies: Biostatistics interpretation of the question (latest acceptable date: day 3, because programming, QC and review need 7 days), confirmation of the data cut to use (day 2), and Regulatory review of the response (day 9). If the interpretation is promised for day 4, R2 makes it Blocking, R5 triggers an escalation on day 1, and the escalation offers two options: answer the narrower reading of the question on time, or request an extension.

Late SAP amendment three weeks before database lock

A change to a derivation affects 14 outputs. Dependencies: a signed change statement (latest acceptable date: day -15), updated specifications (day -13) and re-QC capacity. Demand for re-QC is 30 hours against 24 available, a capacity ratio of 1.25, so R3 makes it Blocking. The options are more QC capacity or a risk-based regression scope agreed with Biostatistics and documented as an exception.

11. Human judgment and oversight

CDRN structures the conversation; people make the decisions. The planner sets durations, decides which items are gating, judges whether a commitment is credible and chooses between escalation options. The sponsor's procedures, the protocol and SAP, current agency guidance and accountable functional leads remain authoritative. No CDRN status should be used as the sole basis for locking a database or submitting data.

12. Limitations and assumptions

• The step fractions, buffer and thresholds are heuristics from one author's experience and have not been calibrated against outcomes.
• The Navigator's linear step chain is a simplification; real dependency networks branch.
• Role guidance outside Statistical Programming is editorial and awaits independent review by those functions.
• Calendar-day arithmetic is used; planners must account for working days, holidays and time zones themselves.
• The method assumes owners report status honestly and early. It cannot detect a risk nobody records.
• CDRN has not been tested for predictive accuracy. It does not predict whether a milestone will be met.

13. Validation status

CDRN Framework v1.0 is an author-developed methodology. No independent evaluation has been completed, no reviewer agreement has been measured and no effectiveness claim is made. A pre-specified evaluation with synthetic scenarios and independent practitioners is described in the validation protocol. Practitioners can volunteer as reviewers; critical and negative findings are welcome and will be reported.

14. Version and citation

This page documents CDRN Framework version 1.0, released with Clinical Data Readiness Navigator | v1.0. Material changes are recorded in the changelog with a new version number. Stable citation:

See Citation for the software citation and the machine-readable CITATION.cff.