Guidelines for Participant Onboarding
Process of onboarding network participants
Last updated
Process of onboarding network participants
Last updated
While the actual onboarding/deboarding process for an HCX ecosystem would be drafted by its operator and agreed upon by its participants, this section outlines key design guidelines and an overall approach to arrive at such a policy.
Building further from the key design considerations laid out for business policies in the HCX open specifications, the onboarding approach should:
Aim to enable rather than control the participation of the interested ecosystem actors.
Require minimal and necessary information, enough to prove the identity of the participant and enable working of the network. The process requirements should be non-discriminatory and at the same time requrie enough detail to keep out any frivolous organizations.
Needs to be simple and cost effective enough to encourage participation of entities working with low income segments.
A list of different kinds of participants who would need onboarding into an HCX registry is provided in the Access Control section above. Onboarding onto the HCX is envisioned as a two step process:
Sandbox - for compliance testing and certification
Go Live on live instances
Diagrams below depicts the key steps in onboarding process across these two phases:Proposed onbaording process flowSections below provide high level description for each of these steps:
Sections below provide high level description for each of these steps:
The key goal of the sandbox is to help the participants test their software against the HCX protocol, and get certified to ensure interoperability and gain required trust by the other network participants.
All participants including the HCX instance(s) and its participants are expected to go through certifications to ensure adherence/compliance to the specifications. However, as indicated later, the mode of compliance may vary based on the role of the participant. Compliance step would include:
Technical Compliance checks - API schema conformance, Security specification (Transport layer, API security, Message security) conformance
Domain Compliance checks - Payload schema conformance, Terminology compliance, Publication of extended terminologies
Process Compliance checks - Adherence to strategy/ approach/ guidelines/ recommendations on business policies
Sandbox testing environment shall publish a set of test cases (test suite) for each type/role of the participant (payer, provider, etc.). It will require applicants to send a series of messages as defined in the test cases to the Sandbox. The system will analyze the messages received and mark the test as pass or fail as per the requirement of the test case. The sandbox system will provide a list of all messages and their testing status.
The Sandbox environment(s) shall also include documentation and suggestions regarding the software libraries, tools and example implementations for encryption, FHIR resource generation, code generation and other new/complex parts of the HCX protocol. The sandbox portal would ensure that the participants are provided with all the necessary help to get started and complete the API integration.
Based on affiliate HCX policies, the sandbox may necessitate additional security testing and reviews like STQC or CERT-IN. Suggestive pointers on infrastructural requirements for security testing clearance can be found in this document.
Key steps for sandbox certification process would be:
The participants submit an online application to express their interest to access the chosen HCX sandbox. Sandbox registration/verification process is expected to be simpler than the production process to encourage newer ecosystem actors to try the benefits of the network.
Once sandbox registration requirements are met, the participant id along with the sandbox access secret credentials will be provided. Participants are expected to keep the secret credentials safe and report any compromises at the earliest to the Sandbox operator.
In this step, the participants integrate their respective claim processing platform applications with the sandbox HCX. This step could be done by software providers on behalf of their customers. This is a one time event/requirement from the solution provider, once they have tested and certified on the sandbox, the same solution can be utilized by multiple payers/providers willing to utilize HCX services.
In this step, the sandbox provider reviews the results of respective test cases and provides necessary feedback to the participant till the compliance is achieved.
Since HCX design principles demand complete security and privacy of the data exchanged safeguarding the personal information of the beneficiaries, it is critical to assess the security & privacy measures a solution provider has implemented. For this, the solution provider either can get a security compliance certificate from an entity like STQC or any other authorized SIs. The solution provider will be required to submit the certificate as a proof to the HCS operator sandbox committee to get a go ahead on access to the production APIs.
On successful review, the sandbox will issue a successful completion certificate valid for a configured period of time. This certificate can be used by the participant to get onboarded to the production environments of the HCX operators.​
Once a participant successfully completes the sandbox process, they can use the certification to get onboarded to the HCX production environment and production access keys will be shared with the solution provider that can be used to integrate with the production APIs.
HCX operator(s) may nominate or list Sandbox operator(s) whose certification will be considered valid for onboarding to their platforms.
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:
In this step, HCX operator validates the sandbox certificate for applicability (whether it allows for certification from the sandbox provider) and validity.
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:
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.
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
Option to complete the NDHM HFR process and use the resultant credentials.
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
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
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
Facility is empanelled with a Government/public health scheme but is neither registered in HFR nor ROHININote-This is a special use case wherein only the public/state health scheme can verify that the requesting facility is empanalled with them and approve the onboarding​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 to verify if the requesting facility is empanelled with them or not
3.Empanelment details- Empanelment ID, attachment of signed contract with the said payer/scheme details, latest transaction with the said payer/scheme, contract validity & status
Regulators like IRDA, NHA, IIB or state regulators
agency.regulator
Will be worked on a case to case basis based on need.
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.
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.
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.
This section lists some of the deboarding scenarios that may be considered as part of the final deboarding policies by the HCX operators:
Involuntary deboarding of a participant initiated by Regulator/Legal Authority. Few examples:
Suspension/Deactivation of a provider by a regulator for fraudulent activity.
Suspension/Deactivation of a TPA or a Payer by IRDA
Involuntary deboarding of a participant (mostly TSPs) initiated by HCX. Few cases:
Serious violation of HCX policies (e.g. grave SLA violation repeatedly)
Hacking attempts made by participants for unauthorized access, after an investigation by HCX
Bad or irresponsible behaviour from participants if it significantly impacts the stability and performance of the HCX (like frequent bursts of requests beyond authorised rate limits).
Voluntary deboarding of participants. Few examples:
A provider or payer shifting to another HCX
A provider or payer shuts down their business
A provider or payer merges with another entity listed on the exchange
Please note that while the above list suggests a few of the scenarios for potential deboarding of a participant, this process should be treated with utmost care and an elaborate warning mechanism should be kept in place whenever the deboarding is not voluntary.
In addition, to provide a fair chance of appeal, the grievance redressal process on HCX is expected to provide grievance mechanisms to handle appeal against deboarding of a participant.
Building on the earlier work on these guidelines, this section now provides recommended approach for HCX onbaording. In future there may be further work on:
Inclusion of new type of members in HCX network and their respective verification processes.
Evolution of verification process for curently defined participants
Recommendations on ways to automate and simplify the onbaording process
