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

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.