Clinical research coordinator to data scientist: CRFs to models

Before day one: write down what you actually handled

List the artefacts from your site work. Most coordinators will recognise these:

• Visit schedule with windows (for example, Day 28 ± 3 days) and the deviation log when a visit fell outside.
• CRF pages you completed from source documents, and the edit checks that fired in the EDC system.
• Query logs — the data manager's questions, the date raised, the date you answered.
• Screening and enrolment logs, including screen failures and reasons.
• Withdrawal and lost-to-follow-up records.

Each of these becomes a table in your synthetic dataset. None of the real data leaves your employer, and your portfolio should say so plainly.

Days 1–30: rebuild the site's data in Python

Goal: describe a synthetic trial accurately and reproducibly.

Learn enough pandas to load tables, compute dates and group results. Your first exercise is one you could once do in your head: which visits were out of window, and how old are the open queries?

import pandas as pd

# Synthetic visit data for one site
visits = pd.DataFrame({
    "subject": ["S001","S001","S002","S002","S003","S003","S004"],
    "visit":   ["D28","D56","D28","D56","D28","D56","D28"],
    "target_day": [28, 56, 28, 56, 28, 56, 28],
    "actual_day": [27, 60, 29, 55, 35, None, 28],
})
WINDOW = 3
visits["deviation_days"] = visits["actual_day"] - visits["target_day"]
visits["status"] = "in window"
visits.loc[visits["deviation_days"].abs() > WINDOW, "status"] = "out of window"
visits.loc[visits["actual_day"].isna(), "status"] = "missed"
print(visits[["subject","visit","deviation_days","status"]])

# Synthetic query log
queries = pd.DataFrame({
    "query_id": [1, 2, 3, 4],
    "subject": ["S001","S002","S003","S003"],
    "raised": pd.to_datetime(["2026-08-01","2026-08-20","2026-09-02","2026-09-10"]),
    "closed": pd.to_datetime(["2026-08-04", None, None, "2026-09-12"]),
})
as_of = pd.Timestamp("2026-09-27")
open_q = queries[queries["closed"].isna()].copy()
open_q["age_days"] = (as_of - open_q["raised"]).dt.days
print(open_q[["query_id","subject","age_days"]])

Output:

  subject visit  deviation_days         status
0    S001   D28            -1.0      in window
1    S001   D56             4.0  out of window
2    S002   D28             1.0      in window
3    S002   D56            -1.0      in window
4    S003   D28             7.0  out of window
5    S003   D56             NaN         missed
6    S004   D28             0.0      in window
   query_id subject  age_days
1         2    S002        38
2         3    S003        25

Notice subject S003: out of window at Day 28, then missed Day 56, with an open query. As a coordinator you would already be worried about S003. That instinct is the hypothesis your model will later test.

Show at day 30: a notebook that generates a synthetic trial of around 200 subjects, with a README explaining each table and how it mirrors real site data.

Days 31–60: statistics you can defend

Goal: describe differences between groups with appropriate uncertainty, not just averages.

• Compare dropout rates between subjects with and without an out-of-window visit, with a confidence interval, not only the two percentages.
• Learn time-to-event thinking. Dropout is a time-to-event outcome: a subject still enrolled at the data cut is censored, not a success. Coordinators understand this intuitively; data science courses formalise it.
• Learn SQL well enough to join visits, queries and withdrawals — a data-management team will expect it.

Show at day 60: a short written analysis — two pages — answering "Are early window deviations associated with later withdrawal in this synthetic trial?", with the caveats you would expect a medical monitor to raise.

Days 61–90: a validated dropout-risk model

Goal: predict which enrolled subjects are at higher risk of withdrawing, using only information available at the time of prediction.

1. 1Features from the first 28 days only: window deviation, number of queries, days to answer queries, distance-to-site band, number of rescheduled visits.
2. 2Target: withdrawn or lost to follow-up by Day 84.
3. 3Split subjects into training and test sets before any tuning.
4. 4Compare against a simple rule, such as "flag anyone with an out-of-window visit".
5. 5Report precision at a realistic review capacity — if a site can phone ten subjects a week, how many of the top ten flagged would actually drop out?

The Data Science programme teaches the modelling and validation sequence this phase depends on, and the leakage warning in step 1 is the part coordinators most often get wrong: an end-of-study variable must never be a feature.

Show at day 90: the model, the baseline comparison, a plain-language explanation of its main drivers, and a limitations section.

The gap you are closing

• Python and SQL — you have used EDC systems, not queried databases directly.
• Statistics beyond summaries — confidence intervals, survival analysis basics, confounding.
• Model validation — held-out testing, baselines, leakage.
• Explaining to technical peers — a data team will ask how, not only what.

Clinical data roles as the first stepping stone

Titles like clinical data analyst, clinical data management associate with programming, real-world evidence analyst or health data scientist (junior) use your background most. Read postings carefully: some expect SAS or CDISC standards, which are worth learning later if clinical data is your long-term direction.

Your answer to "why leave clinical operations?"

As a coordinator I saw the same subjects get into trouble: a late visit, then a missed one, then an unanswered query, then withdrawal. I could often predict it, but the site had no systematic way to act early. I rebuilt that pattern in a synthetic trial, then built a model that flags at-risk subjects using only their first four weeks of data, and compared it with a simple out-of-window rule. I want to work where that kind of analysis shapes how trials and patient programmes are run.

For a related healthcare route with less modelling and more reporting, see medical coder to healthcare data analyst.