Third party Information sharing
Enabling use cases for sharing information related to claims with other participants
Last updated
Was this helpful?
Enabling use cases for sharing information related to claims with other participants
Last updated
Was this helpful?
There are multiple use cases in the context of claims where certain information about the claims need to be shared to parties that are not directly involved in the claim processing cycle. Some such examples are:
Regulators like IIB need to collect information about the processed claims at the completion of a claims cycle. IIB uses this information to help the insurance industry with information and analytical support.
Sponsors like NHA/SHA/Corporate/Community need to know about completion and details of a claims cycle for all the patients sponsored by them.
An ISNP needs to know the status and details of a claim on behalf of its patient.
Such information can be made available to the interested parties in either of the following ways in HCX:
Parties involved in the cycle can report the information to all the subscribed parties when a claim cycle is completed
Parties who need information about a claim cycle can fetch the information from involved parties after the completion of a claim cycle (this is mostly be triggered when the interested party receives the relevant workflow notification)
Information reporting can be enabled by leveraging the capability of the protocol. Since the information to be reported may contain PII information of the patients & other sensitive information, the “PII carrying workflow notification” category of notifications should be used for this purpose.
The steps and process for PII carrying workflow notifications are detailed in the .
Though a mechanism to report information is available, there still may be some scenarios where the parties may need to fetch the required information on demand (e.g.: if the PII notification is not delivered due to technical problems). In such cases, there should be a way for the participants to fetch the required information by directly querying the involved party (a payor or a provider). As the current known use cases for information fetching are only around claim workflows and such information request can be fulfilled by sending the information in form of an ExplanationOfBenefit (EOB) resource, the API paths are qualified to clearly scope the usage of API only for this purpose (i.e. reporting of claims information using EOB resource).
Following two APIs will be enabled for claim information fetching using EOB resource:
eob/fetch: Used by third parties (like IIB, sponsor or an ISNP) to request for information about a specific claim (or pre-auth or a pre-determination). The third party shall call the fetch API on the HCX switch and HCX internally routes the fetch request to the relevant participant. The payload for this API should contain the correlation_id of the cycle for which the information is being requested for.
eob/on_fetch: This is the callback API via which the requested information is sent back to the third party via the HCX switch.
Request Payload Similar to where a FHIR resource is used as the payload to request for status of a specific API call, the Fetch API shall also use Task resource to request for information about a specific claim workflow. The Task resource shall contain details about the claim workflow for which the information is being requested and optionally the purpose of the fetch request.
Sample Task resource as Fetch API request payload:
Response Payload The payload of response to a fetch request should contain all information related to a claim cycle. As per HL7, the ExplanationOfBenefit (EOB) resource combines key information from a Claim, a ClaimResponse, optional account information and can be used as a resource for data exchange for use cases like reporting. Hence, the ExplanationOfBenefit resource shall be used as the response payload for a claim workflow fetch request.
Full API specifications in OpenAPI 3.0 format are available .
This API is for the authorised participants in the network to request information about a claim workflow. The request body (header attributes and the FHIR document) should be sent in the form of a JWE token (RFC-7516) created as per the steps defined in HCX specs.
The JWE payload (request body) primarily should contain the following:
The domain payload is expressed using Task resource, where
The response to this API could be one of the following:
If the request is successfully accepted by the HCX gateway and forwarded to the recipient, the sender of the request (who made the Fetch API call) should expect the response via a call back to On Fetch API asynchronously. The response API payload may either contain the requested claim workflow details or error details in case of any errors during processing.
This object is used as payload in the HCX protocol APIs that require the request body to sent in JWE format (as defined in RFC-7516).
The paylod should be a JWE token containing the following elements.
The final payload should be serialzed using JWE compact serialization as defined in the RFC-7516 -
protected || '.' || encrypted_key || '.' || iv || '.' || ciphertext || '.' || authentication_tag
Detailed steps on how to construct the JWE token are provided in this section of the HCX specifications.
eyJlbmMiOiJBMjU2R0NNIiwKImFsZyI6IlJTQS1PQUVQIiwKIngtaGN4LXNlbmRlcl9jb2RlIjoiMS00ZGMzZTA4OC1hMzEzLTQ0YWItYWZhMS0wMjIyOTU5Y2I3NWIiLAoieC1oY3gtcmVjaXBpZW50X2NvZGUiOiIxLTkzZjkwOGJhLWI1NzktNDUzZS04YjJhLTU2MDIyYWZhZDI3NSIsCiJ4LWhjeC1yZXF1ZXN0X2lkIjoiMjZiMTA2MGMtMWU4My00NjAwLTk2MTItZWEzMWUwY2E1MDkxIiwKIngtaGN4LWNvcnJlbGF0aW9uX2lkIjoiNWU5MzRmOTAtMTExZC00ZjBiLWIwMTYtYzIyZDgyMDY3NGUxIiwKIngtaGN4LXRpbWVzdGFtcCI6IjIwMjEtMTAtMjdUMjA6MzU6NTIuNjM2KzA1MzAiLAoieC1oY3gtc3RhdHVzIjoicmVxdWVzdC5pbml0aWF0ZSIsCiJ4LWhjeC13b3JrZmxvd19pZCI6IjVlOTM0ZjkwLTExMWQtNGYwYi1iMDE2LWMyMmQ4MjA2NzRlMiIsCiJ4LWhjeC1kZWJ1Z19mbGFnIjoiSW5mbyIsCiJ4LWhjeC1lcnJvcl9kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCAidHJhY2UiOiAiIn0sCiJ4LWhjeC1kZWJ1Z19kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCJ0cmFjZSI6IiJ9LAoiandzX2hlYWRlciI6eyJ0eXAiOiJKV1QiLCAiYWxnIjoiUlMyNTYifSwKImp3ZV9oZWFkZXIiOnsiYWxnIjoiUlNBLU9BRVAiLCJlbmMiOiJBMjU2R0NNIn0KfQ==.6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.Mz-VPPyU4RlcuYv1IwIvzwThis is the callback API for payors to send the response for a EOB fetch request from the originator. In case of a successful scenario, this API payload should contain the claim workflow details (represented using ExplanationOfBenefit FHIR resource).
Payors should send the following details as the request payload in this callback API:
The responder shall send a ProtocolResponse object (derived from ProtocolHeader) as the request payload if there are any protocol related errors in processing the corresponding EOB Fetch request (see error handling section in the HCX specifications). The x-hcx-status header value in the ProtocolResponse must be "response.error" while responding with an error.
In case the EOB fetch request could be processed, responder should send a JWEPayload derived from protected ProtocolHeader and ExplanationOfBenefit resources as prescribed for the use case by the domain specifications. ExplanationOfBenefit resource inside the payload would contain details about the claim workflow for which a fetch request is sent.
This object is used as payload in the HCX protocol APIs that require the request body to sent in JWE format (as defined in RFC-7516).
Object to be returned as payload of the callback API (on_* APIs) in case there are any protocol related errors while processing the request or send a redirection instruction to the original sender of the request.