Terminology Overview

Operational data in clinical trials includes planning details and performance metrics, encompassing various aspects relevant to clinical operations and the entire project team. It covers information such as the clinical development plan, investigational product, investigator sites, personnel, contracted agents (e.g., CROs, Labs, independent contractors), protocols, and study sites. The primary sources of operational data are CTMS solutions and Excel trackers.

Operational Insights, within the elluminate platform, comprises a set of modules focused on providing operational data. It appears as a category header in the Platform Menu, which can be expanded or collapsed based on user access rights and licensed modules.

The Operational Data Repository, previously known as Clinical Trial Management System (CTMS), underwent a name change in release 23.1 to better reflect its capabilities. This module enables users with appropriate privileges to directly interact with predefined data tables containing operational data fields. Its purpose is to facilitate data entry and editing for designated individuals responsible for planning details and metrics. The module primarily serves users responsible for ensuring timeliness and data quality. Most operational data consumers utilize the Operational Oversight app.

The Operational Oversight app, previously known as CTMS Insights, underwent a name change in release 23.1 to better align with its purpose and value. It serves as an Analytics app, providing a dashboard view of operational data. The Operational Oversight app is designed for most operational data consumers.

This Analytics app offers pre-defined visualizations based on the operational data repository tables. Clients who find the predefined tables sufficient for their needs can utilize these visualizations as-is. For clients importing supplemental data, the out-of-the-box visualizations can serve as starting templates for creating customized sheets.

Data Flow: Operational Data Repository & Operational Oversight

The numbered diagram below shows the operational data flow.

1: Data Sources

Operational data may come from a variety of sources, all which elluminate can manage. Typically, the data feeds for operational data contain data for numerous studies. The most common are:

• Data feeds from a CTMS system used by a CRO or development partner. These are commonly provided in one of the following formats: CSV files, delimited files, Excel files, SAS datasets, or SAS Transport files.
• Excel trackers. These may be used by internal teams, or by contractors.

Clinical Data in this context refers to the data collected for individual studies during the conduct of the clinical trial. The sources of this data are commonly from systems such as: EDC, eCOA, and Labs. These data feeds contain the data for one study at a time. Most of this data flows into individual study data stores. If desired, the mapping steps used to conform this data may collect aggregated metrics to be fed into the operational data, in which case these aggregated metrics would be written to a global data store for later use.

2: Identify & Import

The process for identifying operational data sources and importing the data is the same as for the rest of the elluminate platform. Use the Data Sources module to identify where the data is coming from. Use Importer to manage the imports. The imported files get stored in their native format in eDrive and an SQL rendition of the data is stored in the appropriate data store.

Previously, mappings were only run for study data imports. A new action has been added within Tasks to provide the option to define when to run the mapping. This new action can be used for both study data imports and for global data stores, such as operational data.

There are three navigation options to get to the Task definition:

• From the Importer module, use the Schedule button to open a New Task
• From the Tasks module directly
• From the new Schedule button within Mapper
  

3: Global Data Store Staging

Operational Data should be brought into global data stores. To avoid potential conflicts, the data feed from each data source should be brought into a separate global data store.

4: Operational Data Repository (ODR) & ODRViews

The ODR is the set of pre-defined tables that data may either be imported into or manually entered. By design, data that gets imported into these forms may be edited. This is to allow a limited set of users (who have been assigned one of the privileges allowing them to edit the data) to make updates to avoid lag times that would be required to have a CRO update the data, resend it, and then re-import it. 

Importing data into the ODR relies on having the data from various sources be put into a common intermediate structure. This intermediate structure is a highly normalized format that is commonly referred to as a tall and skinny structure. Mapper is typically used to read data from the staging area and converts it into the tall and skinny structure. By having such intermediate files follow a defined naming convention, a stored procedure recognizes these files and updates the contents in the ODR tables.

The ODR is comprised of a set of pre-defined tables that capture common operational data. These numerous tables are provided to capture details that include, but are not limited to:

• Investigational Products
• Clinical Development Plans
• Therapeutic Areas
• Programs
• Protocols
• Institutional Review Boards
• Organizations
• Investigator Sites
• Investigators
• Protocol Site Associations
• Persons
• Protocol Deviations
• Preferred Providers
• Regulatory Submissions
• Sponsors

The current best practice recommendation is to reserve use of the ODR pre-defined tables for data that will be manually entered and maintained within elluminate. Operational data that is maintained externally (such as in a CRO’s CTMS system) are best imported into a separate global data store and consolidated with the ODR data during mapping. This simplifies the maintenance by assuring that all maintenance is done in the source system. If data is imported from multiple sources (such as from multiple CROs), each source should have its contents imported into a separate data store. Consolidation of such various data feeds can be managed using Mapper.

The ODRViews are automatically created views of the pre-defined ODR tables. These views differ from the tables to make them easier to work with in Mapper:

• Some table names have been shortened and/or adjusted to make them more readily understood.
• Some column names have been shortened and/or adjusted to make them more readily understood.
• The foreign keys used to link contents to other tables have been supplemented by adding the corresponding table’s lookup returned as an additional column. For example: a table that has the foreign key PERSONID will have its database view include the actual person’s name in addition to the system assigned ID.

Custom fields are included in the views in a separate table within ODRViews named CustomFieldsValues with the fields: 

• EntityId
• FormMetadataId
• FormName
• Label
• Name
• Value

5: Mapping Global Data Store and ODR Data

Global data stores do not have sub-level stores (staging areas or data marts). Therefore, when creating a global data store mapping, there is no option to select the output data store. In practice this means that the mapping used to consolidate data from the various global data stores should be created in the final global data store intended to be used for the Operational Oversight app (the Qlik based Analytics dashboard). It is recommended to use the global data store ODRMart as a common convention for this.

6: Mapping Individual Study Data

Actual study milestones and metrics may be derived during the mapping step for individual studies to be included in the operational data. The resultant table with the derived results may be consolidated with the rest of the operational data in the mapping definition of the global data store to be used by the Operational Oversight app.

7: Operational Oversight App

Operational Oversight is the Analytics app that provides the dashboard of the operational data. There are three ways to access the app:

• From the Platform Menu, expand the Operational Insights category (if not already expanded) and select the menu item Operational Oversight.
• From within the Operational Data Repository, select the Open Dashboard icon in the master header.
• From the Platform Menu, expand the Data Review category (if not already expanded), select Analytics, then search for and select the app Operational Oversight.

8: Statistical Computing Environment

The SCE can be used as an alternative to Mapper for programming in SAS or R. Data in the global data stores can be read and used within SAS or R programs.