The National Health Policy 2017 has the stated objective of Universal Health Coverage. The government is already providing cover to nearly 40% of the population from lower economic segments with PM-JAY. This is expected to expand to cover about 70% of the population over time. The number of claims from Government sponsored schemes is expected to see a significant increase with both increase in awareness and wider coverage of the population.
5 | It is important that the adoption of an electronic claims system happens before the large scale usage of claims becomes a reality.
6 |
7 |
The joint working group of NHA and IRDAI (2019) recommends the creation and adoption of a Health Claims Data Exchange Gateway and standardization of e-claims and other related documents to enable the ecosystem to move to a low cost paperless ecosystem that inherently allows for innovation. This will include adoption of open standards by all the actors in the Health Insurance Eco‐system.
8 |
Based on the recommendations from NHA & IRDAI, the HCX working groups have created a open specification for enabling health claims exchange. The detailed specifications are available here.
9 |
Introduction
10 |
The FHIR Implementation Guide for Health Claims Data Exchange Specifications is based on FHIR Version R4 and defines the minimum conformance requirements for exchanging claims-related information between relevant actors - payors, providers, beneficiaries, regulators, observers.
11 |
Purpose
12 |
The purpose of this implementation guide is to provide essential and minimum artefacts that can be captured and exchanged as per Health Claims Data Exchange Specifications 1.0.
13 |
How to read this Guide
14 |
This Guide is divided into several pages which are listed at the top of each page in the menu bar.
15 |
16 |
17 | Home: The home page provides the introduction, purpose, and scope of Health Claims Data Exchange Specifications 1.0.
18 |
19 |
20 | Artifacts: These pages provide detailed descriptions and formal definitions for all the FHIR objects defined in this guide.
21 |
22 |
23 | Profiles:This page lists the set of Profile that are defined in this guide to exchange claims data.
24 |
25 | Terminology:This page lists the value sets defined for FHIR Implementation Guide for HCX profiles.
26 |
27 |
28 |
29 | Downloads: This page provides links to downloadable artefacts.
30 |
--------------------------------------------------------------------------------
/README (1).md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Background of the Health Claims Data Exchange effort
3 | ---
4 |
5 | # Context
6 |
7 | ## Need for a new approach
8 |
9 | ### Overview of the Current Process
10 |
11 | The current claims filing and processing experience is fairly manual in nature.
12 |
13 | 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.
14 |
15 | 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.
16 |
17 | 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.
18 |
19 | 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.
20 |
21 | _(_[_Reference: NHA IRDAI Joint Working Group Report_](https://pmjay.gov.in/sites/default/files/2019-09/Sub%20Group%20on%20Common%20IT%20Infrastructure%20Report\_11-09-19.pdf)_)_
22 |
23 | ### Challenges of the Current Process
24 |
25 | * The current claims exchange process is not standardized across the ecosystem
26 | * Most data flow is PDF/manual
27 | * High variability of process between insurer/TPA/provider
28 |
29 | This results in:
30 |
31 | * Multiple follow-ups, lack of visibility
32 | * Long receivable cycles
33 | * High cost of processing
34 | * Poor scalability
35 | * Poor patient experience
36 |
37 | Inspired by the [recommendations of the Joint Working Group of NHA and IRDAI (2019)](https://pmjay.gov.in/sites/default/files/2019-09/Sub%20Group%20on%20Common%20IT%20Infrastructure%20Report\_11-09-19.pdf), these specifications have been developed over the last two years by 100+ volunteers from across the healthcare ecosystem (including Insurers, Hospitals, TPAs, Insurance Technology players and Think tanks), as a part of a transparent, collaborative and open effort anchored by Swasth.
38 |
39 | 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. The current version of the specifications is widely evaluated for the cashless claim use case, and different volunteers are working on the evaluation for other use cases, such as reimbursements and OPD. More use cases are being planned for the future.
40 |
41 | {% hint style="info" %}
42 | While the [recommendations of the Joint Working Group of NHA and IRDAI (2019)](https://pmjay.gov.in/sites/default/files/2019-09/Sub%20Group%20on%20Common%20IT%20Infrastructure%20Report\_11-09-19.pdf) refers to the concept as HCP (Health Claims Platform), working groups decided to choose the new name HCX (Health Claims Data Exchange) after the feedback from the ecosystem that HCP involves many more things than data exchange facilitation.
43 | {% endhint %}
44 |
--------------------------------------------------------------------------------
/future-roadmap.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Potential focus areas proposed in future versions
3 | ---
4 |
5 | # Future Focus Areas\*
6 |
7 | Following are the list of potential enhancements envisioned/propsed by the community members for the future versions of the protocol.
8 |
9 | {% hint style="info" %}
10 | Please note that this is a tentative list and that the community may revise and prioritise it according to the ecosystem needs.
11 | {% endhint %}
12 |
13 | #### Tech and Domain related
14 |
15 | 1. **Improvement in semantic interoperability (WIP) :**
16 | * Defining higher confidence, harmonised valuesets based on ecosystem input
17 | * Valueset discoverability through terminology registry and services
18 | 2. **Mechanism for challenging the claim adjudication process :** Enabling beneficiaries/providers to dispute claim adjudication outcomes via the Health Claims Exchange (HCX). This would help beneficiaries/providers with a standard mechanism to raise disputes, and streamline the challenge process, fostering increased transparency and trust in the system.
19 | 3. **Enabling multi payer - multi policy claim adjudication :** Enabling beneficiaries/ providers to submit claims to multiple payers for a given episode, e.g. when the treatment expenses exceed coverage limits, or certain procedures are not included in a specific policy.
20 | 4. **Analyse and expand for other OPD categories:** Exploring other categories within the OPD use case, understanding their unique challenges, and enhancing the workflow to address specific nuances.
21 | 5. **Analysing/enhancing the protocol for non-insurance benefits (Corporate wellness, health CSR, community/cooperatives benefits) :** Broadening the scope of the Health Claims Exchange (HCX) to encompass a wider range of benefit scenarios, including corporate wellness, health CSR, and community/cooperative benefits. This strategic expansion aligns with our commitment to innovation and the realisation of the Universal Health Coverage (UHC) vision.
22 | 6. **Claim initiation using QR Code (WIP) :** Allowing consumers to initiate claims or pre-authorization flows conveniently by using QR codes, simplifying the initiation process. More details [here](https://github.com/hcx-project/hcx-specs/discussions/113) in the github comment.
23 | 7. **Enhancing CommunicationRequest cycle to allow structured Queries :** Enabling hospitals/payers to raise structured queries on the Healthcare Exchange (HCX) platform to payers/hospitals, improving communication and speeding up resolution for reimbursement-related inquiries.
24 | 8. **Enhancement in Insurance Plan object :** The existing profile only allows to declare limits at benefit level, but we cannot add conditions/rules of eligibility. Also, the values of limits could be expressions, not just values/constants always.
25 | 9. **Multiple claims submission :** Analysis the feasibility of allowing multiple claims submissions against a single pre-authorization.
26 | 10. **Detailed approach on handling attachments/supporting information :** Further elaboration on the multiple options to share the supporting information when not available in structured format.
27 | 11. **Further detailing of the domain objects (descriptions, examples, etc.) :** Enhancing IG to provide better description of the Profiles/Attributes/Valuesets and including more examples/use cases from the domain.
28 | 12. **Examples of typical use cases :** Adding real-life use cases of the medical episodes and insurance claims.
29 | 13. **Guidelines on Technical Operations of the HCX switch(es)/network**
30 | 14. **Notification Delivery status API**
31 | 15. **Notification - Failure and retry policies**
32 | 16. **Consumers wanting to unsubscribe notification from a HIU/ISNP** - Consumers may want to stop notifications from the HIUs (Like policy bazaar, etc.) or switch the HIU to get updates on their policies.
33 |
34 | #### Policy related
35 |
36 | 1. **Workflow efficiency :** Assigning turnaround time (TAT) to each workflow step to streamline the OPD process and ensure timely handling of claims.
37 | 2. **Understanding Master policy holder (MPH) as stakeholder :** Cater and engage with MPH as stakeholders to understand their specific use cases and analyse/prescribe/enhance the HCX workflow and specifications to serve their needs.
38 | 3. **Fraud mitigation :** Assessing the potential risks of fraudulent activities in the OPD claims and implementing measures. This is already being discussed under the policy workstream.
39 | 4. **Insurance agent persona :** Understanding the distinct needs of insurance agents as users of the platform and ensuring their requirements.
40 | 5. **Digital contracting (WIP) :** Hospital Tariff document (Schedule of Charges, etc…) standardisation and contract between hospital and insurer.
41 | 6. **Further refinement of Provider onboarding process.**
42 | 7. **Enhancements in model business policies in various operational areas.**
43 |
44 |
--------------------------------------------------------------------------------
/glossary.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Key terms & their descriptions
3 | ---
4 |
5 | # Glossary\*
6 |
7 |
Term
Description
Beneficiary Service Platform (BSP)
Digital platforms dedicated for assisting beneficiaries to track and file claims.
Coverage Eligibility
Process of checking if the beneficiary's policy is in force and cover the proposed goods, products and services.
Claims
Process of seeking payer's authorisation on the proposed set of goods, products and services and getting funds.
FHIR Profile
A JSON data structure that defines a domain model eligible to be carried as part of JWE payload in the HCX protocol APIs.
HCX Switch
Instance of the HCX gateway, implemented as per the HCX protocol, that facilitates the information exchange between its participants.
HCX Network
Instance(s) of HCX and their participating systems governed by a common network policy.
In-patient department (IPD)
Inpatient care, often referred to as the In-patient department (IPD), is a dedicated section within a healthcare facility specifically designed to deliver comprehensive medical care and treatment to patients or beneficiaries who require admission or an extended stay within the hospital.
Network participants
Any platform that has implemented the HCX protocol and becomes the part of a network as above.
Notification
A logical unit of information sent to relevant network participants. Notifications can be triggered by an event, activity or time trigger on the network.
Notify
Act of sending a notification.
Out patient department (OPD)
The Outpatient Department (OPD) is a distinct component of a healthcare facility, such as a hospital or clinic, dedicated to delivering medical services to patients who do not necessitate overnight hospitalisation.
Payer/Payor
Insurance provider, employer, organisation or an individual responsible for making payments, typically for services or goods delivered to the beneficiaries.
Pre -authorization/pre-auth
Process of seeking payer's authorisation on the proposed set of goods, products and services and reservation of needed funds.
Provider
Service provider is a facility, professional, or entity that offers required services and bills insurers or the beneficiaries for the services provided.
Registry
A tamper proof, audited collection of entries with their provenance.
Reimbursement
Service delivery context in which beneficiary initially pays for the service expenses to the service provider, and then seeking reimbursement from their respective payer.
Schema
A JSON data structure that defines an entity as per OpenAPI 3.0 schema specifications.
Template
Message structure with placeholder for context dependent data variable that helps in standardising the message parsing on the network.
Technical Service Provider (TSP)
Organisation that offers specialised technical support, services, or solutions to assist HCX network participants like providers, payers, etc.
Third party administrator (TPA)
Third-Party Administrator (TPA) in healthcare manages administrative tasks, such as claims processing and provider network management, on behalf of health insurance companies or self-funded employers.
8 |
9 | Following sections provides details of the origins & need of the Health Data Exchange (HCX) effort.
10 |
--------------------------------------------------------------------------------
/hcx-domain-specifications/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: >-
3 | Domain data specifications and business policies to implement health claims
4 | data exchange
5 | ---
6 |
7 | # Domain Specifications
8 |
9 | This section focuses on **domain** **specifications** needed to realize the health claims data exchange. As detailed in the [key specification](../what-is-hcx.md#key-specifications) section, the most significant aspect of domain specification would be agreement on formats for data exchange (data models and any domain specific languages to assist standardisation) and terminologies (taxonomies) being used in those data models.
10 |
11 | In order to achieve this, in line with the key design principles detailed [here](https://hcxprotocol.io/governance/), the following key design guidelines are proposed for domain specifications:
12 |
13 | ## Key Design Considerations
14 |
15 | 1. Data specifications should be broken down to simpler fundamental units as far as possible.
16 | 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:
17 | * Leverage HL7/FHIR R4 specifications wherever possible
18 | * Leverage NRCES FHIR specifications where base FHIR specs need contextualization to the Indian context
19 | * Create minimal extensions needed in case both base FHIR and NRCES specs are not enough to support the use case
20 | * FHIR Document profiles appropriate for the protocol should be created composed of base FHIR resources
21 | 3. Data specifications should be created with the principle of minimalism and inclusivity. In order to achieve this:
22 | * 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.
23 | * Specs should use permissive terminologies/code binding strength as much as possible. E.g. in the [FHIR terminology construct](https://www.hl7.org/fhir/terminologies.html) (Section 4.1.5), if there’s a conflict in choosing between “extensible” and “preferred” strengths for a coding system, “preferred” should be chosen.
24 | 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:
25 | * 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.
26 | * Data specifications should allow for namespacing in field names to indicate the source/reason/category of the extended fields.
27 | 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.
28 |
29 | Based on these principles and design considerations, subsections below define the following key elements of the proposed domain specifications:
30 |
31 | 1. Domain Data Models
32 | 2. Terminologies (Code sets and Metadata standards)
33 | 3. Domain Specific Languages (DSLs)
34 |
35 | Details of Open Protocol and TechOps policies are covered in the [previous section](../hcx-technical-specifications/), and the details of Business Policy Specifications are covered in the subsequent section.
36 |
--------------------------------------------------------------------------------
/hcx-domain-specifications/domain-data-models/handling-processing-errors.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Handling domain/business processing related errors
3 | ---
4 |
5 | # Handling Processing Errors
6 |
7 | While the protocol related errors are expected to be handled as per [Error Response section in the Technical Specifications](../../hcx-technical-specifications/open-protocol/key-components-building-blocks/error-descriptions.md), this section provides detail on responding when there are errors during business processing of the request.
8 |
9 | An error in business processing will be responded using corresponding on\_\* callback containing corresponding response FHIR profile with following additional constraints:
10 |
11 | 1. **x-hcx-status** needs to be set to "response.error"
12 | 2. Error code in **x-hcx-errordetails** header needs to be set to "ERR\_DOMAIN\_PROCESSING" as mentioned in [Recipient error scenarios table](../../hcx-technical-specifications/open-protocol/key-components-building-blocks/error-descriptions.md#recipient-error-scenarios) in the Error Response section in the Technical Specifications.
13 | 3. Within the corresponding response FHIR profile {response\_resource}
14 | 1. Error status need to be indicated in {response\_resource}.**outcome** attribute
15 | 2. Details of error need to be carried in the corresponding {resopnse\_resource}.**error** attribute.
16 |
--------------------------------------------------------------------------------
/hcx-domain-specifications/implementation-guide.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: FHIR IG for the proposed eObjects and terminologies
3 | ---
4 |
5 | # FHIR Implementation Guide\*
6 |
7 | 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.
8 |
9 | Such a publication can be used to validate content against the implementation guide as a whole.
10 |
11 | The extended profiles and structures of the FHIR bundles and resources to be used in HCX are available [here](https://ig.hcxprotocol.io/v0.9/index.html).
12 |
--------------------------------------------------------------------------------
/hcx-domain-specifications/terminologies-code-sets-or-metadata-standards.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Code sets or domain metadata standards
3 | ---
4 |
5 | # Terminologies
6 |
7 | To achieve semantic interoperability, it is recommended that HCX data standards incorporate well established and suitable terminology and coding systems.
8 |
9 | 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.
10 |
11 | ## Guidelines
12 |
13 | * For Clinical resources (e.g. Condition, Procedure, Observations) - please refer to the guidance issued by NRCeS.
14 | * In India, SNOMED-CT is free for use by all as Clinical Terminology, while ICD codes are used for classifications.
15 | * Labs typically use LOINC codes
16 | * For other code/concepts in the FHIR based data standards, we would recommend guidelines as per [FHIR Terminology binding strength definitions (Section 4.1.5)](https://www.hl7.org/fhir/terminologies.html).
17 | * If any attributes are marked as “required” - then, use of the codes defined in the value sets
18 | * 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.
19 | * If marked as “example” - then the domain must agree and define a value set for usage.
20 | * ValueSet may be created derived from existing sets, either composed/included from the base or expanded.
21 | * 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.
22 |
23 | For the broader NDHM interoperability and conformance, HCX would align with domain specific guidelines published by NRCeS.
24 |
25 | The code systems/valuesets proposed by the HCX working groups are published as part of the [HCX FHIR Implementation Guide](https://ig.hcxprotocol.io/v0.9/valuesets.html). The IG and the code systems/valuesets are versioned and published independently of the HCX protocol.
26 |
27 | HCX switch provider or neutral protocol supporting organisations may host domain specific FHIR Terminology Services which the ecosystem can leverage to retrieve information and use, and validate resources as defined by the IG.
28 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Digital blueprint and building blocks to implement health claims network
3 | ---
4 |
5 | # Technical Specifications
6 |
7 | This section focuses on **Technical** **specifications** that are needed to realize the health claims network - Open Protocol and digital network management policies.
8 |
9 | Details of domain specifications and business policies are covered in the subsequent sections.
10 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/digital-network-policies.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Guidelines for technical operations of the network
3 | ---
4 |
5 | # Digital Network Policies
6 |
7 | To ensure smooth operation, data privacy and security of the message exchanges and adherence to SLAs, the HCX networks will need to follow certain technical operations guidelines. These are currently being worked upon by the technical working group and are expected to be released in the future version of the protocol
8 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Technology backbone for the Health Claims Data Exchange
3 | ---
4 |
5 | # Open Protocol
6 |
7 | As described in Key Specifications, Open protocol defines the technology backbone for the Health Claims Data Exchange. In order to fulfil architectural principles listed [here](https://hcxprotocol.io/governance/), the protocol needs to consider the following key design elements:
8 |
9 | ## Key Design Considerations
10 |
11 | * The protocol must be designed to support the asynchronous exchange of information to support the scale and asynchronous nature of processes in the industry
12 | * The protocol must support the federated deployment of multiple HCX instances.
13 | * In order to ensure the security and privacy of sensitive data
14 | * The protocol must allow for separation of transport (and any other common information) from sensitive information in the respective flows
15 | * The protocol must provide for encryption, signing, and auditing of relevant information
16 | * The protocol should allow creating unique identifiers for each message exchange
17 | * The protocol should allow related multiple messages that are part of a single business flow
18 | * 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
19 | * The protocol should be designed to allow for the inclusion of the new types of use cases
20 | * 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)
21 |
22 | Based on these principles and design considerations, subsections below define the following key elements of the proposed Open Protocol:
23 |
24 | 1. Registries - Definition of key registries needed for the functioning of the exchange.
25 | 2. Health Claims data Exchange (HCX) Protocol - Details of the exchange flows including terminologies used, key constructs, message structures, unbundled APIs and error handling.
26 | 3. Data Privacy and Security - Details of key security features of the protocol.
27 | 4. Audit and Reporting
28 |
29 | Following sub-section provides details on the HCX registries and different participant registries.
30 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/audit.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Overview of audit requirements on HCX
3 | ---
4 |
5 | # Audit and Reporting
6 |
7 | 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.
8 |
9 | #### Key Requirements:
10 |
11 | * 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.
12 | * The audit information stored should be made available through an API, so that the participating systems can query the audit log related to them.
13 | * 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.
14 | * It is recommended for HCX instances to have a configuration to control the amount of information that gets stored in the audit logs.
15 |
16 | Following section provides details of the HCX notification classification, structure, and triggers.
17 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/data-security-and-privacy/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Details of mechanisms to ensure data security and privacy
3 | ---
4 |
5 | # Data Security and Privacy
6 |
7 | 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).
8 |
9 | There are many language specific libraries available that can help you implement the required encryption/signing/verification that is described above.
10 |
11 | In order to achieve this, various approaches are defined in the [subsequent sections](transport-security.md).
12 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/data-security-and-privacy/transport-security.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: TLS as default mode of communication
3 | ---
4 |
5 | # Transport Security
6 |
7 | 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.
8 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Building blocks of the Health Claims Data Exchange protocol
3 | ---
4 |
5 | # Claims Data Exchange (HCX) Protocol
6 |
7 | This section defines the following key building blocks of the data exchange protocol:
8 |
9 | 1. Message Flows: Details of various message flows and steps involved
10 | 2. Message Structure: Components of the protocol messages and their details
11 | 3. API structure: Details of the protocol APIs that facilitate the exchange
12 | 4. Error handling: Types of protocol errors, list of error codes and their descriptions
13 |
14 | Following sub-section provides details of the various data exchange scenarios, workflows, and stakeholders involved in each exchange.
15 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/api-structure/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Specifications of API for Claims Exchange in the HCX Ecosystem
3 | ---
4 |
5 | # API Specifications\*
6 |
7 | This section provides details about the following API categories designated for implementation and utilization by participants within the HCX ecosystem for claims exchange:
8 |
9 | * Registry APIs: Manage and access participants & users data in the HCX ecosystem.
10 | * Primary Flow APIs: Facilitate the core processes and workflows crucial for claims exchange.
11 | * Supporting APIs: Provide auxiliary functionalities and support for operations within HCX.
12 | * Notification APIs: Enable communication and alerts related to claims & other activities within HCX.
13 | * Third Party Information Sharing APIs: Enable exchange of claim related information among participants in the HCX ecosystem.
14 |
15 | ## API Structure
16 |
17 | Based on the protocol definition and the message structure, all APIs in the HCX ecosystem follow the following pattern:
18 |
19 | \://\/\\/\, where
20 |
21 | * **transport\_protocol** - for currently published versions, it will always be **https**
22 | * **server\_address** is the address of the server on which the API is called (an HCX for payor/provider or a payor/provider/HCX for an HCX)
23 | * **protocol\_version** - API version for the current protocol to help support protocol transitions
24 | * **resource\_name** is the name of the registry entity, domain resource or other objects that the API is serving. E.g. for claims, it may be “coverage eligibility”, “claims”, etc; for registries, it may be "participant" or "user".
25 | * **action** is the action sought within the context of the resource. E.g. for claims, it may be "check" (for checking coverage eligibility), "submit" (for submitting a pre-auth or a claim request), etc; for registry entities, it may be "create", "read", "search", etc; for notifications, it may be "subscribe", "unsubscribe", "notify", etc.
26 | * **on\_action** is applicable for asynchronous APIs, where the response to the API is sent asynchronously by the receiving system for responding to the original message. All the primary flow and supporting APIs have the asynchronous behaviour and will have an "on\_action" API for every "action" API. E.g. "coverageeligibility/on\_check" as response to "coverageeligibility/check", "claim/on\_submit" as response to "claim/submit", etc.
27 |
28 | Following subsections elaborates on the various API endpoints within each category, their request and response formats, along with additional details.
29 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/api-structure/primary-flow-apis.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Details of the APIs that facilitate the claims exchange flow
3 | ---
4 |
5 | # Primary Flow APIs
6 |
7 | ### **CoverageEligibility**
8 |
9 | * **Eligibility check**
10 | * /coverageeligibility/check (provider->HCX, HCX->payor)
11 |
12 | {% swagger src="https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml" path="/coverageeligibility/check" method="post" %}
13 | [https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml](https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml)
14 | {% endswagger %}
15 |
16 | * /coverageeligibility/on\_check (payor->HCX, HCX->provider)
17 |
18 | {% swagger src="https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml" path="/coverageeligibility/on_check" method="post" %}
19 | [https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml](https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml)
20 | {% endswagger %}
21 |
22 | ### **Claims**
23 |
24 | * **PreDetermination submission**
25 | * /predetermination/submit (provider->HCX, HCX->payor)
26 |
27 | {% swagger src="https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml" path="/predetermination/submit" method="post" %}
28 | [https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml](https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml)
29 | {% endswagger %}
30 |
31 | * /predetermintation/on\_submit (payor->HCX, HCX->provider)
32 |
33 | {% swagger src="https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml" path="/predetermination/on_submit" method="post" %}
34 | [https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml](https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml)
35 | {% endswagger %}
36 |
37 | * **PreAuth submission**
38 | * /preauth/submit (provider->HCX, HCX->payor)
39 |
40 | {% swagger src="https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml" path="/preauth/submit" method="post" %}
41 | [https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml](https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml)
42 | {% endswagger %}
43 |
44 | * /preauth/on\_submit (payor->HCX, HCX->provider)
45 |
46 | {% swagger src="https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml" path="/preauth/on_submit" method="post" %}
47 | [https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml](https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml)
48 | {% endswagger %}
49 |
50 | * **Claim submission**
51 | * /claim/submit (provider->HCX, HCX->payor)
52 |
53 | {% swagger src="https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml" path="/claim/submit" method="post" %}
54 | [https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml](https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml)
55 | {% endswagger %}
56 |
57 | * /claim/on\_submit (payor->HCX, HCX->provider)
58 |
59 | {% swagger src="https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml" path="/claim/on_submit" method="post" %}
60 | [https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml](https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml)
61 | {% endswagger %}
62 |
63 | ### **Payments**
64 |
65 | * **Payment notice and acknowledgement**
66 | * /paymentnotice/request (payor>HCX, HCX->provider-)
67 |
68 | {% swagger src="https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml" path="/paymentnotice/request" method="post" %}
69 | [https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml](https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml)
70 | {% endswagger %}
71 |
72 | * /paymentnotice/on\_request (provider->HCX, HCX->payor)
73 |
74 | {% swagger src="https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml" path="/paymentnotice/on_request" method="post" %}
75 | [https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml](https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi_hcx.yaml)
76 | {% endswagger %}
77 |
78 | Following [OpenAPI 3.0 specification](https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi\_hcx.yaml) details these APIs in detail. These API specs can be opened in swagger editor via this [link](https://editor.swagger.io/?url=https://raw.githubusercontent.com/hcx-project/hcx-specs/v0.9/API%20Definitions/openapi\_hcx.yaml).
79 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/exchange-protocol/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Details of various types of message flows and steps involved
3 | ---
4 |
5 | # Message Flows
6 |
7 | ## **Key Terms**
8 |
9 | 1. **Request** - Initiation of the flow by the sender by passing relevant payload in the message structure defined by this protocol. Requests may travel from Sender to the Receiver through a relay of HCX instances.
10 | 2. **Response** - Response/reply by the recipient of the request by passing relevant response payload defined by the protocol. The key difference here is that it is always in response to an earlier event received from the HCX instance and needs to carry the correlation\_id from the original event. Responses may also travel from the “original request message” recipient to the “original request message” sender through a relay of HCX instances.
11 | 3. **HCX instance** - A runtime of the HCX platform that performs the role of message receiving and forwarding on behalf of senders and receivers. Based on the use case, any participating party may act as the sender (thereby a requester), or a receiver (thereby a recipient). E.g. for the cashless claims use cases defined so far - Providers will be the senders in case of CheckEligibility, PreAuth and ClaimSubmission use cases (and the payers will be recipients), while Payers will be the sanders in case of PaymentNotice (and the providers will be recipients).
12 | 4. **Message** - HCX protocol transfers a Message that contains a transport envelope and the content as per the use case.
13 | 1. Transport envelope is a set attribute that carries the transport information for HCX to reliably forward the message to the destination
14 | 2. Content would have two parts:
15 | 1. Business headers - any domain or use case specific information which may not be necessary for the transportation but allows more information about the payload, e.g. type of the payload
16 | 2. Payload - Domain object defined for the pertinent use case. Usually, this data will be encrypted using the recipient's key to ensure that HCX instances cannot view this data.
17 | 5. **Senders and Receivers** - Two systems participating in the information exchange. They may also be referred to as client/server as per current industry terminology. E.g. Provider(s) are senders in claims flow use case, and Payor(s) are senders in Payment Notice use case in the flow diagram above.
18 |
19 | Following sub-sections provide details on the primary and alternate flows on the data exchange.
20 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/exchange-protocol/additional-message-flows/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Description of alternate flows envisioned in the protocol
3 | ---
4 |
5 | # Additional Message Flows
6 |
7 | The alternate flows are a deviation from the main claims flow on HCX. These flows detail out the protocol when certain conditions or events disrupt the normal progression of the process.
8 |
9 | Alternate flows are typically defined to handle exceptional or unusual situations such as exception handling, different user interactions, or error handling. HCX protocol deals with following alternate flows :
10 |
11 | 1. Redirect
12 | 2. Forward
13 | 3. Relay
14 | 4. Intra-cycle Communication
15 | 1. Claim Supporting Info
16 | 2. Obtaining beneficiary consent
17 | 3. Seeking account information
18 |
19 | These alternate flows help to make the system robust and ensure that it can handle a variety of situations, providing a more comprehensive and reliable user experience.
20 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/exchange-protocol/additional-message-flows/forward.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: >-
3 | Forwarding the message to one or more participants to seek inputs in
4 | processing
5 | ---
6 |
7 | # Forward
8 |
9 | After the original message is received and acknowledged by the receiver, the receiver may forward the request to multiple parties for processing and get their responses before finally responding to the original requestor (sender).
10 |
11 | A forward flow would have the following steps:
12 |
13 | 1. Current Recipient \[R] reads the message from sender \[S] and identifies that it requires help from other parties for processing.
14 | 2. Recipient \[R] creates the message to be forwarded to the next Recipient \[R1].
15 | 3. \[R] sends across the message to \[R1] by marking appropriate recipient details to HCX. The message needs to carry the same correlation\_id as included by the sender \[S] in step 1.
16 | 4. HCX checks the validity of correlation\_id (that it is initiated by a sender and is open for processing) and forwards the message to the \[R1].
17 | 5. \[R1] responds to \[R]
18 | 6. \[R] may repeat steps 2-4 for multiple next recipients (\[R2], \[R3], …) in parallel or sequentially and receive responses.
19 | 7. \[R] processes responses from all forwarded requests and respond with the final response to \[S]
20 |
21 |
22 |
23 | Following section provides details of the alternate communication flows to get additional information, obtain consent, etc. through HCX.
24 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/exchange-protocol/additional-message-flows/information-reporting-and-fetching.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: >-
3 | Enabling use cases for sharing information related to claims with other
4 | participants
5 | ---
6 |
7 | # Third party Information sharing
8 |
9 | There are multiple use cases in the context of claims where certain information about the claims need to be shared to parties that are not directly involved in the claim processing cycle. Some such examples are:
10 |
11 | * Regulators like IIB need to collect information about the processed claims at the completion of a claims cycle. IIB uses this information to help the insurance industry with information and analytical support.
12 | * Sponsors like NHA/SHA/Corporate/Community need to know about completion and details of a claims cycle for all the patients sponsored by them.
13 | * An ISNP needs to know the status and details of a claim on behalf of its patient.
14 |
15 | Such information can be made available to the interested parties in either of the following ways in HCX:
16 |
17 | 1. Parties involved in the cycle can report the information to all the subscribed parties when a claim cycle is completed
18 | 2. Parties who need information about a claim cycle can fetch the information from involved parties after the completion of a claim cycle (this is mostly be triggered when the interested party receives the relevant workflow notification)
19 |
20 | ### Information Reporting
21 |
22 | Information reporting can be enabled by leveraging the [notifications](../notification-specs-proposal/) capability of the protocol. Since the information to be reported may contain PII information of the patients & other sensitive information, the “PII carrying workflow notification” category of notifications should be used for this purpose.
23 |
24 | The steps and process for PII carrying workflow notifications are detailed in the [Notification specifications](../notification-specs-proposal/categories.md#workflow-notification).
25 |
26 | ### Fetching Information
27 |
28 | Though a mechanism to report information is available, there still may be some scenarios where the parties may need to fetch the required information on demand (e.g.: if the PII notification is not delivered due to technical problems). In such cases, there should be a way for the participants to fetch the required information by directly querying the involved party (a payor or a provider). As the current known use cases for information fetching are only around claim workflows and such information request can be fulfilled by sending the information in form of an ExplanationOfBenefit (EOB) resource, the protocol includes APIs to fetch claims related information using EOB resource. Details of these APIs are available [here](broken-reference).
29 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/exchange-protocol/additional-message-flows/intra-cycle-communication/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Additional communication to aid claim processing
3 | ---
4 |
5 | # Intra Cycle Communication\*
6 |
7 | HCX protocol facilitates the intra cycle communication among stakeholder for claim related clarifications. Participants can leverage communication request/on\_request API pair for these information exchanges. Intra cycle communication may be needed for following purposes :
8 |
9 | 1. Claim related supporting information and documentation
10 | 2. Seeking beneficiary consent for claim processing
11 | 3. Getting beneficiary or provider payment account information
12 |
13 | Following section will provide more details on each of the communication reasons.
14 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/exchange-protocol/additional-message-flows/intra-cycle-communication/seeking-account-information.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Seeking payment account information to help process the payment
3 | ---
4 |
5 | # Seeking Account Information
6 |
7 | This can be enabled via the Communication cycle between the payor and the TSP.
8 |
9 | Ref. : [Seeking support information sequence diagram for detailed workflow.](seeking-supporting-information.md)
10 |
11 | Communication Request
12 |
13 | 1. about: reference to the pre-auth, predetermination, claim for which the communication is requested
14 | 2. reasonCode: use the code “Payment Account Information” in the [Communication Reason codes](https://ig.hcxprotocol.io/v0.9/ValueSet-communication-reason-codes.html) valueset
15 | 3. payload.contentString: optionally, send a description about the request
16 |
17 | Communication Response
18 |
19 | 1. about: reference to the pre-auth, predetermination, claim for which the communication is requested
20 | 2. reasonCode: use the code “Payment Account Information” in the [Communication Reason codes](https://ig.hcxprotocol.io/v0.9/ValueSet-communication-reason-codes.html) valueset
21 | 3. payload.contentReference: Send the payment account information in this element.
22 |
23 | Following section provides details of the relay usecase, when multiple HCXs are involved.
24 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/exchange-protocol/additional-message-flows/intra-cycle-communication/seeking-supporting-information.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: >-
3 | Seeking supporting information related to an original request (pre-auth or
4 | claim)
5 | ---
6 |
7 | # Seeking Supporting Information
8 |
9 | If a payer requires supporting information or documentation from the provider or beneficiary for pre-auth or claim adjudication, the payer can utilise the communication API pair to initiate and fulfil the data exchange. The communication reason codes for getting supporting information are [outlined in the HCX IG](https://ig.hcxprotocol.io/v0.9/ValueSet-claim-supporting-info-codes.html).
10 |
11 | The typical workflow for stakeholders to seek and share the required supporting information during pre-auth is as follows :
12 |
13 |
14 |
15 | Following subsection provide details of the seeking beneficiary consent use case.
16 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/exchange-protocol/additional-message-flows/redirect.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Redirection of the message to another participant
3 | ---
4 |
5 | # Redirect
6 |
7 | After the original message is received and acknowledged by the initial receiver, the receiver may choose to completely hand over the processing of the request to another entity (new receiver). The receiver can achieve this by informing the sender to send (i.e. redirect) the request to the new receiver.
8 |
9 | Redirect flow would have the following steps:
10 |
11 | 1. Current Recipient \[R] reads the message from Sender \[S] and identifies that the request needs to be redirected to another entity \[R1] for processing.
12 | 2. \[R] response to the original request with a redirection response (using the status parameter in the header) \[S]. Redirection response includes the next recipient’s \[R1] details (participant id on the hcx platform).
13 | 3. \[S] sends a new request to \[R1] by re-encrypting the request using the \[R1] key and marking the appropriate participant id to HCX.
14 | 4. HCX forwards the new request to \[R1]. Further processing of the request is handled by the recipient \[R1].
15 |
16 |
17 |
18 | Following section provides details of the leveraging forward claims construct on HCX.
19 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/exchange-protocol/additional-message-flows/relay.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Scenario involving multiple HCX switches between sender and the receiver
3 | ---
4 |
5 | # Relay
6 |
7 | In case Sender and receiver are listed/registered on different HCX instances, there may be request/response relays between the HCXs. Steps 2, 5, 8 and 11 in the below diagram may involve such relays. The diagram below provides an example of a provider-payor use case with a relay between two HCXs.
8 |
9 |
10 |
11 | The cross gateway communication will be required in the following scenarios –
12 |
13 | 1. When a provider is onboarded in a gateway instance but the payer for that health policy scheme is registered in another gateway instance.
14 | 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.
15 | 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.
16 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/exchange-protocol/notification-specs-proposal/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Specifications to enable participant notifications on HCX
3 | ---
4 |
5 | # Notifications
6 |
7 | ### Context
8 |
9 | As a facilitator of the value between various participating entities, while HCX is envisioned to help different participants directly exchange the claims related information in standardised manner, the network would benefit further if the relevant information about such exchanges could also be shared with other interested/relevant participants in a safe and secure manner. Example of such information could be onboarding/de-boarding of participants, information about participant system maintenance/upgrades, availability of new functionality, or specific information needed by a participant on a particular claims use case - e.g. Regulator (IRDA/IIB) or Sponser (NHA/SHA/Corporate/Community) needing to know about completion of a claims cycle, or an ISNP needing to know status of a claim on behalf of its beneficiaries.
10 |
11 | Key benefits of such a notification infrastructure would be:
12 |
13 | 1. Operational efficiency
14 | 2. Transparency
15 | 3. Trust in ecosystem
16 | 4. Better user experience
17 | 5. Better participant support
18 |
19 | This section of the specification describes such needs and proposed enhancements to facilitate such information exchange in the network.
20 |
21 | ### Abstract
22 |
23 | Event driven notification can enable valuable near real time information for the HCX network participants in a privacy preserving and secure manner. This proposal outlays the enhancements in the protocol to detail the approach and proposed APIs and data structures to achieve such notification capabilities. Key capabilities proposed to be included are:
24 |
25 | 1. Classification of key notification types
26 | 2. Notification templates/data structure
27 | 3. Notification registry (a set of predefined notifications mapped with access control)
28 | 4. Subscribe/Unsubscribe APIs
29 | 5. Notify APIs
30 | 6. Guidelines for policies related to notification capabilities
31 |
32 | As part of the overall HCX specifications, the Notification delivery specifications are designed keeping in mind the HCX design principles listed [here](https://hcxprotocol.io/governance/).
33 |
34 | Following sub-section provides details on the key notification categories and their triggers.
35 |
36 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/key-components-building-blocks/exchange-protocol/primary-message-flow.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Details of the key data exchange flow on HCX
3 | ---
4 |
5 | # Primary Message Flow
6 |
7 | HCX protocol is designed for the exchanges to work in an asynchronous manner (like SMTP), therefore each use case will be completed in a cycle of messages as detailed below:
8 |
9 |
10 |
11 | **Sender to HCX (Leg 1)**
12 |
13 | * **The sender** (originator of the communication) sends the initial message to its preferred HCX instance.
14 | * HCX validates the status of the sender and the next intended recipient (maybe another HCX instance) on its registries.
15 | * HCX then performs required signature verifications etc before responding with an acknowledgement to the sender.
16 | * It then forwards it to either the end recipient (if registered with the same instance) or the next HCX in the chain.
17 |
18 | Steps 1 and 7 in the above diagram are examples of this leg.
19 |
20 | **HCX to Receiver (Leg 2)**
21 |
22 | * Final HCX in the relay chain (could be the original HCX itself) checks the status of the recipient on its registries,
23 | * performs needed verifications and forwards the message to the recipient.
24 | * The recipient acknowledges the receipt of the message.
25 |
26 | Steps 3 and 9 in the above diagram are examples of this leg.
27 |
28 | **Receiver to HCX (Leg 3)**
29 |
30 | * **The recipient** (receiver of the original request message) sends the response message to its preferred HCX instance.
31 | * HCX validates the status of the recipient and original sender (maybe another HCX instance) on its registries.
32 | * HCX then performs required signature verifications etc before responding with an acknowledgement to the recipient.
33 | * It then forwards it to either the initial sender (if registered with the same instance) or the next HCX in the chain.
34 |
35 | Steps 4 and 10 in the above diagram are examples of this leg.
36 |
37 | **HCX to Sender (Leg 4)**
38 |
39 | * Final HCX in the relay chain (could be the original HCX itself) checks the status of the original sender on its registries,
40 | * Performs needed verifications and forwards the response message to the sender.
41 | * The sender acknowledges the receipt of the response message.
42 |
43 | Steps 6 and 12 in the above diagram are examples of this leg.
44 |
45 | As indicated in the [**overall message flow diagram**](primary-message-flow.md#overall-message-flow-diagram), the exchange platform will be the routing engine that will be responsible for receiving the data from either participant (provider, payor, another HCX instance, ...), performing necessary validations, and forwarding it to the intended recipients.
46 |
47 | Following subsections will provide details about the alternate flows facilitated by HCX.
48 |
--------------------------------------------------------------------------------
/hcx-technical-specifications/open-protocol/notification-specs-proposal/terminology.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Key terminologies used in notifications
3 | ---
4 |
5 | # Terminology
6 |
7 | **HCX Network**: In the context of HCX, HCX network refers to instances of an HCX and its participating systems governed by a common network policy.
8 |
9 | **HCX Switch**: Instance of the HCX gateway, implemented as per the HCX protocol, that facilitates the information exchange between its participants.
10 |
11 | **Network participants**: Any platform that has implemented the HCX protocol and becomes the part of a network as above.
12 |
13 | **Schema**: A JSON data structure that defines an entity as per OpenAPI 3.0 schema specifications.
14 |
15 | **FHIR Profile**: A JSON data structure that defines a domain model eligible to be carried as part of JWE payload in the HCX protocol APIs.
16 |
17 | **Notification**: A logical unit of information sent to relevant network participants. Notifications can be triggered by an event, activity or time trigger on the network.
18 |
19 | **Template**: Message structure with placeholder for context dependent data variable that helps in standardising the message parsing on the network.
20 |
21 | **Notify**: Act of sending a notification.
22 |
23 | **Registry**: A tamper proof, audited collection of entries with their provenance.
24 |
25 | ###
26 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Operating policy guidelines for key business processes on HCX
3 | ---
4 |
5 | # Business Policy Specifications
6 |
7 | 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 are:
8 |
9 | 1. Onboarding
10 | 2. Defaulting & De-boarding policies
11 | 3. Dispute resolution policies
12 | 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.
13 | 5. Business SLAs
14 | 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
15 | 7. Service rating policies - What would be the parameters and mechanisms to rate each type of actor on the data exchange.
16 |
17 | HCX networks will be a crucial element in India’s health system and as such will need to enable health system objectives/goals, for example-
18 |
19 | * Universal health coverage,
20 | * Improved health outcomes (levels & equity),
21 | * Make the system responsive to individuals, families, and communities,
22 | * Deliver social & financial protection
23 | * Efficiency
24 |
25 | (adapted from [World Health Report 2000: Health Systems : Improving Performance](https://www.who.int/publications/i/item/924156198X))
26 |
27 | 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:
28 |
29 | ## Key Design Considerations
30 |
31 | 1. Policies should focus on enabling the ecosystem rather than monitoring or controlling it
32 | 2. Policy formulation should be done as an open consultative process to foster trust in policies
33 | 3. Rules of participation and disqualification should be transparently laid out
34 | 4. They should follow the principle of minimalism and be evolved over a period of time
35 |
36 | Following sections provide the current set of guidelines on the key aspects on network policies as mentioned above.
37 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/guidelines-for-beneficiary-authentication-by-providers-payors.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Beneficiary authentication valid instruments
3 | ---
4 |
5 | # Guidelines for Beneficiary Authentication by Providers/Payors
6 |
7 | ## Aadhaar Digital eKYC API
8 |
9 | Authentication of beneficiaries by providers on provider TMS/beneficiary APP.
10 |
11 | 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.
12 |
13 | ## Optional Aadhaar Authentication (mobile OTP/biometric)
14 |
15 | Authentication of beneficiaries by providers on provider TMS/beneficiary APP
16 |
17 | 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.
18 |
19 | The payer TMS system and HCP will integrate the Aadhar authentication open API for verification of the beneficiary ID during the claim validation stage.
20 |
21 | ## Verifiable Govt ID based verification (DL/PAN/Voter ID)
22 |
23 | Authentication of beneficiaries by providers on provider TMS/beneficiary APP
24 |
25 | 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 enrolment of beneficiary in their systems and validate the beneficiary ID during claim processing
26 |
27 | ## Token based authentication by Payer
28 |
29 | 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.
30 |
31 | ## Direct Authentication by Payer
32 |
33 | 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.
34 |
35 | #### Next Steps
36 |
37 | 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.
38 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/guidelines-for-event-audits.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Standard and goals of the audit processes on HCX.
3 | ---
4 |
5 | # Guidelines for Event audits
6 |
7 | 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 provenance, immutability, non-tamperability, and non-repudiability.
8 |
9 | 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.
10 |
11 | #### Next Steps
12 |
13 | 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.
14 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/guidelines-for-grievance-redressal/guideline-process-for-dispute-resolution.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Envisioned guideline process for dispute resolution
3 | ---
4 |
5 | # Guideline process for dispute resolution
6 |
7 | ### Objectives
8 |
9 | * Build a better dispute resolution experience for digital claims
10 | * Aim for 95% of the claims disputes related to the scope as outlined in the document for Phase 1 to be resolved before reaching IGMS/ombudsman
11 |
12 | {% hint style="info" %}
13 | In subsequent phases, the dispute resolution system referred to in this document would aim to integrate with the dispute resolution processes instituted by IRDAI to provide a comprehensive dispute resolution process for the ecosystem.
14 | {% endhint %}
15 |
16 |
17 |
18 | ### Guideline Process
19 |
20 | Key idea of the process given below are:
21 |
22 | * The HCX resolution platform implementation should aim to provide a single window (digital) to log all disputes and track status
23 | * All participants in the HCX ecosystem should adhere to lodging all disputes mentioned in the scope through the HCX resolution platform only
24 |
25 | The following table provides an illustration of steps and SLA time for HCX network dispute resolution. Please note that it is intended to serve as a guide and may be further extended/customised by the HCX operators to suit the ecosystem needs.
26 |
27 |
Step
Process
Proposed Timeline
Participants
1
Dispute is lodged
Day 0
Complainant, HCX, Defendant
2
Parties in the dispute are informed. Parties
Provide information to the discovery file
Provide consent to get information from third parties including HCX switch operator to populate the discovery file
In-built consent from complainant
Day 2
3
Discovery file is created with inputs from all parties involved
Responses and counter arguments from the defendant and complainant. (there should be limit to frequency (maximum two times) of queries to be raised by insurer , as it will be difficult for the claimant to respond multiple times )
Day 15
Complainant, Defendant, Arbitrator
28 |
29 | #### Activities to aid dispute resolution
30 |
31 | * Contractual agreement from all the stakeholders to adhere to the terms and conditions of HCX dispute resolutions framework.
32 | * Reference contractual templates for Terms of Use and proposed addendums to Payer-Provider and Payer-Policyholder contract have attempted to cover these aspects in a contractual format to help seed the ecosystem.
33 | * Escalation SOP for entities not satisfied with HCX dispute resolution
34 | * Decision needs to be taken on the scope of HCX dispute resolution
35 | * Limited to arbitration
36 | * Enforcement of penalties on non-adherence of arbitration awards (Setting-up of TATs on acknowledgment, acceptance and implementation of arbitration awards)
37 | * Enforcement of compliance _(linked to adjudication, hence may not be in the scope)_
38 |
39 | {% hint style="info" %}
40 | ### HCX Switch Considerations
41 |
42 | The HCX switch needs to take into consideration the below mentioned points to play an effective role in dispute resolution
43 |
44 | Data storage: Data has to be stored by the HCX switch for a minimum period of \[5 years] to be able to provide data for any dispute resolution. Disputes on insurance claims in India can be filed upto a maximum of 3 years (Claim dispute comes under limitation act, and for three years if the customer doesn’t say anything he is said to have waived off his rights. Unless of course he has solid ground. Insurers need to maintain record for at least \[5 years].)
45 |
46 | \*\[] indicate the recommended value of the time period, however it may differ based on the context.
47 | {% endhint %}
48 |
49 | ###
50 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/guidelines-for-grievance-redressal/involved-participants.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: >-
3 | List of participants involved and their role in the above mentioned types of
4 | disputes
5 | ---
6 |
7 | # Involved participants
8 |
9 | | **Participant Type** | **Role** | **Comments** |
10 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------ | -------------------------------------------------------------------------------- |
11 | | Payors (Insurers) | Complainant/Defendant | HCX role: payer |
12 | | Health Care Providers | Complainant/Defendant | HCX role: provider |
13 | | Health Insurance Intermediaries - (Licensed) - E.g., Brokers & Corporate Agents | Complainant/Defendant | HCX role: \ |
14 | | Health Insurance Facilitators (No licence) - E.g., distributors, marketers, facilitators (Includes Master policy holders and institutions that provide coverage through group policies including self insurance schemes) | Complainant/Defendant | HCX role: member.isnp |
15 | | Third Party Administrators | Complainant/Defendant | HCX role: agency.tpa |
16 | | Arbitrators (Online Dispute Resolution Entities ) | Fast track arbitration process | Multiple entities to be empanelled by the HCX operator (HCX role: To be decided) |
17 | | HCX Switch Operator |
Complainant/Defendant
Data Provider
| HCX role: HIE/HIO.HCX |
18 |
19 | In addition, participants like IRDAI (IGMS system - the existing dispute resolution platform) and insurance ombudsman and grievance redressal system in healthcare being co opted in subsequent phases.
20 |
21 | {% hint style="info" %}
22 | Each participant in the above list will be mapped with HCX participnt roels mentioned in the [Access Control ](broken-reference)section.
23 | {% endhint %}
24 |
25 | Followign sections provides details on the proposed process to follow in the dispute resolution.
26 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/guidelines-for-grievance-redressal/next-steps.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Envisioned next steps to a robust dispute resolution process for the ecosystem
3 | ---
4 |
5 | # Next steps
6 |
7 | An effective and comprehensive digital dispute resolution system is vital to the success of HCX. While this document refers to the first phase - commercial health insurance for in-patient procedures, the end goal is to resolve a majority of insurance claims related disputes before it reaches the legal system. Initiatives like integrating with various existing and emerging grievance resolution mechanisms in the insurance and healthcare ecosystem is important for HCX to achieve this vision.
8 |
9 | Keeping this in mind, the policy guidelines workign groups would keep working to evolve the guidelines based on ecosystem needs. It would mainly cover following aspects:
10 |
11 | 1. Further simplification and posiible automation of the process
12 | 2. Broadening of scope for other use cases - reimbursement, OPD, etc.
13 | 3. Integration of HCX scope into the larger ecosystem process like **insurance ombudsman and other upcoming grievance redressal system in healthcare**
14 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/guidelines-for-grievance-redressal/scope-of-disputes.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Envisioned list of disputes whose resolution can be facilitated by HCX
3 | ---
4 |
5 | # Scope of disputes
6 |
7 | Initially envisioned List of Disputes HCX can assist with:
8 |
9 |
Dispute Category
Type of Dispute
Examples
Delays
TATs related disputes
Delay in submission of supporting documents e.g., hospital bills, discharge summary to the insurer
Delay in processing claims
Delay in communicating pre-authorization approval/rejections to the customers
Delays from HCX Switch Operator
Data Transmission Related
Disputes related to transmission failures (packet drop)Disputes related to transmission data mismatch between origination and receipt
Delay in data transmission
Data mismatch
Data transmission failure
Data Privacy
Disputes related to data privacy violation by an entity in the HCX ecosystem
Data sharing without consent
Data storage which is not in compliance with agreed standards
Policy Related (E.g., Onboarding )
Disputes related to the non compliance of HCX with respect to HCX policies
Examples
Onboarding entities not in accordance to HCX policies
HCX not agreeing to share data for dispute resolution
HCX not in compliance with contractual agreements like fast track arbitration
Enforcement of Data Standards
Disputes related to members of the HCX ecosystem not adhering data transmission standards
Non compliance with agreed data formats
10 |
11 | {% hint style="info" %}
12 | The list of disputes is not exhaustive and the categories may grow with subsequent iterations
13 | {% endhint %}
14 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/guidelines-for-operating-charges.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Guidelines on strategy for operating charges by the operators
3 | ---
4 |
5 | # Guidelines for Operating charges
6 |
7 | ### Operating charges/Pricing
8 |
9 | Like with any infrastructural offering, offerings of the operating entity (based on the ecosystem needs with the infrastructure) will evolve over time. Therefore the model pricing strategy needs to be flexible to provide for evolution of needs as the ecosystem evolves. E.g. in the beginning the objective may be higher integration and adoption rates, as time progresses need may be to provide new value added use cases/service, and it may further evolve to provide tighter (real time/near real time) SLAs.
10 |
11 | Operators may charge fees from participants in any of the methods commonly used by exchanges, depositories (for example, stock exchanges, commodity exchanges,stock depositories etc.). The methods could be the following or a combination thereof :
12 |
13 | 1. Listing and subscription
14 | 2. Fixed fee per claim or subscription slabs based on number of claims
15 | 3. Transaction/Claim specific fee based on special needs of a claim, say additional quantum of data exchanged, or number of times data is exchanged to settle a claim
16 |
17 | The pricing and choice of pricing models can be modified by the operator from time to time, reacting to competitive pressures and also to enhance the value delivered to its participants (customers)
18 |
19 | It may help to unbundle different aspects of the pricing strategy to allow needed flexibility in the strategy. The following categorisation of offerings gives a costing basis as also a justification basis for the adopted pricing. However, it is recommended that the pricing models be kept very simple and focused on just a few key, well understood drivers -
20 |
21 | **What (offerings) may be charged**
22 |
23 | 1. Registry maintenance and access, e.g.
24 | 1. Subscription to change notifications
25 | 2. Facilitating the claim submission process
26 | 1. Basic process - Simple cycle
27 | 2. Advance process facilitation, e.g.
28 | 1. Enabling forward/redirects for multi party processing facilitation
29 | 2. Auto status check and reporting to providers/ISNPs
30 | 3. In process communication for pre-auth/claims cycle etc.
31 | 3. Facilitating compliance reporting of the claims data, e.g.
32 | 1. Operating entity may run and maintain schedules against which it can search the data from the payers and forward to IIB, thereby easing the process for the payor)
33 | 4. Open data streams on the agreed data (data in protocol/domain headers)
34 | 5. Other innovating offerings
35 |
36 | **Who may get charged for each of these offerings**
37 |
38 | Here is the [list of key roles](https://docs.swasth.app/v1.1-draft/hcx-domain-specifications/healthcare-operations-policies/access-control-roles) envisioned in the current version of the HCXS specifications. While the list includes many roles, they can be high level categorized in following personas:
39 |
40 | 1. Claim Sender - providers
41 | 2. Claim Receiver - payers/sponsors
42 | 3. Processing helpers - TPAs, TSPs, ISNPs, other HCX instance
43 | 4. Observers - regulators, Sponsors, ISNPs, researchers
44 |
45 | In the current scenario, claim processing expenses are mostly borne by the payers, however, based on the nature of key offerings on HCX there may be a potential to levy charges to other roles too.
46 |
47 | **What could be the Basis and Quantum of charges**
48 |
49 | One way to think about it could be that actual pricing of an offering from an operator would be a function of many operational choices and best derived by the operator. There can be many models that may emerge - flat claim fee, flat transaction fee, or flat monthly fee, or mixed slabs etc. However the key aspect here would be that the pricing plan strategy is formulated using a robust governance process and transparently published in the public domain.
50 |
51 | RBI has also prescribed a guideline for a similar construct (Account Aggregator) in the financial domain ([Section 13, Account Aggregator master directive](https://rbi.org.in/Scripts/BS\_ViewMasDirections.aspx?id=10598)).
52 |
53 | It is generally felt that a transaction/claim value based pricing may not be justifiable for an infrastructure business in a high volume, evolved market.
54 |
55 | An infrastructure service may choose to estimate infrastructure costs and per transaction costs and translate that into a pricing model. Translating per transaction costing into a pricing model could include one or more of the following:
56 |
57 | 1. Listing and storage pricing per day/month/year - by estimating average transaction volumes and storage needs
58 | 2. Per transaction price, can also be aggregated into transaction volume slabs
59 | 3. Per claim price, where transactions per claim can be estimated/averaged out and aggregated into claim volume slabs
60 | 4. A subscription charge based on estimated transaction volumes
61 | 5. Other factors that may evolve with ecosystem usage
62 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/guidelines-for-slas-and-ecosystem-satisfaction.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Key considerations for ecosystem satisfaction with the HCX network
3 | ---
4 |
5 | # Guidelines for SLAs and ecosystem satisfaction
6 |
7 | Best practices for service SLAs for high volume transactions already exist as high volume exchanges have been around for many decades, and so has regulation for such exchanges (for example the stock exchanges, depositories and SEBI). It is recommended that the HCX adopts the SLAs currently in operation and publicly available from the likes of National Stock Exchange and NSDL/CSDL.
8 |
9 | HCX Operator should provider following SLAs in their agreements with the participants:
10 |
11 | * Uptime
12 | * Response times for transactions
13 | * Operation of Sandbox
14 | * Operation of helpdesk
15 | * Upgrade of software as per the latest specifications of HCX.while keeping backward compatibility
16 | * Data protection
17 |
18 | An HCX operator may not be able to impose SLAs on participants like payers, providers, or TPAs, as HCX has no control over these players. However, to improve the overall performance of the ecosystem, the HCX Operator could publish the following metrics on a periodic basis:
19 |
20 | * Average time for sandbox registration to sandbox certification by participant type
21 | * Average time for claim submission from patient discharge by providers
22 | * Average time for response from payor to providers for each applicabkle cycle (eligibility, predetermination, preauth, claim)
23 | * Average time for claim to cash by payor
24 | * Average time for response from providers for payor queries
25 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/next-steps.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Thoughts on further work on the HCX network policy guidelines
3 | ---
4 |
5 | # Next steps
6 |
7 | An HCX network would be an important infrastructure service for the healthcare industry. Its continued, predictable operation and evolution with the needs of the ecosystem would be essential for the smooth functioning of the participating health care system. Inability to do so can cause damage to the participating systems and the public they serve.
8 |
9 | Therefore, guiding policies for the network continues to be a focus area for the HCX Policy Guidelines working group, and more robust guidelines are expected in upcoming versions of the protocol.
10 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/participant-onboarding/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Process of onboarding network participants
3 | ---
4 |
5 | # Guidelines for Participant Onboarding\*
6 |
7 | {% hint style="info" %}
8 | This section has been enhanced to accommodate the scope and the requirements of [OPD and Reimbursement use cases](../../use-cases/), and address the on-ground provider onboarding realities. The key changes include:
9 |
10 | 1. **Addition of BSP Onboarding Recommendations:** To align with the evolving healthcare landscape, recommendations for onboarding Beneficiary Service Platforms (BSPs) have been incorporated.
11 | 2. Enhancement of "Non ABDM enrolled Providers with no ROHINI id": This section has been expanded to encompass a comprehensive approach to provider onboarding. It now includes verification processes involving both public and private payers, reflecting the current industry practice. This update acknowledges the practical realities of onboarding healthcare providers and ensures a more inclusive and adaptable onboarding process within the network.
12 | {% endhint %}
13 |
14 | 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.
15 |
16 | ### Key design considerations
17 |
18 | Building further from the key design considerations laid out for business policies in the HCX open specifications, the onboarding approach should:
19 |
20 | 1. Aim to enable rather than control the participation of the interested ecosystem actors.
21 | 2. Require minimal and necessary information, enough to prove the identity of the participant and enable working of the network. The process requirements should be non-discriminatory and at the same time require enough detail to keep out any frivolous organisations.
22 | 3. Needs to be simple and cost effective enough to encourage participation of entities working with low income segments.
23 |
24 | A list of different kinds of participants who would need onboarding into an HCX registry is provided in the [Access Control](https://docs.swasth.app/enhancements-policy-guidelines-group-phase-1/9EKhP0MBRjkQ0mAd1A3W/healthcare-operations-policies/access-control-roles) section above. Onboarding onto the HCX is envisioned as a two step process:
25 |
26 | 1. Sandbox - for compliance testing and certification
27 | 2. Go Live on live instances
28 |
29 | Diagrams below depicts the key steps in onboarding process across these two phases: Proposed onboarding process flow; Sections below provide high level description for each of these steps:
30 |
31 |
Envisioned onboarding process flow
32 |
33 | Following subsections provide high level description for each of these phases.
34 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/participant-onboarding/potential-de-boarding-scenarios.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Guidelines on potential deboarding scenarios
3 | ---
4 |
5 | # Potential De-boarding scenarios
6 |
7 | This section lists some of the deboarding scenarios that may be considered as part of the final deboarding policies by the HCX operators:
8 |
9 | 1. Involuntary deboarding of a participant initiated by Regulator/Legal Authority. Few examples:
10 | 1. Suspension/Deactivation of a provider by the regulator for fraudulent activities.
11 | 2. Suspension/Deactivation of a TPA or a Payer by IRDA
12 | 2. Involuntary de-boarding of a participant (mostly TSPs) initiated by HCX. Few cases:
13 | 1. Serious violation of HCX policies (e.g. grave SLA violation repeatedly)
14 | 2. Hacking attempts made by participants for unauthorized access, after an investigation by HCX
15 | 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).
16 | 3. Voluntary de-boarding of participants. Few examples:
17 | 1. A provider or payer shifting to another HCX
18 | 2. A provider or payer shuts down their business
19 | 3. A provider or payer merges with another entity listed on the exchange
20 |
21 | Please note that while the above list suggests a few of the scenarios for potential de-boarding of a participant, this process should be treated with utmost care and an elaborate warning mechanism should be kept in place whenever the de-boarding is not voluntary.
22 |
23 | 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 de-boarding of a participant.
24 |
25 | {% hint style="info" %}
26 | **Potential Next Steps on Guidelines for Participant onboarding**
27 |
28 | In future there may be further work on:
29 |
30 | 1. Inclusion of new type of members on HCX network and their respective verification processes.
31 | 2. Evolution of verification process for currently defined participants
32 | 3. Recommendations on ways to automate and simplify the onboarding process
33 | {% endhint %}
34 |
35 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/participant-onboarding/sandbox-process.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Phase 1 of the participant onboarding
3 | ---
4 |
5 | # Sandbox process
6 |
7 | The key goal of the sandbox is to help the participants test their software against the HCX protocol, and get certified to ensure interoperability and gain required trust by the other network participants.
8 |
9 | All participants including the HCX instance(s) and its participants are expected to go through certifications to ensure adherence/compliance to the specifications. However, as indicated later, the mode of compliance may vary based on the role of the participant. Compliance step would include:
10 |
11 | 1. Technical Compliance checks - API schema conformance, Security specification (Transport layer, API security, Message security) conformance
12 | 2. Domain Compliance checks - Payload schema conformance, Terminology compliance, Publication of extended terminologies
13 | 3. Process Compliance checks - Adherence to strategy/ approach/ guidelines/ recommendations on business policies
14 |
15 | Sandbox testing environment shall publish a set of test cases (test suite) for each type/role of the participant (payer, provider, etc.). It will require applicants to send a series of messages as defined in the test cases to the Sandbox. The system will analyze the messages received and mark the test as pass or fail as per the requirement of the test case. The sandbox system will provide a list of all messages and their testing status.
16 |
17 | The Sandbox environment(s) shall also include documentation and suggestions regarding the software libraries, tools and example implementations for encryption, FHIR resource generation, code generation and other new/complex parts of the HCX protocol. The sandbox portal would ensure that the participants are provided with all the necessary help to get started and complete the API integration.
18 |
19 | 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](https://sandbox.ndhm.gov.in/documents/NDHM\_Secure\_Application\_Development-Reference\_Document.pdf).
20 |
21 | Key steps for sandbox certification process would be:
22 |
23 | #### **Step 1: Sandbox Registration**
24 |
25 | The participants submit an online application to express their interest to access the chosen HCX sandbox. Sandbox registration/verification process is expected to be simpler than the production process to encourage newer ecosystem actors to try the benefits of the network.
26 |
27 | #### **Step 2: Provisioning of sandbox credentials**
28 |
29 | Once sandbox registration requirements are met, the participant id along with the sandbox access secret credentials will be provided. Participants are expected to keep the secret credentials safe and report any compromises at the earliest to the Sandbox operator.
30 |
31 | #### **Step 3: Mock API integration and testing**
32 |
33 | In this step, the participants integrate their respective claim processing platform applications with the sandbox HCX. This step could be done by software providers on behalf of their customers. This is a one time event/requirement from the solution provider, once they have tested and certified on the sandbox, the same solution can be utilized by multiple payers/providers willing to utilize HCX services.
34 |
35 | #### **Step 4: Test result review (tech, Domain, Process compliance)**
36 |
37 | In this step, the sandbox provider reviews the results of respective test cases and provides necessary feedback to the participant till the compliance is achieved.
38 |
39 | #### **Step 5 : Security Certification/Proof submission**
40 |
41 | Since HCX design principles demand complete security and privacy of the data exchanged safeguarding the personal information of the beneficiaries, it is critical to assess the security & privacy measures a solution provider has implemented. For this, the solution provider either can get a security compliance certificate from an entity like STQC or any other authorized SIs. The solution provider will be required to submit the certificate as a proof to the HCS operator sandbox committee to get a go ahead on access to the production APIs.
42 |
43 | #### **Step 6: Sandbox certification**
44 |
45 | 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.
46 |
47 | Once a participant successfully completes the sandbox process, they can use the certification to get onboarded to the HCX production environment and production access keys will be shared with the solution provider that can be used to integrate with the production APIs.
48 |
49 | {% hint style="info" %}
50 | HCX operator(s) may nominate or list Sandbox operator(s) whose certification will be considered valid for onboarding to their platforms.
51 | {% endhint %}
52 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/reference-templates/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: >-
3 | Compilation of reference contractual templates to facilitate better network
4 | experience
5 | ---
6 |
7 | # Reference Templates
8 |
9 | As discussed in multiple sections under Business policy specifications, policy guidelines working group has created following key templates to aid upcoming HCX network(s) in facilitating easier onboarding of participants and improve overall network experience to all the participants:
10 |
11 | 1. HCX - Terms of use: Template of HCX operators agreement with its participants
12 | 2. Addendum to Payer-Provider contracts: Template addendum to aid payers and providers to make their contracts FTA friendly.
13 | 3. Addendum to Payer-Policyholder contracts: Template addendum to aid payers in making their Policyholder contracts FTA friendly.
14 |
15 | Following subsections detail each of these templates:
16 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/reference-templates/hcx-terms-of-use.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: >-
3 | Guidelines on key terms for and draft template agreement between an HCX and
4 | its participants
5 | ---
6 |
7 | # HCX - Terms of use
8 |
9 | ### Approach
10 |
11 | The Terms of Use and Privacy Policy of an HCX will constitute the Agreement with its Participants. As there is no HCX operational, there is no such existing agreement to use as a reference. Therefore, the proposed temaplate below provides the needed reference template.
12 |
13 | In order to create the drafts of the templates, it is necessary to first identify the key terms of the relationship between the parties, i.e., the HCX and a participant. These key terms have been derived from the guidelines earlier specified in the business specifications:
14 |
15 | 1. [Guidelines for Participant Onboarding](../participant-onboarding/)
16 | 2. [Guidelines for Grievance redressal](../guidelines-for-grievance-redressal/)
17 | 3. [Guidelines for SLAs and Customer satisfaction](../guidelines-for-slas-and-ecosystem-satisfaction.md)
18 | 4. [Guidelines for Operating charges](../guidelines-for-operating-charges.md)
19 | 5. Other guidelines the the current business specifications
20 |
21 | In effect, the terms of use and privacy policy drafts are summaries of the above guidelines, couched in the form of legally binding contracts.
22 |
23 | In keeping with the endeavour to ensure rapid dispute resolution between all entities in the HCX, the drafts are being created so that they are FTA friendly. In order for the documents to be FTA friendly, they must be unambiguous and identify the potential disputes that could arise between an HCX and a Participant and the evidence needed by the parties to prove their case and, as far as possible, damage computation formulae.
24 |
25 | The aim is to create terms of use and privacy policy drafts that are documents that are model templates that any prospective HCX Operator can adopt as-is, though the Operator would, of course, be free to make modifications, or to adopt completely different terms. However, since these documents will have been vetted by the entire health claims ecosystem, it is unlikely that an operator would adopt entirely different terms.
26 |
27 | ### Template - [HCX Terms of use](https://docs.google.com/document/d/1XzCAaxNuPWGg1AXgf9-VTbhLumBjvdfxCC2pU4smUI4/edit?usp=sharing)
28 |
29 | {% embed url="https://docs.google.com/document/d/1XzCAaxNuPWGg1AXgf9-VTbhLumBjvdfxCC2pU4smUI4/edit?usp=sharing" %}
30 |
--------------------------------------------------------------------------------
/healthcare-operations-policies/reference-templates/payer-provider-addendum.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Guidelines On Enhancements in Payor/Provider Agreements
3 | ---
4 |
5 | # Payer-Provider addendum
6 |
7 | ### Approach
8 |
9 | The proposed template addendum aims to provide the needed clauses that payors and providers can use to make their contracts FTA friendly.
10 |
11 | An FTA friendly contract is one where, to the extent possible, the potential disputes that may occur between parties are anticipated, the evidence required by parties to prove their case is pre-defined, and so are the compensation computation mechanisms.
12 |
13 | The benefits of an FTA friendly contract are two-fold:
14 |
15 | 1. Because there is less ambiguity, it reduces the likelihood of parties getting into disputes
16 | 2. Even if a dispute does occur, having an FTA friendly agreement enables the adjudicator (arbitrator/tribunal/ombudsman/court) to quickly adjudicate the dispute, thereby reducing the time spent litigating.
17 |
18 | In order to do so, it is essential to first identify potential disputes. Based on a reading of the multi-party dispute document and the sample agreement, the following disputes could arise between a payer and provider:
19 |
20 | 1. Provider’s obligation to provide ‘reasonable care’ to the Members
21 | 2. Delayed payment of invoices by payor/defective invoice submitted by provider
22 | 3. Company’s right to levy penalty in the case of ‘proven error/omission’ by provider
23 | 4. Charges for services which are not detailed in the tariff list given by the provider to the payor.
24 |
25 | In addition, the temaplte addendum also contains suggestions for modification of certain other clauses in a payor-provider contract.
26 |
27 | In addition to the guidelines metioned in this document (specially the guidance for grievance redressal) the template is based on the [following sample agreement](https://docs.google.com/document/d/1QZdEANQ\_hAHqTJ9GAMkGDk1OpqLRzU0s50M5wftHKAA/edit) between a Payor and a Provider. The clauses referred to in the addendum have been taken from the sample agreement.
28 |
29 | ### Template - [Addendum to Payer-Provider contract](https://docs.google.com/document/d/13-NcL-TFSj2ownxDKc7X1GXU2wvwyk13\_F8GJNrux9Q/edit?usp=sharing)
30 |
31 | {% hint style="info" %}
32 | Payers may execute addendums in the case of existing contracts. For new contracts, Payers may simply incorporate the clauses mentioned in the addendum into their drafts.
33 | {% endhint %}
34 |
35 | {% embed url="https://docs.google.com/document/d/13-NcL-TFSj2ownxDKc7X1GXU2wvwyk13_F8GJNrux9Q/edit?usp=sharing" %}
36 |
--------------------------------------------------------------------------------
/how-to-submit-responses.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Key resources and guidelines to contribute
3 | ---
4 |
5 | # Contributing to the protocol
6 |
7 | As mentioned in the governance section, hcx-specifications are fundamental to the success of the envisioned claims network. Specifications need to create consensus amongst a broad base of health system stakeholders to ensure that they can act as this common foundation. Current specifications are a result of collaborative effort from many committed volunteers.
8 |
9 | We look forward to further strengthening the collaboration with border participation. Sections below provide the key resources and mechanisms to contribute to the specifications.
10 |
11 | ### Key resources
12 |
13 | Key resources for this version (v0.9) are available as follows:
14 |
15 | * [This GitBook documentation](./) is the reader friendly published documentation for the current version.
16 | * Source code for documentation and specifications is available in [this GitHub repo](https://github.com/hcx-project/hcx-specs/tree/v0.9).
17 | * Discussions about the specifications are in the github repo’s [discussion forum](https://github.com/hcx-project/hcx-specs/discussions) and on the [discord server](https://discord.gg/jxMTMh5RYw).
18 |
19 | ### Contributing to the specs
20 |
21 | #### Enhancement requests/ideas/suggestions/questions
22 |
23 | Please use the github discussion forum to ask questions, make suggestions, and raise enhancement requests. You can also participate in the existing discussion by appropriately commenting on the discussions of your interest.
24 |
25 | #### Use cases
26 |
27 | Please evaluate HCX protocol for newer use cases in health claims and recommend enhancements/changes to the protocol, if required, to enable the use case through HCX. For use cases evaluation, define the typical workflows of the use case and how they can be mapped through HCX protocol similar to the cashless and reimbursement usecases detials in this [section](how-to-submit-responses.md#use-cases).
28 |
29 | #### Raising issues
30 |
31 | Issues can be raised to bring attention to any shortcoming in the specifications ( e.g. API specifications, Domain Data specifications - eObjects, Documents, Value Sets, Implementation Guide etc.) using one of the following mechanisms:
32 |
33 | 1. A confirmed issue can be raised as a github issue against the repo [here](https://github.com/hcx-project/hcx-specs/issues).
34 | 2. If unsure about the issue, it can be raised as a discussion in GitHub or Discord with the community and can be converted to an issue on confirmation.
35 |
36 | We aim to make hcx-specifications one of the best open community projects with your help. In order to achieve this, we expect the participants to follow [GitHub's community Guidelines](https://docs.github.com/en/github/site-policy/github-community-guidelines) and adhere to the [GitHub Community Forum Code of Conduct](https://docs.github.com/en/github/site-policy/github-community-forum-code-of-conduct) while participating in the forum.
37 |
38 | If for some reason, you cannot raise issues using github, you can also send them via email to [contact@hcxprotocol.io](mailto:contact@hcxprotocol.io).
39 |
40 | However, to get the best assistance from the community, get timely responses and benefit everyone from the observations, we strongly encourage everyone to use the github forum. Please use [these instructions](https://docs.github.com/en/get-started/signing-up-for-github/signing-up-for-a-new-github-account) to sign up for a free github account, if you dont already have one. You can then write to us at [contact@hcxprotocol.io](mailto:contact@hcxprotocol.io) with your github id to include you as a part of the github community for the hcx-specifications.
41 |
42 | > This specification document can also be downloaded as a PDF for offline consumption. Instructions to download specifications as a PDF are available [here](https://docs.gitbook.com/features/pdf-export#export-entire-space).
43 |
--------------------------------------------------------------------------------
/readme-1.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Background of the Health Claims Data Exchange effort
3 | ---
4 |
5 | # Context
6 |
7 | ## Need for a new approach
8 |
9 | ### Overview of the Current Process
10 |
11 | The current health claims filing and processing experience is fairly manual in nature.
12 |
13 | Patients usually reach the health service provider and provide the provider with either the policy details or a card issued by the Payers. The provider 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 Payer (Insurance, TPA, …) typically over email. Several payers also provide providers with their own electronic portal where their claims can be submitted as an alternative to email.
14 |
15 | On receipt of the pre-auth/claim form, the Payer 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.
16 |
17 | A response to the pre-auth/claim is sent back to the provider over email. Payments are done electronically and notifications for payment advice are sent via email. Similar to the cashless procedures outlined here, reimbursement and other processes in health claims require considerable levels of manual intervention.
18 |
19 | Furthermore, most payer including 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 the payers.
20 |
21 | _(_[_Reference: NHA IRDAI Joint Working Group Report_](https://pmjay.gov.in/sites/default/files/2019-09/Sub%20Group%20on%20Common%20IT%20Infrastructure%20Report\_11-09-19.pdf)_)_
22 |
23 | ### Challenges of the Current Process
24 |
25 | * The current claims exchange process is not standardized across the ecosystem
26 | * Most data flow is PDF/manual
27 | * High variability of process between payers/insurer/TPA/provider
28 |
29 | This results in:
30 |
31 | * Multiple follow-ups, lack of visibility
32 | * Long receivable cycles
33 | * High cost of processing
34 | * Poor scalability
35 | * Poor patient experience
36 |
37 | Inspired by the [recommendations of the Joint Working Group of NHA and IRDAI (2019)](https://pmjay.gov.in/sites/default/files/2019-09/Sub%20Group%20on%20Common%20IT%20Infrastructure%20Report\_11-09-19.pdf), these specifications have been developed over the last two years by 120+ volunteers from across the healthcare ecosystem (including Insurers/payers, Hospitals, TPAs, Insurance Technology players and Think tanks), as a part of a transparent, collaborative and open effort anchored by Swasth Alliance.
38 |
39 | 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. The specifications are comprehensively evaluated for various health claims scenarios, including cashless and reimbursement procedures for both Inpatient (IPD) and Outpatient (OPD) treatments. This evaluation is conducted by volunteers from various sectors within the health claims industry. And there are plans to evaluate and incorporate additional use cases in the future.
40 |
41 | {% hint style="info" %}
42 | While the [recommendations of the Joint Working Group of NHA and IRDAI (2019)](https://pmjay.gov.in/sites/default/files/2019-09/Sub%20Group%20on%20Common%20IT%20Infrastructure%20Report\_11-09-19.pdf) refers to the concept as HCP (Health Claims Platform), working groups decided to choose the new name HCX (Health Claims Data Exchange) after the feedback from the ecosystem that an HCP would involve many more things than data exchange facilitation.
43 | {% endhint %}
44 |
45 | The next section provides high level details of the HCX vision, mission, & structure of the protocol.
46 |
--------------------------------------------------------------------------------
/use-cases/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Listing key use cases & their need
3 | ---
4 |
5 | # Use cases\*
6 |
7 | This section presents key health claims use cases that have been thoroughly analyzed by HCX community work streams for feasibility and implementation within the HCX protocol. These use cases are invaluable for the ecosystem as they provide a clear understanding and visualisation of the diverse health claims transactions that can be facilitated through HCX.
8 |
9 | Health claims are primarily categorised into the following groups:
10 |
11 | 1. OPD (Cashless & Reimbursement)
12 | 2. IPD (Cashless & Reimbursement)
13 |
14 | These use cases represent real-world scenarios and serve as essential reference points for stakeholders looking to leverage the HCX protocol effectively within their healthcare processes.
15 |
16 | Following subsections provide details about the typical workflows, reimagined workflows using HCX, & key considerations/challenges while implementing these use cases.
17 |
--------------------------------------------------------------------------------
/use-cases/cashless/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Provider led Health Claims process
3 | ---
4 |
5 | # Cashless
6 |
7 | Cashless health insurance allows policyholders/beneficiaries to receive medical treatment without having to pay upfront to the providers for the medical services/treatment. It covers both outpatient department (OPD) and inpatient department (IPD) expenses, providing financial relief to the beneficiaries.
8 |
9 | **Advantages of cashless claims :**
10 |
11 | 1. Improves patient experience : Cashless insurance enhances the overall beneficiary experience by streamlining the healthcare process. It reduces the administrative hassles of reimbursement claims and paperwork submission.
12 | 2. Financial relief : By covering medical expenses directly, cashless insurance reduces the financial burden on policyholders/beneficiaries during times of illness or emergencies.
13 | 3. Access to quality care : Cashless insurance often partners with a network of hospitals and healthcare providers, ensuring access to quality medical facilities and specialists for policyholders.
14 | 4. Prompt treatment : Beneficiaries can plan prompt medical treatment, without having to worry about arranging funds before getting the necessary care.
15 |
16 | **Challenges:**
17 |
18 | 1. Limited network : Cashless insurance poses a challenge when policyholders require immediate care from healthcare providers outside the insurer's network, leading to out-of-pocket expenses.
19 | 2. Pre-authorization delays : Delays in obtaining pre-authorization for medical procedures can hinder prompt treatment, causing inconvenience to policyholders and providers.
20 | 3. Exclusions and limitations on treatments/services : Cashless insurance often comes with exclusions and limitations on certain treatments or services, which can result in unexpected expenses for policyholders.
21 | 4. Upcoding, duplicate billing & falsified records : Dishonest practices such as upcoding, duplicate billing, and falsified records by healthcare providers can lead to inflated claims, potentially increasing premiums and affecting policyholders' trust in the system.
22 | 5. Frauds : Impersonation/identity theft, phantom service, etc.
23 |
24 | Following section provide details of the typical workflows for service delivery and cashless claim submission in both IPD and OPD.
25 |
--------------------------------------------------------------------------------
/use-cases/cashless/implementation-considerations.md:
--------------------------------------------------------------------------------
1 | # Implementation Considerations
2 |
3 | This section identifies the key workflow and data attribute considerations for implementing the cashless claims for both IPD and OPD usecases.
4 |
5 | **Workflow considerations :**
6 |
7 | The existing V0.8 version caters to all the workflow requirements for the reimagined claims workflows.
8 |
9 | **Data attributes considerations :**
10 |
11 | | Scenario | Remarks |
12 | | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
13 | | IPD vs OPD | Use the element “type” in the Claim object to identify whether the claim is an OPD or an IPD claim. The claim-type value set (binded to the “type” element) has a code “professional” which is meant to be used typically for outpatient claims from Physician, Psychological, Chiropractor, Physiotherapy, Speech Pathology, rehabilitative, consulting. |
14 | | | |
15 |
16 |
17 |
18 | **Future Considerations :**
19 |
20 | * Analysing/enhancing the protocol for non-insurance benefits - Corporate wellness, health CSR, community/cooperatives benefits
21 | * Analyse and expand for other OPD categories: Exploring other categories within the OPD use case, understanding their unique challenges, and enhancing the workflow to address specific nuances.
22 | * Understanding Master policy holder (MPH) as stakeholder : Cater and engage with MPH as stakeholders to understand their specific use cases and analyse/prescribe/enhance the HCX workflow and specifications to serve their needs.
23 |
--------------------------------------------------------------------------------
/use-cases/cashless/mapping-to-the-hcx-protocol/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Cashless Workflow on HCX
3 | ---
4 |
5 | # Mapping to the HCX Protocol
6 |
7 | This section provides details of how typical cashless IPD and OPD workflows can be enabled through HCX protocol. It also highlights the key implementation considerations while implementing these workflows on HCX.
8 |
9 | Through the implementation of these workflows via the HCX protocol, numerous challenges in cashless processing can be effectively tackled, significantly improving the overall quality and effectiveness of the services delivered and claims adjudicated. These improvements yield a range of benefits such as:
10 |
11 | * Enhanced provider network
12 | * Prompt coverage eligibility, pre-auth, & claim response
13 | * Transparency on policy eligibility
14 | * Enables payor systems to detect frauds
15 |
16 | Following sub-sections will provide detailed HCX enabled IPD and OPD workflows.
17 |
--------------------------------------------------------------------------------
/use-cases/cashless/mapping-to-the-hcx-protocol/inpatient-ipd.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Mapped IPD workflow through HCX protocol
3 | ---
4 |
5 | # Inpatient (IPD)
6 |
7 | The redesigned IPD cashless claims workflow, powered by the HCX protocol, provides a valuable insight into the seamless and efficient processing of claim requests. HCX brings interoperability and transparency in the claim adjudication process, ensuring that claims are handled promptly and effectively.
8 |
9 | Ref: [Typical IPD cashless claims workflow](../typical-workflows/inpatient-ipd.md)
10 |
11 | {% hint style="info" %}
12 | **Important note :** The work stream's original diagram representing the overall workflow of the reimagined IPD cashless using HCX is available [here](https://drive.google.com/file/d/1Upcz5oRkIK8loaqeeinw-eFY4au7MiJS/view?usp=drive\_link). Based on initial feedback for improving the readability, the sections below detail it in multiple diagrams representing each stage separately.
13 | {% endhint %}
14 |
15 | ### **IPD cashless claims through HCX**
16 |
17 | #### **Coverage eligibility flow**
18 |
19 | The coverage eligibility check for the beneficiary is usually the first stage in an IPD service delivery and claims process. HCX facilitates a structured and timely response to the coverage eligibility check request and response delivery for stakeholders. The following diagram describes the steps and stakeholders involved in the coverage eligibility flow.
20 |
21 |
22 |
23 | #### **Pre-auth flow**
24 |
25 | After the coverage eligibility process, the provider determines the required services or treatment plan for the beneficiary's requirements, along with the associated expenses, and submits it to the payer for pre-authorization. The following diagram provides an overview of the steps and stakeholders involved in the pre-auth flow.
26 |
27 |
28 |
29 | #### **Claims flow**
30 |
31 | Once the Provider has provided the services to the beneficiary in accordance with the treatment plan, it initiates the claim request with the concerned payer through HCX, furnishing the necessary information for the claim adjudication. The following diagram describes the steps and stakeholders involved in the claims flow through HCX.
32 |
33 |
34 |
35 | The next section describes OPD claims workflow leveraging HCX protocol.
36 |
--------------------------------------------------------------------------------
/use-cases/cashless/mapping-to-the-hcx-protocol/outpatient-opd.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Mapped workflow, key gaps identified and proposed protocol changes
3 | ---
4 |
5 | # Outpatient (OPD)
6 |
7 | The reimagined OPD cashless claims workflow leveraging HCX protocol help us understand how claim requests can processed timely and efficiently. Increased provider network coverage, real time updates and approval of the OPD claims will enhance adoption and trust in the system for policyholder.
8 |
9 | Ref: [Typical OPD cashless claims workflow](../typical-workflows/outpatient-opd.md)
10 |
11 | {% hint style="info" %}
12 | **Important note :** The work stream's original diagram representing the overall workflow of the OPD cashless claims workflow using HCX is available [here](https://drive.google.com/file/d/1cKb4gfqZjHib4vKOEjYIvcySl4KiO8hR/view?usp=sharing). Based on initial feedback for improving the readability, the sections below detail it in multiple diagrams representing each stage separately.
13 | {% endhint %}
14 |
15 | ### **OPD cashless claims**
16 |
17 | #### **Coverage eligibility flow**
18 |
19 | The OPD service delivery and claims process would usually start with the coverage eligibility (optional) check for the beneficiary. The following diagram shows the steps and stakeholders involved in the coverage eligibility flow.
20 |
21 |
22 |
23 | #### **Pre-auth flow**
24 |
25 | After the coverage eligibility process, the provider would determine the required services or treatment plan for the beneficiary's requirements, along with the associated expenses, and submits it to the payer for pre-authorization. The following diagram provides an overview of the steps and stakeholders involved in the pre-auth flow.
26 |
27 |
28 |
29 | #### **Claims flow**
30 |
31 | Once the Provider has provided the services to the beneficiary in accordance with the treatment plan, it initiates the claim request with the concerned payer through HCX, furnishing the necessary information for the claim adjudication. The following diagram describes the steps and stakeholders involved in the claims flow through HCX.
32 |
33 |
34 |
35 | The next section details the important implementation considerations for cashless health claims.
36 |
--------------------------------------------------------------------------------
/use-cases/cashless/typical-workflows/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Typical cashless workflows
3 | ---
4 |
5 | # Typical workflows
6 |
7 | Typical workflows outlines the series of tasks, processes, and interactions that takes place between different stakeholders throughout the cashless health claims cycle. These workflows represent usual operations and there can be some variation in the process based on different usecases.
8 |
--------------------------------------------------------------------------------
/use-cases/cashless/typical-workflows/inpatient-ipd.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Typical Inpatient (IPD) flow
3 | ---
4 |
5 | # Inpatient (IPD)
6 |
7 | Inpatient care, often referred to as the In-patient department (IPD), is a dedicated section within a healthcare facility specifically designed to deliver comprehensive medical care and treatment to patients or beneficiaries who require admission and an extended stay within the hospital. This department is equipped to provide specialized care for individuals whose medical conditions necessitate continuous monitoring, treatment, and support during their hospitalization.
8 |
9 | Typical/existing workflow for IPD service delivery and cashless insurance claim :
10 |
11 |
12 |
13 | **Workflow details :**
14 |
15 | 1. An individual/beneficiary schedules an appointment or arrives as a walk-in (emergency) at the healthcare provider's facility
16 | 2. The individual/beneficiary provides necessary details including insurance details, which may involve filling out a form or scanning a QR code to share relevant information.
17 | 3. **(Optional)** The Healthcare Provider initiates a coverage verification process by contacting the Payer to confirm the high-level service coverage, aiming to determine if the expected services are covered under the Individual's insurance plan.
18 | 4. **(Optional)** The payer responds back with coverage eligibility details of the plan.
19 | 5. The Healthcare Provider confirms the admission for the individual.
20 | 6. The individual proceeds with the check-in, registration, and finalisation of required service(s) based on their needs and preferences.
21 | 7. **(Optional)** The Healthcare Provider further engages with the payer to verify treatment coverage, seeking preauthorization for the proposed treatment/service plan and involved cost details as required by the insurance policy. Wherever applicable, this step may be repeated multiple times to signal change in treatment/service plan.
22 | 8. The payer responds back with the preauthorization response for each request alongwith the pre-authorized amount for each procedure, product, service, etc.
23 | 9. The healthcare provider provides the necessary services to the Individual, which may include a range of medical procedures, tests, administration of drugs, products, therapy sessions, or any other relevant treatments.
24 | 10. The healthcare provider initiates the claim submission process by forwarding the relevant details and documents to the payer.
25 | 11. The payer performs the on-the-spot adjudication to evaluate the submitted claim
26 | 12. The payer responds to the healthcare provider with either approval (full or partial) or rejection of the claim.
27 | 13. After receiving the claim response from the payer, the healthcare provider communicates the claim details to the individual, informing them about the approved services and any payment obligations that remain.
28 | 14. The beneficiary proceeds with any necessary payments, settling any remaining balance based on the coverage provided by the insurance policy, and subsequently concludes the treatment or service provision setting.
29 |
--------------------------------------------------------------------------------
/use-cases/cashless/typical-workflows/outpatient-opd.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Typical Outpatient (OPD) flow
3 | ---
4 |
5 | # Outpatient (OPD)
6 |
7 | The Outpatient Department (OPD) is a distinct component of a healthcare facility, such as a hospital or clinic, dedicated to delivering medical services to patients who do not necessitate overnight hospitalization.
8 |
9 | Within the OPD setup, healthcare professionals provide diagnosis, treatment, consultations, and a wide array of medical services to individuals with conditions that can be effectively managed without requiring an extended stay in the healthcare facility.
10 |
11 | Typical/existing workflow for OPD service delivery and cashless insurance claim :
12 |
13 |
14 |
15 | **Workflow details :**
16 |
17 | 1. An individual/Beneficiary schedules an appointment or arrives as a walk-in (emergency) at the healthcare provider's facility
18 | 2. The individual/Beneficiary provides necessary details including insurance details, which may involve filling out a form or scanning a QR code to share relevant information.
19 | 3. **(Optional)** The Healthcare Provider initiates a coverage verification process by contacting the Payer to confirm the high-level service coverage, aiming to determine if the expected services are covered under the Individual's insurance plan.
20 | 4. **(Optional)** The payer responds back with coverage eligibility details of the plan.
21 | 5. The Healthcare Provider confirms the admission for the individual/beneficiary.
22 | 6. The individual/beneficiary proceeds with the check-in, registration, and finalisation of required service(s) based on their needs and preferences.
23 | 7. **(Optional)** The Healthcare Provider further engages with the payer to verify treatment coverage, seeking preauthorization for the proposed treatment/service plan and involved cost details as required by the insurance policy. Wherever applicable, this step may be repeated multiple times to signal change in treatment/service plan.
24 | 8. The payer responds back with the preauthorization response for each request alongwith the pre-authorized amount for each procedure, product, service, etc.
25 | 9. The healthcare provider provides the necessary services to the Individual, which may include a range of medical procedures, tests, administration of drugs, products, therapy sessions, or any other relevant treatments.
26 | 10. The healthcare provider initiates the claim submission process by forwarding the relevant details and documents to the payer.
27 | 11. The payer performs the on-the-spot adjudication to evaluate the submitted claim
28 | 12. The payer responds to the healthcare provider with either approval (full or partial) or rejection of the claim.
29 | 13. After receiving the claim response from the payer, the healthcare provider communicates the claim details to the individual, informing them about the approved services and any payment obligations that remain.
30 | 14. The individual proceeds with any necessary payments, settling any remaining balance based on the coverage provided by the insurance policy, and subsequently concludes the treatment or service provision setting.
31 |
32 | Following section provides details of the reimagined workflow of the cashless claims leveraging HCX protocol.
33 |
--------------------------------------------------------------------------------
/use-cases/ipd/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Scope, Typical workflows and mapping to the protocol
3 | ---
4 |
5 | # IPD
6 |
7 | Inpatient care, often referred to as the In-patient department (IPD), is a dedicated section within a healthcare facility specifically designed to deliver comprehensive medical care and treatment to patients or beneficiaries who require admission and an extended stay within the hospital. This department is equipped to provide specialized care for individuals whose medical conditions necessitate continuous monitoring, treatment, and support during their hospitalisation.
8 |
--------------------------------------------------------------------------------
/use-cases/ipd/mapping-to-the-hcx-protocol/README.md:
--------------------------------------------------------------------------------
1 | # Mapping to the HCX protocol
2 |
3 | This section provides details of how typical cashless and reimbursement IPD workflows can be enabled through HCX protocol. It also highlights the key implementation considerations while implementing these workflows on HCX.
4 |
5 | Through the implementation of these workflows via the HCX protocol, numerous challenges in cashless processing can be effectively tackled, significantly improving the overall quality and effectiveness of the services delivered and claims adjudicated.
6 |
7 | Following sub-sections will provide detailed HCX enabled IPD workflows.
8 |
--------------------------------------------------------------------------------
/use-cases/ipd/mapping-to-the-hcx-protocol/cashless.md:
--------------------------------------------------------------------------------
1 | # Cashless
2 |
3 | The redesigned IPD cashless claims workflow, powered by the HCX protocol, provides a valuable insight into the seamless and efficient processing of claim requests. HCX brings interoperability and transparency in the claim adjudication process, ensuring that claims are handled promptly and effectively.
4 |
5 | Ref: [Typical IPD cashless claims workflow](broken-reference)
6 |
7 | {% hint style="info" %}
8 | **Important note :** The work stream's original diagram representing the overall workflow of the reimagined IPD cashless using HCX is available [here](https://drive.google.com/file/d/1Upcz5oRkIK8loaqeeinw-eFY4au7MiJS/view?usp=drive\_link). Based on initial feedback for improving the readability, the sections below detail it in multiple diagrams representing each stage separately.
9 | {% endhint %}
10 |
11 | ### **IPD cashless claims through HCX**
12 |
13 | #### **Coverage eligibility flow**
14 |
15 | The coverage eligibility check for the beneficiary is usually the first stage in an IPD service delivery and claims process. HCX facilitates a structured and timely response to the coverage eligibility check request and response delivery for stakeholders. The following diagram describes the steps and stakeholders involved in the coverage eligibility flow.
16 |
17 |
18 |
19 |
20 |
21 | **Pre-auth flow**
22 |
23 | After the coverage eligibility process, the provider determines the required services or treatment plan for the beneficiary's requirements, along with the associated expenses, and submits it to the payer for pre-authorization. The following diagram provides an overview of the steps and stakeholders involved in the pre-auth flow.
24 |
25 |
26 |
27 | #### **Claims flow**
28 |
29 | Once the Provider has provided the services to the beneficiary in accordance with the treatment plan, it initiates the claim request with the concerned payer through HCX, furnishing the necessary information for the claim adjudication. The following diagram describes the steps and stakeholders involved in the claims flow through HCX.
30 |
31 |
32 |
33 | The next section describes IPD reimbursement claims workflow leveraging HCX protocol.
34 |
--------------------------------------------------------------------------------
/use-cases/ipd/mapping-to-the-hcx-protocol/reimbursement.md:
--------------------------------------------------------------------------------
1 | # Reimbursement
2 |
3 | The reimagined IPD reimbursement claims workflow leveraging HCX protocol help us understand how claim requests can processed timely and efficiently. HCX will bring interoperability and transparency in the claim adjudication process.
4 |
5 | [Link to the typical IPD](broken-reference) reimbursement claims workflow.
6 |
7 | {% hint style="info" %}
8 | **Important note :** The work stream's original diagram representing the overall workflow of the reimagined IPD reimbursement flow using HCX is available [here](https://drive.google.com/file/d/1lxsoR0SfrriGoQ38aiQH3TBmDHGc1OSq/view?usp=sharing). Based on initial feedback for improving the readability, the sections below detail it in multiple diagrams representing each stage separately.
9 | {% endhint %}
10 |
11 | ### **IPD reimbursement claims**
12 |
13 | **Coverage eligibility flow**
14 |
15 | Even in a reimbursement situation, an IPD service delivery and claims process could start with the beneficiary/policyholder checking their coverage eligibility using the BSP interface. This would serve as a pre-notification for the payer, and aid the beneficiary in obtaining the initial details regarding the coverage. The following diagram shows the steps and stakeholders involved in the coverage eligibility flow.
16 |
17 |
18 |
19 | #### **Claims flow**
20 |
21 | Once the services are provisioned and the beneficiary is discharged, the Beneficiary/policyholder would initiate a reimbursement claim request with the payer through HCX, furnishing the necessary information for the claim adjudication. The beneficiary would use a BSP app to start the claim. Before processing a claim, the Payer would seek consent from the beneficiary to ensure claim authenticity. The following diagram describes the steps and stakeholders involved in the claims flow through HCX.
22 |
23 |
24 |
25 | The next section describes IPD usecase key implementation considerations.
26 |
--------------------------------------------------------------------------------
/use-cases/ipd/typical-workflows/README.md:
--------------------------------------------------------------------------------
1 | # Typical Workflows
2 |
3 | Typical workflows outlines the series of tasks, processes, and interactions that takes place between different stakeholders throughout the IPD health claims cycle. These workflows represent usual operations and there can be some variation in the process based on different usecases.
4 |
--------------------------------------------------------------------------------
/use-cases/ipd/typical-workflows/cashless.md:
--------------------------------------------------------------------------------
1 | # Cashless
2 |
3 | Cashless health insurance allows policyholders/beneficiaries to receive medical treatment without having to pay upfront to the providers for the medical services/treatment. It covers both outpatient department (OPD) and inpatient department (IPD) expenses, providing financial relief to the beneficiaries.
4 |
5 | Ref : [OPD cashless section for the advantages and challenges in the cashless insurance](../../opd/typical-workflows/cashless.md)
6 |
7 | Typical/existing workflow for IPD service delivery and cashless insurance claim :
8 |
9 |
10 |
11 | **Workflow details :**
12 |
13 | 1. An individual/beneficiary schedules an appointment or arrives as a walk-in (emergency) at the healthcare provider's facility
14 | 2. The individual/beneficiary provides necessary details including insurance details, which may involve filling out a form or scanning a QR code to share relevant information.
15 | 3. **(Optional)** The Healthcare Provider initiates a coverage verification process by contacting the Payer to confirm the high-level service coverage, aiming to determine if the expected services are covered under the Individual's insurance plan.
16 | 4. **(Optional)** The payer responds back with coverage eligibility details of the plan.
17 | 5. The Healthcare Provider confirms the admission for the individual.
18 | 6. The individual proceeds with the check-in, registration, and finalisation of required service(s) based on their needs and preferences.
19 | 7. **(Optional)** The Healthcare Provider further engages with the payer to verify treatment coverage, seeking preauthorization for the proposed treatment/service plan and involved cost details as required by the insurance policy. Wherever applicable, this step may be repeated multiple times to signal change in treatment/service plan.
20 | 8. The payer responds back with the preauthorization response for each request alongwith the pre-authorized amount for each procedure, product, service, etc.
21 | 9. The healthcare provider provides the necessary services to the Individual, which may include a range of medical procedures, tests, administration of drugs, products, therapy sessions, or any other relevant treatments.
22 | 10. The healthcare provider initiates the claim submission process by forwarding the relevant details and documents to the payer.
23 | 11. The payer performs the on-the-spot adjudication to evaluate the submitted claim
24 | 12. The payer responds to the healthcare provider with either approval (full or partial) or rejection of the claim.
25 | 13. After receiving the claim response from the payer, the healthcare provider communicates the claim details to the individual, informing them about the approved services and any payment obligations that remain.
26 | 14. The beneficiary proceeds with any necessary payments, settling any remaining balance based on the coverage provided by the insurance policy, and subsequently concludes the treatment or service provision setting.
27 |
--------------------------------------------------------------------------------
/use-cases/opd/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Scope, Typical workflows and mapping to the protocol
3 | ---
4 |
5 | # OPD
6 |
7 | The Outpatient Department (OPD) is a distinct component of a healthcare facility, such as a hospital or clinic, dedicated to delivering medical services to patients who do not necessitate overnight hospitalization.
8 |
9 | Within the OPD setup, healthcare professionals provide diagnosis, treatment, consultations, and a wide array of medical services to individuals with conditions that can be effectively managed without requiring an extended stay in the healthcare facility.
10 |
11 | Please note that the scope of OPD use cases has been limited to following key categories in the current version:
12 |
13 | 1. **Drugs/Pharmacy** - High frequency, a large part of the OOO expenses, always needed as part of any OPD/IPD intervention.
14 | 2. **Diagnostics** - Almost always needed in pre and post part of any IPD or OPD intervention, results in high OOP
15 | 3. **Consultations** - Entry point of an OPD journey, medium frequency, crucial to start health journey
16 | 4. **Wellness** - Wellness interventions involving Consultation, Diagnostics and Drugs/Pharmacy as they will be very similar to #1, #2, and #3 above (except that the policy could be issued by payers/sponsors other than insurance companies).
17 |
18 | Prioritisation of above categories was done based on the following prioritisation criterions:
19 |
20 | 1. **Coverage -** Services that cover most patients (using Pareto Principle)
21 | 2. **Critical -** Services for which OPD insurance is most needed (cost, frequency, etc.)
22 | 3. **Ease of implementation -** Well defined services & procedures and needing least implementation effort by the participants
23 | 4. **Core service -** Most offered in current OPD products (Mostly covered in 1 & 2)
24 | 5. **Availability of insurance providers -** Companies who are providing an OPD insurance to their existing consumers
25 |
26 | Following subsections details out the typical workflows in the cashless anf reimbursement OPD claims usecase.
27 |
--------------------------------------------------------------------------------
/use-cases/opd/mapping-to-the-hcx-protocol/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Mapping the OPD workflows to HCX protocol
3 | ---
4 |
5 | # Mapping to the HCX protocol
6 |
7 | This section provides details of how typical cashless and reimbursement OPD workflows can be enabled through HCX protocol. It also highlights the key implementation considerations while implementing these workflows on HCX.
8 |
9 | Through the implementation of these workflows via the HCX protocol, numerous challenges in cashless processing can be effectively tackled, significantly improving the overall quality and effectiveness of the services delivered and claims adjudicated. These improvements yield a range of benefits such as:
10 |
11 | * Enhanced provider network
12 | * Prompt coverage eligibility, pre-auth, & claim response
13 | * Transparency on policy eligibility
14 | * Enables payor systems to detect frauds
15 |
16 | Following sub-sections will provide detailed HCX enabled OPD workflows.
17 |
--------------------------------------------------------------------------------
/use-cases/opd/mapping-to-the-hcx-protocol/cashless.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Mapping cashless OPD claims to HCX protocol
3 | ---
4 |
5 | # Cashless
6 |
7 | The reimagined OPD cashless claims workflow leveraging HCX protocol help us understand how claim requests can processed timely and efficiently. Increased provider network coverage, real time updates and approval of the OPD claims will enhance adoption and trust in the system for policyholder.
8 |
9 | Ref: [Typical OPD cashless claims workflow](broken-reference)
10 |
11 | {% hint style="info" %}
12 | **Important note :** The work stream's original diagram representing the overall workflow of the OPD cashless claims workflow using HCX is available [here](https://drive.google.com/file/d/1cKb4gfqZjHib4vKOEjYIvcySl4KiO8hR/view?usp=sharing). Based on initial feedback for improving the readability, the sections below detail it in multiple diagrams representing each stage separately.
13 | {% endhint %}
14 |
15 | ### **OPD cashless claims**
16 |
17 | #### **Coverage eligibility flow**
18 |
19 | The OPD service delivery and claims process would usually start with the coverage eligibility (optional) check for the beneficiary. The following diagram shows the steps and stakeholders involved in the coverage eligibility flow.
20 |
21 |
22 |
23 | **Pre-auth flow**
24 |
25 | After the coverage eligibility process, the provider would determine the required services or treatment plan for the beneficiary's requirements, along with the associated expenses, and submits it to the payer for pre-authorization. The following diagram provides an overview of the steps and stakeholders involved in the pre-auth flow.
26 |
27 |
28 |
29 | #### **Claims flow**
30 |
31 | Once the Provider has provided the services to the beneficiary in accordance with the treatment plan, it initiates the claim request with the concerned payer through HCX, furnishing the necessary information for the claim adjudication. The following diagram describes the steps and stakeholders involved in the claims flow through HCX.
32 |
33 |
34 |
35 | The next section details the important implementation considerations for cashless health claims.
36 |
--------------------------------------------------------------------------------
/use-cases/opd/mapping-to-the-hcx-protocol/reimbursement.md:
--------------------------------------------------------------------------------
1 | # Reimbursement
2 |
3 | The reimagined OPD reimbursement claims workflow leveraging HCX protocol help us understand how claim requests can processed timely and efficiently. Increased provider network coverage, real time updates and approval of the OPD claims will enhance adoption and trust in the system for policyholder.
4 |
5 | [Link to the typical OPD reimbursement claims workflow.](broken-reference)
6 |
7 | {% hint style="info" %}
8 | **Important note :** The work stream's original diagram representing the overall workflow of the reimagined OPD reimbursement flow using HCX is available [here](https://drive.google.com/file/d/13VEPfN\_dLNlz\_HhwVD3-e5SQr0seoxSw/view?usp=sharing). Based on initial feedback for improving the readability, the sections below detail it in multiple diagrams representing each stage separately.
9 | {% endhint %}
10 |
11 | ### **OPD reimbursement claims**
12 |
13 | #### **Coverage eligibility flow**
14 |
15 | Even in a reimbursement situation, an OPD service delivery and claims process could start with the beneficiary/policyholder checking their coverage eligibility using the BSP interface. This would serve as a pre-notification for the payer, and aid the beneficiary in obtaining the initial details regarding the coverage. The following diagram shows the steps and stakeholders involved in the coverage eligibility flow.
16 |
17 |
18 |
19 | **Pre-auth flow**
20 |
21 | After the coverage eligibility process, once the provider has decided on the services or treatment plan and the costs, the beneficiary could potentially send a preauthorisation to the payer. This could provide payers with an opportunity to assist the beneficiary with their treatment and expenses planning. The following diagram provides an overview of the steps and stakeholders involved in the pre-auth flow.
22 |
23 |
24 |
25 | #### **Claims flow**
26 |
27 | Once the services are provisioned and the beneficiary is discharged, the Beneficiary/policyholder would initiate a reimbursement claim request with the payer through HCX, furnishing the necessary information for the claim adjudication. The beneficiary would use a BSP app to start the claim. Before processing a claim, the Payer would seek consent from the beneficiary to ensure claim authenticity. The following diagram describes the steps and stakeholders involved in the claims flow through HCX.
28 |
29 |
30 |
31 | The next section details the important implementation considerations for OPD health claims.
32 |
--------------------------------------------------------------------------------
/use-cases/opd/typical-workflows/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Typical OPD Cashless and Reimbursement workflows
3 | ---
4 |
5 | # Typical Workflows
6 |
7 | Typical workflows outlines the series of tasks, processes, and interactions that takes place between different stakeholders throughout the OPD health claims cycle. These workflows represent usual operations and there can be some variation in the process based on different use cases.
8 |
--------------------------------------------------------------------------------
/use-cases/opd/typical-workflows/cashless.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Defining OPD cashless claims, advantages, challenges, & typical workflow
3 | ---
4 |
5 | # Cashless
6 |
7 | Cashless health insurance allows policyholders/beneficiaries to receive medical treatment without having to pay upfront to the providers for the medical services/treatment. It covers both outpatient department (OPD) and inpatient department (IPD) expenses, providing financial relief to the beneficiaries.
8 |
9 | ### **Advantages of cashless claims**
10 |
11 | 1. **Improves patient experience :** Cashless insurance enhances the overall beneficiary experience by streamlining the healthcare process. It reduces the administrative hassles of reimbursement claims and paperwork submission.
12 | 2. **Financial relief :** By covering medical expenses directly, cashless insurance reduces the financial burden on policyholders/beneficiaries during times of illness or emergencies.
13 | 3. **Access to quality care :** Cashless insurance often partners with a network of hospitals and healthcare providers, ensuring access to quality medical facilities and specialists for policyholders.
14 | 4. **Prompt treatment :** Beneficiaries can plan prompt medical treatment, without having to worry about arranging funds before getting the necessary care.
15 |
16 | ### **Challenges**
17 |
18 | 1. **Limited network :** Cashless insurance poses a challenge when policyholders require immediate care from healthcare providers outside the insurer's network, leading to out-of-pocket expenses.
19 | 2. **Pre-authorization/claims delays :** Delays in obtaining pre-authorization/claims for OPD can hinder prompt treatment and causes inconvienience for both providers and beneficiaries.
20 | 3. **Frauds :** As the OPD claims adjudication is time sensitive; possibility of the impersonation/identity theft, phantom service, etc. frauds increases further.
21 |
22 | ### **Typical/existing workflow for OPD cashless claims**
23 |
24 |
Typical OPD Cashless workflow
25 |
26 | #### **Workflow details**
27 |
28 | 1. An individual/Beneficiary schedules an appointment or arrives as a walk-in (emergency) at the healthcare provider's facility
29 | 2. The individual/Beneficiary provides necessary details including insurance details, which may involve filling out a form or scanning a QR code to share relevant information.
30 | 3. **(Optional)** The Healthcare Provider initiates a coverage verification process by contacting the Payer to confirm the high-level service coverage, aiming to determine if the expected services are covered under the Individual's insurance plan.
31 | 4. **(Optional)** The payer responds back with coverage eligibility details of the plan.
32 | 5. The Healthcare Provider confirms the admission for the individual/beneficiary.
33 | 6. The individual/beneficiary proceeds with the check-in, registration, and finalisation of required service(s) based on their needs and preferences.
34 | 7. **(Optional)** The Healthcare Provider further engages with the payer to verify treatment coverage, seeking preauthorization for the proposed treatment/service plan and involved cost details as required by the insurance policy. Wherever applicable, this step may be repeated multiple times to signal change in treatment/service plan.
35 | 8. The payer responds back with the preauthorization response for each request alongwith the pre-authorized amount for each procedure, product, service, etc.
36 | 9. The healthcare provider provides the necessary services to the Individual, which may include a range of medical procedures, tests, administration of drugs, products, therapy sessions, or any other relevant treatments.
37 | 10. The healthcare provider initiates the claim submission process by forwarding the relevant details and documents to the payer.
38 | 11. The payer performs the on-the-spot adjudication to evaluate the submitted claim
39 | 12. The payer responds to the healthcare provider with either approval (full or partial) or rejection of the claim.
40 | 13. After receiving the claim response from the payer, the healthcare provider communicates the claim details to the individual, informing them about the approved services and any payment obligations that remain.
41 | 14. The individual proceeds with any necessary payments, settling any remaining balance based on the coverage provided by the insurance policy, and subsequently concludes the treatment or service provision setting.
42 |
43 | Following subsection details out the typical workflow for the reimbursement claims for OPD.
44 |
--------------------------------------------------------------------------------
/use-cases/reimbursement/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Beneficiary led Health Claims process
3 | ---
4 |
5 | # Reimbursement
6 |
7 | Reimbursement claims in healthcare refer to the process through which policyholders request payment from insurance companies or government healthcare programs for the medical services/benefits they have received. This process plays a crucial role in the healthcare industry, as it ensures that policyholders receive compensation for the expenses incurred.
8 |
9 | In the Reimbursement scenario, the onus is on the patient to duly submit all the necessary documents and share the information with the insurer as required for processing the claim.
10 |
11 | Here, we will explore the advantages and challenges associated with reimbursement claims in healthcare.
12 |
13 | **Advantages of Reimbursement Claims in Healthcare:**
14 |
15 | 1. **Wider access for policyholders:** Enables access to out-of-network healthcare services and providers, and when cashless authorisation is denied by the insurer. Reimbursement claims help make healthcare services more accessible to patients.
16 | 2. **Coverage for Out-of-Network Services:** Beneficiaries can get reimbursement for OPD/IPD and supporting services, typically as pre/post hospitalisation expenses. These expenses may include:
17 | 1. Diagnostic tests
18 | 2. Doctor consultations, medications, rehabilitation, therapies, etc.
19 | 3. Medical supplies and equipments
20 | 3. **Risk Mitigation:** For patients, insurance coverage and reimbursement claims mitigate the financial risk associated with unexpected medical expenses. Policyholders feel protected knowing that a significant portion of their healthcare expenses will be covered.
21 |
22 | Incentive for High-Quality Care: The reimbursement process often incorporates quality metrics and performance indicators. Healthcare providers may receive higher reimbursements for delivering high-quality care, which incentivizes them to maintain or improve the quality of their services.
23 |
24 |
25 |
26 | **Challenges of Reimbursement Claims in Healthcare :**
27 |
28 | 1. **Financial burden on policyholders :** As reimbursement claims require policyholders to pay for medical expenses out of pocket at non-network facilities. It may lead to financial stress or even medical debts for the patients. Policyholders often experience delays in receiving reimbursement payments, which can further exacerbate their financial condition. These delays can be due to various factors, including claim reviews and administrative processes.
29 | 2. **Compromised healthcare outcomes :** As individuals have to make upfront payments to the providers; they may avoid or delay necessary treatments.
30 | 3. **Degraded patient experience :** Policy exclusion and claim rejections may lead to dissatisfaction and trust deficit among policyholders. It will have negative effect on the health insurance sector, resulting in a decrease in participation and buying.
31 | 4. **Administrative Burden:** The process of submitting and processing reimbursement claims can be highly administrative and complex.Policyholders often need to seek help from as dedicated BSPs or third-party billing services to manage the paperwork efficiently.
32 | 5. **Fraud and Abuse:** The complexity of the reimbursement process can also create opportunities for fraud and abuse. Dishonest practices such as upcoding or unnecessary procedures can lead to overbilling, which harms both patients and payers.
33 |
34 | Following section provide details of the typical workflows for service delivery and reimbursement claim submission in both IPD and OPD.
35 |
--------------------------------------------------------------------------------
/use-cases/reimbursement/mapping-to-the-hcx-protocol/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Workflow on HCX and proposed protocol enhancements
3 | ---
4 |
5 | # Mapping to the HCX protocol
6 |
7 | This section provides details of how typical cashless IPD and OPD workflows can be enabled through HCX protocol. It also highlights the key implementation considerations while implementing these workflows on HCX.
8 |
9 | Through the implementation of these workflows via the HCX protocol, numerous challenges in reimbursement processing can be effectively tackled, significantly improving the overall quality and effectiveness of the workflow. These improvements yield a range of benefits such as:
10 |
11 | * Transparency on policy eligibility
12 | * Prompt communication & reduced administrative burden
13 | * Increased patient trust and adoption
14 | * Enables payor systems to detect frauds
15 |
16 | Following subsections will provide detailed HCX enabled IPD and OPD workflows.
17 |
--------------------------------------------------------------------------------
/use-cases/reimbursement/mapping-to-the-hcx-protocol/inpatient-ipd.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: IPD Reimbursement process
3 | ---
4 |
5 | # Inpatient (IPD)
6 |
7 | The reimagined IPD reimbursement claims workflow leveraging HCX protocol help us understand how claim requests can processed timely and efficiently. HCX will bring interoperability and transparency in the claim adjudication process.
8 |
9 | [Link to the typical IPD](../typical-workflows/inpatient-ipd.md) reimbursement claims workflow.
10 |
11 | {% hint style="info" %}
12 | **Important note :** The work stream's original diagram representing the overall workflow of the reimagined IPD reimbursement flow using HCX is available [here](https://drive.google.com/file/d/1lxsoR0SfrriGoQ38aiQH3TBmDHGc1OSq/view?usp=sharing). Based on initial feedback for improving the readability, the sections below detail it in multiple diagrams representing each stage separately.
13 | {% endhint %}
14 |
15 | ### **IPD reimbursement claims**
16 |
17 | **Coverage eligibility flow**
18 |
19 | Even in a reimbursement situation, an IPD service delivery and claims process could start with the beneficiary/policyholder checking their coverage eligibility using the BSP interface. This would serve as a pre-notification for the payer, and aid the beneficiary in obtaining the initial details regarding the coverage. The following diagram shows the steps and stakeholders involved in the coverage eligibility flow.
20 |
21 |
22 |
23 | **IPD reimbursement claims : Pre-auth flow**
24 |
25 | After the coverage eligibility process, once the provider has decided on the services or treatment plan and the costs, the beneficiary could potentially send a preauthorisation to the payer. This could provide payers with an opportunity to assist the beneficiary with their treatment and expenses planning. The following diagram provides an overview of the steps and stakeholders involved in the pre-auth flow.
26 |
27 |
28 |
29 | #### **Claims flow**
30 |
31 | Once the services are provisioned and the beneficiary is discharged, the Beneficiary/policyholder would initiate a reimbursement claim request with the payer through HCX, furnishing the necessary information for the claim adjudication. The beneficiary would use a BSP app to start the claim. Before processing a claim, the Payer would seek consent from the beneficiary to ensure claim authenticity. The following diagram describes the steps and stakeholders involved in the claims flow through HCX.
32 |
33 |
34 |
35 | The next section describes OPD reimbursement workflow leveraging HCX protocol.
36 |
--------------------------------------------------------------------------------
/use-cases/reimbursement/mapping-to-the-hcx-protocol/outpatient-opd.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Mapped workflow, key gaps identified and proposed protocol changes
3 | ---
4 |
5 | # Outpatient (OPD)
6 |
7 | The reimagined OPD reimbursement claims workflow leveraging HCX protocol help us understand how claim requests can processed timely and efficiently. Increased provider network coverage, real time updates and approval of the OPD claims will enhance adoption and trust in the system for policyholder.
8 |
9 | [Link to the typical OPD reimbursement claims workflow.](../typical-workflows/outpatient-opd.md)
10 |
11 | {% hint style="info" %}
12 | **Important note :** The work stream's original diagram representing the overall workflow of the reimagined OPD reimbursement flow using HCX is available [here](https://drive.google.com/file/d/13VEPfN\_dLNlz\_HhwVD3-e5SQr0seoxSw/view?usp=sharing). Based on initial feedback for improving the readability, the sections below detail it in multiple diagrams representing each stage separately.
13 | {% endhint %}
14 |
15 | ### **OPD reimbursement claims**
16 |
17 | #### **Coverage eligibility flow**
18 |
19 | Even in a reimbursement situation, an OPD service delivery and claims process could start with the beneficiary/policyholder checking their coverage eligibility using the BSP interface. This would serve as a pre-notification for the payer, and aid the beneficiary in obtaining the initial details regarding the coverage. The following diagram shows the steps and stakeholders involved in the coverage eligibility flow.
20 |
21 |
22 |
23 | #### **Pre-auth flow**
24 |
25 | After the coverage eligibility process, once the provider has decided on the services or treatment plan and the costs, the beneficiary could potentially send a preauthorisation to the payer. This could provide payers with an opportunity to assist the beneficiary with their treatment and expenses planning. The following diagram provides an overview of the steps and stakeholders involved in the pre-auth flow.
26 |
27 |
28 |
29 | #### **Claims flow**
30 |
31 | Once the services are provisioned and the beneficiary is discharged, the Beneficiary/policyholder would initiate a reimbursement claim request with the payer through HCX, furnishing the necessary information for the claim adjudication. The beneficiary would use a BSP app to start the claim. Before processing a claim, the Payer would seek consent from the beneficiary to ensure claim authenticity. The following diagram describes the steps and stakeholders involved in the claims flow through HCX.
32 |
33 |
34 |
35 | The next section details the important implementation considerations for reimbursement health claims.
36 |
--------------------------------------------------------------------------------
/use-cases/reimbursement/typical-workflows/README.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: Typical cashless workflows
3 | ---
4 |
5 | # Typical workflows
6 |
7 | Typical workflows for the service delivery and reimbursement claim submission outlines the series of tasks, processes, and interactions that takes place between different stakeholders throughout the reimbursement health claims cycle. These workflows represent usual operations and there can be some variation in the process based on different usecases.
8 |
--------------------------------------------------------------------------------
/use-cases/reimbursement/typical-workflows/outpatient-opd.md:
--------------------------------------------------------------------------------
1 | ---
2 | description: OPD reimbursement process
3 | ---
4 |
5 | # OPD
6 |
7 | The Outpatient Department (OPD), component of a healthcare facility such as a hospital or clinic, dedicated to providing medical services to patients who do not require overnight hospitalization.
8 |
9 | In the OPD, healthcare professionals offer diagnosis, treatment, consultation, and various medical services to individuals with medical conditions that can be managed without the need for an extended stay in the healthcare facility.
10 |
11 | Typical/existing workflow for OPD service delivery and reimbursement insurance claim :
12 |
13 |
14 |
15 | **Workflow details :**
16 |
17 | 1. **(Optional)** The Individual initiates the process by contacting the Payer to verify service coverage, seeking high-level information about whether the insurance plan covers the expected services. The policyholder could also do this step after seeking the appointment/walk in.
18 | 2. **(Optional)** The payer responds back with eligibility details.
19 | 3. The Individual schedules an appointment or arrives as a walk-in at the Healthcare Provider's facility.
20 | 4. The Healthcare Provider proceeds with check-in, registration, and finalizing the treatment plan based on the Individual's requirements.
21 | 5. The Healthcare Provider communicates the treatment details to the Individual, providing necessary information about the proposed course of action for the treatment or services.
22 | 6. **(Optional)** The Individual contacts the Payer to verify treatment coverage, seeking preauthorization for the proposed treatment plan and obtaining cost details if required by the insurance policy. Wherever applicable, this step may be repeated multiple times to signal change in treatment/service plan.
23 | 7. **(Optional)** The payer responds back with the preauthorization response for each request.
24 | 8. In the case where an advance payment is required, the Healthcare Provider provides an itemised bill to the Individual, takes the fees and provisions of the required services, such as consultation, tests, drugs, products, therapy sessions, or any other relevant treatments.
25 | 9. Alternatively, if payment is to be made after service provision, the Healthcare Provider directly provides the necessary services, then presents the Individual with an itemised bill detailing the fees and receives payment.
26 | 10. The Individual submits the claim to the Payer, providing all relevant documents and information needed for claim processing.
27 | 11. The Payer processes the submitted claim, reviewing the details and documents provided by the Individual (or the Healthcare Provider).
28 | 12. The Payer responds to the Individual with the claim outcome, which could be approval (full or partial) of the claim or rejection, with the applicable reimbursement amount based on the policy coverage.
29 |
30 | Following section provides details of the reimagined workflow of the reimbursement claims leveraging HCX protocol.
31 |
--------------------------------------------------------------------------------