Chapter - 1 : Introduction
Purpose
This document describes the integration options for the Oracle Insurance Data Gateway application. It is intended for developers and connectivity analysts intending to design and build client feeds into the system.
Description
OIDG allows client (sender) and host (receiver) companies to participate in various insurance transaction types while simplifying the technical integration needs on both sides. Client companies will have a standard set of integration APIs and procedures to develop against while the host company is shielded from client specific requirements. OIDG provides the platform to support the varied integration needs including security, transport type, transaction type, job frequency, etc., of each client using the system.
Here is an example set of insurance processes OIDG supports.
- A client company creates a new policy record and sends it to OIDG to be forwarded on to a receiving company.
- OIDG validates the incoming request against format and business rules, interrogates the payload to get the sender ID, receiver ID, transaction type and other info.
- OIDG validates that the sender has an integration contract configured to be allowed to interact with the receiver for the requested transaction type.
- OIDG routes the policy to the appropriate receiver systems based on transaction type and policy status.
- As changes occur to the policy by the client, including change in policy status, change in coverage, change in client details, etc., they will be sent by the client through OIDG to the receiving company as a policy update. OIDG will validate and route the request to appropriate receiving company systems as described above.
- As periodic premium payments are processed by the client company, an updated policy record with the premium payment info included will be sent through OIDG to the receiving company. OIDG will validate and route the request to appropriate receiving company systems as described above.
- Commission statements generated by the client company are sent through OIDG to the receiving company and will be used to reconcile commission payments. OIDG will validate and route the request to appropriate receiving company systems as described above.
- Finally a full policy extract will be conducted by the client company and sent through OIDG to the receiving company for policy reconciliation. OIDG will validate and route the request to appropriate receiving company systems as described above.
System Overview
The system has several major components including front-end user interfaces, middle-tier service integration and business processing components, and databases.
- QuickView – is a user interface for viewing transaction history and status and for manual retry submissions
- AdminView – is a user interface for configuring sender and receiver parties, the integration contracts between senders and receivers, and system settings
- Process Orchestration – provides transaction specific insurance workflows as well as business rule validation logic. It is implemented on top of SOA Suite.
- Data Services – provide utilities for encrypting sensitive data, managing file-based transactions, managing batch requests, database abstraction, and logging.
- Service Virtualization – exposes client-side web-services and integration to outbound business services. It validates incoming payload schema and provides mediation to appropriate outgoing payload schemas.
Sender companies can send requests to OIDG for real-time processing via web-services or in batch by FTP file submission. Both mechanisms trigger the same processes once a policy reaches inbound processing in OIDG’s Service Virtualization (SV) layer. Once here a policy is validated against ACORD schema and for valid sender/receiver IDs. PII data is immediately encrypted to avoid accidental viewing by administrators. SV then calls Process Orchestration to execute business validation rules to check for required inputs and co-dependent fields as required by OIDG over and beyond ACORD.
Once the policy passes all inbound validation, it is placed on the process queue. At this point, Process Orchestration (PO) pulls the policy off of the process queue, determines what transaction needs to be performed, as indicated by the payload, then routes the policy to the corresponding transaction workflow. This may result in several outbound requests being made by PO to outbound services hosted by SV. These include, Submit Policy, Submit Customer Data, Submit Payment, etc. When these outbound services are called they in turn make calls to external systems that SV has been configured to call.
If OIPA happens to be one of these external systems, then SV knows how to communicate with it out of the box. Other non-Oracle systems will require a custom extension to be built by integrators. The custom extension must adhere to the OIDG outbound web-service WSDL specifications but can implement whatever integration logic it needs to communicate with an external business service. As an example, the custom extension may need to convert the ACORD XML from OIDG to some custom format and may need to write it to disk, place it on a queue, insert it into a database, or send it to some other web-service.
Any errors encountered during schema validation, business rules validation, contract validation, outbound business service communication, or internal to the OIDG application, could result in a failure to process a transaction. These issues are reported as described in the Error Handling and Notifications section of this document.
Insurance Processes
The following insurance processes are supported by OIDG. The ACORD Messaging Library (AML) message type and proposed modes of operation are given for each.
Note: A Policy Synchronization Message contains the complete* policy and customer information
| Business Process | Message Details | Proposed Frequency and Mode |
|---|---|---|
| Proposal Notification and New Business(NB) Status Updates |
|
One policy per message via web-services, or multiple policies in batch via sFTP. |
| New Policy Notification |
|
Web service, one message per policy record |
| Policy Changes |
|
Web service, one message per policy record |
| Initial Historical Policy Migration |
|
One time scheduled batch process via sFTP |
| Policy Reconciliation |
|
Monthly scheduled batch process via sFTP |
| Note: A Premium Bordereaux Message contains policy references and premium payment data | ||
| Publish Premium Payments |
|
Web service, one message per policy record |
| Publish Commission Statements |
|
Monthly scheduled batch process via sFTP |
ACORD Messaging Library (AML) Standards
OIDG messaging is based on industry standards developed by the Association for Cooperative Operations Research and Development (ACORD). The ACORD Messaging Library standard will be referenced throughout this document as the AML standard. The following is a brief description from the ACORD Messaging Library standards documentation.
The ACORD Messaging Library (AML) Standard contains business messages that support business functions relevant to all lines of business, varied geographies, business-to-business (B2B), business-to-consumer (B2C), and internal systems. The message inventory is developed on a common set of design rules.
The business message functions vary as needed, either as unique or common. For example, one business message may be specific to one portion of the industry (i.e., obtain life insurance policy quote OR issue commercial auto policy) or have cross-industry relevance (i.e., change name). The resulting business messages provide for consistency regardless of process, product, or geography. Each message is designed at a level of granularity that is appropriate for the business function it supports to alleviate inconsistent interpretation. The technical architecture is vendor neutral and supports cross-industry standards such as HTTP, SOAP, and XML.
Details on the specific messages to be used by the client company to communicate information with the host company via OIDG are defined in this document. However, this is not meant to be a replacement of the ACORD published specifications which should be used as supplementary reference documents for additional details.
Additional Documentation
In addition to this specification, you may need to refer the following documents:
ACORD Messaging Library (AML) Standards
ACORD published the AML specification for Asia Pacific on September, 2016. This new standard is based on the Australia/New Zealand approved standards that are already published in addition to new additions added specifically for inclusion of Asia Pacific requirements. The new standard is available for download at www.acord.org.
ACORD XML Naming and Design Rules
The ACORD Naming and Design Rules Specification documents the common XML architectural functionality, naming conventions, design rules, schema implementation and data types that are used in ACORD XML specifications. This specification provides the information and rules necessary to define XML structures that will be reused across all the domains at ACORD.
ACORD Messaging Library Messages
Two AML messages are used as the standard formats for communicating the following required policy information updates between client and host companies.
| ACORD AML Process Message | Description |
|---|---|
| Policy Synchronization Message | A PolicySynchronization message contains policy and customer data and is utilized to communicate policy details between client company and host company. This includes information on the current status and contents of policies from the inception of a new business application at the client company, updates to policies currently being underwritten, and updates to active policies. |
| Premium Bordereaux Message | A PremiumBordeaux message contains policy data and payment data and is used to communicate premium payments and commission payments between client and host companies. |