This is the second 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 1.
Capturing time points on a CRF requires some careful thought. If a series of time points are to be captured on a form, should a corresponding date also be captured? One might think not, since “they will all be on the same day.” But what if the time series spans across the midnight boundary? Also, should seconds be part of the data field? If the time points have to progress in a logical sequence, with one point needing to be after another point, it is possible that two time points can occur on the same minute. An edit check or Conditional Action would incorrectly fire stating that point 2 is not after point 1 if seconds were not captured.
There may be obvious blatant oversights in CRF design. For example, a form may ask for the systolic and diastolic blood pressure, but only provide one textbox to input the response. What is the user expected to do? Enter in the two numbers separated by a slash or a comma? If so, how would a biostatistician be easily able to analyze the data when working with the data extract?
Another common oversight in form design is to not provide all the relevant options for a dropdown list. It is important to consider the entire patient population and what may be a relevant response. Sometimes cultural or regional biases in CRF design make it difficult to fill in for particular subjects. Providing the option for “Other” in any list is a possible solution, but that introduces the possibility of getting a majority of responses as “Other”. How is “Other” to be aggregated and reported? If providing the choice for “Other,” it is generally a good idea to provide a “Specify” text box where the response can be further described.
What about the length of a text box? A form designer should provide enough room for the user to be able to enter a valid response, without providing too much space for them to put in unnecessary information. There is also a distinction between how long a textbox appears, versus how many characters it can process through scrolling.
Asking for “extra” information on the CRFs can also become difficult to handle. Often times, there will be an “Additional Comments” CRF that will get created. This is a carry-over from the days of paper CRFs when real-time communication between sites and sponsor was not possible. In the context of EDC, one must ask whether this is necessary. A guiding question to ask is, “What will be done with this data?” Is it going to end up on a summary listing on the submission to FDA or other regulatory authority? Is it going to be aggregated and analyzed in some way? If not, which is the likely answer, then why collect it as part of the study data to begin with?
This brings up the final point. If a data element on a CRF is not going to be aggregated and analyzed in the final submission and if it is not even going to be included in a summary listing, then it should probably not be placed on the CRF to begin with. Extraneous information often generates unnecessary queries, adds to the time and cost of monitoring visits, and yet provides little or no value in the end. Further, this is often done to provide the site coordinator with a set of steps they can follow. Plenty of “yes/no” style questions or check boxes end up on CRFs to guide the site coordinator through a set of steps. These should not be placed as fields on a CRF; rather. they could be included on a work instruction or training procedure.
When designing CRFs, it is very useful to consider whether or not the data elements are going to be analyzed or part of a summary listing. In doing so, a number of unnecessary questions can be removed, which leads to more accurate data and less confusion on the part of site coordinators. Combining thorough User Acceptance Testing (UAT) with meaningful data extracts to allow for the capture of a range of data is an empowering exercise that can lead to better CRF design. Typically, it has not been possible to get such broad access to EDC functionality unless you are a programmer. That is, until now, with the availability of Clinical Studio. Get started today with a 30 day trial and experience the rich functionality of a fully-featured EDC for yourself.