Third party Information sharing

Enabling use cases for sharing information related to claims with other participants

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:

1. Parties involved in the cycle can report the information to all the subscribed parties when a claim cycle is completed

2. 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

Information reporting can be enabled by leveraging the notifications 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 Notification specifications.

Fetching Information

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 Status API where a Task 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:

{
  "resourceType": "Task",
  "id": "fm-example4",
  "status": "requested",
  "intent": "order",
  "priority": "stat",
  "code": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/Insurance",
        "code": "EOB-15C"
      }
    ]
  },
  "authoredOn": "2018-10-04T08:25:05+10:00",
  "lastModified": "2018-10-04T08:25:05+10:00",
  "requester": {
    "display": "IIB"
  },
  "input": [
    {
      "type": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/financialtaskinputtype",
            "code": "correlation-id"
          }
        ]
      },
      "valueId": "correlation-id-xyz"
    }
  ]
}

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.

API Definitions

post

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:

1. A set of header attributes that provide transport, security, message integrity and summary information about the message being exchanged. This information is used by the HCX gateway for routing the request and auditing purposes.
2. Domain payload containing the Task entity (eObject) as prescribed for the use case by the domain specifications. This needs to be encrypted so that HCX cannot read this and can be decrypted & processed only by the intended recipient.

The domain payload is expressed using Task resource, where

• Task.code specifies the purpose of information of fetch request, e.g.: "EOB-15C" by IIB
• Task.input carries identifiers of the claim workflow for which the information is being requested for, e.g.: "correlation-id-xyz"

The response to this API could be one of the following:

1. A successful accepted response from the HCX gateway if the strucuture of the request is valid and the validation of open attributes (protocol headers) is successful. Upon successful validation, HCX gateway forwards the same request to the intended recipient asynchronously.
2. An error response if any of the validations fail.

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.

Authorizations

bearer_auth

AuthorizationstringRequired

Bearer authentication header of the form Bearer <token>.

Body

application/json

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).

Responses

202

Accepted

application/json

400

Request Validation failed

application/json

404

Requested resource was not found

application/json

500

Downstream systems down/unhandled exceptions.

application/json

post

/eob/fetch

HTTPcURLJavaScriptPython

POST /eob/fetch HTTP/1.1
Authorization: Bearer YOUR_SECRET_TOKEN
Content-Type: application/json
Accept: */*
Content-Length: 1231

{
  "payload": "eyJlbmMiOiJBMjU2R0NNIiwKImFsZyI6IlJTQS1PQUVQIiwKIngtaGN4LXNlbmRlcl9jb2RlIjoiMS00ZGMzZTA4OC1hMzEzLTQ0YWItYWZhMS0wMjIyOTU5Y2I3NWIiLAoieC1oY3gtcmVjaXBpZW50X2NvZGUiOiIxLTkzZjkwOGJhLWI1NzktNDUzZS04YjJhLTU2MDIyYWZhZDI3NSIsCiJ4LWhjeC1yZXF1ZXN0X2lkIjoiMjZiMTA2MGMtMWU4My00NjAwLTk2MTItZWEzMWUwY2E1MDkxIiwKIngtaGN4LWNvcnJlbGF0aW9uX2lkIjoiNWU5MzRmOTAtMTExZC00ZjBiLWIwMTYtYzIyZDgyMDY3NGUxIiwKIngtaGN4LXRpbWVzdGFtcCI6IjIwMjEtMTAtMjdUMjA6MzU6NTIuNjM2KzA1MzAiLAoieC1oY3gtc3RhdHVzIjoicmVxdWVzdC5pbml0aWF0ZSIsCiJ4LWhjeC13b3JrZmxvd19pZCI6IjVlOTM0ZjkwLTExMWQtNGYwYi1iMDE2LWMyMmQ4MjA2NzRlMiIsCiJ4LWhjeC1kZWJ1Z19mbGFnIjoiSW5mbyIsCiJ4LWhjeC1lcnJvcl9kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCAidHJhY2UiOiAiIn0sCiJ4LWhjeC1kZWJ1Z19kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCJ0cmFjZSI6IiJ9LAoiandzX2hlYWRlciI6eyJ0eXAiOiJKV1QiLCAiYWxnIjoiUlMyNTYifSwKImp3ZV9oZWFkZXIiOnsiYWxnIjoiUlNBLU9BRVAiLCJlbmMiOiJBMjU2R0NNIn0KfQ==.6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.Mz-VPPyU4RlcuYv1IwIvzw"
}

{
  "timestamp": "1629057611000",
  "api_call_id": "123e4567-e89b-12d3-a456-426614174000",
  "correlation_id": "123e4567-e89b-12d3-a456-426614174000"
}

post

This 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:

1. 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.

2. 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.

Authorizations

bearer_auth

AuthorizationstringRequired

Bearer authentication header of the form Bearer <token>.

Body

application/json

or

Responses

202

Accepted

application/json

400

Request Validation failed

application/json

404

Requested resource was not found

application/json

500

Downstream systems down/unhandled exceptions.

application/json

post

/eob/on_fetch

HTTPcURLJavaScriptPython

POST /eob/on_fetch HTTP/1.1
Authorization: Bearer YOUR_SECRET_TOKEN
Content-Type: application/json
Accept: */*
Content-Length: 1231

{
  "payload": "eyJlbmMiOiJBMjU2R0NNIiwKImFsZyI6IlJTQS1PQUVQIiwKIngtaGN4LXNlbmRlcl9jb2RlIjoiMS00ZGMzZTA4OC1hMzEzLTQ0YWItYWZhMS0wMjIyOTU5Y2I3NWIiLAoieC1oY3gtcmVjaXBpZW50X2NvZGUiOiIxLTkzZjkwOGJhLWI1NzktNDUzZS04YjJhLTU2MDIyYWZhZDI3NSIsCiJ4LWhjeC1yZXF1ZXN0X2lkIjoiMjZiMTA2MGMtMWU4My00NjAwLTk2MTItZWEzMWUwY2E1MDkxIiwKIngtaGN4LWNvcnJlbGF0aW9uX2lkIjoiNWU5MzRmOTAtMTExZC00ZjBiLWIwMTYtYzIyZDgyMDY3NGUxIiwKIngtaGN4LXRpbWVzdGFtcCI6IjIwMjEtMTAtMjdUMjA6MzU6NTIuNjM2KzA1MzAiLAoieC1oY3gtc3RhdHVzIjoicmVxdWVzdC5pbml0aWF0ZSIsCiJ4LWhjeC13b3JrZmxvd19pZCI6IjVlOTM0ZjkwLTExMWQtNGYwYi1iMDE2LWMyMmQ4MjA2NzRlMiIsCiJ4LWhjeC1kZWJ1Z19mbGFnIjoiSW5mbyIsCiJ4LWhjeC1lcnJvcl9kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCAidHJhY2UiOiAiIn0sCiJ4LWhjeC1kZWJ1Z19kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCJ0cmFjZSI6IiJ9LAoiandzX2hlYWRlciI6eyJ0eXAiOiJKV1QiLCAiYWxnIjoiUlMyNTYifSwKImp3ZV9oZWFkZXIiOnsiYWxnIjoiUlNBLU9BRVAiLCJlbmMiOiJBMjU2R0NNIn0KfQ==.6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.Mz-VPPyU4RlcuYv1IwIvzw"
}

{
  "timestamp": "1629057611000",
  "api_call_id": "123e4567-e89b-12d3-a456-426614174000",
  "correlation_id": "123e4567-e89b-12d3-a456-426614174000"
}

Full API specifications in OpenAPI 3.0 format are available here.