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.
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.
Background of the Health Claims Data Exchange effort
The current claims filing and processing experience is fairly manual in nature.
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.
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.
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.
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.
()
The current claims exchange process is not standardized across the ecosystem
Most data flow is PDF/manual
High variability of process between insurer/TPA/provider
This results in:
Multiple follow-ups, lack of visibility
Long receivable cycles
High cost of processing
Poor scalability
Poor patient experience
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. These Health Claims Exchange Specifications for Cashless Insurance are now being published for public consultation and we seek your feedback for the same.
As a stakeholder in the health finance ecosystem, what benefits or risks do you see of implementing such a data exchange process? How can the risks be mitigated?
Inspired by the , these specifications have been developed over the last 12 months by 50+ 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.
While the 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.
This consultation document takes forward the recommendations set up by, which talks about the challenges and limitations of claims processing and advocates the setup of the data exchange mechanism (called HCP in the paper). What are the incentives/disincentives for various stakeholders to participate? Please provide the list and mention the role and description of the stakeholder.
Instructions to send responses to the consultation questions are available .
List of considerations to ensure adherence to the listed design principles
In order to fulfil architectural principles listed in Health Claims Data Exchange - Open Specifications, the protocol needs to consider the following key design elements:
The protocol must be designed to support the asynchronous exchange of information to support the scale and asynchronous nature of processes in the industry
The protocol must support the federated deployment of multiple HCX instances.
In order to ensure the security and privacy of sensitive data
The protocol must allow for separation of transport (and any other common information) from sensitive information in the respective flows
The protocol must provide for encryption, signing, and auditing of relevant information
The protocol should allow creating unique identifiers for each message exchange
The protocol should allow related multiple messages that are part of a single business flow
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
The protocol should be designed to allow for the inclusion of the new types of use cases
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)
Based on these principles and design considerations, the next section lists key components of the HCX protocols.
Please review Key Design Considerations and suggest if there are other considerations that could help in the better design of Open Protocol.
Instructions to send responses to the consultation questions are available here.
Key design principles for Open Specifications
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.
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.
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.
Minimalism is crucial to ensuring that specifications enable and do not restrict innovation or inclusion.
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.
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.
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.
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.
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.
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.
Design principles, key categories and governance proposal for the Open Specifications
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.
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:
participant_code
Machine-readable unique identifier of the participant, generated by the HCX instance.
String
Mandatory
Unique across installations - namespaced as participant_code@hcx_instance_code
hfr_code
Health Facility Registry code for the participant - used to link the provider record to HFR record
String
Optional
participant_name
A human-readable name for the participant
String
Mandatory
Unique within the HCX instance context
roles
Roles assigned to the participant as per the definition in the domain specifications. This will be used for access control.
String
Mandatory
address
The physical address of the participant including its geolocation
JSON structure
Optional
Email ids for claims related communication
String
Optional
Maximum 3
phone
Landline number of the participant
String
Optional
Maximum 3
mobile
Mobile number for claims related communication
String
Mandatory
Minimum 1
Maximum 3
status
Current status of the participant on the instance. Can be:
Created (Not verified yet)
Active
Inactive
Blocked
String
Mandatory
signing_cert_path
URI/file path to the JWT signing certificate
String
Optional
encryption_cert
URI/file path to encryption certificate
String
Mandatory
endpoint_url
Default endpoint to make API calls
String
Mandatory
payment_details
Default payment details:
UPI ID, or
Ac Number + IFSC Code
JSON Structure
Optional
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:
user_id
Machine-readable user-id as the unique identifier generated by the HCX instance.
String
Mandatory
Should be unique across the installation
user_name
Human readable use name - something like email id
String
Mandatory
Name spaced and unique within a context
Can be system generated
pin
Identification pin if needed to be set
String
Optional
mobile*
Mobile number of the user
String
Conditionally optional, if any other identifier like Aadhar is provided
email*
Email Id of the user
String
Conditionally optional, if any other identifier like Aadhar is provided
Roles
An array of additional roles (apart from being a base/citizen user which is assigned to every user by default) assigned to the user
String
Mandatory
May have different roles against different tenants in advance setups
Roles should be a subset of the ones defined in reference to Master Data in the platform
Tenant
Base tenant of the admin user
String
Mandatory
Represents key operational geography and function of the user
linkedUserId
User ID in the source system
String
Optional
Following OpenAPI 3.0 document describes these registries and the associated APIs.
Please review the proposed participant registry 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 participant registry 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 user registry 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 user registry 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 here.
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.
HCX specifications could enable the existence of multiple HCX instances and relays between them (please see example flow here). 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 here.
TLS as default mode of communication
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.
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.
In order to achieve this, various approaches are defined in the subsequent sections.
Overview of audit requirements
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.
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.
The audit information stored should be made available through an API, so that the participating systems can query the audit log related to them.
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.
It is recommended for HCX instances to have a configuration to control the amount of information that gets stored in the audit logs.
Apart from the list mentioned here, what other audit and reporting requirements would you expect HCX to fulfil?
Instructions to send responses to the consultation questions are available here.
The domain data model consists of the electronic claim (e-claim) objects (a.k.a. eObjects) that are designed to capture the required information essential for processing a health claim transaction. The e-claim objects, being machine -eadable, facilitate the flow of data exchange between different systems and data processing in health claim transactions without the need for human intervention.
All e-claim objects will be modelled as FHIR bundles of type "document", with "bundle.composition.type" specifying the type of bundle.
The first resource in the bundle shall be a “Composition” resource followed by a series of other resources referenced from the “Composition” resource. The elements “type”, “category” and “section” in the “Composition” shall be used to define the purpose and set the context of the document.
For example, the data packet for a coverage eligibility check request will be a bundle with “bundle.composition.type” as “Coverage Eligibility Check” and the bundle will have a “CoverageEligibilityRequest” FHIR resource embedded in it.
type = “document”
composition
type = “Coverage Eligibility Check Bundle”
section : cardinality (1..1)
code = “Coverage Eligibility Request”
entry : cardinality (1..1)
reference : “CoverageEligibilityRequest”
CoverageEligibilityRequest FHIR resource
Patient FHIR resource
Coverage FHIR resource
Any other resources referenced in the CoverageEligibilityRequest resource
For any resources requiring identifiers (e.g. Patient.identifier), naming systems have to be defined and agreed upon within the affinity domain to be specified in the “identifier.system” element to namespace the identifier value. This can allow an entity or resource to be referenced against system-specific identifiers. For example, a patient may be referenced as:
For some identifiers, “identifier.type” can be used to provide additional information.
“identifier.use” can be used to indicate what/where/how a particular identifier might be used for.
Example:
For external entities like patients, organisations, practitioners, etc, a reference alone is enough unless additional information is required to be passed. For example, patient address & other demographics.
All eObjects shall be encrypted and sent in the API request body and cannot be accessed by the HCX gateways. However, there is a provision in the API request body for providers and payers to share certain eObjects' related information with the HCX gateway. This information can be sent in the domain_header part of the request body (as key-value pairs) which can be accessed and stored by HCX gateways for auditing and reporting purposes. Each eObject shall define the domain header values that are to be sent in the API request body.
In addition to the workflow APIs for claim processing workflows, HCX also defines APIs for searching eObjects. To support the search APIs, all eObjects will define the search request parameters.
Payors/Providers can share certain information about eObjects with the HCX gateways as part of domain headers in the request body. At present, domain working groups have kept these headers empty. Please suggest the data in each eObject that can be shared with the HCX gateways.
HCX defines search APIs to search eObjects. The search parameters for each eObject are not currently defined. Please suggest the search parameters for each eObject. Also, should there be additional search APIs that do not require FHIR encoding of the response payload? Kindly elaborate on the nature of these APIs.
Proposed domain data models and terminologies require adopting FHIR as domain object standards. How does one facilitate and enable the participants to adopt FHIR and change their systems and processes?
Instructions to send responses to the consultation questions are available here.
Domain data specifications and business policies to implement health claims data exchange
This section focuses on business specifications needed to realize the health claims data exchange - Domain Data Specifications and domain policies.
Details of Open Protocol and TechOps policies are covered in the previous section.
Use of JWE to ensure payload security and integrity
TO ensure that sensitive information in the actual domain objects is not accessible even to the HCX, protocol requires the payload defined by the domain data specifications to be encrypted using a separate asymmetric encryption key of the final recipient established at the time of participant onboarding into the registry. API then carries the encrypted value of the payload. The payload encryption is expected to be performed using JSON web encryption RFC7516 as per algorithm and enclosed values fixed in the protected headers section above. At this point in time, no unprotected headers are envisioned in the HCX protocol. We also do not envision multiple recipient delivery in the current version of the HCX protocol.
The high-level steps to encrypt the payload using the public key of the final recipient are:
Find out the public key of the recipient through registry lookup on HCX.
Let JWE protected header be = BASE64URL(UTF8((Registered JOSE headers) U (HCX Protocol Headers) U (HCX Domain Headers)). Please note that initial version of HCX protocol requires following JOSE headers: {"alg":"RSA-OAEP","enc":"A256GCM"}
Generate a random Content Encryption Key (CEK) as per the encryption algorithm.
Encrypt the CEK with the recipient's public key using the RSAES-OAEP algorithm to produce the JWE Encrypted Key.
Base64url-encode the JWE Encrypted Key.
Generate a random JWE Initialization Vector.
Base64url-encode the JWE Initialization Vector.
Let the Additional Authenticated Data encryption parameter be
ASCII(BASE64URL(UTF8(JWE Protected Header))).
Perform authenticated encryption on the plaintext with the AES GCM algorithm using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated Data value, requesting a 128-bit Authentication Tag output.
Base64url-encode the ciphertext.
Base64url-encode the Authentication Tag
Assemble the final representation in flattened JSON serialization (Section 7.2.2 of RFC7516):
The high-level steps to decrypt and verify the integrity of the payload using the private key of the final recipient are:
From the received JSON serialized JWE token, Base64url decode the encoded representations of the JWE Protected Header (protected), the JWE Encrypted Key (encrypted_key), the JWE Initialization Vector (iv), the JWE Ciphertext (ciphertext), the JWE Authentication Tag (tag), and the JWE AAD (aad), following the restriction that no line breaks, whitespace, or other additional characters have been used.
Verify that the octet sequence resulting from decoding the encoded JWE Protected Header is a UTF-8-encoded representation of a completely valid JSON object conforming to RFC 7159; let the JWE Protected Header be this JSON object.
Let the JOSE Header be the JWE Protected Header. Verify that the resulting JOSE Header does not contain duplicate Header Parameter names.
Determine the Key Management Mode employed by the algorithm specified by the "alg" (algorithm) Header Parameter.
Verify that the JWE uses a key known to the recipient.
Decrypt the JWE Encrypted Key to produce the CEK. The CEK MUST have a length equal to that required for the content-encryption algorithm.
Compute the Encoded Protected Header value BASE64URL(UTF8(JWE Protected Header)). This protected header is (Registered JOSE headers) U (HCX Protocol Headers) U (HCX Domain Headers).
Let the Additional Authenticated Data encryption parameter be ASCII(Encoded Protected Header).
Decrypt the JWE Ciphertext using the CEK, the JWE Initialization Vector, the Additional Authenticated Data value, and the JWE Authentication Tag (which is the Authentication Tag input to the calculation) using the specified content-encryption algorithm, returning the decrypted plaintext and validating the JWE Authentication Tag in the manner specified for the algorithm, rejecting the input without emitting any decrypted output if the JWE Authentication Tag is incorrect.
Participating systems are expected to follow best practices guidelines as in RFC8725 to ensure the security of the payload.
It is recommended to rotate these encryption keys once every year and mechanisms implemented for the providers/payers/HCX to intimate the ecosystem about the potential compromise of the keys.
Here is a sample of the set of libraries that you can explore:
Bouncy castle
Openssl
NaCl
Libgcrypt
PyNaCl
TweetNaCl
This section suggests JSON Web Encryption as per RFC7516 as the mechanism for payload security and integrity. Which alternative mechanism for payload security and privacy would you explore for HCX? Kindly provide the pros and cons of the alternative mechanism.
In addition to the best practices mentioned in RFC8725, which other best practices/guidelines would you suggest to HCX participants for data security and privacy?
Instructions to send responses to the consultation questions are available here.
Building blocks of the Health Claims Data Exchange protocol
As indicated in the 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, ...), and performing necessary validations, and forwarding it to the intended recipients.
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.
Response - Response/reply by the recipient of the request by passing relevant response payload defined by this protocol. Responses may also travel from the “original request message” recipient to the “original request message” sender through a relay of HCX instances. The key difference here is that a response is always sent as an earlier event received from the HCX instance.
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).
Message - HCX protocol transfers a Message that contains a transport envelope and the content as per the use case.
Transport envelop is a set attribute that carries the transport information for HCX to reliably forward the message to the destination
Content would have two parts:
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
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.
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.
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 shown below:
Sender to HCX (Leg 1)
The sender (originator of the communication) sends the initial message to its preferred HCX instance.
HCX validates the status of the sender and the next intended recipient (maybe another HCX instance) on its registries.
HCX then performs required signature verifications etc before responding with an acknowledgement to the sender.
It then forwards it to either the end recipient (if registered with the same instance) or the next HCX in the chain.
Steps 1 and 7 in the above diagram as examples of this leg.
HCX to Receiver (Leg 2)
Final HCX in the relay chain (could be the original HCX itself) checks the status of the recipient on its registries,
performs needed verifications and forwards the message to the recipient.
The recipient acknowledges the receipt of the message.
Steps 3 and 9 in the above diagram as examples of this leg.
Receiver to HCX (Leg 3)
The recipient (receiver of the original request message) sends the response message to its preferred HCX instance.
HCX validates the status of the recipient and original sender (maybe another HCX instance) on its registries.
HCX then performs required signature verifications etc before responding with an acknowledgement to the recipient.
It then forwards it to either the initial sender (if registered with the same instance) or the next HCX in the chain.
Steps 4 and 10 in the above diagram as examples of this leg.
HCX to Sender (Leg 4)
Final HCX in the relay chain (could be the original HCX itself) checks the status of the original sender on its registries,
Performs needed verifications and forwards the response message to the sender.
The sender acknowledges the receipt of the response message.
Steps 6 and 12 in the above diagram as examples of this leg.
Relays
In case Sender and receiver are listed/registered on different HCX instances, there may be relays between the HCXs. Steps 2, 5, 8 and 11 in the above diagram may involve such relays. Appendix A provides an example of a provider-payor use case with a relay between two HCXs.
To facilitate safe, secure, and reliable message exchanges through HCX, its message payload needs to be designed in a manner that separates the actual use case-specific information (payload) from transport and generic domain-specific information (headers). To achieve this, HCX messages can be structured in line with JWE tokens as below (value in bracket are the corresponding JSON keys as per JWE):
Protected headers (protected) - A set of attributes that provide transport, security, message integrity and summary information about the message being exchanged.
Encrypted Payload (ciphertext) - Payload containing the relevant domain entity (eObject) as prescribed for the use case by the domain specifications. This needs to be encrypted so that HCX cannot read this.
Signature (tag) - Digital signature on the protected header and the payload of the message to ensure its integrity.
Other JWE elements like iv (Initialisation Vector for the algorithm), aad (additional authentication data), and encrypted_key (Content Encryption Key)
HCX expects the resulting JWE token to be JSON serialised. The following subsections detail each of these message elements:
Protected headers contain information that helps exchanges to identify senders, receivers of the message, perform integrity checks, audits and routing functionality. Header values are posted in clear and never contain any Personally Identifiable Information (PII) about the patient. HCX protocol uses JWE protected headers for such information to ensure these are not tampered with by the intermediate gateways. Protected Headers for HCX will be the union of the following three header categories:
JSON Web encryption header as per RFC7516. For HCX V1, this is proposed to be fixed to:
{"alg":"RSA-OAEP","enc":"A256GCM"}
Used as private headers as per RFC7516 section 4.3. Please note that all the parameter names are appended with “x-hcx-” to avoid a collision.
The following table provides the protocol related header elements in the claims exchange:
x-hcx-sender_code
Registry code of the sender (e.g. provider or payer)
String
Mandatory
x-hcx-recipient_code
Registry code of the recipient (e.g. provider or payer)
String
Mandatory
x-hcx-request_id
Sender generated unique id for each originating request.
String
Mandatory
x-hcx-correlation_id
Unique id of the conversation (a collection of related messages). It may be chosen as the message_id of in the original sender’s (initiator’s) system. For return messages (asynchronous responses) responders are expected to populate with the one in the request.
String
Mandatory
x-hcx-workflow_id
Unique id of workflow that may span over a series of message exchanges, e.g. an eligibility check, a preauth and then claims submission for a patient may be linked with such an id from the providers initiate a request on check eligibility
String
Optional
x-hcx-timestamp
Unix timestamp of the message while sending
datetime
Mandatory
x-hcx-debug_flag
Request to the server to include debug information. Useful in the time of integration testing and prod debugging. However, server(s) may choose to ignore this flag based on their policy.
ENUM
- Error
- Info
- Debug
Optional
x-hcx-status
Operational status of the message. Depending on the leg of the message it would be:
request.initiate
request.retry
response.success
response.fail
response.sender_not_supported
response.unhandled
response.request_retry
String
Mandatory
x-hcx-error_details
Expected to be used for providing details of the status. It Will be especially useful in scenarios where Operational status indicates an irrecoverable error.
Key elements of this object are:
Code: error, info, debug code from the system - expected to be namespaced for better readability
Message: Short description of the detail
Trace: Long description supporting the Code
JSON Object -
E.g.
{error.code: “bad.input”, error.message: “Provider code not found”, trace: “”}
Optional
x-hcx-debug_details
Expected to be used for providing details of the status. It Will be especially useful in debugging scenarios
Key elements of this object are:
Code: error, info, debug code from the system - expected to be namespaced for better readability
Message: Short description of the detail
Trace: Long description supporting the Code
JSON Object -
E.g.
{error.code: “bad.input”, error.message: “Provider code not found”, trace: “”}
Optional
JSON object containing a map of domain-specific header values as proposed in domain data specifications. E.g. For claims use cases, domain specs may decide to populate the total claimed amount, list of diagnostics/procedures. Please note that all such parameter names must follow the naming convention x-hcx-<use_case_name>-<parameter_name>, where
use_case_name = short name (<16 chars) given to the use case by domain working group, it is advisable to keep it the same as the one in API’s URI path
Parameter_name = short name (<32 chars) given to the parameter
Therefore the protected headers will be:
Protected Headers = (Registered JOSE headers) U (HCX Protocol Headers) U (HCX Domain Headers)
Use case-specific base64 encoded, encrypted payload as defined in Domain Data specifications. This can be thought of as a private claim in JWT terminology. JSON web encryption as defined in RFC7516 to be used for encrypting the payload with “alg” and “enc” as defined in the JOSE header above.
E.g. In the current cashless claims scenario, domain working groups have decided the payload to be an FHIR bundle of the appropriate type. Therefore the payload will be an encrypted FHIR bundle as defined in the domain data specs.
As per RFC7516, cryptographic mechanisms used in JWE encrypts and provides integrity protection to encrypted payload and protected headers using Authenticated Encryption with Associated Data (AEAD), hence additional signatures are not needed for message integrity protection.
Based on the above protocol definition and the message structure, each use case API in the HCP ecosystem is expected to follow the following pattern for the onward and return journey of the use case message:
<transport_protocol>://<server_address>/<protocol_version/><resource_name>/<action|on_action>, where
transport_protocol - for HCX V1 purpose it will always be https
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)
protocol_version - API version for the current protocol to help support protocol transitions
resource_name is the name of the domain resource that the API is serving. E.g. for cashless claims, it may be “claims”, “coverage eligibility”, etc. based on the use case.
action is the action sought within the context of that resource
on_action represents the callback from the receiving system for responding to the original message
Keeping this pattern in mind, in the current cashless use case following APIs are expected to be supported.
Please note that search APIs are expected to support search parameters as detailed in the domain data specifications. For FHIR based entities this is expected to be clearly published in the corresponding implementation guides. Visibility and availability of the attributes in the search result payloads are also expected to be defined in domain data specifications.
Eligibility check
/coverageeligibility/check (provider->HCX, HCX->payor)
/coverageeligibility/on_check (payor->HCX, HCX->provider)
PreAuth submission
/preauth/submit (provider->HCX, HCX->payor)
/preauth/on_submit (payor->HCX, HCX->provider)
PreAuth Search
/preauth/search (provider->HCX, HCX->payor)
/preauth/on_search (payor->HCX, HCX->provider)
Claim submission
/claim/submit (provider->HCX, HCX->payor)
/claim/on_submit (payor->HCX, HCX->provider)
Claims Search (Also supports status search)
/claim/search (provider|regulator|auditor->HCX, HCX->payor)
/claim/on_search (payor->HCX, HCX->provider|regulator|auditor)
Payment notice and acknowledgement
/paymentnotice/request (payor>HCX, HCX->provider-)
/paymentnotice/on_request (provider->HCX, HCX->payor)
Payment Search (Also supports status search)
/paymentnotice/search (provider->HCX, HCX->payor)
/paymentnotice/on_search (payor->HCX, HCX->provider)
Following OpenAPI 3.0 specification details these APIs in detail.
Please review the Exchange Protocol and provide comments/suggestions on its comprehensiveness. Kindly provide aspects of the protocol would you find challenging and suggestions to overcome those challenges.
While the consultation paper covers only interactions between the provider and payer, and the interactions with the beneficiary will be detailed post public consultation, what additional workflows do you think must be considered?
Instructions to send responses to the consultation questions are available here.
This version of the HCX specification defines the domain model specifications required for the following eObjects:
Coverage Eligibility Request and Coverage Eligibility Response
Claim Request and Claim Response: These objects will be used for both Pre-Authorization and Claim use cases (and for Pre-Determination also in future).
Payment Notice and Payment Reconciliation
As mentioned in the design considerations for domain specification, the eObjects leverage HL7/FHIR4 specification and extend it, wherever required.
As per the design considerations and guidelines listed in the previous sections, the coverage eligibility request payload has to be created as an FHIR document bundle. The bundle should have the following resources:
Claim object is used by providers to submit pre-authorization and claim requests to the payers. The same eObject can be used for both these use cases and the usage can be differentiated by the value of “claim.use” element. The value of this element should be set as “preauthorization” for Pre-Authorization requests and as “claim” for Claim requests.
ClaimResponse object is used by payers to send the response for pre-authorization and claim requests to the providers. The same eObject can be used for both these use cases and the usage can be differentiated by the value of “ClaimResponse.use” element. The value of this element should be set as “preauthorization” for Pre-Authorization responses and as “claim” for Claim responses.
Details of API security to ensure authenticated and authorised access to APIs
The protocol defines an API key-based security for authentication and authorization of the API calls between the participating systems and the HCX gateway. HCX instances have to generate the API keys in the form of JWT tokens () and shall mandatorily set an expiry time for all the generated tokens.
In future versions, HCX instances may support JWTs issued by other system identity providers, e.g. Health Facility Registry’s IDP.
All participant systems (e.g.: providers, payers) should obtain an API key from the HCX gateway with which it identifies itself to the gateway. When calling any API on the HCX gateway, the participant system should pass the API key as part of the 'Authorization' http header.
After a successful verification and onboarding of a participant system onto the participant registry, the HCX instance managing the registry shall share the following details via email, SMS, or both with the participant system:
client_id: this is the identifier of the participant in the participant registry.
client_secret: a unique secret is generated for the participant by the HCX instance. The client_secret value shall be stored in the participant registry in an encrypted format and shall not be sent in the registry APIs.
The participant system can call ‘/token/generate’ API along with the client_id and client_secret they have received to obtain the API key.
HCX instance would respond with the API token upon successful validation of the client_id and client_secret values:
JOSE Header should be a JSON with the following values:
JWS Payload should be a claim set containing the mandatory claims jti, iss, sub, iat and exp.
jti - unique identifier for the JWT
iss - HCX instance identifier
sub - client_id of the participant
iat - unix timestamp at which the JWT is issued
exp - the expiration time after which the JWT must not be accepted for processing
JWS Signature must be computed in the manner defined for HS256 algorithm over the input ASCII(BASE64URL(UTF8(JOSE Header)) || '.' || BASE64URL(JWS Payload)) using the client_secret value of the participant.
HCX instances can revoke the API key of a participant by generating a new client_secret and updating it in the participant registry. The participant system has to generate a new API key by calling the ‘/token/generate’ API with the new client_secret value.
HCX instances while making the calls to the participant system will use a self-generated JWT token with the following elements:
JOSE Header should be a JSON with the following values:
JWS Payload should be a claim set containing the mandatory claims jti, iss, sub, iat and exp.
jti - unique identifier for the JWT
iss - HCX instance identifier
sub - same as iss claim, HCX instance identifier
iat - unix timestamp at which the JWT is issued
exp - the expiration time after which the JWT must not be accepted for processing
JWS Signature must be computed in the manner defined for RS256 algorithm over the input ASCII(BASE64URL(UTF8(JOSE Header)) || '.' || BASE64URL(JWS Payload)) using the private key of the HCX instance.
Participant systems should validate the API key signature using the public key of the HCX instance.
There are two key DSLs being considered for the Health Claims Exchange - Policy Markup Language (PML) and Bill Markup Language (BML). These are currently work in progress and are expected to be released in the later version of HCX specifications after substantial proof of concept development with various members of domain working groups.
The purpose of policy markup language is to provide a DSL to payers such that the policies can be encoded in machine readable format, thereby helping with the automation of eligibility check and adjudication processes.
The purpose of bill markup language is to provide a DSL to payers such that the supporting bills can be parsed as machine readable structured data, thereby helping with the automation of adjudication processes.
The section above refers to adopting appropriate DSLs for policy and bills. Kindly suggest your views on the useability of such domain-specific language and provide prior examples.
Are there any existing solutions that have been used/experimented with? Please provide examples.
Instructions to send responses to the consultation questions are available .
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.
Such a publication can be used to validate content against the implementation guide as a whole.
The extended profiles and structures of the FHIR bundles and resources to be used in HCX are available .
Potential multi HCX scenario
The cross gateway communication will be required in the following scenarios –
When a provider is onboarded in a gateway instance but the payer for that health policy scheme is registered in another gateway instance.
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.
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.
The most significant aspect of domain specification would be agreement on formats for data exchange and terminologies (taxonomies) being used in those data models. These would mainly include:
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-related codes (e.g. room rent, ICU charges, etc.), 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.
In order to achieve this, in line with the key design principles detailed in , following key design guidelines are proposed:
Data specifications should be broken down to simpler fundamental units as far as possible.
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:
Leverage HL7/FHIR R4 specifications wherever possible
Leverage NRCES FHIR specifications where base FHIR specs need contextualization to the Indian context
Create minimal extensions needed in case both base FHIR and NRCES specs are not enough to support the use case
FHIR Document profiles appropriate for the protocol should be created composed of base FHIR resources
Data specifications should be created with the principle of minimalism and inclusivity. In order to achieve this:
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.
Specs should use permissive terminologies/code binding strength as much as possible. E.g. in the (Section 4.1.5), if there’s a conflict in choosing between “extensible” and “preferred” strengths for a coding system, “preferred” should be chosen.
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:
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.
Data specifications should allow for namespacing in field names to indicate the source/reason/category of the extended fields.
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.
Based on the priorities listed above and design considerations, key domain specifications included in Phase 1 are detailed in the following sub-sections.
API keys are expected to be in JWT format and signed as per JSON web signature (). The API key should have three elements separated by periods (.): BASE64URL(UTF8(JOSE Header)), BASE64URL(JWS Payload), and BASE64URL(JWS Signature).
This section suggests JSON Web Tokens as per as the mechanism for API security. Which alternative mechanism for API security would you explore for HCX? Kindly provide the pros and cons of the alternative mechanism.
Instructions to send responses to the consultation questions are available .
Resource
Description
Composition
type: should be a code representing Coverage Eligibility Request document type.
section: The document shall have one section with a single entry having reference to CoverageEligibilityRequest resource.
structure definition: CoverageEligibilityRequest Document
CoverageEligibilityRequest
The document must contain a CoverageEligibilityRequest resource.
FHIR Profile: link
structure definition: CoverageEligibilityRequest
Patient
The document should contain a Patient resource with minimal required information about the patient (refer to rows #38-42 in the “Coverage eligibility check” sheet).
FHIR Profile details:
Patient resources should mandatorily have an NDHM identifier.
Patient resources can also have a hospital Id (Medical record number).
Patient resources can also have an insurance id (PMJAY ID).
Patient resources can also have employee IDs and other business identifiers.
structure definition: Patient
Coverage
The document should contain one or more Coverage resources with minimal information of the policy about which the information is requested (refer to row#30 in the “Coverage eligibility check” sheet).
FHIR Profile details:
Coverage resources should mandatorily have an identifier for the policy ID issued by the insurer.
structure definition: Coverage
Key
Description
Key
Description
Resource
Description
Composition
type: should be a code representing Coverage Eligibility Response document type.
section: The document shall have one section with a single entry having reference to CoverageEligibilityResponse resource.
structure definition: CoverageEligibilityResponse Document
CoverageEligibilityResponse
The document must contain a CoverageEligibilityResponse resource.
FHIR Profile: link
structure definition: CoverageEligibilityResponse
Coverage
The document should contain one or more Coverage resources with minimal information of the policy about which the information is being returned.
FHIR Profile details:
Coverage resources should mandatorily have an identifier for the policy ID issued by the insurer.
structure definition: Coverage
Key
Description
Key
Description
Resource
Description
Composition
type: should be a code representing Claim Request document type.
section: The document shall have one section with multiple entries having references to Claim and Signature resources.
structure definition: ClaimRequest Document
Claim
Coverage
The document should contain one or more Coverage resources with minimal information on the policy about which the information is being returned.
FHIR Profile details:
Coverage resources should mandatorily have an identifier for the policy ID issued by the insurer.
structure definition: Coverage
Encounter
Condition
Signature resources
List of signatures by Hospital, Doctor and Patient associated with this Claim request.
structure definition: Signature
Key
Description
usage
“preauthorization” or “claim”, to indicate the use case this eObject is being used for.
Key
Description
Resource
Description
Composition
type: should be a code representing Claim Response document type.
section: The document shall have one section with a single entry having reference to ClaimResponse resource.
structure definition: ClaimResponse Document
ClaimResponse
The document must contain a ClaimResponse resource.
FHIR Profile: link
structure definition: ClaimResponse
Key
Description
usage
“preauthorization” or “claim”, to indicate the use case this eObject is being used for.
Key
Description
Resource
Description
Composition
type: should be a code representing Payment Notice document type.
section: The document shall have one section with a single entry having reference to PaymentNotice resource.
PaymentNotice
The document must contain a PaymentNotice resource.
FHIR Profile: link
structure definition: PaymentNotice
PaymentReconciliation
The document should contain a PaymentReconciliation resource with information about the payment related to this payment notice.
FHIR Profile: link
structure definition: PaymentReconciliation
Key
Description
Key
Description
Participating systems in the Claims information exchange ecosystem may possess one or more of the following roles. These roles are based on the base set of organisation roles defined in hl7 specifications here. Namespaced coding is used to further qualify the role in the context of the claims exchange process.
provider: Health Service Provider
payer: Insurance service provider
agency.tpa: Third party administrator acting on behalf of the payer. In the current version, this role is expected to behave like a payer from the data exchange perspective.
agency.regulator: IRDAI and IIB like regulatory bodies.
research: Research groups, etc.
member.isnp: eCommerce platforms facilitating insurance adoption
agency.sponsor: Scheme owners of specific programs, e.g. NHA for Ayushman Bharat
HIE/HIO.HCX: Other HCXs
The following table further describes these roles for their corresponding access rights and scenarios for version 1 of the claims exchange process:
Role
Allowed actions
Comments
provider
Eligibility check
Send request
Receive response
Pre Auth
Send request
Receive response
Claims request
Send request
Receive response
Payment
Receive notice
Send Acknowledgement
Search/Status
Pre auth
Claims status
Providers can make search/status requests for multiple requests that originated from them.
payer/
agency.tpa
Eligibility check
Receive request
Send response
Pre Auth
Receive request
Send response
Claims request
Receive request
Send response
Payment
Send notice
Receive Acknowledgement
Search/Status
Payment confirmation
Payers can make search/status requests for multiple payment notices that originated from them.
agency.regulator
Search
Claims
Data exchange switch will forward the search request to all payers who are expected to return the claims data in the proposed FHIR structure as per regulator’s policies.
research
Eligibility check
Receive request
Send response
Search
Pre Auths - aggregate and/or anonymised
Claims - aggregate and/or anonymised
All data exhausts for these roles would only have aggregate and anonymised data. Key aggregations for eligibility requests, preauthentication, claims and payments information will need to be further defined.
member.isnp
Eligibility check
Receive request
Send response
Search
Pre Auths - aggregate and/or anonymised
Claims - aggregate and/or anonymised
Claims - Individual claims data as per beneficiary consent
As facilitators of insurance eCommerce, it is proposed to provide ISNPs access to the data available to research role as well as individual beneficiary queries (preauth, claims) based on beneficiary consent. This consent flow is expected to work with existing consent management infrastructure and ISNPs are expected to submit the acquired consent as part of the domain header.
agency.sponsor
As planners of the insurance schemes, sponsors are proposed to be given access equivalent to payer role.
HIE/HIO.HCX
As an HCX this participant is expected to play different roles as per the need of the use case. However, due to the data privacy and security measures prescribed in the Open Protocol, it will not be able to view the actual payload.
The primary stakeholders/roles in the HCX ecosystem are mentioned in the section Access Control. Are there any other primary or secondary stakeholders that should be considered as HCX participants? If yes, please outline their role in the HCX ecosystem.
This section also mentioned allowed actions for the current set of stakeholders, please review these actions and suggest any changes needed for those actors.
Instructions to send responses to the consultation questions are available here.
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 immutability, non-tamperability, and non-repudiability.
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.
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. These documents will be released for public consultation in time for an initial pilot of the HCX ecosystem.
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 is:
Onboarding
Defaulting/Deboarding policies
Dispute resolution policies
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.
Business SLAs
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
Service rating policies - What would be the parameters and mechanisms to rate each type of actor on the data exchange.
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:
Policies should focus on enabling the ecosystem rather than monitoring or controlling it
Policy formulation should be done as an open consultative process to foster trust in policies
Rules of participation and disqualification should be transparently laid out
They should follow the principle of minimalism and be evolved over a period of time
Keeping these guidelines in mind, the following key policies guidelines are provided for the purpose of wider consultation as part of version 1:
Access control (Roles)
Participant onboarding/deboarding
Grievance redressal
Event Audit
To achieve semantic interoperability, it is recommended that HCX data standards incorporate well established and suitable terminology and coding systems.
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.
For Clinical resources (e.g. Condition, Procedure, Observations) - please refer to the guidance issued by NRCeS.
In India, SNOMED-CT is free for use by all as Clinical Terminology, while ICD codes are used for classifications.
Labs typically use LOINC codes
For other code/concepts in the FHIR based data standards, we would recommend guidelines
If any attributes are marked as “required” - then, use of the codes defined in the value sets
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.
If marked as “example” - then the domain must agree and define a value set for usage.
ValueSet may be created derived from existing sets, either composed/included from the base or expanded.
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.
For the broader NDHM interoperability and conformance, HCX would align/inherit domain specific guidelines.
The table below lists the code systems/value sets proposed by current domain working groups. Based on the above guidelines, we are proposing them to be “preferred” or “example” binding strengths as per FHIR Terminology binding strength definitions (Section 4.1.5).
Terminology name
FHIR Value Set link
Proposed Binding Strength
Insurance Company Owners
(coverageeligibilityrequest.insurer)
Preferred
Procedure Type
(claim.procedure.type)
Example
Procedure Code
(claim.procedure.procedureCode)
Example
Denial Codes (claimresponse.item.adjudication.reason)
Preferred
Procedure Modifiers
(claim.item.modifier)
TODO
Example
Service Categories
(claim.item.category)
Example
Service Codes
(claim.item.productOrService)
TODO
Preferred
Medical Speciality Type
(practitionerRole.speciality)
Preferred
Health Service Provider role
(claim.careTeam.role)
Example
HCX or a neutral protocol supporting organisation will host domain specific FHIR Terminology Services which the ecosystem can leverage to retrieve information and use, and validate resources as defined by the IG.
During multiple discussions with the ecosystem, it has been suggested that while the specifications suggest recommended terminologies, they are not yet mandated (hence the low binding strength's against each terminology). Kindly provide your view on mandatory standardisation of terminologies and approaches to enable your suggestions.
In your view, what clinical terminologies and codes (e.g SNOMED-CT, ICD-10, LOINC) be considered? In addition, are you aware of any well established and accepted codes/value sets available that can be applicable to the Indian scenario? Kindly provide details.
Instructions to send responses to the consultation questions are available here.
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.
A list of different kinds of participants who would need onboarding into an HCX registry is provided in the section above. Onboarding onto the HCX is envisioned as a two step process:
Sandbox - for compliance testing and certification
Go Live on live instances
Sections below provide high level guidelines for each of these steps.
The key goal of the sandbox is to help the ecosystem test its specific components against the communication standards, and get certified to become a part of the system. Once a participant successfully completes the sandbox process, they can use the certification to get onboarded to the HCX production environment with the necessary access.
HCX operator(s) may nominate or list Sandbox operator(s) whose certification will be considered valid for onboarding to their platforms.
The following are the steps to integrate, test and launch with the help of sandbox.
Step 1: Registration
The participants submit an online application to express their interest to access the HCX sandbox. The requests from different participants are verified to see if the participant is eligible to participate in the sandbox environment by doing basic checks against the details provided in the application form. Details of the model application form for various roles will be developed in the upcoming phase of the specifications.
There may be requests that would not satisfy the conditions required for the sandbox access such as multiple requests from the same participant, participants not registered with any registry, TSPs without a valid website, spam applications, etc., which would prove to be redundant and may have to be filtered. This process would be semi-manual.
On successful verification, the approved participants are added to the HCX sandbox and provisioned with the necessary credentials to access the sandbox environment.
Step 2: API integration and testing
In this step, the participants integrate their respective claim processing applications with the sandbox HCX. This is to aid the developments as well as ensure that their applications are compliant with the HCX standards and build all the missing pieces on their side to use the set of HCX APIs necessary for their planned workflows.
Sandbox website would 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.
Step 3: Sandbox certification
All participants are expected to fulfil a set of functional and security tests/flows applicable to them.
Once the system is ready and tested against the applicable test cases, the participant will be required to submit their test results including the application's usage of and interaction with HCX APIs to the Sandbox Operator for review and approval.
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.
After obtaining the affiliated sandbox certification, the participant would have to apply for onboarding into the HCX production environment. This process will consist of the following key steps:
Step 1: Registration on HCX
In this step, interested participants will be required to go through the onboarding process with the HCX. HCX operators are expected to provide a choice of registration flows with the following high level guidelines:
If the participants are registered in the NDHM Health Facility registry, then they should be allowed to use HFR authentication as a means to register in the HCX registry, if they choose to do so.
If the participants are not registered in the NDHM Health facility registry then the participant should be allowed to use alternate means of verification like
Option to complete the NDHM HFR process and use the resultant credentials.
Authentication/Certificates/documents from IRDA or equivalent such agency identified and clearly stated in HCX’s onboarding policy.
Summary details of the HCX application duly filled. This application form will be more detailed, requiring more details of the participant including contact numbers, company registration details, and other details as needed in the HCX registry.
Step 2: Review of Sandbox certification
A final round of approval for application go-live will be sought from the internal team at HCX. Applicants will be required to share Functional and security testing certificates issued by the affiliate sandbox environment.
Step 3: Provisioning of production credentials
Once these requirements are met, the participant id along with the production access secret credentials will be provided. Participants are expected to keep the secret credentials safe and report any compromises at the earliest to the HCX operators.
Step 4: Go-Live
The application is now expected to be prepared for go-live in respective participant ends. All the participants are advised to plan the change management at their end and conduct necessary training for their staff before going live in production HCX, preferably after piloting with a small set of clients.
This section lists some of the deboarding scenarios that may be considered as part of the final deboarding policies by the HCX operators:
Involuntary deboarding of a participant initiated by Regulator/Legal Authority. Few examples:
Suspension/Deactivation of a provider by a regulator for fraudulent activity.
Suspension/Deactivation of a TPA or a Payer by IRDA
Involuntary deboarding of a participant (mostly TSPs) initiated by HCX. Few cases:
Serious violation of HCX policies (e.g. grave SLA violation repeatedly)
Hacking attempts made by participants for unauthorized access, after an investigation by HCX
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).
Voluntary deboarding of participants. Few examples:
A provider or payer shifting to another HCX
A provider or payer shuts down their business
A provider or payer merges with another entity listed on the exchange
Please note that while the above list suggests a few of the scenarios for potential deboarding of a participant, this process should be treated with utmost care and an elaborate warning mechanism should be kept in place whenever the deboarding is not voluntary.
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 deboarding of a participant.
This section proposes a high-level approach that can be adopted for onboarding/deboarding 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 onboarding/deboarding policy formulation as well as a model policy for easy adoption. These documents will be released for public consultation in time for an initial pilot of the HCX ecosystem.
While the working groups will further deliberate on details, according to you what should be the mechanism of the certification on the network? Who all can be the certifying authorities?
How do you suggest verifying the identity and authenticity of various participants in the exchange (like facilities, payers), owing to the fact that the national level registries - HFR and HPR - are not complete, but only include the providers and facilities in the places where it is piloted (UTs)? What is your point of view on these registries, once complete, be the only mechanism for verification?
While the actual grievance redressal policy 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. These guidelines and approach are aligned with earlier thinking from IRDAI in its publication , however, these are now envisioned to cover grievance from any actor of the ecosystem with respect to other actors.
Final operational policies for grievance redressal are expected to be drafted by the HCX operators as these may change over time based on the need of the ecosystem and use cases under consideration. However, to make the policies consistent and effective, the following key grievance policy design guidelines are proposed:
Each HCX operator must publish a dispute/grievance resolution policy to allow digital initiation, routing and tracking of the grievances of any of the participants.
The policy should clearly list out all the grievances that would be addressed under it and mechanism to resolve grievances that are not covered under it.
The policy should require all participating actors to set up nodal governance bodies contactable at the digital and physical communication mechanisms provided as part of onboarding. These communication details are made available to all participants using the read access to the registry.
As part of the participant registry, the HCX instance also publishes the details of its governance body.
The policy should publish the types and priority of the grievances handled by each type/role of the participant including any required as per prevailing regulations.
The policy should publish SLA for each grievance type including any required as per prevailing regulations.
The policy should be versioned, required to be signed by new members at the time of onboarding and any change has to be proactively informed to all existing network participants.
The policy should require ample due diligence cycle to address the grievance and review the redressal before responding back to the requester
The policy should allow for the reopening of the grievances
The policy should allow for escalation to the network operator in case the requestor does not feel satisfied with the resolution. Escalated grievances should follow accelerated timelines for resolution.
The policy should clearly layout review and resolution criteria for a grievance to be escalated and the approach the operator would take to reach a resolution.
The policy should include ways of keeping requesters informed about the latest status and any additional requirements to help address the grievance.
Like with the specifications so far, constitute a new working group for Dispute Resolution policies.
The working group drafts a model policy in accordance with the above principles and in line with the detailed approach from step 2 above.
The principles, detailed approach and model dispute resolution policy draft is versioned and released for public consultation.
The domain working group deliberates the feedback and enhances principles/model policy as needed.
HCX Operators adopt the model policy according to the needs of their network
Further enhancements, e.g. for new use cases, changes in approach, improvements in model policy due to on-ground observations undergo steps 3-6 and result in a newer version of the artefacts (principles, approach or model policy).
This section proposes a high-level approach that can be adopted for grievance redressal 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 grievance redressal policy formulation as well as a model policy for easy adoption. These documents will be released for public consultation in time for an initial pilot of the HCX ecosystem.
Beyond what’s being proposed as a guideline, what areas and roles do you think HCX as the data exchange gateway should play in grievance redressal?
While the working groups will further deliberate on details, according to you what should be the mechanism of the grievance redressal on the network? What should be the key grievances that need to be honored between network participants? How should escalations work?
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 .
Instructions to send responses to the consultation questions are available .
Drafting and evolving an efficient and truly implementable policy for grievance resolution would need active participation from the HCX ecosystem. Keeping this in mind, the following high level approach is proposed in line with the overall :
The working group contextualises and adopts the open specifications design principles and high level approach as detailed in for the dispute resolution context.
Instructions to send responses to the consultation questions are available .
Next steps on specifications and open-source reference implementation
As indicated in Key User cases/Workflows, the current version of specifications mainly covers cashless insurance use cases. Also, the real test of specifications and approach defined so far would be in using them in live scenarios. With these two objectives in mind, below are two key dimensions of the proposed roadmap:
Following key focus areas are proposed to be further worked upon while the first version of the open-source HCX tech platform is made available for implementation:
Enhancements of the specifications for the reimbursement use case
Further detailing of formulation approach and model policies for
Participant onboarding/deboarding
Grievance redressal
Event audits
Beneficiary authentication (by participants)
Market rules around charges and fees
Claims adjudication
Guidelines for Technical Operations
Domain Specific Languages:
Policy Markup language - To assist auto-adjudication and eligibility checks through the machine-readable encoding of policies
Bill Markup Language - To assist auto-adjudication through the machine-readable encoding of bills
Explanation Markup Language (Low priority)
To enable the Learn-Do-Learn cycle of taking the HCX work forward, Swasth proposes to build the first version of Open Source reference implementation of the HCX software. Following timelines are proposed for this reference version:
V1 of the open-source reference software - December 2021
Availability of sandbox for pilot integrations - January 2022
Production readiness/Go Live of HCX and integrations - March 2022
The Roadmap on specifications provides a list of areas that are being planned for further work. Please provide your priority order for these areas. Kindly feel free to add additional areas that you may want to include in the specification work.
Instructions to send responses to the consultation questions are available here.
Authentication of beneficiaries by providers on provider TMS/beneficiary APP.
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.
Authentication of beneficiaries by providers on provider TMS/beneficiary APP
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.
The payer TMS system and HCP will integrate the Aadhar authentication open API for verification of the beneficiary ID during the claim validation stage.
Authentication of beneficiaries by providers on provider TMS/beneficiary APP
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 enrollment of beneficiary in their systems and validate the beneficiary ID during claim processing
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.
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.
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.
Instructions to submit comments & responses to consultation questions, and consolidated list of questions
Written comments on the HCX specifications and responses to the consultation questions are invited from all the members of the ecosystem. The last date to submit responses is October 8, 2021. Comments and responses are to be sent via email to hcx@swasthapp.org.
The specification document can also be downloaded as a PDF for offline consumption. Instructions to download specifications as a PDF are available here.
Please respond to the individual questions captured in various sections. You may refer to the relevant sections to read the full text.
Please note that the questions included are intended to guide the consultation process and not to restrict the thinking on these lines. Therefore participants are invited to think of and suggest any other relevant guiding questions/comments/suggestions and include them in their responses.