You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Health Claims eXchange (HCX) protocol, developed by the HCX protocol community, aims to facilitate seamless claims data exchange among stakeholders in the health claims ecosystem.
Currently, two networks based on the HCX protocol are operational in India:
NHCX (National Health Claims Exchange): Managed by the National Health Authority (NHA), this network focuses on supporting social insurance and inpatient department (IPD) cases. It extends version 0.7.1 of the HCX protocol to meet the specific use cases envisioned by the NHA.
OpenHCX: Managed by the Swasth community, OpenHCX adheres to the latest HCX protocol specifications (v0.9) set by the open community. In addition to supporting IPD cases, OpenHCX includes support for outpatient healthcare (OPD) scenarios and reimbursement use cases.
In the early stages of protocol evolution, variations tailored to specific scenarios are expected. For instance, the TCP/IP protocol suite has seen variations like IPv4 and IPv6, designed to address different needs such as address space and security enhancements. Similarly, HTML has evolved through multiple versions (e.g., HTML4, XHTML, and HTML5) to accommodate new web technologies and user requirements.
Currently, entities such as insurance companies, hospitals, and technology providers choose to integrate with one network based on their operational needs. However, integrating with both networks can unlock additional business opportunities and streamline operational efficiencies. Recognizing this potential, the OpenHCX community has established a workstream group to analyze both networks and propose solutions that facilitate seamless integration for entities utilizing both networks.
While leveraging both NHCX and OpenHCX networks may require extra effort initially, ongoing efforts aim to simplify interoperability between these variations. This document is an attempt to contribute to these efforts by analyzing and proposing solutions for seamless integration across both networks.
1.2 Objective:
The primary objective of this workstream is to meticulously identify and analyze the differences between NHCX and OpenHCX networks. By understanding these variations, we aim to propose pragmatic solutions that facilitate seamless integration for entities engaging with both networks. Our approach is designed to minimize the overall effort required for integration while maximizing the unique benefits and opportunities provided by each network.
2. Approach
This workstream has adopted a systematic, two-stage approach to achieve its objectives, ensuring a thorough and structured path towards enhanced interoperability and reduced integration burden.
Stage 1: Identification of Differences
Initially, the workstream conducted a comprehensive analysis to identify differences between the NHCX and OpenHCX networks. This analysis spanned various critical elements, including:
Registries: Examination of registry structures, data models, and registration processes.
APIs: Detailed comparison of API specifications, endpoints, and functionalities.
FHIR Profiles: Evaluation of FHIR (Fast Healthcare Interoperability Resources) profiles used in both networks, focusing on variations in data representation and exchange formats.
Stage 2: Solution Development
Following the identification phase, the focus shifted to developing and recommending practical solutions to bridge the identified gaps. The aim is to enable HCX integrators to operate seamlessly with both networks, with minimal additional effort. Key activities in this stage include:
Develop actionable recommendations and solutions to bridge identified gaps, ensuring interoperability and reducing integration complexity.
Facilitate the creation of tools, standards, and guidelines that enhance interoperability between the two networks, enabling entities to leverage the strengths of both.
3. Gap Analysis
3.1 Registries
Both the NHCX and OpenHCX networks have defined specifications for the "Participant" registry, encompassing two main aspects:
Schema: The schema definitions are largely similar, with a minor distinction in the structure of address details. Notably, the "address" field is optional in both protocols.
Registry APIs: Except for the "List All Participants" API which is defined only in NHCX, both networks share a common set of APIs for participant registry management. However, the “List All Participants” capability is enabled by the “Search Participants” API in OpenHCX.
Additionally, in its latest version, OpenHCX has introduced specifications for a "User Registry" to support multiple users operating on behalf of a participant entity. This feature is currently unique to the OpenHCX network.
3.2 APIs
The workstream has categorized the APIs into the following three categories:
Core APIs: These APIs handle essential claim processing tasks such as coverage eligibility, pre-authorization, predetermination, claims submission, and payment notification. Both networks share the same set of core APIs, with minor differences in request paths and domain payload object for “/paymentnotice/on_request” API:
NHCX specifies the "TaskBundle" FHIR resource, while 7OpenHCX uses the "PaymentNotice" FHIR resource as prescribed in the base protocol.
Auxiliary APIs: These APIs support alternate flows within the claims workflow, including communication and status requests. Most auxiliary APIs are similar in both protocols, but differences exist in request paths and domain payload objects.
Domain Payload differences:
NHCX uses "TaskBundle" for the "status request" API, whereas OpenHCX uses "Task" FHIR resource as prescribed in the base protocol.
For "communication response" APIs, NHCX uses "Communication" FHIR resource and OpenHCX uses "CommunicationBundle" as prescribed in the base protoco..
Additionally, NHCX includes extra APIs for searching claims, submitting claim reprocessing tasks, and fetching insurance plans. API differences:
NHCX includes /v1/search/submit and /v1/search/on_submit APIs for searching claims, which are absent in OpenHCX. Instead, OpenHCX provides /eob/fetch and /eob/on_fetch APIs for fetching details of specific claims as prescribed in the base protocol.
NHCX has /v1/task/submit and /v1/task/on_submit APIs for claim reprocessing or cancellation, whereas OpenHCX uses the core /claim/submit and /claim/on_submit APIs for similar tasks as prescribed in the base protocol.
NHCX offers /v1/insuranceplan/request and /v1/insuranceplan/on_request APIs to retrieve specific insurance plan objects, while OpenHCX integrates this functionality within the /coverageeligibility/on_check API as prescribed in the base protocol.
Upstream & Downstream APIs: These APIs extend beyond claim processing to tasks like establishing patient profiles. Their implementation and use are specific to the use cases targeted by different HCX networks and are not covered in the gap analysis conducted by the workstream. Integrators must implement these APIs as per their specific use cases.
3.3 FHIR Profiles
Workstream has analyzed the FHIR definitions within both networks, focusing primarily on two key aspects:
Cardinality of elements: Minimum and maximum occurrences of elements in FHIR profiles. Following differences in cardinality across the networks have been identified:
There are multiple elements that are optional in one protocol but are mandatory in the other, and vice versa. Some examples of such instances are:
ClaimResponse.requestor & ClaimResponse.request: required in OpenHCX and optional in NHCX
CoverageEligibilityRequest.item.productOrService: optional in OpenHCX and required in NHCX
Some elements have a maximum cardinality greater than 1 in one protocol, indicating them as list items, while the same elements have a maximum cardinality of 1 in the other protocol, implying they are not list items. For example, Claim.identifier has max cardinality greater than 1 in OpenHCX but the max cardinality is set to 1 for the same element in NHCX.
FHIR Terminology Bindings: Strength of binding and the associated value sets bound with FHIR profiles. Following differences in terminology bindings across the networks have been identified:
The binding strength is same for all value set elements across both the networks for all elements with “required” binding strength. There are two elements where the binding strength is “example” in OpenHCX, but “preferred” in NHCX: Claim.supportingInfo.category & Claim.supportingInfo.code.
All FHIR elements with a “required” binding strength use the same value sets. For elements with “example” and “preferred” binding strengths, there are some differences in value set bindings, which are detailed in the Appendix section below. Since these differences pertain only to non-required bindings and value sets are generally chosen based on specific use cases, no additional work is needed in this aspect to ensure interoperability between networks. Both of the above variations are expected behavior for the contextual adoption of the base protocol profiles.
4. Harmonizing Strategies
At this stage, based on the identified gaps from the gap analysis, the workstream has proposed the following strategies/recommendations to make both the networks interoperable:
Enhance SDKs for Improved Integration: The HCX community and Swasth currently offer SDKs to integrators to facilitate network integration. These SDKs could be enhanced to serve as a bridge between the networks, enabling seamless interoperability for integrators across both networks. The enhancements could enable the following (full list of enhancements are listed in the Appendix section below):
Transform API request paths and request body attributes from one format to another, with an option to configure whether to retain or omit certain attributes.
Turn off or disable services/features that are not available in one network but present in the other network. Integrators may be presented pertinent messages to indicate the same.
Translate domain payloads between different formats. This includes setting default values for required elements and converting from list to single-element formats & vice versa.
Enhance networks to harmonize protocol variations for interoperability: Both networks should look to harmonize with the base protocol and implement the necessary improvements to achieve full interoperability. This would include proposing enhancements in the base open protocol that could be vetted by the community and included as needed and make any necessary changes to their switches.
5. Conclusion
Integrating with both NHCX and OpenHCX offers significant business opportunities within the health claims ecosystem. The workstream's analysis suggests that the effort required to enable interoperability is manageable. Implementing the recommended enhancements will facilitate seamless operation across both networks, leading to increased operational efficiency and unlocking growth potential.
Going forward, it is crucial for both networks to prioritize ongoing communication and collaboration to address integration challenges effectively. This proactive approach will help create a more cohesive and efficient ecosystem for all stakeholders.
6. Appendix
FHIR Valueset Binding Differences
List of FHIR elements where the value set binding is different across both the networks:
List of capabilities to be provided by HCX SDKs to enable interoperability across both the networks:
Gap Identified
Recommended SDK Capability
Participant Registry Schema
Transform the "address" field from one protocol format to another, with the option to configure whether to retain or omit the "address" field.
Participant Registry APIs
Convert "List All Participants" API of NHCX to "Search Participants" API of OpenHCX, and vice versa.
User Registry
Return an unsupported error and the applications should disable user registry functionality when integrating with NHCX.
API Request Paths
Convert API request paths between OpenHCX and NHCX APIs, ensuring compatibility in both directions.
NHCX Claim Search API
Return an unsupported error and the applications should disable search functionality when integrating with OpenHCX.
Insurance Plan APIs
Translate NHCX Insurance Plan APIs to OpenHCX coverage eligibility APIs.
NHCX claim reprocessing APIs
Translate the NHCX task/submit & task/on_submit APIs to OpenHCX claim/submit & claim/on_submit APIs.
Required FHIR elements
Incorporate a configuration feature allowing users to specify default values for all required elements. During profile transformation, the SDK should automatically assign these configured defaults to the required elements.
FHIR elements cardinality
Automatically transform between list and single-element formats as needed.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
1. Introduction
1.1 Context:
The Health Claims eXchange (HCX) protocol, developed by the HCX protocol community, aims to facilitate seamless claims data exchange among stakeholders in the health claims ecosystem.
Currently, two networks based on the HCX protocol are operational in India:
In the early stages of protocol evolution, variations tailored to specific scenarios are expected. For instance, the TCP/IP protocol suite has seen variations like IPv4 and IPv6, designed to address different needs such as address space and security enhancements. Similarly, HTML has evolved through multiple versions (e.g., HTML4, XHTML, and HTML5) to accommodate new web technologies and user requirements.
Currently, entities such as insurance companies, hospitals, and technology providers choose to integrate with one network based on their operational needs. However, integrating with both networks can unlock additional business opportunities and streamline operational efficiencies. Recognizing this potential, the OpenHCX community has established a workstream group to analyze both networks and propose solutions that facilitate seamless integration for entities utilizing both networks.
While leveraging both NHCX and OpenHCX networks may require extra effort initially, ongoing efforts aim to simplify interoperability between these variations. This document is an attempt to contribute to these efforts by analyzing and proposing solutions for seamless integration across both networks.
1.2 Objective:
The primary objective of this workstream is to meticulously identify and analyze the differences between NHCX and OpenHCX networks. By understanding these variations, we aim to propose pragmatic solutions that facilitate seamless integration for entities engaging with both networks. Our approach is designed to minimize the overall effort required for integration while maximizing the unique benefits and opportunities provided by each network.
2. Approach
This workstream has adopted a systematic, two-stage approach to achieve its objectives, ensuring a thorough and structured path towards enhanced interoperability and reduced integration burden.
Stage 1: Identification of Differences
Initially, the workstream conducted a comprehensive analysis to identify differences between the NHCX and OpenHCX networks. This analysis spanned various critical elements, including:
Stage 2: Solution Development
Following the identification phase, the focus shifted to developing and recommending practical solutions to bridge the identified gaps. The aim is to enable HCX integrators to operate seamlessly with both networks, with minimal additional effort. Key activities in this stage include:
3. Gap Analysis
3.1 Registries
Both the NHCX and OpenHCX networks have defined specifications for the "Participant" registry, encompassing two main aspects:
Additionally, in its latest version, OpenHCX has introduced specifications for a "User Registry" to support multiple users operating on behalf of a participant entity. This feature is currently unique to the OpenHCX network.
3.2 APIs
The workstream has categorized the APIs into the following three categories:
3.3 FHIR Profiles
Workstream has analyzed the FHIR definitions within both networks, focusing primarily on two key aspects:
4. Harmonizing Strategies
At this stage, based on the identified gaps from the gap analysis, the workstream has proposed the following strategies/recommendations to make both the networks interoperable:
5. Conclusion
Integrating with both NHCX and OpenHCX offers significant business opportunities within the health claims ecosystem. The workstream's analysis suggests that the effort required to enable interoperability is manageable. Implementing the recommended enhancements will facilitate seamless operation across both networks, leading to increased operational efficiency and unlocking growth potential.
Going forward, it is crucial for both networks to prioritize ongoing communication and collaboration to address integration challenges effectively. This proactive approach will help create a more cohesive and efficient ecosystem for all stakeholders.
6. Appendix
FHIR Valueset Binding Differences
List of FHIR elements where the value set binding is different across both the networks:
SDK Enhancements
List of capabilities to be provided by HCX SDKs to enable interoperability across both the networks:
Beta Was this translation helpful? Give feedback.
All reactions