Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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.
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.
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.
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