Designing your electronic case report form (eCRF) starts with understanding the anatomy of a form. While this sounds very basic, experienced clinical data managers know that data concerning the safety and efficacy of a treatment, or data that’s meant to describe the course of a disease, is the informational equivalent of dynamite. Handled properly, it can open new avenues. Handled improperly, it can lead to disaster. In addition, how we collect this data is heavily regulated and therefore, how you design your electronic case report forms (eCRFs) is critical to effective clinical research. Don’t let your efforts to capture better data, faster, end in an explosion!
In this blog, we’ll walk through some of the terms that you need to know before embarking on the design of your electronic case report form (eCRF). Be sure to view our eCRF Design Guide for further ideas and best practices to help you build forms that will: deliver the highest quality data, speed time to capture, enable the widest possible integration, facilitate robust and rapid analysis, and make regulatory submissions smoother.
Now let’s talk about electronic case report forms (eCRFs)!
The anatomy of an electronic case report form (eCRF)
An electronic case report form (eCRF) is a digital, usually web-based, questionnaire for collecting data about a study participant. There are many routes data can take into the eCRF. It may be:
- manually entered, piece by piece, by a clinical research coordinator;
- provided directly from the study participant herself;
- uploaded in bulk; or
- transferred directly by integrating with an external data source (e.g. EHR, imaging database, via API, etc.).
Forms hold the data that biostatisticians will analyze to draw conclusions from a study. Given the preciousness of their contents, it’s no wonder that a whole system of required components, controls, and features should converge to ensure that these forms function reliably.
Why “case report”?
In medicine, a case is an instance of a disease or diagnosis. A case report provides a history of the signs, symptoms, treatment, and follow-up of the patients with the disease or diagnosis along with supporting context. Not all participants in a clinical study may have the disease under investigation; control or comparison groups often do not. Regardless, the term “case report” persists, in general form, within clinical studies. A “casebook” refers to the completed set of case report forms for one study participant.
Back to basics: must-know electronic case report form (eCRF) components and terminology
The form components that we’ll talk about in this section are the basic ones you need to understand before delving further into the realm of actually designing your eCRFs. The terms, like “item,” “field,” and “question” are often used interchangeably among data managers, but sometimes with variation. One manager’s item is another’s question. What you’ll call an item label, a colleague may call a field label. The concepts nonetheless are the same.
The above picture shows a variety of components and terminology used when designing electronic case report forms (eCRFs). Keep reading to learn their meaning.
- Form label
The form label should clearly and concisely describe the kinds of questions being asked within the form. A descriptive form label helps your clinical research coordinators distinguish one form from another at a glance, which is crucial when scanning the list of all forms to be completed. - Group label
A form might include dozens of questions (or items, technically speaking.) Groups help sub-categorize them. Like the form label, a group label should describe the questions that it contains. Note that a group can recur within a form, as when a set of blood pressure values is measured multiple times over the course of a day. These groups are called repeating groups. A form can consist of just one group, and the form builder can decide how conspicuous to make the groupings. - Item label
A short, clear, and precise prompt for a user to enter a particular piece of data. The label may be a single word or term, like ‘Serum creatinine level,’ or a full sentence, such as ‘Specify the participant’s ethnicity.’ - Item hint or description
Short text that contains instructions for the user who will enter data. Suitable for detail that you don’t want cluttering up the item label. - Field
The space, initially empty, that the user will fill with a value is a field. Note that a field need not be a single, contained space. A set of radio buttons or checkboxes can also represent a single field. - Value
Typically the input of the user, in response to the item label and hint. However, values may also be generated by calculations carried out by the form. For example, the BMI may be auto-calculated from height and weight values entered by the user. The field is then set as read-only. - Choice label
When the field offers the user a choice among multiple options, each option is represented by a choice label. A choice label is different from a choice name. The form user sees the label (e.g. “Yes”). Upon selection, the corresponding choice name (e.g. ‘1’, representing the “Yes” response) is saved to the database. - Data validation/edit check
Forms can flag values that fall outside of some range or otherwise violate some criteria set by the form designer. These criteria are called “edit checks.” When the user enters a value which violates an edit check, the system should alert the user with a clear message. Failed edit checks also give rise to automatic queries, or alerts for a data manager to review the value and confirm its accuracy with the user who entered it.
Pre-fabricated, standardized eCRFs
A given clinical trial protocol typically requires capturing the same or similar information about study participants as other clinical trials do. For instance, nearly every study will require data in the areas of demographics, medical history, vital signs, medications, adverse events, and other domains. As a result, standards such as Clinical Data Acquisition Standards Harmonization (CDASH) have emerged in order to provide study designers with structured and widely accepted ways of defining this information. This is especially helpful because it ensures that your data managers, biostatisticians, clinical research coordinators, and the rest of your clinical trial team are aligned on the standards you create. One simple example of this is the adverse start date. If your team agrees to the CDASH standards, the adverse start date will always be notated as “AESTDAT,” which is the standard acronym used by CDASH. Following these types of standards reduces friction among study team members by making these details abundantly clear and standardized amongst the team. And here at OpenClinica, we aim to always make the complex easy for our customers. To support this mission, we provide our customers with a curated library of pre-built fully functional eCRFs, aligned with CDASH and other standards, that you can easily tailor for use in your own studies.
Congrats! Now you’re ready to conquer more complexities of electronic case report forms (eCRFs)
Electronic case report forms (eCRFs) are a way for clinical data managers, researchers, and other clinical trial stakeholders to get better data, faster. To learn more about designing eCRFs, view our eCRF Design Guide to build forms that will: deliver the highest quality data, speed time to capture, enable the widest possible integration, facilitate robust and rapid analysis, and make regulatory submissions smoother.