Health Data & Interoperability

Most African health systems do not lack data: they lack data that moves. A patient's history cannot follow her to the next clinic, a lab result is re-typed until errors creep in, and an outbreak signal sits in one system while responders work from another. This Level II course teaches the discipline that fixes that. Over 8 weeks (15 CEU), you will diagnose fragmentation in a real health information system and trace it to financing and governance rather than technology, work across the four layers of interoperability using HL7 FHIR, ICD, and LOINC, and map the OpenHIE component set onto a national platform such as Ethiopia's. You will configure and interpret DHIS2 for routine reporting, turn dashboards into decisions, run a data-quality assessment, and make a defensible build-versus-buy decision. It is designed for HIS officers, informaticists, and data managers, and open to health professionals and students across disciplines.

Course glossary

• Interoperability — the ability of two or more systems to exchange information and to use the information that is exchanged; has technical, syntactic, semantic, and organizational layers.
• Integration — direct connection of two applications without an intermediary exchange, as distinct from many-system interoperability through a shared mediator.
• Fragmentation — vertical, siloed applications that cannot usefully exchange data; the default pathology of unmanaged digital health, produced by financing and governance.
• Digital health platform (DHP) / infostructure — a shared information infrastructure of common, reusable components (identity, registries, exchange, terminology) on which applications run.
• OpenHIE — an open-source reference architecture specifying the standard component set for a national health information exchange.
• Client registry / Master Patient Index (MPI) — the component assigning each person a unique identity across systems; the foundation of longitudinal records.
• Facility registry — the authoritative single source of truth for facilities (e.g., Ethiopia's Master Facility Registry, MFR).
• Shared health record (SHR) — the longitudinal clinical repository populated by point-of-service systems.
• Terminology service — the running authority for codes (ICD, LOINC, national drug codes) that gives exchanged data shared meaning.
• Health information exchange (HIE) — the governed capability for moving health data between systems and organizations; a mandate, not mere plumbing.
• HL7 FHIR — a global, web-based standard for passing healthcare data between systems, organising clinical concepts into reusable resources accessed via REST APIs.
• HL7 v2 — the older pipe-delimited messaging standard FHIR progressively replaces.
• ICD — the international classification for coding diagnoses and causes of death.
• LOINC — Logical Observation Identifiers Names and Codes; the standard for laboratory and clinical observations.
• SNOMED CT — an internationally used controlled clinical vocabulary covering findings, procedures, and more.
• DHIS2 — the open-source HMIS platform (University of Oslo) that is Africa's routine-reporting backbone.
• HMIS — the routine aggregation of facility data for management and planning.
• OpenMRS — the leading open-source EMR platform for low-resource settings (basis of KenyaEMR, UgandaEMR).
• EMR vs EHR — a record within one organization versus a longitudinal record shareable across organizations.
• Digital public goods (DPGs) / global goods — open-source, standards-based, do-no-harm digital health applications that are adaptable, multi-donor-funded, and interoperable.
• Total cost of ownership (TCO) — the full lifetime cost of a system including implementation, hosting, support, and staffing — not just licences.
• Data sovereignty — national governance of domestically generated data, including hosting location and administrative control.
• Data-use gap — the failure mode where a system collects data successfully but does not change decisions.
• Data quality — fitness of data for use, across completeness, timeliness, consistency, and accuracy.
• Donor cliff — the loss of a single-donor-funded system's sustainability when the grant cycle ends without a domestic budget.
• Learning health system — a system that continuously and routinely studies and improves itself using its own data.

Frequently asked questions

Q: Isn't interoperability mainly a technical (FHIR) problem to be solved by engineers? A: No — that is the most common and most expensive mistake. Interoperability has four layers, and the one that decides success is the organizational layer: data-sharing agreements, consent rules, and a governance authority with the power to compel exchange. The book's repeated finding is that "FHIR and shared terminologies are necessary but not sufficient without governance authority," and that an HIE "exists only where policy compels it." Buy the best FHIR server in the world and you still have no interoperability if no procurement rule mandates it, no law permits the data to move, and no body enforces either.

Q: What is the difference between integration and interoperability? A: Integration directly wires two applications together without an intermediary. Interoperability lets many systems exchange data through a shared mediator (the HIE) using common standards. A nation of point-to-point integrations is still a tangle of up to N×N interfaces; interoperability through a platform turns that tangle into a hub where each system builds one connection.

Q: Why are registries — especially the client registry — so important? A: Because identity is the foundation of everything else. Without a reliable unique patient identifier, the same person appears as different people in different systems and no record can follow her, so longitudinal care, accurate counting, and de-duplicated analytics all fail. Ethiopia's Blueprint is explicit that the lack of a unique digital ID "has been one of the areas of struggle" and names it a top-priority intervention. Facility identity (Ethiopia's Master Facility Registry) plays the same foundational role for reporting.

Q: What do ICD, LOINC, and SNOMED CT each code, and why do I need them if I already use FHIR? A: FHIR formats messages; terminologies give them meaning. ICD codes diagnoses and causes of death; LOINC codes laboratory and clinical observations; SNOMED CT is a broad controlled clinical vocabulary. Without shared codes, "sugar," "DM," and "type 2 diabetes" cannot be counted as the same disease even inside a perfectly formatted FHIR message. And a terminology is only useful while maintained — "an unmaintained standard is merely an old opinion" — so it requires a standing standards body to version and certify it.

Q: Is DHIS2 enough on its own to fix our health information system? A: No. DHIS2 is the excellent open-source backbone for aggregate routine reporting, but its hardest problem is the data-use gap — collecting data that never changes decisions. Closing that gap "is less about software than about management culture": review meetings that interrogate data, supervisors who act, and visible local benefit. Ethiopia's Information Revolution institutionalises this by verifying facilities at "model" status for demonstrated data use, not just data entry — with the caution that maturity models can decay into checkbox exercises without sustained supervision.

Q: Why prefer digital public goods over commercial products — isn't "free software" risky? A: The case is strategic, not about price. DPGs give sovereignty (you control the code and hosting), better total cost of ownership at scale, a global implementer community, and adaptability without a vendor's roadmap. The 2023 collapse of Babylon Health — which ran a national telehealth partnership in Rwanda — shows the platform fragility you inherit from commercially fragile foreign vendors. But DPGs are not free of dependency: "open source shifts dependency from vendors to capacity," and "open" does not automatically mean interoperable or secure. The mature rule is to default to DPGs within a certified architecture and admit proprietary tools only on exit-safe terms.

Q: What is the "donor cliff" and how does interoperability help with it? A: The donor cliff is what happens when a system funded by a single external grant loses its funding, support, and sustainability at the end of the cycle — leaving a graveyard of half-dead, non-communicating pilots. Interoperability and a digital-public-goods strategy reduce the exposure: standards-based, open systems on a national platform can be sustained, re-hosted, and supported by domestic and regional capacity rather than dying with the grant. This is why sovereignty and sustainable financing recur in Ethiopia's Blueprint as central concerns.

Q: We have low bandwidth and unreliable power. Can we really do interoperability and analytics? A: Yes, if you design for the infrastructure Africa actually has. Solutions that are "offline-capable, low-bandwidth, mobile-first... repeatedly outperform solutions transplanted from high-bandwidth settings." FHIR's granular resources can sync individually when a connection appears; DHIS2 supports offline data entry; mHealth channels like SMS/USSD reach feature phones. The constraint shapes the design — it does not forbid the goal. What it does forbid is copying a high-bandwidth architecture and hoping.