Five-minute tour
This tour walks the entire clinical data lifecycle on the seeded demo study, from data entry with edit checks through query resolution, source data verification, Part 11 signature, snapshot publication, and self-service analytics, switching between the clinical roles that would perform each step in a real study.
Prerequisite: a running stack with the demo study seeded (Installation). The demo users are demo-admin, demo-dm (data manager), demo-inv (investigator), demo-coord (site coordinator), and demo-cra (monitor); they share the password printed by db:seed-demo.
1. See the study as a coordinator
Sign in as demo-coord. You land on the studies list. Users only see studies they’ve been granted a role on, and site-scoped roles only see their site’s subjects.
Open the study, then subjects. The subject matrix shows every subject × event × form and its workflow state at a glance, with each subject’s lifecycle status (screening, enrolled, completed, withdrawn) badged next to their key:
2. Correct data and watch the query close itself
DEMO-002’s Vital Signs form is in progress with 1 open query: the seeded systolic blood pressure (62 mmHg) failed the plausible-range edit check, which automatically raised a system query.
Enter a plausible value (say 118) and save, providing a reason for change: every modification to saved clinical data requires one, and the prior value remains visible in the audit trail forever. The edit check now passes, and the system query closes automatically.
Edit checks are JSONata expressions defined in the study build. They run client-side for instant feedback and server-side as the source of truth.
The demo study’s forms are dynamic, too. On the Demographics form, the pregnancy-test question only appears while the subject’s recorded sex allows it — record male and it vanishes; and on Vital Signs, the BMI field carries a computed badge: it fills itself in from height and weight, and the server recomputes and audits it on every save. Try changing a saved sex from female to male: the recorded pregnancy result is kept, flagged not collected, and a system query stays open until you clear it. See Data capture.
3. Verify as a monitor
Sign in as demo-cra and open the same form. Mark it verified. The workflow state machine (in progress → complete → verified → signed → locked) is enforced server-side, so transitions are only offered when the role and the current state allow them.
You can also review every query across the study from the queries dashboard:
4. Sign as the investigator
Sign in as demo-inv, open the completed form, and sign it. Part 11 signing requires re-entering your credentials at the moment of signature; the signature records name, date/time, and meaning, and is cryptographically bound (SHA-256) to the exact record versions signed. If the form is later reopened for editing, the signature is invalidated, visibly and irreversibly.
5. Review the audit trail
Any create, change, or state transition you just performed is in the study’s audit trail: who, when, what changed, and why, filterable and exportable to CSV. Append-only storage is enforced by database triggers, so history cannot be rewritten even by a buggy application path.
6. Publish a snapshot and analyze it
Sign in as demo-dm and open analytics. Click Publish snapshot: this pivots current study data into typed, analysis-ready tables (one per CDISC item group, plus subjects and queries) in the study’s DuckLake lake. Each snapshot is an immutable, point-in-time dataset: reruns against snapshot v1 return identical results forever.
Run SQL against the pinned snapshot:
Or switch to the R or Python tab: scripts execute server-side in sandboxed containers with lake_read() / lake_query() helpers (data.frames in R, pandas DataFrames in Python), and every execution is recorded with its code, logs, and results:
7. Export and archive
From the analytics page you can export any snapshot table as Dataset-JSON v1.1 (the FDA-accepted exchange format), CSV, or Parquet, or download the study archive: a self-contained zip with the ODM study definition (XML + JSON), all datasets, the complete audit trail, the signature manifest, and a PDF casebook for every subject.
That’s the whole loop: capture → clean → verify → sign → snapshot → analyze → archive, with every step audited. For details on any piece, head to the user guide.