Wednesday, August 1, 2012

eCRF Development for a Clinical Trial

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.

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).
As we develop eCRFs, if helps dramatically to read the protocol, understand the requirement and the reports to be requested as well as the statistical analysis.


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 
  About the author 
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.

Tuesday, July 26, 2011

How can standards help with reporting

Throughout my career in the Life Science industry, I always worked with data using multiple EDC/CDMS tools (Clindex, Oracle Clinical, ERT and Rave). Developing reports and creating study databases has always been part of my daily activities and one of the biggest challenges I always had was being able to map the same type of data across studies.

As we look deeper into how we can really gather data across studies, we find the true value of data standards. Lets look at a simple example within the Medical Device arena - every study uses enrollment date and procedure date. If the "Procedure Date" is designed different for every study using a different field name name (i.e. PROCDT vs. PROCDAT), then the standards are broken and we can not look at procedure dates across similar studies. However, if standards are developed and all studies use the same PROCDT as the field for "Procedure Date", then reviewing the procedure date across studies becomes simpler.

With that said, standards play a big role in being able to run reports across studies. However, there is a lot more work that goes into reporting across studies and more data points have to be identified in order to make this possible.

Back to our topic on standards, many companies are starting to recognize the importance of data standards, but are not sure where to start. Well for beginners, I would recommend to start developing the CRFs using CDASH standards. Keep in mind that while CDISC does not have an answer to every question, they provide a standard way for how it should be done.