4 Clinical data models

• In DEV and QC, run a full data model installation only to revert destructive changes
  
• Install and promote data models after every change
  
• Check out the associated transformation when you update a target data model
  
• Limit data model size
  
• Check out a data model to remove or update its business areas
  
• Include a SUBJECTVISIT table
  
• Use SDTM Identifiers for as many columns as possible
  

In DEV and QC, run a full data model installation only to revert destructive changes

• Recommendation: When you install data models in the DEV or QC lifecycle, run a full installation only to revert destructive changes.

• Rationale: A regular data model installation modifies existing structures, and a full installation performs a drop and recreate action on the structures.

  DMW does not allow you to make destructive changes to data models in the Production lifecycle. As a result, you should not need to run a full installation in the Production lifecycle.

• Additional information: When you're working in the Production lifecycle, we do not recommend using the full data model installation. However, you might need to run a full data model installation if you made several changes, deletions, or modifications to the data structure in the DEV or QC lifecycle.

  When you run a regular installation to install data models, DMW updates or upgrades updated tables. When you run a full installation to install data models:

  • DMW drops and recreates all tables.

  • DMW does not drop and recreate the data model schema.

  • LSH drops and recreates the data model schema.

  • LSH drops and recreates Business Area (BA) objects.

Install and promote data models after every change

• Recommendation: Each time you update a data model (for example by adding a table or column), run a regular data model installation, then promote and install to the QC lifecycle.

• Rationale: Installing and promoting data models after each update ensures that changes are installable, both individually and incrementally.

• Additional information: Installing and promoting ensures that the same versions of the data models exist in both the DEV and QC lifecycles. Keeping the lifecyles in sync can help to improve performance and reduce errors that can occur if you promote cumulative data model changes at one time.

Check out the associated transformation when you update a target data model

• Recommendation: When you update a target data model, check out its associated transformation as well.

• Rationale: When you update a target data model, if check out its associated transformation, DMW automatically upgrades the transformation to use the latest version of the data model. As a result, you do not need to manually upgrade the transformation, and you can easily ensure that the transformation uses the most up-to-date version of the target data model.

• Additional information: You are still required to upgrade maps if you modify the transformation's source data models.

Limit data model size

• Recommendation: Create data models with 100 tables or fewer.

• Rationale: Data models with more than 100 tables can cause performance issues.

• Additional information: If you need to, you can create smaller data models and leverage transformations to move the data. If your InForm study's source data model contains more than 100 tables:

  1. Divide the InForm Buffer Model so that each direct transformation between InForm and the Buffer handles fewer than 100 tables.

     This configuration allows several jobs to share the load and results in improved performance.

  2. Create a Union for common data sets (for example., the InForm ECG or PK sample forms) to a smaller number of target tables.

     This allows you to consolidate the multiple Buffer models into a single Aggregation layer.

     For more information about buffer models and aggregation layers, see the data model plan recommendations in the Guidance for DMW Implementation and Configuration document (Document ID: 2469980.1) on My Oracle Support.

Check out a data model to remove or update its business areas

• Recommendation: If you need to modify a business area (BA):

  1. Check out its associated data model in the Development lifecycle.

  2. Update the data model in the Development lifecycle.

  3. Install the changes in the Development lifecycle.

  4. Promote and install to QC and Production, as needed.

• Rationale: A business area is a property of a data model, and you can only change it by creating a new version of the data model.

• Additional information: Avoid modifying the business area schema in the LSH user interface. This is consistent with recommendations In DEV and QC, run a full data model installation only to revert destructive changes and Install and promote data models after every change.

Include a SUBJECTVISIT table

• Recommendation: To include a SUBJECTVISIT table in your study:

  1. Select one table in one of your study's data models, and set its SDTM Identifier property to SUBJECTVISIT.

  2. In the SUBJECTVISIT table, select a column to use for each of the following SDTM Identifiers:

     • USUBJID

     • VISITNUM

     • SUBJID

     • VISIT

  3. In the SUBJECTVISIT table, set the SDTM Identifier property for as many additional columns as you can.

• Rationale: The SUBJECTVISIT table is required to support discrepancy handling, filtering, and Unit Of Work processing.

• Additional information: We do not recommend defining more than one SUBJECTVISIT table per study, due to potential Unit Of Work considerations.

Use SDTM Identifiers for as many columns as possible

• Recommendation: For each table, assign SDTM Identifiers to as many columns as possible.

  • We recommend assigning USUBJID and SUBJID for subject-level tables.

  • We recommend assigning USUBJID, VISITNUM, SUBJID, and VISIT for subject-visit-level tables.

• Rationale: DMW/LSH indexes are based on the identifiers.

• Additional information: Mapping columns to SDTM Identifiers increases the filtering capability in the DMW Data Management user interface.