This post is not for the Pfizers, Novartis, Merck and GSK giants of the life science industry.

Its for the innovators, the smaller, creative life science companies that are challenged by the costs, the regulatory load and complexity of executing a clinical trial.

This post is dedicated to the startup entrepreneurs of the world.

Building an EDC system for your clinical trial requires executing a plan in order to successfully recruit patients, collect high quality data, sustain patient safety and produce your statistical report in a timely fashion. You can potentially embark on an EDC journey without a plan, without a simple, well-designed protocol, and without appropriate clinical monitoring. This will guarantee you a long trek of pain, burning cash while you resolve issues and clean data.

The pivotal question to any clinical decision maker is this: Do you want to start building an ECRF (electronic case report form) now and pay in pain and cash later, or plan now and own the process?

Simple concept, but important message.

It doesn’t matter if your business is a one-person startup or a “Big Five” bio-technology company. If you develop medical devices, medtech, biotech or drugs on a daily basis, you are faced with an increasing stable of competitors, and barriers to success that can frustrate you as a business manager or a startup entrepreneur trying to make payroll.

Being an entrepreneur like you, I’ve constantly been exposed to walls that have continuously tried to prevent me from success. In this post, you will learn how to plan and execute EDC quickly, efficiently and successfully and break through the business, clinical and regulatory barriers that stand in your way. In a world where competition erodes market share, depresses product pricing, and where large company branding and marketing tramples the innovative medtech startup, the key is not first to eCRF the key is smart to market.

So – here are 2 factors to consider to help get you faster to the finish line.

Number 1 – Features are necessary but not sufficient. Focus on your must-have functionality, not the vendor features

Animated graphics in an eCRF may look pretty, but they are not going to help your study run any smoother or deliver the results the study is aimed at achieving.

DIY CRF GUI builders are great and may enable a person on your clinical data management team to build a study in a week or two. But the apparent speed and convenience of DIY CRF builders are really a fallacy.

Your first study will take 9-12 weeks to build and validate.

This is because you are inexperienced. Only 2 weeks out of the 12 is for building forms, the rest will be spent testing, fixing bugs, fixing your mistakes and assuring that the flow fits the study protocol.

DIY form builders in the hands of unexperienced biologists may in a data model with fundamental bugs that will prove near-fatal in the statistical analysis and require expensive and time-consuming rework for data preparation.

Putting aside form building for a moment, here is what you need to consider:

– Build a robust data model (does it contain the right data elements you need to prove your primary end-point)?
– What about the study protocol? Does the eCRF that your junior staff member just built conform to the study protocol?
– Consider validation. You must perform V&V on your implementation. Preferably performed by an independent third-party
– What about extracting data for statistical analysis?
– What about clinical operations? the cost of setting up sites, user access management, blinding, cross-CRF edit checks and more?

Number 2 – Link EDC features and functions to time to market

EDC systems are essential tools for saving time and money in your clinical research,
but there can be too much of a good thing. In the software world, this is called “feature glut”. If the primary goal of implementing EDC is to reduce clinical data management costs, increase data quality and speed up time to statistical report for an open-label medical device study, then you do not need drug inventory and randomization functionality.

Key factors you should consider in your EDC product selection and implementation include:

– Modules – can you pay for the features needed and not more?
– Support – Is the EDC vendor capable of providing a bespoke solution, including integration with your medical device API?
– Pricing and packaging – How does the vendor price his product? Do you pay extra for more users, sites, studies and data?
– Pure play software or a murky mix of services? Are you working with a bio-statistician that offers you data management and EDC on the way, or a data manager that offers you bio-statistics and a “preferred” EDC system or a CRO that offers you a package deal with his own EDC? Can you unbundle the software product and professional services? Can you start simple, and add features as needed with vendor collaboration during design.
– Usability design – consider who your users are. Your guiding light should be KISS – “Keep it simple stupid” and remember that the most elegant scientific experiments were the simplest. Better 5 forms than 3. Better 3 fields than 13. Better 3 options than 23.
– Customer feedback -talk to other users of the product? Ask them what they liked, and what they disliked. Talk to site coordinators.
before you talk to managers. Make sure you talk to a hands-on person.
– Do you require PRO – patient reported outcomes? Apropos usability – factor in whether or not you need patient-submitted data during your study. Patients are hardly professional clinicians, so the simplest CRF design will be the easiest way for patients to submit reliable data.
– Look ahead. Are you planning a series of studies? Generally sponsors will execute a series of research studies of varying degrees of complexity, but more often than not, especially if a smaller startup company is involved,trial complexity is progressive rather than regressive, study after study.
– Look ahead again. How long will the study take?
Time and money is saved for sponsors when the needs of a study are communicated
to the vendor, and software features are added, rather than deleted. Take for
account the example of data storage space: if your study is going to be less
than a year and involve only a couple dozen subjects, likely you will not need
an EDC system with unlimited data storage, and can save EDC costs with a finite
amount of storage.
Advanced features, such as unlimited study sites or unlimited EDC users, can always be added on an as-needed basis. Just because a vendor has designed myriad software features, it does not mean that your study will use all of them. Building an EDC system from the bottom up, rather than top down, ensures that only the essential features for your study are included in the software.
– Negotiate. Take advantage of the competitive, global EDC landscape
Being that EDC designed for clinical trials has been in use for over 15 years now, there are vendors popping up on a seemingly weekly basis, all competing with each other to win your business. The absolute lowest cost, baseline EDC system may not necessarily be the best option for your clinical trial, but many vendors can offer robust and study-specific systems at increasingly competitive price-points (FlaskData.io offers cloud EDC solutions, which feature integrated risk-based-monitoring, for 30-50% less than competitors who are providing EDC only).
With SaaS cloud EDC, vendors can be headquartered or use development and support teams in less costly geographic locations. If your study is being conducted in New York, why not save costs on using an EDC system developed in the Middle East or Southeast Asia? Costs of labor may be much lower in many instances, without losing on sophisticated software design and support. After all, the Internet and code development know no borders.