CRF Design and Database Build
CRF design translates protocol endpoints into structured data fields. Good design minimizes queries: use consistent naming, clear instructions, controlled vocabularies (dropdowns), and avoid free-text where coded data is needed. Each field should map to a protocol objective or a safety requirement - collecting data "just in case" increases cost and query burden. Understand the difference between the CRF (the form) and the database (the underlying structure of tables, fields, and edit checks).
Key concepts: field types (date, numeric, coded, text), units, ranges, mandatory vs. optional fields, derived vs. collected variables (never collect what can be derived reliably), and the annotation/CRF specification that links each field to its database variable. Edit checks come in types: range, consistency (cross-field), format, and missing-data checks. Build includes database structure, code lists, and test scripts.
Traps: collecting a value and also collecting its derived total (redundancy risk); designing a date field without specifying format (ambiguity in DD/MM vs. MM/DD); using free text for AEs or medications instead of coded fields; and forgetting that a field used in an edit check must exist in the database before the check can run. Another trap is confusing a hard edit check (prevents save) with a soft check (warns but allows).
Rule of thumb: every field should be justified by "which analysis or safety decision needs this?" Worked example: a form asks for "Date of birth" and "Age." Collecting both invites inconsistency; collect birth date (or age if privacy requires) and derive the other, applying the protocol's age rule consistently.