A thriving data exchange requires clear rules of engagement on various activities in the data exchange to ensure trust from all actors. The key list of policy candidates to be addressed is:
Onboarding
Defaulting/Deboarding policies
Dispute resolution policies
Access control (Data sharing) policies - which actor plays what role and gets to see which parts of data. These policies will then affect the visibility and access to domain specific attributes that will typically travel in the body of the data structures defined by the data exchange.
Business SLAs
Charges and fees - These would be policies around charges various data exchange entities will be allowed to levy on others depending on the role they play
Service rating policies - What would be the parameters and mechanisms to rate each type of actor on the data exchange.
The success of the data exchange will depend on trust and willing participation from its ecosystem players. Therefore, to ensure the success of the claims data exchange, its governing policies need to focus on enabling the ecosystem and gaining its trust. To ensure this, the following key policy design guidelines are recommended:
Policies should focus on enabling the ecosystem rather than monitoring or controlling it
Policy formulation should be done as an open consultative process to foster trust in policies
Rules of participation and disqualification should be transparently laid out
They should follow the principle of minimalism and be evolved over a period of time
Keeping these guidelines in mind, the following key policies guidelines are provided for the purpose of wider consultation as part of version 1:
Access control (Roles)
Participant onboarding/deboarding
Grievance redressal
Event Audit
All events (claim request created, claim forwarded, data requested, authorisation, payment, etc) in the claims flow and corresponding system requests and responses between Provider TMS/Beneficiary apps, HCPs, and Payer TMS must be digitally signed and logged to ensure immutability, non-tamperability, and non-repudiability.
The HCX needs to persist the logs for a configurable (as prescribed by the law of the land) period of time so that they can be retrieved when necessary and this audit trail must be made transparently available to the customer. To ensure integrity, logs should be append-only and should not be allowed to be edited.
This section proposes a high-level approach that can be adopted for event audit policies for an HCX ecosystem. More deliberation is needed to arrive at model policies that can then be readily extended to be adopted by the ecosystem. Domain working groups will continue to work on developing a detailed approach for event audit policy formulation as well as a model policy for easy adoption. These documents will be released for public consultation in time for an initial pilot of the HCX ecosystem.
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.
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
Sections below provide high level guidelines for each of these steps.
The key goal of the sandbox is to help the ecosystem test its specific components against the communication standards, and get certified to become a part of the system. Once a participant successfully completes the sandbox process, they can use the certification to get onboarded to the HCX production environment with the necessary access.
HCX operator(s) may nominate or list Sandbox operator(s) whose certification will be considered valid for onboarding to their platforms.
The following are the steps to integrate, test and launch with the help of sandbox.
Step 1: Registration
The participants submit an online application to express their interest to access the HCX sandbox. The requests from different participants are verified to see if the participant is eligible to participate in the sandbox environment by doing basic checks against the details provided in the application form. Details of the model application form for various roles will be developed in the upcoming phase of the specifications.
There may be requests that would not satisfy the conditions required for the sandbox access such as multiple requests from the same participant, participants not registered with any registry, TSPs without a valid website, spam applications, etc., which would prove to be redundant and may have to be filtered. This process would be semi-manual.
On successful verification, the approved participants are added to the HCX sandbox and provisioned with the necessary credentials to access the sandbox environment.
Step 2: API integration and testing
In this step, the participants integrate their respective claim processing applications with the sandbox HCX. This is to aid the developments as well as ensure that their applications are compliant with the HCX standards and build all the missing pieces on their side to use the set of HCX APIs necessary for their planned workflows.
Sandbox website would 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.
Step 3: Sandbox certification
All participants are expected to fulfil a set of functional and security tests/flows applicable to them.
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.
Once the system is ready and tested against the applicable test cases, the participant will be required to submit their test results including the application's usage of and interaction with HCX APIs to the Sandbox Operator for review and approval.
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.
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: Registration on HCX
In this step, interested participants will be required to go through the onboarding 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.
Summary details of the HCX application duly filled. This application form will be more detailed, requiring more details of the participant including contact numbers, company registration details, and other details as needed in the HCX registry.
Step 2: Review of Sandbox certification
A final round of approval for application go-live will be sought from the internal team at HCX. Applicants will be required to share Functional and security testing certificates issued by the affiliate sandbox environment.
Step 3: 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.
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.
This section proposes a high-level approach that can be adopted for onboarding/deboarding policies for an HCX ecosystem. More deliberation is needed to arrive at model policies that can then be readily extended to be adopted by the ecosystem. Domain working groups will continue to work on developing a detailed approach for onboarding/deboarding policy formulation as well as a model policy for easy adoption. These documents will be released for public consultation in time for an initial pilot of the HCX ecosystem.
While the working groups will further deliberate on details, according to you what should be the mechanism of the certification on the network? Who all can be the certifying authorities?
How do you suggest verifying the identity and authenticity of various participants in the exchange (like facilities, payers), owing to the fact that the national level registries - HFR and HPR - are not complete, but only include the providers and facilities in the places where it is piloted (UTs)? What is your point of view on these registries, once complete, be the only mechanism for verification?
Instructions to send responses to the consultation questions are available here.
Authentication of beneficiaries by providers on provider TMS/beneficiary APP.
The Provider TMS system will support Aadhar eKYC open API integration for beneficiary authentication using Aadhar. All the govt schemes and most of the private providers may use Aadhar based KYC process for verification of the beneficiary in their TMS system.
Authentication of beneficiaries by providers on provider TMS/beneficiary APP
The Provider TMS system will use Aadhaar based authentication (Aadhar integrated Mobile OTP based authentication, biometric based authentication) for authentication of a beneficiary to initiate the claim transaction in the provider TMS system. All provider systems that are enrolled with NDHM will have biometric devices for validation and creation of the health ID.
The payer TMS system and HCP will integrate the Aadhar authentication open API for verification of the beneficiary ID during the claim validation stage.
Authentication of beneficiaries by providers on provider TMS/beneficiary APP
The providers and payers may choose to integrate different open APIs in their TMS systems to validate the beneficiary ID based on verifiable Government identity database lookup (e.g. PAN, Ration Card, Passport etc.) as well as any other mechanism to verify the beneficiary credentials during enrollment of beneficiary in their systems and validate the beneficiary ID during claim processing
In this case, the payer issues a token (e.g., an OTP) to the customer, which the customer then supplies to the provider for subsequent forwarding back to the payer. This provides a confirmation to the payer that the customer has approved the claim request.
The payer authenticates the customer by directly interacting with him. For example, the payer sends a message with an OTP and a URL to the beneficiary’s phone. The beneficiary clicks on the URL. The payer displays the beneficiary’s photo and some basic details of the claim (e.g. diagnosis, treatment planned and sum claimed). The beneficiary either rejects the claim or approves it.
This section proposes a high-level approach that can be adopted for beneficiary authentication policies for an HCX ecosystem. More deliberation is needed to arrive at model policies that can then be readily extended to be adopted by the ecosystem. Domain working groups will continue to work on developing a detailed approach for beneficiary authentication guidelines for easy adoption. These documents will be released for public consultation in time for an initial pilot of the HCX ecosystem.
Final operational policies for grievance redressal are expected to be drafted by the HCX operators as these may change over time based on the need of the ecosystem and use cases under consideration. However, to make the policies consistent and effective, the following key grievance policy design guidelines are proposed:
Each HCX operator must publish a dispute/grievance resolution policy to allow digital initiation, routing and tracking of the grievances of any of the participants.
The policy should clearly list out all the grievances that would be addressed under it and mechanism to resolve grievances that are not covered under it.
The policy should require all participating actors to set up nodal governance bodies contactable at the digital and physical communication mechanisms provided as part of onboarding. These communication details are made available to all participants using the read access to the registry.
As part of the participant registry, the HCX instance also publishes the details of its governance body.
The policy should publish the types and priority of the grievances handled by each type/role of the participant including any required as per prevailing regulations.
The policy should publish SLA for each grievance type including any required as per prevailing regulations.
The policy should be versioned, required to be signed by new members at the time of onboarding and any change has to be proactively informed to all existing network participants.
The policy should require ample due diligence cycle to address the grievance and review the redressal before responding back to the requester
The policy should allow for the reopening of the grievances
The policy should allow for escalation to the network operator in case the requestor does not feel satisfied with the resolution. Escalated grievances should follow accelerated timelines for resolution.
The policy should clearly layout review and resolution criteria for a grievance to be escalated and the approach the operator would take to reach a resolution.
The policy should include ways of keeping requesters informed about the latest status and any additional requirements to help address the grievance.
Like with the specifications so far, constitute a new working group for Dispute Resolution policies.
The working group drafts a model policy in accordance with the above principles and in line with the detailed approach from step 2 above.
The principles, detailed approach and model dispute resolution policy draft is versioned and released for public consultation.
The domain working group deliberates the feedback and enhances principles/model policy as needed.
HCX Operators adopt the model policy according to the needs of their network
Further enhancements, e.g. for new use cases, changes in approach, improvements in model policy due to on-ground observations undergo steps 3-6 and result in a newer version of the artefacts (principles, approach or model policy).
This section proposes a high-level approach that can be adopted for grievance redressal policies for an HCX ecosystem. More deliberation is needed to arrive at model policies that can then be readily extended to be adopted by the ecosystem. Domain working groups will continue to work on developing a detailed approach for grievance redressal policy formulation as well as a model policy for easy adoption. These documents will be released for public consultation in time for an initial pilot of the HCX ecosystem.
Beyond what’s being proposed as a guideline, what areas and roles do you think HCX as the data exchange gateway should play in grievance redressal?
While the working groups will further deliberate on details, according to you what should be the mechanism of the grievance redressal on the network? What should be the key grievances that need to be honored between network participants? How should escalations work?
While the actual grievance redressal policy 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. These guidelines and approach are aligned with earlier thinking from IRDAI in its publication , however, these are now envisioned to cover grievance from any actor of the ecosystem with respect to other actors.
Drafting and evolving an efficient and truly implementable policy for grievance resolution would need active participation from the HCX ecosystem. Keeping this in mind, the following high level approach is proposed in line with the overall :
The working group contextualises and adopts the open specifications design principles and high level approach as detailed in for the dispute resolution context.
Instructions to send responses to the consultation questions are available .
Participating systems in the Claims information exchange ecosystem may possess one or more of the following roles. These roles are based on the base set of organisation roles defined in hl7 specifications here. Namespaced coding is used to further qualify the role in the context of the claims exchange process.
provider: Health Service Provider
payer: Insurance service provider
agency.tpa: Third party administrator acting on behalf of the payer. In the current version, this role is expected to behave like a payer from the data exchange perspective.
agency.regulator: IRDAI and IIB like regulatory bodies.
research: Research groups, etc.
member.isnp: eCommerce platforms facilitating insurance adoption
agency.sponsor: Scheme owners of specific programs, e.g. NHA for Ayushman Bharat
HIE/HIO.HCX: Other HCXs
The following table further describes these roles for their corresponding access rights and scenarios for version 1 of the claims exchange process:
The primary stakeholders/roles in the HCX ecosystem are mentioned in the section Access Control. Are there any other primary or secondary stakeholders that should be considered as HCX participants? If yes, please outline their role in the HCX ecosystem.
This section also mentioned allowed actions for the current set of stakeholders, please review these actions and suggest any changes needed for those actors.
Instructions to send responses to the consultation questions are available here.
Role
Allowed actions
Comments
provider
Eligibility check
Send request
Receive response
Pre Auth
Send request
Receive response
Claims request
Send request
Receive response
Payment
Receive notice
Send Acknowledgement
Search/Status
Pre auth
Claims status
Providers can make search/status requests for multiple requests that originated from them.
payer/
agency.tpa
Eligibility check
Receive request
Send response
Pre Auth
Receive request
Send response
Claims request
Receive request
Send response
Payment
Send notice
Receive Acknowledgement
Search/Status
Payment confirmation
Payers can make search/status requests for multiple payment notices that originated from them.
agency.regulator
Search
Claims
Data exchange switch will forward the search request to all payers who are expected to return the claims data in the proposed FHIR structure as per regulator’s policies.
research
Eligibility check
Receive request
Send response
Search
Pre Auths - aggregate and/or anonymised
Claims - aggregate and/or anonymised
All data exhausts for these roles would only have aggregate and anonymised data. Key aggregations for eligibility requests, preauthentication, claims and payments information will need to be further defined.
member.isnp
Eligibility check
Receive request
Send response
Search
Pre Auths - aggregate and/or anonymised
Claims - aggregate and/or anonymised
Claims - Individual claims data as per beneficiary consent
As facilitators of insurance eCommerce, it is proposed to provide ISNPs access to the data available to research role as well as individual beneficiary queries (preauth, claims) based on beneficiary consent. This consent flow is expected to work with existing consent management infrastructure and ISNPs are expected to submit the acquired consent as part of the domain header.
agency.sponsor
As planners of the insurance schemes, sponsors are proposed to be given access equivalent to payer role.
HIE/HIO.HCX
As an HCX this participant is expected to play different roles as per the need of the use case. However, due to the data privacy and security measures prescribed in the Open Protocol, it will not be able to view the actual payload.