Open protocol for claims data exchange - Health Claims Transfer Protocol

Like HTTP or SMTP, open protocol for claims exchange will define the following key aspects:

1. Authentication (Payor, Provider, Regulator, Observer, ...)

2. Request/response message syntax - header and header attributes, optional body, mandatory vs optional, transport constraint on the messages, etc.

3. Supported methods (APIs)

4. Communication mode (synchronous or asynchronous nature of APIs)

5. Response codes

6. Data security and privacy considerations: Security, authenticity, and non-repudiability aspects of message exchange

   1. Encryption of certain parts of message for transport security (beyond SSL on Health Claims data exchange)

   2. Message signing protocol for verifiability and non-repudiation

7. Sequence of interactions

Tech Ops Policy Specifications

These will include the following policies for participation in the health claims data exchange:

1. Onboarding policies - How does any entity get on board on the data exchange? Adherence to protocol, the process for a compliance review, frequency of compliance review, etc

2. Deboarding policies: What makes an entity to be blocked or ejected from the data exchange. Things like adherence to technical SLAs, non-compliance with expected protocol versions, message security or privacy violations, etc.

3. Access control policies - Role-based, need for consent to access APIs, data attributes, etc.

4. Exchange operation policies

   1. Key rotation requirements

   2. Segregation of duties and responsibilities within various teams of exchange operators

   3. Operational reports and dashboards

   4. Audit checklist and frequency

Domain Data Specifications

Specifications about format and definition of domain data. A lot of these may be adopted from existing domain standards like FHIR, SNOMED, ICD-10-PCS. In the context of claims data exchange few key focus areas will be:

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 codes (e.g. room rent, ICU charges), 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.

Business Policy Specifications

A thriving data exchange will also require clear rules of engagement to ensure trust from all actors. These specifications will involve guidelines around:

1. Access control (Data sharing) policies - which actor plays what role and gets to see which parts of the 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.

2. Business SLAs

3. Charges/Fees - these would be policies around charges various data exchange entities will be allowed to levy on others depending on the role they play

4. Dispute resolution policies

5. Onboarding

6. Defaulting/deboarding policies

7. Service rating policies - that would be the parameters and mechanisms to rate each type of actor on the data exchange.

Questions for Consultation

Question 1

Please comment on the comprehensiveness of key categories of the specifications mentioned and suggest any additional areas which will require open specifications for efficient working of the HCX ecosystem.

This section focuses on digital specifications that are needed to realize the health claims network - open protocol and digital network management policies.

Details of domain data models and business policies are covered in the next section here.

Given the sensitive nature of the information involved during claims processing - personal details, health-related information, etc., it is imperative that the data is kept secure during the exchange process (security if data while stored at sender and receiver is expected to be as per the prevailing data security regulation of the data storage).

There are many language specific libraries available that can help you implement the required encryption/signing/verification that is described above.

In order to achieve this, various approaches are defined in the subsequent sections.

All communications between health claims exchange(s) and participating entities are expected to be done using Transport Layer Security. Therefore all APIs are expected to work only as HTTPS in the production environments.

The Health Claims data Exchange can be envisioned as analogous to the internet in general and email exchange networks more specifically, where data packets travel to and fro between an origin and the destination. In this context, Health Claims Data Exchanges can be thought of as routing switches or email gateways that facilitate communication with the desired level of consistency, security, privacy, and durability. However, unlike the internet or email, this protocol is defined for a specialized use case of exchanging claims-related information between relevant actors - payors, providers, beneficiaries, regulators, observers.

The figure below shows a simple depiction of a health claims network facilitated by an HCX instance:

Vision, Mission, and Objectives

1. Expand Insurance Penetration

   1. Significantly lower cost of claims processing implies new use cases – such as OPD and Pharmacy

   2. New kinds of payors in the market that can lead to an increase in insured base

   3. Reduce receivable cycles and increase acceptance of cashless claims (even in smaller hospitals)

2. Facilitate insurance innovation

   1. Highly personalized policies

   2. Short duration, low premium policies

   3. Auto adjudication, better fraud, and abuse prevention

3. Simplify and bring efficiency to claims processing

   1. Standardized claims process, less operational overheads

   2. Increase trust among payers and providers through a transparent, rule-based mechanism

4. Better patient experience

Key Use cases/Workflows

In its initial version, HCN is focused on facilitating message exchange for the cashless claims process and envisions to facilitate the following information flows:

1. Get provider/payor details

2. Eligibility check

3. Pre auth request flow

4. Claims request flow

5. Payment notification

6. Payment acknowledgement

7. Search/fetch claims data for status checks, regulatory compliance, etc.

Key constituents

The claims network will consist of the following key building blocks:

1. Specifications - this layer defines the blueprint for different aspects of the claims network. These include communication protocols, data packet specifications, Taxonomies, privacy and security specifications, network policies (onboarding and deboarding rules), business rules, operational specifications, etc. Please note that the document intentionally calls these artifacts as specifications to indicate that they become standards only after a “de jure” or “de facto” adoption by the ecosystem.

2. Reference Health Claims Exchange (aka switch) software - A reference gateway implementation build as per the standards defined above. The main goal here will be to provide fundamental software building blocks of the network to enable faster adoption by the ecosystem.

3. Compliance sandbox - Implemented using the above reference software, the key goal of the sandbox will be to help the ecosystem test its specific components against the network standards defined above and get certified to become part of the network.

4. Health Claim Platform runtime(s) - Operating instances of the health claims platform that enable real-world claims interactions on the network. Like with the internet and email example, there can be multiple such running instances that are expected to be interoperable by adhering to the standards defined as in #1 above.

5. Participating platforms - These are digital systems of the network participants (Payors, Providers, Regulators, Observers, etc) that sit on the edges of the claims network and initiate/receive the communication happening through the network. These would be analogous to client/servers in the internet analogy and various email service providers in the email analogy.

The following sections describe the key aspects of the proposed open specifications including design principles, a list of key specifications, proposed governance and details of technology and domain specifications work completed so far.

Questions for Consultation

Question 1

HCX specifications could enable the existence of multiple HCX instances and relays between them (please see example flow here). What challenges do you foresee in both scenarios - single HCX for all stakeholders v/s multiple connected HCXs? What would be your criteria to choose one scenario over the other?

Need for a new approach

Overview of the Current Process

The current claims filing and processing experience is fairly manual in nature.

Patients usually reach the hospital and provide the hospital with either the policy details or a card issued by the TPA. The hospital fills out the pre-auth/claim form by hand, scans all the required documents that need to be part of the claim, and sends these to the appropriate Insurance or TPA typically over email. Several TPAs/insurers also provide hospitals with their own electronic portal where their claims can be submitted as an alternative to email.

On receipt of the pre-auth/claim form, the Insurer/TPA verifies and digitizes the form in the software they use internally for claims processing. The team then adjudicates the claims. A large portion of adjudication in India is currently manual while many developed markets auto-adjudicate over 90% of their claims.

A response to the pre-auth/claim is sent back to the hospital over email. Payments are done electronically and notifications for payment advice are sent via email.

All insurers have to report claim details in a specified format to the Insurance Information Bureau of India (IIB). This is done on a monthly basis by each insurer.

()

Challenges of the Current Process

• The current claims exchange process is not standardized across the ecosystem

• Most data flow is PDF/manual

• High variability of process between insurer/TPA/provider

This results in:

• Multiple follow-ups, lack of visibility

• Long receivable cycles

• High cost of processing

• Poor scalability

• Poor patient experience

The goal is to create an open, widely agreed Health Claims data Exchange Specifications as a public good that can be adopted. Specifications in this context refer to the blueprint of each aspect of the envisioned claims network and are fundamental to the working of the network. They have been carefully designed to be open to support technology and vendor neutrality, evolvable over a period of time thereby helping adapt to changing needs, enable and not restrict innovation or inclusion. These Health Claims Exchange Specifications for Cashless Insurance are now being published for public consultation and we seek your feedback for the same.

Questions for Consultation

Question 1

Question 2

As a stakeholder in the health finance ecosystem, what benefits or risks do you see of implementing such a data exchange process? How can the risks be mitigated?

Specifications are fundamental to the success of the envisioned claims data exchange. In order to ensure that they can act as this common foundation, this section proposes design principles for the open specifications in line with basic principles outlined in the .

Open

Specifications must be designed to be open to support technology and promote vendor neutrality. They must be published under the most unrestricted license (Creative Commons or MIT license) as applicable to enable wider ecosystem participation and foster innovation through extensibility. Being open also helps leverage wider ecosystem expertise at the time of designing and evolving the specifications.

Evolvable and Extendable

They must be designed to be evolvable over a period of time thereby helping adapt to changing needs. By being extendable they provide ecosystems with the capability to leverage these specifications for their context while maintaining interoperability.

Minimalistic and Inclusive

Minimalism is crucial to ensuring that specifications enable and do not restrict innovation or inclusion.

Balance data privacy and security with data empowerment

They must provide for the mechanisms to keep the data secure (e.g. mandating SSL for data in transit, requiring relevant data to be encrypted) and private (e.g. consent-based data access) while still allowing for mechanisms to exchange needed information between trusted parties.

Provide for non-repudiability

They must provide mechanisms to view and verify attribute trails - who accessed or updated what and when - through mechanisms like digital signatures and tamper-proof audit trails.

Unbundled

They should strive to break down the complexity of the domain into multiple simple pieces thereby resulting in multiple simple specifications which can be bundled in a modular manner to suit the needed context and help solve dynamic challenges.

Questions for Consultation

Question 1

Specifications here refer to the blueprint of each aspect of the envisioned claims data exchange. In this context, the specifications can be thought of as a collection of minimal requirements and definitions which helps participants on the claims data exchange to -

• Co-exist and inter-operate correctly with each other (e.g. Provider/Payor/Sponsor, HCX1/HCX2)

• Speed up time to go live for the new data exchange use cases

• Define and meet the necessary regulations/policies

• Allow participants the choice of technology/solutions

In order to foster collaborative work while still maintaining consistency, envisioned specifications should adhere to key design principles defined in the .

HCX instances are expected to log each API call received along with the non encrypted details (domain headers, sig/enc algorithm details, sender & recipient details) and status of signature verification.

Key Requirements:

• HCX instances should provide reports against the audit logs for different actors - payors, providers, beneficiaries, regulators, observers. Each HCX instance shall publish the list of reports supported by that instance and also define the level/details of information in each report.

• The audit information stored should be made available through an API, so that the participating systems can query the audit log related to them.

• Each HCX instance shall define an archival policy for retention & deletion of audit logs. The policy shall also define the process for accessing the logs after archival, if the HCX instance has support for it.

• It is recommended for HCX instances to have a configuration to control the amount of information that gets stored in the audit logs.

Questions for Consultation

Question 1

Apart from the list mentioned here, what other audit and reporting requirements would you expect HCX to fulfil?

In order to fulfil architectural principles listed in , the protocol needs to consider the following key design elements:

• The protocol must be designed to support the asynchronous exchange of information to support the scale and asynchronous nature of processes in the industry

• The protocol must support the federated deployment of multiple HCX instances.

• In order to ensure the security and privacy of sensitive data

  • The protocol must allow for separation of transport (and any other common information) from sensitive information in the respective flows

  • The protocol must provide for encryption, signing, and auditing of relevant information

• The protocol should allow creating unique identifiers for each message exchange

• The protocol should allow related multiple messages that are part of a single business flow

• The protocol should allow using existing registries for key entities - beneficiary, provider, and payor with a facility to extend them for the specific use case

• The protocol should be designed to allow for the inclusion of the new types of use cases

• The protocol should be designed to allow extending a use case as per the need of the use case/program (for example, a particular government scheme or innovative health financing solution may need different information about the beneficiary, provider, or intervention)

Based on these principles and design considerations, the lists key components of the HCX protocols.

Questions for Consultation

Question 1

Please review and suggest if there are other considerations that could help in the better design of Open Protocol.

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.

TO ensure that sensitive information in the actual domain objects is not accessible even to the HCX, protocol requires the payload defined by the domain data specifications to be encrypted using a separate asymmetric encryption key of the final recipient established at the time of participant onboarding into the registry. API then carries the encrypted value of the payload. The payload encryption is expected to be performed using JSON web encryption RFC7516 as per algorithm and enclosed values fixed in the protected headers section above. At this point in time, no unprotected headers are envisioned in the HCX protocol. We also do not envision multiple recipient delivery in the current version of the HCX protocol.

Message Encryption

The high-level steps to encrypt the payload using the public key of the final recipient are:

1. Find out the public key of the recipient through registry lookup on HCX.

2. Let JWE protected header be = BASE64URL(UTF8((Registered JOSE headers) U (HCX Protocol Headers) U (HCX Domain Headers)). Please note that initial version of HCX protocol requires following JOSE headers: {"alg":"RSA-OAEP","enc":"A256GCM"}

3. Generate a random Content Encryption Key (CEK) as per the encryption algorithm.

4. Encrypt the CEK with the recipient's public key using the RSAES-OAEP algorithm to produce the JWE Encrypted Key.

5. Base64url-encode the JWE Encrypted Key.

6. Generate a random JWE Initialization Vector.

7. Base64url-encode the JWE Initialization Vector.

8. Let the Additional Authenticated Data encryption parameter be

ASCII(BASE64URL(UTF8(JWE Protected Header))).

1. Perform authenticated encryption on the plaintext with the AES GCM algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value, requesting a 128-bit Authentication Tag output.

2. Base64url-encode the ciphertext.

3. Base64url-encode the Authentication Tag

4. Assemble the final representation in flattened JSON serialization (Section 7.2.2 of RFC7516):

{
  "protected":"<integrity-protected header contents from step 2 above>",
  "encrypted_key":"<encrypted key contents from step 5 above>",
  "aad":"<additional authenticated data contents from step 8 above>",
  "iv":"<initialization vector contents from step 7 above>",
  "ciphertext":"<ciphertext contents from step 10 above>",
  "tag":"<authentication tag contents from step 11 above>"
}

Message Decryption

The high-level steps to decrypt and verify the integrity of the payload using the private key of the final recipient are:

1. From the received JSON serialized JWE token, Base64url decode the encoded representations of the JWE Protected Header (protected), the JWE Encrypted Key (encrypted_key), the JWE Initialization Vector (iv), the JWE Ciphertext (ciphertext), the JWE Authentication Tag (tag), and the JWE AAD (aad), following the restriction that no line breaks, whitespace, or other additional characters have been used.

2. Verify that the octet sequence resulting from decoding the encoded JWE Protected Header is a UTF-8-encoded representation of a completely valid JSON object conforming to RFC 7159; let the JWE Protected Header be this JSON object.

3. Let the JOSE Header be the JWE Protected Header. Verify that the resulting JOSE Header does not contain duplicate Header Parameter names.

4. Determine the Key Management Mode employed by the algorithm specified by the "alg" (algorithm) Header Parameter.

5. Verify that the JWE uses a key known to the recipient.

6. Decrypt the JWE Encrypted Key to produce the CEK. The CEK MUST have a length equal to that required for the content-encryption algorithm.

7. Compute the Encoded Protected Header value BASE64URL(UTF8(JWE Protected Header)). This protected header is (Registered JOSE headers) U (HCX Protocol Headers) U (HCX Domain Headers).

8. Let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header).

9. Decrypt the JWE Ciphertext using the CEK, the JWE Initialization Vector, the Additional Authenticated Data value, and the JWE Authentication Tag (which is the Authentication Tag input to the calculation) using the specified content-encryption algorithm, returning the decrypted plaintext and validating the JWE Authentication Tag in the manner specified for the algorithm, rejecting the input without emitting any decrypted output if the JWE Authentication Tag is incorrect.

Participating systems are expected to follow best practices guidelines as in RFC8725 to ensure the security of the payload.

It is recommended to rotate these encryption keys once every year and mechanisms implemented for the providers/payers/HCX to intimate the ecosystem about the potential compromise of the keys.

Here is a sample of the set of libraries that you can explore:

1. Bouncy castle

2. Openssl

3. NaCl

4. Libgcrypt

5. PyNaCl

6. TweetNaCl

Questions for Consultation

Question 1

This section suggests JSON Web Encryption as per RFC7516 as the mechanism for payload security and integrity. Which alternative mechanism for payload security and privacy would you explore for HCX? Kindly provide the pros and cons of the alternative mechanism.

Question 2

In addition to the best practices mentioned in RFC8725, which other best practices/guidelines would you suggest to HCX participants for data security and privacy?

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.

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?

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.

Scenarios for Cross gateway exchange

The cross gateway communication will be required in the following scenarios –

1. When a provider is onboarded in a gateway instance but the payer for that health policy scheme is registered in another gateway instance.

2. If a beneficiary enrolled in health policy took treatment in a network hospital in another state and that hospital is onboarded in a different gateway instance than the payer.

3. For top-up cases, the providers and payers are registered in different gateway instances and in such scenarios primary insurance is handled by one payer in one gateway instance but the secondary insurance is handled by another payer registered in a different gateway instance.

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.

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.

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

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

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?