SAS® Insurance

Intelligence Solutions

Usage Guide for DDS

Edition 3.2 Release B 1.0

© 2006 SAS Institute Inc.

 Usage Agreement
Company means the legal entity represented by
its employees accepting the enclosed material.
SAS Institute Inc. and its subsidiaries do not
guarantee and shall not take any responsibility for
the success or failure of a project due to the use
of all or parts of the SAS® Insurance Intelligence
Solutions. It remains the sole responsibility of the
Company’s project manager and project team
members to utilize the SAS® Insurance
Intelligence Solutions material, to plan and to
manage project activities for a Company’s client.
SAS Institute Inc. and its subsidiaries shall not be
liable for failure of a project, any lost profits, or
other incidental, direct or indirect damages
resulting from such a project, through use of the
SAS® Insurance Intelligence Solutions and SAS®
Insurance Intelligence Solutions material.
SAS Institute Inc. and its subsidiaries do not
guarantee that the materials in this reference
manual are correct. If errors are found, SAS
Institute Inc.’s local subsidiaries should be notified
in writing.
SAS Institute Inc. or its subsidiaries do not offer
technical support for the SAS® Insurance Intelligence
Solutions or the use of the SAS® Insurance
Intelligence Solutions. The SAS® Insurance
Intelligence Solutions and any SAS® Insurance
Intelligence Solutions material are and will remain
the exclusive copyrighted property of SAS Institute
Inc. The Company is granted a non-transferable,
non-exclusive and gratuitous right to use the SAS®
Insurance Intelligence Solutions and SAS® Insurance
Intelligence Solutions material in any project where
Company is involved.
In the event the SAS® Insurance Intelligence
Solutions has become obsolete due to major product
developments, SAS Institute Inc.’s subsidiaries have
the right to request the Company to stop using the
SAS® Insurance Intelligence Solutions and SAS®
Insurance Intelligence Solutions material in future
projects. The Company agrees to adhere to this
request and discontinue using the SAS® Insurance
Intelligence Solutions and SAS® Insurance
Intelligence Solutions material.

The correct bibliographic citation for this manual is as follows:

SAS Institute Inc., SAS® Insurance Intelligence Solutions, Cary, NC: SAS Institute Inc., 2006.
32 pages.

SAS® Insurance Intelligence Solutions

Copyright 2006 by SAS Institute Inc., Cary, NC, USA.

All rights reserved. Printed in India. No part of this publication may be reproduced, stored in a retrieval
system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, or otherwise,
without the prior written permission of the publisher, SAS Institute Inc.

Restricted Rights Legend. Software and accompanying documentation are provided to the U.S.
government in a transaction subject to the Federal Acquisition Regulations with Restricted Rights. Use,
duplication, or disclosure of the software by the government is subject to restrictions as set forth in FAR
52.227-19 Commercial Computer Software-Restricted Rights (June 1987). The Contractor/Licensor is
SAS Institute Inc., located at SAS Campus Drive, Cary, North Carolina 27513.

SAS Institute Inc., SAS Campus Drive, Cary, North Carolina 27513.

1st printing, April 2006

SAS® and all other SAS Institute Inc. product or service names are registered trademarks or trademarks
of SAS Institute Inc. in the USA and other countries. ® indicates USA registration

ii SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Contents

Contents
Preface ........................................................................................................................................................... v
Purpose ...................................................................................................................................................... v
Who Should Read This Document........................................................................................................... v
How to Use This Document...................................................................................................................... v
Conventions ............................................................................................................................................... v
Part I. Acquisition ETL Guidelines ........................................................................................................ 1
1. Introduction ............................................................................................................................................... 2
1.1 Prerequisites ........................................................................................................................................ 2
1.2 Detail Data Store Foundation ............................................................................................................. 2
2. Guidelines for Acquisition ETL to DDS .................................................................................................. 3
2.1 Define Scope of Data Load into DDS................................................................................................. 3
2.2 Identify and Locate Data from Source Systems............................................................................... 4
2.3 Extract, Cleanse, Transform, and Consolidate Source Data in Staging Area............................... 6
2.4 Load the Reference Tables................................................................................................................. 6
2.5 Load and Validate Data into the DDS ................................................................................................ 7
Part II. IIS DDS Table Categories.......................................................................................................... 17
1. Introduction ............................................................................................................................................. 18
1.1 Main IIS DDS Tables .......................................................................................................................... 18
1.2 IIS DDS Write Back or Results Tables............................................................................................. 19
1.3 IIS DDS Reference Tables................................................................................................................. 20
Part III. Load Sequence of IIS DDS........................................................................................................ 21
1. Load Sequence for DDS ......................................................................................................................... 22
Part IV. Customizable Parameters......................................................................................................... 31
1. Customizable Parameter Details ........................................................................................................... 32

Figures
Figure 1 Sources and Stages Involved in Loading the DDS .............................................................3
Figure 2 Table Level ACORD Mapping.............................................................................................5
Figure 3 Column Level ACORD Mapping .........................................................................................5
Figure 4 Branch Office Hierarchy Example .....................................................................................18

Tables
Table 1 Input: A Sample Individual Customer Table with One Year of History .............................14
Table 2 Individual Output Table ...............................................................................................15
Table 3 INTERNAL_ORG Table ......................................................................................................19
Table 4 INTERNAL_ORG_ASSOC Table .........................................................................................19
Table 5 IIS Write Back Tables........................................................................................................19
Table 6 Category 5 Tables .............................................................................................................20
Table 7 Example of Data in the REFERENCE_MASTER Table ...................................................20
Table 8 Example of Data in the REFERENCE_DETAIL table: ......................................................20
Table 9 Load Sequence for DDS Load (General Insurance).........................................................22
Table 10 Load Sequence for DDS Load (Life Insurance) ................................................................26
Table 11 Customizable Parameters.................................................................................................32

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. iii
Usage Guide for DDS

iv SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Preface

Preface
Purpose
Insurance Intelligence Solutions contains best practice, industry-specific data, analytical models, and
templates. This document of the Insurance Intelligence Solutions provides acquisition ETL guidelines
for the Insurance DDS and the possible sources, load sequence, and priorities of tables.

Who Should Read This Document

This document should be read by anyone engaged in or about to be engaged in a project implementing
the Insurance DDS.

How to Use This Document

The main use of this document is to understand the data requirements for IIS 3.2 and identify the
possible data sources for tables. It also provides step by step guidance in writing acquisition ETL to
populate the Insurance DDS.

For details regarding the DDS, refer to the DDS Data Dictionary and the Data Model.

This document has four parts:

I Acquisition ETL Guidelines

II IIS DDS Table Categories
III Load Sequence of IIS DDS
IV Customizable Parameters

Conventions
The typographic and usage conventions of this guide are as follows:

Item Usage

Italics Italicized font is used within text for the values of fields that are typed in/entered
or selected in the UI. Italicized font is also used for book titles, new terminology,
emphasis, and values of configuration options.

Bold Bold font is used within text for key names, key combinations, key sequences,
menu items, and commands on menus, buttons, and various screen elements.

Monospace Monospace font is used within text for sample code and code listings, API and
language elements (such as function names and class names), file names,
path names, directory names, table names, column names, macro names and
HTML tags.

MonoItalics MonoItalics font is used within text to indicate variable placeholders in angular
brackets.

Note: Text in a gray box indicates a point of particular interest or that special notice should be
given to the text that follows.

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. v

Usage Guide for DDS

vi SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

Part I. Acquisition ETL
Guidelines
Usage Guide for DDS

1. Introduction
This section introduces the Detail Data Store (DDS) as the foundation for IIS implementation.

1.1 Prerequisites
The following are prerequisites for loading data into the DDS.

• Installation of the Insurance DDS Pack.

• Familiarity with general database technology, and data warehousing.

1.2 Detail Data Store Foundation

The primary foundation of the Insurance Intelligence Solutions (IIS) is the DDS. The DDS is a data
warehouse, a “single version of truth” that stores comprehensive, accurate, consolidated, and historical
information related to Insurance industry. The DDS serves as the primary data store for all the data
coming from the various source systems. It contains data at an atomic level and serves as a foundation
layer to populate all the IIS solution areas. A key difference from operational systems is that the
Insurance DDS is designed to capture current as well as historical data. Capturing historical data
includes the history of temporal data (event data that occurs at a particular date/time such as an
account inquiry) as well as non-temporal data (non-event data such as a customer or a financial
account). It also holds data that flows back from various solutions, and this data can again be used by
other solutions. Many of the Insurance DDS design decisions relate to the need for capturing this
historical data.

The benefits of implementing Insurance DDS at a customer’s site are:

• The Insurance DDS provides a single data target for loading data.
For example, assume that a customer first implements Customer Segmentation for Insurance,
and during the implementation populates the tables like CUSTOMER,
GENERAL_INSURANCE_POLICY, etc. Following the Customer Segmentation project, the
customer implements Customer Retention for Insurance. Since the CUSTOMER and
GENERAL_INSURANCE_POLICY tables have already been populated with cleansed data, the
customer can use the same tables in loading the Retention mart. Moreover, since the definition of
the DDS tables is already known, the ETL from the DDS to the Solutions data marts will be pre-
built.
• It ensures a “single version of truth” across solutions.
For example, the definition of “customer” should be the same for SAS Marketing Automation for
Insurance as well as for SAS Customer Retention for Insurance. Populating a single definition of
a customer table ensures that both of these solutions have a “single version of the truth.”
• Data created from SAS solutions can be stored in a central location and shared with other
solutions.
For example, the lapse scores from Customer Retention for Insurance are written back to the
DDS and shared with the Campaign Management for Insurance Solution.

2 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part I. Acquisition ETL Guidelines
Guidelines for Acquisition ETL to DDS

2. Guidelines for Acquisition ETL to DDS

Figure 1 Sources and Stages Involved in Loading the DDS

The following sections define the recommended process to load data into the DDS. Since this is a bespoke
development, it may be customized as deemed necessary.

The steps to load the DDS are:

1. Identify data structures in the DDS that need to be loaded to meet the business needs of the bank or
financial institution.
2. Identify and locate source systems for the data by mapping DDS data and source system data.
3. Extract, cleanse, and transform the source system files and consolidate them into the staging area
designed to load data into the DDS. The data here is validated to ensure that all
interdependencies/relationships in the DDS are defined.
4. Load reference tables that store code values required in the DDS using history management tool.
5. Load data into the DDS using history management tool and retained surrogate key approach.

Steps 2 to 5 become part of Acquisition ETL as depicted in Figure 1.

2.1 Define Scope of Data Load into DDS

The DDS has been designed to support multiple solution areas, though not all solutions will be
implemented simultaneously. Therefore, it is necessary to identify the precise information that needs to
be loaded into the DDS to support the Solutions to be implemented. This is often an iterative process.

Please refer to the Solution to DDS Map document to map it to the Solution area of your interest.

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 3

Usage Guide for DDS

Rather than indiscriminately populating everything, this document aims at identifying some priorities for
populating the DDS.

The following table categories are used in this document:

• Category 1: Mandatory tables for IIS. These are the tables, which are used across all the solution
areas.
• Category 2: Mandatory tables for one or more solution areas but not all.
• Category 3: Optional for solution areas or not required. These tables provide additional
information such as bureau information that provides more advanced analysis but is not
mandatory for the core functioning of the Solution Areas in IIS.
• Category 4: Output Tables. In IIS these are the Analytical Results tables. No data acquisition ETL
processes are required for these tables. These tables will be populated by the output from the
analytical models.
• Category 5: Reference tables.

The DDS tables have been classified according to these categories in Part II of this document, titled IIS
DDS Table Categories.

2.2 Identify and Locate Data from Source Systems

The next step is to identify the source systems that hold the required data. The IIS DDS can be
populated with data from operational systems or from an existing data warehouse, if this warehouse has
the required data. The data structures need to be identified within the source systems from which the
data needs to be extracted. This is done by mapping DDS data to data from the source systems.

2.2.1. Summary of Required Source Data

A high level overview of source systems or sub-systems generally available with insurers and
required for IIS is as follows:

• Underwriting systems
• Claims management systems
• Customer management systems—marketing/CRM
• Agency management systems
• Accounting systems
• Product management systems
• Transactional systems—systems where the transactions like premium collection, agency
payment, claim payment information is stored
• Analytical model and scoring system

2.2.2. ACORD Mapping

The IIS DDS provides mappings to ACORD, which is the most prevalent EDI standard in the
insurance industry. The IIS DDS provides a two level mapping with ACORD:

1. DDS Table Level: ACORD object or aggregate is mapped to the DDS table.
2. DDS Column Level: ACORD attribute to which the DDS column matches.

4 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part I. Acquisition ETL Guidelines
Guidelines for Acquisition ETL to DDS

The mappings are expressed in ERwin Detail Data Store Diagram as User Defined Property (UDP)
at both the table level and column level. It also specifies the segment of the insurance industry.
Examples of these are shown below.

Figure 2 Table Level ACORD Mapping

Figure 3 Column Level ACORD Mapping

These mapping can be used to load data into the IIS DDS if a customer has tools to map its source
system data to ACORD.

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 5

Usage Guide for DDS

2.3 Extract, Cleanse, Transform, and Consolidate Source

Data in Staging Area
The source system files are extracted, cleansed, transformed, and consolidated through multiple
staging areas. The last stage in the staging area is designed to load data into the DDS. The data here is
validated such that all interdependencies/relationships in the DDS will be defined. The data structure
here is a look-alike of the DDS except for the validity date pairs and surrogate keys in DDS required for
versioning. The data extracted in the staging area is supposed to be kept temporarily till the DDS is
loaded. Usually it has only the CDC (change data capture) during regular loads. The initial load is
handled separately. The staging area is used as a scratch pad.

2.4 Load the Reference Tables

2.4.1. Code-to-Description Reference Tables
Tables in the Reference subject area of the model provide reference data used in conjunction with
the main DDS model. These tables are standardized structures relating codes (short business keys)
to descriptions. These tables will be used to create SAS formats to present short coded values as
descriptive text for reporting or display purposes.

If the DDS table, which is to be populated, contains any column name ending with _CD, these
column names will have a corresponding reference table with the same column name. These
reference tables must also be populated. The table definition should clearly specify the data that is
required to populate the table.

These tables fall under Category 5 in the listing of IIS DDS table categories. Please refer to Part II of
this document, titled IIS DDS Table Categories for more information on IIS DDS categorization.

The load sequence for the reference table is provided in Part III of this document, titled Load
Sequence of IIS DDS.

The following consideration should be taken while loading the reference tables:

• Different source systems may use different codes to represent the same value.
• Codes as required by the DDS may not be defined.
• The column width of existing code columns may not match the width defined in the DDS.

To ensure that the code values are stored correctly and are as expected by the solutions that will
work off the DDS, a detailed exercise of code definition that includes business users, IT staff of the
bank or financial institution, and Insurance solution consultants, needs to be carried out. The
required codes can then be loaded using the supplied History Management macros so that the
versioning date columns are given suitable values or can be loaded manually. To know more on how
to load these tables using history management macros please refer to the History Management tool
documentation, which is included with the IIS 3.2 DDS Pack.

6 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part I. Acquisition ETL Guidelines
Guidelines for Acquisition ETL to DDS

Once the code values have been finalized, the customizable parameter file has to be modified. This
file holds all assumed code values in macro variables along with other date values required for load.
These macro variables are used to categorize data and populate the subsequent marts above the
DDS. This file needs to be modified to contain the code present in the reference tables of DDS.
Please ensure that the parameter file and actual code values in table are in synchronization. The
parameter file is provided with the IIS DDS Pack Installation. The name of file is
IIS_customize_para.sas. A list of global parameters with their assumed value is provided in
Part IV of this document, titled Customizable Parameters.

2.5 Load and Validate Data into the DDS

The final step is to load the data into the DDS followed by a process of validating that the data has been
successfully loaded. The consideration here is that data should be loaded in the correct sequence. For
example, an agent transaction cannot be loaded unless the agent for which the transaction has taken
place is first loaded into the DDS. The detailed sequence of loading DDS tables is as described in Part
III of this document, titled Load Sequence of IIS DDS.

There are a few important columns in the DDS tables, which play an important role in the DDS Load
and tracking history. These are described below.

2.5.1. Retained Key

The DDS can potentially hold data originating from multiple source systems. The primary key for
data in the DDS is therefore generated as part of this step. The column name of the DDS identifier
key has a suffix as “RK”. It is recommended to populate the _RK field that is part of the primary key
with a retained surrogate (generated) key approach. This numeric key does not change for the
different “versions” of the row.

The following table provides the structure for the reference table to generate the “RKs” for each of
the DDS tables. To generate the “RKs”, reference tables would be have to be created for the tables
that have the “Ref Table Required” value as “Y”.

Ref Table
Table Name Surrogate Key Reference Table Columns
Required
AIR_SPORT_DETAILS N LIFE_STYLE_ACTIVITY_
RK
ALARM_DETAILS Y ALARM_RK ALARM_TYPE_CD,
SUBJECT_OF_INSURANCE_RK
ANNUITY_POLICY_DETAILS N POLICY_RK
ANNUITY_PRODUCT N INSURANCE_PRODUCT
_RK
ANTI_THEFT_DEVICE N - NA -
AUTO_LOSS_DETAILS Y AUTO_LOSS_RK CLAIM_UNIT_RK, VEHICLE_NO
AVIATION_DETAILS N LIFE_STYLE_ACTIVITY_
RK
BATHROOM_TYPE_DETAILS Y BATHROOM_TYPE_RK BATHROOM_TYPE_CD
BLDG_IMPROVEMENT_DETAILS N SUBJECT_OF_INSURAN
CE_RK
BLDG_OCCUPANCY_DETAILS N SUBJECT_OF_INSURAN
CE_RK
BLDG_PROTECTION_DETAILS N SUBJECT_OF_INSURAN
CE_RK

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 7

Usage Guide for DDS
Ref Table
Table Name
Required
BUILTINS_DETAILS
CAMPAIGN
CARDIAC_MURMUR_DETAILS
CATASTROPHE
CLAIM_ADMINISTRATOR
CLAIM_DRIVER_DETAILS
CLAIM_INJURED_DETAILS
CLAIM_ITEM
CLAIM_SERVICE_PROVIDER
CLAIM_TRANS
CLAIM_TRANS_LINE_ITEM
CLAIM_UNIT
CLAIM_UNIT_X_ADMINISTRATOR
CLAIM_UNIT_X_SERVICE_PROVID
ER
CLAIMANT
CLIMBING_DETAILS
COINSURANCE_DETAILS
COL_INDEX
COMML_AUTO_SECTION
COMML_DRIVER_DETAILS
COMML_NON_OWNED_DETAILS
COMML_PROP_CONSTR_DETAILS
COMML_PROP_DETAILS
COMML_PROP_SECTION
COMML_VEHICLE_DETAILS
COMMUNICATION
COMPETITION_DETAILS
COMPLAINT
CONTRACT_ITEM
COST_CENTER
COST_CENTER_ASSOC
COVERAGE
COVERAGE_DETAILS
COVERAGE_OPTIONS_BENEFITS
COVERED_PERILS
CREDIT_SCORE_DETAILS
8 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.
Surrogate Key Reference Table Columns
Y BUILTINS_RK BUILTINS_CD, DWELL_RK
Y CAMPAIGN_RK CAMPAIGN_CD
N - NA -
Y CATASTROPHE_RK CATASTROPHE_CD
Y CLAIM_ADMINISTRATO CLAIM_ADMINISTRATOR_NO
R_RK
N - NA -
N - NA -
Y CLAIM_ITEM_RK CLAIM_ITEM_NO,
CLAIM_SERVICE_PROVIDER_RK
Y CLAIM_SERVICE_PROVI CLAIM_SERVICE_PROVIDER_ID
DER_RK
N - NA -
N - NA -
Y CLAIM_UNIT_RK CLAIM_RK, UOE_RK
N - NA -
N - NA -
Y CLAIMANT_RK CLAIMANT_ID
N LIFE_STYLE_ACTIVITY_
RK
N - NA -
N - NA -
N POLICY_SECTION_RK
N - NA -
Y NON_OWNED_CLASS_R NON_OWNED_CLASS_CD,
K POLICY_SECTION_RK
Y COMML_PROP_CONST CONSTR_CD,
R_RK SUBJECT_OF_INSURANCE_RK
Y SUBJECT_OF_INSURAN POLICY_SECTION_RK,
CE_RK LOCATION_RK,
SUBJECT_OF_INSURANCE_CD
N POLICY_SECTION_RK
N VEHICLE_RK
N - NA -
N LIFE_STYLE_ACTIVITY_
RK
N - NA -
Y CONTRACT_ITEM_RK SERIAL_NO,
SUBJECT_OF_INSURANCE_RK
Y COST_CENTER_RK COST_CENTER_ID
N - NA -
Y COVERAGE_RK COVERAGE_CD
Y COVERAGE_RK COVERAGE_NO
Y OPTION_RK PRODUCT_CD, COVERAGE_RK
N - NA -
N -NA-
 Part I. Acquisition ETL Guidelines
Guidelines for Acquisition ETL to DDS

Ref Table
Table Name Surrogate Key Reference Table Columns
Required
CREDIT_SURCHARGE N CREDIT_SURCHARGE_ CREDIT_SURCHARGE_CD,
RK UOE_RK
CRIME_DETAILS N SUBJECT_OF_INSURAN
CE_RK
CRIMINAL_CONVICTION_DETAILS Y CRIME_TYPE_RK CRIME_TYPE_CD, INSURED_RK
CUSTOMER Y CUSTOMER_RK CUSTOMER_ID
CUSTOMER_COMMUNICATION N - NA -
CUSTOMER_SURVEY N - NA -
DECK_DETAILS Y DECK_RK DECK_ID, DWELL_RK
DEDUCTIBLE Y DEDUCTIBLE_RK DEDUCTIBLE_TYPE_CD, UOE_RK
DIVE_PURPOSE_DETAILS N LIFE_STYLE_ACTIVITY_
RK
DRIVER Y DRIVER_RK DRIVER_NO
DRIVER_HISTORY N - NA -
DRIVER_VEHICLE_DETAILS N - NA -
DWELL_DETAILS Y DWELL_RK DWELL_ID,
SUBJECT_OF_INSURANCE_RK
EMPLOYEE Y EMPLOYEE_RK EMPLOYEE_ID
EVENT N - NA -
EXTERNAL_ORG Y EXTERNAL_ORG_RK EXTERNAL_ORG_REFERENCE_N
O
EXTERNAL_ORG_ADDRESS Y ORG_ADDRESS_RK ADDRESS_TYPE_CD,
EXTERNAL_ORG_RK
EXTERNAL_ORG_ASSOC N - NA -
FAMILY_ILLNESS_DETAILS Y FAMILY_ILLNESS_RK FULL_NM, INSURED_RK
FEES Y FEE_RK INSURANCE_PRODUCT_RK,
FEE_TYPE_CD
FLEET_DETAILS Y FLEET_RK FLEET_ID
FOREIGN_TRAVEL_DETAILS N - NA -
GARAGE_TYPE_DETAILS Y GARAGE_TYPE_RK GARAGE_TYPE_CD, DWELL_RK
GENERAL_APPLN_DETAILS Y APPLICATION_RK APPLICATION_NO
GENERAL_INSURANCE_CLAIM Y CLAIM_RK INSURANCE_CLAIM_NO,
POLICY_RK
GENERAL_INSURANCE_POLICY Y POLICY_RK ORIGINAL_POLICY_NO
GENERAL_INSURANCE_PRODUCT Y INSURANCE_PRODUCT INSURANCE_PRODUCT_CD
_RK
GENERAL_POLICY_TRANS N - NA -
GENERAL_POLICY_TRANS_LINE_I N - NA -
TEM
GENERAL_PRODUCT_CATEGORY Y PRODUCT_CATEGORY_ PRODUCT_CATEGORY_CD
RK
GENERAL_UNIT_OF_EXPOSURE Y UOE_RK SUBJECT_OF_INSURANCE_RK,
PRODUCT_COVERAGE_RK
GL_ACCOUNT N - NA -
GL_ACCOUNT_ASSOC N - NA -
GL_ACCOUNT_BALANCE N - NA -
GL_JRNL N - NA -

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 9

Usage Guide for DDS
Ref Table
Table Name
Required
GL_JRNL_DETAILS
GLASS_SIGN_TYPE_DETAILS
HEATING_UNIT_DETAILS
INCIDENT_DETAILS
INCOME_OPTIONS
INCOME_PAYOUT_DETAILS
INDIVIDUAL
INDIVIDUAL_ADDRESS
INDIVIDUAL_ASSOC
INSURANCE_POLICY_RESTRICTIO
NS
INTERIOR_FINISH_DETAILS
INTERNAL_ORG
INTERNAL_ORG_ASSOC
INVENTORY_DETAILS
INVESTMENT_DETAILS
INVESTMENT_PRODUCT
ITEM_CATEGORY
ITEM_CATEGORY_ASSOC
ITEM_DETAILS
LEASE_DETAILS
LIFE_APPLN_DETAILS
LIFE_INSURANCE_CLAIM
LIFE_INSURANCE_POLICY
LIFE_INSURANCE_PRODUCT
LIFE_INSURANCE_TRANS
LIFE_POLICY_DETAILS
LIFE_PRODUCT
LIFE_RISK
LIFE_STYLE_DETAILS
LIFE_UNIT_OF_EXPOSURE
LIMIT
LINE_OF_BUSINESS
LINE_OF_BUSINESS_ASSOC
LOAN
LOCATION
10
Surrogate Key
N - NA -
Y SCHEDULE_TYPE_RK
Y HEATING_UNIT_RK
Y INCIDENT_RK
Y INCOME_OPTION_RK
Y INCOME_PAYOUT_RK
N INDIVIDUAL_RK
Y INDIVIDUAL_ADDRESS_
RK
N - NA -
Y RESTRICTION_RK
Y INTR_FINISH_RK
Y INTERNAL_ORG_RK
N - NA -
N SUBJECT_OF_INSURAN
CE_RK
N POLICY_RK
Y INVESTMENT_PRODUC
T_RK
Y ITEM_CATEGORY_RK
N - NA -
N - NA -
N SUBJECT_OF_INSURAN
CE_RK
Y APPLICATION_RK
Y CLAIM_RK
Y POLICY_RK
Y INSURANCE_PRODUCT
_RK
N - NA -
N POLICY_RK
N INSURANCE_PRODUCT
_RK
Y INSURED_RK
Y LIFE_STYLE_ACTIVITY_
RK
Y UOE_RK
Y LIMIT_RK
Y LOB_RK
N - NA -
Y LOAN_RK
Y LOCATION_RK
SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.
Reference Table Columns
SCHEDULE_TYPE_CD,
SUBJECT_OF_INSURANCE_RK
HEATING_UNIT_ID, DWELL_RK
INCIDENT_TYPE_CD, LOSS_DT,
LOSS_TM
INCOME_OPTION_CD,
INCOME_PAYOUT_RK
PRODUCT_CD,
INSURANCE_PRODUCT_RK
ADDRESS_TYPE_CD,
INDIVIDUAL_RK
RESTRICTION_CD, POLICY_RK
INTR_FINISH_ID, DWELL_RK
INTERNAL_ORG_REFERENCE_NO
INVESTMENT_PRODUCT_CD,
INSURANCE_PRODUCT_RK
ITEM_CATEGORY_CD
APPLICATION_NO
CLAIM_REFERENCE_NO
POLICY_NO
PRODUCT_CD
INSURED_ID
LIFE_STYLE_ACTIVITY_TYPE_CD,
INSURED_RK
COVERAGE_RIDER_RK,
INSURED_RK
UOE_RK, LIMIT_APPLIES_TO_CD
LOB_CD
LOAN_NO
LOCATION_ID
 Part I. Acquisition ETL Guidelines
Guidelines for Acquisition ETL to DDS

Ref Table
Table Name Surrogate Key Reference Table Columns
Required
MEDICAL_CONDITION_DETAILS Y CONDITION_TYPE_RK CONDITION_TYPE_CD,
INSURED_RK
MEDICAL_EXAM_DETAILS N - NA -
MEDICAL_PREVENTION_DETAILS Y TEST_TYPE_RK TEST_TYPE_CD, INSURED_RK
MEDICAL_TREATMENT_DETAILS Y TREATMENT_TYPE_RK TREATMENT_TYPE_CD,
CONDITION_TYPE_RK
MILITARY_EXP_DETAILS N INSURED_RK
MONEY_DETAILS N SUBJECT_OF_INSURAN
CE_RK
PAYEE Y PAYEE_RK PAYEE_ID
PAYOUT Y PAYOUT_RK PAYOUT_CD, POLICY_RK
PERIL N - NA -
PERS_ACCIDENT_SECTION N POLICY_SECTION_RK
PERS_ACCIDENT_SECTION_DETA Y INSURED_RK INSURED_ID
ILS
PERS_AUTO_SECTION N POLICY_SECTION_RK
PERS_DRIVER_DETAILS N DRIVER_RK
PERS_PROP_CONSTR_DETAILS Y PERS_PROP_CONSTR_ CONSTR_CD, DWELL_RK
RK
PERS_PROP_SECTION N POLICY_SECTION_RK
PERS_VEHICLE_DETAILS N VEHICLE_RK
PHYSICIAN Y PHYSICIAN_RK PHYSICIAN_ID
POLICY_SECTION Y POLICY_SECTION_RK POLICY_RK,
PRODUCT_SECTION_RK
PORCH_TYPE_DETAILS Y PORCH_TYPE_RK PORCH_TYPE_CD, DWELL_RK
PRESCRIPTION_DRUG_DETAILS Y PRESCRIPTION_DRUG_ PRESCRIPTION_DRUG_TYPE_CD,
RK INSURED_RK
PRODUCER Y PRODUCER_RK PRODUCER_ID
PRODUCER_LICENSE N - NA -
PRODUCER_TARGETS N - NA -
PRODUCER_TRANS N - NA -
PRODUCER_TRANS_LINE_ITEM N - NA -
PRODUCER_X_INTERNAL_ORG N - NA -
PRODUCER_X_UOE N - NA -
PRODUCT_COVERAGE Y PRODUCT_COVERAGE_ PRODUCT_COVERAGE_CD
RK
PRODUCT_FEATURES Y FEATURE_RK FEATURE_CD,
INSURANCE_PRODUCT_RK
PRODUCT_SECTION N PRODUCT_SECTION_R
K
PROFIT_CENTER Y PROFIT_CENTER_RK PROFIT_CENTER_ID
PROFIT_CENTER_ASSOC N - NA -
PROP_LOSS_DETAILS Y PROPERTY_LOSS_RK CLAIM_UNIT_RK,
SUBJECT_OF_INSURANCE_RK
RACING_DETAILS N LIFE_STYLE_ACTIVITY_
RK
REINSURANCE_CARRIER Y REINSURER_RK REINSURER_CARRIER_CD

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 11

Usage Guide for DDS

Ref Table
Table Name Surrogate Key Reference Table Columns
Required
REINSURANCE_DETAILS Y TREATY_RK CEDENTS_TREATY_ID
REP_GRP Y REP_GRP_RK REP_GRP_CD, SECTION_RK
REP_GRP_ASSOC N - NA -
RESERVES_ESTIMATES N - NA -
RESPONSE N - NA -
SAFE_VAULT_DETAILS Y SAFE_RK SAFE_NO,
SUBJECT_OF_INSURANCE_RK
SALVAGE_DETAILS N - NA -
SECTION Y SECTION_RK SECTION_CD
SECURITY_DETAILS N SUBJECT_OF_INSURAN
CE_RK
SERVICED_TERMINAL_DETAILS N - NA -
SPECIALTY_ROOM_DETAILS Y SPECIALITY_ROOM_RK SPECIALITY_ROOM_CD,
DWELL_RK
SUB_ACCOUNT Y SUB_ACCOUNT_RK SUB_ACCOUNT_ID
SUB_ACCOUNT_AMOUNTS N - NA -
SUBS_USAGE_DETAILS Y SUBSTANCE_TYPE_RK SUBSTANCE_TYPE_CD,
INSURED_RK
SUBSTRUCTURE_TYPE_DETAILS Y SUBSTRUCTURE_TYPE SUBSTRUCTURE_TYPE_CD,
_RK DWELL_RK
SUPER_ANNUATION_DETAILS N POLICY_RK
SURVEY N - NA -
SURVEY_ANSWER N - NA -
SURVEY_QUESTION N - NA -
SWIMMING_POOL_DETAILS Y SWIMMING_POOL_RK SWIMMING_POOL_NO,
SUBJECT_OF_INSURANCE_RK
TARIFF_DETAILS N - NA -
TRUCKERS_TERMINAL N - NA -
UNDERWATER_DIVING_DETAILS N LIFE_STYLE_ACTIVITY_
RK
UW_CLASS_DETAILS Y UW_CLASS_RK UW_CLASS_CD, COVERAGE_RK
VEHICLE Y VEHICLE_RK VEH_IDENTIFICATION_NO
VEHICLE_ACCESSORIES N VEHICLE_RK
VIOLATION_DETAILS Y VIOLATION_RK VIOLATION_TYPE_CD,
INSURED_RK
YOUNG_DRIVER_DETAILS N DRIVER_RK

2.5.2. Valid_From_Dttm and Valid_To_Dttm

These columns are used in conjunction with the _RK column to track changes over time. These
dates describe the time period during which the contents of the row is valid. It is used as a
versioning base. It is recommended that VALID_TO_DTTM be set to a date far into the future for
ease of joins. If the source system does not track historical changes to records, the
VALID_FROM_DTTM and VALID_TO_DTTM would correspond to the date/time the DDS was loaded.
However, if the source system captured multiple changes of a row between load times of the DDS,
then there could be more than one row for the same retained key for a given load into the DDS.

12 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part I. Acquisition ETL Guidelines
Guidelines for Acquisition ETL to DDS

Known choices for creating the VALID_FROM_DTTM values are:

• Business Timestamps – This is the value that should normally be used. Using the business
processing date timestamps as VALID_FROM_DTTM will help in cases of initial load and also
from a perspective of reconciling with the source system figures.
• DDS load DateTime – not recommended.
• ETL extract DateTime – not recommended.

As mentioned above, the primary purpose of the VALID_FROM/VALID_TO DateTime pair is to

record versioning.

2.5.3. Processed Date/Time

Along with VALID_FROM_DTTM and VALID_TO_DTTM, it is also useful to capture the last time a row
was processed in the DDS. Processing of the row could include either the initial creation of the row
or updating of a row. The PROCESSED_DTTM is used to determine which rows have been changed
since the last loading into the data mart.

PROCESSED_DTTM denotes the last time the record was updated by the data administrator for
unusual updates, such as error correction and data patching, that do not version the row. If the
record does not have unusual updates, set the value to the DateTime stamp when the record was
loaded in the warehouse.

2.5.4. Business Keys

In DDS tables, it is often useful to keep the primary source system identifier (also known as
“business key”). Business keys in most tables in the DDS are represented as <TABLE_NAME>_ID,
<TABLE_NAME>_CD, etc. These business keys originate from the source systems and typically
contain long alphanumeric strings. Retaining this key is often useful when there is a need to go back
to the transactional systems to investigate data at the source.

2.5.5. Periodicity of Load/Load Frequency and History

Consideration
The IIS DDS and associated solutions are designed to support any periodic load frequency namely
daily, weekly, or monthly. The DDS is designed to support ad-hoc loads. Partial loads where parts of
information are loaded into the DDS are also supported, provided consistency of the data is
maintained.

The minimum history required for the data in the DDS tables is dependant on the solution specific
history requirement as well as on the amount of historical data available in the source system.

Some examples of the historical data requirement for the solutions that will be implemented are
given below.

• The recommended history for a reasonably accurate analytical model is 3 complete years.
• For campaign management in IIS, there is no specific minimum history required in the DDS.
The solution can initially be used even with current information. Solution capabilities can be
significantly enhanced with up to 24 months of history.
• Similarly, for the Customer Base Reporting, Claims Reporting, Product Performance
Reporting and Agency Management Solutions, history requirements depend on the specific
reporting requirements.

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 13

Usage Guide for DDS

Usually five to six years of history can be kept in the current warehouse and the rest can be backed
up on tapes.

The expected load frequency for IIS DDS is daily.

2.5.6. Loading the DDS

While loading data into the DDS from staging, the business key of the source data is matched with
data available in the DDS. If it exists in the DDS, the existing DDS record is expired and a new
record is inserted with the updated information. The identifier key in the DDS retains the same value
while the validity dates are changed.

A history management tool is provided to load the DDS from the staging area. To understand more
about the usage of this history management macro please refer to the History Management tool
documentation included with the IIS 3.2 DDS Pack.

The sequence to load the DDS table is provided in Part III of this document, titled Load Sequence of
IIS DDS.

Initial Load
During initial load, the process of extracting the data from source systems to staging area will be
similar to the above, but will contain complete history instead of only the latest change. The
History Management macros allow the initial load of history spanning over years with some
special control parameters and assumptions. Please refer to the History Management macros
documentation for details regarding implementation.

A simple example of loading a Customer Table in IIS DDS from a sample Customer Input Table
in staging is explained. It also shows an example to call the history management macro.

In this example the change in record_date is considered as a versioning date.

Step 1
Table 1 Input: A Sample Individual Customer Table with One Year of History
Customer
NAME ADDRESS GENDER_CD RECORD_DATE
Input Table
AP1001 Sam 32, Palm Grove, Hill Range, Male 1-Jan-03
Singapore.
AP1002 Terry 35, Palm Grove, Singapore. Male 4-Jan-03
AP1001 Sam #18-02, Block 35, Tampines Male 5-May-03
North Street Singapore.
AP1001 Sam #02-05, Mandarin Gardens, East Male 7-Jul-03
Coast Road, Singapore.
AP1001 Sam #04-123, Block 2, Lavender Male 9-Oct-03
Street, Singapore.

In the above table, the customer named Sam has changed his address four times in the year
2003. The RECORD_DATE (critical for initial load which is business_dttm) actually represents a
date when the OLTP system tracked his change of address (that is, the date when they enter this
record in OLTP system).

14 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part I. Acquisition ETL Guidelines
Guidelines for Acquisition ETL to DDS

Step 2
Perform initial load of 2003 to DDS on 01Jan2004.

Assume that you are loading all of this one year’s data into Customer table of the DDS.

The history management tool will use the Business_Dttm to populate the Valid_From_Dttm
and Valid_To_Dttm dates in the warehouse.

Call of history management macro - update_with_history - is as follows:

%update_with_history(
history_table = Customer,
update_table = Customer,
business_key = customer_id,
surrogate_key = customer_rk,
business_dttm = record_date,
versioning_base = BUSINESS_DTTM,
load_run_dttm = 01jan2004:00:00:00
);

Step 3
Output table Customer with Retain Surrogate Key Approach.

Please see the change in value of Valid_From_Dttm and Valid_To_Dttm and the retained
surrogate key Customer_Rk, which has been added.

Table 2 Individual Output Table

VALID_FROM_DTTM

PROCESSED_DTTM
VALID_TO_DTTM
CUSTOMER_RK

CUSTOMER_ID

GENDER_CD
ADDRESS
NAME

1 AP1001 Sam 32, Palm Grove, Hill Male 01JAN2003:00: 04MAY2003:23: 1-Jan-
Range, Singapore. 00:00 59:59 04
2 AP1002 Terry 35, Palm Grove, Male 04JAN2003:00: 31DEC4747:00: 1-Jan-
Singapore. 00:00 00:00 04
1 AP1001 Sam #18-02, Block 35, Male 05MAY2003:00: 06JUL2003:23: 1-Jan-
Tampines North 00:00 59:59 04
Street Singapore.
1 AP1001 Sam #02-05, Mandarin Male 07JUL2003:00: 08OCT2003:23: 1-Jan-
Gardens, East Coast 00:00 59:59 04
Road, Singapore.
1 AP1001 Sam #04-123, Block 2, Male 09OCT2003:00: 01DEC2003:23: 1-Jan-
Lavender Street, 00:00 59:59 04
Singapore.
1 AP1001 Sam #05-00 Astona Park, Male 02DEC2003:00: 31DEC4747:00: 1-Jan-
Kembangan, Bedok, 00:00 00:00 04
Singapore.

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 15

Usage Guide for DDS

Step 4
Following this, all other tables related to the customers can be loaded in a similar fashion. If any
child table contains customer_rk as foreign key, then it will use one more macro, namely,
<map_business_to_surrogate> in the history management tool to generate the foreign keys
in that child table.

Regular Load
Once the initial data is in, the load frequency will become atomized and regular. The regularity
can be daily/weekly/monthly depending upon the solution requirements and data availability.
During regular load, the staging area will be populated with the CDC (change data capture)
principle, that is, with only the latest changes.

The History Management tool can be used as explained for the initial loads except few changes
in the parameters.

16 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

Part II. IIS DDS Table
Categories
Usage Guide for DDS

1. Introduction
This section provides the categorization listing for all the IIS DDS tables. The tables in the IIS DDS can be
broadly categorized into the following:

• Main IIS DDS Tables: These are the tables that will be used across multiple solution areas. To
find the tables that are required for implementing a solution area, please refer to the Solution to
DDS Map document.
• IIS DDS Write Back or Results Tables
• Reference Tables

1.1 Main IIS DDS Tables

The amount of history to be retained in the DDS tables depends on the solution areas being
implemented and also on the availability of historical data. Normally for most of the solution areas, at
least 36 months of history would be required. If data is available this should be the amount of data that
should be loaded as part of the initial load for the IIS DDS.

The IIS DDS also supports any required load frequency. The load frequency for different tables may
differ, but it is important to ensure that data within the DDS remains consistent. For example, to avoid
the situation of policies without agents, the policy information should not be loaded without loading
agent information. The load frequency is generally business driven and depends on the business
expectation from solutions and reports that source data from the DDS.

1.1.1. Association Tables

The association tables from IIS DDS provide flexibility of modeling multiple hierarchies for any entity.
It is a generic structure used to model multiple hierarchies of varying depths. For example, an
insurer may have a branch office geography hierarchy and a separate reporting hierarchy. Both of
these can be modeled in the INTERNAL_ORG, INTERNAL_ORG_ASSOC table. The method of
putting data in these tables is explained with an example below:

ORG5

ORG3 ORG4

ORG1 ORG2

GEO – Geography Hierarchy

REP – Reporting Hierarchy

Figure 4 Branch Office Hierarchy Example

18 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part II. IIS DDS Table Categories
Introduction

Table 3 INTERNAL_ORG Table

INTERNAL_ORG_RK ORG_NM INTERNAL_ORG_REFERENCE_NO
3001 ORG1 IT1
3002 ORG2 IT2
4001 ORG3 T2
4002 ORG4 T3
5001 ORG5 AT3

Table 4 INTERNAL_ORG_ASSOC Table

ITEM_CATE PARENT_ITEM_ ITEM_CATEGORY_ LEVEL_NO LEVEL_DESC
GORY_RK CATEGORY_RK ASSOC_TYPE_CD
3001 4001 GEO 3 CITY_OFFICE
3002 4002 GEO 3 CITY_OFFICE
4001 5001 GEO 2 ZONE
4002 5001 GEO 2 ZONE
5001 5001 GEO 1 HQ
3001 5001 REP 2 REP_BRANCH
3002 5001 REP 2 REP_BRANCH
4001 5001 REP 2 REP_BRANCH
4002 5001 REP 2 REP_BRANCH
5001 5001 REP 1 HQ

1.2 IIS DDS Write Back or Results Tables

These are the tables for which data is generated by the solutions like analytical model results and
customer communication and response data from campaign management, etc. The various IIS
solutions would act as the source systems for these tables. The update frequency of these tables would
depend on the frequency with which scoring is done or campaigns are run.

Table 5 IIS Write Back Tables

Serial No. Table Name
1. ANALYTICAL_MODEL
2. CUST_SEGMENT
3. POLICY_SEGMENT
4. CUST_MODEL_SCORE
5. POLICY_MODEL_SCORE
6. RATEMAKING_CLAIM_FREQ_SEVERITY
7. RATEMAKING_FACTOR
8. RESPONSE
9. CUSTOMER_COMMUNICATION
10. EVENT

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 19

Usage Guide for DDS

1.3 IIS DDS Reference Tables

In IIS, reference data is stored in the form of master and detail tables. These are populated initially
before all other tables. They are subsequently updated only if the codes or their descriptions change.
These tables are used in IIS to generate SAS formats.

Table 6 Category 5 Tables

Serial No. Table Name

1. REFERENCE_MASTER
2. REFERENCE_DETAIL

The REFERENCE_MASTER table holds all the details about the columns that have reference values,
for example, GENDER_CD, STD_OCCUPATION_CD, etc.

Table 7 Example of Data in the REFERENCE_MASTER Table

COLUMN_NAME FORMAT_NM FORMAT_TYPE PROCESSED_DTTM
GENDER_CD GENDER C 10JAN2005:00:00:00
STD_OCCUPATION_CD STDOCC C 10JAN2005:00:00:00

The REFERENCE_DETAIL table would have the details for the columns in terms of their code values
and description.

Table 8 Example of Data in the REFERENCE_DETAIL table:

COLUMN_NAME CODE_ VALID_FROM_D CODE_DES VALID_TO_DTT PROCESSED_DT
VALUE TTM C M TM
GENDER_CD M 10JAN2005:00:0 Male 31DEC4747:23:5 10JAN2005:00:00:
0:00 9:59 00
GENDER_CD F 10JAN2005:00:0 Female 31DEC4747:23:5 10JAN2005:00:00:
0:00 9:59 00
STD_OCCUPATION E 10JAN2005:00:0 Engineer 31DEC4747:23:5 10JAN2005:00:00:
_CD 0:00 9:59 00
STD_OCCUPATION L 10JAN2005:00:0 Lawyer 31DEC4747:23:5 10JAN2005:00:00:
_CD 0:00 9:59 00
STD_OCCUPATION D 10JAN2005:00:0 Doctor 31DEC4747:23:5 10JAN2005:00:00:
_CD 0:00 9:59 00

NOTE: REFERENCE_MASTER and REFERENCE_DETAIL tables are pre-populated and provided with
this DDS pack with dummy values for codes. REFERENCE_MASTER table includes all code columns from
DDS along with SAS format name for each. These formats are applied on cubes in various solutions.

20 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

Part III. Load Sequence
of IIS DDS
Usage Guide for DDS

1. Load Sequence for DDS

The loading of DDS will need to follow a sequence in order to take care of all the table dependencies. The
detailed sequence for loading the DDS tables is given in the tables below. The load sequence for Life and
General insurance business is given separately.

The REFERENCE_DETAIL table contains _cd values for codes and their descriptions. It is often
necessary to establish the final codes and their descriptions across the enterprise. For example, across all
departments of an insurer, the transaction_type_cd values of payment, withdrawal, etc., need to be
agreed upon. Often code harmonization across departments is necessary as they view business from
different perspectives. Also, if different departments use different systems then the codes differ across
those systems. The reference tables are populated once codes and their descriptions are established
across the enterprise. The code values change very rarely and normally only the latest values are kept.
The data for these tables can sometimes come from operational systems. In other cases, they are
prepared by consultants themselves in consultation with the client.

Examples of master tables are CUSTOMER, PRODUCER, GENERAL_INSURANCE_PRODUCT, etc. These

tables can be populated from the operational systems or the data warehouse. Sometimes the master
tables also have an inter-dependency that needs to be considered before sequencing the load.

Examples of transaction tables are GENERAL_POLICY_TRANS, GENERAL_POLICY_TRANS_LINE_ITEM,

etc. These tables need the master information to be in place. For example, GENERAL_POLICY_TRANS
requires the corresponding GENERAL_INSURANCE_POLICY to be loaded first.

The loading of the DDS must follow a recommended sequence in order to take care of all the table
dependencies. Based on the inter-table load dependency, the following sequence is recommended. In
each wave, the load for all the tables in the wave can happen simultaneously; however, you cannot
proceed to load any table in the next wave without completing the load for all the tables in the previous
wave, that is, the load must follow an ascending sequence of waves.

Table 9 Load Sequence for DDS Load (General Insurance)

Wave 1
CATASTROPHE
CLAIM_ADMINISTRATOR
CLAIM_SERVICE_PROVIDER
CLAIMANT
CUSTOMER
EVENT
EXTERNAL_ORG
EXTERNAL_ORG_ADDRESS
GENERAL_PRODUCT_CATEGORY
GL_ACCOUNT
INDIVIDUAL
INDIVIDUAL_ADDRESS
INTERNAL_ORG
LINE_OF_BUSINESS

22 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part III. Load Sequence of IIS DDS
Load Sequence for DDS

Wave 1
PRODUCER
REINSURANCE_CARRIER
SURVEY

Wave 2
CAMPAIGN
COVERAGE
CUSTOMER_SURVEY
EMPLOYEE
EXTERNAL_ORG_ASSOC
GENERAL_INSURANCE_PRODUCT
GL_ACCOUNT_ASSOC
GL_ACCOUNT_BALANCE
INDIVIDUAL_ASSOC
INTERNAL_ORG_ASSOC
LINE_OF_BUSINESS_ASSOC
PRODUCER_LICENSE
PRODUCER_TARGETS
PRODUCER_X_INTERNAL_ORG
RESERVES_ESTIMATES
SECTION
SURVEY_QUESTION

Wave 3
COMMUNICATION
COST_CENTER
PERIL
PRODUCT_SECTION
PROFIT_CENTER
REP_GRP
SURVEY_ANSWER

Wave 4
COST_CENTER_ASSOC
CUSTOMER_COMMUNICATION
PRODUCT_COVERAGE
PROFIT_CENTER_ASSOC
REP_GRP_ASSOC

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 23

Usage Guide for DDS

Wave 5
GENERAL_APPLN_DETAILS
GENERAL_INSURANCE_POLICY
RESPONSE

Wave 6
COINSURANCE_DETAILS
COINSURANCE_DETAILS
COMML_AUTO_SECTION
COMML_PROP_SECTION
CREDIT_SCORE_DETAILS
GENERAL_POLICY_TRANS
GENERAL_POLICY_TRANS_LINE_ITEM
LOCATION
PERS_ACCIDENT_SECTION
PERS_AUTO_SECTION
PERS_PROP_SECTION
POLICY_SECTION

Wave 7
COMML_NON_OWNED_DETAILS
COMML_PROP_DETAILS
DRIVER
DWELL_DETAILS
FLEET_DETAILS
GL_JRNL
GL_JRNL_DETAILS
ITEM_DETAILS
PERS_ACCIDENT_SECTION_DETAILS
SERVICED_TERMINAL_DETAILS
TRUCKERS_TERMINAL
VEHICLE

Wave 8
ALARM_DETAILS
ANTI_THEFT_DEVICE
BATHROOM_TYPE_DETAILS
BLDG_IMPROVEMENT_DETAILS
BLDG_OCCUPANCY_DETAILS

24 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part III. Load Sequence of IIS DDS
Load Sequence for DDS

Wave 8
BLDG_PROTECTION_DETAILS
BUILTINS_DETAILS
COMML_DRIVER_DETAILS
COMML_PROP_CONSTR_DETAILS
COMML_VEHICLE_DETAILS
CONTRACT_ITEM
CRIME_DETAILS
DECK_DETAILS
DRIVER_VEHICLE_DETAILS
GARAGE_TYPE_DETAILS
GENERAL_UNIT_OF_EXPOSURE
GLASS_SIGN_TYPE_DETAILS
HEATING_UNIT_DETAILS
INTERIOR_FINISH_DETAILS
INVENTORY_DETAILS
LEASE_DETAILS
MONEY_DETAILS
PERS_DRIVER_DETAILS
PERS_PROP_CONSTR_DETAILS
PERS_VEHICLE_DETAILS
PORCH_TYPE_DETAILS
SAFE_VAULT_DETAILS
SECURITY_DETAILS
SPECIALTY_ROOM_DETAILS
SUBSTRUCTURE_TYPE_DETAILS
SWIMMING_POOL_DETAILS
VEHICLE_ACCESSORIES

Wave 9
CATASTROPHE
COMPLAINT
COVERED_PERILS
CREDIT_SURCHARGE
DEDUCTIBLE
DRIVER_HISTORY
GENERAL_INSURANCE_CLAIM
INCIDENT_DETAILS
LIMIT

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 25

Usage Guide for DDS

Wave 9
PRODUCER_TRANS
PRODUCER_TRANS_LINE_ITEM
PRODUCER_X_UOE
REINSURANCE_DETAILS
TARIFF_DETAILS
YOUNG_DRIVER_DETAILS

Wave 10
CLAIM_TRANS
CLAIM_TRANS_LINE_ITEM
CLAIM_UNIT
ITEM_CATEGORY
ITEM_CATEGORY_ASSOC
CLAIM_TRANS

Wave 11
AUTO_LOSS_DETAILS
CLAIM_DRIVER_DETAILS
CLAIM_INJURED_DETAILS
CLAIM_UNIT_X_ADMINISTRATOR
CLAIM_UNIT_X_SERVICE_PROVIDER
PROP_LOSS_DETAILS
SALVAGE_DETAILS

Wave 12
CLAIM_ITEM

Table 10 Load Sequence for DDS Load (Life Insurance)

Wave 1
CLAIM_ADMINISTRATOR
CLAIM_SERVICE_PROVIDER
CLAIMANT
CUSTOMER
EVENT
EXTERNAL_ORG
EXTERNAL_ORG_ADDRESS
GL_ACCOUNT
INDIVIDUAL
INDIVIDUAL_ADDRESS

26 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part III. Load Sequence of IIS DDS
Load Sequence for DDS

Wave 1
INTERNAL_ORG
LIFE_INSURANCE_PRODUCT
LINE_OF_BUSINESS
PHYSICIAN
PRODUCER
REINSURANCE_CARRIER
SURVEY

Wave 2
ANNUITY_PRODUCT
CAMPAIGN
CUSTOMER_SURVEY
EMPLOYEE
EXTERNAL_ORG_ASSOC
FEES
GL_ACCOUNT_ASSOC
GL_ACCOUNT_BALANCE
INDIVIDUAL_ASSOC
INTERNAL_ORG_ASSOC
INVESTMENT_PRODUCT
LIFE_APPLN_DETAILS
LIFE_PRODUCT
LINE_OF_BUSINESS_ASSOC
PRODUCER_LICENSE
PRODUCER_TARGETS
PRODUCER_X_INTERNAL_ORG
RESERVES_ESTIMATES
SURVEY_QUESTION

Wave 3
COMMUNICATION
COST_CENTER
COVERAGE_DETAILS
INCOME_PAYOUT_DETAILS
LIFE_RISK
PRODUCT_FEATURES
PROFIT_CENTER
SURVEY_ANSWER

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 27

Usage Guide for DDS

Wave 4
COL_INDEX
COST_CENTER_ASSOC
COVERAGE_OPTIONS_BENEFITS
CRIMINAL_CONVICTION_DETAILS
CUSTOMER_COMMUNICATION
FAMILY_ILLNESS_DETAILS
FOREIGN_TRAVEL_DETAILS
INCOME_OPTIONS
LIFE_STYLE_DETAILS
MEDICAL_CONDITION_DETAILS
MEDICAL_EXAM_DETAILS
MEDICAL_PREVENTION_DETAILS
MILITARY_EXP_DETAILS
PRESCIPTION_DRUG_DETAILS
PROFIT_CENTER_ASSOC
SUBS_USAGE_DETAILS
UW_CLASS_DETAILS
VIOLATION_DETAILS

Wave 5
AIR_SPORT_DETAILS
AVIATION_DETAILS
CARDIAC_MURMUR_DETAILS
CLIMBING_DETAILS
COMPETITION_DETAILS
DIVE_PURPOSE_DETAILS
MEDICAL_TREATMENT_DETAILS
RACING_DETAILS
RESPONSE
UNDERWATER_DIVING_DETAILS

Wave 6
ANNUITY_POLICY_DETAILS
INVESTMENT_DETAILS
LIFE_INSURANCE_POLICY
LIFE_POLICY_DETAILS

28 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

 Part III. Load Sequence of IIS DDS
Load Sequence for DDS

Wave 7
INSURANCE_POLICY_RESTRICTIONS
LIFE_UNIT_OF_EXPOSURE
LOAN

Wave 8
CLAIM_UNIT
COMPLAINT
LIFE_INSURANCE_CLAIM
PAYEE
PAYOUT
PRODUCER_X_UOE
REINSURANCE_DETAILS
SUB_ACCOUNT
SUB_ACCOUNT_AMOUNTS
SUPER_ANNUATION_DETAILS

Wave 9
CLAIM_TRANS
CLAIM_TRANS_LINE_ITEM
CLAIM_UNIT_X_ADMINISTRATOR
CLAIM_UNIT_X_SERVICE_PROVIDER
LIFE_INSURANCE_TRANS
PRODUCER_TRANS
PRODUCER_TRANS_LINE_ITEM

Wave 10
GL_JRNL
GL_JRNL_DETAILS

SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc. 29

Usage Guide for DDS

30 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.

Part IV. Customizable
Parameters
Usage Guide for DDS

1. Customizable Parameter Details

The following table lists some of the important global customizable parameters and their current values.

Table 11 Customizable Parameters

Parameter Name Comment Current Value(s)
GLOBAL_HIGH_DTTM_VALUE It is the high date derived from 31DEC4747:23:59:59
GLOBAL_HIGH_DTTM but stored in
datetime format.
LOAD_DTTM It is the high date derived from
LOADING_DTTM but stored in
datetime format.
LOAD_DATE It is the high date derived from
LOADING_DATE but stored in date
format.

32 SAS® Insurance IS 3.2 Release B 1.0 © 2006 SAS Institute Inc.