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.

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.

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

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

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

• Define and meet the necessary regulations/policies

• Allow participants the choice of technology/solutions

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

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

Open

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

Evolvable and Extendable

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

Minimalistic and Inclusive

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

Balance data privacy and security with data empowerment

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

Provide for non-repudiability

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

Unbundled

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

Questions for Consultation

Question 1

Please share your thoughts on the comprehensiveness of the design principles outlined, and suggest methods to ensure these principles are adhered to. Please suggest if there are other principles that must be included and how are they going to help with the design of Open Specifications.