HCX Protocol
v0.9
Search
K

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. 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. 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. 1.
      Option to complete the NDHM HFR process and use the resultant credentials.
    2. 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. 1.
      Letter from authorized signatory of the company seeking participation
    2. 2.
      IRDA registration Number/license number,
    3. 3.
      IRDA User ID
    4. 4.
      Registered email id,
    5. 5.
      System admin details for OTP authentication
    State schemes
    agency.sponsor
    Verification Details:
    1. 1.
      Government licence/approval letter
    2. 2.
      Letter from authorized signatory of the company seeking participation
    3. 3.
      Registered email id,
    4. 4.
      System admin details for OTP authentication
    Corporates paying for their employees
    agency.sponsor
    Verification Details:
    1. 1.
      Letter from authorized signatory of the company seeking participation
    2. 2.
      Registered email id,
    3. 3.
      System admin details for OTP authentication
    TPAs
    agency.tpa
    Verification Details:
    1. 1.
      Letter from authorized signatory of the company seeking participation
    2. 2.
      IRDA registration Number/license number,
    3. 3.
      IRDA User ID
    4. 4.
      Registered email id
    5. 5.
      System admin details for OTP authentication
    HIUs (like TSPs, ISNPs) and other user intermediaries
    member.isnp
    Verification Details:
    1. 1.
      Letter from authorized signatory of the company seeking participation
    2. 2.
      Registered email id,
    3. 3.
      System admin details for OTP authentication
    4. 4.
      IRDA registration Number/license number (if applicable)
    5. 5.
      IRDA User ID (if applicable)
    ABDM enrolled Providers
    provider (provider.hospital, provider.clinic, provider.practitioner, provider.diagnostics, provider.pharmacy)
    Verification Details:
    1. 1.
      HFR ID & Role/type
    2. 2.
      Verification status,
    3. 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. 4.
      An automated lookup API to check the authenticity and availability of the HFR ID in the ABDM registry
    5. 5.
      Fetch api with consent from the facility manager to pull facility details from HFR
    6. 6.
      ABDM credentials (API based check) via HFR and HPR integration
    7. 7.
      For facilities - HFR ID & OTP auth can work
    8. 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. 1.
      Facility details- Name, License , validity, GSTN etc
    2. 2.
      ROHINI ID
    3. 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. 1.
      Facility details - Name, License, facility manager details, location address
    2. 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. 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. 1.
      Name
    2. 2.
      Email
    3. 3.
      Mobile no.
    4. 4.
      GSTN
    5. 5.
      Registered Address proof
    6. 6.
      Stakeholder serviced (Policyholder for now)
    7. 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:
  1. 1.
    Consent requirement for tracking the claims - Please see “Subscription Mechanism” section under Workflow notification.
  2. 2.
    OPD reimbursement proposed workflow section here.
  3. 3.
    IPD reimbursement proposed section workflow here.
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.