“Like the “old” Internet, social networking’s value to clinical development will take some time to realize.”

Given the trendy and transient nature of technology fads, I thought I would try and write about social networking’s potential in clinical research before anyone beat me to it. The potential for the technology platform and principles of use which underlie social networking to empower parts of the clinical development process is definitely strong. Unfortunately perhaps, pharma’s track record in adopting new information technology, in the clinical phase at least, is abysmally slow.

Social networking, for those who don’t have teenagers and are over 35, is the most ubiquitous manifestation of “Web 2.0”, where the Internet takes over key elements of our personal and business transactions in elemental fashion, instead of being only a tool in the corner of the room we take out and use like a super-powerful hammer. Social networking is the generic term for sites like Facebook and MySpace, the latter of which in particular is being broadly exploited by those in need of networking (public relations agencies, job-seekers, politicians, real estate agents), for whom it provides literally an exponential benefit. The concern, for clinical research professionals, as it was with the “old” Internet or any other IT innovation, is how is social networking relevant to our work, how do we properly control its use without undermining its benefits, how do we exploit it in unexpected ways that are directly beneficial to the special work we do?

Superficially, the interface and functionality of social networking sites may seem familiar and crude to a corporate user. These tools supply an email analogue, bulletin boards, news feeds, multimedia sharing, document exchange, and other features which corporate users are used to having in a more silo’ed and structured fashion. For the inventors and initial beneficiaries of social networking, those attributes are secondary – they are handy extras to use on a site which is really designed for, well, networking. This is networking in the sense of “old boy networks”; it’s about creating networks gloriously independent of, and unimaginably more specific than, the “old boys” – a truly democratizing (and at the same time, fragmenting) revolution in connecting people, literally worldwide.

Our colleagues in the discovery side of pharma have been exploiting early forms of social networking for some years, such as sharing “wikis” on various specific topics. (A wiki is defined as “a website or similar online resource which allows users to add and edit content collectively”.) Wikis seek to organize information better than the sharing of “blogs” (usually linear writings of a single person on potentially multiple unrelated topics) or discussion forums (originally called “bboards” in the early days and later “threads” – especially if you were/are a Lotus Notes user). None of these Web 1.0 media contain the basis of social networking’s power: the endless linking, de-linking and re-connecting of individuals around the world at digital speeds based on having something in common.

By its nature, social networking is at first glance very problematic for application to clinical research. Clinical research must live in a regulated environment and adhere to the rules of science, not randomness. While serendipity may be at the heart of most of biopharma’s success in the largest sense, we try to avoid serendipity in the details! But what if this essentially new medium can be controlled or steered in a manner which we can benefit from? We need to learn from pharma’s initial rejection of the Internet (a sometimes vociferous rejection whose echoes can still be heard in the corridors of our companies) and suspend our knee-jerk compliance fears until we’ve explored the possibilities fully. Let’s look at two of these possibilities: patient recruitment and trials management.

Discovering Our Subjects

How is social networking different from a Web portal – a “Web 1.0” concept which is still very underutilized in clinical research? Web portals can have all the same functionality accessible to us through a single screen, albeit only with the design and support of lots of IT resources. Social networking’s distinguishing characteristic for us, in this context, is its “discovery” component. Discovery goes beyond the Web 1.0 concepts of “push” (subscribing to news feeds to your desktop) and “pull” (EDC, to use a clinical research example). A recent Wall Street Journal news item about social networking developments gave a great example of discovery: a new Indian restaurant in the suburbs used MySpace and the town’s “network” to discover who had listed Indian food as something they liked. The network was set up in such a way that the restaurant could make itself known to these eager diners, and the result was a level of targeted communication previously impossible to achieve in an open marketplace.

Taking off from this example, an obvious, immediately applicable, use of social networking is for subject recruitment – the most notorious shortfall in clinical research today. Investigative sites, research businesses, academic centers, and CROs can and should all be looking to exploit this new medium to make that essential, informed connection between we researchers and the subjects we require, the patients who can benefit. It is not costly, it is fresh, and the more it is used in daily life, the more likely this can be used in clinical study recruitment. This is much like what happened with the initial objections to Internet-based EDC: the argument that “the study coordinators will never use the Internet” gave way when pharmas realized the coordinators all went home at night to shop on eBay.

But like the “old” Internet, social networking’s value to clinical development will take some time. Fortunately, positive feedback loops in social networking (so-called “viral” networking) operates at Internet speed, so as people tell other people that listing a medical condition or disease interest on Facebook (or wherever) leads to rapid contact with new therapeutic opportunities (in clinical trials), more people will include this information in their profile (certainly the motivated ones, who are those we are looking for in the first place).

Note that all this does is bring a potential subject to the awareness of the site (but of course, that’s all most any patient recruitment scheme does). All of the rigor of informed consent, protocol inclusion/exclusion criteria, and proper site procedures and approvals will still apply. Subject protection and study design rigor are not affected by the magic of MySpace, but making the first step faster and more efficient would be a great boon.

Communicating with Our Faces

Maybe, although not necessarily, social networking will prove to be a more used (usable, accessible, worthwhile) means of communication in clinical trial conduct, at all levels: sponsor to subject, investigator to subject, sponsor to investigator, and more. And perhaps this technology or format will be more useful internally at pharma as well, replacing more static or IT-maintained study portals for the study team. As always, all of these audiences need both general education (on the disease, on the study protocol, on procedures) and news (status updates, alerts to changes, good developments and bad, progress and performance metrics). This is what needs work before social networking makes sense for clinical research: we aren’t dating or job-hunting, we’re trying to learn. Can social networking help us learn? Maybe so.

Is a social networking “wall” better than a dashboard for communicating study metrics? Intrinsically, from a technical standpoint, it is probably worse, but if people use it more – read it sooner, report to it sooner, gain insight from it faster – then it won’t matter. The ultimate value of social networking (in general and in clinical research) will always come to “what’s in it for me”. Since today’s highly complex CTMS’ (clinical trials management systems) are notoriously underutilized at great investment costs, trying something new (and much cheaper) has to be worth the experiment.

The lessons we’ve learned from other clinical IT innovations apply here:

Implementation is more problematic than technology

Getting data out is more valuable than getting data in

Governance and control of how the technology is applied is crucial to success.

I can hear the objections already, so let me list some now. Any tool which adds more email to our day is a disaster. Bulletin boards are filled with recipes and fatuous exchanges about last night’s TV episodes. We’ve already spent years developing “e-Rooms” full of “shared” documents no one is reading. Absolutely true. The only point of social networking is if its unique dimension adds more value than it destroys.

There are subtler implications of social networking that pharma may not enjoy. At present, most sponsors have to help sites find patients for studies, sometimes at considerable expense in advertising and other forms of outreach. If social networking makes it much easier for sites to find patients, is this another way that the power relationship between sponsor and site shifts away from the sponsor and to the site (like EDC shifting data possession to the site)? And there is already tension between patient self-advocacy on the one hand, and the scientific requirements for rigor on the other hand. Will the heightened level of information (and misinformation and disinformation) that social networking generates aggravate these tensions and interfere with successful research?

These are just some of the questions that must be answered before we know if this latest manifestation of technological creativity can be the catalyst for the quantum leap in clinical research performance that the 21st century needs so badly. Our space, our book, is far from full or finished; what is the power of endlessly connected people?

A current business buzzword seems to have increasing relevance to the relationship between clinical development functions and information technology departments: “transparency”. More and more, we hear clinical operations functions complain that they aren’t getting the information they need from IT or data management. We hear the same from data management about IT, or IT about clinical operations, for that matter. Each of us is the one who’s hard-working and well-meaning, and it’s the other guy who’s withholding information we need. If there is one message each group can agree on, it’s that “I can’t see you.”

Opaque and Obstinate

How does perceived opaqueness stand in the way of clinical IT? In at least four areas: Communication, Planning & Management, Requirements, and Performance. In each area, despite their diverse business impact, the underlying sentiments are common:

I don’t understand you

I don’t want you to understand

I don’t want you to know what I know

I don’t want you to judge us

I don’t think you are helping me

I think you are withholding what I need

I don’t trust you.

These are powerful sentiments, fundamental to human interaction, and turn what should be “only business” into the personal. What are we being opaque about? In the following examples, I will pick on IT, but with a little tweaking, you can apply them equally to IT’s customers in data management or clinical operations.

First, clinical groups will complain that IT is being opaque about, well, information technology! “I go to them and ask for something simple (sic), and all I get is a lot of technical mumbo-jumbo back”. Indeed, at a conference I once attended on the nature of professions in society, the very definition of a “profession” was proposed as “something which one group knows that everybody else doesn’t,” and it was pointed out that it was essential to a profession’s success to create a language (a vocabulary) which was impenetrable to those outside of the profession. IT professionals are masters of this technique (as are pharma’s physicians, scientists, statisticians, and regulatory affairs experts). So as in the famous line from the film Cool Hand Luke, what we’ve got here is a failure to communicate.

Second, and quite different, is the lack of transparency around the deliverables that groups are expecting from IT. For any given project, often as not, IT’s customers feel they have little or no visibility into progress, timing, potential risks, unforeseen stumbles, and the ultimate completion date. Closely related to this, and more inflammatory, is the question of how much something will cost, or how long it will take. The typical consequence of this opaqueness, driven by that list of sentiments itemized above, is a stalemate across the conference room table:

ClinOps is waiting for a set of reports to be programmed out of its CTMS tool, and IT says, “mumble-mumble-technical, so it’s not ready.” When will it be ready? “As soon as we can! – don’t you trust us?” Well, since you ask, no.

At worst, it ends in a game of executive “chicken”, where we find out which VP is more powerful (or cares about us) that week.

Opacity extends deeper, into the nature of the deliverables we are expecting from IT. Let’s take the example of requirements for a new software application. IT asks for our “requirements” and we (think) we tell them. The process IT uses for determining these requirements, prioritizing them, and applying them, is often unclear to the requestor – especially if the results of the requirements gathering aren’t recognizable to those who asked for it.

Support services for IT applications is another common source of opacity. Again, the technology’s users think it is obvious that what is required is to have any and all of its questions answered whenever they have them. The fact that this might not always be possible is somewhat acceptable – life is imperfect – but the reason for this imperfection escapes us. The procedures, capabilities, scope, challenges, obstacles and costs of providing near-perfect support is opaque; only the shortfall in performance is clear. And who’s to blame for the opacity? Generally speaking, it is the service provider who has the responsibility to explain themselves, no matter which side you are on.

All of this can be summarized as an opacity of performance. Common IT performance issues, such as meeting commitments of schedule and budget, or maintaining network uptime, or Help Desk response time and accuracy, cannot be understood if the reasons behind the performance shortfall are opaque, or if the expectations are unreasonable, or if (most typical), the communications come to a mistrusting standoff. This opacity itself is the worst performance of all.

Transparent and Cooperative

What should IT (or ClinOps, or data management, if they are the guilty ones) do to make themselves visible? In many organizations, the dilemma of transparency is increasingly known but seems intractable: the connection between performance and trust is inseparable, and seemingly unfixable once it has descended into a dark negative loop. But misunderstanding is also a fundamental cause, and surely this is approachable, and redeemable.

We talk about international culture gaps freely, with justifiable sensitivity, but the interdepartmental culture gaps are somehow an unspeakable embarrassment, a source of angry stonewalling, something to be kept in the closet. And this does no one any favors. We can start by translating our professional vocabularies, and then move to comparing our everyday vocabularies – what does “on-time” or “commitment” mean to you? What does “easy to use” or “soon” or “expert” mean?

Most importantly, we need to open up our worlds to each other. Have you been to a store, or airline counter or hotel check-in desk these days, where the salesperson stops staring at their flat-panel computer screen, and turns it around to show you what she or he is looking at, as a way of explaining what you are buying (or why your plane is late)? It’s a rare but marvelous experience. The sharing is so unexpected that mistrust evaporates in an instant. That’s the power of transparency. Perhaps we should all, literally or metaphorically, turn our laptop screens around to face the person across the conference room table. Instead of stubborn confrontation, perhaps we can share our business secrets and see our common ground.

It’s baseball season again and I can’t help but use a baseball metaphor to highlight two disturbing trends in clinical IT adoption. Consider base running: the art of it (after hitting the ball in the first place), is to run “through the bag”, i.e., don’t slow up as you get near it so you can be thrown out by a strong infielder, and don’t overrun the bag so that you get picked off for going too far. Many sponsors are in danger of both errors, on the same play, by thinking too far ahead while not finishing the work they have already started.

How does this metaphor apply? Our current shortfall in successfully implementing useful and reliable clinical IT applications is a failure to run through the bag: we buy the software, we design an incomplete implementation, we run out of funding just short of the end – out at first base! Now think of the time you or your strategy staffers are spending dreaming of the intersection of pharma research and the world’s infant-state electronic health records: you just overran the base – out at first again!

Stopping Short

Despite what many executives might have been told, or senior middle managers sincerely believe, the usefulness and reliability of many clinical IT installations (EDC, CTMS, AES, ePRO, data warehousing) is consistently disappointing. It’s not to say that these applications and services are not working, or even that sponsors are not deriving value from them. But the shortfall between promise and potential on the one hand, and actual execution on the other hand, is remarkable. There are many examples:

–Adverse event systems whose report programming is still too complex

–ePRO instruments which take too long to translate into multiple languages

–EDC vendor project managers who understand little about clinical trials or the account they are serving

–Document management tools which require weeks of training and legions of “super-users”

–Clinical operations departments using multiple tools with pieces of the same data entered over and over again

–Safety departments who don’t trust their AES tools

–EDC users who simply buy the vendor’s services and change nothing internally, and are surprised that things go wrong.

The use, or disuse, of enterprise CTMS systems is probably the most egregious example. Walk into any company using a large-scale CTMS application and the refrain is the same: “yes, I enter data into the application every Friday like I am supposed to…but do you want to see the Excel spreadsheet I programmed that I really use to run my trial?” That enterprise CTMS in a big company cost hundreds of thousand of dollars and staff hours in configuration and training – why aren’t people using it for real work? Because these applications, originally conceived with good intentions, have long since left operational reality behind. Part of it is because it is so hard to develop a single program for trial management which meets all the diverse needs of the industry. Part of it is because the enterprise tools are all based on something other than clinical research: sales force automation, managing construction projects, financial portfolio management, investigator site payables, or generic workflow mapping. But ultimately it is we users, as purchasers of these tools, who allowed such disappointing outcomes. Examine how you are using your CTMS now, and compare it to the demo you first saw, or the requirements you first developed. Isn’t it remarkable that such an expensive and complex product does so little for you, after all that time and money?

Data warehousing and mining, the successor to our CDMS’ across the industry, is another example of clinical IT anticlimax. Go behind the conference presentations and you will find that little evidence of truly successful and complete data aggregation and data integration that these projects originally promised.

Indeed, there are so many examples that it makes one wonder whether there are inherent flaws in the thinking behind our clinical IT projects, or in their management, or in the vendors supplying software and services for them. Some common flaws come to mind:

–we do not know how to balance conflicting needs on the basis of operational practicality instead of team politics

–we do not budget sufficiently so that the project can “run through the bag”, so that we can’t afford the cost of configuration and training, and fixing mistakes and re-training

–we are impatient with multi-year projects and we are running too many such projects simultaneously

–we don’t dedicate to the project our best staff polymaths, who have the essential combination of operational, technical, interpersonal and leadership skills to keep the project focused and see it through.

What is common to both the CTMS and data storage stories is highly instructive: value has been derived, and good things have come from these projects, but in deep disproportion to the investment required. The most successful of these implementations recognized at some point (consciously or not) that, for instance, just getting everyone’s opinion on the investigator’s address and phone number in one single place in the enterprise is a useful step forward. Or that being able to make the simplest query across multiple EDC standalone trial databases begins to make up for killing off the CDMS dinosaur.

Success is in Simplicity

In the present state of clinical IT, vendors must supply, and users must demand, more business-useful functionality and improved levels of service. At the same time, the end-users who I am idolizing here are also responsible for the fix they find themselves in. As we try to get the most out of what we have, users must understand that simplicity is powerful and preferable.

We will get much more satisfaction from our service and software vendors if we are able to articulate clearly a reasonable set of functionality. We observed a project recently where a sponsor properly chastised a CTMS vendor for providing an unwieldy, complex tool for report generation. The sponsor proudly announced that they had taken matters into their hands and whittled down their trial status reporting needs to 48 reports! Forty-eight reports! Not a single biopharma employee on earth will read through, keep track of, learn from, or benefit from 48 tracking reports. It is this kind of sponsor-vendor interaction which led to the overly complex software and services we have in the first place. If you cannot manage your clinical trials by tracking far less than even a dozen parameters, you need to revisit your management skills.

Indeed, simplicity is at the heart of many of the problems we have described. If we aim for the fewest patient-reported scales, the best recruiting sites, the fewest fields with the minimum of edit checks on our eCRFs, the “vital few” metrics on CRO performance, then we will have a chance of a) getting a reliable tool or service to deliver what we need; and b) be able to execute our trial programs with greater efficiency and speed. Fewer sites to monitor, fewer datapoints to process, fewer vendors or CROs to manage – these all lead to better operational performance.

Take Back the Dialog

One thing that is clear is that many of those specifically charged with leading the future of clinical IT have left these problems behind them. They have run past the base in their enthusiasm for the “next big thing”, as if the shortfalls described above do not matter or are not recognized. They are chasing electronic medical records, ubiquitous wireless Internet, Web 2.0, SaaS, iPhones, arcane analytics, and every other technical trend. Yes indeed the future lies there, or beyond, and someone should be looking. But perhaps not quite so many of us. You cannot leave this generation’s work undone; if you do you will do just as bad a job when the next big thing shows up.

Our futures are being described by (and therefore, are in the hands of) those who are bored with EDC, CTMS and the traditional clinical IT niches. I will always remember the informatics VP of a big, famous pharma (no longer employed there!) who, having done one EDC study, said “OK, we’ve done that, what’s next?”. Funny, except he was serious, and he controlled the purse-strings. Users must take back the dialog from folks like these. Users are not bored with reliability, with applications that automatically generate the reports they need and make it easy to specify new ones ad hoc, with aggregation of disparate data sources into a single database for their clinical trial, or the integration of their existing, underused applications. There is so much to be done: a Grand Vision is not needed in the industry at the moment, execution is. We have much to gain from the tools (or the raw material for tools) and services that we have already purchased. If you’re bored with these problems, you’re in the wrong business.

By failing to get your clinical IT applications and services to work up to their potential, or by skipping the hard work and only strategizing about the future, you’re out at first base either way. In baseball and in business, it’s execution that wins the game, and it’s hard work regardless. To paraphrase Tom Hanks’ character in League of Their Own, “there’s no skpping in baseball.”

I want to

Few areas in pharma can benefit more from a top ten list than that of pharmacovigilance (PV). Ongoing developments in areas like E2B formats, potential FDA tome requirements, data-mining, DSM Boards needs, Eudravigilance, and EDI gateways have made the world a complex and challenging place for PV professionals today. In that context, a top 10 list devoted to pharmacovigilance can be of great service, either as a planning tool – for those wondering how to respond to these challenges – or as an internal check-up – for those looking to make a mid-course correction. So here’s my top 10 tips related to pharmacovigilance. It is my way of organizing the PV world into an action list.

1.THINK PAPERLESS

Yes, ‘paperless’ can be a cliché, but within clinical development, it is more and more of a reality. EDC systems collect data at sites without paper case report forms. Field monitors produce trip reports ‘online’ within their company’s clinical trial management system. The same reports are reviewed and signed electronically by management. On the back-end of the clinical process, data managers and even medical monitors are reviewing the data with online tools that provide sorting, graphing and searching capabilities. Yet in the PV world, case processing still consists of piles of folders, passed physically from one desk to another. Red folders for ‘hurry’; blue folders for ‘no hurry’; the whole scene could come from an office in the 1950s. Searching the files of vacationing colleagues for needed documents is a typical story that only magnifies the sense of deja vu. It is ironic that today’s adverse events systems allow electronic routing of cases, scanning and storage of external documents and other capabilities that make the folders obsolete. Yes, you can still print a document or a listing as a working copy, but the official record remains within the validated, secure system. The technology supporting this is mature and ready to be used.

2. START MEASURING

Let’s face it, measuring takes time that many of us are not prepared to spare. How many cases do you process in a year? How many people do you need to do this? What is your average number of follow-ups to get a case closed? Is this number good or bad? How do you know? Before you go to your boss to ask for that new system or those additional headcounts, it would be good to know how well you are doing with what you have now. Metrics by one PV organization claim to handle over 1,000 cases per year per FTE, while 250 cases per year per FTE is given as the ‘industry benchmark’. If 1,000 is the upper bound and 250 is the mean, we know there has to be a lower bound out there somewhere. Can you imagine a company where only 100 cases per year per FTE are done? Can you then imagine the differing workflows and data flows that produce a four-fold, or even a 10-fold, difference in efficiency? Where do you fit into this scheme? Your boss should ask you these questions before she signs up for more money or headcount.

3. BROADEN YOUR VIEW OF E2B

In today’s pharma landscape, marketing rights for a product can be divided across multiple companies, countries, indications and even categories of healthcare providers. One marketing partner may end up with the general practitioner market segment for a single indication across the Nordic countries and the UK, while five other companies will divide up the rest of the market across the EU, the US and Japan. Such marketing agreements, while presumably advantageous from a sales perspective, produce multiple, overlapping ICSR reporting responsibilities for the PV professionals at each company. How can a PV professional meet the interlocking demands for receiving and sending ICSR’s across so many partners for a single product?

One answer lies in looking beyond E2B as a means of reporting to health authorities, and to consider the use of both the common format and the gateway functionality to communicate with marketing partners. System vendors have promoted this for years, but several years later the typical sponsor is still struggling just to use the gateway to communicate with authorities. Many of you will know that the so-called E2B or ESTRI gateway is built on an electronic data interchange (EDI) format that is used by thousands of companies (including pharma companies) to process millions of transactions each year with their customers and supply partners. Yet, even in 2007, the number of ICSRs transmitted via a gateway is still measured in mere thousands, and the vast majority of these are between sponsors and agencies. Inter-partner exchange is still dominated by PDF attachments and retyped data. E2B and the gateway offer a new and better way forward.

4. STOP CHECKING THE CHECKERS

Many PV processes are still marked by the idea that ‘checking and rechecking’ equals quality. One process I encountered produced the following workflow:

• ICSRs are printed out by clerical staff for medical monitors to review

• Medical monitors redline the ICSRs and send them back for data entry

• Clerical staff make the changes, reprint the ICSRs, and send both copies back to the medical monitor

• The medical monitor then checks to make sure the corrections have been ‘correctly’ made.

Such ideas of ‘quality’ ignore the fundamental advances made in this area by people like Edward Deming and movements like TQM. Quality is now understood to be a good process followed by trained professionals. Gone are the days when we start searching for problems at the end of the assembly line. The same needs to happen within your organization’s processes.

5. LOOK BEYOND REPORTING

In many PV organizations, the main focus of departmental work, and even departmental goals, remains satisfying regulatory deadlines for reporting. Did we meet the expedited targets? Are all the annual updates filed on time? Such a view minimizes the potential value of pharmacovigilance to the larger organization, and contributes to the view that PV professionals mainly push paper around for a living.

What do your data tell you about the profile of your company’s products? What ideas do your data generate about potential new studies? How can they inform on-going protocols? Getting things filed on time remains essential, but it is no longer sufficient. There are more ways to add value, and forward-looking PV departments are finding ways to move beyond it.

6. KEEP A DUAL FOCUS

While most of your staff are immersed in the specifics of each case, making sure to respond to PV work on time, it means that someone in your group needs to be looking at the bigger picture. Where are the cases coming from? Are these numbers in balance with market share data? Are incident frequencies giving us clues we should pay attention to? Is this bigger picture review a stated part of your process? If so, which role is doing this? My repeated impression when visiting PV operations is that they are very busy, they focus on detail, and are under pressure to get cases and reports done and ‘out the door’. Without planned, allocated time to review, consider and contemplate the big picture, an important part of the PV function is being missed.

7. MAXIMIZE THE BENEFITS OF YOUR SYSTEM

How much of your adverse event system are you actually using? It is amazing to find duplicate functionally being maintained by PV departments outside of the AE system. The most common example of this is tracking spreadsheets. Even though most adverse event systems have tracking and timing mechanisms that can display the status and timelines of cases, these features go unused in favor of a spreadsheet. Another common culprit is reporting systems. Some departments have built complete, parallel databases in MS Access to run reports. Data get double loaded, or even double entered, so that summary reports on the data can be used. The AE system’s own reporting capabilitiesare ignored, or simply not trusted. If this sounds like your situation, fixing this may become the number one idea on this list. Ignored functionality means more cost, more training, more risk and a lousy thing to admit when your boss is quizzing you on your budget increase requests.

8. UPDATE YOUR STANDARDS

The words ‘SAE reconciliation’ generate a universal response across the industry and the response is not necessarily a good one. Reconciliation is an ongoing job that creates burdens for both clinical data managers and PV professionals. The better news is that both sides now have a dominant standard: SDTM 3.x for the data managers and DTD 2.x for PV departments. The use of these standards can facilitate reconciliation by providing consistent, predictable relationships between the two domains. Automated reconciliation can become better than ever by capitalizing on this consistency across all clinical trials.

9. GOOGLE YOUR DATA

The buzzword is data-mining and it refers to sophisticated single detection capabilities run against large amounts of data. Drug interactions and event interactions are some of the key outcomes being produced. Data-mining, however, is heavy duty, technical stuff compared to case processing, with a very different tool set and a demand for

expertise that may go beyond the capabilities of your current staff and your IT support. It is, however, a big part of the future of pharmacovigilance and the sooner you get started the better.

10. START COMPARING

No, I don’t mean just comparing your operations with other companies; I mean comparing yourself against yourself. Contrary to widely held views, there is more value in knowing how much better (or worse!) you are getting over time, as compared to merely knowing whether you are keeping up with your neighbors. PV departments across the industry are organized and staffed quite differently, with big differences in their technology infrastructures as well. Some companies have large, centralized operations, while others, often due to mergers and other corporate history, are dispersed and decentralized, even using different legacy AE systems. So comparing yourself with the guy over the fence may be unhelpful and even misleading.

Much more valuable is both knowing and measuring the impact of your own improvement efforts. You bought that tool and rebuilt that process last year. Has it made a difference? Was the difference worth the cost? These are the real signals of process improvement. You can still trade stories with your PV colleagues at the DIA conference. Just don’t confuse that with measuring progress.

Frank Capra’s 1946 film, It’s a Wonderful Life, portrayed a common theme: George Bailey, like many of us, didn’t realize how fortunate he was to be living the life that he was. If you are a CRA fortunate enough to be using EDC to conduct clinical research, you too can have a fortunate life.

Hard to believe, since you are a busy CRA who is monitoring multiple sites for multiple trials, all at the same time? If you are “e-enabled”, your life consists of: 1) using the capabilities of EDC to make better use of your time; 2) enjoying increased flexibility as to when and where you do certain tasks; 3) allowing the computer to do mundane tasks for you; and 4) exploiting the EDC data to isolate potential problems before they can cause you trouble.

Let’s see how this works by looking at the wonderful life of Mike Monitor, a regional CRA, who is: 1) monitoring several sites for Study A; 2) completing and locking one site for Study B; and 3) initiating a new site for Study C. We’ll follow Mike for a week and see how he uses EDC to cope with his workload and optimize his life/work balance. (Note: If this week in Mike’s life doesn’t sound much like one of yours, it may be time to voice your concerns about how your company is using EDC.)

Monday, 9 A.M.

Cleaning data remotely. Mike’s company allocates regular office time for regional monitors, so they can review and clean data before the next site visit. Mike’s office day for this week is Monday. Mike begins by filtering the data in the EDC system to isolate all new data entered since his last cleaning session. He works his way through the data review items per his monitoring plan and raises several manual queries. He also checks for open queries and sees that nine out of ten from his last session have been answered. He reviews the answers on the nine and closes those queries. At the same time, he makes a note in the comment field of the data item with the open query, so that he can discuss this query with the site at his next visit.

Tracking site performance. Mike has set an expectation with the site that they will catch up on all data entry at least once a week. This expectation has been set during the training session and, beginning this year, is also expressed as an incentive clause in the site contracts for all new studies. Mike runs a standard report that shows the average time between a patient’s visit and the day on which the data for that visit are entered into the EDC system. An average time for each of his sites, as well as an overall average for each study, are displayed in the report. Two of his sites currently qualify for the incentive, while a third site is close to doing so. Mike makes a note in the system to discuss the incentive with this site at his next visit.

Anticipating problems. Mike also examines a list of all his queries, sorting them by eCRF form and then by data item. By doing this, he can see the number of queries that have been issued for a single data item. He notices that he has generated a query on the same primary efficacy endpoint for 12 patients across all his sites for Study A. As this study still has two years to run, he puts a comment on that data item to retrain his sites on the data completion guidelines for that item.

He also runs a separate report on the percentage of missing items and sees that one site has twice the percentage of his other sites. He composes an email to the coordinator for that location, citing several examples of missing data elements and offering to discuss with the site how to avoid this going forward.

Finally, he filters his query list to display only queries that have fired automatically. He examines and closes most of them, but notices that his largest site in Study A has a habit of insisting on the original entry and providing rather weak explanations for why the data value, in spite of the query message, should be considered to be correct. Mike is particularly concerned with this trend, as this site has three times the enrollment of the other sites and is the leading enroller across the entire study. He considers what this means as far as the suitability of these patients and spends additional time reviewing the five enrollment waivers that have been granted to this site. He also makes a note to reexamine the inclusion/exclusion data in the source documents at his next visit. Mike knows that this high enroller will most likely be the target of a pre-approval inspection by Bioresearch Monitoring auditors and he wants to be proactive in addressing potential concerns that may arise then.

Tuesday, 7 P.M.

On Tuesday evening, Mike hops a plane for a two-day road trip: one day for a monitoring visit at a site in Study A, and a second day for an initiation visit at the first site for Study C.

Wednesday, 9 A.M.

Doing SDV. This morning, Mike is at the site for Study A. The site coordinator provides Mike with the patient files and Mike logs in to the EDC system with his own laptop and verifies the data against the source. Since he is not using the site’s computer, he can work freely without interruptions. Having cleaned these data on Monday, Mike’s activity is focused on checking for transcription errors against the source and also looking for unrecorded AE’s. Only one transcription error is found and Mike chooses to raise a query about this within the system, as the site coordinator is unavailable for consultation at that moment. While in the EDC system, Mike also sees the note he created on Monday about the unanswered, open query. He finds the answer himself in the source documents and closes the open query.

Mike is done with his work by 1 P.M. This early finish is consistent across all of his EDC studies, where he finds that he spends about 50% less time working through patient files compared to a paper trial. Regularly viewing and querying these data prior to the site visit has made this acceleration possible.

Thursday, 6 P.M.

Catching the LPLV. On Thursday, Mike has traveled to a different site for an initiation visit for Study C. At the same time, Mike is anticipating the last visit of the last patient that afternoon for Study B. Fortunately, Mike has worked out an agreement with that site’s coordinator to expedite the entry of these data into the EDC system. Now Mike is at the airport on his way home, and he is able to log into the EDC system and view and clean these LPLV data. He also source verifies this final visit, using three, anonymized source documents that the site has agreed to send via e-mail. Just before boarding the plane, Mike is able to flag this visit in the EDC system as SDVed and clean. He also sends an email to the data manager for the trial indicating that, from a monitoring perspective, the trial data are ready for locking.

Friday, 9 A.M.

Checking enrollment. On Friday morning, Mike logs in to the EDC system for each of his studies. He knows that enrollment updates are due in the corporate CTMS on Fridays. He also knows that the IVRS/EDC interface has done its weekly update overnight on Thursday and that all randomized patients now have an entry in the EDC system. He runs an online report showing the total enrollment for every study and the progress status for each patient. He has to update the CTMS data with these data, but has figured out how to copy and paste the results from the online EDC report, so that he doesn’t have to retype them in the CTMS. He also knows that even this will eventually go away, as an EDC/CTMS interface will arrive in 2008 to complement the IVRS/EDC interface.

Having finished his EDC work for the week, Mike spends the rest of Friday on his many other duties, including writing trip reports, reviewing the protocol for Study C and participating via conference call on the project team for the new EDC/CTMS interface. At 5 P.M. on the dot, Mike is off into a restful weekend.

The Rest of the Story

In case you think this is sounding more like Sir Thomas More’s Utopia, let me quickly remind you of the rest of the story. EDC doesn’t mean that your sites will never make irritating mistakes; that site responses to your queries will never be confusing; or that the technology will never have its negative moments. EDC will also require, at least initially, more focus on training and a new perspective on defining and testing the EDC system from the site’s perspective, requirements that may involve you in activities you didn’t have to do in paper trials.

But good use of EDC will also always mean: 1) that you are more in control than ever; 2) that you now have new and flexible ways to do your work on your terms and according to your own schedule; and 3) that mundane tasks like query generation and resolution will be easier than ever, leaving more time for true clinical research and building positive site relationships.

A key part of our movie, It’s a Wonderful Life, is our hero George being shown what life in his hometown would have been like if he had never been born. Review Mike Monitor’s week and imagine it without EDC. Recall what it is like to do a paper trial: the mountains of binders; the queries coming from headquarters six months later; the forced timing of site visits to pick up CRFs; the pressure to finish your work at a site before they closed for the day; and the many data “surprises” that arise as you tried to lock the database. The good news is you don’t have to jump off the bridge: EDC is here to stay, and you really can have a relatively wonderful life – not in the movies, but working as an “e-enabled” monitor.