HCX Protocol
v0.9
v0.6v0.7v0.8v0.7.1v0.9
v0.9
v0.6v0.7v0.8v0.7.1v0.9
  • Summary*
  • Glossary*
  • Context
  • Introduction to HCX*
  • Technical Specifications
    • Open Protocol
      • Registries*
        • QR Code Specifications*
      • Claims Data Exchange (HCX) Protocol
        • Message Flows*
          • Primary Message Flow
          • Additional Message Flows
            • Redirect
            • Forward
            • Intra Cycle Communication*
              • Seeking Supporting Information
              • Seeking Beneficiary Consent
              • Seeking Account Information
            • Relay
            • Third party Information sharing
          • Notifications
            • Categories
            • List of key topics
        • Message Structure
        • API Specifications*
          • Registry APIs
          • Primary Flow APIs
          • Supporting APIs
          • Notification APIs
        • Error Handling
      • Data Security and Privacy
        • Transport Security
        • Message Security and Integrity
        • API Security*
      • Audit and Reporting
    • Digital Network Policies
  • Domain Specifications
    • Domain Data Models
      • Handling Attachments
      • Handling Processing Errors
    • Terminologies
    • Domain Specific Languages (DSLs)
    • FHIR Implementation Guide*
  • Business Policy Specifications
    • Access Control (Roles)*
    • Guidelines for Participant Onboarding*
      • Sandbox process
      • Production onboarding (Go live)*
      • Potential De-boarding scenarios
    • Guidelines for Grievance Redressal
      • Scope of disputes
      • Involved participants
      • Guideline process for dispute resolution
      • Guidelines for leveraging FTA
      • Next steps
    • Guidelines for SLAs and ecosystem satisfaction
    • Guidelines for Operating charges
    • Guidelines for Beneficiary Authentication by Providers/Payors
    • Guidelines for Event audits
    • Reference Templates
      • HCX - Terms of use
      • Payer-Provider addendum
      • Payer-Policyholder addendum
    • Next steps
  • Use cases*
    • OPD
      • Typical Workflows
        • Cashless
        • Reimbursement
      • Mapping to the HCX protocol
        • Cashless
        • Reimbursement
    • IPD
      • Typical Workflows
        • Cashless
        • Reimbursement
      • Mapping to the HCX protocol
        • Cashless
        • Reimbursement
    • Implementation Considerations
  • Contributing to the protocol
  • Future Focus Areas*
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. Technical Specifications
  2. Open Protocol
  3. Claims Data Exchange (HCX) Protocol
  4. Message Flows*

Primary Message Flow

Details of the key data exchange flow on HCX

PreviousMessage Flows*NextAdditional Message Flows

Last updated 1 year ago

Was this helpful?

HCX protocol is designed for the exchanges to work in an asynchronous manner (like SMTP), therefore each use case will be completed in a cycle of messages as detailed below:

Sender to HCX (Leg 1)

  • The sender (originator of the communication) sends the initial message to its preferred HCX instance.

  • HCX validates the status of the sender and the next intended recipient (maybe another HCX instance) on its registries.

  • HCX then performs required signature verifications etc before responding with an acknowledgement to the sender.

  • It then forwards it to either the end recipient (if registered with the same instance) or the next HCX in the chain.

Steps 1 and 7 in the above diagram are examples of this leg.

HCX to Receiver (Leg 2)

  • Final HCX in the relay chain (could be the original HCX itself) checks the status of the recipient on its registries,

  • performs needed verifications and forwards the message to the recipient.

  • The recipient acknowledges the receipt of the message.

Steps 3 and 9 in the above diagram are examples of this leg.

Receiver to HCX (Leg 3)

  • The recipient (receiver of the original request message) sends the response message to its preferred HCX instance.

  • HCX validates the status of the recipient and original sender (maybe another HCX instance) on its registries.

  • HCX then performs required signature verifications etc before responding with an acknowledgement to the recipient.

  • It then forwards it to either the initial sender (if registered with the same instance) or the next HCX in the chain.

Steps 4 and 10 in the above diagram are examples of this leg.

HCX to Sender (Leg 4)

  • Final HCX in the relay chain (could be the original HCX itself) checks the status of the original sender on its registries,

  • Performs needed verifications and forwards the response message to the sender.

  • The sender acknowledges the receipt of the response message.

Steps 6 and 12 in the above diagram are examples of this leg.

Following subsections will provide details about the alternate flows facilitated by HCX.

As indicated in the , the exchange platform will be the routing engine that will be responsible for receiving the data from either participant (provider, payor, another HCX instance, ...), performing necessary validations, and forwarding it to the intended recipients.

overall message flow diagram