HISP

1
HISP

• Aims of this lecture
• See the big picture of HISP, all that surrounds
  the software
• Introduction to DHIS

2
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

3
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

4
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

5
HISP is truly global
6
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)

7
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

8
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

9
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

10
Critique of Software development (last years
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

11
Software development today

• South Africa
• Main engine of development of v1.3 and 1.4
• Oslo
• Two PhDs and numerous Masters 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

12
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

13
(No Transcript)
14
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

15
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

16
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

17
Current Scenario, Botswana
IDSR

Notifiable
EPI
Home Based Care
Diseases
Health Statistics
PMTCT
STD
Nutrition
Family Planning
MCH
HIV/AIDS
TB
School Health
Mental Health
And more
District
-
DHT
ARV
IPMS
Facility 1
Facility 2
Facility n
Facility 3
18
Future scenario, Botswana
19
Part IIDHIS and design principles
20
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.

21
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

22
(No Transcript)
23
(No Transcript)
24
(No Transcript)
25
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

26
4. Maintenance

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

27
HISP activities are all about moving people from
providing services, to also using information to
manage services
28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
(No Transcript)
32
Record of patients seen
Summary of key information
Data analysis and use
Data entry into database
33
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

34
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

35
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.
Reporting OrgUnit
36
The Organisational Hierarchy

Parent OrgUnit
Country
Health district


Facility


Parent OrgUnit
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.
Reporting OrgUnit
37
An example of an organisational hierarchy in the
DHIS14
1. Central Ministry
2. Health districts
3. Health facilities
38
(No Transcript)
39
Adding data to the org units

Parent OrgUnits


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


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

40
(No Transcript)
41
Adding data to the org units

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




Parent OrgUnit
Reporting OrgUnit
Semi-permanent data

• Routine data set
• Data element 1
• Data element 2
• Data element n

42
Understanding org units, org unit groups, and
org unit group sets
Org unit 1
Group 1
Group set 1
Org unit 2
Group 2
Org unit 3
Group 3a
Exclusive
Org unit 4
Group 3b
Group set 2
Compulsory
Org unit 5

• An example
• Org unit types
• Location
• Ownership

Org unit 6
Group 3c
43
Understanding org units, org unit groups, and
org unit group sets
Exclusive
Org unit 1
Group 1
Group set 1
Compulsory
Org unit 2
Group 2

• Examples
• Accreditation
• Inclusion in Training programmes
• Inclusion in research projects

Org unit 3
Group 3a
Org unit 4
Group 3b
Group set 2
Org unit 5
Org unit 6
Group 3c
44
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

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

• Routine data set
• Data element 1
• Data element 2
• Data element n

Data element groups
Indicators
46
Understanding the data elements, and data element
groups

• Routine/semi-permanent/survey data sets
• Data element 1
• Data element 2
• Data element n

Raw data
Data element groups
Processed information
Indicators
47
Understanding data elements, and data element
groups
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
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)
Data element
Data element
Data element
People are interested in a grouping in one way or
another this is what we analyse
48
Understanding data elements, and data sets
Data element 1
Data set 1
Data element 2
Data element 3
Data element 4
Data element 5
Data element 6
Data set 2
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)
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.
49
Understanding data elements, and data sets
Data element 1
Data set 1
Data entry form 1
Data element 2
Data element 3
Data element 4
Data element 5
Data element 6
Data set 2
Data entry form 3

• A data entry form can be created to address the
  specific needs of
• A dataset, or
• An org unit.

50
(No Transcript)
51
Understanding data elements, and data sets
Data element 1
Data set 1
Data entry form 1
Org unit 1
Data element 2
Org unit 2
Data element 3
Org unit 3
Data element 4
Org unit 4
Data element 5
Org unit 5
Data element 6
Data set 2
Org unit 6
Data entry form 3
52
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