1 General recommendations

• Create and modify study objects in the DEV lifecycle only
  
• Use the DMW user interface to work with objects in the DMW_DOMAIN
  
• Do not perform tasks in the DMW_DOMAIN work areas if check out required
  

Create and modify study objects in the DEV lifecycle only

You should only create and modify study object in the Development lifecycle as described:

• Recommendation: Use the Development lifecycle to build your study, then promote objects to QC and Production.

• Rationale: Underlying LSH functionality supports this usage model. QC is the only place where you have a reasonable ability to verify how objects will behave when you promote them to Production. In addition, when you check an object out of the QC or Production lifecycle, you need to re-promote it to QC and back to Production.

• Additional information: If you check out a model, transformation or validation check in QC or Production, the existing installed version of the object in the QC and Production lifecycles continues to function until you promote the new version to QC or Production and install it there.

We recommend that you use each lifecycle in the following ways:

• Development: Create clinical data models, transformation programs, and validation checks. You can create them manually or from a library, a study, or a study template. Load data into the Development lifecycle schema, and do initial testing there.
• QC: Formally test study components (optional). This is equivalent to the UAT InForm environment.
• Production: Load, review, and clean production study data. The system prevents destructive changes to tables and models in a production environment.

Use the DMW user interface to work with objects in the DMW_DOMAIN

• Recommendation: When working with the DMW_DOMAIN and the DMW_UTILS sub-domain, do only the following in the LSH user interface:
  • Create therapeutic areas as sub-domains of the DMW_DOMAIN
  • In the DMW_UTILS sub-domain:
    • Create custom functions.
    • Store custom program definitions.
    • Create LSH tables and programs that you want to use in your DMW studies.

  For all other tasks, use the DMW user interface.

• Rationale: Working outside of the DMW user interface to update underlying LSH objects or create objects in DMW's hierarchy is not supported. Doing so can cause:
  • Synchronization issues between DMW and the underlying database objects.
  • Instability in the LSH/DMW environment.
• Additional information: Never create any objects, including data marts, load sets, tables, programs workflows or business areas in DMW_DOMAIN.

  Provided with the correct security, data stored in DMW is still accessible to domain hierarchy outside the DMW_DOMAIN that can establish Views to DMW_DOMAIN tables. As a result, data marts and other LSH objects can be used against the data that's stored and cleaned in DMW.

  DMW creates all necessary application areas, work areas, programs, tables and additional objects to function as described in the Oracle documentation.

Do not perform tasks in the DMW_DOMAIN work areas if check out required

In general, do not perform a task in the DMW_DOMAIN work areas if the task requires you to check out a work area as described:

• Recommendation: The exception to this rule is any task that requires you to check out a work area that is used for a custom function, and the work area exists in an application area in the DMW_UTILS sub-domain.

• Rationale: DMW cannot anticipate its underlying database objects being checked out from outside its application. The unexpected object states cause system instability.

• Additional information: Only perform actions in the DMW_DOMAIN under direct instruction from Oracle Support or Oracle Product Engineering when they determine it is necessary for the resolution of a Service Request.