layout | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
The concept of a beneficiary registry (BR) involves maintaining a database or record system that contains information about individuals or entities who are beneficiaries of a particular program, service, or assistance. This registry typically includes details such as the beneficiary's identity number, eligibility criteria, participation in programs, entitlements, and any benefits received.
BR resides in PBMS and contains the following:
- Beneficiary to Program mapping
- Entitlement of beneficiaries
- Status of disbursement
BR may be queried to know about all the programs that a beneficiary is enrolled into. Further, information on the amount of assistance (cash, in-kind) along with disbursement status may be queried.
OpenG2P registry is a single repository containing details of the registrants. The registry uses PostgreSQL for maintaining the information.
The purpose of the registry is to provide a single source of truth to the program administrators and managers. Program administrators can grant access to other program participants to act on this information.
Individual registrant information is entered in a single row, whereas group details are stored in multiple rows in the form of relationships with the head or representative of the group.
Feature | Functionality |
---|---|
Identification of records | Identification of records in the registry is done with configured ID types. ID can be foundational like MOSIP ID or functional like a voter's card, tax number, driver's license, etc. |
Multiple entries | OpenG2P platform supports multiple entries for a registrant in the registry. The intent is to keep all the entries for a registrant and deduplicate later at the program level, if required. Multiple entries allow program administrators the flexibility to build a registry without bothering about duplicate entries, especially during a crisis such as a flood, earthquake, tsunami, etc., and work on deduplication later using the Deduplication Manager. |
Security | Data at rest is encrypted using robust cryptographic techniques. The data is decrypted in memory while processing the record so that no trace of the unencrypted data is stored anywhere in the system. |
Privacy | Data is anonymized while displayed in human-readable form (for example, UI screen). Similarly, any query results from the registry are anonymized such that this information cannot be used to target an individual. |
The difference between the Beneficiary Registry (BR) and Social Registry (SR) are given below:
Aspect | Beneficiary Registry | Social Registry |
---|---|---|
Data content | Contains data specific to beneficiaries of programs, entitlements and disbursement status | Contains demographic data of individuals and groups not necessarily linked to specific programs. The data may be consumed by several applications |
Data management | Data is accessed and managed by Program Managers | Data is accessed and managed by Administrator responsible for social registry management |
Location | Resides inside PBMS | Independent registry with its own storage and control. See Functional Architecture. |
Source code | https://github.com/OpenG2P/openg2p-registry | https://github.com/OpenG2P/openg2p-social-registry |
Data population | Populated by pulling data from SR | Populated by several means. To learn more, click here. |
Personally Identifiable Information (PII) | Does not contain PII data*. Minimal demographic data (only that is required for eligibility and entitlement) | Contains PII data and other demographic data |
{% hint style="info" %} * It is advised not to populate PII data into the BR. However, the platform does not restrict such a usage. {% endhint %}
TBD
Beneficiary program data can be shared to external systems via APIs.
https://github.com/OpenG2P/openg2p-registry