Supporting APIs

Details of APIs that provide support for operations within HCX. These APIs are useful in enabling the additional message flows in HCX.

Communication APIs

Communications API will be used for communications between multiple participants in the HCX ecosystem.

/communication/request

This API is for payors to raise a communication requests to HCX gateway and for HCX gateway to route the same request to providers during the claims cycle.

A communication request can happen only within the context of a existing claim cycle (predetermination, preauth or the actual claim). The protocol header x-hcx-correlation_id should carry the correlation id of the original claim request for which the communication request is being raised. HCX gateway should validate that the correlation id is a valid identifier and the original claim request is still open.

Payload for this API has to be created as per the Communication Request defined in HCX Specifications and serialized as per the guidelines in HCX Specifications.

POST/communication/request

Authorization

Body

payload*object (string)

The paylod should be a JWE token containing the following elements.

Protected headers (protected) - A set of attributes that provide transport, security, message integrity and summary information about the message being exchanged.
JWE element (encrypted_key) - Content Encryption Key.
JWE element (iv) - Initialisation Vector for the algorithm.
Encrypted Payload (ciphertext) - Payload containing the relevant domain entity (eObject) as prescribed for the use case by the domain specifications. This needs to be encrypted so that HCX cannot read this.
Authentication tag (authentication_tag) - Digital signature on the protected header and the payload of the message to ensure its integrity.

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.

Response

Accepted

Body

timestamp*string

Unix timestamp when the response is sent.

api_call_id*string (uuid)

That is present in the transport header of the request.

correlation_id*string (uuid)

That is present in the transport header of the request.

Request

const response = await fetch('/communication/request', {
    method: 'POST',
    headers: {
      "Authorization": "Bearer JWT",
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      "payload": "eyJlbmMiOiJBMjU2R0NNIiwKImFsZyI6IlJTQS1PQUVQIiwKIngtaGN4LXNlbmRlcl9jb2RlIjoiMS00ZGMzZTA4OC1hMzEzLTQ0YWItYWZhMS0wMjIyOTU5Y2I3NWIiLAoieC1oY3gtcmVjaXBpZW50X2NvZGUiOiIxLTkzZjkwOGJhLWI1NzktNDUzZS04YjJhLTU2MDIyYWZhZDI3NSIsCiJ4LWhjeC1yZXF1ZXN0X2lkIjoiMjZiMTA2MGMtMWU4My00NjAwLTk2MTItZWEzMWUwY2E1MDkxIiwKIngtaGN4LWNvcnJlbGF0aW9uX2lkIjoiNWU5MzRmOTAtMTExZC00ZjBiLWIwMTYtYzIyZDgyMDY3NGUxIiwKIngtaGN4LXRpbWVzdGFtcCI6IjIwMjEtMTAtMjdUMjA6MzU6NTIuNjM2KzA1MzAiLAoieC1oY3gtc3RhdHVzIjoicmVxdWVzdC5pbml0aWF0ZSIsCiJ4LWhjeC13b3JrZmxvd19pZCI6IjVlOTM0ZjkwLTExMWQtNGYwYi1iMDE2LWMyMmQ4MjA2NzRlMiIsCiJ4LWhjeC1kZWJ1Z19mbGFnIjoiSW5mbyIsCiJ4LWhjeC1lcnJvcl9kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCAidHJhY2UiOiAiIn0sCiJ4LWhjeC1kZWJ1Z19kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCJ0cmFjZSI6IiJ9LAoiandzX2hlYWRlciI6eyJ0eXAiOiJKV1QiLCAiYWxnIjoiUlMyNTYifSwKImp3ZV9oZWFkZXIiOnsiYWxnIjoiUlNBLU9BRVAiLCJlbmMiOiJBMjU2R0NNIn0KfQ==.6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.Mz-VPPyU4RlcuYv1IwIvzw"
    }),
});
const data = await response.json();

Response

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

/communication/on_request

This is a callback API is for recievers of Communication request to send the Communication response.

Responder 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 in the following scenarios:
- if there are any protocol related errors in processing the corresponding CommunicationRequest (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.
- if the responder wants to send a redirection instruction to the original sender (see redirection flow in the HCX specifications). The x-hcx-status header value in the ProtocolResponse must be "response.redirect" and the x-hcx-redirect_to header must have a value while sending a redirection instruction.
In case CommunicationRequest could be processed, responder should send a JWEPayload derived from protected ProtocolHeader and Communication bundle as prescribed for the use case by the domain specifications. Communication resource inside the bundle would contain details about the domain/business processing outcome as follows as per FHIR specifications for the resource.

POST/communication/on_request

Authorization

Body

one of

Response

Accepted

Body

timestamp*string

Unix timestamp when the response is sent.

api_call_id*string (uuid)

That is present in the transport header of the request.

correlation_id*string (uuid)

That is present in the transport header of the request.

Request

const response = await fetch('/communication/on_request', {
    method: 'POST',
    headers: {
      "Authorization": "Bearer JWT",
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      "payload": "eyJlbmMiOiJBMjU2R0NNIiwKImFsZyI6IlJTQS1PQUVQIiwKIngtaGN4LXNlbmRlcl9jb2RlIjoiMS00ZGMzZTA4OC1hMzEzLTQ0YWItYWZhMS0wMjIyOTU5Y2I3NWIiLAoieC1oY3gtcmVjaXBpZW50X2NvZGUiOiIxLTkzZjkwOGJhLWI1NzktNDUzZS04YjJhLTU2MDIyYWZhZDI3NSIsCiJ4LWhjeC1yZXF1ZXN0X2lkIjoiMjZiMTA2MGMtMWU4My00NjAwLTk2MTItZWEzMWUwY2E1MDkxIiwKIngtaGN4LWNvcnJlbGF0aW9uX2lkIjoiNWU5MzRmOTAtMTExZC00ZjBiLWIwMTYtYzIyZDgyMDY3NGUxIiwKIngtaGN4LXRpbWVzdGFtcCI6IjIwMjEtMTAtMjdUMjA6MzU6NTIuNjM2KzA1MzAiLAoieC1oY3gtc3RhdHVzIjoicmVxdWVzdC5pbml0aWF0ZSIsCiJ4LWhjeC13b3JrZmxvd19pZCI6IjVlOTM0ZjkwLTExMWQtNGYwYi1iMDE2LWMyMmQ4MjA2NzRlMiIsCiJ4LWhjeC1kZWJ1Z19mbGFnIjoiSW5mbyIsCiJ4LWhjeC1lcnJvcl9kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCAidHJhY2UiOiAiIn0sCiJ4LWhjeC1kZWJ1Z19kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCJ0cmFjZSI6IiJ9LAoiandzX2hlYWRlciI6eyJ0eXAiOiJKV1QiLCAiYWxnIjoiUlMyNTYifSwKImp3ZV9oZWFkZXIiOnsiYWxnIjoiUlNBLU9BRVAiLCJlbmMiOiJBMjU2R0NNIn0KfQ==.6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.Mz-VPPyU4RlcuYv1IwIvzw"
    }),
});
const data = await response.json();

Response

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

Status APIs

Status API can be used by providers to know the status of a request made by them. For example, a provider can query the status of a pre-auth request using the status API. HCX gateway shall return the protocol status synchronously and the recipient returns the status in the on_status callback API asynchronously.

/hcx/status

Participants (Provider/Payors) in the network can check the business status of particular processes initiated, for example, status of pre-auth request, claim, status of information requested. The request payload is expressed using FHIR Task, where

Task.code specifies the nature of the check, and
Task.focus specifies the context identifiers (e.g case-id for a registered pre-auth, claim id of the provider TMS).
Task.input carries additional information about the context, e.g: type of entity - preauthorization, claim, etc.

The protocol header x-hcx-correlation_id should carry the correlation id of the process (request) for which the status is being requested for. HCX gateway should validate that the correlation id is a valid identifier and the request is still open.

The request body for this API should be sent in the form of a JWE token (RFC-7516) using the steps defined in HCX specs. HCX gateway shall validate the incoming request and send the protocol status in the http response. The protocol status value could be one of the following:

request.queued - This status means that HCX gateway has not yet forwarded the original request (for which the status is being requeested for) to the intended recipient. The request is still under processing by the HCX gateway. In this scenario, there shall not be a status response via the call back API /hcx/on_status to the caller.
request.dispatched - This means that HCX gateway has dispatched the original request to the intended recipient and thus, HCX gateway will forward the status request to the same recipient. And the recipient shall respond with status details via the call back API /hcx/on_status to the caller.

POST/hcx/status

Authorization

Body

payload*object (string)

The paylod should be a JWE token containing the following elements.

Protected headers (protected) - A set of attributes that provide transport, security, message integrity and summary information about the message being exchanged.
JWE element (encrypted_key) - Content Encryption Key.
JWE element (iv) - Initialisation Vector for the algorithm.
Encrypted Payload (ciphertext) - Payload containing the relevant domain entity (eObject) as prescribed for the use case by the domain specifications. This needs to be encrypted so that HCX cannot read this.
Authentication tag (authentication_tag) - Digital signature on the protected header and the payload of the message to ensure its integrity.

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.

Response

Accepted

Body

timestamp*string

Unix timestamp when the response is sent.

api_call_id*string (uuid)

That is present in the transport header of the request.

correlation_id*string (uuid)

That is present in the transport header of the request.

resultStatusResponseObject (object)

Request

const response = await fetch('/hcx/status', {
    method: 'POST',
    headers: {
      "Authorization": "Bearer JWT",
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      "payload": "eyJlbmMiOiJBMjU2R0NNIiwKImFsZyI6IlJTQS1PQUVQIiwKIngtaGN4LXNlbmRlcl9jb2RlIjoiMS00ZGMzZTA4OC1hMzEzLTQ0YWItYWZhMS0wMjIyOTU5Y2I3NWIiLAoieC1oY3gtcmVjaXBpZW50X2NvZGUiOiIxLTkzZjkwOGJhLWI1NzktNDUzZS04YjJhLTU2MDIyYWZhZDI3NSIsCiJ4LWhjeC1yZXF1ZXN0X2lkIjoiMjZiMTA2MGMtMWU4My00NjAwLTk2MTItZWEzMWUwY2E1MDkxIiwKIngtaGN4LWNvcnJlbGF0aW9uX2lkIjoiNWU5MzRmOTAtMTExZC00ZjBiLWIwMTYtYzIyZDgyMDY3NGUxIiwKIngtaGN4LXRpbWVzdGFtcCI6IjIwMjEtMTAtMjdUMjA6MzU6NTIuNjM2KzA1MzAiLAoieC1oY3gtc3RhdHVzIjoicmVxdWVzdC5pbml0aWF0ZSIsCiJ4LWhjeC13b3JrZmxvd19pZCI6IjVlOTM0ZjkwLTExMWQtNGYwYi1iMDE2LWMyMmQ4MjA2NzRlMiIsCiJ4LWhjeC1kZWJ1Z19mbGFnIjoiSW5mbyIsCiJ4LWhjeC1lcnJvcl9kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCAidHJhY2UiOiAiIn0sCiJ4LWhjeC1kZWJ1Z19kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCJ0cmFjZSI6IiJ9LAoiandzX2hlYWRlciI6eyJ0eXAiOiJKV1QiLCAiYWxnIjoiUlMyNTYifSwKImp3ZV9oZWFkZXIiOnsiYWxnIjoiUlNBLU9BRVAiLCJlbmMiOiJBMjU2R0NNIn0KfQ==.6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.Mz-VPPyU4RlcuYv1IwIvzw"
    }),
});
const data = await response.json();

Response

{
  "timestamp": "1629057611000",
  "api_call_id": "123e4567-e89b-12d3-a456-426614174000",
  "correlation_id": "123e4567-e89b-12d3-a456-426614174000",
  "result": {
    "sender_code": "text",
    "recipient_code": "text",
    "entity_type": "coverageeligibility",
    "protocol_status": "request.queued"
  }
}

/hcx/on_status

This is a callback API is for recievers of status request to send the processing status of requested resource.

Responder 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 in the following scenarios:
- if there are any protocol related errors in processing the corresponding Status 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.
- if the responder wants to send a redirection instruction to the original sender (see redirection flow in the HCX specifications). The x-hcx-status header value in the ProtocolResponse must be "response.redirect" and the x-hcx-redirect_to header must have a value while sending a redirection instruction.
In case Status request could be processed, responder should send a JWEPayload derived from protected ProtocolHeader and Response bundle corresponding to the resource (e.g. a CoverageEligibilityResponse or a ClaimResponse etc.) indicated in the status request. It could be any of the Response resources as prescribed for the use case by the domain specifications. Response resource inside the bundle would contain details about the domain/business processing outcome as follows as per FHIR specifications for the resource.

In a way this callback behaves similar to corresponding cycle's on_* callback, however, while those callbacks would usually carry the FHIR resource with "complete" or "error" outcome, this callback may also indicate a partially processed resource.

POST/hcx/on_status

Authorization

Body

one of

Response

Accepted

Body

timestamp*string

Unix timestamp when the response is sent.

api_call_id*string (uuid)

That is present in the transport header of the request.

correlation_id*string (uuid)

That is present in the transport header of the request.

Request

const response = await fetch('/hcx/on_status', {
    method: 'POST',
    headers: {
      "Authorization": "Bearer JWT",
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      "payload": "eyJlbmMiOiJBMjU2R0NNIiwKImFsZyI6IlJTQS1PQUVQIiwKIngtaGN4LXNlbmRlcl9jb2RlIjoiMS00ZGMzZTA4OC1hMzEzLTQ0YWItYWZhMS0wMjIyOTU5Y2I3NWIiLAoieC1oY3gtcmVjaXBpZW50X2NvZGUiOiIxLTkzZjkwOGJhLWI1NzktNDUzZS04YjJhLTU2MDIyYWZhZDI3NSIsCiJ4LWhjeC1yZXF1ZXN0X2lkIjoiMjZiMTA2MGMtMWU4My00NjAwLTk2MTItZWEzMWUwY2E1MDkxIiwKIngtaGN4LWNvcnJlbGF0aW9uX2lkIjoiNWU5MzRmOTAtMTExZC00ZjBiLWIwMTYtYzIyZDgyMDY3NGUxIiwKIngtaGN4LXRpbWVzdGFtcCI6IjIwMjEtMTAtMjdUMjA6MzU6NTIuNjM2KzA1MzAiLAoieC1oY3gtc3RhdHVzIjoicmVxdWVzdC5pbml0aWF0ZSIsCiJ4LWhjeC13b3JrZmxvd19pZCI6IjVlOTM0ZjkwLTExMWQtNGYwYi1iMDE2LWMyMmQ4MjA2NzRlMiIsCiJ4LWhjeC1kZWJ1Z19mbGFnIjoiSW5mbyIsCiJ4LWhjeC1lcnJvcl9kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCAidHJhY2UiOiAiIn0sCiJ4LWhjeC1kZWJ1Z19kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCJ0cmFjZSI6IiJ9LAoiandzX2hlYWRlciI6eyJ0eXAiOiJKV1QiLCAiYWxnIjoiUlMyNTYifSwKImp3ZV9oZWFkZXIiOnsiYWxnIjoiUlNBLU9BRVAiLCJlbmMiOiJBMjU2R0NNIn0KfQ==.6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.Mz-VPPyU4RlcuYv1IwIvzw"
    }),
});
const data = await response.json();

Response

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

Following APIs are included in the protocol 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

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:

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

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

POST/eob/fetch

Authorization

Body

payload*object (string)

The paylod should be a JWE token containing the following elements.

Protected headers (protected) - A set of attributes that provide transport, security, message integrity and summary information about the message being exchanged.
JWE element (encrypted_key) - Content Encryption Key.
JWE element (iv) - Initialisation Vector for the algorithm.
Encrypted Payload (ciphertext) - Payload containing the relevant domain entity (eObject) as prescribed for the use case by the domain specifications. This needs to be encrypted so that HCX cannot read this.
Authentication tag (authentication_tag) - Digital signature on the protected header and the payload of the message to ensure its integrity.

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.

Response

Accepted

Body

timestamp*string

Unix timestamp when the response is sent.

api_call_id*string (uuid)

That is present in the transport header of the request.

correlation_id*string (uuid)

That is present in the transport header of the request.

Request

const response = await fetch('/eob/fetch', {
    method: 'POST',
    headers: {
      "Authorization": "Bearer JWT",
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      "payload": "eyJlbmMiOiJBMjU2R0NNIiwKImFsZyI6IlJTQS1PQUVQIiwKIngtaGN4LXNlbmRlcl9jb2RlIjoiMS00ZGMzZTA4OC1hMzEzLTQ0YWItYWZhMS0wMjIyOTU5Y2I3NWIiLAoieC1oY3gtcmVjaXBpZW50X2NvZGUiOiIxLTkzZjkwOGJhLWI1NzktNDUzZS04YjJhLTU2MDIyYWZhZDI3NSIsCiJ4LWhjeC1yZXF1ZXN0X2lkIjoiMjZiMTA2MGMtMWU4My00NjAwLTk2MTItZWEzMWUwY2E1MDkxIiwKIngtaGN4LWNvcnJlbGF0aW9uX2lkIjoiNWU5MzRmOTAtMTExZC00ZjBiLWIwMTYtYzIyZDgyMDY3NGUxIiwKIngtaGN4LXRpbWVzdGFtcCI6IjIwMjEtMTAtMjdUMjA6MzU6NTIuNjM2KzA1MzAiLAoieC1oY3gtc3RhdHVzIjoicmVxdWVzdC5pbml0aWF0ZSIsCiJ4LWhjeC13b3JrZmxvd19pZCI6IjVlOTM0ZjkwLTExMWQtNGYwYi1iMDE2LWMyMmQ4MjA2NzRlMiIsCiJ4LWhjeC1kZWJ1Z19mbGFnIjoiSW5mbyIsCiJ4LWhjeC1lcnJvcl9kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCAidHJhY2UiOiAiIn0sCiJ4LWhjeC1kZWJ1Z19kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCJ0cmFjZSI6IiJ9LAoiandzX2hlYWRlciI6eyJ0eXAiOiJKV1QiLCAiYWxnIjoiUlMyNTYifSwKImp3ZV9oZWFkZXIiOnsiYWxnIjoiUlNBLU9BRVAiLCJlbmMiOiJBMjU2R0NNIn0KfQ==.6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.Mz-VPPyU4RlcuYv1IwIvzw"
    }),
});
const data = await response.json();

Response

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

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:

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.

POST/eob/on_fetch

Authorization

Body

one of

Response

Accepted

Body

timestamp*string

Unix timestamp when the response is sent.

api_call_id*string (uuid)

That is present in the transport header of the request.

correlation_id*string (uuid)

That is present in the transport header of the request.

Request

const response = await fetch('/eob/on_fetch', {
    method: 'POST',
    headers: {
      "Authorization": "Bearer JWT",
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      "payload": "eyJlbmMiOiJBMjU2R0NNIiwKImFsZyI6IlJTQS1PQUVQIiwKIngtaGN4LXNlbmRlcl9jb2RlIjoiMS00ZGMzZTA4OC1hMzEzLTQ0YWItYWZhMS0wMjIyOTU5Y2I3NWIiLAoieC1oY3gtcmVjaXBpZW50X2NvZGUiOiIxLTkzZjkwOGJhLWI1NzktNDUzZS04YjJhLTU2MDIyYWZhZDI3NSIsCiJ4LWhjeC1yZXF1ZXN0X2lkIjoiMjZiMTA2MGMtMWU4My00NjAwLTk2MTItZWEzMWUwY2E1MDkxIiwKIngtaGN4LWNvcnJlbGF0aW9uX2lkIjoiNWU5MzRmOTAtMTExZC00ZjBiLWIwMTYtYzIyZDgyMDY3NGUxIiwKIngtaGN4LXRpbWVzdGFtcCI6IjIwMjEtMTAtMjdUMjA6MzU6NTIuNjM2KzA1MzAiLAoieC1oY3gtc3RhdHVzIjoicmVxdWVzdC5pbml0aWF0ZSIsCiJ4LWhjeC13b3JrZmxvd19pZCI6IjVlOTM0ZjkwLTExMWQtNGYwYi1iMDE2LWMyMmQ4MjA2NzRlMiIsCiJ4LWhjeC1kZWJ1Z19mbGFnIjoiSW5mbyIsCiJ4LWhjeC1lcnJvcl9kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCAidHJhY2UiOiAiIn0sCiJ4LWhjeC1kZWJ1Z19kZXRhaWxzIjp7ImVycm9yLmNvZGUiOiAiYmFkLmlucHV0IiwgImVycm9yLm1lc3NhZ2UiOiAiUHJvdmlkZXIgY29kZSBub3QgZm91bmQiLCJ0cmFjZSI6IiJ9LAoiandzX2hlYWRlciI6eyJ0eXAiOiJKV1QiLCAiYWxnIjoiUlMyNTYifSwKImp3ZV9oZWFkZXIiOnsiYWxnIjoiUlNBLU9BRVAiLCJlbmMiOiJBMjU2R0NNIn0KfQ==.6KB707dM9YTIgHtLvtgWQ8mKwboJW3of9locizkDTHzBC2IlrT1oOQ.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.KDlTtXchhZTGufMYmOYGS4HffxPSUrfmqCHXaI9wOGY.Mz-VPPyU4RlcuYv1IwIvzw"
    }),
});
const data = await response.json();

Response

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

Third Party Information Sharing API specifications in OpenAPI 3.0 format are available here.

PreviousPrimary Flow APIs NextNotification APIs

Last updated 4 months ago

Communication APIs

Status APIs

Third Party Information Sharing APIs

API Definitions