EDC Study Startup Time

EDC Guru left a comment on the Top 10 mistakes made when implementing EDC posting.  In this comment, it is suggested that one of the potential failure areas is not leaving sufficient startup time when switching from Paper to EDC.  I fully agree, although, from a sales perspective, the alternative is the sponsor goes to another CRO or Vendor that will offer the required timeline.

If you speak to an EDC company, one of the metrics they often pride themselves in is the time to First Patient In.  12 weeks, 10 weeks, 8 weeks or even 6 weeks are banded about.  This is clearly a metric worth considering, but, what actually is included in these weeks?   Is that how long it takes the vendor or CRO to *do* the study build, or is that how long it takes for a sponsor to be ready for EDC.

I would put forward that any sponsor company that goes from no experience to executing EDC studies in 12 weeks will not demonstrate the full benefits with EDC. In fact, there is a danger that the experience will be sufficiently poor as to impact the ongoing acceptance of EDC in an organization.Unwisely implementing EDC can result in similar metrics to paper studies, but at considerably extra cost.

So - what is the solution?  Do I think that drug programs be delayed for the benefit of EDC technologies?     Well - no, but, should an EDC based study be delayed until the organization is sufficiently in tune to the experience - yes.

So taking the above as accepted, what are the boundaries to achieving a better prepared company?

1). Senior Management within sponsor organizations will measure the success of a drug development program but the compounds that go in the various phases of study.  Placing a delay in startup will appear like a failure

2). It is very difficult to develop effective EDC processes :-

• Sponsor companies new to EDC do not have the experience to determine where the eClinical tools brings benefits and where other methods are better.
• Vendor companies tackle the process problems from the perspective of technology rather than by tackling the actual business requirements.
• Consulting companies deliver non adventurous palatable process solutions based on regurgitated generic concepts.

3). Silo structured organizations may not offer broad department support for process changes that will make a company wide eClinical approach successful.

 

Ok, so I have managed to point out 3 potential problem areas, so, what is the solution.... or rather, what is my take on a potential solution?

1) Senior Management -

the measurement of success is as important as the success itself.   I have seen this attempted, but I have not seen a lot of success.  If everything changes, how do you compare 'apples with apples'.  If nothing changes, then what is the point. You need to look for the lowest common denominator. Faster development, lower costs is a start...

2) Processes -

How many readers go along to DIA or similar conferences, and either avoid, or sleep through Process topics.  That is a shame, as it is still the Process, Workflow and Change elements of eClinical that are causing bottlenecks.

You get Technology Guru's that create brilliant eClinical systems. Why not empower a Change Guru that 'gets' the technology and 'understands' the potential for changing an organization.

3). I have just answered 3) with 2).

So - back to EDC Guru's comment.  There is a place for rapid start EDC where the vendor or CRO acts just as they did for an old Paper study, and takes on the bulk of the work to make an effective deployment.  Some benefits will be realized, but certainly not all. I don't think the term 'Start Up' should be defined as study start up.  It should implementation program start-up.  A study will appear, down the road, but, not in the same sentence.

Open Source eClinical - Myths & Facts

I came across a blog / article posted by here that provides a Q&A with Ben Baumann of Akaza Research.  On reading the article, I feel obliged to respond to some of the comments made. 

First of all, I believe that Open Source based systems do provide a valid alternative to closed source products.  I have both developed, and used Open Source systems in the past. Both Open and Closed Source based systems are designed to create a financial return for the companies that develop and support them.  With the Open Source model, the revenue comes from support and consulting with the reduced cost of development shared across a number of organizations.   With Commercial software, revenue comes from licenses, support and consulting.  The cost of the development is higher, but, this cost is typically covered by the corresponding license revenue.

Back to the article. There are a few points that jump out at me as arguments for OpenClinica;

In addition to a full set of EDC and CDM features one might expect in such a system, OpenClinica has  built-in features that give users the ability to set-up their own studies.

Any EDC or CDM system worth their salt will provide functions that give users the ability to setup their own studies.  Good systems will also ensure that an absolute and clear separation is maintained between the configuration of the study and the tool itself. If the tool has to be modified in any way, then you have a validation nightmare each time you run a study.

In short, an organization can make a rapid and highly informed decision whether or not to use OpenClinica without having to go through lengthy vendor-biased demonstrations and negotiations, and rely on a vendor in order to get their studies configured appropriately.

Well... instead of going through a demonstration that presents the features of the product, the user really needs to start digging into the source code to gain a good understanding of what goes on. So, as a user you need to have a good understanding of fairly complex 3rd generation language programming.   To fully understand how a tool works takes some time. For large EDC or CDM systems I would put that estimate, for an experienced programmer, weeks if not months of detailed analysis. 

Enhanced validation. Validation can be much more thorough with open source software. Buying proprietary software is like buying a car with the  hood welded shut-you don’t know what’s really know going on behind the scenes. Open source provides the highest level of transparency making it possible to truly validate a system from end-to-end.

"Oh! so I need to validate the system myself?" Validation is complicated and expensive.  All systems in the eClinical world require that the development runs within a structured process. You generally need to maintain a trace-ability matrix that takes the software through a lifecycle from specification through to coding and on to completed and recorded testing.   As with InHouse systems, maintaining this will can be challenging

Typical eClinical systems split the code product, that is developed and validated, from the configuration of the product. That part is typically just 'tested'.  In the situation, you don't need to re-validate the software product following a configuration of the product for a particular deployment (i.e. Study).  The validation of a full EDC product might take 200 man days. The testing of a configuration might only take 10 days.   If you mix the configuration with changes to the core software product, you need to be very careful that you don't compromise the core product validation.

As I said at the start, open source solutions have a place in the eClinical business area.  They can be the right solution in certain circumstances, but, they are not always suitable.