HCX Protocol
v0.8
v0.8
  • Summary
  • Context
  • Introduction to HCX
  • Approach
    • Design Principles
    • Key Specifications
    • Governance
  • Technical Specifications
    • Open Protocol
      • Registries
      • Claims Data Exchange (HCX) Protocol
        • Exchange Protocol
        • Message Structure
        • API Structure
        • Error Handling
      • Data Security and Privacy
        • Transport Security
        • Message Security and Integrity
        • API Security
      • Audit and Reporting
      • Notifications
        • Terminology
        • Categories
        • API specifications
        • List of key topics
        • Future considerations
      • Third party Information sharing
    • Digital Network Policies
  • Domain Specifications
    • Domain Data Models
      • Handling Attachments
      • Handling Processing Errors
    • Terminologies (Code sets or Metadata standards)
    • Domain Specific Languages (DSLs)
    • Implementation Guide
  • Business Policy Specifications
    • Access Control (Roles)
    • Guidelines for Participant Onboarding
    • 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
  • Contributing to the specifications
  • Future Roadmap
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. Business Policy Specifications

Access Control (Roles)

Roles on Health Claims Exchange

PreviousBusiness Policy SpecificationsNextGuidelines for Participant Onboarding

Last updated 2 years ago

Was this helpful?

Participating systems in the Claims information exchange ecosystem may possess one or more of the following roles. These roles are based on the base set of organisation roles defined in hl7 specifications . Namespaced coding is used to further qualify the role in the context of the claims exchange process.

  1. provider: Health Service Provider

  2. payer: Insurance service provider

  3. agency.tpa: Third party administrator acting on behalf of the payer. In the current version, this role is expected to behave like a payer from the data exchange perspective.

  4. agency.regulator: IRDAI and IIB like regulatory bodies.

  5. research: Research groups, etc.

  6. member.isnp: eCommerce platforms facilitating insurance adoption

  7. agency.sponsor: Scheme owners of specific programs, e.g. NHA for Ayushman Bharat

  8. HIE/HIO.HCX: Other HCXs

The following table shows typical scenarios and actions for the claims exchange process:

Role

Allowed actions

Comments

provider

  1. Eligibility check

    1. Send request

    2. Receive response

  2. Pre Auth

    1. Send request

    2. Receive response

  3. Claims request

    1. Send request

    2. Receive response

  4. Payment

    1. Receive notice

    2. Send Acknowledgement

  5. Communication Request

    1. Recieve request

    2. Send response

  6. Status

    1. Make request

    2. Recieve response

Providers can make search/status requests for multiple requests that originated from them.

payer/

agency.tpa

  1. Eligibility check

    1. Receive request

    2. Send response

  2. Pre Auth

    1. Receive request

    2. Send response

  3. Claims request

    1. Receive request

    2. Send response

  4. Payment

    1. Send notice

    2. Receive Acknowledgement

  5. Communication Request

    1. Send request

    2. Receive response

  6. Status

    1. Receive request

    2. Send response

  7. EoB

    1. Receive request

    2. Send response

In case of "forward" payers/TPAs may also originate requets like coverage eligibility, pre auth and Claims to the party being forwarded.

agency.regulator

  1. Fetch

    1. EoB

  2. Notifications

    1. Send

    2. Receive

Regulator would be able to raise fetch requests for Form 15C equivalent EoB, receive notifications as agreed with payers, and send certain category/type of notifications.

research

  1. Eligibility check

    1. Receive request

    2. Send response

  2. Fetch

    1. EoB

    2. Anonymised Data aggregates

  3. Notifications

    1. Send

    2. Receive

All data exhausts for these roles would only have aggregate and anonymised data. Key aggregations for eligibility requests, preauthentication, claims and payments information will need to be further defined.

member.isnp

  1. Eligibility check

    1. Receive request

    2. Send response

  2. Fetch

    1. EoBs - For patient information

    2. Claims - Individual claims data as per beneficiary consent

As facilitators of insurance eCommerce, it is proposed to provide ISNPs access to the data available to research role as well as individual beneficiary queries (preauth, claims) based on beneficiary capabilities consent. This consent flow is expected to work with existing consent management infrastructure and ISNPs are expected to submit the acquired consent as part of the domain header.

agency.sponsor

As planners of the insurance schemes, sponsors are proposed to be given access equivalent to payer role.

HIE/HIO.HCX

As an HCX this participant is expected to play different roles as per the need of the use case. However, due to the data privacy and security measures prescribed in the Open Protocol, it will not be able to view the actual payload.

here