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

Guidelines for SLAs and ecosystem satisfaction

Key considerations for ecosystem satisfaction with the HCX network

Best practices for service SLAs for high volume transactions already exist as high volume exchanges have been around for many decades, and so has regulation for such exchanges (for example the stock exchanges, depositories and SEBI). It is recommended that the HCX adopts the SLAs currently in operation and publicly available from the likes of National Stock Exchange and NSDL/CSDL.

HCX Operator should provider following SLAs in their agreements with the participants:

  • Uptime

  • Response times for transactions

  • Operation of Sandbox

  • Operation of helpdesk

  • Upgrade of software as per the latest specifications of HCX.while keeping backward compatibility

  • Data protection

An HCX operator may not be able to impose SLAs on participants like payers, providers, or TPAs, as HCX has no control over these players. However, to improve the overall performance of the ecosystem, the HCX Operator could publish the following metrics on a periodic basis:

  • Average time for sandbox registration to sandbox certification by participant type

  • Average time for claim submission from patient discharge by providers

  • Average time for response from payor to providers for each applicabkle cycle (eligibility, predetermination, preauth, claim)

  • Average time for claim to cash by payor

  • Average time for response from providers for payor queries

PreviousNext stepsNextGuidelines for Operating charges

Last updated 2 years ago

Was this helpful?