Collect Data from Oracle Health Insurance Applications

Oracle Insurance Gateway can be used to gather data from Oracle Health Insurance applications and transform it to send it to another (external/Oracle Health Insurance) application. This essential means - gather data file/raw payload from Oracle Health Insurance, transform the data and create file/raw payload, and send it to another application.

Oracle Health Insurance applications expose various means by which data can be collected from it, for example:

1) Generic API e.g. GET on a resource

2) Extract Integration Point

3) Specific IPs e.g. Claims Transaction Out, Enrollment Status Response Integration Point.

Oracle Insurance Gateway can be configured to perform a wide variety of integration scenarios. To clarify the possibilities around configuration, consider the following use cases

  • Query a claim for a given claim code - This use case can be realized by having an QUERY step. This would typically be a sub step within an integration when a claim must be fetched.

  • Check whether a specified service is a capitated service or not for a given provider and as of date - In this example provider code, service code, as of date are supplied as request parameters. Generic API can be used to GET /organizationproviders details. The system reads the dynamic record 'Capitated Services' on the provider to check if the given service is capitated or not. If the service is active for the supplied as of date, then the exchange must return the status as 'Capitated', otherwise 'Not Capitated'. This use case can be realized by having a CUSTOM step. The setup involved in realizing this use case is covered in detail in the next chapter 'Synchronous Integration'.

  • Periodic member extract SFTP to a downstream system - This use case can be realized by having an EXTRACT step, followed by a DELIVERY step. In this example, an incremental extract is configured to get member data including:

  • Read consumptions - In this example, the long-running process 'Read Consumptions' is invoked for specific limit code(s) and a cutoff date-time. This use case can be realized by having a PROCESS step, followed by a DELIVERY step

In this chapter 1) querying a specific claim, 2) periodic member data extract and 3) read consumption, use cases are described

The Oracle Insurance Gateway configuration for all the examples is shown using API/IPs. The same is also possible using the user interface.
The examples below assume that the reader is familiar with Oracle Health Insurance applications integration capabilities (especially HTTP API/IP concepts). For details refer to chapters on HTTP API/IP concepts in the Developer Guide.

Query Claims Data

For this use case a rest destination 'claims must be configured.

The rest destination "policies" is configured as :

Fields Configuration Remarks

code

claims

credentialKey

claims_user

The following must be done to set up credential key "claims_user"

  1. Create credential using credential IP or Credential Page

    Example: To set up credential key "claims_user" using Credential IP the following must be done

    PUT  http(s)://{host:port}/{oig application context}/credentials/credential/_claims_user_

    with payload

    {
  "username" : "user that OIG should use to access {claimsComponent} ",
  "password": "password to access claims application"
}

  2. Set the authentication mechanism using generic api - properties or using property configuration page

Example: To set up authentication using Generic API - /properties (assuming the polices application uses basic authentication) the following must be done

POST : http(s)://{host:port}/{oig application context}/generic/properties

with payload

{
    "name": "ohi.service.**policy_user**.client.authentication",
    "value": "BasicAuthentication"
}
For details on generic api refer to Developer Guide, section HTTP API concepts.

addressKey

address.key.claims.baseurl

The address key can be setup using Generic API /properties or properties page

Example : To set up address key using Generic Api /properties the following must be done

POST: http(s)://{host:port}/{oig application context}/generic/properties

with payload

{

  "name": "address.key.claims.baseurl",
  "value": "URL till {claimsComponent} context root
   e.g. http://{host:port}/{context-root}"
}

destinationType

REST

typeConfig

path: {path}

httpMethod: {httpMethod}

Here, the path and http method are parameterized (recommended). This way a single rest destination can be used by multiple integrations with Policies application.

NOTE: For the given use case, the system ignores the path and http method configuration. System will create destination url using the address key and the query api resource. Method used is GET.

Let’s assume that for this use case is for Claims data must be sent to a downstream system over a REST endpoint. The REST destination to communicate with the external application "externalApp" must also be configured.

The next step is to create an Integration using the building blocks mentioned above . This is done by sending the following request using POST Method to Generic API resource /integrations.

{
  "code": "QueryClaimsData",
  "integrationSteps": [
    {
      "code": "QueryClaims",
      "sequence": 1,
      "subtype" : "Query",
      "outputName" : "claimsResponse",
      "typeConfig": {
        "resourceName" : "claims",
        "q" : " code.eq(\'{claimCode\}')",
        "expand" : "addressList|maritalStatusList"
      }
    },
    {
      "code": "claimsDelivery",
      "sequence": "2",
      "subtype" : "DELIVERY",
      "functionTransformation": {
        "code" : "transformClaim"
      },
      "destination" : {
          "code" : "externalApp"
      }
    }
  ]
}

This integration when triggered would query claims data by sending in the following GET request to Claims

http(s)://{host:port}/{context root}/generic/claims?q=code.eq ({this will be the claimsCode value supplied during intergation invocation)

Accept header for this GET request gets set to application/json;expand=addressList|maritalStatusList

The response received from the Claims is available as the "raw payload" to the delivery step. If transformation logic is not configured then this reasons in its as-is form is delivered to the configured delivery destination.

In this example, dynamic logic transformClaim is configured to read the Claims response and convert it into the format expected by the external system. The response from Claims application is accessible in the dynamic logic transformClaim through bind variable claimsResponse. For more details on transformation possibilities and How tos refer to chapter Transformation Dynamic Logic in the guide.

This integration can be invoked using Exchange Integration Point - with parameters options (see image), with claimCode being the request parameter.

Query Claims Data

Member Data Extract

The first step is to identify and set up destinations. Here, the system needs to reach out to extract integration point in Policies application. Therefore, for this use case a REST destination must be set up.

The rest destination "policies" is configured as explained in the Enrollment product upload example in the chapter 'File Upload'

The extracted data is required to be SFTP to a downstream system. For this SFTP destination "memberDataSFTP" is configured. The request specifics to configure a SFTP destination can be accessed by doing a GET to:

http(s)://{host:port}/{context-root}/generic/sftpdestination/create-form

For more details on attributes refer to chapter Destinations in the guide.

The next step is to create an Integration using the building blocks mentioned above. This is done by sending the following request using POST Method to Generic API resource /integrations.

{
  "code": "MemberExtract",
  "integrationSteps": [
    {
      "code": "ExtractStep",
      "sequence": 1,
      "subtype" : "EXTRACT",
      "outputName" : "memberExtract",
      "indicatorExpectNotification":"true",
      "typeConfig": {
        "resourceName" : "persons",
        "fields" : "prefix.code|language.code|addressList.country.code|addressList.countryRegion.code",
        "expand" : "addressList|maritalStatusList"
      }
    },
    {
      "code": "ExtractDelivery",
      "sequence": "2",
      "subtype" : "DELIVERY",
      "functionTransformation": {
        "code" : "memberExtractTransformation"
      },
      "destination" : {
          "code" : "memberDataSFTP"
      }
    }
  ]
}

The indicator expects notification is set to true for the EXTRACT steps. The effect of setting this indicator is that the exchange will get into waiting mode after triggering the extract and would wait for a notification response from Policies application.

This requires the 'extract notification endpoint' in the Policies application to be set to Oracle Insurance Gateway notification endpoint'.

To do this the system property `ohi.extract.gateway.notification.endpoint must be set to:

http(s)://{host:port}/{oig application context}/notification

In addition to the endpoint setting, in the Policies application, the credential and authentication property must be set for the key gateway. This is similar to the setting of credential and authentication for the key policies_user as explained in the Enrollment Product Upload example

Oracle Insurance Gateway reads the extract notification and downloads the data file. This data file is then accessible under bind variable "memberExtract" in subsequent dynamic logic functions.

The subsequent step "ExtractDelivery" of type DELIVERY - involves transforming the member extract using dynamic logic.

  • Invoke the functionTransformation

  • SFTP the transformed file based on the "memberDataSFTP" destination settings .

Dynamic logic function Transform Dynamic Logic "memberExtractTransformation" is implemented to convert the extracted data (which is in the Oracle Health Insurance-specific format) to a format as expected by the downstream application. For more details on transformation possibilities and How tos refer to chapter Transformation Dynamic Logic in the guide.

The "memberExtractTransformation" dynamic logic is invoked with the following bind variables:

Variable Name Value

memberExtract

The data file set that is created as part of the extract

fileReader

Using transformation dynamic logic, reader can be asked on the data file that is part of the dataFileSet.

memberExtractOutput

Handle to the stream of the transformed file as an output. Type OutputStream

exchangeStep

Object that represents the exchange step for the transformation.

properties

Exchange properties

Extract Invocation

This integration can be invoked using Exchange Integration Point - With Parameters.

Note that all extracts are by default incremental in nature. The integration invocation can control whether it is full or incremental, this is done by using the invocation parameter "extractIncremental" which takes a boolean value. Setting this parameter to 'false' result in a full extract.

First Time

The following clause is added to the extract payload: lastUpdateDate.lt(<high_water_mark>). Here the value the high_water_mark is the creation_date of the integration invocation.

Second Time

The following clause is added to the extract payload: lastUpdateDate.lt(<high_water_mark>).and.lastUpdatedDate.gte(<low_water_mark>). Here the value the high_water_mark is the creation_date of the integration invocation. The value of low_water_mark is the creation date of the previous invocation of the same integration. Therefore, making the extract incremental.

Read Consumption

Read Consumption is a long-running process that can be triggered by sending in the following request to http://[hostName]:[portNumber]/[api-context-root]/readconsumptionbatches

{
   "limitCodes" : [ "code1", "code2", ",..." ],
   "transactionStartDateTime" : {
      "value" : "..."
   },
   "transactionEndDateTime" : {
      "value" : "..."
   }
}

Integration step of type PROCESS supports invocation of the long-running processes.

If the data returned by the read consumption batch needs to be uploaded to some external application using a REST based endpoint, then the following destinations are required to be configured:

1) REST destination to communicate with claims application

2) REST destination to communicate with external application

The rest destination "claims_readconsumption" is configured as :

Fields Configuration Remarks

code

claims_readconsumption

credentialKey

claims_user

Refer to policy_user configuration in the File Upload example for more details.

addressKey

address.key.claims.baseurl

To set up address key using generic api - /properties the following must be done

POST  http(s)://{host:port}/{oig application context}/generic/properties with payload
{
  "name": "address.key.claims.baseurl",
  "value": "URL till {claimsComponent} context root
  e.g. http://{host:port}/{context-root}"
}

destinationType

REST

typeConfig

path: /readconsumptionbatches

httpMethod: POST

The rest destination "external_readconsumption" is configured as :

Fields Configuration Remarks

code

external_readconsumption

credentialKey

external_user

Credentials needed to connect to the external application

addressKey

address.key.external.app.baseurl

To set up address key using generic api - /properties the following must be done

POST  http(s)://{host:port}/{oig application context}/generic/properties

with payload

{
  "name": "address.key.external.app.baseurl",
  "value": "Base URL till context root of the external application
  e.g. http(s)://{host:port}/{context-root}"
}

destinationType

REST

typeConfig

path: /uploadreadconsumption

httpMethod: POST

Assuming that the consumption data can be uploaded to the external application by doing a POST multi-part request to the following URL

http(s)://{host:port external application}/{context-root-external}/uploadreadconsumption

The next step is to create an Integration using the building blocks mentioned above. This is done by sending the following request using POST Method to Generic API resource /integrations.

{
  "code": "ReadConsumption",
  "integrationSteps": [
    {
      "code": "readConsumption",
      "sequence": 1,
      "subtype":"PROCESS",
      "outputName":"consumption",
      "indicatorExpectNotification":"true",
      "destination": {
        "code": "claims_readconsumption"
      },
      "typeConfig": {
       "payloadContentType":"application/json"
     }
    },
    {
      "code": "readConsumptionDelivery",
      "sequence": "2",
      "subtype" : "DELIVERY",
      "functionTransformation": {
        "code" : "readConsumptionTransformation"
      },
      "destination" : {
          "code" : "external_readconsumption"
      }
    }
  ]
}

Here the indicator expects notification is set to true for the PROCESS steps. The effect of setting this indicator is that the exchange will get into waiting mode after triggering the read consumption batch and is waiting for a notification response from Claims application.

This requires the 'read consumption batch notification endpoint' in the Claims application to be set to Oracle Insurance Gateway notification endpoint.

To do this the system property ohi.ReadConsumptionBatch.endpoint.request must be set to:

http(s)://{host:port}/{oig application context}notification

In addition to the endpoint setting, in the Claims application, the credential and authentication property must be set for the key ReadConsumptionBatch. This is similar to the setting of credential and authentication for the key policies_user as explained in the Enrollment Product Upload example

Oracle Insurance Gateway reads the notification and downloads the data file containing the consumption data. This data file is then accessible under bind variable "consumption" in subsequent dynamic logic functions.

The subsequent step "readConsumptionDelivery" of type DELIVERY - involves transforming the consumption data using dynamic logic.

  • Invoke the function readConsumptionTransformation

  • Delivers the transformed file to "external_readconsumption" destination .

Dynamic logic function Transform Dynamic Logic "readConsumptionTransformation" is implemented to convert the consumption data (which is in the Oracle Health Insurance-specific format) to the format as expected by the external application. For more details on transformation possibilities refer to Transformation Dynamic Logic in the guide.

The "readConsumptionTransformation" dynamic logic is invoked with the following bind variables:

Variable Name Value

consumption

The data file set that is created as part of the extract

fileReader

Using transformation dynamic logic, reader can be asked on the data file that is part of the dataFileSet.

consumptionOutput

Handle to the stream of the transformed file as an output. Type OutputStream

exchangeStep

Object that represents the exchange step for the transformation.

properties

Exchange properties

This integration can be invoked using Exchange Integration Point - With Payload.

In this example the exchange invocation payload is the same as the payload required by the long-running operation. Alternatively, the dynamic logic function 'Invoke Function Payload' can also be implemented to generate payload.

{
   "limitCodes" : [ "code1", "code2", "..."],
   "transactionStartDateTime" : {
      "value" : "..."
   },
   "transactionEndDateTime" : {
      "value" : "..."
   }
}

..