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

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

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

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” 5 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

6. An example of fragmentation: Mozambique 7

7. Point of departure Fragmented information & Poor data quality 1 st step : Integrate data reporting Use existing data in District /National database repository & Demonstrate integration is possible and useful Revise data reporting forms & structures 2 nd 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

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

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

10. Sierra Leone: 2nd step Integration & interoperability (vertical) DHIS Others OpenMRS iHRIS Interoperability Patient recordsHuman 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

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 vs Minimum 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

20. 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”

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

23. Three levels of HIA (enterprise architecture) 24 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.

24. 25 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 /agencies Agree to standardisation Unique id. Standardisation & interoperability may be seen as going on at three levels of increasing complexity

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

26. 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 dataSDMX-HD 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-HDSDMX-HD

27. The application level of IHIA 28

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-HDHL7SDMX-HD 30

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

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

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 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 33

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

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

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