Development of an eCRF can sometimes be tricky and an art at the same time. We each have our ways of developing a CRF and most of the ways are correct. However, one way of development can be very efficient in reporting and another can make it difficult and confusing. In order to develop an eCRF that is user friendly and that can be reported on effectively, the developer should have some understanding of the protocol and what analysis will be conducted.
When someone writes a document, do they type is in MS Word or Excel? Most likely it is created in MS Word. That does not mean that the user can not write the document in Excel, but to make it readable, the user might have to do further formatting and enhancement to the Excel file. While writing it in MS Word, not much formatting will need to be done. What I am trying to say is that using a standard format that is widely used by others saves the hassle and makes for an easier CRF to read and review.
In this section, I am going to address a couple of bad practice CRF development that I have seen in hope that others do not make the same mistake.
Wessam Sonbol is a clinical data consultant with over 12 years of experience in the life science industry focusing on clinical data management, database development and data management strategy improvement. Email: wsonbol@clinsysconsultants.com.
When someone writes a document, do they type is in MS Word or Excel? Most likely it is created in MS Word. That does not mean that the user can not write the document in Excel, but to make it readable, the user might have to do further formatting and enhancement to the Excel file. While writing it in MS Word, not much formatting will need to be done. What I am trying to say is that using a standard format that is widely used by others saves the hassle and makes for an easier CRF to read and review.
eCRF Development - Bad Practice
In this section, I am going to address a couple of bad practice CRF development that I have seen in hope that others do not make the same mistake.
- User creates Two CRFs for Adverse Event, one CRF asking if a CRF has occurred or not (just a yes/no question) and another CRF to record the event detail. This is quite a poor design that can create more queries than needed. In addition, it is an extra added step that is not needed. In most situations an AE CRF is only created if an AE existed anyway - so this will just create more work than needed.
- The protocol is requesting for Vital Signs to be captured during multiple visits. The developer creates a new Vital Sign page for each visit. This is when re-usability and standards can have a big impact. For example, if the Vital Sign section has already been created previously, then the developer can either remap or re-use what was already developed (depending on the system used).
How to be efficient
To be efficient in our design, the following steps can help;
- Create an eCRF library. This can increase efficiency dramatically.
- Re-use what the team has developed previously
- Use standards as much as you can - this will allow for better reports and faster development turn around time.
- Use the tools that the system provides to prevent the need for more edit checks and custom functions
Wessam Sonbol is a clinical data consultant with over 12 years of experience in the life science industry focusing on clinical data management, database development and data management strategy improvement. Email: wsonbol@clinsysconsultants.com.
