This is the first in a two part article describing important points to consider when designing Case Report Forms (CRFs) in an Electronic Data Capture (EDC) system for use in a clinical trial. Click here for Part 2.
When designing CRFs, it is important to ask the right questions, but it is equally important to ask in the right way. 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. For instance, what if an Adverse Event is still ongoing at the time the subject ends the study? Should the end date of the study be used as the Adverse Event end date, even though the Adverse Event itself is still ongoing? Or should a check box 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 average duration of an Adverse Event, how would duration be calculated for an event with no end date? In this scenario, it might make sense to put the study exit date as the end date.
Another point to consider is: what happens if only a partial date is known? An example would be in collecting a 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? If a date type field is used to collect the response, this 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 day or “6” for 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 check box that reads “Partial Date.” Checking this box would disable the date control and enable two drop-downs – one for month and one for year. Both of these would have an “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.
You can investigate all these scenarios yourself by registering for the free subscription of Clinical Studio and experimenting for yourself. First-hand experience is the best way to work through these issues, so get started today and take advantage of all the available documentation that explains the different controls available in the form builder.