Registries

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

• Easy maintenance of base data at the source registry

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

• Better interoperability

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

• Create

• Update

• Search

• Delete

• Cancel

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

Participating Organisations/Systems Registry

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

Name	Description	Type	Additional Properties
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	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

User Registry

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

Name	Description	Type	Additional Properties
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.

Questions for Consultation

Question 1

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?

Question 2

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?

Question 3

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?

Question 4

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.