2. definitions and approaches to...

| 7Integrating data and information management for social protection: social registries and integrated beneficiary registries

2. DEFINITIONS AND APPROACHES TO INTEGRATION

2.1 Background to this study: confusion in the terminology

Despite growing recognition that integrated data and information management plays a pivotal role in social

protection, terminology used by individual countries and in the theoretical and grey literature9 is confused. The

tendency is to:

» use the same terminology when referring to systems that are radically different in objective (see Section 1.2); in

focus; in functionality; in overall levels of complexity, maturity and sophistication; and in the hardware and

software used. For example:

– ‘MIS’ is used for systems that integrate data across several programs, as well as for systems for individual

programs

– ‘single registry’ is used for systems that integrate registration and eligibility determination and not much

else (Brazil’s Cadastro Único), as well as systems that consolidate data across existing programs to ensure

M&E and integrated delivery without offering integrated eligibility determination (Kenya’s Single Registry)

» use different terminology (e.g. poverty database, single registry, unified database) when referring to systems

that are overall quite similar.10 This is especially the case as almost each individual country has a different

name for its system (see section 3).

This study shows that what matters is not the name that a country calls its system, but what the system is set up

to do: most importantly where the data is flowing from (e.g. where is it originally being collected and what other

data sources is it drawing from) and to (e.g. who has access to the data and how).

While there is significant literature and agreement on the ideal set-up of program-level solutions (Grosh et

al. 2008; Chirchir and Kidd 2011), there is still scarce systematic evidence on integrated systems for data and

information management operating across different social protection programs and sectors.

There are two main reasons for this confusion, which are the consequence of historical evolution of the

terminology used in this field.

» First, the terms ‘database, ‘registry’ and ‘MIS’ are often used interchangeably by social protection

practitioners. However, these have different meanings and functions (see Section 2.2).

» Second, in the social protection field, the term ‘MIS’ has become synonymous with program-level solutions

(e.g. a cash transfer ‘program MIS’), while the words ‘registry’ and ‘database’ are increasingly used for

integrated solutions (e.g. ‘single registry’, ‘social registry’, ‘unified database’, ‘poverty database’). However,

this is a misrepresentation (see Section 2.2).

Specifically, the term ‘single registry’ has gradually become the main term used by policymakers and practitioners

to describe integrated approaches to data and information management in the social protection sector. This term

is misleading, as Box 2 explains, and a challenge of this paper is to unpack its meaning in different contexts.

9 Literature describing individual country experience with integrating social protection information.

10 For example, Samson’s seminal manual on designing and implementing social transfer programs (2006) points to the advantages of a ‘single national registry’ such as Brazil’s Cadastro Único without questioning whether it is really single (it is not in the strict sense of the term, as it is not the only registry in Brazil) or which objectives such a registry can achieve. Castaneda and Lindert (2005) talk about a ‘unified household information registry’ (or ‘cadastre’), which includes all interviewed households. However, the word ‘unified’ can be misleading in this context: what is being unified and what is not? Villalobos, Blanco and Bassett (2010) discuss the benefits of ‘sophisticated MISs’ that can ‘integrate the management of social protection systems’, while Azevedo, Buillon and Irarrázaval (2011) — in the most comprehensive publication on the topic available in Spanish – talk about ‘integrated systems for social information’ (sistemas integrados de información social).

8 | Integrating data and information management for social protection: social registries and integrated beneficiary registries

Box 2: ‘Single registry’ — why is the term misleading?

Countries’ approaches to integrated data and information management in the social protection sector have

often been referred to as ‘single registries’ — including in the previous version of this report. This report

explicitly choose to avoid the use of this terminology. Why?

» It was born as a literal translation of Brazil’s ‘Cadastro Único’. In recent years Cadastro Único is no longer

translated as ‘Single Registry’ but as ‘Unified Registry’.

» It has been used to refer to very different approaches to integration in different countries, so it does not

ensure clarity. For example, Kenya’s solution is called the Single Registry but has a different set-up and

functionality than Brazil’s Cadastro Único (see Annex 1, Case studies).

» Key stakeholders (World Bank, ILO etc.) are rapidly moving away from the term, though it has stuck in

describing country solutions to integration (e.g. Kenya).

» ‘Single registries’ are not necessarily single since they often do not comprehend all social protection

programs in a country and are not a substitute for individual MISs.

» ‘Single registries’ do not necessarily entail a single process for targeting or unifying operations across

programs.

» The word ‘registry’ alone does not cover the full functionality of data and information management in the

social protection sector.

2.2 Defining the underlying terminology for the study: components of a social protection information system

This report starts by defining a social protection information system11 — the broader system that enables the

flow and management of information within the social protection sector, and sometimes beyond to other

sectors. This is the focus of this paper, and the area of greatest confusion in the literature, primarily because such

a system can be achieved and operationalised in different ways, influenced by the main objectives pursued with

integration (see Section 1.2) and by a country’s context and trajectory.

The overarching social protection information system will encompass (see Box 3 for full definitions):

» a data repository, such as a registry/database for storing and retrieving data. See Section 2.3

» a software application that helps manage, link and process the data, transforming data into information and

analysing/using the information (at program level these are referred to as management information systems,

MISs). See Section 2.5.

It will also be sustained by a set of procedures for data sharing, most often using information and

communications technology (ICT) (see Section 4.3.4) and will ultimately be managed by qualified staff (see

Section 4.1.3).

11 This terminology is preferred as it ensures clarity and consistency with IT parlance. Another potential choice and effective synonym is ‘integrated system for social protection information management’.

https://www.wwp.org.br/en/unified-registry-0


Box 3: Key definitions

» Social protection information system12 — the broader system that enables the flow and management of

information within the social protection sector, and sometimes beyond to other sectors

» Database — a system to organise, store and retrieve large amounts of data easily

» Registry (a term of pre-ICT origin) — an official written record of names, events and/or transactions

– In a computerised environment, ‘databases’ and ‘registries’ are overlapping concepts (effectively

synonyms); both are for storing and retrieving data and therefore act as ‘data repositories’ When

discussing integrated data repositories we retain the word ‘registry’ as this is most commonly used.

» MIS13 — a system that transforms retrieved data from a program’s database/register (or, in some cases,

different databases linked to different modules) into information that can be used for efficient and

effective program management.

– In social protection literature, the term MIS is associated with program-level information management.

When discussing integrated solutions we use the generic term ‘application software’, referring to

the tailored solution that allows for the input, processing and output (e.g. display/presentation) of

information. In the literature this is sometimes referred to as ‘integrated MIS’.

The way in which these building blocks are operationalised in country will influence the system’s overall

functionality, level of dynamism and level of integration, ultimately affecting the extent to which the benefits of

integration discussed in Section 1.1 can be achieved in practice. Table 2 provides a few examples — which should

be kept in mind throughout this report — in Table 2 below.1213

Table 2 How variations in operationalisation can affect outcomes

Variations in operationalisation that will affect outcomes (examples) See section(s)

Registry/ database

What percentage of population is in the registry 2.4, 3.1, 4.2.1, 4.2.7

Whose data is in the registry (e.g. beneficiary vs potentially eligible) 4.2.1

What data is being collected and stored (e.g. what variables) 4.2.1

How data is being collected 4.2.1

How data is being updated 4.2.2

What data sources are being used and how 2.5, 4.2.1

Application software (and procedures for data sharing)

How data is being managed and used 2.5, 4.2.3, 4.2.4, 4.2.5, 4.2.6

Whether data exchange is real time or not 2.5, 4.3.4

Opportunities for data access at decentralised level and for external stakeholders (accessibility)

4.1.1,4.1.2, 4.3.4

Level of security / data privacy guaranteed 4.3.1

12 See footnote 11.

13 This term has been borrowed from the business world, where it is defined as a ‘system that provides information that organisations require to manage themselves efficiently and effectively’.


In practice, there are two main approaches for setting up an integrated data repository (registry) for the social

protection sector — namely integrated beneficiary registries and social registries, as explained in Section 2.3.

These are compared and contrasted in Section 2.4. Section 2.5 then explains the complementary and essential

role of the tailored software application.

2.3 Two main approaches to setting up a social protection data repository

2.3.1 Integrated beneficiary registries

Integrated beneficiary registries14 integrate data from program MISs of several different schemes (see Figure 1). In

practice, they provide a consolidated overview of data collected by different programs, focusing on beneficiaries

alone (no information on potential beneficiaries is recorded15). This approach is mainly adopted where the

main objective of integration is to provide coordination and oversight. It can also be used to integrate selected

operations and services (see for example Section 1.2.1).

While this is a low-cost approach that allows building on existing systems, it is important to note that the quality

of the consolidated data is only as good as the data collected and processed by the programs (each of which will

have its own process for registration, eligibility determination and updating). Moreover, because of their focus

on existing beneficiaries, integrated beneficiary registries cannot be used for the determination of potential

eligibility for programs.

The best example of such a registry is Kenya’s Single Registry,16 which acts as a data warehouse across the

country’s five main social protection programs, as discussed in Annex 1, Case study 4.

Importantly, integrated beneficiary registries are building blocks that help achieve integration. Their full potential

as ‘information systems’ is only unleashed when they are used together with a software application that links

them dynamically to other databases, systematically transforms data into information, and analyses and uses the

information. This is discussed in Section 2.5.

14 This is in line with recent practice within the World Bank’s Social Protection and Labour Delivery Systems Group. The author thanks the group, and in particular Kathy Lindert, for inputs into this report update. In the previous version of this report, this was called a ‘consolidated model’ (Barca and Chirchir, 2014). Other terminology used to discuss such models includes ‘central beneficiary database’ and ‘common beneficiary system’.

15 When consolidating data from several existing programs, data on non-beneficiaries could also be consolidated. However, to date this has never been the case in countries following this approach to integration.

16 Single Registry is the official name.


Box 4: Integrated beneficiary registry — what it is and is not

What it is

» It is a registry of beneficiaries across several programs

» It integrates data from the MISs of several programs, adopting a ‘service integration’ approach

» It supports integrated M&E and planning, and can be designed to support integration of delivery systems

(e.g. payments and grievances)

» It is a building block that helps achieve integration. Its full potential as an ‘information system’ is only

unleashed when it is used together with a software application that enables dynamic links to other

databases, systematically transforms data into information, and analyses and uses the information (see

Section 2.5)

What it is not17

» It is not necessarily comprehensive (i.e. ensuring 100 per cent coverage of population) as it only includes

existing program beneficiaries18

» It cannot be used for ‘targeting’ or determination of (potential) eligibility for programs, because it only

contains information on people or households who have already been deemed eligible by existing

programs (beneficiaries and not potential beneficiaries)

» It does not necessarily include data from all social assistance programs in a country (some programs may

not have been integrated)

» It does not necessarily include data from social insurance beneficiaries (as this data may not have been

linked)

» It is not necessarily highly integrated with other government databases (e.g. civil registry, tax authority)

» It is not necessarily a substitute for individual program databases and MISs (unless specifically designed to

do so, it cannot support program-specific delivery systems)

» It is not necessarily ‘national’, since social protection programs (and data collected for registration) are

sometimes targeted geographically

2.3.2 Social registries1718

Social registries are databases of potential beneficiaries of social assistance. They differ from integrated

beneficiary registries by centralising data integration up front and collecting data for a national database/

register that is then drawn upon by specific programs19 (see Figure 1). Their primary function is to support and

consolidate the initial social protection implementation phases of intake and registration. They can also support

the assessment of needs and conditions for the purposes of determining potential eligibility for enrolment in

selected social programs (see Section 1.2.2).

In some cases, and especially at their initial stages of development, social registries simply ‘piggyback’ on the data

collection effort of the country’s flagship social protection program database, rather than start from scratch. This

was the case for Bolsa Familia in Brazil.20

17 In all the statements below the terms ‘not necessarily’ mean this can be achieved if explicitly pursued.

18 It could be if 100 per cent of the population were beneficiaries (e.g. universal guaranteed minimum income).

19 In Barca and Chirchir 2014 this was discussed this in Section 2.3.2 as the ‘centralised model’.

20 In Barca and Chirchir 2014 this was discussed in Section 2.3.2 as the ‘program-centred model.’


Like integrated beneficiary registries, social registries are a building block that helps achieve integration. Their full

potential as information systems is only unleashed when they are used together with a software application that

links them dynamically to other databases (ideally enabling a two-way data flow with program MISs), systematically

transforms data into information, and analyses and uses the information (see Section 2.5).

Two of the most famous social registries worldwide are Brazil’s Cadastro Único (see Annex1, Case study1) and

Indonesia’s Unified Database (see Annex1, Case study3). Box 5 further clarifies what a social registry, in its most

basic formulation, is and is not. More useful information can be found in sections 3 and 4, while below also

describes an advanced technical approach to developing a social registry, namely ‘virtual social registries’.21

Box 5: Social registry — what it is and is not

What it is

» It is a registry/database of all people and households registered (the percentage of population registered

will depend on the data collection approach and the user program needs)

» Its primary function is to consolidate and support the initial implementation phases of intake and

registration. It assesses needs and conditions for the purposes of determining potential eligibility for

enrolment in selected social programs (‘targeting’)

» It aims to collect, record and store updated and historical information on individual and household

characteristics and circumstances, and verifies and checks information consistency

» It adopts a ‘data integration’ approach (through a shared master data system)

» It is a building block that helps achieve integration. Its full potential as an ‘information system’ is only

unleashed when it is used together with a software application that enables dynamic links to other

databases, systematically transforms data into information, and analyses and uses the information (see

Section 2.5)

What it is not21

» It is not necessarily comprehensive (i.e. ensuring 100 per cent coverage of population) unless a national

census survey is conducted covering the whole population

» It is not just a list of beneficiaries (eligible people who have been selected for social protection programs)

— i.e. it includes data on potential eligible households too

» It does not necessarily enable an integrated overview of who is receiving what across different programs,

as the main data flow is from the social registry to program MISs, not back again

» It does not necessarily provide data for all social assistance programs in a country (some programs may

retain their own registration and data collection)

» It is not necessarily highly integrated with other government databases (e.g. civil registry, tax authority)

» It does not necessarily offer a current snapshot of poverty, unless data is kept sufficiently up to date

» It does not necessarily entail integrating operations across programs and is not a substitute for individual

program registries and MISs

» It is not necessarily ‘national’ since social protection programs (and therefore data collected by the social

registry) are sometimes targeted geographically

21 In all the statements below the terms ‘not necessarily’ mean that this can be achieved if explicitly pursued.


‘Virtual’ social registries

One technical approach to developing a social registry is to source data by making existing government databases

interoperable — i.e. ensuring that they can ‘talk to each other’ (share data) effectively (see also Section 2.5).

This is defined here as a ‘virtual’ social registry.22 This approach can be used by countries that have strong civil

registry/ID systems and a favourable e-governance context and wish to have a comprehensive (100 per cent of

population), cross-sector and proactive (linked to life-cycle events) overview of their population.

The amount of information consolidated based on this virtual integration is sufficient to determine eligibility for

universal social assistance programs,23 as for Argentina’s child allowance and Thailand’s health insurance beneficiary

registry schemes (see Box 6), but not for poverty-targeted programs. When this is the case, information from several

sources is consolidated and further data is then collected in order to determine (targeted) eligibility for social

programs (which requires additional information that is often not available from existing databases) — as discussed

in Section 4.2.1. For example, this is the case with Chile’s Registro Social de Hogares (see Annex 1, Case study 2) and

with Turkey’s Integrated Social Assistance Information System (see Annex 1, Case study 5).24

Box 6: Thailand’s national health insurance registry

Built on a partnership between Thailand’s Ministry of Interior and social health protection schemes, the

country’s national health insurance beneficiary registry facilitates access to health care for all.

Launched in 2001, the Universal Coverage Scheme (UCS) covers the 76 per cent of the population who are not covered by existing social health protection schemes. UCS beneficiaries are identified by extracting data from the national population database maintained by the Ministry of Interior and — using the country’s 13-digit national ID number25 as a unique ID (see also Section 4.2.4) — removing individuals who already benefit from other schemes. No additional data collection is required. The National Health Security Office — an autonomous institution — was created and designated to compile and maintain the resulting registry.

Beyond helping to verify eligibility, the national ID number is also used by health-care providers to track

delivered services, settle claims, and build a shared medical record for each patient.

Source: ILO (2015c).26

2.4 Comparing approaches2526

2.4.1 Evolving nature and differing operationalisation

Importantly, these approaches to setting up a data repository for the social protection sector are not static over

time and evolve as capacity, technology, and the broader governance environment matures. This complicates the

classification of country experiences. For example, a country consolidating information from existing programs into an

integrated beneficiary registry may decide to coordinate data collection activities to create a national social registry.

This social registry may then increase its level of interoperability with other government databases (see also Section

2.5) and take on features of a virtual social registry, as has been the case in Chile (see Annex 1, Case study 2).

22 Others have defined these as ‘federated databases’ or ‘co-databases’. Barca and Chirchir 2014 called this a ‘virtual consolidated model’.

23 Universal programs are those that target anybody within a given demographic category (e.g. old age social pensions). These require less information as they do not require data for poverty targeting.

24 It is important to note that in Turkey’s system the name itself reveals the importance of the software application component (it is primarily an information system, not a ‘registry’).

25 This unique 13-digit identification number is generated for each Thai citizen when their birth is registered in the national civil registration database. National ID cards are issued to citizens when they reach seven years of age. Non-Thai residents and foreigners can be issued with ad hoc ID numbers.

26 Available at socialprotection.org


Similarly, no two registries developed by different countries adopting the same approach (e.g. social

registry) are the same and offer the same level of functionality. This is because of the endless design and

implementation variations possible when operationalising a system that affects ultimate functionality. Table 2

provides a good overview.

The basic set-ups for developing integrated beneficiary registries, social registries and virtual social registries are

represented visually in Figure 1. These do not encompass any focus on potential wider interoperability managed

through the registries’ tailored software application, further discussed in Section 2.5: they simply focus on where

the data for the registry is being primarily sourced.

Figure 1 Visualising different approaches to data integration

Program 1MIS

ELIGIBILITY

ELIGIBILITYProgram 3MIS

VIRTUAL SOCIAL

REGISTRY

ADMINISTRATIVEDATABASE 1 MIS

MIS

MIS

ADMINISTRATIVEDATABASE 3

NATIONAL IDDATABASE

Possibledata

collection

Datacollection

INTEGRATED BENEFICIARY REGISTRY

‘VIRTUAL’ SOCIAL REGISTRY

SOCIAL REGISTRY

Program 1MIS

Program 3MIS

Program 1MIS

Program 3MIS

SOCIALREGISTRY

SOFTWAREAPPLICATION

ELIGIBILITY

Program 2MIS

INTEGRATEDBENEFICIARY

REGISTRY

SOFTWAREAPPLICATION

ELIGIBILITYProgram 2MIS

Program 2MIS

SOFTWAREAPPLICATION

ADMINISTRATIVEDATABASE 2 MIS

Source: Developed by the author.

Note: Boxes indicate databases; circles indicate MIS. All arrows have been portrayed as one-directional here (one-way data flow), though this is not necessarily the case. The transparent arrows behind each figure represent the direction in which it should be read.

2.4.2 Types of integration enabled

Social registries and integrated beneficiary registries are further classified in Table 3 based on the types of

integration enabled by each in their most basic form (see also sections 1.2 and 2.5). It is clear from the table that:

» integrated beneficiary registries enable integrated M&E and potentially integration of operations and services

across programs

» social registries enable an integrated process for registration and eligibility determination across programs

» virtual social registries can support registration and eligibility determination for universal programs.

The extent to which other benefits are reaped depends on the external links established through the tailored

software applications (see Section 2.5).


Table 3 What type of integration can be achieved? Comparing social registries and integrated beneficiary registries

Integrated beneficiary registries Social registries

M&E and overview of beneficiaries across programs

Yes Only if registry receives data from program MISs (often not the case)

Integrated process for eligibility determination across programs

No (eligibility is determined at program level, then integrated)

Yes

Integrating operations and services across programs

Yes (if pursued as policy objective) Only if registry receives data from program MISs

Integrating policy across social protection sector

Only if registry is linked to all social assistance programs and social insurance etc.

Only if registry is linked to all social assistance programs and social insurance etc.

Integration with other sector MISs Only if application software enables this

Only if application software enables this

2.4.3 How country context and needs affect choices

Ultimately, a country’s solution for integration must be strongly linked to the country context and overall

objectives of the system (see Section 1.2), and is not therefore set in stone. It does not matter whether the

system is initially set up as an integrated beneficiary registry, social registry or virtual social registry — what

matters is that the approach chosen responds to a country’s needs, is appropriate to its context and is affordable

and sustainable. Overarching considerations are presented in Table 4 below.

Table 4 How context and needs affect choices

Approach When most suited

Integrated beneficiary registry

» Policy objective is M&E / overview of beneficiaries, planning and integrating operations and services across programs

» Existing program MISs are high quality

» Existing programs have reliable/strong approaches to registration, eligibility determination and enrolment (and re-registration)

Social registry » High capacity and commitment at central level

» Policy objective is integrating the process for intake/registration (and sometimes poverty/eligibility assessment) across programs

» Resources and capacity are available for frequent national census survey registration (e.g. every two years) or on-demand registration, or a combination

Virtual social registry

» High capacity and commitment at central level

» Policy objectives include integrating the process for intake/registration across programs

» Evolved e-government and buy-in from other ministries and stakeholders

» Web service access is ensured (broadband network, data standards etc.)

» National ID system has extremely high coverage


2.4.4 How different solutions compare to a country’s total and ‘eligible’ population

To better understand the relationship between social registries, integrated beneficiary registries and the wider

population (which can be potentially reached by virtual social registries), see Figure 2 below. In Figure 2:

» The widest green circle is a country’s whole population (rich and poor).

» The next rust circle is the population included in a country’s social registry. This is 100 per cent of the total

population in a few cases (rust and green circles overlap) — notably where comprehensive census surveys are

completed — but most often focuses on the sub-population of those who are potentially eligible for social

assistance programs (e.g. relatively poorer). See Section 3.1.

» The smallest blue circle represents the population included in a country’s integrated beneficiary registry: the

sum of all the beneficiaries of the social protection programs whose MISs have been integrated. This could

be 100 per cent of the population if all citizens were beneficiaries of one program or another, but this is very

rarely the case.

» The grey dotted circle represents a country’s eligible population (those who are entitled to receive some

form of social assistance benefit based on the targeting criteria of any of the existing programs).27 The area

that does not overlap with the green or the blue line represents households who should be included but

are not (exclusion errors). The area within the blue circle that does not overlap with the grey one represents

households who are included in the social registry but not eligible based on existing eligibility criteria (they

could be if these changed). All beneficiary households (green circle) are eligible (unless there are inclusion

errors, not figured here).

Figure 2 How different solutions compare to a country’s total and ‘eligible’ population

SOCIALREGISTRY

ELIGIBLEPOPULATION

(EG ‘POOR, AGE 65+ ETC)

COUNTRY’SPOPULATION

INTEGRATEDBENEFICIARY

REGISTRY


27 In cases of universal coverage, this grey dotted line would correspond to the outer green circle.


2.5 Unpacking the role of the software application

Sections 2.3 and 2.4 mainly focus on the role of the social protection data repository: the registry/database.

However no matter what approach is adopted for developing that data repository, its full potential as an

information system is only unleashed when it is used together with a software application that links it dynamically

to other databases, systematically transforms data into information, and analyses and uses the information.

2.5.1 Dynamic link to other databases

A system that guarantees full integration within the social protection sector and beyond, in accordance with the

right to privacy, would establish a direct and two-way link28 (web service — see Section 4.3.4) to:

» all social assistance program MISs and related databases — to keep track of who is receiving what, potentially

integrate selected services, and enable adequate M&E and planning

» social insurance MISs and related databases — to integrate social assistance and social insurance and ensure a

life-cycle and comprehensive approach to social protection

» any other relevant government MISs and related databases (e.g. civil registry, tax authority) — to collect and

cross-check data, enhance accountability, and enable a comprehensive approach to social policy planning.

This can only be achieved through a purpose-designed application software, ideally using each citizen’s national

ID number as a unique identifier (see Section 3.2.4 for more details and critique), allowing for instant access to up-

to-date data, with information flowing in both directions — conditional on the permission level of each user. The

overall solution would look something like Figure 3 below.

As an example, Table 5 focusses on social registries (see Section 2.2), to discuss the relative advantages of

enabling a data flow from and to a social registry for selected stakeholders.

Table 5 Advantages of data flow from/to the social registry for selected stakeholders

Stakeholder Advantages of data flow from social registry to (…)

Advantages of data flow to social registry from (…)

National social protection programs

» Programs can use data from the registry (and potentially national poverty index) to select their beneficiaries

» Programs can benefit from further data integration established at national level (e.g. verifying data with civil registry)

» Programs can be given access to integrated M&E information

» Potential for integrating services across programs

» Registry continuously updated

» Being able to keep track of who receives what

» Integrated M&E across programs

» Potential for integrating services across programs

Civil registry and/or national ID number (see also Section 4.2.4)

» Data collection effort for registry could help identify and register unregistered individuals

» National ID number acts as unique identifier and enables instant linkage with other government databases

» Civil registry or National ID data can be used as an information base on all citizens (e.g. name, address), including notification of births and deaths

» Authentication of registry data

28 In Section 2.3.2 discusses how virtual social registries source their data from existing administrative databases. This section discusses linkages beyond the simple sourcing of data to be used for targeting purposes (two-way flows; use of data for validation, accountability and planning).


Stakeholder Advantages of data flow from social registry to (…)

Advantages of data flow to social registry from (…)

Bank or other payment institution

» Potential for coordinating payments across different programs (economies of scale)

» Payment authentication and reconciliation across programs

Tax authority » Tax authority could benefit from better understanding of poverty and social protection receipt

» Tax data can be cross-checked (e.g. to aid eligibility decisions and prevent fraud)

Social security database

» Better integration, coordination and planning across social protection and social insurance

» Development of complementary packages targeted at social protection beneficiaries (primarily health Insurance)

» Social security data can be cross-checked (e.g. employment status and social insurance receipt to aid eligibility decisions and prevent fraud)

» Better integration, coordination and planning across social protection and social insurance

Health and education ministry MISs

» Data from the registry can be used for sectorial anti-poverty policies

» Better integration, coordination and planning across social sectors

» Integrated M&E across social protection and other sectorial programs (e.g. health insurance)

» Health/education data could be used as information base for registry (education status, health status etc.)

» Monitoring of compliance to co-responsibilities/conditionality (if any)

» Better integration, coordination and planning across social sectors

Other state institutions

» Improved transparency and accountability (e.g. monitoring government projects, open data platforms)

» Planning, coordination and mainstreaming of poverty eradication strategies

» Data can be used as information base for registry (e.g. land registry)

Decentralised governments

» Data from the registry can be used for local anti-poverty programs

» Local governments can be actively involved in management of social protection

» Cross-checks and eligibility assessments

» Better planning, coordination and implementation of social protection programs


In reality, of course, in many countries these linkages do not exist in practice or are not developed to their

full potential. This is not a problem; the ultimate set-up will depend on a country’s objectives, related needs

and context. In fact, higher levels of integration and interoperability increase the risks associated with misuse

and misappropriation (see Section 1.1) — which is the reason why many high-income countries have explicitly

legislated against this (e.g. the United Kingdom). For example, data flows will often:

» not be bi-directional, but only one way. This is represented in Annex 1 with uni-directional arrows

» not be set up through a web service, but established on an ad hoc basis (sent in batches using CDs, email etc.).

This is represented in Annex 1 with dotted arrows (see Section 4.3.4).

» be very limited, e.g. linking to the programs they are serving and not far beyond.


Figure 3 Full integration of data and information management

BANK

DATABASE

Either operationalised as IntegratedBeneficiary Registry or Social Registry

+ application software

CIVIL REGISTRY

SOCIAL SECURITY

MIS

OTHER STATE

INSTITUTIONS

LOCAL GOVERNMENTS

MIS

DATABASES

DATABASES

DATABASES

OTHER NATIONAL & LOCAL MIS

Program 1 database Program 2 database Other program databases

TAXAUTHORITY

MIS

DATABASE

BANKMIS

BANKDATABASE

MIS MIS

SOCIAL PROTECTIONINFORMATION SYSTEM


Note: Boxes indicate databases; circles indicate MISs; bold lines indicate direct link (e.g. web service access); dotted lines indicate indirect link (batch process, CDs etc.); arrows indicate where information flows in one direction or two directions.

2. definitions and approaches to...

Documents