Skip to content

Latest commit

 

History

History
56 lines (44 loc) · 17.7 KB

registries.md

File metadata and controls

56 lines (44 loc) · 17.7 KB
Raw

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

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
linked_registry_codes

Identifier of the participant in other registries. Each identifier shall be in a “normalised” notation having the structure “identifier@registry”, where registry is a unique code for the registry system and identifier is the unique id of the participant in that registry system.

Ex: facility001@hfr - to link the provider record to HFR record.

The list of supported registry codes (e.g. hfr, rohini, etc) should be a configuration at the HCX instance level.

 List
  • Optional
scheme_code

name/code of the scheme provided by the payor. scheme_code is mandatory for all participants of type “Payor”.

If a payor has multiple schemes, there will be multiple entries in the registry for the same payor (participant) - one entry per scheme.

If the payor wishes to use a single entry for all its schemes, the schem_code value should be set to “default”.

 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
primaryEmail Primary Email id for claims related communication String
  • Optional
additionalEmail Additional/alternative email ids of the participant for backup/recovery purposes. Maximum of 2 email addresses are allowed. Array
  • Optional
  • Maximum 2
primaryMobile Primary mobile number for claims related communication String
  • Mandatory
additionalMobile Additional/alternative mobile numbers of the participant for backup/recovery purposes. Maximum of 2 email addresses are allowed. String
  • Optional
  • Maximum 2
phone Landline number of the participant String
  • Optional
  • 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:

  1. UPI ID, or
  2. 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.