Good online systems do not use paper paradigms. In this post – I will try and entertain you with historical perspective and quantitative tools for choosing an EDC system for your medical device study.
Decades of common wisdom in clinical trials still hold to a paper-based data processing model. One of the popular EDC systems talks about the advantages of having online forms that look exactly like paper forms. True – familiarity is a good thing, but on the other hand a digital UX has far more possibilities for user engagement and ease-of-use than paper. So – it is, in a way admitting failure to provide a better UX and downgrading to paper.
We recently engaged with an Israeli medical device vendor who has an innovative device for helping solve a common medical indication for men over 50.
I won’t go into details.
If you are a guy over 50, you know what I mean.
If not, it doesn’t matter.
The client CEO was interested in an eCRF (electronic CRF – case report form) system. eCRF is better than paper, but it is, at the end of the day just a paper form in an electronic format.
I was having a lot of trouble trying to understand the CEO’s business requirements. My attempts to steer the conversation to a discussion of how to obtain fast data for his clinical trial and reduce his time to FDA submission fell on deaf ears. A follow up conversation and demo of Flaskdata with the clinical and regulatory manager focused more on reports and how to manage queries. Queries are a vestige from the paper CRF period, where a study monitor would visit the research site once/month, compare the paper source with the electronic data entry and raise queries or discrepancies.
In order to put this process into a historical context, let’s compare accounting systems from the late 70s, early 80s to an eCRF system.
Accounting versus eCRF
|Feature||Accounting circa 1970||eCRF circa 2019|
|Input data||Paper JV – journal voucher||Paper source|
|Data entry||Data entry to a 2-sided accounting system||Data entry to an eCRF|
|Data processing||A batch job, processes punch-card data entry and produces a data entry report and data error report||Site coordinators enter data to a Web app 1-3 days after the patient visit. Data entry errors or invalid data create data validation queries which are ignored until the study monitor visit a month later|
|Exception reporting||Data error report – with non-numeric or invalid dates||Queries|
|Management reports||Trial balance
Profit and loss
|Bean counters of CRF/items
What is profit and loss?
What does a cash flow model have to do with clinical trials?
Cost justification and TCO for medical device EDC systems
My first recommendation would be don’t buy an EDC system just because its cheap. Charging $100-300/month for a data entry application is not be a reason to give someone money. As a client of ours once said – “I know I can use Google Forms for data entry and its free but Google Forms does not have an audit trial so Google Forms is not an option for clinical trials”.
As a rule-of-thumb, a good EDC system for medical device studies should include audit trails and a clinical cash flow report (the flow of patients in and out, the flow of data items in and out). The EDC should also be able to produce a clinical Profit and loss statement, showing you how well you are doing on your primary and secondary efficacy and safety end points. A well-designed and well-implemented EDC should include a robust data model for testing the primary endpoint and collecting safety data. At the minimum, a solid design and implementation will cost at least $10,000. Over 10 months, that’s a starting cost of $1000/month. As Robert Heinlein said – “There is no such thing as a free lunch”.
Your decision to buy EDC should be based on an economic breakeven point. One breakeven method is based on cost reduction in site monitoring. Assume the EDC system costs $4000/month (weighted cost including implementation) and assuming a monthly site visit costs $800/day, then your EDC system must be able to save 5 site visit a month and assure protocol compliance. This places an upper bound on the price you can pay.
This is albeit problematic for small, 1 site studies which often use DIY implementations. Just remember, that ignoring the implementation cost, does not make the product cheaper. In other words calculate your TCO (Total cost of ownership).
Or as one wise man one said – I’m too poor to buy a cheap car.