2 October 2006Johan Sæbø HISP Aims of this lecture –See the big picture of HISP, all that...

2 October 2006 Johan Sæbø

HISP

• Aims of this lecture

– See the big picture of HISP, all that surrounds the software

– Introduction to DHIS


Overview of lecture

• HISP overview– Goals– Activities

• Information systems in the context of developing countries– How data is collected and transformed into

information– Use of information

• DHIS and the key design principles


What is HISP?

• Health Information Systems Programme• Global network of individuals and organisations

– Academic institutions– Non-governmental organisations– Governmental organisations

• Members are orientated towards the “HISP goal”• An example of a South-South-North

collaboration


The HISP goal

• To support local management of health care delivery and information flows

• Design, implement and sustain HIS following a participatory approach

• In health facilities, districts, and provinces

• And its further spread within and across developing countries


HISP is truly global


Achieved through

• HIS design, development and implementation (including, but not limited to software)

• Organisational and human resources development

• Theoretical and practical knowledge about challenges of implementing HIS in developing countries (action research)


Short history

• Started in South Africa after Apartheid

• Software piloted in one province for two years

• Political climate allowed a total renovation of the health system

• Strategy followed a bottom-up development and standardization


Short history

• Mozambique first international node

• India, Malawi, Cuba, Ethiopia, Tanzania, Vietnam, Botswana, Nigeria, Mongolia etc.

• Considerable human capacity on HISP developed in India, Ethiopia, Mozambique

• Different contexts call for different approaches


HISP as a FOSS project• Software (District Health Information Software, DHIS), FOSS

• Emphasis on – Participatory development– Creation of software that empowers the users

• Increasingly open to use of and integration with other FOSS packages

• Distributed development although major work done in South Africa

• Customisation of packages done locally

• Multilanguage enabled software


Critique of Software development (last year’s slide)

• Too focused on SA– In fact too focused on a single individual in SA

• Possibly we have not harnessed opportunities in India strongly enough

• In some countries software development component has not been complemented with a strong enough “project implementation” focus


Software development today

• South Africa– Main engine of development of v1.3 and 1.4

• Oslo– Two PhD’s and numerous Master’s students

developing v.2.0• India

– Many programmers, working with 1.4 and 2.0• Vietnam

– Some programmers, working with 2.0• Various other smaller projects

– Extra modules often made locally


The context of a developing country

• Often severe problems related to:– Infrastructures– Human resources– Inequality (urban/rural)– Hardware and spare parts– Politics– Migration, natural disasters, war etcs– Centralistic, bloated, and fragmented legacy

systems


Health Information use in developing countries

• Curative vs. Preventive approach reflected in information system

• Little use of information at local levels

• Little use of indicators, focus on raw data

• Centralistic approach, data collected for the top level, little or no feedback

• Fragmented, little communication between health managers


Legacy systems

• Hard to change, reflects power relationships

• Donor agencies works around them by making their own systems, just increasing the original problem of fragmentation.

• Developer has left many years ago, took the code with him

• Legacy systems can be a force of resistance against new systems


HISP strategy

• Often beginning with a strong association with grass roots organisations and services

• Focus on piloting and modifying system in a few districts

• Empower local health managers with information and train them how to use it

• Creation of alliances with ministry for recognition of grass-roots progress and further roll-out


Health Statistics

District - DHT

Facility 1 Facility 2 Facility n

IDSR – NotifiableDiseases

PMTCT

EPI

STD

Home Based Care

Nutrition

MCH

Family Planning

HIV/AIDS

TBSchool Health

Mental HealthAnd more …

Facility 3

IPMS

ARV

Current Scenario, Botswana


Health Statistics

Facility 1 Facility 2 Facility n

IDSR – Notifiable

Diseases

PMTCT

EPI

STD

Home Based Care

Nutrition

MASA

MCH

Family Planning

IPT

TBSchool Health

Mental HealthOthers

Facility 3

National HIS

District 1 DHIS District n DHIS

IPMS

District 2 DHIS

Future scenario, Botswana


Part IIDHIS and design principles


Basic Criteria for Health Information Software:

1. Data capture:

• Prevents the capture of duplicate datasets.• Has mechanisms for data validation.• Can be adapted by users to reflect the changing

reality in the health sector– Organisational units– Data elements (and indicators).

• Is able to calculate indicators that use population as a denominator.


2. Reporting functions:

• Reporting must be readily available to provide managers with real time data.

• Can provide automatic reports to various organisational levels.

• Must allow the creation of customised reports• Links to GIS functionality


0

20

40

60

80

100

120C

wel

e

Man

gcw

angu

leni

Mak

hoty

ana

Man

tusi

ni

Nku

man

deni

Pila

ni

Nta

pane

Luda

lasi

Mba

lisw

eni

Ngq

elen

i

Koh

lo

Libo

de C

linic

Qan

du

Ngc

olor

a

Ngc

oya

Bam

bisa

na M

ob

Mam

pond

omis

eni

Bom

vini

Ntib

ane

Maj

ola

Luts

haya

Mgw

enya

ne

Tom

bo

Por

t St J

ohns

CH

C

Old

Bun

ting

Nda

nya

Mal

usi

Isili

mel

a G

atew

ay

Lujiz

wen

i

Can

zibe

Gat

eway

Nka

nunu

Bam

bisa

na P

HC

Nya

nden

i Clin

ic

Bun

tingv

ille

Nol

ita

Mta

mba

lala

Lwan

dile

Nqa

nda

A

St B

arna

bas

Gat

eway

Dou

ble

Fal

ls

Nta

fufu

Nka

nga

Mev

ana

Can

zibe

Cag

uba

National Average 75%

RDS Site Nyandeni sub-district: Percentage Children Fully Immunised under 1 year for 2002

%


0

200

400

600

800N

gcol

ora

Bam

bisa

na M

ob

Dou

ble

Fal

ls

Ntib

ane

Mba

lisw

eni

Nya

nden

i Clin

ic

Nol

ita

Lwan

dile

Mgw

enya

ne

Man

gcw

angu

leni

Mev

ana

Nda

nya

Nqa

nda

A

Maj

ola

Mta

mba

lala

Nku

man

deni

Mam

pond

omis

eni

Koh

lo

Ngq

elen

i

Bun

tingv

ille

Mak

hoty

ana

Mal

usi

Luda

lasi

Isili

mel

a G

atew

ay

Ngc

oya

Nta

pane

Nta

fufu

Nka

nunu

Bom

vini

Qan

du

Pila

ni

Old

Bun

ting

Luts

haya

Lujiz

wen

i

Man

tusi

ni

Libo

de C

linic

Nka

nga

Can

zibe

Gat

eway

Tom

bo

Bam

bisa

na P

HC

St B

arna

bas

Gat

eway

Por

t St J

ohns

CH

C

Nu

mb

ers

Children to be immunised (target)

Children fully immunised under 1 year

RDS Site Nyandeni sub-district: Children fully immunised under 1 year compared to their targets


Qaukeni LSA

Umzimvubu LSA

Nyandeni LSA

Mhlontlo LSA

Umzimkulu LSA

King Dalindyebo LSA

70.2%

32.1%

42.0%

49.3%

43.0%

54.3%

Qaukeni LSA

Nyandeni LSA

Mhlontlo LSA

Umzimkulu LSA

King Dalindyebo LSA

62.9%

42.3%

39.2%

41.5%

36.4%

27.3%Umzimvubu LSA

Immunisation Coverage 2001

Immunisation Coverage 2002


3. Export/Import function:

• Can automatically export data from lower levels for import at higher levels.

• Can specify data export of different groups of data (for onward transmission to various stakeholders – e.g. donors, programme managers, etc).

• Can export data for use with other applications and databases


4. Maintenance:

• Can be locally (in country) supported, adapted, and developed.

• FOSS + Platform independent


HISP activities are all about moving people from providing services, to also using information to manage services


Record of patients seen Summary of key information

Data entry into database

Data analysis and use


DHIS

• Originally developed in Visual Basic for MS Access and Excel

• DHIS 1.4 last version to be tied to MS

• DHIS 2.0 platform independent FLOSS, web-enabled. Same functions as 1.4

• 1.4 still used in most countries, some use of 2.0 in India and Ethiopia


DHIS, the basic structure

• Same principle for all versions of DHIS– Need to reflect the health hierarchy– Need to map data to each reporting unit

– Need to be easy to use– Need to be flexible


“Reporting OrgUnit”

The Organisational Hierarchy

DHIS 1.4 supports an “infinite” number of OrgUnit levels in the hierarchy, but standard setups would be between 3 and 7.

The lowest level is in this case called the “reporting OrgUnit”.


“Parent OrgUnit”

“Reporting OrgUnit”

“Parent OrgUnit” Country

Health district

Facility

The Organisational Hierarchy

Reporting OrgUnits belong to parent OrgUnits, which are either physical health facilities (clinics, hospitals) or administrative OrgUnits arranged in a hierarchical structure. Parent OrgUnits can also be reporting OrgUnits, but the norm is to collect as much data as possible at the lowest level.


An example of an organisational hierarchy in the DHIS14

1. Central Ministry

2. Health districts

3. Health facilities


“Parent OrgUnits”

“Parent OrgUnits”

“Reporting OrgUnit” “Semi-permanent data”

Routine data set (monthly, weekly, quarterly, annually, daily, etc)

•Data element 1

•Data element 2

•Data element n

Adding data to the org units

Data that is collected is “attached” or “linked” to reporting units.




“Reporting OrgUnit” “Semi-permanent data”

Routine data set

•Data element 1

•Data element 2

•Data element n

Data can also be added to higher level OrgUnits (i.e. data can be captured at multiple levels)

Adding data to the org units


Org unit 5

Org unit 4

Org unit 3

Org unit 2

Org unit 6

Org unit 1 Group 1

Group 3c

Group 3b

Group 2

Group set 1

Group set 2

Group 3a Exclusive

Compulsory

An example:

• Org unit types

• Location

• Ownership

Understanding org units, org unit groups, and

org unit group sets


Org unit 5

Org unit 4

Org unit 3

Org unit 2

Org unit 6

Org unit 1 Group 1

Group 3c

Group 3b

Group 2

Group set 1

Group set 2

Group 3a

Exclusive

Compulsory

Examples:

• Accreditation

• Inclusion in Training programmes

• Inclusion in research projects

Understanding org units, org unit groups, and

org unit group sets


Importance of this function

• Health services are often in a state of flux• Hard-coding various types of classification (e.g.

groupings might thus block specific use• Enabling the user to determine these options increases

functionality in an environment that is constantly changing (and with large variations between DHIS-using countries)

• Main purpose of these groupings is to allow analysis to be performed on certain groups

• Limits on groupings in version 1.3 have been a significant impediment, with a lot of tinkering and ad-hoc modifications necessary to make it work


Routine data set

•Data element 1

•Data element 2

•Data element n

Data element groups

Indicators

Understanding data elements, and data element groups(which are also used as indicator groups)


Routine/semi-permanent/survey data sets:

•Data element 1

•Data element 2

•Data element n

Data element groups

Indicators

Raw data

Processed information

Understanding the data elements, and data element groups


Data element

Data element

Data element

Data element

Data element

Data element

Data Element & Indicator Groups are defined in the lookup tables.

The grouped data elements / indicators have some characteristic in common (a data entry form, a programme/service, whether they are gender sensitive or not)

Understanding data elements,

and data element groups

People are interested in a grouping in one way or another – this is what we analyse

Data element

Data element

Data element

Data element

Data element

Data element

Data element

Data element

Data element

Data element

Data element

Data element


Data element 1

Data element 6

Data element 5

Data element 4

Data element 3

Data element 2

Data set 1

Data set 2

The DHIS “back-end” data file uses One table to store all data elements.

Each data element can be assigned to one or more data sets.

Each data set can be used to capture or import data for a number of OrgUnits – but it may not be necessary for all org units to complete all data sets.

Typically, a data set reflect either one paper form, a collection of data that “belong together” (e.g. Census data), or a collection of data elements traditionally updated in a similar manner (e.g. semi-permanent data)

Understanding data elements, and data sets


Data element 1

Data element 6

Data element 5

Data element 4

Data element 3

Data element 2

Data set 1

Data set 2

Data entry form 1

Data entry form 3

A data entry form can be created to address the specific needs of:

•A dataset, or

•An org unit.



Data element 1

Data element 6

Data element 5

Data element 4

Data element 3

Data element 2

Data set 1

Data set 2

Data entry form 1

Org unit 5

Org unit 4

Org unit 3

Org unit 2

Org unit 6

Org unit 1

Data entry form 3



Useful Articles• Braa, J., O. Hanseth, et al. (2005). "Standardisation of Health Information

Systems in Developing Countries - flexible standards the "third way"."• Braa, J. and C. Hedberg (2000). Developing District-based Health Care

Information Systems: The South African Experience. IRIS 23.• Braa, J. and C. Hedberg (2002). "The Struggle for District Based Health

Information Systems in South Africa." 18: 113-127.• Braa, J., E. Monteiro, et al. (2004). "Networks of Action: Sustainable

Health Information Systems Across Developing Countries." MIS Quarterly 28(3): 337-362.

• Wilson, R., C. Hedberg, et al. (2003). South Africa's District Health Information System: Case Study, EQUITY Project: 17.

• HISP Websites (follow links from confluence)• Manual on DHIS 1.4 (early, limited draft only!!)• Manual on DHIS 1.3 (comprehensive but occasionally complicated)• GIS User Manual

2 October 2006Johan Sæbø HISP Aims of this lecture –See the big picture of HISP, all that...

Documents

Transcript of 2 October 2006Johan Sæbø HISP Aims of this lecture –See the big picture of HISP, all that...