elluminate Best Practices

This article is currently being updated. Please come back later for updates.

elluminate Best Practices consolidates our best practices into one article, including links to the source articles. Following best practices ensures high-quality results across studies in elluminate. 

API Best Practices

  • Create one service account per environment. Limit the account to read-only access for required studies and data stores. Generate an App-key and App-secret for the account, and store and rotate credentials in an approved secrets system.
  • Share keys through an approved process. Grant access using an enterprise password manager or secrets vault instead of sending raw values. If transmission is unavoidable, use a one-time, end-to-end encrypted method, set a short expiry, and log the access. Prohibit sharing via email, chat, tickets, code, or plain-text configurations.
  • Store the App-key and App-secret in an industry-standard secrets manager such as AWS Secrets Manager, Azure Key Vault, Google Secret Manager, or a CI/CD secrets store like GitLab CI/CD Variables or Azure DevOps Pipeline Variable Groups. Do not hard-code the generated values.
  • Rotate keys periodically and immediately on staff changes. Create new credentials, update pipelines and apps, verify successful calls, revoke old credentials, update the stored values, and redeploy pipelines/apps.
  • Validate the structure before pulling data. Call metadata endpoints to verify study access. Then, list the study’s available data stores using its SchemaPrefix. Select the correct store before requesting domains and data. Verify domain and field definitions, and compare the returned metadata with the expected schemas to identify any drift.
  • Minimize payloads and frequency. Request only required domains and columns, schedule extracts to match downstream needs, and avoid full-store pulls when a subset suffices. Prefer incremental transfers when business keys or timestamps allow downstream duplication.

For more details, see the Configure and Manage Outbound Web Services article in the Administrative section here.

Automated Tasks Best Practices

  • Validate before automating: To ensure the task executes as expected, manually Run the task to test. Confirm the Last Run and verify that the Result = Succeeded. After validation, set the task to Active and configure the recurring schedule.
  • Schedule tasks intentionally: Using the local time zone as listed on the Schedule tab; align start times with data availability and consumer windows, adding buffer time as needed. Stagger dependent actions to prevent conflicts, avoid peak hours, and maintenance windows. For temporary automations, specify the Ends date.
  • Prevent stalled runs from blocking the schedule. Enable the Cancel stalled action(s) after feature to automatically cancel runs that remain in Running status beyond the set hours which then resets the task for the next occurrence. Set this threshold for less time than the Repeat interval so a stalled run clears before the next start.  
  • Monitor and clean up regularly. Review the Tasks list often. Sort or filter by Status, Last Run, and Result to identify failures, incomplete runs, and stale entries with Next Run: Never. Expand details to check Actions and error messages, then choose to Run, Edit, or Delete as needed.  
  • Create tasks within the target module when available. For example, configuring the task from Importer or Exporter preselects the study and action, and automatically generates an email notification, reducing effort and mistakes. Use the Tasks module for cross-study scheduling or multi-action chains. After saving the scheduled task, always verify that the Next Run matches the expected schedule.
  • Schedule email notifications for import success or errors. When data imports are scheduled automatically, an import error can delay the process if it occurs. Set up email notifications so that the appropriate users are notified when the import is complete. If an import error occurs, another team also receives an email, allowing for immediate action.

For more details, see the Manage your Automated Tasks article in the Tasks section here.

Configure Data Central Best Practices

  • Validate prerequisites before configuration. Begin with an active elluminate study and current clinical and operational imports. For Rave, verify Biostats Gateway and Rave ODM Adaptor connections, ensure an RWS-enabled account is available for query processing, and confirm that the study name, environment, and CRF version are correct. For non-Rave, confirm that query tables are mapped according to Data Central's internal requirements.
  • Configure the Subjects Listing for stability and clarity. In Data Central Configuration → Subjects Listing, select a domain with reliable subject and site identifiers, and choose the Subject Identifier Field and Site Identifier Field that stay consistent across data reloads. Limit the listing to essential columns for better performance and focus, and for Rave studies only use Append Default Rave Status when the chosen domain lacks a dependable subject status field.
  • Enable Clean Participant Tracker with consistent inputs. In Data Central Configuration → Subjects Listing → Clean Participant Tracker, select a populated Subject Status Field and Group Assignment Field that appear in the subject listing. Under System Fields, choose the query statuses, issue statuses, and reviewer roles to include. Under Domain Fields, add numeric fields used in the cleanliness calculation. The selected fields are displayed in the Clean Status tooltip. Data Review must be enabled for a Reviewer Role in any domain for that role to be selectable.
  • Configure Data Review for each data store and designate a steward responsible for setup and maintenance. In Data Central Configuration → Data Review, set the Data Store for Related Forms to the store containing EDC clinical forms. For each Data Store, define Default Identifiers for Subject ID, Site ID, and optional Visit ID to ensure consistent context. Use the Validate Keys button to verify uniqueness and monitor any messages. Use the Identifier Overrides tab for domains where subject/site fields differ from the defaults. In the Review Settings tab, assign roles to Show Domains and Enable Data Review, and carefully use the Domain Settings gear icon to include and enable new domains automatically if appropriate.
  • Configure Query Settings to align with EDC workflows and study turnaround goals. In Data Central Configuration → Query, enable Show Queries in Data Central only when a mapped queries table exists. Set the Data Store for Queries Table to ODM_Mapped for Rave studies, and for other non-Rave studies, use the store that contains the mapped Queries table. Enter Open Days and Answer Days to match study targets so overdue items are seen in the Queries listing in Data Central with red text. When allowed, enable Use Stored Credentials to avoid credential prompts and optionally Append elluminate username to all query text for traceability.
  • Configure Role Query Actions to align with the study workflow. In Data Central Configuration → Role Query Actions, select the query actions each role can perform for each status. For Rave studies, import Notification Groups or add groups with names that exactly match the Rave group, and grant None → Open only to roles that need to create new queries. For InForm and Veeva studies, set query actions to the EDC’s available statuses (e.g., InForm includes Cancel and Reopen, Veeva may not). Enable only the actions required for the role so that the UI displays only valid options.
  • Avoid common pitfalls that lead to rework.
    • Overview icons indicate unconfigured items. Proceed only when all items display green checks.
    • Keys must be immutable and unique across loads. Avoid using unstable fields that can change or be reformatted, such as free text or labels.
    • Set the Data Store for Queries Table to ODM_Mapped only for Rave. Select a different mapped data store for non-Rave studies.
    • Rave Notification Group names must match exactly, or two-way processing fails. Always import controlled lists when possible.
    • Role settings in Data Central require underlying User Management privileges for access and review actions.

For more details, see the Configure Data Central article in the Data Central section here.

Data Import Best Practices

  • Define the Data Source first. Configure the URL, credentials, remote folder, remote study, API keys, and other necessary properties before building the Import Definition; manual file imports are the only exception.
  • Choose the simplest data source. Use out-of-the-box API connectors or S3 / Box pulls over custom SFTP scripts, as they require less setup and deliver data more quickly.
  • Confirm column size and precision match data formats. Ensure all columns with numeric values match the set scale and precision when using a precise file format like SAS. Any cases where imported data exceeds the format assigned in metadata can cause truncation or other issues downstream in elluminate.
  • Watch Study Import Control limits. If record-change thresholds are enabled and the import exceeds configured thresholds, the import completes with a warning indicating that elluminate does not import the data.
  • Schedule imports to avoid contention. A study can run only one import into a data store at a time. For example, Study A and Study B may import into their respective Clinical data stores simultaneously, but Study A cannot schedule two imports to run concurrently in its Clinical data store. Subsequent imports queue automatically, so stagger schedules for faster throughput.

For more details, see the Manage Data Imports article in the Importer section here.

elluminate Assist Best Practices

  • Break Complex Questions into Smaller Logical Components
    When a question involves multiple domains, timing logic, or derived calculations, separate the analytical components before creating the query. Instead of combining joins, filters, grouping, and calculations in one prompt, isolate the core clinical condition first. This helps prevent overly complex SQL generation and lowers the chance of unintended joins or misinterpreted logic.

    Example:

    Step 1. Show me a list of records with Subject ID (from the DM domain), 
      Site, Adverse Event Term, Serious flag, and Treatment Emergent flag. 
      Do not group or count.
Step 2. From this result, show me only the records with Serious Flag = Y 
      and Treatment Emergent Flag = Y
Step 3. Count the distinct Subject IDs from this result and group it by Site

    Focus: Logical decomposition of a complex problem.

  • Clearly Define Subject Population
    Always clearly specify the intended subject population (e.g., Enrolled, Randomized, Treated, Completed, Discontinued). If a population is not defined, the chatbot might assume a broader dataset than intended. When calculating rates or percentages, the denominator (the group being divided by) must be explicitly defined. Defining the denominator ensures that counts, rates, and percentages are accurate.

    Example:

    • Show rate of Serious AEs among Enrolled subjects.
• Calculate percentage of Treated subjects with at least one Treatment-Emergent AE.
• Return count of Randomized subjects with ALT > 3x ULN.

  • Explain Specialized Terminology When Needed
    When a question contains study-specific terms, briefly define them using measurable criteria. Do not assume the chatbot understands internal cohort names or derived logic. Instead, convert those terms into specific variables, operators, and thresholds. Providing this structured definition helps the chatbot generate accurate SQL logic.

    Example:

    • Show subjects in the 'High Risk Cohort' (defined as subjects where AESER = 'Y' 
        for at least one adverse event and LBSTRESN is greater than 
        (3 times the LBSTNRHI) for at least one LBTESTCD = 'ALT').
• Identify 'Early Discontinuations' (defined as subjects where 
        DSDECOD = 'DISCONTINUED' and DSSTDY is less than 30).
• Show subjects with 'Frequent Visit Changes' (defined as subjects with SV records 
        where the count of SVTESTCD = 'VISIT' is greater than 5).

  • Specify Aggregation and Output Structure
    Be clear about whether counts of records or distinct subjects are needed, and specify the desired output level. (e.g., one row per subject, one row per site, grouped by country). Without this clarification, the chatbot might return results at an unintended level of detail. Clear instructions about grouping and aggregation help improve the accuracy of the results.

    Example:

    • Return one row per Site with count of distinct subjects with Serious AEs.
• Show total AE records by Study and Country.
• One row per Subject with maximum ALT value.

  • Use Measurable Criteria Instead of Qualitative Terms
    Avoid vague phrases like 'high labs,' 'early in study,' or 'bad data.' These are subjective and can't be reliably converted into SQL. Instead, use clear variable names, operators, and specific numerical thresholds (for example, LBSTRESN > 3 * LBSTNRHI or AESTDY <= 7). Well-defined, measurable criteria ensure SQL accuracy.

    Example:

    • Show subjects where LBTESTCD = 'ALT' and LBSTRESN > (3 * LBSTNRHI) and LBDY > 1.
• List adverse events where AESER = 'Y' and AEREL = 'Y'.
• Identify lab records where LBSTRESN >= (2 * LBSTNRHI) and LBSTNRHI is not null.

  • Define Time Logic Explicitly
    When working with timing concepts such as baseline, post-baseline, treatment-emergent events, or follow-up periods, clearly specify the time window in the prompt. Indicate whether the comparison is based on Study Day, First Dose Date, Baseline value, or another specific date variable. Avoid vague phrases like 'after baseline' or 'during treatment' without defining the exact time window. Clear timing logic ensures accurate record selection and prevents the accidental inclusion of pre-treatment data.

    Example:

    • Show adverse events that started on or after the subject’s first dose date.
• Show lab results collected after Study Day 1 and compare them to each 
        subject’s baseline lab value.
• List adverse events that occurred within 30 days after a subject’s last dose date.

    Note: Many SDTM datasets include a Baseline Flag (for example, LBBLFL = 'Y') that directly identifies baseline records and is the most reliable reference. If no Baseline Flag exists, baseline must be defined using study timing logic, such as the earliest record, Study Day 1 (or Day 0), or a visit labeled 'Baseline.' Always describe baseline using these study terms rather than assuming a specific visit number if no Baseline Flag exists.

  • Review and Validate Output Carefully Before Refining
    Before asking follow-up questions, review the output and SQL carefully to ensure they meet expectations. Check subject counts, filters, domain joins, and derived logic. If something is wrong, fix the prompt before adding more complexity. Building on incorrect results can cause multiple compound errors.

    Example:

    • Explain the SQL logic used for this result.
• Confirm whether distinct subjects are being counted.
• What joins are used between AE and DM?

  • Iterate and Refine Based on Output Review
    After generating an initial result, carefully review both the output and SQL logic before expanding the query. Use follow-up prompts to adjust grouping, refine filters, add denominators, or clarify time logic. Repeated refinement improves accuracy and helps prevent unnecessary complexity from incorrect interim results.

    Example:

    Step 1. List all Serious AEs with Subject ID and Site from the DM table.
Step 2. Using the results above, filter the records to only display the 
      ones with AEs that are Treatment Emergent.
Step 3. Count the number of distinct Subjects from this result by each Site ID.
Step 4. Append a new column to this result to show the percentage of 
      the total number of enrolled Subjects per Site ID.

    Focus: Progressive enhancement after validation.

For more details, see the Use elluminate Assist article in the elluminate Assist section here.

Global Library Best Practices

  • Use the Global Library as a central hub for reusable assets. Promote only vetted, reusable Mapped Domains and Review Objectives so other studies can import them. Manage Status, Description, Tags, and Scope (Therapeutic Areas / Compounds / Programs) to control availability and improve searchability. When replacing an object, set the previous version to Deprecated to preserve history while preventing future use.
  • Author objects in studies, then promote to the Global Library. Develop and validate Mapped Domains and Review Objectives within a study before promotion. The Global Library serves as a repository, not a content creation workspace. This approach preserves source context and ensures only validated objects are shared.
  • Restrict modification access. Assign the Global Library Configure privilege to a limited administrative group. All users can promote objects from studies, but only authorized users can edit or delete objects in the Global Library. Use Last Modified By and Last Modified Date to track changes and maintain accountability. Prefer Deprecated over Delete to retain history.
  • Promote reusable logic and avoid duplication. Promote objects that contain reusable logic such as calculations, scope, and rules. After import, configure study-specific thresholds or targets within the study. This reduces duplication, improves maintainability, and keeps the library organized.
  • Review dependencies during Mapped Domain promotion. During promotion of Mapped Domains, review the Manage Dependencies step and include all required domains to prevent import failures or inconsistent results. Use Overwrite only when intentionally replacing an existing object. The Global Library does not support versioning. When logic or structure changes significantly, create a new object instead of overwriting to preserve clarity and historical context.
  • Organize and document for discoverability. Use the Description field to clearly define purpose and intended usage. Apply consistent, meaningful tags and maintain a controlled tag set. Organize objects using a clear folder structure and naming convention. Consistent metadata improves search accuracy, onboarding, and audit readiness.

For more details, see the Manage Objects in the Global Library Browser article in the Administration section here.

Mapper Best Practices

    Mapped Domains Best Practices

  • Link to a Standard / Specification first. Selecting a CDISC standard, custom standard, or specification allows for the auto-completion of field names, labels, and code lists, which helps prevent downstream mapping errors.
  • Use unique domain names. Assign a unique table name to each mapped domain. When selecting source tables (including those created from previous mappings), be cautious not to choose a table the mapping is also designed to recreate, as this may result in the system blocking execution.
  • Use Intermediate domains. Break complex transformations into smaller intermediate domains to create the final mapped domain. This approach simplifies troubleshooting and allows for the reuse of baseline or first-entry logic in other mappings. For instance, establish an intermediate domain that calculates each subject's baseline visit date, which can then be utilized in downstream mappings.
  • Promote mapped domains to the Global Library. Promoting to the Global Library allows the mapped domain to be imported into other studies without re-coding, ensuring consistency and saving programming time.
  • Use the Extract button in the Domain Editor. Extract complex transformation logic from an existing mapped domain into a reusable intermediate domain. This allows the same transformation to be referenced in other mappings without requiring a rebuild.

For more details, see the Create a Mapping and New Mapped Domain in Mapper article in the Mapper section here.

Operational Data Repository Best Practices

  • Design the panel grids for easy review. In the field configuration, show only the relevant columns needed for an overview of the record. Sort, filter, and fix key columns to the left or right for stable scanning. Use the shaded Filters icon to confirm active filters, then export the filtered view when needed.
  • Export ODR data with the right tool. For a quick Excel download of the current filtered grid, use the Export this data option. Use Open in Exporter for full exports that include richer options, especially for picklist fields.
  • Use Issues for collaboration with other users. Create Issues directly from ODR listings or edit windows to capture context, assign owners, set due dates, and notify assignees by email. Track and action Items from the Related Issues window or the global Issues module.
  • Manage record lifecycle with Archive / Restore. Use Archive (with a provided reason for archiving) instead of deleting records, then Show Archived Records to review or Restore (with a reason) when needed. Verify all changes in the Audit Trail to maintain traceability.
  • Standardize data entry. When configuring input fields for records, utilize Picklists over free text and use multi-select fields where supported to minimize ambiguity. Remember to name custom picklists with the CP_ prefix and avoid entering duplicate values in picklists, as duplicate values cause an error.

For more details, see the Overview of the Operational Data Repository (ODR) article in the Operational Data Repository section here.

Orchestrator Rule Creation Best Practices

  • When using the Condition Builder, use Preview frequently to validate and review the result set and the generated SQL. Switch to the SQL Editor only when necessary; enabling the SQL Editor disables the visual Condition Builder for the rule. Consider duplicating the rule first to preserve a visual version.
  • Use Tokens instead of hard-coding. Create Value tokens for fixed constants (for example, a specific country or site) and SQL tokens for dynamic sets (for example, a subject cohort). Assign clear names to tokens (e.g., @subjects_with_fatigue), and ensure the token output type matches the filtered field. For example, do not use @site = '101 - University Hospital' (string) against DM.SITEID (numeric), because such a mismatch may return no rows.

  • In a condition, AND is evaluated before OR. Use a Group (blue block) to control the execution order, so that grouped conditions run first. Example:

    AESER='Y' AND (AEREL='RELATED' OR AEREL='POSSIBLY RELATED') returns records with AESER='Y' and AEREL equal to RELATED or POSSIBLY RELATED.

    AESER='Y' AND AEREL='RELATED' OR AEREL='POSSIBLY RELATED' without the grouping is interpreted as (AESER='Y' AND AEREL='RELATED') OR (AEREL='POSSIBLY RELATED'), which also returns all POSSIBLY RELATED records regardless of AESER.

  • Use clear naming and tagging conventions. When naming rules, make it meaningful. Keep the name short, as it is displayed in the Opened By column in the Issues listing on Data Central. Apply relevant Tags and add a concise Description specifying intent, the tokens used, and the expected outcome.

For more details, see the Create and Manage Rules in Orchestrator article in the Orchestrator section here.

Protocol Deviations Best Practices

  • Apply a PDAP as early as possible. When adding a protocol deviation, it is best to include the PDAP (Protocol Deviation Assessment Plan) during creation or initial review to speed up the workflow and minimize rework. Note that a PD record cannot be saved in Reviewed status without a PDAP. It is recommended to use mappings for imports to automatically apply PDAP entries, ensuring that records are pre-classified where applicable.
  • Record review actions and reasons in the Edit window. Use the Edit Protocol Deviation window for any needed PDAP assignment or adjustments, and importance overrides, and to add comments explaining reasons for any status changes. The required comment field changes based on the selected status (for example, choosing Canceled prompts for a Reason for Canceling). These embedded notes create a clear history of activity on the record and speed up follow-up, by keeping that activity attached to the PD.
  • Specify the records to be selected before performing bulk edits. Filter and choose only the PD records that have the same Status and the same Applied PDAP Entry, and provide a shared context comment. Run separate bulk edits for different outcomes to prevent unintended status changes or PDAP reclassification.
  • Clearly define re-review triggers. A re-review trigger is an imported field that, when changed from the previous import, automatically updates the Status to Re-Review. The list of tracked fields is set by eCS at the environment level; submit a request to eCS to add or remove fields. Eligible fields include Category, Description, Importance, Identified Date, Start Date, and End Date. Limiting the tracked fields helps reduce unnecessary re-reviews.

For more details, see the Use the Protocol Deviations Dashboard in Data Central article in the Protocol Deviations section here.

Protocol Deviation Assessment Plans (PDAPs) Best Practices

  • Establish a Global PDAP as the enterprise standard. Use the Global list as the authoritative source for PD categories and definitions, and avoid modifying existing entries. Record study-specific needs as new entries in the Study PDAP to keep definitions stable and ensure comparable metrics across studies.
  • Structure entries with stable identifiers. Define Level, Standard Category, Standard Description, and assign a PD Code for each entry. Use Category + Description + PD Code as the unique key. 

  • Define PDAP Level deliberately. For Global PDAPs, use the Organizational level for global standards reused across all or most studies. Use the Intermediate level for Therapeutic Area, Compound, Program, or study-specific rules used across multiple studies. When configuring the Study PDAPs, assign relevant Global entries, then add Intermediate PDAPs when variation is required. Add a Study level PDAP entry if more granularity is needed.

    A Global Intermediate entry is created in the Global PDAP with a Level of Intermediate and assigned to multiple studies, where it is read-only. In contrast, a study-level entry is made in the Study PDAP for a single study, can include a Protocol Version, and remains editable.

  • Manage PDAP imports with traceability. Use Get Template when creating a new PDAP or performing an initial bulk load. Use Export → Edit → Import when updating an existing PDAP to maintain exact field formats and identifiers. Ensure the Study PDAP sheet/tab name matches the study title, and rely on automatic eDrive storage to keep a verifiable history across environments.

For more details, see the Configure the Protocol Deviation Assessment Plan (PDAP) article in the Protocol Deviations section here.

Pinnacle 21 Enterprise Best Practices

  • Verify prerequisites before running. Confirm that Pinnacle 21 Enterprise validation is enabled and licensing is configured for the elluminate URL, that the study has Data Quality enabled, and that the required privileges are assigned. Contact an eCS support representative for assistance if needed.
  • Scope each validation job deliberately. Select the correct Data Store (Staging vs. Data Mart) and include only domains required for validation. Smaller, focused jobs reduce run time and keep findings topical, making the discovery of any findings faster, and easier to action.
  • Select specific versions for Standard, Controlled Terminology, and any dictionary options in the validation job, rather than relying on defaults that can change over time. Record the choices in the Validation Comment to document the configuration. Using fixed versions ensures that repeated runs apply the same rules and reference data, producing comparable results and a clear audit trail.
  • Name jobs consistently. Consider using a naming pattern that contains study, package, standard, and scope. Consistent names make tiles, history, and exported reports easy to find, compare, and submit to any regulatory reviewers if necessary.
  • Iterate and compare over time. Re-run the same job after data fixes to create a new entry in Validations and track progress by reviewing validation findings and issue counts. Maintain a validation schedule aligned to data refreshes or study milestones.

For more details, see the Use Data Quality Tool to Validate Data with Pinnacle 21 Enterprise article in the Standards section here.

Risk Management Best Practices

  • Assign an owner for each study assessment and schedule regular reviews that follow RACT reassessment intervals and RBQM engine runs. Consistent ownership ensures accountability and keeps metrics current.
  • Monitor the Study Data Refresh and RBQM Refresh timestamps on the RBQM card during every home page visit. Trigger a manual refresh or investigate ETL issues whenever timestamps drift beyond the expected refresh schedule.
  • Synchronize risk management module workflows and finalize or archive RACT assessments on time, ensuring RBQM monitoring runs against the latest risk definitions. This coupling ensures that proactive planning (RACT) and scheduled analytics (RBQM) reference the same risk environment.
  • Any substantial changes to the step-by-step procedures of protocols should prompt a new RACT version and re-evaluation of KRIs or QTL thresholds. Re-baselining protects data integrity and ensures that monitoring rules remain aligned with the updated protocols.

For more details, see the Overview of Risk Management Home Page article in the Risk Management section here.

Study Configuration Best Practices

  • Configure Study Attributes. Before adding a study in elluminate, go to Platform Administration → Configuration to set up Study Attributes. Configured attributes populate the drop-down menus used when adding a study and enable proper grouping in the CDA and CTOA Analytics applications.
  • Use 'Add From Template' whenever possible. Study templates provide reusable blueprints for new studies and prepopulate common choices across the five tabs. Templates enable straightforward setup, consistent standards and dictionaries across trials, and reduced configuration drift. Maintain a small, curated library of study templates and version the library as organizational needs evolve.
  • Enforce a concise, searchable naming convention. Follow elluminate rules for Study Name: 2 to 24 characters, must start with a letter or number, and only underscores, hyphens, or spaces are allowed after the first character. The study name becomes the schema prefix in the elluminate database; keep the name short, simple, and effective.
  • Complete all five tabs before saving. elluminate recommends filling out the tabs (Configuration, Standards, Dictionaries, Settings, and ETL) and saving only after all tabs are complete to avoid closing the Add Study window in the middle of setup. Many settings depend on each other; for example, enabling Clinical Data Analytics on the Settings tab requires selecting an SDTM standard on the Standards tab.
  • Select standards & dictionaries deliberately and document them. Choose SDTM and ADaM standards with corresponding Controlled Terminology (CT) dates and dictionary versions. Record the selections and avoid changes during the study unless governed by change control. Maintaining consistent standards, controlled terminology, and dictionaries ensures data quality, analytics, and external validation (e.g., Pinnacle 21 Enterprise) results.

For more details, see the Configure a New Study article in the Administration section here.

Study Attribute Configuration Best Practices

  • Configure study attributes before creating the first study. At a minimum, set up essential items such as Compound (required), Therapeutic Area, Program, and other relevant attributes. Properly configuring these attributes ensures complete drop-down options during the Add Study and Edit Study processes.
  • Standardize attribute vocabularies. Follow industry-standard practice by establishing a single approved list of values for items such as Therapeutic Area, Compounds, Program, Phase, Study Type, Blindings, Staging Areas, Data Marts, and more. Use consistent names and precise descriptions to prevent duplicates, improve search, simplify reporting, analytics, and governance across studies.
  • Plan Data Stores intentionally. Use the default staging areas Clinical, Operational, and ODM_Stage for raw source data and the default data marts SDTM, Reporting, and ODM_Mapped for mapped analysis-ready outputs. Add new staging areas or data marts only when justified by integration or reporting needs. Set a default only when it should be the standard selection across the entire environment, as changes to default configurations affect all studies. Avoid altering the schema suffix, as it controls database schema names and can disrupt downstream processes like existing mappings; change it only if absolutely necessary. Document the modification thoroughly, and ensure all downstream programming and configuration function as expected after the change.
  • Set priorities for review workflows. Configure the Issue Priority with Due in Days values to match the review turnaround times. Set the Review Objective Priority with numeric ranks to organize review work by risk and impact. This helps ensure timely follow-up across IDRP and issue management. If IDRP is in use in the environment; keep at least one Review Objective Priority active, try to standardize names and colors, limit the list to three to five levels, and review the settings regularly.
  • Reuse proven configurations. When a configuration is confirmed to work as intended, export the configuration items to an Excel (.xlsx) file and then import the file into another elluminate environment to establish the same settings. Maintain a version-controlled library of approved exports, organized by environment and program, to speed up setup, reduce errors, and improve consistency across studies.

For more details, see the Configure Study Attributes article in the Administration section here.

 

Was this article helpful?

1 out of 1 found this helpful

Have more questions? Submit a request