Oracle® Health Sciences Translational Research Center ... · applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures

Oracle® Health Sciences Translational Research CenterAdministrator’s Guide

Release 3.0.1

E35651-04

April 2014

Oracle Health Sciences Translational Research Center Administrator's Guide, Release 3.0.1

E35651-04

Copyright © 2012, 2014 Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

This software and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

iii

Contents

Preface ................................................................................................................................................................ vii

Audience...................................................................................................................................................... viiDocumentation Accessibility .................................................................................................................... viiFinding Information and Patches on My Oracle Support .................................................................... viiFinding Documentation on Oracle Technology Network..................................................................... ixRelated Documents ..................................................................................................................................... ixConventions ................................................................................................................................................. x

Part I Common Configuration

1 Common Configurable ETL Tables

1.1 Configuring the C_LOAD_PARAM Table ............................................................................. 1-11.2 Configuring C_LOAD_DE_IDENTIFY Attributes................................................................. 1-61.3 Standard Configuration of the C_COHORT_PROCEDURE_TYPE Table ...................... 1-111.4 ETL Global Parameters ........................................................................................................... 1-12

2 Virtual Private Database

2.1 Overview...................................................................................................................................... 2-12.2 HIPAA Attribute Groupings..................................................................................................... 2-12.3 Assigning Users to Virtual Private Database Configurations .............................................. 2-32.4 Auditing Trail of Configurations and Assignments .............................................................. 2-32.5 Enabling Row Access to Virtual Private Database Data ....................................................... 2-42.6 Global Policy for All HIPAA Attributes .................................................................................. 2-42.7 Virtual Private Database Configuration Limitations............................................................. 2-4

Part II Oracle Health Sciences Translational Research Center for Informatica

3 Informatica ETL Configuration

3.1 Standard Configuration of C_LOAD_DATES_INFA Table ................................................. 3-13.2 Configuring Informatica Workflows and Global Parameter File ........................................ 3-1

4 Architecture

4.1 Overview...................................................................................................................................... 4-14.2 ETL Behavior ............................................................................................................................... 4-2

iv

4.3 Informatica Repository Artifacts .............................................................................................. 4-3

5 Executing Informatica ETLs

5.1 Introduction ................................................................................................................................. 5-15.2 Executing Full Load.................................................................................................................... 5-15.3 Executing Incremental Load...................................................................................................... 5-3

Part III Oracle Health Sciences Translational Research Center for Oracle Data Integrator

6 Architecture

6.1 Overview...................................................................................................................................... 6-16.2 ETL Behavior ............................................................................................................................... 6-16.3 Oracle Data Integrator Work Repository Artifacts ................................................................ 6-26.3.1 Execution Plans .................................................................................................................... 6-46.3.2 Mappings .............................................................................................................................. 6-56.3.3 Variables................................................................................................................................ 6-66.3.4 Sequences .............................................................................................................................. 6-76.3.5 User-defined Functions....................................................................................................... 6-86.3.6 Knowledge Modules ........................................................................................................... 6-96.3.7 Models ................................................................................................................................... 6-9

7 Configuration Steps

7.1 Standard Configuration of the C_LOAD_DATES Table....................................................... 7-1

8 Executing ETLs

8.1 Executing Full Load.................................................................................................................... 8-18.2 Executing Incremental Load...................................................................................................... 8-38.3 Executing an Individual ETL .................................................................................................... 8-48.4 Scheduling an ETL Execution Plan .......................................................................................... 8-6

Part IV Statistics

9 Statistics for Query Engine

9.1 Executing the Package................................................................................................................ 9-1

Part V Appendices

A ETL Related Tables

A.1 Mapping of Key System Attributes Between HDWF and CDM......................................... A-1

B Work Repository Artifacts

B.1 Variables...................................................................................................................................... B-1B.2 Sequences .................................................................................................................................... B-3

v

B.3 Interfaces ..................................................................................................................................... B-4

C Healthcare Data Warehouse Foundation to Cohort Data Mart Mappings

C.1 HDWF to CDM Mappings........................................................................................................ C-1

D Assumptions

D.1 Details .......................................................................................................................................... D-1

Index

vi

vii

Preface

Oracle Health Sciences Translational Research Center (TRC) comprises of two products, Oracle Health Sciences Omics Data Bank (ODB) and Oracle Health Sciences Cohort Explorer (CE). This guide provides information on the TRC architecture and describes how to perform various administrative tasks.

AudienceThis document is intended for:

■ Implementation team that wants to explore TRC

■ Data Warehouse administrators, ETL developers, and system administrator

This guide assumes that you have knowledge of the following:

■ Oracle Database

■ Oracle Data Integrator (ODI)

■ Informatica (INFA)

■ Oracle Healthcare Data Warehouse Foundation (HDWF)

■ Oracle Business Intelligence Enterprise Edition (OBIEE)

Documentation AccessibilityFor information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle SupportOracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=accid=info or visit http://www.oracle.com/pls/topic/lookup?ctx=accid=trs if you are hearing impaired.

Finding Information and Patches on My Oracle SupportYour source for the latest information about Oracle Health Sciences Cohort Explorer is Oracle Support's self-service Web site, My Oracle Support (formerly MetaLink).

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc

viii

Before you install and use an Oracle software release, always visit the My Oracle Support Web site for the latest information, including alerts, release notes, documentation, and patches.

Creating a My Oracle Support AccountYou must register at My Oracle Support to obtain a user name and password account before you can enter the Web site.

To register for My Oracle Support:

1. Open a Web browser to http://support.oracle.com.

2. Click the Register here link to create a My Oracle Support account. The registration page opens.

3. Follow the instructions on the registration page.

Signing In to My Oracle SupportTo sign in to My Oracle Support:

1. Open a Web browser to http://support.oracle.com.

2. Click Sign In.

3. Enter your user name and password.

4. Click Go to open the My Oracle Support home page.

Searching for Knowledge Articles by ID Number or Text StringThe fastest way to search for product documentation, release notes, and white papers is by the article ID number.

To search by the article ID number:

1. Sign in to My Oracle Support at http://support.oracle.com.

2. Locate the Search box in the upper right corner of the My Oracle Support page.

3. Click the sources icon to the left of the search box, and then select Article ID from the list.

4. Enter the article ID number in the text box.

5. Click the magnifying glass icon to the right of the search box (or press the Enter key) to execute your search.

The Knowledge page displays the results of your search. If the article is found, click the link to view the abstract, text, attachments, and related products.

In addition to searching by article ID, you can use the following My Oracle Support tools to browse and search the knowledge base:

■ Product Focus — On the Knowledge page, you can drill into a product area through the Browse Knowledge menu on the left side of the page. In the Browse any Product, By Name field, type in part of the product name, and then select the product from the list. Alternatively, you can click the arrow icon to view the complete list of Oracle products and then select your product. This option lets you focus your browsing and searching on a specific product or set of products.

■ Refine Search — Once you have results from a search, use the Refine Search options on the right side of the Knowledge page to narrow your search and make the results more relevant.

ix

■ Advanced Search — You can specify one or more search criteria, such as source, exact phrase, and related product, to find knowledge articles and documentation.

Finding Patches on My Oracle SupportBe sure to check My Oracle Support for the latest patches, if any, for your product. You can search for patches by patch ID or number, or by product or family.

To locate and download a patch:

1. Sign in to My Oracle Support at http://support.oracle.com.

2. Click the Patches & Updates tab.

The Patches & Updates page opens and displays the Patch Search region. You have the following options:

■ In the Patch ID or Number is field, enter the primary bug number of the patch you want. This option is useful if you already know the patch number.

■ To find a patch by product name, release, and platform, click the Product or Family link to enter one or more search criteria.

3. Click Search to execute your query. The Patch Search Results page opens.

4. Click the patch ID number. The system displays details about the patch. In addition, you can view the Read Me file before downloading the patch.

5. Click Download. Follow the instructions on the screen to download, save, and install the patch files.

Finding Documentation on Oracle Technology NetworkThe Oracle Technology Network Web site contains links to all Oracle user and reference documentation. To find user documentation for Oracle products:

1. Go to the Oracle Technology Network at

http://www.oracle.com/technetwork/index.html and log in.

2. Mouse over the Support tab, then click the Documentation hyperlink.

Alternatively, go to Oracle Documentation page at

http://www.oracle.com/technology/documentation/index.html

3. Navigate to the product you need and click the link.

For example, scroll down to the Applications section and click Oracle Health Sciences Applications.

4. Click the link for the documentation you need.

Related DocumentsFor more information, see the following documents:

Oracle Business Intelligence Enterprise Edition DocumentationThe Oracle Business Intelligence Suite Enterprise Edition Online Documentation Library documentation set includes:

■ Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1)

x

■ Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1)

■ Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1)

■ Oracle Fusion Middleware Scheduling Jobs Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1)

■ Oracle Fusion Middleware Security Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1)

■ Oracle Fusion Middleware Developer's Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1)

■ Oracle Fusion Middleware Integrator's Guide for Oracle Business Intelligence Enterprise Edition 11g Release 1 (11.1.1)

Oracle Healthcare Data Warehouse Foundation DocumentationThe Oracle Healthcare Data Warehouse Foundation documentation set includes:

■ Oracle Healthcare Data Warehouse Foundation Release Notes

■ Oracle Healthcare Data Warehouse Foundation Secure Installation and Configuration Guide

■ Oracle Healthcare Data Warehouse Foundation Programmer's Guide

■ Oracle Healthcare Data Warehouse Foundation Interface Table Programmer's Guide

Oracle Data Integrator DocumentationThe Oracle Data Integrator documentation is a part of the Oracle Fusion Middleware 11.1.1.6 documentation. Oracle Data Integrator documents in the Fusion Middleware Documentation Library are as follows:

■ Oracle Fusion Middleware Getting Started with Oracle Data Integrator 11g Release 1 (11.1.1)

■ Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator 11g Release 1 (11.1.1)

■ Oracle Fusion Middleware Installation Guide for Oracle Data Integrator 11g Release 1 (11.1.1)

■ Oracle Fusion Middleware Application Adapters Guide for Oracle Data Integrator 11g Release 1 (11.1.1)

■ Oracle Fusion Middleware Knowledge Module Developer's Guide for Oracle Data Integrator 11g Release 1 (11.1.1)

■ Oracle Fusion Middleware Connectivity and Knowledge Modules Guide for Oracle Data Integrator 11g Release 1 (11.1.1)

ConventionsThe following text conventions are used in this document:

Convention Meaning

boldface Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

xi

italic Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

Convention Meaning

xii

Part IPart I Common Configuration

This part of the guide describes how to configure ETL tables common to both ODI and INFA. It contains the following chapters:

■ Chapter 1, "Common Configurable ETL Tables"

■ Chapter 2, "Virtual Private Database"

1

Common Configurable ETL Tables 1-1

1Common Configurable ETL Tables

This chapter describes configurable ETLs common to both ODI and INFA. It contains the following topics:

■ Section 1.1, "Configuring the C_LOAD_PARAM Table"

■ Section 1.2, "Configuring C_LOAD_DE_IDENTIFY Attributes"

■ Section 1.3, "Standard Configuration of the C_COHORT_PROCEDURE_TYPE Table"

■ Section 1.4, "ETL Global Parameters"

1.1 Configuring the C_LOAD_PARAM Table The C_LOAD_PARAM table stores the seed data required for loading the Cohort Data Mart (CDM) data model tables. Table 1–1 describes the attributes of this table. After TRC is successfully installed, this table is populated with the default seed data. Change the value in the PARAM_VALUE field according to your requirements.

Update the PARAM_VALUE fields with appropriate code type values. Update the PARAM value as per the code repository value for the following records in the C_LOAD_PARAM table:

PACKAGE_NAME - records starting with LOAD are configuration records for loading the respective data model table. For example, in Table 1–2, the package LOAD_CONSENT_DIMENSION is the configuration record required for loading W_EHA_CONSENT_D. Therefore, you must provide an appropriate code type value for loading W_EHA_CONSENT_D in the PARAM_VALUE field for that corresponding package.

Table 1–1 LOAD PARAM Attributes in the HDWF Schema

Column Name Data_Type Description

CDM_PARAM_ID NUMBER(38,0) Primary key. Serial number against the row in this table.

ENTITY_NM VARCHAR2(100) CDM target table name based on which ETLs pick the respective parameters.

PACKAGE_NM VARCHAR2(300) Not applicable.

PARAM_NM VARCHAR2(100) Name of the parameter used in Informatica mappings.

PARAM_VAL VARCHAR2(4000) Actual value of parameters used in Informatica mappings.

PARAM_DESC VARCHAR2(4000) Description against the parameters.

INSERT_DT DATE Date when the record is inserted.

ENTERPRISE_ID NUMBER NOT NULL

Unique identifier for an enterprise in a multi-enterprise environment.

Configuring the C_LOAD_PARAM Table

1-2 Oracle Health Sciences Translational Research Center Administrator's Guide

Table 1–2 provides the list of parameters available to configure different code types.

Note: For ANATOMICAL_SITE_D and DIAGNOSIS_D ETLs, irrespective of hierarchy in HDWF (that is, no data in HDM_ARC and HDM_GRAPH), CDM 3.0 ETLs populate flat hierarchy like all levels are the same.

Table 1–2 Records in the C_LOAD_PARAM Table and Configuring Code Types

PACKAGE_NAME PARAM_NAME PARAM_VALUE

LOAD_ANATOMICAL_SITE_DIMENSION

ANATOMICAL_SITE_CODE SPCMN_ANA_SITE_CD

LOAD_ANATOMICAL_SITE_ DIMENSION

ANAT_HIER_CE ANAT_HIER_CE_V1

LOAD_CONSENT_DIMENSION CONSENT_TYPE_CODE CNSNT_TYP

LOAD_CONSENT_STATUS_DIMENSION

CONSENT_STATUS_CODE CNSNT_STCD

LOAD_DIAGNOSIS_DIMENSION DIAGNOSIS_CODE CNRN_CD

LOAD_DIAGNOSIS_ DIMENSION DIAG_HIER_CE DIAG_HIER_CE_V1

LOAD_DIAGNOSIS_STATUS_DIMENSION

DIAGNOSIS_STATUS_CODE CNRN_STCD

LOAD_ETHNICITY_DIMENSION ETHNICITY_CODE 'ETHN_CD'

LOAD_HISTORY_VALUE_DIMENSION

HISTORY_VALUE_CODE 'PT_HX_VAL_CD'

LOAD_MEDICATION_DIMENSION MEDICATION_CODE 'SUB_CD'

LOAD_DX_PATIENT_BRIDGE ENC_FAC_RLSHPTYP_CODE ENC_FAC_RLSHPTYP_PRMRY_CARE_SITE

LOAD_DX_PATIENT_BRIDGE CNRN_SVCPRV_RLSHP_CODE CNRN_SVCPRV_RLSHPTYP_PERFMR

LOAD_DX_PATIENT_BRIDGE CNRN_SVCPRV_RLSHP_TYPE_CODE CNRN_SVCPRV_RLSHPTYP

LOAD_DX_SUBJECT_BRIDGE ENC_FAC_RLSHPTYP_TYPE_CODE ENC_FAC_RLSHPTYP

LOAD_DX_SUBJECT_BRIDGE ENC_FAC_RLSHPTYP_CODE ENC_FAC_RLSHPTYP_PRMRY_CARE_SITE

LOAD_DX_SUBJECT_BRIDGE CNRN_SVCPRV_RLSHP_CODE CNRN_SVCPRV_RLSHPTYP_PERFMR

LOAD_DX_SUBJECT_BRIDGE CNRN_SVCPRV_RLSHP_TYPE_CODE CNRN_SVCPRV_RLSHPTYP

LOAD_ENCOUNTER_PATIENT_BRIDGE

ENC_FAC_RLSHPTYP_TYPE_CODE ENC_FAC_RLSHPTYP


ENC_FAC_RLSHPTYP_CODE ENC_FAC_RLSHPTYP_PRMRY_CARE_SITE

LOAD_ENCOUNTER_TYPE_DIMENSION

ENCOUNTER_TYPE_CODE 'ENC_SUBTYP'

LOAD_FACILITY_DIMENSION FACILITY_CODE 'FAC_SUBTYP'

LOAD_FAMBR_RLSHP_DIMENSION FAMBR_RLSHP_TYPE_CODE 'PRTY_RLSHPTYPD_FAM'

LOAD_OBSERVATION_DIMENSION OBSV_CODE OBSV_CD

LOAD_OBSV_PATIENT_BRIDGE VALUE_BLN VAL_TYP_BLN

LOAD_OBSV_PATIENT_BRIDGE VALUE_TYPE_CODE TYP_CD

LOAD_OBSV_PATIENT_BRIDGE OBSV_SVCPRV_RLSHP_TYPE_CODE OBSV_SVCPRV_RLSHPTYP

LOAD_OBSV_PATIENT_BRIDGE OBSV_SVCPRV_RLSHP_CODE OBSV_SVCPRV_RLSHPTYP_AUTHR

LOAD_OBSV_PATIENT_BRIDGE ENC_FAC_RLSHPTYP_TYPE_CODE ENC_FAC_RLSHPTYP

LOAD_OBSV_PATIENT_BRIDGE ENC_FAC_RLSHPTYP_CODE ENC_FAC_RLSHPTYP_PRMRY_CARE_SITE



LOAD_OBSV_PATIENT_BRIDGE VALUE_CODE VAL_TYP_CD

LOAD_OBSV_SUBJECT_BRIDGE OBSV_SVCPRV_RLSHP_TYPE_CODE OBSV_SVCPRV_RLSHPTYP

LOAD_OBSV_SUBJECT_BRIDGE OBSV_SVCPRV_RLSHP_CODE OBSV_SVCPRV_RLSHPTYP_AUTHR

LOAD_OBSV_SUBJECT_BRIDGE ENC_FAC_RLSHPTYP_TYPE_CODE ENC_FAC_RLSHPTYP

LOAD_OBSV_SUBJECT_BRIDGE ENC_FAC_RLSHPTYP_CODE ENC_FAC_RLSHPTYP_PRMRY_CARE_SITE

LOAD_OBSV_SUBJECT_BRIDGE VALUE_BLN VAL_TYP_BLN

LOAD_OBSV_SUBJECT_BRIDGE VALUE_TYPE_CODE TYP_CD

LOAD_OBSV_SUBJECT_BRIDGE VALUE_CODE VAL_TYP_CD

LOAD_OBSV_VALUE_DIMENSION OBSV_VALUE_TYPE_CODE 'OBSV_VAL_CD'

LOAD_PATIENT_FAMBR_RLSHP_BRIDGE

FAMBR_RLSHP_TYPE_CODE ABC

LOAD_PATIENT_FAMBR_RLSHP_BRIDGE

FAMBR_RLSHP_TYPE_CODE PRTY_RLSHPTYPD_FAM

LOAD_PATIENT_HISTORY_DIMENSION

PATIENT_HISTORY_CODE PT_ALGY_HX_CD

LOAD_PATIENT_HISTORY_DIMENSION

PATIENT_HISTORY_CODE PT_HX_CD

LOAD_PATIENT_HISTORY_PATIENT_BRIDGE

VALUE_BLN VAL_TYP_BLN


PATIENT_FAM_HX_CODE PT_HX_SUBTYP_FAM_HX


PATIENT_HISTORY_SUBTYP_CODE PT_HX_SUBTYP


PATIENT_SCL_HX_CODE PT_HX_SUBTYP_SCL_HX


PATIENT_ALGY_HX_CODEP T_HX_SUBTYP_ALGY_HX


VALUE_CODE VAL_TYP_CD


VALUE_TYPE_CODE TYP_CD


PATIENT_SUBST_HX_CODE PT_HX_SUBTYP_SUBST_HX

LOAD_PROCEDURE_DIMENSION PROCEDURE_CODE 'PROC_CD'

LOAD_PROCEDURE_PATIENT_BRIDGE

PROCEDURE_CODE PROC_CD


PROCEDURE_CODE_INFA PROC_CD


INTVN_SVCPRV_RLSHPTYP_TYPE_CODE

INTVN_SVCPRV_RLSHPTYP


INTVN_SVCPRV_RLSHPTYP_CODE INTVN_SVCPRV_RLSHPTYP_ATTNDG_SVCPRV





LOAD_PROCEDURE_SUBJECT_BRIDGE

INTVN_SVCPRV_RLSHPTYP_TYPE_CODE




Table 1–2 (Cont.) Records in the C_LOAD_PARAM Table and Configuring Code Types







INTVN_SVCPRV_RLSHPTYP_CODE INTVN_SVCPRV_RLSHPTYP_ATTNDG_SVCPRV


PROCEDURE_CODE PROC_CD

LOAD_PROCEDURE_TYPE_PROCEDURE_BRIDGE

PROCEDURE_CODE 'PROC_CD'

LOAD_PROCEDURE_TYPE_PROCEDURE_BRIDGE

PROCEDURE_CODE_INFA PROC_CD

LOAD_PROC_OUTCOME_DIMENSION

PROC_OUTCM_CODE INTVN_OUTCM_CD

LOAD_RACE_DIMENSION RACE_CODE 'RC_CD'

LOAD_RESEARCH_PATIENT_D PRTY_ADDR_TYP_EML PRTY_ADDR_TYP_EML

LOAD_RESEARCH_PATIENT_D PRTY_ADDR_TYP_HME PRTY_ADDR_TYP_HME

LOAD_RESEARCH_PATIENT_D PRTY_ADDR_TYP PRTY_ADDR_TYP

LOAD_RESEARCH_PATIENT_D CNTCT_INFO_SUBTYP_TELE CNTCT_INFO_SUBTYP_TELE

LOAD_RESEARCH_PATIENT_D CNTCT_INFO_SUBTYP CNTCT_INFO_SUBTYP

LOAD_RESEARCH_PATIENT_D CNTCT_INFO_SUBTYP_EML CNTCT_INFO_SUBTYP_EML

LOAD_RESEARCH_PATIENT_D ADDR_STATUS_CODE PRTY_ADDR_STCD_ACTV

LOAD_SBJ_GRP_SBJ_DHL SBJ_GRP_TYPE_CODE RLSHPTYPD_HMN_SUBJ_STDY_GRP

LOAD_SERVICE_PROVIDER_DIMENSION

SERVICE_PROVIDER_CODE 'SVCPRV_TYP_CD'

LOAD_SPECIALTY_DIMENSION SPECIALTY_CODE 'SVCPRV_SPEC_CD'

LOAD_SPECIMEN_DIMENSION SPECIMEN_TYPE_CODE 'SPCMN_TYP_CD'

LOAD_SPECIMEN_PATIENT_BRIDGE VENDOR_CODE SPP_SVCPRV_RLSHPTYP

LOAD_SPECIMEN_SUBJECT_BRIDGE VENDOR_CODE SPP_SVCPRV_RLSHPTYP

LOAD_SUBADMN_OUTCOME_DIMENSION

SUBADMN_OUTCOME_CODE_TYPE 'SUBADMN_OUTCM_CD'

LOAD_SUBADMN_PATIENT_BRIDGE ENC_FAC_RLSHPTYP_TYPE_CODE ENC_FAC_RLSHPTYP

LOAD_SUBADMN_PATIENT_BRIDGE INTVN_SVCPRV_RLSHPTYP_TYPE_CODE


LOAD_SUBADMN_PATIENT_BRIDGE INTVN_SVCPRV_RLSHPTYP_CODE INTVN_SVCPRV_RLSHPTYP_ATTNDG_SVCPRV

LOAD_SUBADMN_PATIENT_BRIDGE ENC_FAC_RLSHPTYP_CODE ENC_FAC_RLSHPTYP_PRMRY_CARE_SITE

LOAD_SUBADMN_SUBJECT_BRIDGE ENC_FAC_RLSHPTYP_CODE ENC_FAC_RLSHPTYP_PRMRY_CARE_SITE

LOAD_SUBADMN_SUBJECT_BRIDGE INTVN_SVCPRV_RLSHPTYP_TYPE_CODE


LOAD_SUBADMN_SUBJECT_BRIDGE INTVN_SVCPRV_RLSHPTYP_CODE INTVN_SVCPRV_RLSHPTYP_ATTNDG_SVCPRV

LOAD_SUBADMN_SUBJECT_BRIDGE ENC_FAC_RLSHPTYP_TYPE_CODE ENC_FAC_RLSHPTYP

LOAD_SUBJECT_D CNTCT_INFO_SUBTYP CNTCT_INFO_SUBTYP

LOAD_SUBJECT_D CNTCT_INFO_SUBTYP_TELE CNTCT_INFO_SUBTYP_TELE

LOAD_SUBJECT_D ADDR_STATUS_CODE PRTY_ADDR_STCD_ACTV

LOAD_SUBJECT_D PRTY_ADDR_TYP PRTY_ADDR_TYP

LOAD_SUBJECT_D PRTY_ADDR_TYP_EML PRTY_ADDR_TYP_EML





Type codes are available in HDM_CD_TYP. Codes are available in HDM_CD_REPOSITORY to accept multiple type codes as per Table 1–2.

Seed values in C_LOAD_PARAM are of the following types:

■ Some seed data PARAM_VAL is in single quotes. To add multiple parameters, add in the same entry as a comma separated list.

For example,

CONSENT_TYPE_CODE needs multiple type codes as parameters, as follows:

'CNSNT_TYP', 'CNSNT_TYP2’, 'CNSNT_TYP3'

LOAD_CONSENT_DIMENSIONW_EHA_CONSENT_DCONSENT_TYPE_CODE'CNSNT_TYP', 'CNSNT_TYP1', 'CNSNT_TYP3', CONSENT TYPE CODE

LOAD_SUBJECT_D CNTCT_INFO_SUBTYP_EML CNTCT_INFO_SUBTYP_EML

LOAD_SUBJECT_D PRTY_ADDR_TYP_HME PRTY_ADDR_TYP_HME

LOAD_SUBJECT_FAMBR_RLSHP_BRIDGE

FAMBR_RLSHP_TYPE_CODE PRTY_RLSHPTYPD_FAM

LOAD_SUBJECT_GROUP_DIMENSION

SUBJ_GRP_TYPE_CODE RLSHPTYPD_HMN_SUBJ_STDY_GRP

LOAD_SUBJECT_HISTORY_SUBJECT_BRIDGE

VALUE_TYPE_CODE TYP_CD


VALUE_BLN VAL_TYP_BLN


VALUE_CODE VAL_TYP_CD


PATIENT_HISTORY_SUBTYP_CODE PT_HX_SUBTYP


PATIENT_SCL_HX_CODE PT_HX_SUBTYP_SCL_HX


PATIENT_ALGY_HX_CODE PT_HX_SUBTYP_ALGY_HX


PATIENT_SUBST_HX_CODE PT_HX_SUBTYP_SUBST_HX


PATIENT_FAM_HX_CODE PT_HX_SUBTYP_FAM_HX

LOAD_TRC_LOOKUP_CODE_TABLE MRTL_STCD MRTL_STCD

LOAD_TRC_LOOKUP_CODE_TABLE GNDR_CD GNDR_CD

LOAD_UOM_DIMENSION UOM_CODE 'UOM_TYP'

Note: ETL accepts multiple parameters for type codes.

Table 1–3 Sample for Multiple Consent Type Code


LOAD_CONSENT_DIMENSIONW_EHA_CONSENT_DCONSENT_TYPE_CODE

CONSENT TYPE CODE 'CNSNT_TYP'



Configuring C_LOAD_DE_IDENTIFY Attributes


■ Some seed data PARAM_VAL is not in single quotes. To add multiple parameters, add in another entry with different PARAM_VAL.

For example,

LOAD_DIAGNOSIS_DIMENSIONW_EHA_DIAGNOSIS_DDIAGNOSIS_CODECNRN_CDDIAGNOSIS CODE

DIAGNOSIS_CODE requires multiple type codes as parameters:

CNRN_CD,CNRN_CD2,CNRN_CD3

LOAD_DIAGNOSIS_DIMENSIONW_EHA_DIAGNOSIS_DDIAGNOSIS_CODECNRN_CDDIAGNOSIS CODE

LOAD_DIAGNOSIS_DIMENSIONW_EHA_DIAGNOSIS_DDIAGNOSIS_CODECNRN_CD1DIAGNOSIS CODE

LOAD_DIAGNOSIS_DIMENSIONW_EHA_DIAGNOSIS_DDIAGNOSIS_CODECNRN_CD3DIAGNOSIS CODE

For PACKAGE_NAME records containing SEED_NAV_RECORDS, the PARAM_VALUE fields may or may not change. These records are required to populate NAV records in all dimension tables (%_D).

1.2 Configuring C_LOAD_DE_IDENTIFY AttributesThe C_LOAD_DE_IDENTIFY table stores deidentification attributes and their values for the deidentification process. Deidentification is the process of removing or masking identifiable information such patient's name, medical record number, birth date, and social security number from medical records, to protect patient privacy.

Table 1–5 is loaded with the default seed data when the application is installed successfully. You can change the values for the DE_IDENTITY_VALUE and DE_IDENTITY_FLG fields according to your business needs. The default configuration is to move the value of patient's deidentification attributes as is from HDWF to CDM. Oracle recommends that you enable masking these attributes. The attributes of the table are described below.

Table 1–4 Sample for Multiple Concern Code Type


LOAD_DIAGNOSIS_DIMENSIONW_EHA_DIAGNOSIS_DDIAGNOSIS_CODE

DIAGNOSIS CODE CNRN_CD

Table 1–5 C_LOAD_DE_IDENTIFY Table Attributes

Column Name Column Type Description

PACKAGE_NAME VARCHAR2 (300) Name of the ODI package that includes the variable, full, and incremental interfaces.

TARGET_TABLE_NAME VARCHAR2 (80) Name of the main target table that is loaded by this package.

PARAM_NAME VARCHAR2 (80) Name of the parameter used in the interface.

PARAM_DATA_TYPE VARCHAR2 (80) Data type of the parameter. The supported data types are varchar, number, and date.

DE_IDENTITY_VALUE VARCHAR2 (4000) Deidentity value of the parameter used in the interface. This field contains value when the DE_IDENTITY_FLG is set to S.



You can select any one of the following masking options:

■ Populate HDM values as is to the corresponding CDM attributes (set DE_IDENTITY_FLG to null).

■ Populate a standard value to the CDM deidentification attributes (masking with constant value).

■ Populate a calculated value to the CDM deidentification attributes (masking with a calculated value).

The configuration table C_LOAD_DE_IDENTIFY is created to select any one of the above options. The following deidentification functions are created for obtaining the calculated value of each type of value (for example, CHAR, NUMBER, and DATE). These are:

■ CUSTOM_HDM_DATE_DE_IDENTIFY (…) - user-defined function to encrypt a DATE attribute.

■ CUSTOM_HDM_NUMBER_DE_IDENTIFY (…) - user-defined function to encrypt a NUMBER attribute.

■ CUSTOM_HDM_STRING_DE_IDENTIFY (…) - user-defined function to encrypt a CHAR or STRING attribute.

You can change the logic of these functions. You can use the DE_IDENTITY_FLG_OBF and DE_IDENTITY_VALUE fields in the C_LOAD_DE_IDENTIFY table to select the option for any deidentification attribute.

Each deidentification attribute has a corresponding record in this table. You must provide S or C values for each record in the DE_IDENTITY_FLG_OBF field, null or 'N' for each record in the DE_IDENTITY_FLG based on the following criteria:

■ If you do not want to mask any attribute at any time, leave the DE_IDENTITY_FLG_OBF value as null. In this case, the value from the HDWF attribute is populated to the corresponding attribute of CDM.

■ If you want to mask the value of the attribute, configure the DE_IDENTIFY_FLG_OBF as 'S', and configure the value of DE_IDENTIFY_VALUE with the masked value that you want to populate into the corresponding CDM attribute.

For example, if you want to mask the value of DIAGNOSIS_ONSET_DT attribute of W_EHA_DX_PATIENT_H to '01-01-1900', configure the record as shown in Table 1–6.

DE_IDENTITY_FLG VARCHAR2 (1) Represents the type of value supplied to the parameter null or N.

Null - ETL populates actual values from HDM to CDM.

N - ETL populates null.

DE_IDENTITY_FLG_OBF VARCHAR2 (1) Represents the type of value supplied to the parameter.

S represents standard value.

C represents the custom value. This calls your customized PL/SQL function.


Table 1–5 (Cont.) C_LOAD_DE_IDENTIFY Table Attributes




■ If you want to populate standard values for any attribute, provide value S in this field. Also, provide the standard value that is populated in CDM in the DE_IDENTITY_VALUE field.

■ If you want to populate calculated values, provide value C in this field. The value is populated with any of the functions listed above depending on the data type of the attribute.

Table 1–7 displays the default values populated in the C_LOAD_DE_IDENTIFY table.

Table 1–6 C_LOAD_DE_IDENTIFY Table Seed Data

PACKAGE_NAME

TARGET_TABLE_NAME PARAM_NAME

PARAM_DATA_TYPE

DE_IDENTITY_VALUE

DE_ IDENTITY_ FLG_OBF

DE_IDENTITY_FLG

INSERT_DT

LOAD_DX_PATIENT_BRIDGE

W_EHA_DX_PATIENT_H

DIAGNOSIS_ONSET_DT

DATE 01/01/1900 00:00:00

S null NULL

Note: Ensure that:

■ the PARAM_DATA_TYPE column in the C_LOAD_DE_IDENTIFY table is configured to the data type column of the masked attribute.

■ the value of PARAM_VALUE is correctly formatted. Do not prefix or suffix quotes to the literal configured.

– The date field must be in the MM/DD/YYYY HH24:MI:SS format.

– The varchar field must be a varchar.

– The number field must be a valid number.

Table 1–7 C_LOAD_DE_IDENTIFY Table Seed Data

PACKAGE_NAME


PARAM_DATA_TYPE

DE_IDENTITY_VALUE

DE_IDENTITY_FLG

DE_IDENTITY_ FLG_OBF

LOAD_CONSENT_PATIENT_BRIDGE

W_EHA_CONSENT_PATIENT_H

CNSNT_EFF_STRT_DT

DATE 1/1/1920 0:01 null S



CNSNT_EFF_END_DT

DATE 1/31/1920 23:59 null S

LOAD_CONSENT_SUBJECT_BRIDGE

W_EHA_CONSENT_SUBJECT_H

CNSNT_EFF_STRT_DT

DATE 1/1/1920 0:01 null S



CNSNT_EFF_END_DT

DATE 1/31/1920 23:59 null S


W_EHA_DX_PATIENT_H

AGE_AT_FIRST_ONSET

NUMBER 50 null S


W_EHA_DX_PATIENT_H

DIAGNOSIS_END_DT

DATE 1/31/1920 23:59 null S




W_EHA_DX_PATIENT_H

DIAGNOSIS_ONSET_DT

DATE 1/1/1920 0:01 null S


W_EHA_DX_PATIENT_H

DIAGNOSIS_REPORTED_DT

DATE 1/1/1920 0:01 null S

LOAD_DX_SUBJECT_BRIDGE

W_EHA_DX_SUBJECT_H

AGE_AT_FIRST_ONSET

NUMBER 50 null S


W_EHA_DX_SUBJECT_H


DATE 1/1/1920 0:01 null S


W_EHA_DX_SUBJECT_H

DIAGNOSIS_END_DT

DATE 1/31/1920 23:59 null S


W_EHA_DX_SUBJECT_H

DIAGNOSIS_ONSET_DT

DATE 1/1/1920 0:01 null S


W_EHA_ENC_PATIENT_H

ENC_STRT_DT DATE 1/1/1920 0:01 null S


W_EHA_ENC_PATIENT_H

ENC_END_DT DATE 1/31/1920 23:59 null S

LOAD_OBSV_PATIENT_BRIDGE

W_EHA_OBSV_PATIENT_H

OBSV_DT DATE 1/1/1920 0:01 null S

LOAD_OBSV_SUBJECT_BRIDGE

W_EHA_OBSV_SUBJECT_H

OBSV_DT DATE 1/1/1920 0:01 null S


W_EHA_PT_HISTORY_PT_H

PATIENT_HISTORY_START_DT

DATE 1/1/1920 0:01 null S



PATIENT_HISTORY_END_DT

DATE 1/31/1920 23:59 null S


W_EHA_PROC_PATIENT_H

PROCEDURE_START_DT

DATE 1/1/1920 0:01 null S



PROCEDURE_END_DT

DATE 1/31/1920 23:59 null S


W_EHA_PROC_SUBJECT_H

PROCEDURE_END_DT

DATE 1/31/1920 23:59 null S



PROCEDURE_START_DT

DATE 1/1/1920 0:01 null S

Table 1–7 (Cont.) C_LOAD_DE_IDENTIFY Table Seed Data

PACKAGE_NAME


PARAM_DATA_TYPE

DE_IDENTITY_VALUE

DE_IDENTITY_FLG




LOAD_RESEARCH_PATIENT_D

W_EHA_RESEARCH_PATIENT_D

DECEASED_DT

DATE 1/1/2000 0:01 null S



DOB_DATE DATE 1/1/1900 12:00 null S



STRT_ADDR STRING Obfuscated null S



CITY STRING ANCHORAGE null S



POSTAL_CODE

STRING 99506 null S



PATIENT_NAME

STRING Obfuscated null S



PATIENT_IDENTIFIER

STRING S null S

LOAD_SPECIMEN_PATIENT_BRIDGE

W_EHA_SPECIMEN_PATIENT_H

SPECIMEN_COLLECTION_DT

DATE 1/1/1920 0:01 null S

LOAD_SPECIMEN_SUBJECT_BRIDGE

W_EHA_SPECIMEN_SUBJECT_H


DATE 1/1/1920 0:01 null S

LOAD_SUBADMN_PATIENT_BRIDGE

W_EHA_SUBADMN_PATIENT_H

INTVN_STRT_DT

DATE 1/1/1920 0:01 null S

LOAD_SUBADMN_PATIENT_BRIDGE


INTVN_END_DT

DATE 1/31/1920 23:59 null S

LOAD_SUBADMN_SUBJECT_BRIDGE

W_EHA_SUBADMN_SUBJECT_H

INTVN_END_DT

DATE 1/31/1920 23:59 null S

LOAD_SUBADMN_SUBJECT_BRIDGE


INTVN_STRT_DT

DATE 1/1/1920 0:01 null S

LOAD_SUBJECT_D

W_EHA_SUBJECT_D

PATIENT_NAME

STRING Obfuscated null S

LOAD_SUBJECT_D

W_EHA_SUBJECT_D

STRT_ADDR STRING Obfuscated null S

LOAD_SUBJECT_D

W_EHA_SUBJECT_D

DECEASED_DT

DATE 1/1/2000 0:01 null S

LOAD_SUBJECT_D

W_EHA_SUBJECT_D

POSTAL_CODE

STRING 11111 null S

LOAD_SUBJECT_D

W_EHA_SUBJECT_D

DOB_DATE DATE 1/1/1900 12:00 null S

LOAD_SUBJECT_D

W_EHA_SUBJECT_D

CITY STRING ANCHORAGE null S


PACKAGE_NAME


PARAM_DATA_TYPE

DE_IDENTITY_VALUE

DE_IDENTITY_FLG


Standard Configuration of the C_COHORT_PROCEDURE_TYPE Table


1.3 Standard Configuration of the C_COHORT_PROCEDURE_TYPE TableThe C_COHORT_PROCEDURE_TYPE table stores different procedure types used in TRC reports. The attributes of the table are as follows:

The C_COHORT_PROCEDURE_TYPE table contains seed data as shown in Table 1–9. Oracle recommends that you not modify the seed data in this table as these procedure types are used in TRC reports.

LOAD_SUBJECT_D

W_EHA_SUBJECT_D

END_DT DATE 1/31/1920 23:59 null S

LOAD_SUBJECT_D

W_EHA_SUBJECT_D

PATIENT_IDENTIFIER

STRING S null S

LOAD_SUBJECT_D

W_EHA_SUBJECT_D

START_DT DATE 1/1/1920 0:01 null S

LOAD_SUBJECT_D

W_EHA_SUBJECT_D

ENRLMT_DT DATE 1/1/1900 12:00 null S


W_EHA_SBJ_HISTORY_SBJ_H


DATE 1/1/1920 0:01 null S




DATE 1/31/1920 23:59 null S



CNSNT_EFF_END_DT

DATE 1/31/1920 23:59 null S



CNSNT_EFF_STRT_DT

DATE 1/1/1920 0:01 null S



CNSNT_EFF_END_DT

DATE 1/31/1920 23:59 null S

Table 1–8 C_COHORT_PROCEDURE_TYPE Table Attributes


COHORT_PROC_TYP_ID

NUMBER(10,0) The surrogate key for procedure type.

COHORT_PROC_TYP_CODE

VARCHAR2(80 BYTE) The actual (functional) code of procedure type.


UPDATE_DT DATE Date when the record was last updated.

DELETE_FLG CHAR(1 BYTE) The soft delete flag of the record.

INTEGRATION_ID VARCHAR2(400 BYTE) The integration ID of each procedure type code.

DATASOURCE_NUM_ID

NUMBER(10,0) The data source number ID of each procedure type code.


PACKAGE_NAME


PARAM_DATA_TYPE

DE_IDENTITY_VALUE

DE_IDENTITY_FLG


ETL Global Parameters


1.4 ETL Global ParametersTable 1–10 lists the global parameters applicable for all ETLs. Oracle recommends that you not make any modification to these parameters.

Table 1–9 C_COHORT_PROCEDURE_TYPE Table Seed Data

COHORT_PROC_TYP_ID

COHORT_PROC_TYP_CODE

INSERT_DT UPDATE_DT

DELETE_FLG INTEGRATION_ID

DATASOURCE_NUM_ID

1 PROC_CHEMO_CODE 11-JAN-11 11-JAN-11 N PROC_CHEMO_CODE

1

2 PROC_ONCOLOGY_CODE

11-JAN-11 11-JAN-11 N PROC_ONCOLOGY_CODE

1

3 PROC_SURGERY_CODE

11-JAN-11 11-JAN-11 N PROC_SURGERY_CODE

1

4 PROC_CD 11-Jan-11 11-Jan-11 N PROC_CD 1

Table 1–10 ETL Global Parameters in C_LOAD_CONFIG Table (C_Load_config)

PACKAGE_NAME PARAM_NAME PARAM_VALUE DESCRIPTION

GLOBAL SEPERATOR ~ NULL

SEED_NAV_RECORDS $NAV_VARCHAR2 NAV NULL

SEED_NAV_RECORDS $NAV_CHAR 1 NULL

SEED_NAV_RECORDS $NAV_NUMBER 9999 NULL

SEED_NAV_RECORDS $NAV_WID -1 NULL

SEED_NAV_RECORDS $NAV_DESC Value not available NULL

SEED_NAV_RECORDS $NAV_DATE 1-Jan-00 NULL

SEED_NAV_RECORDS $NAV_CODE Value not available NULL

2

Virtual Private Database 2-1

2Virtual Private Database

This chapter contains the following topics:

■ Section 2.1, "Overview"

■ Section 2.2, "HIPAA Attribute Groupings"

■ Section 2.3, "Assigning Users to Virtual Private Database Configurations"

■ Section 2.4, "Auditing Trail of Configurations and Assignments"

■ Section 2.5, "Enabling Row Access to Virtual Private Database Data"

■ Section 2.6, "Global Policy for All HIPAA Attributes"

■ Section 2.7, "Virtual Private Database Configuration Limitations"

2.1 OverviewThe TRC Cohort Data Model has patient identifiable data, also referred to as Health Insurance Portability and Accountability Act (HIPAA) attributes. This model stores obfuscated values for each of these attributes. The HIPAA attributes are protected with policies using row level security. These policies are always enabled and keep the data protected. You cannot query this data unless you have the right privileges. The mode of these policies return NULL values for any attribute if you do not have privileges. When the optional mode is enabled, the query does not return any data if you do not have right privileges. By default, this mode is disabled. You can enable it globally, if required.

The code for implementing privileges to view HIPAA data are all contained in the VPD_UTIL package in the CDM schema. The following sections describe the VPD_UTIL package and how to implement secure access to patient identifying data.

2.2 HIPAA Attribute GroupingsThe VPD_UTIL package contains a main stored procedure for creating configuration of patient and subject information. Each configuration is assigned a study primary key for patient and (or) subject records. You can provide a unique name and expiry date for each configuration to deactivate it on a specific date. There are parameters, for this stored procedure, used for all attribute groupings. Attributes are grouped based on the functionality. The stored procedure is listed as follows:

procedure add_vpd_config ( i_config_name in varchar2 default null ,i_PT_CONSENT in char default 'N' ,i_SUBJ_CONSENT in char default 'N' ,i_PT_DX in char default 'N'

HIPAA Attribute Groupings


,i_SUBJ_DX in char default 'N' ,i_PT_ENC in char default 'N' ,i_PT_OBSV in char default 'N' ,i_SUBJ_OBSV in char default 'N' ,i_PT_PROC in char default 'N' ,i_SUBJ_PROC in char default 'N' ,i_PT_HIST in char default 'N' ,i_PT_ID in char default 'N' ,i_PT_DATE in char default 'N' ,i_PT_ADD in char default 'N' ,i_PT_NAME in char default 'N' ,i_SUBJ_HIST in char default 'N' ,i_PT_SPEC in char default 'N' ,i_SUBJ_SPEC in char default 'N' ,i_PT_MED in char default 'N' ,i_SUBJ_MED in char default 'N' ,i_SUBJ_ID in char default 'N' ,i_SUBJ_DATE in char default 'N' ,i_SUBJ_ADD in char default 'N' ,i_SUBJ_NAME in char default 'N' ,i_description in varchar2 default null ,i_expiration_date in date default null ,i_subject_study in varchar2 default null ,i_patient_group in varchar2 default null );

The parameters of each attribute group map to the following tables and columns:

Table 2–1 Identifiable Attribute Groupings

Group Columns Column(s)

PT_CONSENT W_EHA_CONSENT_PATIENT_H CONSENT_START_DT, CONSENT_END_DT

SUBJ_CONSENT W_EHA_CONSENT_SUBJECT_H CONSENT_START_DT, CONSENT_END_DT

PT_DX W_EHA_DX_PATIENT_H DIAGNOSIS_ONSET_DT, DIAGNOSIS_REPORTED_DT, DIAGNOSIS_END_DT, AGE_AT_FIRST_ONSET

SUBJ_DX W_EHA_DX_SUBJECT_H DIAGNOSIS_ONSET_DT, DIAGNOSIS_REPORTED_DT, DIAGNOSIS_END_DT, AGE_AT_FIRST_ONSET

PT_ENC W_EHA_ENC_PATIENT_H ENCOUNTER_START_DT, ENCOUNTER_END_DT

PT_OBSV W_EHA_OBSV_PATIENT_H OBSV_DT

SUBJ_OBSV W_EHA_OBSV_SUBJECT_H OBSV_DT

PT_PROC W_EHA_PROC_PATIENT_H PROCEDURE_START_DT, PROCEDURE_END_DT

SUBJ_PROC W_EHA_PROC_SUBJECT_H PROCEDURE_START_DT, PROCEDURE_END_DT

PT_HIST W_EHA_PT_HISTORY_PT_H PATIENT_HISTORY_START_DT, PATIENT_HISTORY_END_DT

PT_ID W_EHA_RESEARCH_PATIENT_D PATIENT_IDENTIFIER

PT_DATE - DOB, DECEASED_DT

PT_ADD - CITY, POSTAL_CODE, STREET_ADDRESS_1, STREET_ADDRESS_2, STREET_ADDRESS_3

Auditing Trail of Configurations and Assignments

Virtual Private Database 2-3

2.3 Assigning Users to Virtual Private Database ConfigurationsOnce the configuration is created, there are stored procedures that let specific users be assigned to use these configurations. The user name can specify both database and WebLogic users. Every query executed by the TRC user interface passes the WebLogic user information in the session attributes. The Virtual Private Database (VPD) policy code uses this information to check for valid policies. You can specify an expiry data for each user assigned. This lets users be assigned to match how IRB permissions are usually granted to specific investigators. The list of stored procedures in the VPD_UTIL package used to assign users to VPD configurations is as follows:

procedure add_config_user ( i_existing_config_id in number , i_user_name in varchar2 ,i_expiration_date in date default null ); procedure add_config_user ( i_existing_config_name in varchar2 , i_user_name in varchar2 ,i_expiration_date in date default null );

2.4 Auditing Trail of Configurations and AssignmentsThe configurations created and users assigned to each configuration are never deleted. This makes for a consistent audit trail that is accessed by all records to HIPAA attributes. All the records used to assign users keep a status so that expired user assignments and configurations will simply update the status to reflect this.

PT_NAME - FIRST_NAME, MIDDLE_NAME, LAST_NAME

SUBJ_HIST W_EHA_SBJ_HISTORY_SBJ_H SUBJECT_HISTORY_START_DT, SUBJECT_HISTORY_END_DT

PT_SPEC W_EHA_SPECIMEN_PATIENT_H SPECIMEN_COLLECTION_DT

SUBJ_SPEC W_EHA_SPECIMEN_SUBJECT_H SPECIMEN_COLLECTION_DT

PT_MED W_EHA_SUBADMN_PATIENT_H SUBADMN_START_DT, SUBADMN_END_DT

SUBJ_MED W_EHA_SUBADMN_SUBJECT_H SUBADMN_START_DT, SUBADMN_END_DT

SUBJ_ID W_EHA_SUBJECT_D SUBJECT_IDENTIFIER

SUBJ_DATE - DOB, DECEASED_DT

SUBJ_ADD - CITY, POSTAL_CODE, STREET_ADDRESS_1, STREET_ADDRESS_2, STREET_ADDRESS_3

SUBJ_NAME - FIRST_NAME, MIDDLE_NAME, LAST_NAME

Table 2–1 (Cont.) Identifiable Attribute Groupings

Group Columns Column(s)

Enabling Row Access to Virtual Private Database Data


2.5 Enabling Row Access to Virtual Private Database DataA stored procedure can be used to let each row of the tables with HIPAA attributes be visible to only the users that have been enabled access to each configuration. This stored procedure in the VPD_UTIL package is as follows:

procedure enable_row_filter_policies ( enable in boolean );

2.6 Global Policy for All HIPAA AttributesThere is a global policy that permits access to all patient and subject HIPAA attributes. It has an ID value of 1 and is created while installing the database. The purpose of this global policy is to permit specific users, that have elevated permissions and are regulated, to view the HIPAA data at all times.

2.7 Virtual Private Database Configuration LimitationsThe current implementation of the VPD uses a NUMBER column in each table to indicate which policies are valid for each row in tables with HIPAA attributes. Each active configuration uses a bit of an Oracle NUMBER datatype. The Oracle NUMBER datatype supports 127 bits. This means that there is a limitation of 126 active configurations to access any set of patient or subject data. This will be changed in subsequent releases to support more active configurations.

Note: There will be a record of all users assigned access to this global policy with the aforementioned audit capabilities of the tables.

Part IIPart II Oracle Health Sciences Translational

Research Center for Informatica

This part of the guide contains the following chapters:

■ Chapter 4, "Architecture"

■ Chapter 3, "Informatica ETL Configuration"

■ Chapter 5, "Executing Informatica ETLs"

3

Informatica ETL Configuration 3-1

3Informatica ETL Configuration

This chapter describes the different configuration steps required in different cases for INFA ETLs. It contains the following topics:

■ Section 3.1, "Standard Configuration of C_LOAD_DATES_INFA Table"

■ Section 3.2, "Configuring Informatica Workflows and Global Parameter File"

3.1 Standard Configuration of C_LOAD_DATES_INFA TableOnce TRC is installed and install_infa_script.sql has run successfully for INFA ETLs, the C_LOAD_DATES_INFA table is created in the HDWF schema and populated with the default seed data. The C_LOAD_DATES_INFA table is called the job control table. It is used to capture the last execution date, current execution date, and ETL_PROC_WID for each ETL. The same is used in subsequent incremental loads and therefore, this table is loaded automatically during the execution of Informatica ETLs. You do not have to update or change this table.

3.2 Configuring Informatica Workflows and Global Parameter FilePerform the following steps to import and configure the Informatica ETLs:

1. Download the Informatica workflows, wf_SIL_CDM.xml_, from the media pack and save it on your machine.

2. Create an Informatica repository EHA_CDM.

3. Create a directory EHA_CDM_ETL in the Informatica repository you created in step 2.

Table 3–1 Attributes of C_LOAD_DATES_INFA in HDWF Schema

COLUMN_NAME DATA_TYPE Description

ETL_LOAD_DT_ID NUMBER(38,0) Primary key. Serial number against the row in this table.

ENTITY_NM VARCHAR2(80) CDM target table name.

ETL_PROC_WID NUMBER(10,0) Unique identifier that populates all records in that table for a particular load.

LAST_EXEC_DT DATE Last extracted timestamp of the previous load.

CURRENT_EXEC_DT DATE Current extraction timestamp of the current load.


UPDATE_DT DATE Date when the record is updated.

ENTERPRISE_ID NUMBER NOT NULL Unique identifier for an enterprise in a multi-enterprise environment.

Configuring Informatica Workflows and Global Parameter File


4. Import the workflows wf_SIL_CDM.xml to EHA_ CDM_ETL folder from the Informatica Repository Manager Browser.

5. Reuse objects if there are any conflicts while importing.

6. Create the following relational connections in the Informatica Workflow Manager and make a note of the connection objects.

■ ORACLE_HDWF to connect to schema containing HDWF tables.

■ ORACLE_CDM to connect to schema containing CDM tables.

■ ORACLE_APPS to connect to schema containing APPS tables.

7. Configure the following values in INFA ETL global parameter file SIL_CDM_Global_Param_File.prm:

$$DBSCHEMA_HDWF=<HDWF Schema Name>$$DBSCHEMA_CDM=<CDM Schema Name>$$DBSCHEMA_APPS=<APPS Schema Name>$DBConnection_HDWF=ORACLE_HDWF$DBConnection_CDM=ORACLE_CDM$DBConnection_APPS=ORACLE_APPS$$VPD_POLICIES=< VPD_POLICIES_VALUE>

8. Copy the updated global parameter file to ${INFA_INSTALL_DIR}/server/infa_shared/SrcFiles.

9. For column PARAM_VAL of the CDM schema table, C_LOAD_CONFIG, use date format as MM/DD/YYYY.

10. Associate the integration service to the workflows and execute.

4

Architecture 4-1

4Architecture

This chapter describes the TRC architecture for Informatica. It contains the following topics:


■ Section 4.2, "ETL Behavior"

■ Section 4.3, "Informatica Repository Artifacts"

4.1 OverviewOracle Health Sciences Cohort Explorer (CE) is an analytical reporting application. This section outlines the development process and best practices to be followed for Informatica, which is used as the ETL tool for CE.

TRC architecture includes the following principal components:

■ A predefined Cohort Data Model containing tables of patient identifiable medical information and configuration data.

■ Prebuilt Informatica based mappings and workflows that are designed to extract patient related data from HDWF.

Figure 4–1 TRC Architecture

ETL Behavior


4.2 ETL BehaviorFollowing are key system attributes and how they influence loading from HDWF tables to data mart tables:

■ DELETE_FLG - The soft delete flag status determines whether a record in the data mart is deleted or not. If the delete flag is set to Y in any of the source tables, the target record is automatically soft deleted.

■ INTEGRATION_ID - This is populated from the INTEGRATION_ID of the main driving table. If there is more than one driving table, the INTEGRATION_IDs of these tables are concatenated with a separator.

■ DATASOURCE_NUM_ID - This is populated from the DATASOURCE_NUM_ID of the main driving table.

■ UPDATE_DT - UPDATE_DT - This determines when the record is created or updated in HDWF. If a record is updated after completion of the last ETL load, it is selected for incremental load. UPDATE_DT of one or more source tables associated with the data mart table, determines whether the record is selected. When more than one source table exists, the incremental load is performed if the UPDATE_DT of any of the source table records is later than the last load date and time.

■ CURRENT_FLG - If multiple versions of the record are available in HDWF, only the current version is selected. The current version can be ascertained in HDWF using the CURRENT_FLG attribute.

■ Masking Patient INTEGRATION_ID - To mask patient information, Patient INTEGRATION_ID from HDWF is not loaded into data mart, as it may contain patient identification information. Instead, the PT_ID from HDWF is populated to data mart.

■ Populating UOM_WID - If the ETL does not resolve UOM_WID while loading data into the data mart, the UOM_WID is populated with NAV value. The actual value of NAV is picked up from the ETL parameter table C_LOAD_PARAM_INFA in HDWF.

■ Versioning Logic - Versioning is not supported in CDM. For each integration ID in HDWF, there is a single record in CDM. If there are multiple versions in HDWF, the most current version is loaded in the data mart. You can determine the current version in HDWF using the CURRENT_FLG attribute.

The Informatica ETL behavior or architecture is as follows:

1. A view is created on top of the (joining) HDWF tables in the HDWF schema for loading each target in CDM. Informatica ETLs read these views as source and load target table in CDM.

2. A temporary or staging table is created in the CDM schema to store the view output created above (for _H, _DHL, and _F target tables). INFA ETLs extract these views in HDWF and load actual target tables in CDM (lookup to CDM tables through a dblink) for all the dimension tables, as the volume is not huge for dimension tables. Since the volume is huge for bridge (_F, _H, and _DHL) tables in CDM, INFA ETLs extract the view from HDWF and store them temporarily in the staging tables in CDM. It then loads the actual target table in CDM.

3. A parameter file is generated for each target table to be used in the respective Informatica ETLs from global parameter file, parameter table, job control table, and deidentification table (that is, from SIL_CDM_Global_Param_File.prm, C_LOAD_PARAM, C_LOAD_DATES_INFA, and C_LOAD_DE_IDENTIFY).

4. The current execution time is updated in the job control table at the beginning of each load.

Informatica Repository Artifacts

Architecture 4-3

5. The HDWF view is read as source and data is loaded into a temporary table residing in the CDM schema. This step is applicable only for all _H,_DHL, and _F tables.

6. The view or staging tables is read as source and data is loaded into the target tables in the CDM schema. It loads the actual target table in CDM, either from view in HDWF (for dimensions), or from staging tables in CDM for bridge and fact tables (for _F, _H, and _DHL tables).

7. The last execution time is updated in the job control table for the next incremental load.

8. Once the initial load is complete, all other source extractions occur incrementally.

4.3 Informatica Repository ArtifactsThis section describes the Informatica based ETL artifacts like source, target, mappings, sessions, worklets, workflows, and so on that are designed to extract data from HDWF and load CDM tables.

EHA_CDM_ETL is the directory (folder created while importing the Informatica ETLs as mentioned in the Oracle Health Sciences Translation Research Center Installation Guide) in the Informatica repository that contains all the Informatica ETL objects.

SourcesIn Source Analyzer, define the source definitions that are used in mapping. You can either import a source or manually create them. All the tables, views, files that are used as source in Informatica ETLs are imported or created in the repository as shown in Figure 4–2.

Note:

■ The Cohort ETL assumes that on the HDWF side each code can only be associated with one code set. If not W_EHA_OBSERVATION_D and W_EHA_PATIENT_HISTORY_D ETLS fails with an unique constraint error.

■ The Cohort ETL assumes that a subject can only correspond to 0 or 1 patient. A patient may have multiple subjects associated with it but not the reverse. If not W_EHA_SUBJECT_D ETL fails with an unique constraint error.

Ensure the following criteria are fulfilled before running ETLs:

1. Obfuscated Patient ID (PATIENT_IDENTIFIER_OBF) should never be null.

2. Obfuscated Patient ID should be populated with Unique values.

3. If step 1 and 2 are not fulfilled, then the UI does not work correctly.



Figure 4–2 Repository Navigator

TargetsIn Target Designer, you can create the target definitions that are used in mapping. You can either import a target or manually create them. All the tables and files that are used as target in Informatica ETLs are imported or created in the repository as shown in Figure 4–3.

Figure 4–3 Target Designer

MappingsA mapping is a set of source and target definitions linked by transformation objects that define the rules for data transformation. Mappings represent the data flow between sources and targets. To load each target table in CDM, respective mappings are developed as shown in Figure 4–4.


Architecture 4-5

Figure 4–4 Mapping Designer

SessionsA session is a set of instructions that tells the Informatica Server how and when to move data from sources to targets. Each mapping is associated with respective sessions. To load each target table in CDM, there are two sessions, one for the initial or full load, and other for incremental load as shown in Figure 4–5.

Figure 4–5 Sessions

WorkletsA worklet is an object that represents a set of tasks. To execute a worklet, it has to be placed inside a workflow. Each session is associated with its corresponding worklet. To load each target table in CDM, two worklets are developed, one for the initial or full load, and other for incremental load as shown in Figure 4–6.



Figure 4–6 Worklet

These main worklets are further called in other worklets and moved into the workflows to handle the dependency and to maintain the execution plan.

WorkflowsA workflow is a set of instructions that tell the Informatica server how to execute the tasks. It controls the execution of tasks such as worklets, sessions, commands, emails, and so on. To load the complete set of CDM target tables, the following workflows are developed.

■ wf_SIL_CDM_FULL - is used for initial or full load and is a one-time job.

■ wf_SIL_CDM - is used for incremental load and for respective frequency load.

Figure 4–7 Workflows

Each of these workflows contain eight worklets. Each worklet has several subworklets. And each subworklet has sessions.

Note: These worklets (to load each CDM table) consist of the following sessions:

1. Creates parameter file for the respective target table (used by 2nd and 3rd sessions).

2. Loads the data into the respective CDM target table.

3. Updates the control table for the respective ETL for next run.


Architecture 4-7

Figure 4–8 Workflows and Worklets

Table 4–1 lists the worklets in each of the workflows.

Table 4–1 Worklets and their Description

Worklet Description

wklt_Level1_Load_User_Dimension Loads user dimension

wklt_Level2_Load_All_Other_Dimensions Loads all dimensions in parallel

wklt_Level3_Stored_Procedure_And_Patient_Fact

Loads unspecified records for dimensions and patient fact

wklt_Level4_Load_All_Bridge_Tables Loads all bridge tables in parallel

wklt_LEVEL5_LOAD_UNSPECIFIED_RECORDS_FOR_BRIDGE_TABLES

Loads unspecified records for bridge tables

wklt_Level6_Load_Trc_Lookup_Table Loads the TRC_LOOKUP_CODE table in the APPS schema

wklt_Level7_Load_Protocol_Tables Loads protocol related tables

wklt_SIL_CDM_LOAD_COHORT_A Loads W_EHA_COHORT_A in CDM



5

Executing Informatica ETLs 5-1

5Executing Informatica ETLs

This chapter describes about INFA ETL workflows and the logic for full load and incremental load. It contains the following topics:.

■ Section 5.1, "Introduction"

■ Section 5.2, "Executing Full Load"

■ Section 5.3, "Executing Incremental Load"

5.1 IntroductionIn the ETL process, data warehouse must be deployed (full load), and subsequently recently created, changed, or deleted records are incrementally applied to the data warehouse (incremental load). The following workflows are provided:

■ wf_SIL_CDM_FULL for full load

■ wf_SIL_CDM for incremental load

The full load workflow is designed to load data mart tables in a particular sequence with certain assumptions about the volume of data available or expected in different tables. If the volume of data is extremely large, execution may result in resource contention, which declines the overall system performance. Oracle recommends that you formulate a load strategy based on the volume of data. The strategy must minimize the execution time by maximizing parallel executions considering resource constraints.

5.2 Executing Full LoadThis is a one-time load that will process the initial data from source (HDWF) and load it to the target tables (CDM). In full load workflow, the names for sessions, worklets, workflows are suffixed with _FULL. It supports bulk insert.

The difference between the incremental and full load INFA code is the date filter condition in the source qualifier SQL level, based on which it extracts the data. For full load, the date filter condition is not included since the code has to process all initial source data to target and it is a one-time load. Once the initial load process is complete, if any data is changed in the source table, the updated records are handled in incremental load processing.

The full load workflow (wf_SIL_CDM_FULL) runs the ETLs in the following order:

1. Load user dimension.

2. Load all other dimensions in parallel.

Executing Full Load


3. Load unspecified records in all _D tables.

4. Load W_EHA_RESEARCH_PATIENT_F and W_EHA_SUBJECT_F.

5. Load all bridge tables in parallel.

6. Load unspecified records for bridge tables.

7. LOAD W_EHA_COHORT_A

8. Load TRC lookup code table.

9. Load protocol related tables.

To execute full load workflow, perform the following steps:

1. Navigate to Informatica Power Center Workflow Manager.

2. Connect to the folder under repository where Informatica ETLs are exported.

3. Navigate to Workflows > wf_SIL_CDM_FULL.

4. Right-click wf_SIL_CDM_FULL.

5. Select Start Workflow.

Figure 5–1 Executing Full Load

Executing Incremental Load

Executing Informatica ETLs 5-3

5.3 Executing Incremental LoadOnce the initial load process is complete, if any data is changed in the source table, the updated records are handled in incremental load processing. During every incremental load, the ETL reads data that are inserted or updated into HDWF table between last successful execution and current execution of the ETL only. This is implemented using the job control table C_LOAD_DATES_INFA. The LAST_EXEC_DT for a successful ETL run is captured in this table and used when the parameter file is created for the next ETL run by the process.

At the start of each job, the process first updates CURRENT_EXEC_DT to the start time (sysdate) of the job. This ensures that the job reads the data between last successful execution time (LAST_EXEC_DT) and current start time (CURRENT_EXEC_DT). After loading, the process updates LAST_EXEC_DT with the value present in CURRENT_EXEC_DT by adding 1 second, and also increments the ETL_PROC_ID by 1. Each incremental load, while reading the data, extracts only the rows with UPDATE_DT between LAST_EXEC_DT and CURRENT_EXEC_DT. There is a filter condition on source SQL that fetches the data from the source tables, which are inserted or updated between the previous ETL run and current ETL run time, and processes the same. The data filter condition is applied on the driving tables in the query. The following is the code snippet used in the filter condition:

W_EHA_RACE_PATIENT_H_CDM_V.HDM_IND_PRTY_RC_UPDATE_DT betweenTO_DATE ('$$LAST_EXEC_DT','MM/DD/YYYY HH24: MI: SS') and(SELECT CURRENT_EXEC_DT FROM $$DBSCHEMA_HDWF.C_LOAD_DATES_INFA WHERE ENTITY_NM = '$$ENTITY_NM')

The incremental load workflow (wf_SIL_CDM) runs the ETLs in the following order:


2. Load all other dimensions in parallel.

3. Load unspecified records in all _D tables.

4. Load W_EHA_RESEARCH_PATIENT_F and W_EHA_SUBJECT_F.


6. Load unspecified records for bridge tables.

7. LOAD W_EHA_COHORT_A



To execute incremental load workflow, perform the following steps:

1. Navigate to Informatica Power Center Workflow Manager.

2. Connect to the folder under repository where INFA ETLs are exported.

3. Navigate to Workflows > wf_SIL_CDM.

4. Right-click wf_SIL_CDM.

5. Select Start Workflow.

Note: The full load ETL truncates the TRC_Lookup_Code table in the application schema. After the full load is executed successfully, execute trc_lookup_data.sql to populate the seed data again. This script must be run by the application schema user.



Figure 5–2 Executing Incremental Load

Part IIIPart III Oracle Health Sciences Translational

Research Center for Oracle Data Integrator


■ Chapter 6, "Architecture"

■ Chapter 7, "Configuration Steps"

■ Chapter 8, "Executing ETLs"

6

Architecture 6-1

6Architecture

This chapter describes the architecture of TRC. It contains the following topics:


■ Section 6.2, "ETL Behavior"

■ Section 6.3, "Oracle Data Integrator Work Repository Artifacts"

6.1 OverviewTRC architecture includes the following principal components:

■ A predefined CDM containing tables of patient identifiable medical information and configuration data.

■ Pre-built based interfaces that are designed to extract patient related data from HDWF.

6.2 ETL BehaviorThe following are the key system attributes and how they influence loading from HDWF tables to data mart tables:

■ DELETE_FLG - The soft delete flag status determines whether a record in the data mart is deleted or not. Table 2–1 lists the source for each data mart table that determines the soft delete status of a record. If delete flag is set to Y in any of the source tables, the target record is automatically soft deleted.

■ INTEGRATION_ID - This is populated from the INTEGRATION_ID of the main driving table. Appendix A lists the main driving tables, which determine the INTEGRATION_ID. If there is more than one driving tables, the INTEGRATION_IDs of these tables are concatenated with a separator.

■ DATASOURCE_NUM_ID - This is populated from the DATASOURCE_NUM_ID of the main driving table. Appendix A lists the main driving tables.

■ UPDATE_DT - UPDATE_DT of HDWF tables determines when a record is created or updated in HDWF. If a record is updated after completion of the last ETL load, it is picked up for incremental load. UPDATE_DT of one or more source table associated with the data mart table determines if the record is picked. Appendix A lists the source table for each data mart table that determine the updated status of the record. When more than one source table exists, the incremental load is performed if the UPDATE_DT of any of the source table records is later than the last load date and time.

Oracle Data Integrator Work Repository Artifacts


■ CURRENT_FLG - If multiple versions of the record are available in HDWF, only the current version is picked up. Current version is found in HDWF using the CURRENT_FLG attribute.

■ Masking Patient INTEGRATION_ID - To mask patient information, Patient INTEGRATION_ID from HDWF is not loaded into data mart, as it may contain patient identification information. Instead of INTEGRATION_ID, PT_ID from HDWF is populated to data mart.

■ Populating UOM_WID - If UOM_WID is not resolved by ETL while loading data into data mart, the UOM_WID is populated with NAV value. The actual value of NAV is picked up from the ETL Global configuration table C_LOAD_PARAM NAV.

■ Versioning Logic - For each Integration ID in HDWF, there is a single record in CDM. If there are multiple versions in HDWF, the most current version is loaded in the data mart. The most current version in HDWF is determined using the CURRENT_FLG attribute.

6.3 Oracle Data Integrator Work Repository ArtifactsThis section discusses the TRC work repository artifacts.

The work repository contains one project called Oracle Healthcare Analytics.

Note:

■ The Cohort ETL assumes that on the HDWF side each code can only be associated with one code set. If not W_EHA_OBSERVATION_D and W_EHA_PATIENT_HISTORY_D ETLS fails with an unique constraint error.

■ The Cohort ETL assumes that a subject can only correspond to 0 or 1 patient. A patient may have multiple subjects associated with it but not the reverse. If not W_EHA_SUBJECT_D ETL fails with an unique constraint error.

Ensure the following criteria are fulfilled before running ETLs:

1. Obfuscated Patient ID (PATIENT_IDENTIFIER_OBF) should never be null.

2. Obfuscated Patient ID should be populated with Unique values.

3. If step 1 and 2 are not fulfilled, then the UI does not work correctly.


Architecture 6-3

Figure 6–1 Project Structure

This project contains two main folders.

■ Execution Plans

■ Mappings



Figure 6–2 Folder Structure

6.3.1 Execution PlansExecution plan folder contains ETL artifacts related to packaging and executions of ETLs.

Table 6–1 Execution Plan Folder Contents

Folder Description

Level1_Load_User_Dimension

Loads user dimension.

Level2_Load_All_Other_Dimensions

Loads all dimensions in parallel followed by patient fact and unspecified records for dimensions.

Level3_Load_All_Patient_Bridge_Tables

Loads all patient bridge tables in parallel.

Level4_Load_All_Subject_For_Bridge_Tables

Loads all subject bridge tables.

Level5_Load_Aggregate _Counts

Loads aggregate counts into this table.

Level6_Load_Trc_Lookup_ Code_Table

Loads the TRC lookup code table.


Architecture 6-5

6.3.2 MappingsMappings folder contains the interfaces that load data mart tables.

A package is created to populate each data mart table. Each package comprises the following sequence to populate the corresponding data model table:

1. Refresh all the variables used for that particular package.

2. Run any one of the interfaces (full load or incremental load) depending on the type of load.

For a comprehensive list of interfaces and their corresponding packages refer to Appendix B.

Figure 6–3 depicts the design on package for the table W_EHA_RACE_PATIENT_H:

Master Execution Plan This is the incremental load execution plan. Level1 to Level5 packages are included in this plan. Oracle recommends that you do not run the individual packages. For the execution order, see Chapter 8.

Initial Setup The folder contains three sub folders; Create DBLink, Full_Load_Execution_Plan, and Generate_All_Scenarios.

Full_Load_Execution_Plan is the full load execution plan. For the execution order, see Chapter 8.

Table 6–2 Mappings Folder Contents

Folder Description

Dimensions Contains ETLs for all dimensions, bridge, and Trc_lookup_code tables

Facts Contains ETL for the patient fact

Table 6–1 (Cont.) Execution Plan Folder Contents

Folder Description



Figure 6–3 Package for the Table W_EHA_RACE_PATIENT_H

6.3.3 VariablesETL parameters are passed using variables. The variable values are refreshed during an ETL run from the C_LOAD_PARAM table. For a comprehensive list of variables, see Appendix B.


Architecture 6-7

Figure 6–4 Variables in Repository

6.3.4 SequencesSequences are used for populating ROW_WID columns in each of the data mart tables. For a comprehensive list of sequences, see Appendix B.



Figure 6–5 Sequences in Repository

6.3.5 User-defined FunctionsTRC uses a number of user-defined functions.

Table 6–3 User-defined Functions

Function Group

GET_USER_WID User WID

ADD_TO_DATE Date Operation

COALESCE Logical Operation

GET_SCEN_NAME Substitution

NEXTVAL Sequence Operation

QUALIFY Substitution

SESSSTARTTIME Date Operation

TO_CHAR_FORMAT Conversion Operation

%NOW% Date Operation


Architecture 6-9

6.3.6 Knowledge ModulesKnowledge modules are code templates. The following is the list of knowledge modules of TRC:

■ LKM TMP APPS Oracle to Oracle (DBLINK)

■ CKM Oracle

■ IKM TMP APPS Oracle Control Append

■ IKM TMP APPS Oracle Incremental Update

6.3.7 ModelsModels contain metadata of all TRC tables. The following is the list of models of TRC:

■ Oracle TMPAPPS Datamart contains the data mart tables.

■ Oracle Configuration Tables contains the ETL configurations tables.

■ Oracle HDM contains the HDWF tables.

■ Oracle TRC Application Tables contains application schema tables.

Figure 6–6 Model in Repository



7

Configuration Steps 7-1

7Configuration Steps

This chapter contains the following topics:

■ Section 7.1, "Standard Configuration of the C_LOAD_DATES Table"

7.1 Standard Configuration of the C_LOAD_DATES TableThe C_LOAD_DATES table is called the job control table. During the incremental load, this table stores the most recent execution details of packages. Therefore, this table is loaded automatically during the execution of ODI components. You do not need to update this table.

Table 7–1 C_LOAD_DATES Table Attributes


PACKAGE_NAME VARCHAR2 (300) Name of the ODI package that includes the variable, full, and incremental interfaces

TARGET_TABLE_NAME VARCHAR2 (300) Name of the main target table that is loaded by this package

ETL_PROC_WID NUMBER (10) Unique identifier that is used to populate for all the records in that table for a particular load

LAST_MAX_DATE DATE Last extract timestamp -1 second of the previous extraction

INSERT_DT DATE Date when the record is inserted

Note: ETL accepts multiple parameters for type codes.

Standard Configuration of the C_LOAD_DATES Table


8

Executing ETLs 8-1

8Executing ETLs

This chapter discusses interface logic and execution plans. This chapter contains the following topics:

■ Section 8.1, "Executing Full Load"

■ Section 8.2, "Executing Incremental Load"

■ Section 8.3, "Executing an Individual ETL"

■ Section 8.4, "Scheduling an ETL Execution Plan"

In a typical ETL process, data warehouse must be deployed (full load) and subsequently recently created, changed, or deleted records is applied to the data warehouse (incremental).

There are two packages as follows:

■ Full_Load_Execution_Plan for full load

■ Master_Execution_Plan for incremental load

The full load execution plan loads data mart tables in a particular sequence with certain assumptions about the volume of data available expected in different tables. The following is the strategy to create sequence:

■ Based on the referential integrity among different CDM tables, create a load order, which maximizes parallel execution to minimize the total time of loading the CDM data mart.

■ If the volume of data is extremely large, performing parallel execution may result in resource contention, which degrades the overall performance of the system. Oracle recommends that you formulate a load strategy based on the volume of data. This must minimize the execution time by maximizing parallel executions considering the resource constraints.

8.1 Executing Full LoadBefore executing the full load, you must execute the following script:

cohort_drop_indexes.sql: This script deletes indexes in the cohort data model schema. You must run this script if you have privileges to delete indexes in the cohort data model schema.

The full load execution plan runs ETLs in the following order:

1. Load user dimension

2. Load all other dimensions in parallel, load W_EHA_RESEARCH_PATIENT_F, and load unspecified records in all _D tables

Executing Full Load


3. Load all patient bridge tables in parallel

4. Load all subject bridge tables in parallel

5. Load aggregate table

6. Load TRC lookup code table

7. Load Level7_Load_Protocol_Util

To execute a full load, perform the following steps:

1. Navigate to Execution Plans > Initial Setup > Full_Load_Execution_Plan > Packages > Full_Load_Execution_Plan > Scenarios.

2. Right-click FULL_LOAD_EXECUTION_PLAN.

3. Select Execute.

Figure 8–1 Executing a Full Load


Executing ETLs 8-3

8.2 Executing Incremental LoadThe last successful ETL load time for a given interface is used to filter new and changed records in HDWF. In case auxiliary or child tables (tables that are joined to the base source table and whose data is populated into the data mart tables) are used as the source and the UPDATE_DT of these tables are also considered. The following is the code snippet used in the filter condition.

UPDATE_DT > TO_DATE ('#LAST_EXTRACT_DATE','MM/DD/YYYY HH24: MI: SS')

where, LAST_EXTRACT_DATE is the variable name.

The variable LAST_EXTRACT_DATE is used to retrieve the value of LAST_MAX_DT from the table and is referred in the UPDATE_DT logic in the incremental load interface. The following is the code snippet used for this variable:

SELECT case when COUNT (*)>0 then TO_CHAR_FORMAT (MIN (LAST_MAX_DATE),'MM/DD/YYYY HH24: MI: SS') else '01/01/1900 00:00:00' end

FROMQUALIFY (C_LOAD_DATES)

WHEREPACKAGE_NAME='GET_SCEN_NAME ()'

The incremental load execution plan runs ETLs in the following order:


2. Load all other dimensions in parallel and then load W_EHA_RESEARCH_PATIENT_F.

3. Load all patient bridge tables in parallel.

4. Load all subject bridge tables in parallel.




To execute an incremental load, perform the following steps:

1. Navigate to Execution Plans > Master Execution Plan > Packages > Master_Execution_Plan > Scenarios.

2. Right-click MASTER_EXECUTION_PLAN.

3. Select Execute.

Important: After the full load is executed successfully, execute the following scripts:

■ cohort_create_indexes.sql: This script re-creates index in the cohort data model schema and must be run after full data load. This script must be run only if you have privileges to create index in the cohort data model schema. This script prompts for the index tablespace parameter.

■ trc_lookup_data.sql: On full load, the ETL truncates the TRC_Lookup_Code table in the application schema. To populate the seed data again after a full load, re-execute this script. This script must be run by the application schema user.

Executing an Individual ETL


Figure 8–2 Incremental Load

8.3 Executing an Individual ETLIn the package associated with the data mart table, you can decide whether to run the incremental load or initial load using the variable IS_INCREMENTAL, as shown in figure 3-1. The logic for this variable returns Y for incremental load and N for full load.

Once the load is completed successfully, a record is inserted in the C_LOAD_DATES job control table. The following is an example of such record:

where,

■ PACKAGE_NAME is the package for loading the W_EHA_CONSENT_D table.

■ TARGET_TABLE_NAME is the target table name.

Table 8–1 Example of an Inserted Record

PACKAGE_NAME

TARGET_TABLE_NAME

ETL_PROC_WID LAST_MAX_DT INSERT_DT

LOAD_CONSENT_DIMENSION

W_EHA_CONSENT_D

14600 5/10/2011 17:02 5/10/2011 17:03

Executing an Individual ETL

Executing ETLs 8-5

■ ETL_PROC_WID is the unique identifier created using the Ref function.

■ LAST_MAX_DT is the last_extract_date (current system timestamp -1second) of the source schema.

■ INSERT_DT is the date on which the record is inserted into this table.

The following is the code snippet used for the IS_INCREMENTAL variable:

SELECT CASE WHEN COUNT (*)>0 THEN 'Y' ELSE 'N' END

FROM QUALIFY (C_LOAD_DATES)

WHERE PACKAGE_NAME = 'GET_SCEN_NAME ()

Perform the following steps to execute an individual ETL:

For example, to execute ETL for the Diagnosis dimension, perform the following steps:

1. Navigate to Mappings > Dimensions > Load_Diagnosis_Dimension > Packages > Load_Diagnosis_Dimension > Scenarios.

2. Right-click LOAD_DIAGNOSIS_DIMENSION.

3. Select Execute.

Note: Before executing individual ETL, you need to refresh the enterprise_id variable for a fresh TRC installation as it is a one-time process.

Scheduling an ETL Execution Plan


Figure 8–3 Executing an Individual ETL

8.4 Scheduling an ETL Execution PlanScheduling an execution plan implies that its corresponding scenario is scheduled. Perform the following steps to schedule a scenario:

1. Open a scenario.

2. Right-click Scheduling.

3. Select New Scheduling and provide different scheduling options as needed.

4. Click Save from the File menu. The execution plan is initiated accordingly.

For more information on scheduling an ETL execution plan, se Oracle® Fusion Middleware Getting Started with Oracle Data Integrator 11g Release 1 (11.1.1).


Executing ETLs 8-7

Figure 8–4 Scheduling an ETL Execution Plan



Part IVPart IV Statistics

This part of the guide contains the following chapter:

■ Chapter 9, "Statistics for Query Engine"

9

Statistics for Query Engine 9-1

9Statistics for Query Engine

This chapter describes how to calculate the statistics for query engine to optimize the performance.

To optimize the performance of the query engine, Oracle has provided the Procedure_refresh_stats_tab_inserts package in the CDM schema.

You must execute this package after the initial CDM load and then periodically or after any significant changes in data volumes or distribution in the CDM schema.

9.1 Executing the PackageTo execute the Procedure_refresh_stats_tab_inserts package, perform the following steps:

1. Connect to the CDM schema using SQLPlus.

2. Execute the following commands:

set serveroutput onset echo onspool REFRESH_STATS_TABexecute REFRESH_STATS_TABspool offexit

Executing the Package


Part VPart V Appendices


■ Appendix A, "ETL Related Tables"

■ Appendix B, "Work Repository Artifacts"

■ Appendix C, "Healthcare Data Warehouse Foundation to Cohort Data Mart Mappings"

■ Appendix D, "Assumptions"

A

ETL Related Tables A-1

AETL Related Tables

The appendix contains the following topic:

■ Appendix A.1, "Mapping of Key System Attributes Between HDWF and CDM"

A.1 Mapping of Key System Attributes Between HDWF and CDMTable A–1 describes the source HDWF driving entity table for each data model table in TRC.

Table A–1 Mapping of Key System Attributes

CDM Table Key Attributes HDWF Table(s)

W_USER_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_USER

HDM_USER

HDM_USER

HDM_USER

W_UOM_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY,HDM_CD_SYS,HDM_CD_REPOSITORY_CD_TYP,HDM_CD_TYP

HDM_CD_REPOSITORY,HDM_CD_SYS

W_EHA_PT_HISTORY_PT_H Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_PT_HX

HDM_PT_HX

HDM_PT_HX,HDM_SUBST_HX, HDM_SCL_HX, W_EHA_RESEARCH_PATIENT_D

HDM_PT_HX

W_EHA_PROC_PATIENT_H Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_INTVN

HDM_INTVN

HDM_INTVN,W_EHA_RESEARCH_PATIENT_D

HDM_INTVN

W_EHA_PROCEDURE_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY,HDM_CD_SYS,HDM_CD_REPOSITORY_CD_TYP,HDM_CD_TYP

HDM_CD_REPOSITORY,HDM_CD_SYS

Mapping of Key System Attributes Between HDWF and CDM

A-2 Oracle Health Sciences Translational Research Center Administrator's Guide

W_EHA_CONSENT_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY, HDM_CD_REPOSITORY_CD_TYP, HDM_CD_TYP, HDM_CD_SYS

HDM_CD_REPOSITORY, HDM_CD_SYS

W_EHA_RACE_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY



W_EHA_ETHNICITY_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY



W_EHA_PATIENT_HISTORY_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY



W_EHA_SPECIMEN_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY



W_EHA_CONSENT_STATUS_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY



W_EHA_DIAGNOSIS_STATUS_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY



W_EHA_CONSENT_PATIENT_H Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CNSNT

HDM_CNSNT

HDM_CNSNT, HDM_PT, W_EHA_RESEARCH_PATIENT_D

HDM_CNSNT

W_EHA_ETHN_PATIENT_H Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_IND_PRTY_ETHN

HDM_IND_PRTY_ETHN

HDM_IND_PRTY_ETHN, HDM_PT, W_EHA_RESEARCH_PATIENT_D

HDM_IND_PRTY_ETHN

Table A–1 (Cont.) Mapping of Key System Attributes



ETL Related Tables A-3


Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_INTVN_SUSBST

HDM_INTVN_SUSBST

HDM_INTVN_SUSBST, HDM_INTVN, HDM_SUBADMN, HDM_PT, W_EHA_RESEARCH_PATIENT_D

HDM_INTVN_SUSBST, HDM_INTVN, HDM_SUBADMN

W_EHA_RESEARCH_PATIENT_F Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_PT

HDM_PT

HDM_PT

HDM_PT

W_EHA_PROCEDURE_TYPE_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_TYP

HDM_CD_TYP

HDM_CD_TYP, C_COHORT_PROCEDURE_TYPE

HDM_CD_TYP

W_EHA_PROC_TYPE_PROC_DHL

Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY_CD_TYP

HDM_CD_REPOSITORY_CD_TYP

HDM_CD_TYP, HDM_CD_REPOSITORY_CD_TYP, W_EHA_PROCEDURE_D, C_COHORT_PROCEDURE_TYPE,W_EHA_PROCEDURE_TYPE_D

HDM_CD_REPOSITORY

W_EHA_SPECIMEN_PATIENT_H Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_SPCMN

HDM_SPCMN

HDM_PT, W_EHA_RESEARCH_PATIENT_D, W_EHA_ANATOMICAL_SITE_D,HDM_SPCMN,W_EHA_SPECIMEN_D

HDM_SPCMN

W_EHA_RACE_PATIENT_H Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_IND_PRTY_RC

HDM_IND_PRTY_RC

HDM_IND_PRTY_RC, HDM_PT, HDM_CD_REPOSITORY

HDM_IND_PRTY_RC

W_EHA_MEDICATION_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY




Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_PT

HDM_PT.PT_ID

HDM_PT,HDM_IND_PRTY,HDM_LOC,HDM_PRTY_ADDR

HDM_PT,HDM_IND_PRTY,HDM_LOC

W_EHA_DX_PATIENT_H Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CNRN_ANATSITE

HDM_CNRN_ANATSITE

HDM_CNRN_ANATSITE,HDM_CNRN,W_EHA_RESEARCH_PATIENT_D

HDM_CNRN_ANATSITE,HDM_CNRN




A-4 Oracle Health Sciences Translational Research Center Administrator's Guide

W_EHA_ANATOMICAL_SITE_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY



W_EHA_DIAGNOSIS_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_CD_REPOSITORY

HDM_CD_REPOSITORY



W_EHA_STUDY_D Datasource Num ID

Integration ID

Delete Flag

Update Date

HDM_STUDY

HDM_STUDY

HDM_STUDY

HDM_STUDY



B

Work Repository Artifacts B-1

BWork Repository Artifacts

The appendix contains the following topics:

■ Appendix B.1, "Variables"

■ Appendix B.2, "Sequences"

■ Appendix B.3, "Interfaces"

B.1 VariablesTable B–1 lists the variables in the repository.

Table B–1 Variables

Variable Name

ADDR_STATUS_CODE

AGE_AT_FIRST_ONSET_FLG

AGE_AT_FIRST_ONSET_FLG_OBF

AGE_AT_FIRST_ONSET_VALUE

ANATOMICAL_SITE_CODE

CITY_FLG

CITY_FLG _OBF

CITY_VALUE

CNSNT_EFF_END_DT_FLG

CNSNT_EFF_END_DT_FLG _OBF

CNSNT_EFF_END_DT_VALUE

CNSNT_EFF_STRT_DT_FLG

CNSNT_EFF_STRT_DT_FLG _OBF

CNSNT_EFF_STRT_DT_VALUE

CONSENT_STATUS_CODE

CONSENT_TYPE_CODE

DECEASED_DT_FLG

DECEASED_DT_FLG _OBF

DECEASED_DT_VALUE

DEFAULT_WID

DIAGNOSIS_CODE

DIAGNOSIS_END_DT_FLG

DIAGNOSIS_END_DT_FLG _OBF

Variables

B-2 Oracle Health Sciences Translational Research Center Administrator's Guide

DIAGNOSIS_END_DT_VALUE

DIAGNOSIS_ONSET_DT_FLG

DIAGNOSIS_ONSET_DT_FLG _OBF

DIAGNOSIS_ONSET_DT_VALUE

DIAGNOSIS_REPORTED_DT_FLG

DIAGNOSIS_REPORTED_DT_FLG _OBF

DIAGNOSIS_REPORTED_DT_VALUE

DIAGNOSIS_STATUS_CODE

DOB_DATE_FLG

DOB_DATE_FLG _OBF

DOB_DATE_VALUE

ETHNICITY_CODE

HOME_ADDR_TYP

INTVN_END_DT_FLG

INTVN_END_DT_FLG _OBF

INTVN_END_DT_VALUE

INTVN_STRT_DT_FLG

INTVN_STRT_DT_FLG _OBF

INTVN_STRT_DT_VALUE

IS_INCREMENTAL

LAST_EXTRACT_DATE

MEDICATION_CODE

PATIENT_HISTORY_CODE

PATIENT_HISTORY_END_DT_FLG

PATIENT_HISTORY_END_DT_FLG _OBF

PATIENT_HISTORY_END_DT_VALUE

PATIENT_HISTORY_START_DT_FLG

PATIENT_HISTORY_START_DT_FLG _OBF

PATIENT_HISTORY_START_DT_VALUE

POSTAL_CODE_FLG

POSTAL_CODE_VALUE

PROCEDURE_CODE

PROCEDURE_END_DT_FLG

PROCEDURE_END_DT_FLG _OBF

PROCEDURE_END_DT_VALUE

PROCEDURE_START_DT_FLG

PROCEDURE_START_DT_FLG _OBF

PROCEDURE_START_DT_VALUE

RACE_CODE

RESULTING_CODE

SEPERATOR

SPECIMEN_COLLECTION_DT_FLG

Table B–1 (Cont.) Variables

Variable Name

Sequences


B.2 SequencesTable B–2 lists the sequences in the repository.

SPECIMEN_COLLECTION_DT_FLG _OBF

SPECIMEN_COLLECTION_DT_VALUE

SPECIMEN_TYPE_CODE

SUBADMN_END_DT_FLG

SUBADMN_END_DT_VALUE

SUBADMN_START_DT_FLG

SUBADMN_START_DT_FLG _OBF

SUBADMN_START_DT_VALUE

UOM_CODE

STUDY_WID

MRTL_STCD

GNDR_CD

Table B–2 Sequences

Sequence Name

W_EHA_ANATOMICAL_SITE_D_S

W_EHA_CONSENT_D_S

W_EHA_CONSENT_PATIENT_H_S

W_EHA_CONSENT_STATUS_D_S

W_EHA_DIAGNOSIS_D_S

W_EHA_DIAGNOSIS_STATUS_D_S

W_EHA_DX_PATIENT_H_S

W_EHA_ENCOUNTER_D_S

W_EHA_ENCOUNTER_TYPE_D_S

W_EHA_ENC_PATIENT_H_S

W_EHA_ETHNICITY_D_S

W_EHA_ETHN_PATIENT_H_S

W_EHA_ETHN_ SUBJECT _H_S

W_EHA_MEDICATION_D_S

W_EHA_PATIENT_HISTORY_D_S

W_EHA_PROCEDURE_D_S

W_EHA_PROCEDURE_TYPE_D_S

W_EHA_PROC_PATIENT_H_S

W_EHA_PROC_SUBJECT_S

W_EHA_PROC_TYPE_PROC_DHL_S

W_EHA_PT_HISTORY_PT_H_S

W_EHA_SBJ_HISTORY_SBJ_H_S

W_EHA_RACE_D_S

W_EHA_RACE_PATIENT_H_S

Table B–1 (Cont.) Variables

Variable Name

Interfaces


B.3 InterfacesTable B–3 lists repository interfaces and the folder or package containing the interface.

W_EHA_RACE_ SUBJECT _H_S

W_EHA_RESEARCH_PATIENT_D_S

W_EHA_ SUBJECT _D_S

W_EHA_RESEARCH_PATIENT_F_S

W_EHA_ SUBJECT _F_S

W_EHA_SPECIMEN_D_S

W_EHA_SPECIMEN_PATIENT_H_S

W_EHA_SPECIMEN_ SUBJECT _H_S

W_EHA_SUBADMN_PATIENT_H_S

W_EHA_SUBADMN_ SUBJECT _H_S

W_EHA_UOM_D_S

W_USER_D_S

W_EHA_STUDY_S

Table B–3 Interfaces

Interface Name Folder or Package Containing the Interface

INT_TMPAPPS_Research_Patient_F Load_Research_Patient_Fact

INT_TMPAPPS_Research_Patient_F_Full Load_Research_Patient_Fact

INT_TMPAPPS_Subject_F Load_ Subject _Fact

INT_TMPAPPS_ Subject _F_Full Load_ Subject _Fact

INT_TMPAPPS_Patient_History_D Load_Patient_History_Dimension

INT_TMPAPPS_Patient_History_D_Full Load_Patient_History_Dimension

INT_TMPAPPS_Consent_Patient_H_Full Load_Consent_Patient_Bridge

INT_TMPAPPS_Consent_Patient_H Load_Consent_Patient_Bridge

INT_TMPAPPS_Consent_Subject_H_Full Load_Consent_ Subject _Bridge

INT_TMPAPPS_Consent_ Subject _H Load_Consent_ Subject _Bridge

INT_TMPAPPS_Diagnosis_Status_D Load_Diagnosis_Status_Dimension

INT_TMPAPPS_Diagnosis_Status_D_Full Load_Diagnosis_Status_Dimension

INT_TMPAPPS_Race_D Load_Race_Dimension

INT_TMPAPPS_Race_D_Full Load_Race_Dimension

INT_TMPAPPS_Specimen_D Load_Specimen_Dimension

INT_TMPAPPS_Specimen_D_Full Load_Specimen_Dimension

INT_TMPAPPS_Ethnicity_Patient_H_Full Load_Ethnicity_Patient_Bridge

INT_TMPAPPS_Ethnicity_Patient_H Load_Ethnicity_Patient_Bridge

INT_TMPAPPS_Ethnicity_Subject_H_Full Load_Ethnicity_Subject_Bridge

INT_TMPAPPS_Ethnicity_SubjectH Load_Ethnicity_Subject_Bridge

INT_TMPAPPS_Procedure_D Load_Procedure_Dimension

INT_TMPAPPS_Procedure_D_Full Load_Procedure_Dimension

INT_TMPAPPS_DX_PATIENT_H_Full Load_Dx_Patient_Bridge

Table B–2 (Cont.) Sequences

Sequence Name

Interfaces


INT_TMPAPPS_DX_PATIENT_H Load_Dx_Patient_Bridge

INT_TMPAPPS_DX_Subject_H_Full Load_Dx_Subject_Bridge

INT_TMPAPPS_DX_Subject_H Load_Dx_Subject_Bridge

INT_TMPAPPS_W_EHA_RESEARCH_PATIENT_D Load_Research_Patient_Dimension

INT_TMPAPPS_GET_LATEST_PRTY_ADDR_Tmp_1 Load_Research_Patient_Dimension

INT_TMPAPPS_W_EHA_RESEARCH_PATIENT_D_Full

Load_Research_Patient_Dimension

INT_TMPAPPS_GET_LATEST_PRTY_ADDR_Tmp_2 Load_Research_Patient_Dimension

INT_TMPAPPS_Consent_D_Full Load_Consent_Dimension

INT_TMPAPPS_Consent_D Load_Consent_Dimension

INT_TMPAPPS_Ethnicity_D Load_Ethnicity_Dimension

INT_TMPAPPS_Ethnicity_D_Full Load_Ethnicity_Dimension

INT_TMPAPPS_Pt_History_Pt_H Load_Patient_History_Patient_Bridge

INT_TMPAPPS_Pt_History_Pt_H_Full Load_Patient_History_Patient_Bridge

INT_TMPAPPS_Sbj_History_ Sbj _H Load_Subject_History_Subject_Bridge

INT_TMPAPPS_ Sbj _History_ Sbj _H_Full Load_Subject_History_Subject_Bridge

INT_TMPAPPS_Proc_Patient_H Load_Procedure_Patient_Bridge

INT_TMPAPPS_Proc_Patient_H_Full Load_Procedure_Patient_Bridge

INT_TMPAPPS_Proc_Subject_H Load_Procedure_Subject_Bridge

INT_TMPAPPS_Proc_Subject_H_Full Load_Procedure_Subject_Bridge

INT_TMPAPPS_Anatomical_Site_D_Temp Load_Anatomical_Site_Dimension

INT_TMPAPPS_Anatomical_Site_D_Full Load_Anatomical_Site_Dimension

INT_TMPAPPS_Anatomical_Site_D Load_Anatomical_Site_Dimension

INT_TMPAPPS_Diagnosis_D Load_Diagnosis_Dimension

INT_TMPAPPS_Diagnosis_D_Full Load_Diagnosis_Dimension

INT_TMPAPPS_Diagnosis_D_Temp Load_Diagnosis_Dimension

INT_TMPAPPS_Consent_Status_D_Full Load_Consent_Status_Dimension

INT_TMPAPPS_Consent_Status_D Load_Consent_Status_Dimension

INT_TMPAPPS_Procedure_Type_Procedure_DHL_Full

Load_Procedure_Type_Procedure_Bridge

INT_TMPAPPS_Procedure_Type_Procedure_DHL Load_Procedure_Type_Procedure_Bridge

INT_TMPAPPS_Medication_D_Full Load_Medication_Dimension

INT_TMPAPPS_Medication_D Load_Medication_Dimension

INT_TMPAPPS_Race_patient_H Load_Race_Patient_Bridge

INT_TMPAPPS_Race_patient_H_Full Load_Race_Patient_Bridge

INT_TMPAPPS_Race_Subject_H Load_Race_Subject_Bridge

INT_TMPAPPS_Race_Subject_H_Full Load_Race_Subject_Bridge

INT_TMPAPPS_Procedure_Type_D_Full Load_Procedure_Type_Dimension

INT_TMPAPPS_Procedure_Type_D Load_Procedure_Type_Dimension

INT_TMPAPPS_Specimen_Patient_H Load_Specimen_Patient_Bridge

INT_TMPAPPS_Specimen_Patient_H_Full Load_Specimen_Patient_Bridge

INT_TMPAPPS_Specimen_Subject_H Load_Specimen_Subject_Bridge

INT_TMPAPPS_Specimen_Subject_H_Full Load_Specimen_Subject_Bridge

Table B–3 (Cont.) Interfaces


Interfaces


INT_TMPAPPS_UOM_D Load_UOM_Dimension

INT_TMPAPPS_UOM_D_Full Load_UOM_Dimension

INT_TMPAPPS_User_D_Full Load_User_Dimension

INT_TMPAPPS_User_D Load_User_Dimension

INT_TMPAPPS_TRC_LOOKUP_CODE_GENDER_CODE_FULL

Load TRC Lookup Code Table

INT_TMPAPPS_TRC_LOOKUP_CODE_GENDER_CODE


INT_TMPAPPS_TRC_LOOKUP_CODE_MARITAL_STATUS_FULL


INT_TMPAPPS_TRC_LOOKUP_CODE_MARITAL_STATUS


INT_TMPAPPS_Study_D_Full Load Study Dimension

INT_TMPAPPS_Study_D Load Study Dimension

Table B–3 (Cont.) Interfaces


C

Healthcare Data Warehouse Foundation to Cohort Data Mart Mappings C-1

CHealthcare Data Warehouse Foundation toCohort Data Mart Mappings

This section contains HDWF to CDM Mappings.

C.1 HDWF to CDM Mappings

Table C–1 HDWF to CDM Mappings

Cohort Datamart Table

Cohort Datamart Data Element HDWF Entity

HDWF Logical Attribute HDWF Tables

HDWF Columns

W_EHA_ANATOMICAL_SITE_D

ANATOMICAL _SITE_ DESC

Code Repository

Code Description

W_EHA_CD_REPOSITORY_HIER_V CD_DESC


ANATOMICAL_ SITE_ CODE

Code Repository

Code W_EHA_CD_REPOSITORY_HIER_V CD


ANATOMICAL_ SITE_ NAME

Code Repository

Code Name W_EHA_CD_REPOSITORY_HIER_V CD_NM


ANATOMICAL_SITE_LVL1_CODE

Code Repository



ANATOMICAL_SITE_LVL1_NAME

Code Repository



ANATOMICAL_SITE_LVL1_DESC

Code Repository

Code Description




Code Repository




Code Repository




Code Repository

Code Description




Code Repository


HDWF to CDM Mappings

C-2 Oracle Health Sciences Translational Research Center Administrator's Guide



Code Repository




Code Repository

Code Description




Code Repository




Code Repository




Code Repository

Code Description




Code Repository




Code Repository




Code Repository

Code Description




Code Repository




Code Repository




Code Repository

Code Description




Code Repository




Code Repository




Code Repository

Code Description




Code Repository




Code Repository




Code Repository

Code Description




Code Repository


Table C–1 (Cont.) HDWF to CDM Mappings




HDWF Columns





Code Repository




Code Repository

Code Description




Code Repository




Code Repository




Code Repository

Code Description




Code Repository




Code Repository




Code Repository

Code Description




Code Repository




Code Repository




Code Repository

Code Description




Code Repository




Code Repository




Code Repository

Code Description




Code Repository




Code Repository




Code Repository

Code Description


W_EHA_CONSENT_D

CONSENT_TYPE_CODE

Code Repository

Code HDM_CD_REPOSITORY CD

W_EHA_CONSENT_D

CONSENT_TYPE_DESC

Code Repository

Code Description

HDM_CD_REPOSITORY CD_DESC





HDWF Columns



W_EHA_CONSENT_D

CONSENT_TYPE_NAME

Code Repository

Code Name HDM_CD_REPOSITORY CD_NM


CONSENT_END_DT

Consent Consent Effective End Date and Time

HDM_CNSNT CNSNT_EFF_END_DT


CONSENT_START_DT

Consent Consent Effective Start Date and Time

HDM_CNSNT CNSNT_EFF_STRT_DT

W_EHA_CONSENT_STATUS_D

CONSENT_STATUS_CODE

Code Repository



CONSENT_STATUS_DESC

Code Repository

Code Description



CONSENT_STATUS_NAME

Code Repository



CONSENT_END_DT

Consent Consent Effective End Date and Time

HDM_CNSNT CNSNT_EFF_END_DT


CONSENT_START_DT

Consent Consent Effective Start Date and Time

HDM_CNSNT CNSNT_EFF_STRT_DT

W_EHA_DIAGNOSIS_D

DIAGNOSIS_CODE

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_DESC

Code Repository

Code Description


W_EHA_DIAGNOSIS_D

DIAGNOSIS_NAME

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL1_CODE

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL1_NAME

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL1_DESC

Code Repository

Code Description


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL2_CODE

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL2_NAME

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL2_DESC

Code Repository

Code Description


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL3_CODE

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL3_NAME

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL3_DESC

Code Repository

Code Description


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL4_CODE

Code Repository






HDWF Columns



W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL4_NAME

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL4_DESC

Code Repository

Code Description


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL5_CODE

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL5_NAME

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL5_DESC

Code Repository

Code Description


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL6_CODE

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL6_NAME

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL6_DESC

Code Repository

Code Description


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL7_CODE

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL7_NAME

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL7_DESC

Code Repository

Code Description


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL8_CODE

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL8_NAME

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL8_DESC

Code Repository

Code Description


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL9_CODE

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL9_NAME

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL9_DESC

Code Repository

Code Description


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL10_CODE

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL10_NAME

Code Repository


W_EHA_DIAGNOSIS_D

DIAGNOSIS_LVL10_DESC

Code Repository

Code Description


W_EHA_DIAGNOSIS_D


Code Repository


W_EHA_DIAGNOSIS_D


Code Repository


W_EHA_DIAGNOSIS_D


Code Repository

Code Description


W_EHA_DIAGNOSIS_D


Code Repository


W_EHA_DIAGNOSIS_D


Code Repository






HDWF Columns



W_EHA_DIAGNOSIS_D


Code Repository

Code Description


W_EHA_DIAGNOSIS_D


Code Repository


W_EHA_DIAGNOSIS_D


Code Repository


W_EHA_DIAGNOSIS_D


Code Repository

Code Description


W_EHA_DIAGNOSIS_D


Code Repository


W_EHA_DIAGNOSIS_D


Code Repository


W_EHA_DIAGNOSIS_D


Code Repository

Code Description


W_EHA_DIAGNOSIS_STATUS_D

DIAGNOSIS_STATUS_CODE

Code Repository



DIAGNOSIS_STATUS_DESC

Code Repository

Code Description



DIAGNOSIS_STATUS_NAME

Code Repository


W_EHA_DX_PATIENT_H

AGE_AT_FIRST_ONSET

Concern Age at First Onset

HDM_CNRN AGE_AT_FRST_ONST

W_EHA_DX_PATIENT_H

DIAGNOSIS_END_DT

Concern Concern Resolution Date and Time

HDM_CNRN CNRN_RESLUTN_DT

W_EHA_DX_PATIENT_H

DIAGNOSIS_ONSET_DT

Concern Concern Onset Date and Time

HDM_CNRN CNRN_ONST_DT

W_EHA_DX_PATIENT_H


Concern Concern Recorded Date and Time

HDM_CNRN CNRN_RECD_DT

WW_EHA_DX_SUBJECT_H

AGE_AT_FIRST_ONSET

Concern Age at First Onset

HDM_CNRN AGE_AT_FRST_ONST

W_EHA_DX_SUBJECT_H

DIAGNOSIS_END_DT

Concern Concern Resolution Date and Time

HDM_CNRN CNRN_RESLUTN_DT

W_EHA_DX_SUBJECT_H

DIAGNOSIS_ONSET_DT

Concern Concern Onset Date and Time

HDM_CNRN CNRN_ONST_DT

W_EHA_DX_SUBJECT_H


Concern Concern Recorded Date and Time

HDM_CNRN CNRN_RECD_DT

W_EHA_ENCOUNTER_D

ENCOUNTER_NUMBER

Encounter Encounter number

HDM_ENC ENC_NBR





HDWF Columns



W_EHA_ENCOUNTER_TYPE_D

ENCOUNTER_TYPE_CODE

Code Repository



ENCOUNTER_TYPE_NAME

Code Repository

Code Description



ENCOUNTER_TYPE_DESC

Code Repository


W_EHA_ENC_PATIENT_H

ENCOUNTER_START_DT

Encounter ENCOUNTER_START_DT

HDM_ENC STRT_DT

W_EHA_ENC_PATIENT_H

ENCOUNTER_END_DT

Encounter ENCOUNTER_END_DT

HDM_ENC END_DT

W_EHA_ETHNICITY_D

ETHNICITY_CODE

Code Repository


W_EHA_ETHNICITY_D

ETHNICITY_DESC

Code Repository

Code Description


W_EHA_ETHNICITY_D

ETHNICITY_NAME

Code Repository


W_EHA_FACILITY_D

FACILITY_NUMBER

FACILITY FACILITY NUMBER

HDM_FAC FAC_NBR

W_EHA_FACILITY_D

FACILITY_NAME

FACILITY FACILITY_NAME

HDM_FAC FAC_NM

W_EHA_FACILITY_D

FACILITY_TYPE_CODE

Code Repository


W_EHA_FACILITY_D

FACILITY_TYPE_DESC

Code Repository


W_EHA_FAMBR_RLSHP_TYPE_D

FAMBR_RLSHP_TYPE_CODE

Code Repository



FAMBR_RLSHP_TYPE_NAME

Code Repository

Code Description



FAMBR_RLSHP_TYPE_DESC

Code Repository


W_EHA_HISTORY_VALUE_D

HISTORY_VALUE_CODE

Code Repository



HISTORY_VALUE_NAME

Code Repository

Code Description



HISTORY_VALUE_DESC

Code Repository


W_EHA_MEDICATION_D

MEDICATION_CODE

Code Repository


W_EHA_MEDICATION_D

MEDICATION_DESC

Code Repository

Code Description


W_EHA_MEDICATION_D

MEDICATION_NAME

Code Repository


W_EHA_OBSERVATION_D

OBSERVATION_CODE

Code Repository






HDWF Columns



W_EHA_OBSERVATION_D

OBSERVATION_NAME

Code Repository

Code Description


W_EHA_OBSERVATION_D

OBSERVATION_DESC

Code Repository


W_EHA_OBSERVATION_D

OBSERVATION_TYPE_CODE

Code Repository

Code HDM_CD_SET CD_SET_CD

W_EHA_OBSERVATION_D

OBSERVATION_TYPE_NAME

Code Repository

Code Description

HDM_CD_SET CD_SET_DESC

W_EHA_OBSERVATION_D

OBSERVATION_TYPE_DESC

Code Repository

Code Name HDM_CD_SET CD_SET_NM

W_EHA_PATIENT_HISTORY_D

PATIENT_HISTORY_CODE

Code Repository



PATIENT_HISTORY_DESC

Code Repository

Code Description



PATIENT_HISTORY_NAME

Code Repository


W_EHA_PROC_OUTCOME_D

PROCEDURE_OUTCOME_CODE

Code Repository



PROCEDURE_OUTCOME_NAME

Code Repository



PROCEDURE_OUTCOME_DESC

Code Repository

Code Description



PROCEDURE_END_DT

Intervention End Date and Time

HDM_INTVN END_DT


PROCEDURE_START_DT

Intervention Start Date and Time

HDM_INTVN STRT_DT


PROCEDURE_END_DT


HDM_INTVN END_DT


PROCEDURE_START_DT


HDM_INTVN STRT_DT

W_EHA_PROCEDURE_D

PROCEDURE_CODE

Code Repository


W_EHA_PROCEDURE_D

PROCEDURE_DESC

Code Repository

Code Description


W_EHA_PROCEDURE_D

PROCEDURE_NAME

Code Repository


W_EHA_PROCEDURE_TYPE_D

PROCEDURE_TYPE_CODE

Code Type Type Code HDM_CD_TYP TYP_CD


PROCEDURE_TYPE_DESC

Code Type Type Description

HDM_CD_TYP TYP_DESC


PROCEDURE_TYPE_NAME

Code Type Type Name HDM_CD_TYP TYP_NM





HDWF Columns




AMOUNT Substance History

Dose HDM_SUBST_HX/HDM_SCL_HX/HDM_PT_HX

DOS/AVG_QTY_USED/PT_HX_VAL_NMERIC


FREQUENCY Substance History

Frequency HDM_SUBST_HX/HDM_SCL_HX FREQ/AVG_QTY_USED_DUR



Patient History

Patient History Effective End Date and Time

HDM_PT_HX PT_HX_EFF_END_DT



Patient History

Patient History Effective Start Date and Time

HDM_PT_HX PT_HX_EFF_STRT_DT


AMOUNT Substance History

Dose HDM_SUBST_HX/HDM_SCL_HX/HDM_PT_HX

DOS/AVG_QTY_USED/PT_HX_VAL_NMERIC


FREQUENCY Substance History

Frequency HDM_SUBST_HX/HDM_SCL_HX FREQ/AVG_QTY_USED_DUR


SUBJECT_HISTORY_END_DT

Patient History

Patient History Effective End Date and Time

HDM_PT_HX PT_HX_EFF_END_DT


SUBJECT_HISTORY_START_DT

Patient History

Patient History Effective Start Date and Time

HDM_PT_HX PT_HX_EFF_STRT_DT

W_EHA_RACE_D RACE_CODE Code Repository


W_EHA_RACE_D RACE_DESC Code Repository

Code Description


W_EHA_RACE_D RACE_NAME Code Repository



*_NAME(FIRST,MIDDLE,LAST)

Individual Party

Individual Party (NameS)

HDM_IND_PRTY FRST_NM,MID_NM,LST_NM


*_ADDRESS(STREET_ADDRESS_1,STREET_ADDRESS_2,STREET_ADDRESS_3)

HDM_LOC HDM_LOC (Address)

HDM_LOC STRT_ADDR,STRT_ADDR_1,STRT_ADDR_2


CONTACT_INFO

Party contact info

Party contact info

HDM_PRTY_CNTCT_INFO CNTCT_INFO


CONTACT_INFO_TYPE_CODE

Party contact info

Contact info type Code

HDM_CD_REPOSITORY CD





HDWF Columns




CONTACT_INFO_TYP_DESC

Party contact info

Contact info type (Description)



CONTACT_INFO_TYP_NAME

Party contact info

Contact info type (Name)

HDM_CD_REPOSITORY CD_NM


PATIENT_IDENTIFIER

Patient Identification

Identification Number

HDM_PT PT_NBR


CITY Location City Name HDM_LOC CIT


COUNTRY_CODE

Location Country Code



COUNTRY_DESC

Location Country Code (Description)



COUNTRY_NAME

Location Country Code (Name)



DECEASED_DT Individual Party

Deceased Date and Time

HDM_IND_PRTY DECD_DT


DOB Individual Party

Birth Date and Time

HDM_IND_PRTY BIR_DT


GENDER_CODE

Individual Party

Gender Code HDM_CD_REPOSITORY CD


GENDER_DESC Individual Party

Gender Code (Description)



GENDER_NAME

Individual Party

Gender Code (Name)



MARITAL_STATUS_CODE

Individual Party

Marital Status Code



MARITAL_STATUS_DESC

Individual Party

Marital Status Code (Description)



MARITAL_STATUS_NAME

Individual Party

Marital Status Code (Name)



POSTAL_CODE Location Postal Code HDM_LOC PSTL_CD


STATE_CODE Location State Code HDM_CD_REPOSITORY CD


STATE_DESC Location State Code (Description)






HDWF Columns




STATE_NAME Location State Code (Name)


W_EHA_SERVICE_PROVIDER_D

SVCPRV_IDENTIFIER

Serviceprovider

Serviceproviderr number

HDM_SVCPRV SVCPRV_NBR


SVCPRV_TYPE_CODE

Code Repository



SVCPRV_TYPE_NAME

Code Repository

Code Description



SVCPRV_TYPE_DESC

Code Repository


W_EHA_SPECIALTY_D

SPECIALTY_CODE

Code Repository


W_EHA_SPECIALTY_D

SPECIALTY_NAME

Code Repository

Code Description


W_EHA_SPECIALTY_D

SPECIALTY_DESC

Code Repository


W_EHA_SPECIMEN_D

SPECIMEN_TYPE_CODE

Code Repository


W_EHA_SPECIMEN_D

SPECIMEN_TYPE_DESC

Code Repository

Code Description


W_EHA_SPECIMEN_D

SPECIMEN_TYPE_NAME

Code Repository



SPECIMEN_AMOUNT

Specimen Specimen Quantity

HDM_SPCMN SPCMN_QTY



Specimen Specimen Collection Date and Time

HDM_SPCMN SPCMN_COLC_DT


SPECIMEN_NUMBER

Specimen Specimen Number

HDM_SPCMN SPCMN_NBR


SPECIMEN_VENDOR_NUMBER

Serviceprovider

Serviceprovider number



SPECIMEN_AMOUNT

Specimen Specimen Quantity

HDM_SPCMN SPCMN_QTY



Specimen Specimen Collection Date and Time

HDM_SPCMN SPCMN_COLC_DT


SPECIMEN_NUMBER

Specimen Specimen Number

HDM_SPCMN SPCMN_NBR


SPECIMEN_VENDOR_NUMBER

Serviceprovider

Serviceprovider number


W_EHA_STUDY_D STUDY_IDENTIFIER

Hdm Study Study Id HDM_STUDY STDY_NBR

W_EHA_STUDY_D STUDY_NAME Hdm Study Study Nm HDM_STUDY STDY_NM

W_EHA_STUDY_D STUDY_DESC Hdm Study Study Desc HDM_STUDY STDY_DESC





HDWF Columns



W_EHA_STUDY_D STUDY_START_DT

Hdm Study Study Start Date

HDM_STUDY STDY_STRT_DT

W_EHA_STUDY_D STUDY_END_DT

Hdm Study Study End Date

HDM_STUDY STDY_END_DT

W_EHA_SUBADMN_OUTCOME_D

SUBADMN_OUTCOME_CODE

Code Repository



SUBADMN_OUTCOME_NAME

Code Repository

Code Description



SUBADMN_OUTCOME_DESC

Code Repository



SUBADMN_DOSAGE

Substance Administration

Dose HDM_SUBADMN DOS


SUBADMN_END_DT


HDM_INTVN END_DT


SUBADMN_START_DT


HDM_INTVN STRT_DT


SUBADMN_DOSAGE

Substance Administration

Dose HDM_SUBADMN DOS


SUBADMN_END_DT


HDM_INTVN END_DT


SUBADMN_START_DT


HDM_INTVN STRT_DT


OBSV_DT Observation Observation Date and Time

HDM_OBSV OBSV_EFF_STRT_DT


OBSV_VALUE_NUM

Observation Observation Value Number

HDM_OBSV OBSV_VAL_NMERIC


OBSV_DT Observation Observation Date and Time

HDM_OBSV OBSV_EFF_STRT_DT


OBSV_VALUE_NUM

Observation Observation Value Number

HDM_OBSV OBSV_VAL_NMERIC

W_EHA_SUBJECT_D

SUBJECT_IDENTIFIER

Subject Identification

Identification Number

HDM_HMN_SUBJ HMN_SUBJ_NBR

W_EHA_SUBJECT_D

CITY Location City Name HDM_LOC CIT

W_EHA_SUBJECT_D

COUNTRY_CODE

Location Country Code


W_EHA_SUBJECT_D

COUNTRY_DESC

Location Country Code (Description)


W_EHA_SUBJECT_D

COUNTRY_NAME

Location Country Code (Name)






HDWF Columns



W_EHA_SUBJECT_D

DECEASED_DT Individual Party

Deceased Date and Time

HDM_IND_PRTY DECD_DT

W_EHA_SUBJECT_D

DOB Individual Party

Birth Date and Time

HDM_IND_PRTY BIR_DT

W_EHA_SUBJECT_D

GENDER_CODE

Individual Party

Gender Code HDM_CD_REPOSITORY CD

W_EHA_SUBJECT_D

GENDER_DESC Individual Party

Gender Code (Description)


W_EHA_SUBJECT_D

GENDER_NAME

Individual Party

Gender Code (Name)


W_EHA_SUBJECT_D

MARITAL_STATUS_CODE

Individual Party

Marital Status Code


W_EHA_SUBJECT_D

MARITAL_STATUS_DESC

Individual Party

Marital Status Code (Description)


W_EHA_SUBJECT_D

MARITAL_STATUS_NAME

Individual Party

Marital Status Code (Name)


W_EHA_SUBJECT_D

POSTAL_CODE Location Postal Code HDM_LOC PSTL_CD

W_EHA_SUBJECT_D

STATE_CODE Location State Code HDM_CD_REPOSITORY CD

W_EHA_SUBJECT_D

STATE_DESC Location State Code (Description)


W_EHA_SUBJECT_D

STATE_NAME Location State Code (Name)


W_EHA_SUBJECT_D

*_NAME(FIRST,MIDDLE,LAST)

Individual Party

Individual Party (NameS)

HDM_IND_PRTY FRST_NM,MID_NM.LST_NM

W_EHA_SUBJECT_D

*_ADDRESS(STREET_ADDRESS_1,STREET_ADDRESS_2,STREET_ADDRESS_3)

HDM_LOC HDM_LOC (Address)

HDM_LOC STRT_ADDR, STRT_ADDR1, STRT_ADDR2

W_EHA_SUBJECT_D

CONTACT_INFO

Party contact info

Party contact info

HDM_PRTY_CNTCT_INFO CNTCT_INFO

W_EHA_SUBJECT_D

CONTACT_INFO_TYPE_CODE

Party contact info

Contact info type Code


W_EHA_SUBJECT_D

CONTACT_INFO_TYP_DESC

Party contact info

Contact info type (Description)


W_EHA_SUBJECT_D

CONTACT_INFO_TYP_NAME

Party contact info

Contact info type (Name)


W_EHA_SUBJECT_GROUP_D

SUBJECT_GROUP_CODE

Code Repository



SUBJECT_GROUP_NAME

Code Repository

Code Description



SUBJECT_GROUP_DESC

Code Repository






HDWF Columns



W_EHA_UOM_D UOM_CODE Code Repository


W_EHA_UOM_D UOM_DESC Code Repository

Code Description


W_EHA_UOM_D UOM_NAME Code Repository


W_EHA_FACILITY_D

FACILITY_TYPE_NAME

Code Repository

Code Description






HDWF Columns

D

Assumptions D-1

DAssumptions

This section describes the assumptions made in this guide.

D.1 Details

■ Versioning is not supported in CDM.

■ Both HDWF and CDM schema may reside in different database servers.

■ INTEGRATION_ID, DATASOURCE_NUM_ID, and CURRENT_FLG will be treated as business keys in HDWF.

■ INTEGRATION_ID and DATASOURCE_NUM_ID are treated as business key in CDM tables.

■ Referential data integrity is managed by HDM ETLs even if constraints are disabled. Cohort Explorer ETLs will not do any explicit validation.

■ Primary key and referential integrity rules are handled using the Informatica or default error handling technique.

■ Temporary or staging tables are used for loading the target tables that are transient in nature.

■ A database view is used as source for each target table when Informatica ETLs are used.

■ While resolving the dimension WIDs in intersection entities, no explicit validation is handled against code types. As the code repository is master data, it is assumed that the codes in code repository will have appropriate code types in code type table.

■ UPDATE_DT column is used for incremental extraction. If there are multiple driving tables as source, UPDATE_DT of all the driving tables is OR ed along with the base tables UPDATE_DT.

■ The latest records with CURRENT_FLG=Y will only be incrementally extracted from HDWF main driving table.

■ Soft deletion in data mart is dependent on HDWF main driving table and other driving tables. If any of the tables delete flag is Y, then the corresponding record in data mart is set to Y.

■ Two default records are inserted in all the dimensions with ROW_WID as -1 and -2.

Details

D-2 Oracle Health Sciences Translational Research Center Administrator's Guide

■ The system columns in the data mart are mapped one-to-one from HDWF main driving table.

■ The configuration tables necessary for execution of ETLs are created in HDWF and the CDM schema.

■ Versioning of seed data is not supported. If you want to change the seed data, update the seed data, and re-execute the ETL.

Index-1

Index

AArchitecture, 6-1Artifacts

Interfaces, B-4Sequences, B-3Variables, B-1

CC_COHORT_PROCEDURE_TYPE Table, 1-11C_LOAD_DATES Table, 7-1C_LOAD_DE_IDENTIFY, 1-6Configuring C_LOAD_PARAM, 1-1Configuring Informatica Workflows and Global

Parameter File, 3-1Current Flag, 6-2

DDatasource num ID, 6-1Delete Flag, 6-1

EETL, 6-1Executing ETL, 8-4Executing the ELT Execution Plan, 8-4Executing the Package, 9-1

FFull Load, 8-1

IIncremental Load, 8-3Informatica Architecture

ETL Behavior, 4-2Overview, 4-1Repository Artifacts, 4-3

Informatica ETLExecuting Full Load, 5-1Executing Incremental Load, 5-3

Informatica ETL ConfigurationStandard Configuration of C_LOAD_DATES_

INFA Table, 3-1

Integration ID, 6-1

OODI Repository Artifacts, 6-2

PPatches, ix

SScheduling an ELT Execution Plan, 8-6Scheduling Execution Plan, 8-6Statistics for Query Engine, 9-1

UUoM WID, 6-2Update Date, 6-1

VVersioning Logic, 6-2

Index-2