Designing an IHIA Health Information Systems Integration and

  • Slides: 18
Download presentation
“Designing” an IHIA Health Information Systems; Integration and Interoperability

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

Conceptualizing Architectures are not end-solutions, but approaches to manage complexity (e. g. city planning

Conceptualizing 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” Standards Prerequisite for integration and interoperability. Without shared “understanding” and meaning, no interoperability or integration 3

IHIA/HIS: Three Challenges Fragmentation of data sources – Different sub-systems, owned by different stakeholders

IHIA/HIS: Three 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 Centralization vs decentralization – Difficult to strike a balance (social & technical) 4

An example of fragmentation: Mozambique 5

An example of fragmentation: Mozambique 5

Some social causes of fragmentation - Statisticians/managers (data people) vs health workers (action people)

Some social causes of fragmentation - Statisticians/managers (data people) vs health workers (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

Statisticians vs Public Health “data represents an event” More is better vs Minimum Data

Statisticians vs Public Health “data represents an event” More is better vs Minimum Data Set & information pyramid Treatment of outliers Upward reporting bias (performance)

Medical vs public health Medical focus on patient record systems Disease based coding &

Medical vs public health Medical focus on patient record systems Disease based coding & classification – ICD 10 Isolated (e. g. Excel) systems that do not talk with others Doctors as informaticians not as users Systems of limited scope and scale

Quick fixes vs long term strategy Ideal: long term, build local capacity / sustainability

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 and knowledge

Donor politics vs national HMIS restructuring - Donors promoting own systems Expatriates/experts Not adopting

Donor politics vs national HMIS restructuring - Donors promoting own systems Expatriates/experts Not adopting integrated health systems framework HISP/DHIS 2 from activists to regulators?

HIS/HIA: Integration “The process of making multiple subsystems appear as one single system” –

HIS/HIA: Integration “The process of making multiple subsystems appear as one single system” – Involves data, organizational behavior, workforce, and policies – Must be sustained over time through routine processes, and is not a one off technical process Example (DHIS 2) District HIS designed to enable collection, collation, and analysis of HMIS & disease surveillance data across different subsystems but it does not have to be so…

Some benefits of integration Value added to data Example Integrated Human Resource & Health

Some benefits of integration Value added to data Example Integrated Human Resource & Health service 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 (training, hardware, software) – Centralized supporting activities (technical maintenance) – Decentralized core activities (public health decision making)

Interoperability and integration require standards Standardisation may be seen as going on at three

Interoperability and integration require standards Standardisation may be seen as going on at three levels of increasing complexity Three Levels of Standards --Organisational/ Political /pragmatic Increasing differences between views Programs / donors /agencies Agree to standardisation Shared / agreed indicators & meta data --Semantic Compared to a telephone conversation Shared interests? Interested in talking? Shared language and shared understanding? Increasing complexity Unique id. --Syntactic /technical SDMX-HD, etc. Compatible telephones & networks? For each level; “solutions” based on solutions at level below, and rely on agreement at level above 14

Horizontal integration: Information from across sectors & Organisational /political health programs available at “one

Horizontal integration: Information from across sectors & Organisational /political health programs available at “one point” level of integration (information needs & usage) Software applications & Information Systems Vertical Integration: “Seamless” flow of information from peripheral to central levels, from patient encounters in clinics to national M&E 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. DHIS 2) 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 i. HRIS to data according to standard loaded in DHIS using SDMX-HD

The application level of IHIA 16

The application level of IHIA 16

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

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, HL 7, SDMX-HD) Shared data standards and indicators, are the primary building block of the IHIA

Four (uneven) processes of change in the IHIA From paper to computer / mobile

Four (uneven) processes of change in the IHIA From paper to computer / mobile phone From stand-alone to networked computers From paper registers to electronic patient records From offline to online (web-based HMIS) Scaling in uneven contexts: Do we need to cover all forms? Do we need to cover all reproting units? If not, useless? 18

Centralization, decentralization and hybrid models – Who makes decisions? – Who controls budget? –

Centralization, decentralization and hybrid models – Who makes decisions? – Who controls budget? – Where does the data reside? (political/technical/managerial) – Does implementation start at top, or bottom? These questions have implications on: – User involvement (not always empowering) – Use of information for decision making