This section focuses on business specifications needed to realize the health claims data exchange - Domain Data Specifications and domain policies.

Details of Open Protocol and TechOps policies are covered in the previous section.

The most significant aspect of domain specification would be agreement on formats for data exchange and terminologies (taxonomies) being used in those data models. These would mainly include:

1. Domain data model - Schema definition of domain entities like Claims, Providers, Payors, Policies, etc. Please note that based on available DSLs some of these data models may be flexible, e.g. policy schema if Policy Markup Language (PML) is available.

2. Metadata specifications - Metadata is data about data, data associated with an object, a document, or a dataset for purposes of description, administration, technical functionality, and preservation. For the context of claims, this would mainly involve coding systems and suggested values for key claim attributes like disease codes, procedure codes, diagnostic codes, billing-related codes (e.g. room rent, ICU charges, etc.), etc.

3. Domain Specific Language(s) - Usually known as DSL, these may be developed When the attributes of the entity are variable from use case to use case but need to adhere to some common constraints/characteristics like types of data element it can contain, the relationship between two data elements, number of occurrences of data elements, etc. Examples of such entities within a claims data exchange would be policies, bills, contracts. In such cases, defining a markup language (DSL) rather than the entity itself allows needed flexibility to the ecosystem to innovate on such entities. These can be thought of like HTML, where multiple flavours of web pages can be defined using the markup elements.

In order to achieve this, in line with the key design principles detailed in , following key design guidelines are proposed:

Key Design Considerations

1. Data specifications should be broken down to simpler fundamental units as far as possible.

2. In order to leverage existing knowledge and resources and provide wider interoperability, data specifications should extend/ reuse/ adopt international/ national models wherever available/applicable. In order to follow this in claims context, data specification should leverage resources as follows:

   • Leverage HL7/FHIR R4 specifications wherever possible

   • Leverage NRCES FHIR specifications where base FHIR specs need contextualization to the Indian context

   • Create minimal extensions needed in case both base FHIR and NRCES specs are not enough to support the use case

   • FHIR Document profiles appropriate for the protocol should be created composed of base FHIR resources

3. Data specifications should be created with the principle of minimalism and inclusivity. In order to achieve this:

   • Specs should permissive cardinalities as much as possible. E.g. they should require minimal mandatory fields to enable maximal inclusion. As a thumb rule, wherever unsure of the cardinality of an attribute, the most permissible one should be used.

   • Specs should use permissive terminologies/code binding strength as much as possible. E.g. in the (Section 4.1.5), if there’s a conflict in choosing between “extensible” and “preferred” strengths for a coding system, “preferred” should be chosen.

4. Data specifications should be extensible i.e. they should allow a way to capture extra information that was not initially included during the model design. To achieve this:

   • It may provide a simple map of key-value pairs. Future versions of the data model may choose to create mandatory/optional names attributes in the data models after researching the wider applicability of such fields.

   • Data specifications should allow for namespacing in field names to indicate the source/reason/category of the extended fields.

5. It is recommended that all timestamps be captured in ISO-8601 format e.g. 2020-08-15T17:02:53.495+05:30. APIs may define display format property to indicate the human-readable format most suitable for display.

Based on the priorities listed above and design considerations, key domain specifications included in Phase 1 are detailed in the following sub-sections.

To assist implementers in the ecosystem to create flow specific payload defined in FHIR spec applicable in HCX, an implementation guide (IG) defining a set of rules about how FHIR resources are used (or should be used), with associated documentation to support and clarify the usage will be created.

Such a publication can be used to validate content against the implementation guide as a whole.

The extended profiles and structures of the FHIR bundles and resources to be used in HCX are available here.

The domain data model consists of the electronic claim (e-claim) objects (a.k.a. eObjects) that are designed to capture the required information essential for processing a health claim transaction. The e-claim objects, being machine -eadable, facilitate the flow of data exchange between different systems and data processing in health claim transactions without the need for human intervention.

Guidelines for eObjects

Bundle Structure

• All e-claim objects will be modelled as FHIR bundles of type "document", with "bundle.composition.type" specifying the type of bundle.

• The first resource in the bundle shall be a “Composition” resource followed by a series of other resources referenced from the “Composition” resource. The elements “type”, “category” and “section” in the “Composition” shall be used to define the purpose and set the context of the document.

• For example, the data packet for a coverage eligibility check request will be a bundle with “bundle.composition.type” as “Coverage Eligibility Check” and the bundle will have a “CoverageEligibilityRequest” FHIR resource embedded in it.

Identifiers:

• For any resources requiring identifiers (e.g. Patient.identifier), naming systems have to be defined and agreed upon within the affinity domain to be specified in the “identifier.system” element to namespace the identifier value. This can allow an entity or resource to be referenced against system-specific identifiers. For example, a patient may be referenced as:

• For some identifiers, “identifier.type” can be used to provide additional information.

• “identifier.use” can be used to indicate what/where/how a particular identifier might be used for.

• Example:

Resources

• For external entities like patients, organisations, practitioners, etc, a reference alone is enough unless additional information is required to be passed. For example, patient address & other demographics.

Domain Header

• All eObjects shall be encrypted and sent in the API request body and cannot be accessed by the HCX gateways. However, there is a provision in the API request body for providers and payers to share certain eObjects' related information with the HCX gateway. This information can be sent in the domain_header part of the request body (as key-value pairs) which can be accessed and stored by HCX gateways for auditing and reporting purposes. Each eObject shall define the domain header values that are to be sent in the API request body.

Search Parameters

• In addition to the workflow APIs for claim processing workflows, HCX also defines APIs for searching eObjects. To support the search APIs, all eObjects will define the search request parameters.

Questions for Consultation

Question 1

Question 2

HCX defines search APIs to search eObjects. The search parameters for each eObject are not currently defined. Please suggest the search parameters for each eObject. Also, should there be additional search APIs that do not require FHIR encoding of the response payload? Kindly elaborate on the nature of these APIs.

Question 3

Proposed domain data models and terminologies require adopting FHIR as domain object standards. How does one facilitate and enable the participants to adopt FHIR and change their systems and processes?

To achieve semantic interoperability, it is recommended that HCX data standards incorporate well established and suitable terminology and coding systems.

In various HL7 standards (including FHIR), these are expressed as Concepts and codes and forms essential vocabulary, ontological binding for resources used to describe document types/categories, element codes and clinical coding like procedure codes, diagnosis codes etc. The data standards defined using FHIR resources and types usually will require agreement on references and usages, through agreed Code Systems and codes, typically manifested through ValueSets.

Guidelines

• For Clinical resources (e.g. Condition, Procedure, Observations) - please refer to the guidance issued by NRCeS.

  • In India, SNOMED-CT is free for use by all as Clinical Terminology, while ICD codes are used for classifications.

  • Labs typically use LOINC codes

• For other code/concepts in the FHIR based data standards, we would recommend guidelines

  • If any attributes are marked as “required” - then, use of the codes defined in the value sets

  • If it is marked as “preferred” or “extensible” - then, users are encouraged to draw from the specified codes for interoperability purposes, unless deemed appropriate within the affinity domain.

  • If marked as “example” - then the domain must agree and define a value set for usage.

  • ValueSet may be created derived from existing sets, either composed/included from the base or expanded.

• For insurance claim domain specific element attributes (e.g. Claim.type) - the domain may define and establish value sets, as suitable in India’s context.

For the broader NDHM interoperability and conformance, HCX would align/inherit domain specific guidelines.

The table below lists the code systems/value sets proposed by current domain working groups. Based on the above guidelines, we are proposing them to be “preferred” or “example” binding strengths as per FHIR Terminology binding strength definitions (Section 4.1.5).

HCX or a neutral protocol supporting organisation will host domain specific FHIR Terminology Services which the ecosystem can leverage to retrieve information and use, and validate resources as defined by the IG.

Questions for Consultation

Question 1

During multiple discussions with the ecosystem, it has been suggested that while the specifications suggest recommended terminologies, they are not yet mandated (hence the low binding strength's against each terminology). Kindly provide your view on mandatory standardisation of terminologies and approaches to enable your suggestions.

Question 2

In your view, what clinical terminologies and codes (e.g SNOMED-CT, ICD-10, LOINC) be considered? In addition, are you aware of any well established and accepted codes/value sets available that can be applicable to the Indian scenario? Kindly provide details.

This version of the HCX specification defines the domain model specifications required for the following eObjects:

• Coverage Eligibility Request and Coverage Eligibility Response

• Claim Request and Claim Response: These objects will be used for both Pre-Authorization and Claim use cases (and for Pre-Determination also in future).

• Payment Notice and Payment Reconciliation

As mentioned in the design considerations for domain specification, the eObjects leverage HL7/FHIR4 specification and extend it, wherever required.

Coverage Eligibility Request

As per the design considerations and guidelines listed in the previous sections, the coverage eligibility request payload has to be created as an FHIR document bundle. The bundle should have the following resources:

Domain Headers:

Search Parameters:

Coverage Eligibility Response

Domain Headers:

Search Parameters:

Claim Request

Claim object is used by providers to submit pre-authorization and claim requests to the payers. The same eObject can be used for both these use cases and the usage can be differentiated by the value of “claim.use” element. The value of this element should be set as “preauthorization” for Pre-Authorization requests and as “claim” for Claim requests.

Domain Headers:

Search Parameters:

Claim Response

ClaimResponse object is used by payers to send the response for pre-authorization and claim requests to the providers. The same eObject can be used for both these use cases and the usage can be differentiated by the value of “ClaimResponse.use” element. The value of this element should be set as “preauthorization” for Pre-Authorization responses and as “claim” for Claim responses.

Domain Headers:

Search Parameters:

Payment Notice

Domain Headers:

Search Parameters:

There are two key DSLs being considered for the Health Claims Exchange - Policy Markup Language (PML) and Bill Markup Language (BML). These are currently work in progress and are expected to be released in the later version of HCX specifications after substantial proof of concept development with various members of domain working groups.

Policy Markup Language (PML)

The purpose of policy markup language is to provide a DSL to payers such that the policies can be encoded in machine readable format, thereby helping with the automation of eligibility check and adjudication processes.

Bill Markup Language (BML)

The purpose of bill markup language is to provide a DSL to payers such that the supporting bills can be parsed as machine readable structured data, thereby helping with the automation of adjudication processes.

Questions for Consultation

Question 1

The section above refers to adopting appropriate DSLs for policy and bills. Kindly suggest your views on the useability of such domain-specific language and provide prior examples.

Question 2

Are there any existing solutions that have been used/experimented with? Please provide examples.

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:

1. Onboarding

2. Defaulting/Deboarding policies

3. Dispute resolution policies

4. 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.

5. Business SLAs

6. 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

7. 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:

Key Design Considerations

1. Policies should focus on enabling the ecosystem rather than monitoring or controlling it

2. Policy formulation should be done as an open consultative process to foster trust in policies

3. Rules of participation and disqualification should be transparently laid out

4. 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:

1. Access control (Roles)

2. Participant onboarding/deboarding

3. Grievance redressal

4. Event Audit

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 Re: GUIDELINES FOR GRIEVANCE REDRESSAL BY INSURANCE COMPANIES, however, these are now envisioned to cover grievance from any actor of the ecosystem with respect to other actors.

Key Policy Design Guidelines

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:

1. 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.

2. 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.

3. 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.

4. As part of the participant registry, the HCX instance also publishes the details of its governance body.

5. 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.

6. The policy should publish SLA for each grievance type including any required as per prevailing regulations.

7. 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.

8. The policy should require ample due diligence cycle to address the grievance and review the redressal before responding back to the requester

9. The policy should allow for the reopening of the grievances

10. 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.

11. 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.

12. The policy should include ways of keeping requesters informed about the latest status and any additional requirements to help address the grievance.

Proposed Approach for Policy Formulation

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 Approach for Open Specifications:

1. Like with the specifications so far, constitute a new working group for Dispute Resolution policies.

2. The working group contextualises and adopts the open specifications design principles and high level approach as detailed in HCX - Cover note for the dispute resolution context.

3. The working group drafts a model policy in accordance with the above principles and in line with the detailed approach from step 2 above.

4. The principles, detailed approach and model dispute resolution policy draft is versioned and released for public consultation.

5. The domain working group deliberates the feedback and enhances principles/model policy as needed.

6. HCX Operators adopt the model policy according to the needs of their network

7. 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).

Next Steps

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.

Questions for Consultation

Question 1

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?

Question 2

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 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:

1. Sandbox - for compliance testing and certification

2. Go Live on live instances

Sections below provide high level guidelines for each of these steps.

Sandbox Process

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.

Go Live process

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:

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.

3. 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.

Deboarding scenarios

This section lists some of the deboarding scenarios that may be considered as part of the final deboarding policies by the HCX operators:

1. Involuntary deboarding of a participant initiated by Regulator/Legal Authority. Few examples:

   1. Suspension/Deactivation of a provider by a regulator for fraudulent activity.

   2. Suspension/Deactivation of a TPA or a Payer by IRDA

2. Involuntary deboarding of a participant (mostly TSPs) initiated by HCX. Few cases:

   1. Serious violation of HCX policies (e.g. grave SLA violation repeatedly)

   2. Hacking attempts made by participants for unauthorized access, after an investigation by HCX

   3. 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).

3. Voluntary deboarding of participants. Few examples:

   1. A provider or payer shifting to another HCX

   2. A provider or payer shuts down their business

   3. 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.

Next Steps

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.

Questions for Consultation

Question 1

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?

Question 2

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?

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.

1. provider: Health Service Provider

2. payer: Insurance service provider

3. 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.

4. agency.regulator: IRDAI and IIB like regulatory bodies.

5. research: Research groups, etc.

6. member.isnp: eCommerce platforms facilitating insurance adoption

7. agency.sponsor: Scheme owners of specific programs, e.g. NHA for Ayushman Bharat

8. 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:

Questions for Consultation

Question 1

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.

Question 2

This section also mentioned allowed actions for the current set of stakeholders, please review these actions and suggest any changes needed for those actors.

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.

Next Steps

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.

Aadhaar Digital eKYC API

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.

Optional Aadhaar Authentication (mobile OTP/biometric)

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.

Verifiable Govt ID based verification (DL/PAN/Voter ID)

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

Token based authentication by Payer

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.

Direct Authentication by Payer

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.

Next Steps

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.