Objective

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. This document proposes a governance approach for the open specifications in line with key design principles outlined in the National Digital Health Blueprint and further contextualized for HCX specifications.

Proposed Governance Approach and Process for Specifications at Swasth during the pilot period

As evident, creating functional specifications will require a robust process and deep collaboration between multiple stakeholders. The process must:

1. Enable the delivery of universal health coverage (UHC) in India

2. Drive healthcare outcomes and inclusion as well as patient safety and privacy

3. Foster consensus*

4. Ensure content is fit for purpose*

5. Ensure content is implementable*

6. Establish an appropriate implementer community*

7. Ensure ongoing maintenance of the standards*

(* Points 3 to 7 have been adopted from the must-have criteria followed by HL7)

Hence, the development and maintenance of standards must follow an open and consultative process with widely inclusive, committed groups that can bring together necessary skills, viewpoints, and networks.

Swasth proposes to maintain and enhance specifications using an inclusive, open, and consultative process. The broad outline of the process would be:

1. Swasth will form a governance council for specifications with representation from across the healthcare ecosystem (insurance, TPA, patient groups, provider representatives, small provider associations, academic institutions/experts in the area, the regulator, and relevant public bodies)

2. The governance council will facilitate the formation of topic-specific working groups

3. Working groups will create clear criteria for the evaluation of a proposal

4. Ideas for new specifications/enhancement is proposed by one of the group members

5. The working group evaluates the idea

6. If approved, development/enhancement begins

7. Resultant specifications/enhancement will be reviewed by peer group for implementability

8. The resulting specifications/enhancement will be put out for public consultation

9. The working group reviews public consultation feedback and incorporates the necessary changes. (Any inputs not included will receive responses too)

10. Specifications will be published for wider adoption

11. Specifications will be maintained in open repositories like GitHub, Confluent (or similar) based on the nature of the output

12. Specifications are made available through most permissible licenses like MIT or Creative Commons

13. Swasth will also create a fully independent ethics and conflicts committee to act as an appellate authority for all our work, including stewardship of specifications

14. All deliberations, minutes, and documents produced by the ethics and conflicts committee, specifications governance council, and working groups will be made publicly available

Proposed Governance Approach for Specifications at iSPIRT

Post one year of finalizing the first version of these specifications, iSPIRT Foundation proposes to govern all the health claims specifications and develop additional specifications including Health Claims Protocol and associated protocols related to multi-party dispute resolution system, fraud registry, regulatory supervision, HCX gateway, and Policy markup language. Further APIs and Standards for Other claim artefacts will be developed by iSPIRT as and when required for use cases. iSPIRT will organize a governance group with Swasth as one of the members to govern the development of the specifications.

Questions for Consultation

Question 1

Is the governance approach laid out here practical and appropriate? What approaches, other than the ones mentioned in the Governance section, can be considered for managing and governing the HCX Open Specifications? Please provide details.

As described in Key Specifications, Open protocol deals with the technology backbone for the Health Claims Data Exchange. Sections below define the key elements of the proposed Health Claims Data Exchange Protocol.

Open protocol for claims data exchange - Health Claims Transfer Protocol

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

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

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

3. Supported methods (APIs)

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

5. Response codes

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

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

   2. Message signing protocol for verifiability and non-repudiation

7. Sequence of interactions

Tech Ops Policy Specifications

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

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

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

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

4. Exchange operation policies

   1. Key rotation requirements

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

   3. Operational reports and dashboards

   4. Audit checklist and frequency

Domain Data Specifications

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

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

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

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

Business Policy Specifications

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

1. Access control (Data sharing) policies - which actor plays what role and gets to see which parts of the data. These policies will then affect the visibility and access to domain-specific attributes that will typically travel in the body of the data structures defined by the data exchange.

2. Business SLAs

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

4. Dispute resolution policies

5. Onboarding

6. Defaulting/deboarding policies

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

Questions for Consultation

Question 1

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

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

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

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

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

HCX registries will act as a source of truth for participant information on the platform. These may be extended from/link to already existing registries in the ecosystem, e.g. registry may extend from National Health Facility Registry provided by NHA. The benefit of extending from an existing registry would be:

• Easy maintenance of base data at the source registry

• The extended registry only needs to maintain additional/supplementary information pertaining to its use case

• Better interoperability

Keeping with the key design principles listed above, registries on HCX will strive to be minimalistic, self-maintainable, support non-repudiability, accessible through OpenAPIs, Extensible and evolvable, and designs for data privacy and security. All registries on the HCX platform will minimally provide the following APIs:

• Create

• Update

• Search

• Delete

• Cancel

Please note that onboarding of the actors in the registry will take place through workflows defined by domain groups and may change over time, therefore the access to the data modification APIs would be controlled by the HCX instance provider and used as part of the onboarding process.

Participating Organisations/Systems Registry

This registry stores key details about the participants on the exchange who can exchange data through it. It may link with data on the HFR registry and will have fields necessary to facilitate claims data exchange with providers. Proposed attributes of the registry are:

User Registry

While the exchange protocol by itself may not need to focus on the human user (as the exchange is between systems), operational management of the exchange infrastructure may require administrative infrastructure that may necessitate a registry for operational users from organizations running HCX as well as participating organizations. Following are the proposed attributes for the User registry:

Questions for Consultation

Question 1

Question 2

Question 3

Question 4

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

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

Vision, Mission, and Objectives

1. Expand Insurance Penetration

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

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

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

2. Facilitate insurance innovation

   1. Highly personalized policies

   2. Short duration, low premium policies

   3. Auto adjudication, better fraud, and abuse prevention

3. Simplify and bring efficiency to claims processing

   1. Standardized claims process, less operational overheads

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

4. Better patient experience

Key Use cases/Workflows

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

1. Get provider/payor details

2. Eligibility check

3. Pre auth request flow

4. Claims request flow

5. Payment notification

6. Payment acknowledgement

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

Key constituents

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

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

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

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

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

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

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

Questions for Consultation

Question 1