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. Business Policy Specifications
  2. Guidelines for Participant Onboarding*

Production onboarding (Go live)*

Recommendations for onboarding onto live network

After obtaining the affiliated sandbox certification, the participant would have to apply for onboarding into the HCX production environment. This process will consist of the following key steps:

Step 1: Validate sandbox certificate

In this step, HCX operator validates the sandbox certificate for applicability (whether it allows for certification from the sandbox provider) and validity.

Step 2: Registration on HCX

In this step, interested participants will be required to go through the onboarding verification process with the HCX. HCX operators are expected to provide a choice of registration flows with the following high level guidelines:

  1. If the participants are registered in the NDHM Health Facility registry, then they should be allowed to use HFR authentication as a means to register in the HCX registry, if they choose to do so.

  2. If the participants are not registered in the NDHM Health facility registry then the participant should be allowed to use alternate means of verification like

    1. Option to complete the NDHM HFR process and use the resultant credentials.

    2. Authentication/Certificates/documents from IRDA or equivalent such agency identified and clearly stated in HCX’s onboarding policy. Proposed list of documents/requirements needed for such an on-boarding based on type of participant are as follows:

    ​

    Payers

    Payer

    Verification Details:

    1. Letter from authorized signatory of the company seeking participation

    2. IRDA registration Number/license number,

    3. IRDA User ID

    4. Registered email id,

    5. System admin details for OTP authentication

    State schemes

    agency.sponsor

    Verification Details:

    1. Government licence/approval letter

    2. Letter from authorized signatory of the company seeking participation

    3. Registered email id,

    4. System admin details for OTP authentication

    Corporates paying for their employees

    agency.sponsor

    Verification Details:

    1. Letter from authorized signatory of the company seeking participation

    2. Registered email id,

    3. System admin details for OTP authentication

    TPAs

    agency.tpa

    Verification Details:

    1. Letter from authorized signatory of the company seeking participation

    2. IRDA registration Number/license number,

    3. IRDA User ID

    4. Registered email id

    5. System admin details for OTP authentication

    HIUs (like TSPs, ISNPs) and other user intermediaries

    member.isnp

    Verification Details:

    1. Letter from authorized signatory of the company seeking participation

    2. Registered email id,

    3. System admin details for OTP authentication

    4. IRDA registration Number/license number (if applicable)

    5. IRDA User ID (if applicable)

    ABDM enrolled Providers

    provider (provider.hospital, provider.clinic, provider.practitioner, provider.diagnostics, provider.pharmacy)

    Verification Details:

    1. HFR ID & Role/type

    2. Verification status,

    3. Registered manager’s HFR ID, mobile number & email ID as per HFR for OTP based authentication and intimation about the HCX onboarding attempt for approval

    4. An automated lookup API to check the authenticity and availability of the HFR ID in the ABDM registry

    5. Fetch api with consent from the facility manager to pull facility details from HFR

    6. ABDM credentials (API based check) via HFR and HPR integration

    7. For facilities - HFR ID & OTP auth can work

    8. For doctors and other health professionals HPR ID with OTP auth or API check can work

    Non ABDM enrolled Providers with ROHINI Id

    provider (provider.hospital, provider.clinic, provider.practitioner, provider.diagnostics, provider.pharmacy)

    Verification Details:

    1. Facility details- Name, License , validity, GSTN etc

    2. ROHINI ID

    3. Mechanism to verify the submitted details with ROHINI database (lookup or manual verification by ROHINI admin)

    Non ABDM enrolled Providers with no ROHINI id

    provider (provider.hospital, provider.clinic, provider.practitioner, provider.diagnostics, provider.pharmacy)

    Facility is empanelled with a Government/public health scheme but is neither registered in HFR nor ROHINI

    Verification Details:

    1. Facility details - Name, License, facility manager details, location address

    2. Payer ID/Name/name of the scheme that has empanelled the registering provider (This will trigger approval email/notification to the scheme authority/state authority/payer to verify if the requesting facility is empanelled with them or not

    3. Empanelment proof - Either a copy of physical proofs such as Empanelment ID, attachment of signed contract with the said payer/scheme details, latest transaction with the said payer/scheme, contract validity & status, or a digitally signed proof from the payer/scheme.

    Regulators like IRDA, NHA, IIB or state regulators

    agency.regulator

    Will be worked on a case to case basis based on need.

    Beneficiary facing platforms

    BSP

    Considering that BSPs' onboarding primarily revolves around compliance with HCX specifications (with data security and privacy aspects covered by protocol measures as mentioned in the note below), a simple onboarding process is recommended to facilitate and encourage participation from these beneficiary-facing entities.

    Verification details:

    1. Name

    2. Email

    3. Mobile no.

    4. GSTN

    5. Registered Address proof

    6. Stakeholder serviced (Policyholder for now)

    7. Compliance certification from the sandbox environment

Addressing data privacy and security on BSP platforms - The HCX protocol necessiate that user/citizen-facing platforms can only assume BSP role with the explicit consent of the beneficiary. The protocol specifies following mechanism and event points for seeking consent:

  2. OPD reimbursement proposed workflow section here.

  3. IPD reimbursement proposed section workflow here.

Step 3: Gather HCX related details

In this step, the operator gathers more details of the participant including contact numbers, company registration details, and other details as needed in the HCX registry.

Step 4: Provisioning of production credentials

Once these requirements are met, the participant id along with the production access secret credentials will be provided. Participants are expected to keep the secret credentials safe and report any compromises at the earliest to the HCX operators.

Step 4: Go-Live

The application is now expected to be prepared for go-live in respective participant ends. All the participants are advised to plan the change management at their end and conduct necessary training for their staff before going live in production HCX, preferably after piloting with a small set of clients.

PreviousSandbox processNextPotential De-boarding scenarios

Last updated 1 year ago

Was this helpful?

Consent requirement for tracking the claims - Please see “Subscription Mechanism” section under .

Workflow notification