Application Overview

The Oracle Health Insurance Integration Gateway is a component that integrates Oracle Health Insurance (OHI) components with other systems within a customer’s application landscape. This could be an enterprise integration platform or another system in the customer landscape expecting a specific message or format. It is designed to support integrations to/from OHI components only and to act as a bridge between external application or middleware layer (per integration), and OHI Components. It is not designed to be a replacement of an enterprise integration tool or a business process implementation tool.

The Integration Gateway supports a wide variety of integration scenarios, including but not limited to feeding claims in OHI from external systems, feeding member/provider data or fetching member extract from OHI applications for downstream systems to consume.

The OHI Integration Gateway offers a lightweight approach to integrations with OHI and comes with prebuilt adapters for various integrations. It supports multiple integrations flows that can be scheduled or invoked separately. Each integration can consist of one or more of the following steps:

  • collect data from source endpoint / file location (through Agent).

  • invoke OHI long running processes.

  • transform the databefore intake to OHI or before export from OHI.

  • delivery of data to a target endpoint/location.

  • executing subflows to trigger parallel/sequential flows to do a series of steps with OHI applications.

OHI Agent for Cloud Deployments

The OHI Agent is a component that is deployed in a customer’s on-premise environment. In a cloud deployment, it serves as the entry point to the OHI Integration Gateway. The OHI Agent supports specific protocols (e.g. file system access) with customer systems, while securely communicating with the cloud environment over HTTPS and WSS only.

Gateway overview

Integrations

An integration is a set of steps that define the flow to accomplish an integration task. Key features of an Integration are:

Version

The integrations are inherently versioned, hence it is possible to support multiple versions of the same integration type and code at the same time. It is very beneficial for protocol changes or data format changes to support both versions and gradually move to a newer version.

Scheduled/Event Based

The integrations can be scheduled or triggered explicitly in different ways, including parameters, payloads, files, etc. The invocations are asynchronousin nature, however integrationinvocation also supports synchronous invocations if needed.

Parameter Driven

Integrations support parameterisation and hence can execute depending on the parameters supplied during the invocation. The parameters can be supplied on the invocation request or can be stored with default values if the integration is invoked with a schedule.

Error Handling and Automatic Recovery

Integrations come with inbuilt error handling at all parts of the flow. It is also possible to raise workflow messages in case of errors. The recovery in case of errors is supported to start from the steps that failed

Timeouts

It is possible to configure timeouts for an integration to finish the execution. These timeouts are possible on the global as well as on the step level.

Auditing and Monitoring

Integration invocations support extensive logging and monitoring capabilities for each step and the overall process. The process can be monitored through the monitor resource or can be notified through the configuration of such an event.

Integration Steps

An integration is set up through a number of configurable steps.

Conditional

Each step supports conditional invocation based on a preconfigured condition and can be skipped if the condition in the invocation phase does not evaluate to true.

Post Processing

Each integration step supports its post processing that can be used to set up parameters, data, logs from the data gathered in the step.

Types

Data Collection Stepssupport collecting data from external systems. The data can be collected in batch or non batch formats:

  • Extract: collect data as an extract from the source systems

  • Query: perform queries using Query API from our source systems.

  • Custom: execute custom logic to collect data from source systems. This is relevant when the source system is not an OHI component.

Invoke Process Stepstrigger a process, such as starting an activity in an OHI component.

  • Invoke Activity: Invokes an activity and waits for a notification to continue with the next step

  • Invoke other processes: Invokes other processes that are not activity based.

Delivery Stepshandle the data that is collected in the Data Collection step.

  • Transform: an optional transformation of the data collected in a previous step to the desired output format. There are various inbuilt readers and writers to assist in transformation of data.

  • Deliver: several delivery options are available, including REST, SFTP, FileUpload or in built for Fusion, Documaker. Delivery also supports compression and encoding of data.

SubFlows execute a series of steps with its own parameter list in parallel or in sequence. The subflows are controlled by the main flow.

Event Store

OHI Integration Gateway provides the ability to store opaque events from external applications. These events can be consumed from within an integration invocation to carry various steps. It offers capabilities to read handled/unhandled events based on the event type. This is designed for handling a low volume of events.

In-Built Adapters

OHI Integration Gateway comes with various inbuilt adapters to ease the integration with OHI Applications with other customer applications in the landscape.

  • Documaker: Documaker is a framework that assists in generating documents in a pre configured format. OHI Integration Gateway comes with prebuilt destination type Documaker to send documents directly. See Sample Configurations for more details.

  • Fusion Financials: OHI Integration Gateway comes with prebuilt destination Fusion Financials to integrate with financial downstream systems by fusion financials. See Sample Configurations for more details.

  • ORMB: Another inbuilt feature is to connect with ORMB as a financial downstream system. See Sample Configurations for more details.

  • OHI Long Running Processes: OHI applications expose a number of long running operations to take care of batches like imports or exports. OHI Integration Gateway has inbuilt capability using OHI Activity and OHI Process steps for automatic recovery handling and message downloads.

Key Features

  • HTTP Based Integration

  • Extensibility and Dynamic Logic

  • Configuration Migration

  • JET Based UI

  • Out of the box Groovy Capabilities