The Solution Landscape Part 1: CDR
A few weeks ago, we raised the subject of clinical data repositories (CDRs) in a LinkedIn discussion and a subsequent blog about spawning acronyms in the clinical data field. While confusion as to what defines a CDR as distinct from a clinical data warehouse (CDW) continues to surface, one can think of a CDR as a consolidated storage of information (data and documents) for your clinical trials which includes workflow, security, tools for performing daily tasks, all under the umbrella of 21 CFR Part 11. Other definitions for a CDR have included operational data store, a data storage environment for multiple reporting and analysis uses, and – though perhaps a more dated definition -- an integrated source of clinical data and metadata sourced from various data sources and departments.
Among all this confusion, a defining characteristic of a CDR is that the data it extracts does not need to reside in a single data base or coherent structure, and it can support both structured datasets – CRO data, EDC data, safety data, patient data, etc. – and unstructured datasets – such as PDFs and Word documents.
The initial reasons for implementing a CDR were two-fold: first, for the purpose of statistical analysis, reporting and publication of clinical trial data; and second, for medical review decisions based on the safety and efficacy of pre-marketed drugs. But the value a CDR offers to a life sciences organization today is multifaceted. For example, companies want their CDRs to:
- Efficiently integrate data across multiple studies and across pipelines
- Support regulatory submissions and filings, locally and globally, including those conducted with partners, such as CROs
- Improve decision-making, ensure reports are produced promptly and accurately, and enable prompt responses to regulators and other departments within an organization, for example research, pharmacovigilance, senior management, etc.
- Support clinical development programs in a 21 CFR Part 11 compliant environment, and store data in a structured and secure manner to support reproducibility
This wide range of ‘requirements’ makes finding and evaluating a solution challenging. The functional requirements of a CDR will vary depending on the needs of the organization,. It is quite common for the requirements of the system to be incomplete. When the requirements are not clearly defined and prioritized, it is possible to spend lots of money on something that doesn’t fully meet the needs of the organization. Companies must also realize that meeting all their fairy tale list of requirements is just not practical with one solution.
Finding a Fit
Implementation of a CDR can be a complex and potentially disruptive task for companies already struggling with keeping up with the day to day work of running their clinical trials and supporting submissions. Before selecting a solution, companies need to ascertain their needs, priorities, budget, and the flexibility and the scalability of current offerings. In addition, d-Wise believes it is important to identify stakeholders to identify pain points, ascertain the barriers to generating reports or performing analyses, determine the challenges in using data, and assess what potential needs might be moving forward.
d-Wise has the unique experience of working with and implementing a full range of CDR solutions. In addition, d-Wise has helped customers who are not ready to take on the huge cost and effort of implementing a CDR by helping them build and rollout their own solution. This breadth of experience along with being vendor and platform agnostic allows d-Wise to leverage new capabilities and ensure CDR implementations keep pace with regulatory changes. Also important is the ability to respond to the varying needs of pharma companies, including service flexibility, cost containment, less configuration, and the ability to personalize a solution.
What options do you have?
SAS is one of the more established players in working with clinical trial data as almost every company in the industry uses the SAS programming language for clinical transformation and reporting because the SAS transport file format is required in FDA submissions. The SAS Drug Development (SDD) CDR is designed to be integrated with the SAS programming environment with the purpose of providing global access to a centralized clinical information repository. It offers the compliance and control features required by industry, such as 21 CFR Part 11, supports statistical analysis within the SAS statistical programming environment, and provides workflow oversight capabilities. However, with over a decade of being in the market, SDD has been met with mixed reviews as a sustainable solution, never really providing a true workflow and robust development environment. A recent new release of the solution is a complete overhaul of the technology and functionality and shows potential promise to meet the dynamic needs of the clinical data community.
Oracle has followed a similar path to SAS both from a timeline perspective and the ability to really hit the mark on a solution. In the late 2000’s, Oracle released Life Sciences Hub, a system intended to be an integrated Clinical Data Repository and statistical programming platform. As a pure CDW (utilizing standards), the system was highly capable and gained traction among pharma companies after its release. However, as a statistical programming platform, the system struggled to meet the unique and flexible needs of the targeted user community. Many of the companies that purchased and implemented LSH used the system for the CDW functionality, but nearly all of them moved back to a traditional programming environment. Companies implementing the Oracle platform continue to struggle with how to optimize their investment outside of the warehousing components where Oracle excels.
Entimo, a company based in Germany, is the new kid on the block providing their entimICE DARE statistical computing environment, which has already demonstrated strong user acceptance in the life science community and provides a combined clinical data and metadata repository, and distinguishes itself through an ability to track dependencies between objects in the analysis process, report outdated ones, and support workflow definition. The Entimo solution is built upon Eclipse, an open source development environment commonly used among software development teams. A company selecting Entimo is taking on the risk of a small company and the solution while promising, is still in the early stages of development.
Finally, without a commercial solution that meets all the needs of the clinical research process, companies always have the option of rolling out their own solution. There are many pros and cons to this approach: Pro – you get exactly what you need; Con – you have to maintain the system and you’re not a product support company. Companies have had success with this method when they approach it correctly and understand the support it needs.
Most organizations struggle with fragmented and non-standardized data sources, making it difficult to use the ever-increasing source of information from clinical trials for analytics. Flexibility and an environment for storing analysis programs and data generated from data gathered will, therefore, become all the more important as commercial and regulatory pressures continue to mount.