(GLOW IMAGES, GETTY IMAGES)
|
Given the years of experience and thousands of clinical studies that have been performed using Electronic Data Capture (EDC),
one could be forgiven for thinking that EDC processes are as firmly established as other data management activities. Surely
EDC has become as routine as other clinical processes like coding or protocol development, hasn't it?
As any project manager who has worked on an EDC study will attest, nothing could be further from the truth. Given the variety
of combinations of sponsor, CROs, and EDC vendors, plus the inherent communication challenges, many companies find themselves
reinventing the wheel with each EDC implementation.
Many have tried to alleviate this problem by working with the same CROs and EDC vendors repeatedly. But even this approach
does not ensure that the current project is going to be handled the same way as previous ones.
Many EDC platforms are updated more than once a year. Some of these changes are relatively minor, while others are major platform
changes such as adding a clinical trial management system or improving development tools. Moreover, sponsor, CRO, and EDC companies are constantly updating their internal processes in an effort to improve productivity
or as a result of recent audit findings.
Last year's successful partnerships do not guarantee that this year's partnerships will also succeed. New software versions,
new project teams, and new procedures can all put this year's projects at risk of failing to meet study objectives. As EDC
systems continue to evolve, the management of these tools continues to mature as well.
This article will focus on issues related to defining deliverables and identifying responsibilities. It will also highlight
some areas where confusion is likely, including planning documentation, roles and responsibilities for testing, change control
communication, and evolving processes.
Finally, the article will describe measures to mitigate the risks posed by the these issues. It assumes that the project will
include both a CRO and a separate EDC vendor. Obviously there are other possible structures, but many of the same issues will
be found in sponsor/CRO and sponsor/EDC vendor relationships.
Define deliverables
When there are multiple team members relying on each other for critical path deliverables, it is essential that there is a
common understanding of the deliverables and the underlying details.
Too often and too late it becomes apparent that there is a discrepancy between what different team members are expecting.
Requirements Specifications are a good example of where stakeholders frequently get confused.
Nontechnical staff may expect Requirements Specifications to be high-level documents that lack technical detail. In technical
parlance, these are often referred to as User Requirements Specifications. Conversely, developers might expect Technical Requirements
Specifications, which are significantly more detailed and often contain technical information that would be foreign to most
nontechnical staff.
When a deliverable is simply described as Requirements Specifications, it can mean two very different things to staff. This
may result in key tasks taking longer than expected, as people reconcile their expectations about what the document should
contain and who should produce key pieces.
One example of poorly defined deliverables involved a CRO, EDC vendor, and sponsor who worked together on a large patient
registry that has long since finished.
The CRO was responsible for approving the design specifications. The CRO's data management lead was expecting the EDC vendor
to translate 10 pages of requirements into roughly 100 pages of very detailed information that would be considered the final
design specifications. This was consistent with the CRO's experience on other EDC studies with other vendors. The project
timeline allowed two days to review and approve these specifications.
A few weeks after forwarding the requirements documentation to the EDC vendor, their technical staff returned over 500 pages
of technical documents that constituted the design specifications. The vendor assumed that the CRO data management lead would
need the complete technical documentation, which supplied every detail of the configuration in a manner that database administrators
and programmers needed, rather than something comprehensible to a knowledgeable lay reader.
Conversely, the CRO data management lead was expecting a document that described the system in detail for a lay audience.
This miscommunication about the specifics of this intermediate deliverable jeopardized timelines for the entire project.
