An electronic case report form (eCRF) is the structured digital instrument used to collect, record, and transmit clinical trial data from study sites to the sponsor. In a medical device investigation, your eCRF is the primary evidence layer between what happens at the clinical site and what ends up in your regulatory submission. A well-designed eCRF produces clean data with minimal queries. A poorly designed one generates months of remediation work before you can lock the database and file.
Most device teams treat eCRF design as a late-stage setup task. It should be one of the first. The decisions you make about form structure, field types, validation rules, and workflow sequencing determine data quality for the entire study. You cannot clean your way out of a structural eCRF problem after data collection has started.
This guide covers eCRF design principles and implementation best practices for medical device clinical investigations specifically. It consolidates material from two earlier Greenlight Guru posts on this topic, updated to reflect current platform capabilities and regulatory context.
eCRF design is the process of defining the structure, content, and logic of the electronic forms used to collect data in a clinical investigation. It includes deciding which data fields to include, what question types to use, which fields are required, what validation rules apply, how forms are sequenced across visits, and how data flows to the export file used for statistical analysis.
For medical device investigations, eCRF design also encompasses device-specific data elements: device identification, adverse event and device deficiency capture, human factors observations, and post-market surveillance data where applicable.
The output of the eCRF design process is a fully built study in your electronic data capture (EDC) system, ready to be tested in a training environment before the first subject is enrolled.
Most published guidance on eCRF design was written for pharmaceutical trials. Medical device investigations have different requirements in ways that matter.
Device studies are smaller and faster-moving. A manufacturer running a feasibility study with 15 subjects works under different constraints than a pharmaceutical sponsor managing a 200-site Phase III trial. Protocol amendments are more common, especially in early-phase device investigations where the protocol evolves based on interim device performance data.
Device-specific data requirements add complexity. Human factors data, device deficiency records, and procedural outcome data are specific to device investigations and rarely covered in pharma-oriented eCRF templates. Under ISO 14155:2020, specific data elements are required for GCP compliance that may not appear in a generic EDC template.
Post-market clinical follow-up (PMCF) under EU MDR extends data collection into the commercial phase. PMCF eCRFs run at sites that are not clinical research centers, operated by staff who are not study coordinators. The forms need to work without a research team in the room.
These differences mean that eCRF design for medical devices requires more upfront attention to clinical workflow, site capability, and regulatory-specific data requirements than a pharma-adapted template provides.
The most common eCRF design mistake is starting with forms instead of starting with questions. Every field on your eCRF should trace back to an endpoint, a safety reporting obligation, or a regulatory requirement. If you cannot identify that trace, the field does not belong on the form.
Before opening your EDC system, confirm these five things:
This analysis takes hours, not days. Skipping it costs weeks in query resolution and data cleaning.
BONUS RESOURCE: Download our free eCRF template for clinical investigations and PMCF studies to start structuring your study.
Every question on an eCRF should have exactly one correct interpretation. Vague language produces ambiguous responses that require manual review.
Replace "If applicable, note any issues" with a structured question: "Did the device deliver the intended therapy at the target anatomical site? Yes / No / Unable to determine." The third option acknowledges clinical reality without creating a free-text field. Free-text fields require human coding before analysis. When the answer space is bounded, design the question to use it.
Required fields prevent missing data but produce inaccurate entries when data is clinically unavailable. Not every field should be required.
Require fields for primary endpoint data, eligibility criteria, and serious adverse event records. For secondary data points and exploratory variables, allow "not available" and "not applicable" as explicit options, as a dropdown, not a blank field. A blank field and a documented "not available" look identical in a naive export but have different meanings in a regulatory submission.
Free-text fields are the primary source of data cleaning work. Responses cannot be analyzed statistically without first coding every entry. In a 100-subject study, that means coding 100 narratives per free-text field before analysis begins.
Use free text only where no structured alternative exists: adverse event narratives, protocol deviation descriptions, and investigator comments that are explicitly not intended for statistical analysis. For every other field, design the question to constrain the answer to a defined set of options. See our eCRF completion guidelines for how well-written completion instructions reduce the pressure to use free text.
An eCRF that fights the clinical workflow gets completed inaccurately or not at all. Site staff are entering data during or immediately after patient procedures, in environments where data collection is secondary to clinical care.
Forms should follow the chronological sequence of a clinical visit. Questions should use terminology that site staff already know, not sponsor or statistician terminology. Data entry should be required only at natural pause points in the workflow, not mid-procedure.
The practical test: walk a study coordinator through a simulated patient visit before finalizing the form structure. If any form requires navigating backward, capturing data from a step that has not yet happened, or leaving fields blank to return to later, restructure it.
Target 10 to 20 questions per form. Build separate forms for distinct clinical phases and topics: screening, baseline, each study visit, device performance assessment, end of study, follow-up. A single form covering 60 questions across six clinical topics generates more errors than six focused forms of 10 questions each.
The pressure in eCRF design always runs toward more fields. Every stakeholder sees data points that would be "useful to have." Each additional field costs time in data entry at every site for every subject for the entire study duration. Require every addition to justify itself against that cost.
EDC systems including Greenlight Guru Clinical support three rule types that catch data quality problems at entry, before they reach the database.
Validation rules reject inputs outside expected ranges in real time. A weight field that rejects values below 20 kg or above 300 kg catches data entry errors immediately. An age field that rejects values outside the eligibility range flags a potential protocol deviation before the site coordinator moves to the next form.
Show rules make fields visible or hidden based on prior responses. If a subject did not receive the investigational device, the device performance section should not appear for that subject. If a screening answer confirms ineligibility, subsequent forms for that subject need not be shown. Show rules reduce the cognitive load on site staff and prevent entries in fields that do not apply.
Process rules apply logic across forms rather than within them alone. If a prior visit recorded a serious adverse event that is still ongoing, the current visit form can automatically surface that record for status update. This prevents events from being closed prematurely or left open indefinitely without review.
Configuring these rules at setup takes time. That time is repaid in reduced queries and cleaner data throughout the study.
Every principle above points toward fewer questions and simpler structure. That is not permission to omit data elements that your regulatory pathway requires.
ISO 14155:2020 specifies GCP requirements for medical device investigations. FDA 21 CFR Part 11 governs electronic records and electronic signatures. Your protocol defines the primary and secondary endpoints. Your clinical investigation plan defines the data collection schedule. Your eCRF must capture everything these documents require.
Simple means: collect exactly what is needed, clearly, in a format that produces analyzable data. It does not mean collecting less than your protocol or regulatory obligations specify.
BONUS RESOURCE: See how Greenlight Guru Clinical handles GCP-compliant data collection, validation rules, and audit trail out of the box.
Train site staff on the eCRF one to two weeks before the study start date. Training too early results in staff forgetting procedures before they apply them. Training too late means the first enrolled subjects generate errors and queries that take weeks to resolve.
Training must be hands-on. Site staff should work through a training study that mirrors the actual study, entering simulated data and navigating the query workflow. Reading a training manual is not sufficient preparation.
Everyone who will enter or review data needs training: principal investigators, study coordinators, research nurses, and any other staff with EDC system access, regardless of prior experience with other systems. Familiarity with one EDC platform does not transfer to another.
Different study roles interact with the eCRF differently. A study coordinator needs to enter data, respond to queries, and mark fields unavailable when appropriate. A principal investigator needs to review, countersign entries that require investigator sign-off, and designate adverse events. A trial sponsor needs to monitor data without editing it.
Effective training focuses on role-specific tasks. Overloading a study coordinator with sponsor-level features produces confusion and increases error rates at the site.
The permissions structure in your EDC system is a study integrity control, not an administrative detail. Greenlight Guru Clinical ships with pre-configured role-based permissions that map to standard investigational roles.
At minimum: study coordinators hold data entry permissions. Principal investigators hold data entry and event designation permissions. Sponsor monitors hold view and query permissions. Export permissions are granted only to designated data managers and require a separate "view identifiable" permission before personal data can be included in an export.
Document the permissions assignment in a study SOP before enrollment begins. Ad-hoc permission grants accumulate during long studies and complicate the audit trail.
Protocol amendments in device investigations are common, particularly in early-phase studies where the protocol evolves based on interim data. Amendments that affect data collection require eCRF changes.
A well-structured EDC system tracks version history for form changes. In Greenlight Guru Clinical, form amendments are versioned with timestamps, so the audit trail reflects which form version was in use when a given data point was collected. Document every form change with the same rigor as the protocol amendment itself: what changed, when, why, and which subjects were enrolled under each version.
Data cleaning at the end of a study is one of the primary causes of delay between last patient last visit and database lock. Teams that resolve queries within days of their appearance consistently close their studies faster than teams that let queries accumulate.
Configure your EDC system to generate automated queries for out-of-range values, missing required fields, and logical inconsistencies between forms. Assign query resolution responsibility to specific roles. Review the open query log at a defined frequency, weekly at minimum, more frequently at high-enrollment periods. Document every query resolution in the audit trail. For regulatory context on what continuous data management looks like across FDA-regulated investigations, see our guide to data management and reporting in FDA-regulated clinical trials.
Greenlight Guru Clinical generates variable names automatically in the format E1_F2_Q3 (Event 1, Form 2, Question 3). Before the study starts, configure your own export labels that describe the data in plain language: "patient_age_at_enrollment," "device_delivered_to_target_site_yn," "adverse_event_severity."
Your analysis team works with the exported data, not with the EDC system. Labeled exports reduce the time between database lock and first analysis. The label configuration is also a documentation artifact that describes what was collected and how it is coded.
Greenlight Guru Clinical is built specifically for medical device and diagnostics investigations. It includes 17 pre-validated question types covering the data collection patterns most common in device studies: numeric fields with configurable ranges, date and time fields, dropdowns, multiple choice, image capture, and clinical observation records.
The study builder supports validation rules, show rules, and process rules at the field and form level. Form amendments are version-controlled with full audit trail. The platform meets 21 CFR Part 11 requirements for electronic records and electronic signatures. Role-based permissions are pre-configured for standard investigational roles and fully adjustable for study-specific needs.
For PMCF studies, the platform supports continuous longitudinal data collection with follow-up scheduling, site access management for non-research sites, and export formats compatible with post-market surveillance reporting under EU MDR. Patient-reported outcomes can be captured via the ePRO module on any device, in-person or remotely.
If you need a broader view of how clinical data management fits into a device manufacturer's quality system, that page covers the full workflow from study setup through post-market surveillance.
If you are evaluating EDC systems and want to assess eCRF design flexibility specifically, the EDC system selection guide for medical devices covers the questions to ask vendors about mid-study amendment handling, question type coverage, and validation documentation. You can also explore Greenlight Guru Clinical's eCRF capabilities in detail before your demo.
When you are ready to see the platform in action, get a demo of Greenlight Guru Clinical.
If you are building out your clinical data collection process, these guides go deeper on specific components: