Proposed changes to message ids in HCX protocol headers

[vrayulu]

Proposed changes to the message ids (x-hcx-request_id, x-hcx-correlation_id & x-hcx-workflow_id) defined in HCX Protocol Headers section of the HCX specifications:

x-hcx-api_call_id

Sender generated unique id for each originating request. All senders (providers & payors) must generate and set a unique value to the x-hcx-api_call_id protocol header in all the API calls to the HCX gateway.

this header replaces the x-hcx-request_id header in the current version of specifications

x-hcx-correlation_id

Unique id for all messages (requests & responses) that are involved in processing of one cycle (like coverage eligibility, pre-auth, claim, or payment notice cycle).
The participant system sending the originating request of the cycle must set the x-hcx-correlation_id in the initial API call and the HCX gateway shall forward the same correlation id to the recipient of the request. The recipient must set the same correlation id in the response API call and in other API calls related to the original request (e.g. communication request, forward/redirect requests). And the same correlation id must be sent in all subsequent API calls (related to the same cycle).

x-hcx-workflow_id

Unique id for one complete workflow that spans over a series of cycles and message exchanges within the context of an admission/case.
This is an optional header that can be set by providers to the same value for all requests (coverage eligibility check, preauth, claim, etc) related to a single admission/case. And when the workflow_id is sent by the originating provider, all other participant systems (payors) must set the same workflow id in all API calls (responses, forwards/redirects, payment notices, etc) related to the workflow.

---

Usage of the above message ids in a sample scenario:

@abhimail @gopi-vitraya @angshu - please review the proposed changes and share your comments.

[gopi-vitraya]

• The x-hcx-api_call_id is used in tracking individual HTTP API calls to HCX, request level issue resolution with/at HCX and for debugging.
• The x-hcx-correlation_id, as far as I could think is set by provider's or subscriber's app (reimbursement case). This means that this header could just be the claim ID of the provider system or subscriber system. The current industry practice is that all the communication is revolved against the case ID set by the payer's system against a claim raised by the provider system. In a sense, this aspect of the protocol is slightly tilting towards the providers or subscribers rather than the payers. Given that the payers are usually technically more resourceful than the former, this shift in the primary tracker ID is not very disruptive. This means the payer system may have to record this ID against their claim object, and probably index it to support search/status API calls. However, let us be open to the feedback from everyone on this point.
• The x-hcx-workflow_id is a bit futuristic where we track all the claims related to a single hospitalization episode or a visit or a homeware episode or a stay at a rehabilitation center, skilled nursing facility or home health agency. Keeping in mind the innovation that could happen with the digitization of claims and policies, we could see coverages extending to outpatient visits, pharmacy expenses, patient commutes, etc... and hopefully leading to the concept of micro-policies or hyper-specialized policies or cooperative coverage by groups or employer payers. This may result in subscribers subscribing to multiple policies at the same time and try to use a combination of policies, thus resulting in multiple claims for an episode or a visit. So, this is definitely optional. We could even remove it in this version of the protocol and introduce it later.

[angshu]

@vrayulu it will be great if you can explain who is responsible for generating and communicating the IDs. For example, I assume that

1. x-hcx-api_call_id : is generated by provider and meant to be unique in the provider context (i.e uniqueness for providerr_id+x-hcx-api_call_id)?
2. x-hcx-correlation_id: is generated by HCX on receipt on the initial call (e.g. pre-auth request) and sent as HTTP response to provider against its request, and then passed onto Payor as protocol heeader?

[vrayulu]

1. Agree, HCX gateway can prefix the provider_id to api_call_id..

2. Should the HCX generate it? I was thinking if providers generate it, they will have the option to use their internal entity reference id as the correlation id and they need not maintain a mapping of correlation id to their system ids.

Another option is to have HCX gateway generate it on the initial call if provider did not set it.

@angshu

[angshu]

@vrayulu I didn't mean that. For request api id - the requester (payor, provider) should generate that. I was talking of making it claer on what cases who would generate which id. and for that purpose, i gave the example of correlation_id.

The "api request id" will also serve the purpose of defending against replay attack. they are also relevant to uniqueness and usage of the request id (e.g. for querying - status check).

• HCX can check the "api_call_id" to guard against replay attack. To accomplish the above, if HCX would keep track and record all such requestId - over time, it may face challenge to query and be performant - imagine hundreds and thousands of request identifiers piling up. One strategy that we used in HIE gateway standards is that the "Request id" only needs to be unique within a timeframe (say +/- 10 mins, to accomodate for time out of sync) - and beyond a certain point (a week or two) - HIE Gateway would archive the details. It uses Redis (cluster) as first level state engine.

[krisaccessh]

1. x-hcx-api_call_id is a Request level unique ID which should change with every request but unique across the multiple provider or payer systems (whoever initiate the request ) within a single HCX gateway as well as multiple distributed HCX gateways so this ID may be prefixed by provider_id and can be something like provider_id+uuid or payer_id+uuid (*provider or payer_id may be the participant codes ?) generated by the sender (provider or payer). This should be created for each new request but the same request_id may be passed for a Retry message to prevent duplication of processing.
2. x_hcp_correlation_id is a unique identifier to identify a particular transaction that may span across HCX gateways. so there will be a unique correlation ID for each new transaction e.g. "preauth eligibility check" or "claim response" and this can be created by the provider or payer whoever initiates the transaction. HCX should not generate this ID as ensuring the uniqueness of correlation_ids across transactions by multiple HCX gateways will be a bit complex. The correlation ID is unique across a transaction which may require multiple request calls (Claim submission transaction -> claim request from Provider To HCX1, HCX1->HCX2(if routing to another gateway), (HCX1-> payer - receiving the claim request) , payer_>HCX1, HCX1->provider(receiving claim response from payer) is one transaction
3. hcp_workflow_id should be unique across all the transactions for a single beneficiary between the provider and payer or insurance company. It may have multiple transactions and multiple request calls.

[angshu]

@krisaccessh I am not sure of whether provider (or initiator) should generate the correlation-id.

Generating a unique identifier across parties and gateways is complex enough, and we can not trust the initiator to know the system requirement across the networks and parties. IMHO, HCX should do that - and send it as http response to the initiator and carry it communicate to the recipient as protocol header. for multi-network calls correlation - I think its analogous to the network tracing problems and maybe we can take inspiration from there - see here https://www.w3.org/TR/trace-context/#problem-statement

[vharish85]

yes I agree to @angshu , HCX should generate id wherever possible and track it. I guess HCX will always inspect protocol headers for all communication happening. Additionally , we do have a payor , provider registration to hcx system right?

I have few questions regarding this diagram . Could someone clarify it.

1. The second request from payor to provides is called "Communication request". Is that an Acknowledgement to the first Claim Request? or its subsequent queries from payor to Providers for additional information.
2. Are these communication request based out of FHIR objects or they are HCX custom API?

[abhimail]

Hi @vharish85,

CommunicationRequest is an additional cycle that is intended to be used to seek additional information on an existing main cycle (eligibility check, preach, claim etc.). Communication request/response cycle is linked to the main cycle by using same correlation_id as the main cycle. HCX is expected to reject a communication request that is not in context of an existing valid main cycle.

A communication request call basically sends the details of the ask using CommunicationRequest FHIR profile and the receiver is expected to respond with response callback containing Communication profile in the response.

Hope this helps! Kindly feel free to request further details.