Every IVD study begins with a conversation. The sponsor describes what they want — a cohort, a sample type, an analyte range, a number of subjects. The CRO listens, asks clarifying questions, sends back a quote. The conversation continues over email, with attachments, with revised eligibility criteria, with revised volumes. Eventually a draft protocol arrives, the kickoff happens, the contract is signed. Three months later, somebody discovers that the inclusion criterion the sponsor's regulatory lead intended is not the inclusion criterion the CRO's medical writer captured, and the resulting protocol amendment costs four to six weeks.
The pattern is so common that it has stopped surprising us. The cause is consistent: the alignment between the sponsor's intent and the CRO's understanding never converges in a single document before the protocol is drafted. The conversation lives across a dozen emails, three quotes, two meeting recordings, and the assumptions each party carried into the kickoff. By the time the protocol writer is drafting, they are reconstructing the alignment from scattered evidence, and they are guessing wrong on three out of four ambiguous fields.
The framework below describes the artifact we use to fix this — the sample spec sheet. It is one document. It contains six tables. The tables ask the questions the study has to answer, in the order they have to be answered, and the sponsor fills it in. We have iterated this form for years. Other CROs have copied it. The simplicity is the feature. A more elaborate form would capture more theoretically; a simpler form would let too much through; the version we use is the version we landed on after refining out everything that did not earn its place.
Capture every detail upfront, in a structured form.
Email threads lose details. A structured form does not. The form asks the questions that have to be answered, in the order they have to be answered.
The first principle. The unstructured discovery process — emails, calls, attachments — loses information by design. Each conversation captures part of the picture, none captures all of it, and the parts overlap, conflict, and decay across the timeline. By contrast, a structured form forces the conversation through a deterministic sequence of questions. The sponsor fills in every field, or explicitly marks "to be determined" against fields they cannot yet answer. The conversation about what is not yet known becomes explicit, instead of disappearing into a series of follow-up emails the CRO has to chase.
The form's structure matters. It begins with the cohort identity and size — the largest-resolution decisions first. It then drills into distribution requirements (age, ethnicity, target population), then recruitment information (eligibility, reimbursement, where to find the subjects), then the lab tests required, then specimen handling. Each section's questions follow from the prior section's answers. A sponsor who cannot yet name the inclusion criteria has not yet decided who their study is for, and the form surfaces that gap rather than letting it pass.
Our current sample spec sheet is one document with six structured tables: Cohort Name; Cohort Size (subjects in cohort, max reimbursable screen failures); Cohort Distribution Requirements (age range, ethnicity, other population requirements); Cohort Recruitment Information (inclusion, exclusion, subject reimbursement, special preparation, where to find subjects, screen-failure definition); Required Lab Tests or Procedures (test names, instrument requirements, min/max analyte values for qualification); and Specimen Handling and Processing (specimen type, container, minimum yield, storage temperature, processing notes). Twenty-five fields, six tables, one page per cohort. Sponsors fill it in directly; we review it directly; the conversation converges quickly.
For every new sponsor engagement, send the spec sheet before the kickoff meeting and ask the sponsor to fill it in for each cohort. The kickoff agenda is to walk through the spec sheet field by field and resolve the open items together. Studies that begin with a complete spec sheet converge faster than studies that begin with a draft protocol.
Simplicity is the feature, not a limitation.
Adding fields to a form is easy. Deciding which fields to leave out is the work. The simplicity comes from years of refinement.
The second principle is the one we are most often asked about. CROs and sponsors who see the spec sheet often ask why it is not longer. Surely there are more details that need to be captured. Surely the form should ask about monitoring frequency, about query response time, about regulatory requirements at the cohort level, about a hundred other operational details that matter to the study.
The answer is that those details belong in other documents — the SOW, the monitoring plan, the kickoff document — and putting them in the spec sheet would dilute the spec sheet's job. The spec sheet's job is to align the sponsor and the CRO on the cohort and the sample, before the protocol is drafted. Every field that does not serve that job is a field that asks the sponsor to make decisions out of sequence. A sponsor who is asked to specify monitoring frequency in the spec sheet has been pulled out of the question of who the study is for, and the alignment work the spec sheet was supposed to do gets diluted.
The simplicity is the result of years of removing fields, not of starting simple. Each field we removed had a story — a sponsor who couldn't answer it productively, a field that conflicted with another, a field that surfaced in another document anyway. The current 25 are the ones we have not been able to remove without losing information the form has to carry. The 25 are not the minimum; they are the irreducible set we have arrived at through use.
The form has been refined over more than a decade of running IVD studies, and we have watched several other CROs adopt structurally similar forms in the years since we started using ours. The convergence is not flattering — it is informative. The fields that survive are the fields that carry the load, and the load is constant across IVD studies regardless of which CRO is running them. We share the form openly because the framework, not the form, is the moat.
When extending or revising any structured form — spec sheet, kickoff document, monitoring plan — the default discipline is removal, not addition. The question for every field is whether removing it loses information the document has to carry. If not, it should not be there.
The spec sheet auto-builds the SOW.
Every field on the spec sheet maps to a structured variable. The SOW iterates over cohorts and renders the same six tables. Aligned data, no rekeying, no drift.
The third principle is operational. A spec sheet that lives in isolation as a Word document is useful. A spec sheet whose fields map directly into the SOW template — and from there into the protocol skeleton, the budget tables, and the kickoff document — is a different artifact entirely. It becomes the source of truth that downstream documents inherit from, rather than a starting point that gets manually re-typed into each subsequent document.
The implementation is not exotic. Every field on the spec sheet has a corresponding variable: cohort name, number of subjects, age range, inclusion criteria, specimen type, storage temperature. The SOW template, drafted as a Word document with merge variables, iterates over the cohort records and renders the same six tables per cohort. The sponsor's spec sheet input becomes the sponsor's SOW content automatically. The CRO does not retype the data into the SOW. The protocol writer does not retype the data into the protocol. The kickoff document references the same spec.
The deeper move this enables is consistency over time. When the spec sheet is the source of truth and the SOW renders from it, every change to the spec sheet propagates downstream. A revised inclusion criterion updates the SOW automatically. A revised cohort size updates the budget tables. A revised specimen handling spec updates the protocol skeleton. The drift between documents that produces most amendments is eliminated, because the documents are not maintained independently — they are projections of the same source.
The spec sheet should be a structured data record, not a free-text document. or any structured-data platform works. Downstream documents — SOW, budget, kickoff doc — should render from that record using merge variables. The sponsor's revisions to the spec sheet propagate automatically. The drift between documents disappears.
What this framework rules out.
The three principles describe how the spec sheet aligns the study before the protocol. They also rule out a few conventions worth naming.
They rule out email-thread-based discovery as the alignment mechanism. Email threads lose detail by design. The structured form does not.
They rule out elaborate forms with dozens of optional fields. Every optional field is a field that did not earn its place. Fields that do not earn their place dilute the form's job and produce sponsor responses that miss the questions that matter.
They rule out downstream documents maintained independently from the spec sheet. Drift between documents is the source of most amendments. The spec sheet is the source; everything else renders from it.
The framework is not closed. When the study outcome matters, you call RDI. The spec sheet is the simplest artifact in our operating system. It is also the one that prevents the most expensive errors.