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.
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.