Visit window calculator (paste the schedule, get every window)

How the windows are computed

A window is three dates from one. The target is the anchor date plus the study day; opens is the target minus the days before; closes is the target plus the days after. With Randomization on Tuesday, September 1, 2026, the Week 4 visit at Day 28 with a ±3 window looks like this:

Two things move that arithmetic, and both are toggles above. If the protocol calls the anchor Day 1 and has no Day 0, then Day 28 is only 27 days after the anchor, and the target becomes Monday, September 28. And if the protocol chains visits — Week 4 counts from the Week 2 that actually happened — then a Week 2 done on September 17 instead of the 15th pushes Week 4 to October 1, and its window with it.

The math is done on whole days, never on clock times, so a target computed in Virginia is the same target computed in Arizona. I lost PK data once to an out-of-window visit; the arithmetic was not hard, the sheet just was not in front of me on the day it mattered.

Questions I get asked

Day 0 or Day 1 — which does my protocol use, and why does it matter?

Open the schedule of assessments and look at the first visit after the anchor. If the anchor visit itself is labelled Day 1 and the next is Day 8, you are on a Day-1 protocol with no Day 0. If the anchor is Day 0 and the next is Day 7, you are on Day 0. It matters because the choice moves every later target by one calendar day: Day 15 is 14 days after a Day-1 anchor and 15 days after a Day-0 one. On a ±2 window that is a quarter of the room you have. The toggle applies once, where a study-day number meets a real date; a chained visit inherits its anchor's date and needs no shift.

What happens when the anchor moves?

Nothing is fixed until the anchor event happens. Every date you see before Randomization is a projection from the planned date, and every one of them is wrong by however many days Randomization slips. When it does happen, enter the real date in the anchor field and everything downstream recomputes from it. That is all re-anchoring means: the windows are a function of one date, and you changed the input. If the subject is still in screening, leave the anchor blank and enter the screening date instead; the pre-anchor visits project from it, and the page tells you where the anchor is expected to land.

Calendar days or business days?

Calendar days, unless the protocol says otherwise, and in my experience it almost never does. Day 28 is 28 calendar days after the anchor whether it lands on a Tuesday or a Sunday. What the weekday changes is scheduling, not the window: if Week 4 opens on a Saturday, you book the subject for the Monday inside the window; you do not move the window to Monday. That is why the target column carries the weekday. When a whole window falls on a weekend or a site closure, the protocol and your SOP say what to do, and that conversation belongs with the monitor before the window, not after it.

My protocol anchors Cycle 2 to the actual Cycle 1 Day 1 — can this do that?

Yes. Tick "chain each visit from the previous visit's actual date". The first visit on or after the anchor stays on the anchor; every later visit hangs off the row above it by the difference in study days, so C1D8 is C1D1 plus 7 and C2D1 is C1D15 plus 7. Enter the actual date of any visit and the ones after it move with it. Rows before the anchor, such as screening, and any row whose day does not increase — an unscheduled visit typed into the middle — stay on the anchor. If your protocol chains only some visits, read the footnotes on the schedule of assessments; they usually say which.

What if a visit was late — does the next window move?

Only if the protocol says the next visit counts from the last one. Most fixed-schedule protocols anchor every visit to the anchor date, so a late Week 4 does not move Week 8; the window is the window, and the late visit is a deviation to note where your site notes them. Cycle-based protocols, and many with a "relative to the previous visit" footnote, do the opposite: the next window counts from the actual date, and the late visit shifts everything after it. This page does whichever you tell it with the chain toggle. Reading the footnotes on this one question is a ten-minute job that prevents a very long one.

Does this store anything or need a subject ID?

No. The arithmetic runs in your browser, and nothing you type is sent anywhere; there is no account, no cookie for the tool, and no server behind it. The optional label is for the printout and the calendar file, and "Subject 012" or a blank is all it needs. Please keep it that way: no names, no initials, no dates of birth. The share link carries the schedule and the dates in the address itself, so treat it the way you would treat the printed sheet, and do not put a label in it that you would not write on the sheet.

Is this a source record?

No. It is a calculator, the same as the one on your desk, and it prints a worksheet. The CRF and the chart are the record of when the visit happened; the protocol, its amendments, and your site's SOPs are the record of when it should have. Use this page to plan the week, to check a window before you book the subject, and to see what a late date does to the visits after it. Then write the actual date where your site writes actual dates. Every printout and calendar file from this page says so in the footer, and I would rather that be said too often than once too few.

A window answers one question: when. The visit still needs the other three — what gets done, in what order, and who at your site is delegated to do each part — and that is a different sheet. I built the windows into CRC Run Sheet first because they are the door; the run sheet for the visit is the room, and the same subject IDs and dates you typed here are all it holds.