“Designing” an IHIA

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

2. Understanding IHIAs • Why IHIA? • IHIA challenges (fragmentation++) • three levels of standards • why is integration important? • integration strategies; including interoperability • scaling of IHIA initiatives

3. IHIA: The motivation “Better information. Better decisions. Better health” - Health Metrics Network (HMN) “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)

4. 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” Standards? Prerequisite for integration and interoperability. Without shared “understanding” and meaning, no interoperability or integration, be it within social or technical systems!

5. 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)

6. An example of fragmentation: Mozambique

7. Another Example: Sierra Leone • Point of departure • Fragmented 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

8. Point of departure Sierra Leone:Fragmentation of information All programs own systems National: Fragmented info Difficult access Directorate of Planning & Information National Statistics Office IDSR EPI HMIS RH/FP TB HIV Census District: Fragmented data management Paper-based transcription and transmission Not fully disaggregated Surveys RH/ FP Outpatient services & morbidity IDSR TB HIV EPI District reports compiled by hand Facility: Many reports Little feedback Little use at facility No hospital reports Outpatient services & morbidity RH/ FP Hospital IDSR TB HIV EPI

9. Information use HIS office DHIS:National data repository Integrated data management Feedback Data and tools available to all staff Information use HIS office DHIS:District data repository Integrated data entry Feedback Health facilities and hospitals reporting aggregate paper forms to HIS office at district Information use Harmonised paper forms HF1 HF2 HF3 HFn ….. Sierra Leone: 1st step- aggregate data from all programs & services (horizontal integration) National Level District Level Facility Level

10. Sierra Leone: 2nd step Integration & interoperability (vertical) Others DHIS Interoperability OpenMRS iHRIS <... Integration ...> Patient records Human Resources

11. 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)

12. 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

13. Statisticians vs Public Health “data represents a public health event” More is better vsMinimum Data Set & information pyramid Treatment of outliers Upward reporting bias (performance)

14. 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

15. 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)

16. 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

17. 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)

18. 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?

19. 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

20. 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 (institutionalization) Example (DHIS2) District HIS designed to enable collection, collation, and analysis of HMIS & disease surveillance data across different subsystems

21. Some benefits of integration Example Integrated Human Resource & Health service data 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)

23. Three levels of HIA (enterprise architecture)

24. Interoperability and integration require standards Standardisation & interoperability may be seen as going on at three levels of increasing complexity 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? Increasing differences between views Programs / donors /agencies Agree to standardisation Shared / agreed indicators & meta data Increasing complexity Increasing complexity Unique id. SDMX-HD, etc. For each level; “solutions” based on solutions at level below, and rely on agreement at level above

25. National District based Integrated data repository DHIS Open Health CRIS Other data sources –programs Statistical data “numbers” DHIS DATA DICTIONARY/ CONCEPT REPOSITORY DHIS Translation & aggregation SDMX-HD Exchange standard HR records “names” iHRIS Open MRS Tensions between Standards and Local Flexibility => Essential Data Set Low Granularity Vertical Levels of aggregation; From HR /patient records, to national & global reporting (MDG indicators) Horizontal Across health programs, Services & agencies at each level High Granularity

27. The application level of IHIA

28. 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)

29. 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

30. Strategies for scaling of IHIAs Technical system, quantitative dimension: Components of the IHIA Social system, qualitative dimension: Cultivation approaches

31. IHIA Scaling: Technical perspective Shared data standards and indicators, are the primary building block of the IHIA 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

32. 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 verticaland horizontalaxes, 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

33. 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) • Scaling in uneven contexts: • Do weneed to cover all forms? (deepen) • Do weneed to cover all reproting units? (widen) • If not, useless?

34. Centralization, decentralization and hybrid models Centralization versus decentralization is a historicalchallenge in IS/HIS design Dimensions involvedhereare • Who makes decisions? • Who controlsbudget? • Wheredoesthe data reside? (political/technical/managerial) • Doesimplementation start at top, or bottom, or a hybrid? These questions have implicationson: • Userinvolvement (not alwaysempowering) • Sustainabilityof systems • Scalabilityof systems • Useofinformation for decisionmaking

35. Discussion topic: HISs/IHIAs as socio-technical systems • 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