UPDATED: This post was updated for 2019 to reflect new information and more examples. Enjoy!
This is the first in a series of two articles describing important points to consider when designing case report forms (CRFs) in an electronic data capture (EDC) system. When creating CRFs in a clinical study build, it’s important to ask the right questions, but it is equally important to ask in the right way. We’ll cover a few different types of fields in this post:
Dates on CRFs
Handling dates can be more involved than one would think. When asking for start and end dates on a form, the study designer needs to consider the possibility that one or the other may not be known. What if an adverse event (AE) is still ongoing at the time the subject ends the study? Should the end date of the study be used as the AE end date, even though the AE itself is still ongoing? Or should a checkbox be provided which enables the user to select ongoing? The answer to this question most likely requires consultation with the biostatistician. If one of the metrics being tabulated in the study report is the average duration of an AE, how would duration be calculated for an event with no end date? In this scenario, it might make sense to have the system auto-populate the study exit date as the end date, but hide it from the user as to not confuse them.
Here’s another point to consider: what happens if only a partial date is known? An example would be in collecting a study participant’s medical history. What if a patient remembers only the month and year of a medical procedure they had? Or perhaps they are only able to remember the year. How should the missing day and month be captured? The simple answer most study designers would utilize is a partial date field which allows users to enter only portions of the date. If a full (non-partial) date type field is used to collect the response, collecting part of the date can pose a problem. One possible solution is to provide CRF completion guidelines which instruct the site coordinator to use the midpoint value for an unknown day or month. For example, if the day was not known, a value of “15” (as the middle day of the month) would be used. If the month was unknown, a value of “6” (as the middle month of the year) would be used.
Another possible solution to employ in handling unknown dates would be to not use a date type field to collect the response, but to use three individual dropdown fields corresponding to the day, month, and year. The first value in the day and month drop-down list would be “UNK” (for unknown). While this would solve the problem of capturing an unknown day or month without specifying an “arbitrary” (as some would perceive) number of “15” for the day or “6” for the month, it introduces another challenge. The built-in date validation that a date control provides would be lost. A user can specify April 31, or February 29. If the selected year were a leap year, then February 29 would be okay, but February 30 would always be wrong. It may be possible to create conditional actions to validate the date, but this is a tedious task and would have to be redone for every instance a date was captured in this manner.
Again, asking the biostatistician what the date would be used for and how it would be aggregated and analyzed will guide the study designer toward the appropriate solution. If the date response needed to be processed as a date (by calculating duration for example), then allowing for the capture of “UNK” would be problematic.
A middle-ground solution would be to provide a date control, along with a checkbox that reads “Partial Date.” Checking this box would disable the date control and enable two drop-downs – one for the month and one for the year. Both of these would have a “UNK” option available. In this fashion, the site coordinator could specify either a complete date, or could indicate a partial date and enter a month and year, or only a year. Upon data extraction, these fields would come out in separate columns and the biostatistician would need to craft an appropriate process to analyze and generate the final listings and report.
Checkboxes versus choices on CRFs
Another regularity on paper versions of CRFs are checkboxes to indicate if something was done. For example, “Check if the test was conducted” versus a single select choice field with Yes or No as options. The latter option provides indication to the data management team that the question was addressed. The checkbox method, on the other hand, if left unchecked, could leave a data manager or monitor with the question of whether the question was skipped, or if the user actually did not complete the test.
Multiple checkboxes for multi-select situations on CRFs
Many platforms available for data collection in various industries allow users to add some form of multi-select field. The common issue with these is that they exist as a single data element collecting potentially multiple responses – versus a single select field which can always only have one response within the data point. The ideal solution for multi-response questions is to utilize multiple separate checkboxes, which each exist as their own unique data points, and to tie them together with conditional logic if you need to ensure at least one of them is checked.
Interested in seeing these scenarios play out firsthand? Request a product demonstration to have one of our product experts walk you through TrialKit’s flexible form builder features and functionality.
