Taking the plunge

pharmafile | December 10, 2004 | Feature | |   

When prompted to do some forward thinking, I often start by looking back. In 1999 I was an evangelist for electronic data capture, telling everyone that in five year's time, most clinical trials would be using it.

Here we are in 2004 and although reliable figures are hard to find, the mass migration away from paper hasn't happened. However, there has been growth in EDC, enough to be able to assess where it is making inroads and where it isn't.

Going even further back, EDC was included in the original FDA Good Clinical Practice guideline in 1977, despite limited technology in those days. The thinking was based on physically large mainframe computers, which were all that anyone had access to then, apart from a very few primitive micros. I still have a Sinclair ZX80.

If electronic data use was being recommended so long ago, why has it been so slow to catch on?

Part of the reason can be found in the FDA guideline itself. In 1977 the FDA insisted on all data being printed out and signed. I don't know if anyone actually did this, but it would have been enough to put anyone off. Unfortunately, it set the scene for decades of Ludditism and mistrust of anything not written down on paper. In reality, the technology has advanced far faster than the users have been prepared to accept.

Real or imagined objections?

Today, most written communication is via e-mail, which has as much credibility and authority as a piece of paper. We accept e-mail as binding, just as we did a wax-sealed letter a century ago.

However, governments are embarrassed, and careers cut short, because of leaked e-mail.  

E-mail is usually not very secure (hence the leaks), while sound EDC systems are immeasurably better in this area. Yet, for some people, security is a problem and these issues illustrate that resistance to EDC is rather more emotional than rational, something I find strange.

Probably the most rational measure of success in business is return on investment, and here we are seeing some real success stories. Companies such as Novartis and Pfizer report big reductions in data management costs using EDC, but most importantly, they can slash development times.

The area of conventional clinical development of which the drug industry should not be proud is database verification, which traditionally can take months, yet I have seen EDC achieve it in two working days. How is this possible? It's not only a matter of replacing the old paper technology with the new electronic one, it's a question of re-engineering the organisation for a new way of working.

Can you stand the heat in the EDC kitchen?

Therein lies the cultural challenge. In 1999 someone said to me: "But if I take this on, I shall have to make all my data management department redundant."

He had it in one, although with all the downsizing going on these days there might not be as much resistance today as there was then. No, the main problem is having to move outside the comfort zone.

The change means that the whole data quality process moves upstream. Instead of cleaning up the mess at the end, much logical thought has to be put into upfront design, including validation rules. This needs a major change of roles.

The traditional clinical research associate no longer needs to spend any time on checking data on paper (why are we paying science graduates high salaries to act as clerks?). But we do need their insight into the clinical trial process to enable good design of the EDC system.

Of course, this means that more effort is required at the beginning of a study, an objection commonly thrown at EDC. It is true that earlier systems (and I suspect some current ones) required a lot of specialist programming before they were up and running.

This might lead to a longer lag before your study can start. But recent years have seen the emergence of much more intuitive design tools, which require fewer specialist skills.

Spoiled for choice

This is changing the way EDC is implemented. From an organisational perspective, there are different ways you can do it. You can pay someone for a turnkey solution, in which the software, hardware hosting, system design, training, and user support are all bundled together.

This is favoured by small customers who don't have much internal resource. At the other extreme, you could simply buy a licence for the software and host it on your own web server, and provide all the other functions yourself as well.

Some major drug companies have taken this a step further, and have written their own EDC software. This avoids licence fees, which can mount up rapidly in large pivotal studies.

An intermediate position is offered by some vendors, who provide web-based systems which include simple drag-and-drop form design subsystems, all hosted on their servers. Some of these companies are however very small, and won't offer the user support that many customers will need.

This means that there is an ever-changing and incredibly diverse range of EDC products out there. This has been driven by the emergence of the internet as a business standard. To be brutally honest, it is extremely easy to design web forms these days, so easy that it has attracted many organisations who may not have an in-depth understanding of drug development, making the choice of vendor difficult.

Demonstrations by vendors can be poor value in terms of wasting your time. A few weeks ago I was asked by a client to sit in on a sales demo. To cut a very long story short, that's exactly what we had to do – cut it. After nearly three hours of being shown every function which the sales person wanted us to see, whether we wanted it or not, we cried: "Enough!". 

Ironically, we had invited them in because we liked their system, but our enthusiasm steadily cooled as the presentation went on and on and on. What interests me far more is talking to existing users. This is difficult for the start-up vendor, as they won't have any users yet, which means that they have to be even more sensitive to their prospective client's needs – they must listen more than talk!

Sizing up new vendors

I would still resist a sales presentation from new vendors. They should be able to provide an evaluation system or a temporary log-in, so that we can play with it and find out if we like it.

If we are buying bundled services as well, we would need to visit their operating headquarters to talk to the support staff – yes, we would really have to prove that they exist.

Another company being considered as an EDC vendor by one of my clients had very prestigious premises in an expensive locality, but there seemed to be very little going on. There were a few people sitting at computers, but desks were suspiciously clear.

This should ring alarm bells. Even if the company is so new that they have almost no customers, everyone should be working extremely hard to get them. I know, I have been on that side of the fence.

Data security encryption sets standard

I don't have enough space to give you a complete checklist of functions you should seek in an EDC offering, but I can revisit the major objections and show how these are being met today.

Let's look at data security. Data encryption is now so secure, that the breaches which are occasionally publicised (usually of banking systems) are never because anyone has 'cracked the code'.

Dual key encryption, which is now industry standard, uses as the decryption key a prime number 128 binary digits long.

To break the cypher, you have to know the number, and it would take the most powerful computer millions of years to find it. No, these breaches are usually because someone has found a password and this is in turn largely a result of carelessness.

But do be aware, that when someone says they are using 128-bit encryption, they should be not only encrypting data in transit, but also storing it encrypted on the server. This protects against hacking. Having said all this, I am not aware of any significant breaches of security for any clinical trials using EDC.

On top of these measures, many new technologies are being used to improve data security and accountability, and it is not the purpose of this discourse to describe these. Suffice to say that EDC is orders of magnitude more secure for clinical trials than anything you will do on paper.

Integrated systems and business benefit

You will also want to know whether you can readily integrate your EDC data into your existing systems, and most informed people will be aware of major moves to standardise data formats. Ideally, I would be looking for CDISC compliance, but at least a validated transfer into my own database type; for most drug companies this will be Oracle-based.

Will you want to use EDC for your whole programme? I would certainly not advise a 100% roll-out for all new studies, without some careful piloting. The questions are: Which studies will provide the most realistic model and confer the most business benefit?

Some companies will be reluctant to entrust their pivotal phase III studies to new technology, although clearly if it all works out well they will get the best return on investment from those.

Cost savings

Cost savings will also be much larger in these studies, because of scale. There is, though, recognised growth in phase IV studies, probably driven by companies having to wring more value out of existing drugs in an environment of far fewer market launches.

These will also be large (often much larger than in phase III), with case report forms which are fairly simple. They will also bring fast marketing payback if they can be completed and reported early (no need to wait for a product licence unless you are extending it).

A good example is the INVEST study conducted by the University of Florida, which used EDC for a multi-country cardiovascular protocol involving some 20,000 patients.

This is not to say that you should not try EDC on early phase studies, but these can be complex (eg, multiple blood samples and vital signs assessments for pharmacokinetics), and are necessarily of small scale.

The type of study you choose may influence the type of EDC system. I will declare a prejudice now, and say that I prefer online-only systems. This means that an internet connection is always needed to use the system. Some EDC software is still quite slow, however, so broadband is preferred, rather limiting the sites you can select.

Not a problem for UK hospitals, although I won't go into the pretty arcane constraints of the NHS network! The big plus for online use is that you have no remote software to support – everything you need is on the server. No problems with version control, or delivering upgrades, because users only need a web browser, which is free. They don even need any particular type of computer it can be PC or Mac or Sun, and can run on Windows or Linux, to name but a few.

Increased control and real time access

The big minus is not in practice as big as it looks, and that is you are a bit stuck if you lose your internet connection. It is a risk, but my own office connection from one of the UK broadband providers is remarkably reliable.

It's for this risk that off-line options are available, and they do give you more confidence in not losing data, because data may be saved to the remote machine. The problem is in prompting investigators to upload – if they don't log on, you have lost control. Control is one of the main reasons that I first became involved in EDC back in 1998.

Suddenly, it gives you real time access to what is going on in the field. You can pick up quality problems as soon as they happen and take project management decisions without having to guess whether you have made the right choice.

We are now moving into a new arena of integrated clinical functions, where the same management data is no longer entered into multiple systems; enter once, use many times.

EDC is just the engine that drives the management system. This isn't a new idea as I published it in a book in 1996! The question is: Who is really doing it today?

By Les Rose