A protocol is the instruction manual for the study. This guide covers the sections it needs, the SPIRIT 2025 checklist, and how to write it so that eCRFs, visits and edit checks can be built straight from it.
Free sandbox · No credit card · 21 CFR Part 11 aligned
Synopsis
Background and rationale
Objectives and endpoints
One primary endpoint
Study design
Participants: eligibility
Interventions
Schedule of assessments
Drives forms and visits
Safety and adverse events
Statistics and data management
Ethics and administration
What makes a protocol good
Why it matters
A protocol has several audiences with different needs. The ethics committee reads it to decide whether participants are protected and whether the study is justified. Investigators use it day to day to know who to enrol and what to do at each visit. Regulators and reviewers use it to judge whether the study can answer its question. And, in a modern trial, the people who build the data system use it to turn procedures into forms, visits and checks. A protocol that serves all four is not necessarily long, but it is precise.
The common failure is writing for the first audience only: a persuasive scientific narrative with the operational detail buried or missing. When the detail is missing, someone fills the gap at the site, differently in each place, and the result shows up as protocol deviations. The protocol deviation tracking software page describes how those are recorded, but the best deviation is the one the protocol made impossible to misread.
If you have never written one, start from the clinical trial protocol template and the official SPIRIT 2025 checklist. Then read how to run your first clinical trial for where the protocol sits in the overall sequence.
Structure
Headings vary by template, but these topics need an answer somewhere in the document. The right-hand column shows what each means for your data system.
| Section | What it must settle | What it means for data capture |
|---|---|---|
| Synopsis | One-page summary of design, population, intervention, endpoints | Check it matches the detail; mismatches are common |
| Background and rationale | Why this question, why now, why this design | None directly |
| Objectives and endpoints | Primary, secondary and exploratory outcomes, defined precisely | Each endpoint needs a form, field and timing |
| Study design | Allocation, blinding, arms, duration | Randomization and blinded-role setup |
| Eligibility | Inclusion and exclusion criteria written as testable statements | A screening form with checks against each criterion |
| Interventions | What, how much, how, by whom, adherence | Dosing and accountability forms |
| Schedule of assessments | What happens at each visit and the allowed window | The visit-by-form grid in the builder |
| Safety | Adverse event definitions, grading, reporting timelines, stopping rules | Adverse event and AESI forms; review workflow |
| Statistics | Sample size, analysis populations, handling of missing data | Exports and derived fields |
| Data management | How data is collected, cleaned and locked | Edit checks, queries, access, lock criteria |
| Ethics and administration | Consent, confidentiality, oversight, publication | eConsent, roles, audit trail |
Core sections
Objectives and endpoints come first because everything else serves them. State one primary endpoint with what is measured, how, when and in whom. Add secondary endpoints deliberately; each has a cost. Define the endpoint well enough that two analysts would calculate it identically. The clinical trial endpoints entry and the sample size calculation entry help here, and you can test assumptions with the sample size calculator.
Eligibility criteria should be written as statements a coordinator can answer yes or no, with the source of the answer. Compare "adequate renal function" with "eGFR of at least a stated value at screening, from the lab report". The second can be a form field with an edit check. Capture includes calculated fields such as eGFR (CKD-EPI 2021), so a derived value can be shown read-only during entry. Keep each criterion only if it has a scientific or safety reason; unnecessary criteria slow recruitment.
The schedule of assessments is the heart of the operational protocol. Build it as a grid: visits across the top, assessments down the side, with windows around each visit. This single table drives your forms, your visit schedule in the data system and your budget. The schedule of assessments builder is a practical way to draft it, and the clinical trial budget template can start from the same grid. If a procedure appears in the text but not in the grid, or vice versa, fix that before submission.
Safety deserves explicit definitions: what counts as an adverse event, how severity and causality are graded, which events need expedited reporting, to whom and how fast, and what would stop the study or a participant's treatment. Do not leave this to the investigator brochure alone. Capture has adverse event and AESI templates in the templates library, and the field-level audit trail records changes with the reason.
Upload a PDF or DOCX to the free sandbox and the AI builder drafts visits and forms for review. No credit card, pay only when you go live.
Writing for the builder
Process
You do not have to write it in order, but you do have to review it as a whole.
Write the one-sentence question before opening a template. If the team cannot agree on it, no protocol will fix that.
Visits across, assessments down, windows noted. Check every cell against a reason.
Use it as a completeness check rather than a form to fill: for each item, find where in your protocol it is addressed.
Ask a site coordinator to walk through a visit using only the protocol, and a statistician to confirm the analysis follows from the endpoints.
Build or AI-draft the eCRFs in the sandbox and see where the protocol is silent or inconsistent. Fix the protocol, not just the form.
Submit to your ethics committee or IRB and prepare registration; see the registration guide. Version and date the document, and manage changes as formal amendments.
From document to system
The AI study builder reads a protocol in PDF, DOCX or DOC and drafts the visit schedule and forms. You review every draft: nothing is saved without human review, and it only works on draft forms. This is a way to get from a blank page to a first build quickly, not a way to skip the thinking. It reads what your protocol says, so a clear schedule grid produces a clear draft, and a vague protocol produces vague forms. That is itself a useful test of the document. See protocol to study setup software for the workflow.
After review, forms go through a draft-to-approved lifecycle. Approved forms are locked for live use, and only approved forms appear in the casebook. Edit checks raise automatic queries when values break rules, and source data verification can be set per field. For ethics or IRB submission you can export a blank eCRF PDF with a cover page, form index and visit-by-form matrix, with every approved form printed empty. If the protocol is amended later, you amend the forms yourself in the same lifecycle; see protocol amendments without change orders.
Remember the limits of any tool. Software helps you capture and control data, but the protocol still has to be scientifically sound, ethically approved and compliant with applicable rules. Part 11 compliance is a shared responsibility between the software and the sponsor, and the computer system validation guide covers your part.
Start with one clear question and primary endpoint, build the schedule of assessments grid, then draft each section (design, eligibility, interventions, safety, statistics, data management, ethics) and check it against the SPIRIT 2025 checklist. Have a site coordinator and a statistician test it before submission.
SPIRIT 2025 is an updated guideline for protocols of randomised trials. It comprises an evidence-based checklist of 34 minimum items to address in a trial protocol, plus a diagram of the schedule of enrolment, interventions and assessments. It adds an open-science section and items on harms and on patient and public involvement.
Requirements depend on your regulator, ethics committee and sponsor, and ICH GCP describes expected content. Typical sections are synopsis, rationale, objectives and endpoints, design, eligibility, interventions, schedule of assessments, safety, statistics, data management and ethics. Check the requirements that apply to you.
Capture's AI works in the other direction: it reads your protocol and drafts the visit schedule and forms for a person to review. It does not decide your scientific design, and nothing is saved without human review.
Detailed enough that a coordinator can run any visit from it: which assessments at which visit, the allowed window and any conditions. This grid drives forms, visit schedules and budget.
A template helps with structure and completeness. Start from the protocol template in the templates library and adapt it to your design and sponsor requirements.
It should. Keep the registered design, outcomes and eligibility consistent with the approved protocol, and update the record when amendments change them.
Keep exploring
Clinical trial protocol template
A structure to start from.
Protocol to study setup software
From document to configured study.
Schedule of assessments builder
Draft the visit grid.
ClinicalTrials.gov registration step by step
Registering the finished protocol.
Running your first clinical trial
The whole sequence.
Upload it to the free sandbox, review the drafted visits and forms, and test with sample data. No credit card, pay only when live.