Most eCRF specifications are not specifications. They are collections of form mock-ups with gaps the EDC build team is left to fill by guesswork. A build-ready specification is a different kind of document, and the difference shows up in build timelines, UAT cycles and the queries your sites raise in the first month of enrolment.
Start from the protocol, not from the last study's forms. Every field in the eCRF should exist for a reason that can be pointed to. The protocol defines the endpoints, the schedule of assessments and the safety reporting obligations. The specification's first job is to demonstrate that the forms cover exactly that. No less, and not much more. In practice this means a traceability exercise: protocol section and assessment mapped to form and field. It expo
Field-level definitions: where most specifications go thin. A mock-up shows what a form looks like. A specification defines what each field is. The difference is a set of attributes the build team cannot invent and should never have to. The details that look pedantic are the ones that matter. Whether an adverse event onset date permits a partial date determines how every date comparison in the study behaves. Whether haemoglobin arrives in g/dL, g/L or thro
Edit checks are a specification of their own. A field definition says what the datum is. An edit check says when the system should challenge it. Conflating the two produces documents where validation logic lives in scattered comments, and builds where nobody can say with confidence what is checked and what is not. Checks deserve their own section, with their own structure: a unique check ID; the type (univariate, cross-form, cross-visit; syst