Clinical research form specification, programming and validation: Why do we make it out to be more than what it really is?
I was recently forwarded a LinkedIn conversation debating the value of validating the study specification document before beginning the Clinical Research Form (CRF) development process. While I agree this capability would be a tremendous asset to the clinical team, I don't think it goes far enough in simplifying clinical trial start up. The approach may reduce the rounds of user acceptance testing (UAT), and will almost guarantee the study team is thinking about the CRF design and edit checks earlier in the process, but this approach does not reduce the need of the study team to perform detailed line-by-line UAT's of metadata, CRFs, and protocol specific requirements.
At the end of the day, we need to make sure the output still matches the specification no matter how many rounds of validation the "spec" went through. A much better solution would be a simplified approach utilizing supporting clinical trial software that is streamlined for efficiencies and made for the person who knows protocols but doesn't necessarily know how to program.
I am of the opinion of: "Why build a specification when you can create the specification and build the Electronic Data Capture (EDC) implementation and validate a vast majority of the study specific requirements at the same time." Fortunately for me, BioClinica has developed tools that make this vision a reality, thus simplifying clinical trial start up.
If you are reading this you are most likely aware our industry has its fair share of Build, Design, Architect and Load tools. Whatever the name, these tools basically do the same thing for a given EDC system. They require a person to program study-specific implementations based off of requirements provided by a study team. They are typically provided in any one or more of the following formats: excel, word or pdf. The really advanced tools may produce an XML file, however, they are typically pulled together from separate Build, Design, Architect or Load tools and then must be massaged to work in the target system. Most systems require a person with advanced programming skills while some systems don't require any programming skills at all.
Simple Clinical Study Builder Tool
BioClinica's Study Builder tool requires only one real skill: the ability to read and interpret the study protocol. After a few days of training, users are ready to specify, program and validate the study CRFs, metadata and time and events schedule. In fact, I was giving a demonstration of the BioClinica Study Builder tool during our Users Group meeting when a person in the audience commented, "I apologize, but it looks so simple a monkey could do it." My reply was rather straightforward when I said "Thank you!"
The "Why spec it when you can build it?" approach has been at the core of BioClinica's products since their inception in the late 1990s. Basically what that means is that we view Study Builder as a specification, development, and validation tool all rolled into one. Think about the time that is wasted as a data manager fills out a specification document and passes it along to a programmer who then passes it along to a QC person who then notifies the data manager who performs UAT against the specification who then forwards to the study team who performs a more robust UAT against the protocol. This process is repeated over and over again until all parties are satisfied. The BioClinica approach allows for more time to make decisions based on science rather than a deadline.
In order to achieve this level of efficiency, BioClinica utilizes CRF libraries that are metadata driven and highly standardized and controlled. A typical field on a CRF may have up to ten validation checks ranging from the CRF question to its position in the export table. During the initial build, the user takes advantage of the re-usability and produces a specification(blank CRFs, metadata tables (normalized and non-normalized), code list tables and study workbooks), EDC implementation and a validation report which includes items that are not "standard." Unfortunately the non-standard items must go through a manual QC process along with manually reviewing the content to ensure the protocol specific needs were met.
Over three quarters of all trials conducted using BioClinica Express in 2011 used this approach. On average, we automate 75% of the validation, leaving the study team that much more time to focus on the protocol.
So back to the LinkedIn conversation. I do see the value in validating the spec, but only if it is a byproduct of the build. As I stated before, "Why 'spec' it when you can build it?" If you are interested in this approach or learning more about how BioClinica can help you in simplifying clinical trial start up, please leave a comment below.
Learn more how you can simplify your clinical trial start up using EDC. Download our free white paper on the "8 Secrets to EDC Success."