Insurable Object Integration Point
This chapter describes the Insurable Object Integration Point messages and how they are used by external interfaces to initially load insurable object data copies into the Oracle Health Insurance application and to keep the copies up-to-date.
Design Principles
The Oracle Health Insurance application requires details of insurable objects that may be maintained (primaried) outside the Oracle Health Insurance application. Where this is the case, the Oracle Health Insurance application needs to store an up-to-date copy of these insurable objects. This copy in the Oracle Health Insurance application is maintained by external (not part of the OHI application) interfaces using Insurable Object Integration Point messages. The external interfaces will initially load details of all required Insurable Objects from the "primary" systems into the Oracle Health Insurance application through Insurable Object Integration Point message calls. Thereafter, they could monitor the "primary" system(s) for updates and new Insurable Objects and make message calls to provide the Oracle Health Insurance application with updated details and to add new Insurable Objects.
External interfaces determine when request messages are sent and what they contain. Each request message will contain the configured insurable object details. Insurable Entity types are configured in the application.
Insurable Object Matching
In order for the Oracle Health Insurance application to be able to recognize when an update to an insurable object"s details is being sent (as opposed to the details of a new insurable object) and to know which insurable object in the Oracle Health Insurance application is to be updated, the insurable object code is used. The type of the insurable object type is recognised by the request element name. The request element name is the usageName configured in the respective Insurable Entity Type.
When the details of an insurable object are received in a message, the Oracle Health Insurance application will consider the details to be a new insurable object if there is not already an insurable object stored with the given code and insurable object type derived from the request element name. The system will consider the details to be an update to an existing insurable object if there is one with the same code for the given type.
Request Message
Each request message may contain the details of one insurable object. The external interfaces will create request messages for the initial data load and in response to entry and update of insurable objects.
A given implementation of the Oracle Health Insurance application could have dynamic fields and dynamic records added to the insurable object that need to be interfaced. For details on how external interfaces can provide values for dynamic fields and dynamic records in request messages and how they are handled by the Oracle Health Insurance application, refer to the concepts in the Developer Guide.
Let"s say InsurableEntityType - Object is configured as below:
| Code | Plural Display Name | Singular Display | Usage Name | Resource Name |
|---|---|---|---|---|
CAR |
Cars |
Car |
car |
cars |
HOME |
Homes |
Home |
home |
homes |
To send in Cars, the request message sent to uri: http://<context-root>/api/cars will look like:
<car code="" description="" objectDate="" >
To send in Homes uri: http://<context-root/api/homes, the request message will look like:
<home code="" description="" objectDate="" >
Response Message
Response messages are created by the Oracle Health Insurance application in response to request messages received from external interfaces. Please refer to the "Response Messages" section in the HTTP API Integration Points part of the Common Features book for more details.
Batches
Batch requests enable the handling of multiple requests in one go. Because the volume of data can become quite extensive, these are file based requests. The root element for the batch request message is the insurable entity type resource name. The root element for the batch response message is the root name for batch request message suffixed with "Response".
Please refer to the "File Based Import" section in the HTTP API Integration Points part of the Common Features book for more details.
Taking the same example from the above, the example Batch Request Message will look like:
Cars batch request messages have the following structure:
<cars> -- resource name takes the root <car/> -- refer to Insurable Object Request for car in the above example </cars>
Cars batch response messages have the following structure:
<carsResponse> <resultMessages/> </carsResponse>
Homes batch request messages have the following structure:
<homes> <home/> -- refer to Insurable Object Request for home in the above example </homes>
Homes batch response messages have the following structure:
<homesResponse> <resultMessages/> </homesResponse>
The elementId attribute that is included as part of the result messages element (refer to the "Activity Integration Point" section in the HTTP API Integration Points part of the Common Features book for more details) contains the insurable object code for example elementId="1234567890" of the insurable object for which the messages are raised.