Technical Design Documentation–Native Solution Onboarding

NATIONWIDE PET INSURANCE

Native Solution Onboarding

Prepared By: Prab

Date: 06/19/2017
Version: 1.0

Notice of Confidentiality and Custodial Responsibilities

This Nationwide document contains confidential information that is Nationwide's intellectual property. As a holder of
this document, you may NOT disclose its content or any information derived from it to any person or entity outside of
Nationwide.

Page 1 of 12 4/14/2018
Technical Design Documentation–Native Solution Onboarding

Page 2 of 12 4/14/2018
Technical Design Documentation–Native Solution Onboarding

Revision History

# Date Version Description Author

1 06/19/2017 1.0 Initial Version Prab
2
3
4
5

Page 3 of 12 4/14/2018
Technical Design Documentation–Native Solution Onboarding

Table of Contents

1. Introduction ....................................................................................................................... 5
2. Overall Processes ............................................................................................................. 5
3. Activity/System Diagrams ................................................................................................ 8
4. Example Screen Mock Ups............................................................................................... 9
5. API Procedures ................................................................................................................10
6. Decisions and Considerations ........................................................................................10
7. Exception Management ...................................................................................................11
8. Security Requirements ....................................................................................................11
9. Performance Requirements ............................................................................................11
10. Deployment Requirements ..........................................................................................11
11. Support Requirements .................................................................................................11
12. Appendix .......................................................................................................................11

Page 4 of 12 4/14/2018
Technical Design Documentation–Native Solution Onboarding

1. Introduction

The objective of the Native Exchange project is to allow Broker to sell the
Nationwide My Pet Protection product suite on their platform. Nationwide will receive
all enrollment data from a file provided by file exchange. This file will be sent by
Technology Provider at the end of any open enrollment period for a specific
employer, or if any perpetual applications are collected.

2. Overall Processes

File Exchange between Entities

Native Exchange
Adjustment File

Platform File
TPA
Demographic/
Eligibility File Batch

Transaction File (Billing) Enrollment File

REN
Remittance/Ineligibility File

Enrollment File

The platform will provide all enrollment application activites to the end user, the
employee. It will then organize all the individual applications, and all necessary data
attributes, into a file and send that file to Nationwide. It will send one file per
employer at the end of each Employer’s Open Enrollment period. This file is called
the Enrollment file.

Nationwide will develop a batch application that will accept the file produced by
Technology Provider, parse this file, and finally convert the parsed data into a
request that can be sent to the REN Exchange Application API for policy application
processing. If there are records that have missing data in the Enrollment Files then
the Nationwide Batch application will send an Adjustment file back to Technology
Provider in the same file format as the Enrollment File.

The Enrollment file will be received by Nationwide via Secure FTP (SFTP). Upon
receiving this file, Nationwide will utilize the existing BatchServices framework to
execute the necessary workflow to submit the enrollment data to REN for policy
creation. The Enrollment file will be formatted into a scheme that has been agreed
upon by both Technology Provider and Nationwide.

Page 5 of 12 4/14/2018
Technical Design Documentation–Native Solution Onboarding

The BatchServices workflow will first parse the received file and organize the data
into a local model. After completion of parsing, each complete application will then
be submitted to REN via an existing API. The resulting success of each submission
will be recorded; in the case of an error, both logging and notifications will be used
as tactics to help with any and all error handling and recovery actions.

Platform File

All the enrollments that come to Nationwide through the phone or for any changes
made over the phone to the policy premiums of that came through the technology
Provider platform will need to be reported to Broker. This is called the Platform File.
The Nationwide Batch Application will parse the Platformfile that REN generates on
a daily basis and convert it into the format.

Technology Provider will send an adjustment file back to Nationwide for those
records in the Platform file that have missing data.

Transaction File

The existing process of REN generating the Transaction file for billing will remain
unchanged. The only change will be that Transaction files can be sent to multiple
TPAs.

Remittance/Ineligibility File

The existing process of receiving the Remittance/Ineligibility File from the TPAs will
remain unchanged. The only change will be that Nationwide Pet will receive
Remittance/Ineligibility files from multiple TPAs.

Policy Holder Portal

The policy holder portal currently displays the pets breed and age as part of policy
information. Pet breed value of 'Unknown' and pet age of over 66 years will be
masked and made NOT visible to the policy holders.

Salesforce

The logic for the nightly batch that transfers policy information from REN to
Salesforce will accommodate and handle default values. For example: Currently, the
available options for Gender is Male or Female. The logic should be able to handle
“Unknown” since that is a default value for MPP products.

Salesforce Quoting Tool and the Intranet Sales Quoting Tool objects will be updated
to present default values from REN.

Page 6 of 12 4/14/2018
Technical Design Documentation–Native Solution Onboarding

MPP Foundational Work

For the MPP Foundational work, the following will be implemented:

 Extending the age of all existing Breeds from 35 to 101 in the Product
Recommendation table.
 Adding another Breed type called “Unknown” to the Breed Master table for
ages 1 through 101 to support the MPP products.
 REN will be able to accept and process applications which have default
values for some of the required REN parameters.
 REN will also develop a script to populate the Base Premium table with
“Unknown” breed for the MPP active products.
 The default value of “Unknown” for the Breed type will be filtered out by the
ESB so that the value “Unknown” does not show up on the Breed dropdown
for Desktop QEC, Mobile QEC, BenefitFocus and ABC.
 For MPP products, REN will modify the Age to say “U” which will then be
translated by Fulfillment to say “Unknown” for Age on all the policy holder
communications.

Pre-load existing policy holder informationon on the Platform

Nationwide Pet will be sending a one time file to technology provider to preload. The
file will contain existing policy holder information of employees who belong to the
platform.

Page 7 of 12 4/14/2018
Technical Design Documentation–Native Solution Onboarding

3. Activity/System Diagrams
File Exchange – Describes the interactions between Nationwide and Easy Enroll.

Nationwide FTP Server Batch Services REN DB

Technology Provider Platform

Recieve Enrollment File

Employee Enrollment

Place File in Appropriate Folder

Send Enrollment File

Process Enrollment File

File IO (Open) Get Employer/Organization Details Organization API

Process Response

Call REN Application API

Application API

Process API Response

Logging

Process Logging Response

Batch Services – Describes the entirety of the batch lifecycle.

Page 8 of 12 4/14/2018
Technical Design Documentation–Native Solution Onboarding

Windows OS Batch Services Application DataBase

Win Scheduled Task DispatchService Controller Job JobRule StoredProcedure DataTables

Launch(DispatchID)

GetDispatchRequest[DispatchID]] GetDispatch(ID) FetchDispatch(ID)

Dispatch DispatchDetails[ProducerSystemID, ControllerID] ResultDataSet

TaskServiceShutDown
IF (Dispatch Is Not Valid)

ELSE GetControllerRequest[Dispatch.ControllerID] GetController(ID) FetchController(ID)

Controller ControllerDetails[List<Job>,List<JobRule>] ResultDataSet

Execute(ProducerSystemID) ProcessRules(Key)

Rule[Value]

Multi-Threaded
ForEach.
ApplyRules

KeepAlive HeartBeat
FOREACH (LOAD)
IsDispatchValid Perform(Load) ProcessRules

Definition

ApplyRules

Valid[Yes/No] Request CRUD Operation

Response[Result] Result

TaskServiceShutDown ShutDown

4. Example Screen Mock Ups

No screens will be used in this solution.

Page 9 of 12 4/14/2018
Technical Design Documentation–Native Solution Onboarding

5. API Procedures

No new API’s will be created for this project.

The existing API’s to be called:

a) Retrieve Platform Details from GetFullOrganization method of ESB REN web

service - RENVPI.WEB_QUOTE.GET_FULL_ORG_DETAILS

b) Submit application to REN for Policy processing -

RENVPI.WEB_ENROLLMENT.APPLICATION_DATA_QEC

c) For the Default values following REN API's will be modified:-

 app_search
 cancel_search
 copy_search
 customer_care
 edr_search
 issue_search
 original_app_search
 policyinfoorg_search1
 reinstate_search1
 switch_search

d) For the Fullfillment values following REN API's will be modified:-

 ren_bexlib_gen
 eob_pkg
e) For the Platform file changes following REN API's will be modified:-
 gen_platform

6. Decisions and Considerations

1. The Technology Provider has to provide a single file format that will be used to
generate the Enrollment file, as such, Nationwide will need to parse this file and
redistribute the data into the existing data model.
2. Reporting on their Platform applications will be slightly different because there is no
way for Nationwide to understand how many people and/or quotes were generated
to yield the final applications. As such, it is impossible to generate a Quote-To-
Application conversion report. Business (Group) is aware of the situation, and has
already initiated investigative meetings with IT, REN and BI. Final solution is TBD.
3. Internal notifications to business partners may be necessary in case of a critical error
occurring in the file exchange process between EasyEnroll and Nationwide. As of

Page 10 of 12 4/14/2018
Technical Design Documentation–Native Solution Onboarding

now, only IT representatives will be notified of the error. As such, it has been
discussed with the business partners (Group) if they would like to create a
‘notification workflow’ that would allow them to directly respond to an error situation.
The decision to include this workflow is TBD.

7. Exception Management

1. All exceptions will be logged to the ESB database as is the current process
2. Fatal errors to be logged into windows log event. Name(s) of events to be discussed
with IT OPPS.

8. Security Requirements

1. All file exchange activities will use secure methods for transportation of files (ie.
SFTP and SSL).
2. All Inbound and Outbound files will be .pgp encrypted.

9. Performance Requirements

1. Response times on all service calls should be less then 1 minute.

2. The existing performance of QEC will be maintained across all pages
3. Business has projected that there will be 1000 new policies coming into Nationwide
system for easyEnroll groups in 2016, 2017 and 2018. This will meet our SLA, our
current SLA is to submit 20,000 applications to REN in 2-3hrs.

10. Deployment Requirements

1. This project will follow the standard Production deployment process. No changes are
being made to the deployment environment or the deployment components.

11. Support Requirements

1. The BatchServices does not require continuous maintenance or support; effort is

only needed upon change of requirements or logic.

12. Appendix

Page 11 of 12 4/14/2018
Technical Design Documentation–Native Solution Onboarding

Page 12 of 12 4/14/2018