By Ryan Bolduan and Kelsey Farley
Case Report Form (CRF) design has always been recognized as more of an art than a science. This design process has traditionally focused on site usability, which while relevant, sidelines data concerns that may lead to bigger problems down the road. Overlooking database development needs and endpoint requirements jeopardizes the ability to effectively generate study reports and/or the final report. This often leads to more time and money spent on data clean-up and worst-case, may require CRF redesign mid-study. Including a database developer in the CRF design process is the best way to mitigate these issues.
Database developers tend to view data differently than those who deal with patient data directly. When reviewing a CRF, developers focus on stored data (i.e. electronic records) and how the CRF interacts with those records. This review ensures that the CRF contains the elements that facilitate accurate and retrievable storage of the data. Developer recommendations primarily focus on the generation of accurate and efficient output and they often ask the question, “will CRF data be stored in a manner that can be easily retrieved and reported/analyzed?” Developers review, among other things, the interaction with other data, sufficient key field definitions, screen design, and the degree of automation required (i.e. edit checks).
Interaction with other data
Database developers also need to understand the interaction between patient data reflected on the CRF and other data such as core lab, randomization assignments, device accountability, and visit intervals. The complexity of these interactions can vary significantly depending on the study protocol requirements and database capabilities. For example, interactions can be as simple as linking a single, site-completed CRF with the associated electronic core lab data. Conversely, implementing a visit tracking system may require the linkage of multiple CRFs and study protocol specific information. Creating a system that enables these features requires an understanding of these needs. For example, to facilitate blinded randomization data, a database developer may recommend a separate randomization CRF in order to better utilize database security. By recognizing these data interactions, electronic systems can be implemented to remove the manual element of study management. This not only increases data accuracy but allows for automation and other efficiencies.
Key fields
Key fields are a fundamental concept in data storage and are critical for analysis as they differentiate unique subject records. Unfortunately, they are also one of the most overlooked elements of CRF design. Key fields appear on every case report form as site and subject identifiers. In the case of follow-up data additional identifier, such as the visit date may be needed. The more complex the relationships between records the more complex the key fields. For example, a serial number may be required on a form that is reported multiple times on the same date (e.g. Adverse Events and Protocol Deviations). In the case of an adverse event, re-using or re-assigning a serial number may lead to over or under reporting of adverse event data during analysis. Key fields are the most critical elements reviewed by database developers.
Data entry and edit checks
A good screen layout can facilitate accurate data entry. Database developers review CRFs to ensure that the question formats and layouts match the data requirements. For example, requesting race as ‘check all that apply’ instead of ‘check only one’ allows for reporting in a manner consistent with the regulations.
Edit checks can automate the data review process by identifying data inconsistencies. This increases data accuracy by removing part of the human element from data review. For example, if a protocol requires subjects receive treatment for a specific duration as an inclusion criterion, an edit check can add together all the times and provide a more accurate total treatment time as compared to manual review. Edit check definition relies on CRF layout and data formatting. If questions are asked correctly, developers can simplify the writing of these automated checks and produce fewer and more pertinent data queries. If questions are poorly designed, edit checks can be cumbersome to write and use which may result in false positive results, multiple data clarifications for the same issue, and/or missed data clarification requests.
Every database technology has different features. Understanding database capabilities and limitations is critical to ensure that desired features can be implemented. End users may not know the database capabilities and may not ask for the features which could prove useful. Interaction with the database developers will provide a bridge between study needs and database capabilities. The database developers will define the needed requirements and, with enough time, can adapt the database to do nearly anything requested by the project team.
Ryan Bolduan is a senior programmer analyst at RCRI. Kelsey Farley is a data management associate at RCRI, which has been turning project concepts into successful, revenue-generating businesses for clients worldwide for more than a decade. More than 400 companies – from entrepreneurial start-ups to Fortune 100 market leaders – have turned to RCRI for expert CRO services.
