Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
A proposed approach for the governance of HCX specifications
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.
As evident, creating functional specifications will require a robust process and deep collaboration between multiple stakeholders. The process must:
Enable the delivery of universal health coverage (UHC) in India
Drive healthcare outcomes and inclusion as well as patient safety and privacy
Ensure content is fit for purpose*
Ensure content is implementable*
Establish an appropriate implementer community*
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:
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)
The governance council will facilitate the formation of topic-specific working groups
Working groups will create clear criteria for the evaluation of a proposal
Ideas for new specifications/enhancement is proposed by one of the group members
The working group evaluates the idea
If approved, development/enhancement begins
Resultant specifications/enhancement will be reviewed by peer group for implementability
The resulting specifications/enhancement will be put out for public consultation
The working group reviews public consultation feedback and incorporates the necessary changes. (Any inputs not included will receive responses too)
Specifications will be published for wider adoption
Specifications will be maintained in open repositories like GitHub, Confluent (or similar) based on the nature of the output
Specifications are made available through most permissible licenses like MIT or Creative Commons
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
All deliberations, minutes, and documents produced by the ethics and conflicts committee, specifications governance council, and working groups will be made publicly available
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.
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.
Instructions to send responses to the consultation questions are available here.
Technology backbone for the Health Claims Data Exchange
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.
List of key types of specifications needed for Health Claims Data Exchange
Like HTTP or SMTP, open protocol for claims exchange will define the following key aspects:
Authentication (Payor, Provider, Regulator, Observer, ...)
Request/response message syntax - header and header attributes, optional body, mandatory vs optional, transport constraint on the messages, etc.
Supported methods (APIs)
Communication mode (synchronous or asynchronous nature of APIs)
Response codes
Data security and privacy considerations: Security, authenticity, and non-repudiability aspects of message exchange
Encryption of certain parts of message for transport security (beyond SSL on Health Claims data exchange)
Message signing protocol for verifiability and non-repudiation
Sequence of interactions
These will include the following policies for participation in the health claims data exchange:
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
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.
Access control policies - Role-based, need for consent to access APIs, data attributes, etc.
Exchange operation policies
Key rotation requirements
Segregation of duties and responsibilities within various teams of exchange operators
Operational reports and dashboards
Audit checklist and frequency
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:
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.
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.
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.
A thriving data exchange will also require clear rules of engagement to ensure trust from all actors. These specifications will involve guidelines around:
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.
Business SLAs
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
Dispute resolution policies
Onboarding
Defaulting/deboarding policies
Service rating policies - that would be the parameters and mechanisms to rate each type of actor on the data exchange.
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.
Instructions to send responses to the consultation questions are available here.
Digital blueprint and building blocks to implement health claims network
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.
Details of mechanisms to ensure data security and privacy
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.
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:
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:
Introduction to Health Claims Data Exchange
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:
Expand Insurance Penetration
Significantly lower cost of claims processing implies new use cases – such as OPD and Pharmacy
New kinds of payors in the market that can lead to an increase in insured base
Reduce receivable cycles and increase acceptance of cashless claims (even in smaller hospitals)
Facilitate insurance innovation
Highly personalized policies
Short duration, low premium policies
Auto adjudication, better fraud, and abuse prevention
Simplify and bring efficiency to claims processing
Standardized claims process, less operational overheads
Increase trust among payers and providers through a transparent, rule-based mechanism
Better patient experience
In its initial version, HCN is focused on facilitating message exchange for the cashless claims process and envisions to facilitate the following information flows:
Get provider/payor details
Eligibility check
Pre auth request flow
Claims request flow
Payment notification
Payment acknowledgement
Search/fetch claims data for status checks, regulatory compliance, etc.
The claims network will consist of the following key building blocks:
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.
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.
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.
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.
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.
In order to achieve this, various approaches are defined in the .
Name | Description | Type | Additional Properties |
---|
Name | Description | Type | Additional Properties |
---|
Following describes these registries and the associated APIs.
Please review the proposed details and provide comments on whether the given attributes are a minimal sufficient list for the functioning of the HCX? What other attributes may be included? What should be the cardinality of those attributes?
Please review the proposed details and any other attributes advised in Question 2 above. Please provide your comments on the data privacy or security aspect of these attributes?
Please review the proposed details and provide comments on whether the given attributes are a minimal sufficient list for the functioning of the HCX? What other attributes may be included? What should be the cardinality of those attributes?
Please review the proposed details and any other attributes advised in Question 3 above. Please provide your comments on the data privacy or security aspect of these attributes?
Instructions to send responses to the consultation questions are available .
HCX specifications could enable the existence of multiple HCX instances and relays between them (please see example flow ). What challenges do you foresee in both scenarios - single HCX for all stakeholders v/s multiple connected HCXs? What would be your criteria to choose one scenario over the other?
Instructions to send responses to the consultation questions are available .