Good to go? The six questions before every study visit

Research is usually bolted onto a clinic that was built for something else. The first coordinator builds the bench out of whoever is around: a tech who can do vitals, a nurse who can draw, a photographer who learned the OCT preset last month. That works while the bench is small. Then studies get added, coordinators get added, non-coordinator techs get added, and the puzzle of who may do what, on which study, as of which date, gets complicated. Study-specific training sits next to study-agnostic GCP. Delegation has to land on the log before the task, not after. In an established study the lead coordinator knows all of this by heart. At start-up, or while someone new is getting acclimated, she does not, and the only way to find out is to walk over and check.

That is the night-before feeling this page is about. It is like checking a lock you already locked. What you want is to see from the hallway that the latch is turned. Six questions, each with the practice a coordinator does by hand, what the app can show from afar today, and what still means walking over.

1. Is every document the current version?

By hand. The protocol, the lab manual, the pharmacy manual, the IB, the worksheets. Each has a version and an effective date, and an amendment can change the order of a visit, a window, or a draw volume. The check is: which version is on the shelf, which version is in the binder tab, which version was everyone trained on, and do those three match. Most sites keep a version log in the regulatory binder and trust the coordinator to remember when it changed.

From afar. Each document you upload carries a version label and links to the steps that cite it. When you upload a replacement, every step that cited the old one gets a check flag until someone opens the new page and confirms it still says what the step says it says. A step's citation opens the document at the page a coordinator confirmed, so a new person can read the paragraph instead of taking the recipe on faith.

Still yours. Which version is current. The app labels versions and flags what changed since anyone looked; it does not decide that version 5 supersedes version 4, and it does not know your IRB approval date. Keep the version log.

2. Is everyone trained and delegated on it?

By hand. Two lists that have to agree: the training log, which says who was trained on what and when, and the delegation log, which says who the PI delegated for which tasks, signed and dated. The inspector's question is whether both dates land on or before the first time the person did the task. Trained first, then delegated is the defensible order.

From afar. The app mirrors the signed delegation log as a matrix: person by study by capability, with a start date and an end date, so "was she delegated for the pregnancy test on that day" is a lookup instead of a binder trip. Training that is study-agnostic, like GCP or IATA, is held once per person with its expiry and counts across every study. Where the matrix and the binder disagree, the app shows the disagreement. It never grants authority; the log does.

Still yours. The signature. Nothing here replaces the PI's pen, and the app does not tie a delegation to a specific document version. If an amendment requires re-training, you decide that.

3. Is the staff on site tomorrow the staff I need?

By hand. The whole visit, procedure by procedure: do we have someone certified, delegated, and (where it matters) correctly masked for each one, and are they in the building tomorrow. This is the one that fails quietly at handoff. A coordinator covers a colleague's visit, does the standard version of a task instead of the protocol's version, and it surfaces at data entry.

From afar. Coverage. For every procedure on the visit the app shows who at your site is delegated and currently certified for it, warns sixty days before a certification lapses, and excludes anyone whose masking status is wrong for the step. If nobody covers a procedure, the visit says so before the day. The lead can see who to tap without opening three binders. Read who can do what at a study visit for the roles.

Still yours. Whether they are on tomorrow. The app does not keep a schedule or a rota, and it does not assign a person to a visit. You see who can do it; your existing schedule says who is in. Team schedules are a future module. Masking status is tracked; that module is early.

4. How do we do this procedure, here?

By hand. The part that lives in people. The protocol says "OCT, both eyes." Your site knows the machine, the preset, that the eye needs twenty minutes of dilation, that the drops are in the second fridge, and that the reading center wants the upload the same day with the accession logged. None of that is written where the person doing it tomorrow can find it. It is why "just getting it" is the job requirement, and why it is not scalable.

From afar. Every procedure carries two layers: the protocol's steps, and your site's how, where, why, and when. The site layer is a recipe. You write it once for a procedure, and the next study that has the same procedure starts with your recipe attached instead of a blank binder. A visit can override the recipe where that visit is different. The person running the visit sees the recipe on the sheet, with the protocol page one click away, so they can check it rather than trust it.

Still yours. Writing the recipes. That is an afternoon per procedure the first time and minutes after that, and it is the afternoon that lets a novice run the visit.

5. When do we do each step, and in what order?

By hand. Two clocks. The protocol's: the visit window, and the prerequisites such as the pregnancy test before the injection and vitals before the blood draw. The site's: what order actually works in your rooms, and where the timing note lives ("PK draw pre-dose, fasting eight hours"; "courier cutoff 15:30"). Getting the day right is the window question. Getting the order right is the visit checklist question.

From afar. Windows compute from the anchor date and recompute when a date moves, with each visit shown as upcoming, opening soon, in window, overdue, done, or missed. Within a visit, the protocol's prerequisites order the checklist and the sheet says "order matters today: A and B before C." Your site's timing notes sit on the step.

Still yours. Clock time. The app knows the day and the order; it does not know that the injection is at 9:40. That is your appointment book.

6. Why?

By hand. The reason behind a step is what lets someone act with judgment when the step does not go to plan. Why three blood pressures five minutes apart, averaged? Why the pregnancy test before the injection and not after? A coordinator who knows why can handle the exception. A coordinator who only knows what will do the standard version.

From afar. Each step can carry the protocol's reason, with a section citation, and your site's reason. Both print on the run sheet. It is one line each and it is the difference between a checklist and a recipe.

Still yours. Writing the line.

What the verdict means

Open a subject's visit and the app rolls these up into one line: Clear to start, Heads-up with the things to know, or Not clear yet with the blockers. The verdict comes from the window state, the unmet prerequisites, and the crew coverage. It is advisory. It never blocks a tick, because the app mirrors your site's authority rather than granting it. It is the latch, seen from the hallway.

The two questions it cannot fully answer, the current version and who is in the building tomorrow, are said plainly on the page so nobody mistakes a green verdict for those. When three people ask for the same missing piece, it gets built. That is how the roadmap works.

The printed sheet

Everything above prints as a run sheet for the visit: the steps in order, the recipe under each, who is covered for it, and the citation. It is a task list beside the source worksheet, not the source record, and it is what you hand to whoever is covering. What a run sheet is, in one page, if the word is new.