1 / 18

“Designing” an IHIA

“Designing” an IHIA. Health Information Systems; Integration and Interoperability. 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

saeran
Download Presentation

“Designing” an IHIA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

  9. Donor politics vsnational HMISrestructuring • Donors promoting own systems • Expatriates/experts • Not adopting integrated health systems framework HISP/DHIS2 from activists to regulators?

  10. 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 (DHIS2) 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…

  11. 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 (training, hardware, software) • Centralized supporting activities (technical maintenance) • Decentralized core activities (public health decision making)

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

  13. The application level of IHIA

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

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

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

More Related