The first protocol I review on every new study is the version the sponsor sent. The second protocol I review is the version we send back. They are usually different documents. The sponsor version is comprehensive — schedule of events, eligibility criteria, sample handling specs, IP accountability procedures, AE reporting flow, statistical analysis plan, regulatory correspondence index. The version we send back is shorter, often by a factor of two or three. It is not less rigorous. It is differently audienced.
Most IVD protocols are written by sponsor scientists who know the assay deeply and who want the protocol to reflect the depth of their knowledge. The instinct is good. The artifact it produces is wrong for its actual readers. The site coordinator running consents on Tuesday afternoon needs five things on one page: who qualifies, what to do, how to handle the sample, what to document, and who to call when something goes wrong. The IRB reviewer needs one or two more sections. The sponsor scientist needs essentially nothing from the protocol once it is approved — they have the IFU, the validation plan, and the statistical analysis plan elsewhere.
The framework below describes how we write protocols that do their job for the people actually using them. It is not an argument for skipping detail. It is an argument for putting the detail where it belongs and stripping the rest. The best protocol is the one page the visit runs from. Every other page should be earning its place.
Compress to the page that drives the visit.
If the visit can be run from one page, write that page. Make every additional page earn its place against the question: who reads this, and what do they need from it?
Every page of a protocol after the first one is a hypothesis: that someone, at some point in the study, will need this content to do their job. Most of those hypotheses turn out to be false. The schedule of events, the inclusion and exclusion criteria, the sample collection summary, the AE reporting trigger conditions, and the contact escalation list — those five things, fit on a single page, are the protocol that the site actually consults on visit day. Everything else lives in the document but is not, day-to-day, the protocol.
The discipline is to write the one page first. Not as an executive summary appended to a long document — that is a different artifact. The one page is the protocol the site staff would print and tape to the inside of the consent room cabinet. Everything else in the document is there to support that page, defend it to the IRB, or answer regulator questions about how it was constructed. Pages that don't serve one of those three functions are pages that should not be in the document.
The deeper move this enables is rigor about what to add. When the question is "should this section be in the protocol," the answer is almost always yes — it cannot hurt to be more complete. When the question is "what does this section do for the one page," many sections fail to earn an answer. Those are the sections that come out.
Across rescue engagements we have repeatedly inherited protocols where the procedural complexity of the document was inversely correlated with how well the site executed the study. The longer protocols produced more deviations, not fewer, because the site staff could not navigate them under time pressure and reverted to whatever version of the procedure they could remember. Shorter protocols, written with the visit in mind, deviated less because the site could actually find the relevant section in real time.
Before adding any section to a protocol, name the reader who needs it and the question it answers for them. If the reader is "the medical writer's checklist" or "the historical convention from prior submissions," the section does not belong. If the reader is the IRB, name the specific IRB question it addresses. If the reader is the regulator, name the specific submission section it supports.
Leave biological tolerance in collection windows.
Tight specifications look rigorous on paper. They produce protocol deviations against biology that does not cooperate.
The most over-specified section in most IVD protocols is sample collection. Two-hour processing windows. Thirty-minute centrifugation latencies. Strict room-temperature exposure limits. Each one is defensible on the science. The composite is a collection workflow that, in real-world clinic conditions, is impossible to execute without occasional deviation.
The convention treats deviation as the site's fault. The site failed to process within two hours, the site failed to centrifuge within thirty minutes, the site failed to refrigerate within the window. We have come to believe the convention has it backwards. If a protocol routinely produces deviations across multiple sites, the protocol — not the site — is what's wrong. Real biology has variance. Real clinic operations have variance. A protocol that does not leave room for either is a protocol that is going to generate a steady stream of avoidable deviations.
The corrective is to write tolerance into the spec deliberately. Where the science permits a wider window, use the wider window. Where it does not, name the narrower window — but justify it with assay-stability data, not with the medical writer's instinct that tighter is better. Specifications anchored to actual stability data, with explicit margin, produce cleaner studies than specifications anchored to the writer's hedge against criticism.
A flu-surveillance forecasting program we ran in 2019 specified swab handling and shipping windows aligned to actual assay stability for the two reference platforms in use, rather than to a single tightest-common-window across them. The result was that on days when one assay's window was tighter than the other, the protocol could route the sample appropriately rather than forcing the wider-window assay to operate as if it were the tighter one. The specificity served the science. It did not over-constrain the operations.
For every collection window in the protocol, ask: is this window anchored to actual assay-stability data, or to a default the medical writer carried over from a prior protocol? If it is the second, replace it with the first, and add the explicit tolerance the data supports.
For R&D protocols, the audience is the site and the IRB. Not the scientist.
The sponsor scientist already knows the assay. The protocol is for the people who don't — and who have to run the study from it.
The third principle is the one that requires the most discipline to internalize. Protocols are written, in most organizations, by the team closest to the assay. The sponsor scientist who developed the assay or the regulatory affairs lead who has owned it across submissions writes the document. They write it in the voice of the person who understands the assay deeply, because that is the voice they have.
For pivotal trials, this is sometimes correct — the FDA reviewer reading the submission is closer to the scientist's expertise than to the site's. For R&D, pre-pivotal validation, and biomarker discovery work, it is wrong. The protocol's primary readers are the site coordinator who has never seen this assay before and the IRB reviewer who has half a day to read 200 protocols this month. Neither of them benefits from the depth of the scientist's understanding being preserved on the page. Both of them benefit from the depth being translated into instructions and rationale that they can act on.
This is not a request for dumbing down. It is a request for translation. The scientist's understanding is the source material. The protocol is a different document, written for different readers, doing a different job. Confusing the two — treating the protocol as the place where the scientist's knowledge is recorded — is the most common authorial error in IVD trial design.
For any R&D or pre-pivotal protocol, name the two primary readers explicitly: the site coordinator and the IRB reviewer. Walk every section against those readers. If a section serves only the scientist's voice, move it to a separate scientific rationale document and remove it from the protocol.
What this framework rules out.
The three principles describe how we write protocols that the site can execute and the IRB can approve quickly. They also rule out a few conventions worth naming.
They rule out length as a proxy for rigor. A 60-page protocol is not more rigorous than a 20-page one. It is, usually, less rigorous, because the rigor that counts is whether the document can be executed, and executability declines steeply with length.
They rule out tight specifications as a hedge. Specifications that are tighter than the underlying biology supports do not protect the study; they generate deviations. Tolerance is rigor when it is anchored to data.
They rule out writing the protocol for the scientist who already knows the assay. The protocol is for the readers who don't. Treating it as documentation of the scientist's understanding produces documents that read well to the author and execute badly in the field.
The framework is not closed. When the study outcome matters, you call RDI. The best protocol is one page — and the work of writing it is in deciding which page that is.