Figure 1
|
Like all technologies, the traditional Roger's curve of technology adoption applies to the electronic Common Technical Document
(eCTD) in the pharmaceutical industry. The eCTD is, as of January 2008, FDA, CDER division's specified format for submitting
an electronic application for new NDA, IND, ANDA, BLA, Annual Report, and DMF submissions. That curve features the upward
trend of innovators and early adopters followed by the early majority (see Figure 1).
Clarkston Consulting recently brought together a group of these eCTD innovators and early adopters of eCTD implementation
for a roundtable discussion. These regulatory experts—charged with eCTD implementation at their companies—shared their specific
challenges and insights to the process. Applied Clinical Trials was invited to report on the event.
Criteria for the tool
There are approximately 15 eCTD vendors offering an eCTD software solution. In selecting the eCTD tool, the roundtable participants
discussed what went into their tool criteria process. 
Return on eCTD Investment
|
As the only representative from a large, global CRO, Laurie Henricks, senior director, global regulatory affairs and medical
writing for Quintiles, said that a tool that fit global requirements was key. "We could not make it a U.S.-centric thing,"
she said. After determining the main global requirements, Henricks involved her IT group, so they could evaluate the potential
vendors and the IT resources required.
Henricks added: "As a CRO, we then had to look at what kind of return on investment we would get because we don't own our
projects, we basically have outsourced projects that come to us for creation." The list of requirements then went to the global
regions, for consensus on criteria on the Quintiles' short list.
Carol Rutkowski, senior director, global regulatory operations for Shire Pharmaceuticals, also explained the need for a global
solution. "We established a global team, which took into consideration global and regional requirements and we made sure all
those parameters were met."
Albert Edwards, PharmD, RAC, director, regulatory operations for Takeda Global Research & Development Center in Lake Forest,
IL, described his company as early adopters, though on the Roger's Curve, they appear more as innovators having moved to eCTD
since 2000.
"Even though we were pretty U.S.-centric at the time, we needed publishing that could occur at 7:30, 8:30, 10:30 at night,
and we wanted to make sure that we had that kind of coverage. We also wanted the ability to have a development copy of the
software that we could bring in-house for testing and kicking the tires to see if it worked."
What comprises tire kicking? To Edwards, a pilot test and a load test of the software is key. Once criteria is set, the pilot
test before the product implementation will go a long way in determining the tool's actual usability and impact on IT resources
before the fact. "I've got to pilot test what I'm going to use ahead of time so that I'm reassured the needs of the organization
and our user population are met," remarked Edwards.
Valerie Mackner, MS, senior manager, global regulatory operations with Wyeth Research, said the company has had its own in-house
solution since 2002. As an early adopter of eCTD, she explained that at that time, they felt available off-the-shelf solutions
weren't going to fit their requirements. Now they are looking for a tool with more functionality.
Said Mackner, "We need to be able to validate within the tool and we need a tool that allows us to see things the way health
authorities are viewing. Right now, our tool does not mirror what FDA sees, or the EMEA, so those are the kind of requirements
we're going to be looking at."
Other requirements included that the tool be Web-based and integrate well with the document software used. And selecting the
tool also involves selecting the right vendor.
Tool selection equals vendor selection
When it comes to selecting the tool, it seems IT should have a good sized role. Many of these early adopters say that the
IT department will perform its own audits of the technology vendors. Those audits include examining information such as financial
viability of the vendor and infrastructure requirements.
In addition, Edwards suggests that you ask the vendor what its history is with hitting targets on software version upgrades.
"You want to be assured that upgrades will actually occur within the time frame originally promised so your organization can
be appropriately prepared. Delays in software version upgrades have potential impacts on IT staffing for other projects and
possible budget implications if the upgrade arrives in the next budget year."
Rutkowski noted that going into the selection, sponsors should be aware that the original vendor contact who is consulted
may not be the same person who works on your implementation. Therefore, they may not be up-to-date on your original stated
requirements.
The group consensus was that with the number of vendors out there, the onus falls on the sponsor to do its homework. In addition
to the IT needs, the level of vendor experience, vendor's upgrade plans, vendor's hitting upgrades (as previously noted),
and the financial stability of the vendor go into the tool selection process. Ideally, the number of technology vendors to
bring into the selection process should be narrowed down to between three and five. Anymore than that can be time consuming
and unproductive.
