35
“Designing” an IHIA Health Information Systems; Integration and Scaling

“Designing” an IHIA Health Information Systems; Integration and Scaling

Embed Size (px)

Citation preview

Page 1: “Designing” an IHIA Health Information Systems; Integration and Scaling

“Designing” an IHIAHealth Information Systems; Integration and Scaling

Page 2: “Designing” an IHIA Health Information Systems; Integration and Scaling

2

– Why IHIA?

– IHIA challenges (fragmentation++)

– three levels of standards

– why is integration important?

– integration strategies; including interoperability

– scaling of IHIA initiatives

Understanding IHIAs

Page 3: “Designing” an IHIA Health Information Systems; Integration and Scaling

IHIA: The motivation

“Global” consensus on the importance of integration

+ HIS means different things to different groups of people

+ Different technologies form parts of the infrastructure used to support various systems

+ Standards allow different systems and supporting infrastructures to “speak to each other”

= Integrated Health Information Architecture (IHIA)

3

“Better information. Better decisions. Better health” - Health Metrics Network (HMN)

Page 4: “Designing” an IHIA Health Information Systems; Integration and Scaling

Conceptualizing Architecture

Architectures are not end-solutions, but approaches to manage complexity (e.g. city planning / regulation)- Tension between short term solution and long term goal

- HIS architectures provide road maps or compass for “good design”

4

Standards? Prerequisite for integration and interoperability. Without shared “understanding” and meaning, no interoperability or integration, be it within social or technical systems!

Page 5: “Designing” an IHIA Health Information Systems; Integration and Scaling

IHIA/HIS: Four Challenges

Fragmentation of data sources– Different sub-systems, owned by different stakeholders

Data-led, not action-led– Focus is on collecting and reporting data, rather than using

if for decision making

Lack of Scaling (and sustainability)– Limited system coverage– Limited uses and users (functionality)

Centralization vs decentralization– Difficult to strike a balance (social & technical)

5

Page 6: “Designing” an IHIA Health Information Systems; Integration and Scaling

An example of fragmentation: Mozambique

6

Page 7: “Designing” an IHIA Health Information Systems; Integration and Scaling

Point of departureFragmented information & Poor data quality

1st step : Integrate data reporting Use existing data in District /National database repository

& Demonstrate integration is possible and useful Revise data reporting forms & structures

2nd Step : “Vertical Integration” Patient record system (OpenMRS) for HIV /AIDS

Export aggregate patient data to DHIS Human resource management (iHRIS)

Export aggregate HR data to DHIS

Another Example: Sierra Leone

Page 8: “Designing” an IHIA Health Information Systems; Integration and Scaling

Point of departure Sierra Leone:Fragmentation of information

National:Fragmented infoDifficult access

District:Fragmented data managementPaper-based transcription and transmissionNot fully disaggregated

Facility:Many reportsLittle feedbackLittle use at facilityNo hospital reports

Census

Surveys

NationalStatisticsOfficeEPI

All programs own systems

HIV RH/FP

Hospital

IDSR

EPIRH/FPHIVIDSR

Directorate ofPlanning & Information

District reports compiled by hand

Outpatient services & morbidity

EPIRH/FPHIVIDSR

HMIS

TB

TB

TB

Outpatient services & morbidity

Page 9: “Designing” an IHIA Health Information Systems; Integration and Scaling

Sierra Leone: 1st step- aggregate data from all programs & services (horizontal integration)

HF1 HF2 HF3 HFn…..

Harmonised paper forms

Health facilities and hospitalsreporting aggregate paper forms toHIS office at district

Nati

onal

Lev

elD

istr

ict L

evel

Faci

lity

Leve

l

HIS officeIntegrated data management

HIS officeIntegrated data entry

Information use

Information use

Information use

Feedback

Feedback

DHIS:District data repository

DHIS:National data repository

Data and tools available to allstaff

Page 10: “Designing” an IHIA Health Information Systems; Integration and Scaling

Sierra Leone: 2nd step Integration & interoperability (vertical)

DHIS

Others

OpenMRS iHRIS<... Integration ...>

Interoperability

Patient records Human Resources

Page 11: “Designing” an IHIA Health Information Systems; Integration and Scaling

IHIAs as social systems

system of systems- IHIA perspective emphasize social context in relation

to technology- multiple rationalities- various human /organizational actors (international

donors, ministry officials, vendors, infrastructure providers) and technologies

- change typically involves redefining power relations (e.g. paper gateways / gate keepers)

11

Page 12: “Designing” an IHIA Health Information Systems; Integration and Scaling

Some social causes of fragmentation

- Statisticians (data people) vs Public health (action people)

- Medical (point of care) vs Public health (aggregate)- Proprietary systems vs Open source- Quick fixes vs Long term Strategy- Isolated systems vs IHIA- Donor Politics vs National Strategy

Page 13: “Designing” an IHIA Health Information Systems; Integration and Scaling

Statisticians vs Public Health

“data represents a public health event”

More is better vs Minimum Data Set & information pyramid

Treatment of outliers

Upward reporting bias (performance)

Page 14: “Designing” an IHIA Health Information Systems; Integration and Scaling

Medical vs public health

Medical focus on patient record systems

Disease based coding & classification – ICD

Isolated (e.g. Excel) systems that do not talk with others

Doctors as informaticians not as users

Systems of limited scale

Page 15: “Designing” an IHIA Health Information Systems; Integration and Scaling

Proprietary vs open source

Proprietary systems may breed corruption

Vendor lock-in & Licensing costs

Short term with respect to system evolution (package)

IT people or finance people in control

Lack of procurement guidelines

BUT even open source initiatives may breed corruption (e.g. training, consultancy)

Page 16: “Designing” an IHIA Health Information Systems; Integration and Scaling

Quick fixes vs long term strategy

Ideal: long term, build local capacity / sustainability / maintainability – linked with education process

BUT

Vendors promise short term utopias

Government officials typically short term – want to be remembered for reforms

Aid projects often short term – pilots

Hardware/software emphasized, not people

Page 17: “Designing” an IHIA Health Information Systems; Integration and Scaling

Isolated systems vs architecture

Isolated systems promoted by many; donors, vendors, health programmes

Funding scheme contribute to fragmentation

Lack of interoperability standards

Architecture thinking is still alien

Many legacy systems (e.g. Norway)

Page 18: “Designing” an IHIA Health Information Systems; Integration and Scaling

Donor politics

How does it play out?- Promoting own systems

- Expatriates/experts

- Influencing government

- Not adopting integrated health

systems framework

HISP/DHIS2 from activists to regulators?

Page 19: “Designing” an IHIA Health Information Systems; Integration and Scaling

IHIA requirements?

Existing work practices as requirements => automating inefficiencies?

Focus on “information use” – information for action

Support information needs across horizontal and vertical dimensions of the IHIA (integration)

Guiding principles

Information available at “one point” (data warehouse)

Lower levels need richer and more granular data

Higher levels need less data; more aggregated

Information for action; essential data and indicators linked to targets and real use

19

Page 20: “Designing” an IHIA Health Information Systems; Integration and Scaling

HIS/HIA: Integration

– Involves data, organizational behavior, workforce, and policies

– Must be sustained over time through routine processes, and is not a one off technical process (institutionalization)

Example (DHIS2)District HIS designed to enable collection, collation, and

analysis of HMIS & disease surveillance data across different subsystems

“The process of making multiple subsystems appear as one single system”

Page 21: “Designing” an IHIA Health Information Systems; Integration and Scaling

Some benefits of integration

Value added to data– New indicators possible– Enables cross-comparison– Ease of access

Cost efficient– Professionalizing information management (e.g. cloud

computing)– Pooling of resources (financial, human)– Economies of scale– Centralized supporting activities (technical maintenance)– Decentralized core activities (public health decision making)

Number of clients per clinical worker per day, by district, 2008 and 2009

0

5

10

15

20

25

Western Area Moyamba Kono Kailahun Bonthe Port Loko Bo Kenema Kambia Koinadugu Bombali Tonkolili Pujehun

Total

PHU (All) Chiefdom (All)

Average of Clients/Clinician/Day

District

Example Integrated Human Resource & Health service data

Page 22: “Designing” an IHIA Health Information Systems; Integration and Scaling

Level 1: InformationNeeds, Users, UsageAcross Organisations

“Social System level”

Level 2: Software applications& Information Systems“Application level”

Level 3: “Data exchange level”“Technical level”

Interoperability & standards, technicalinfrastructure

OpenMRS

DHISPatientrecords

iHRIS

Data warehouseAggregate data

SDMX-HD

Institutional use of information

Applications supporting useof information

Data Standards and infrastructure supporting the applications

Enterprise architecture: 3 Layers

Data & indicator standards

Facility list

SDMX-HD

Page 23: “Designing” an IHIA Health Information Systems; Integration and Scaling

Three levels of HIA (enterprise architecture)

23

Three Levels of the Health Information Architecture

Level 1: Information needs, users and usage:“Business Level/ Social System Level”Level 1 uses services from the level below (level 2)

Information needs and actual usage of information; business processes supported by the HIA. Documented through users specifications and requirements. The defining layer of the architecture!

Level 2: Software applications and information systems:“Application level”Level 2 uses services from the level below (level 3)

Applications and systems responding to the users’ needs, providing the required information and services to the users. Documented through application documentation, manuals, and actual implementations!

Level 3: Data exchange, interoperability and standards:“Technical level”

The technical level of data exchange and interoperability. Data and technical standards for interoperability between systems and applications. Documented as formal standards for data exchange, data dictionaries of data standards and semantics.

Page 24: “Designing” an IHIA Health Information Systems; Integration and Scaling

24

Increasing differences between views

Three Levels of (achieving)Interoperability

--Organisational/ Political /pragmatic

--Semantic

--Syntactic /technical

Compared to a telephone conversation

Shared interests?Interested in talking?

Shared language and shared understanding?

Compatible telephones & networks?

Interoperability and integration require standards

For each level; “solutions” based on solutions at level below, and rely on agreement at level above

SDMX-HD,etc.

Shared / agreed indicators& meta data

Programs / donors /agenciesAgree to standardisation

Unique id.

Standardisation & interoperability may be seen as going on at three levels of increasing complexity

Page 25: “Designing” an IHIA Health Information Systems; Integration and Scaling

HorizontalAcross health programs, Services & agencies ateach level

VerticalLevels of aggregation;From HR /patient records, to national & global reporting (MDG indicators)

DHISOpenHealth

Other data sources –programs

NationalDistrict based

Integrated data repository

CRIS

High Granularity

Low Granularity

iHRIS

DHIS

SDMX-HD

Statistical data“numbers”

HR records“names”

Translation& aggregation

DATADICTIONARY/

CONCEPTREPOSITORY

OpenMRS

DHIS

Exchange standard

Tensions between Standards and Local Flexibility => Essential Data Set

Page 26: “Designing” an IHIA Health Information Systems; Integration and Scaling

Organisational /political level of integration

(information needs & usage)

Horizontal integration: Information from across sectors & health programs available at “one point”

Vertical Integration: “Seamless” flow of information from peripheral to central levels, from patient encounters in clinics to national M&E

Software applications& Information Systems

Horizontal integration: Data warehouse, such as DHIS, integrating & managing data from different health programs and sectors

Vertical Integration: Extracting aggregate data from Human Resource system, and patient record systems into one data warehouse (e.g. DHIS2)

Data exchange, interoperability &

standardisation

Horizontal integration: Shared data & indicator standards prerequisite for sharing data across health programs & sectors, whether from paper or computer sources. SDMX-HD data exchange format enable transfer of indicator definitions and data

Vertical Integration: Shared data standards also prerequisite for aggregating from individual human resource records in iHRIS to data according to standard loaded in DHIS using SDMX-HD

Page 27: “Designing” an IHIA Health Information Systems; Integration and Scaling

The application level of IHIA

27

Page 28: “Designing” an IHIA Health Information Systems; Integration and Scaling

Data Interoperability

Data Interoperability / syntactic/ technical– Essential component to achieve integration– Interoperability; standardized data definitions for data

exchange among sub systems

Example– Shared data definitions among data collections tools (paper

or software) across different subsystems, and standards for exchanging these data (e.g. XML)

Page 29: “Designing” an IHIA Health Information Systems; Integration and Scaling

Standards to facilitate interoperability

Data standards:– Definitions and rules of use for data– Example: ”infant mortality rate” is an internationally agreed

indicator, with a clear definition

Data exchange standars:– For enabling software to process electronically sent

information– Example: HL7, SDMX-HD

29

Page 30: “Designing” an IHIA Health Information Systems; Integration and Scaling

Strategies for scaling of IHIAs

Technical system, quantitative dimension:

Components of the IHIA

Social system, qualitative dimension:

Cultivation approaches

30

Page 31: “Designing” an IHIA Health Information Systems; Integration and Scaling

IHIA Scaling: Technical perspective

Data warehouse for aggregate data- manage the data- integrate the various datasets and sub-systems - Interoperability and data exchange through standards- gateways between data warehouse and sources of data (paper, computer).

The data warehouse needs to be flexible- Integrate and manage data sets as they are emerging, changing and

developing- Present and make data available according to domain knowledge and

"business intelligence", as user needs are developing and emerging

31

Shared data standards and indicators, are the primary building block of the IHIA

Page 32: “Designing” an IHIA Health Information Systems; Integration and Scaling

IHIA Scaling: Social Perspective

User participation; to get users’ at all levels committed, and foster learning and a sense of ownership to information and system

Scale the architecture gradually along the vertical and horizontal axes, depending on users’, and institutional readiness and learning

Focus on solving specific large problems shared by many

Flexibility; data standards, data warehouse and means of data exchange need to be flexible; to enable change according to redefinition of needs, infrastructure and overall context

32

Page 33: “Designing” an IHIA Health Information Systems; Integration and Scaling

Five (uneven) processes of change From paper to computer

From stand-alone to networked computers

From paper records to electronic patient records

From paper to mobile phone

From offline to online (web-based HMIS)

33

Scaling in uneven contexts:

Do we need to cover all forms? (deepen)

Do we need to cover all reproting units? (widen)

If not, useless?

Page 34: “Designing” an IHIA Health Information Systems; Integration and Scaling

Centralization, decentralization and hybrid models

Centralization versus decentralization is a historical challenge in IS/HIS design

Dimensions involved here are– Who makes decisions?– Who controls budget?– Where does the data reside? (political/technical/managerial)– Does implementation start at top, or bottom, or a hybrid?

These questions have implications on:– User involvement (not always empowering)– Sustainability of systems– Scalability of systems– Use of information for decision making

Page 35: “Designing” an IHIA Health Information Systems; Integration and Scaling

Discussion topic: HISs/IHIAs as socio-technical systems1. Form groups

2. Discuss the following proposition in your group”HISs/IHIAs can not be built from scratch, but evolve as socio-technical

systems. The introduction of new (HMIS) routines, new technology etc. takes place in a highly complex and embedded setting, and will be shaped by this”

In relation to the proposition consider:- Data / information flow & transparency - Data ownership- HIS Funding/financing- Health Data regulations & policy- Top-Down vs Bottom-up IHIA restructuring

35