Claim Callout Integration Point
This Integration Point executes a claim callout rule. A claim callout rule trigger during processing of a claim. The claim callout integration point sends, receives, and handles messages to and from an external system. For more information on Callout Rules, see Claim Callout Rules.
Design Choices
-
The request headers includes correlationId for asynchronous call outs. Oracle Health Insurance expects this information back in the response header when the asynchronous response is received.
-
To handle response messages for asynchronous callouts, this Integration Point features one listening endpoint. This endpoint can be consumed by external components to deliver the response messages to asynchronous callouts. This endpoint is protected by access grant 'claimscalloutasync IP'. The endpoint supports three paths:
-
/custom - to handle response messages of a custom format. These responses will be processed using the "Response Logic" specified in the callout definition.
-
/claimsupdate - to handle response messages that adhere to the Claims Update IP (HTTP). The callout rule response mechanism (implemented by the Claim Callout Integration Point) will process such responses as 'regular' Claims Update IP requests (also see "Additional Notes" below).
-
/claimsupdate/submit. The same as the one above. After updating the claim, the claim is submitted as well.
-
Illustrations
Synchronous Messaging
In synchronous messaging the same HTTP connection is used for sending the request (1) and receiving the response (2):
-
The request message (1) is created with the "Request Logic" specified in the callout definition and sent to the external component.
-
If the request message was created and delivered successfully, the request sent timestamp is logged in the claim callout history.
-
The response message (2) is received, stored and processed by executing the 'Response Logic' of the callout definition (if defined). The response received timestamp is logged in the claim callout history. This will be the same as the request sent timestamp, because the callout is synchronous.
Asynchronous Messaging
In asynchronous messaging separate HTTP connections are used for sending the request message and for receiving the response message:
-
The request message (1) is created with the "Request Logic" specified in the callout definition and sent tot the external component.
-
If the request message was created and delivered successfully, the request sent timestamp is logged in the claim callout history.
-
This request message gets a technical response (2) which indicates that the request is being processed by the external component. This response includes only a HTTP status code; any message content is disregarded as that should be included in the asynchronous response message via the separate HTTP connection.
-
The asynchronous response message (3) is received, stored and processed. The response received timestamp is logged in the claim callout history. Depending on the path to which the response is sent, one of the following happens:
-
The response with a custom format is processed by executing the "Response Logic" of the callout definition.
-
The response is passed to the Claims Update IP (HTTP) and processed like regular Claims Update IP requests (also see additional notes below).
-
The response is passed to the Claims Update IP (HTTP) and processed like regular Claims Update IP requests (also see additional notes below) and submitted as well.
-
-
The response (4) to the asynchronous response message (3) contains the response message described below.
Request Message
The request message that is sent to the external component (arrow 1 in both pictures above) may be of any JSON/XML-form as created in dynamic logic (the "Request Logic"). Additionally, the dynamic logic may specify a request header map. When specified, the values are set as request headers of the call out event.
Depicted below is an example request message to a DRG-grouper component using a synchronous callout. The creation of this message, including the encapsulating element <synchronousCalloutRequest>, would have to be coded in dynamic logic (the "Request Logic"):
<synchronousCalloutRequest> <claim> <claimCode>CLAIM12345</claimCode> <fields> <field name="grouperType" value="APR"/> <field name="grouperVersion" value="30"/> </fields> </claim> </synchronousCalloutRequest>
Synchronous Response Message
The synchronous response (arrow 2 in the synchronous scenario) is a custom XML/JSON-message.[1] The entire response message is fed to the "Response Logic" (if defined).
Example:
<synchronousCalloutResponse> <claim code="CLAIM123"> <attendingProvider>123456</attendingProvider> <locationProvider>345678</locationProvider> <operatingProvider>098765</operatingProvider> <referralProvider>567895</referralProvider> </claim> </synchronousCalloutResponse>
Asynchronous Response Message
The asynchronous response (arrow 3 above) should either be a Claims Update IP message with correlation information or be a custom XML/JSON-message [1]. In case of a custom response, the entire response message is fed to the "Response Logic".
Example (custom XML-message):
<asynchronousCalloutResponse> <claim code="CLAIM123"> <attendingProvider>123456</attendingProvider> <locationProvider>345678</locationProvider> <operatingProvider>098765</operatingProvider> <referralProvider>567895</referralProvider> </claim> </asynchronousCalloutResponse>
Asynchronous Response Response Message
See Response Messages for more details.
Error Messages
The following error messages that are specific to this Integration Point may be returned in the Asynchronous Response Response Message:
Code | Sev | Message |
---|---|---|
CLA-IP-CALL-001 |
Fatal |
Callout Response with correlation id {0} is already received |
CLA-IP-CALL-002 |
Fatal |
Callout Request with correlation id {0} could not be found |
CLA-IP-CALL-007 |
Fatal |
Callout Request with correlation id {0} has already timed out |
|
Additional Notes
Note the following applies:
|