Hamza Asumah, MD, MBA, MPH
The Unsexy Advantage
Here’s what founders miss: In African healthtech, your competitive advantage probably isn’t your UI, your AI model, or your feature set. It’s whether you can plug into DHIS2, speak FHIR, and exchange data with government systems nobody’s heard of.
The most widely deployed Health Information Management System platform globally is DHIS2, employed by Ministries of Health in 80 low- and middle-income countries impacting 40% of the world’s population. If your system can’t talk to DHIS2, you can’t integrate with most African government health systems. Full stop.
Why “Boring but Compatible” Beats Flashy Features
Every African government is working toward Universal Health Coverage. That means data systems that track:
- Patient enrollment
- Service delivery
- Disease surveillance
- Supply chain management
- Health workforce deployment
Ethiopia’s HMIS contains 53 data sets used by more than 35,000 health facilities serving different layers of the health sector including health posts, health centers, and hospitals to deliver various types of reports, making it the major source of information for the Federal Ministry of Health.
What this means: Any healthtech product that creates a data island—even a beautiful, clinically useful data island—will eventually hit a ceiling. Governments increasingly require systems that interoperate with national health information platforms.
The company that integrates smoothly wins the tender. The one that requires manual data entry or parallel reporting loses.
The Standards That Actually Matter
1. FHIR (Fast Healthcare Interoperability Resources)
FHIR is an open-source standard that supports the easy transfer of healthcare data in the Health Level Seven format across systems. It’s becoming the global standard for health data exchange.
Why it matters in Africa:
The mHealth4Afrika project leveraged HL7 FHIR to support standards-based data exchange and interoperability between Electronic Medical Records and DHIS2, with successful validation in Ethiopia, Kenya, Malawi, and South Africa.
South Africa has been particularly aggressive in FHIR adoption. The National Department of Health maintains a robust digital HR registry built on FHIR format using the mCSD IHE profile, with the registry holding over 1 million records as the authoritative repository of demographic information on healthcare workers.
Practical implication: If you’re building EMRs, telemedicine platforms, or patient registries, FHIR compatibility isn’t optional—it’s your path to government contracts and donor funding.
2. DHIS2
DHIS2 serves as a platform for receiving and hosting data from different sources and sharing data with other systems and reporting mechanisms, leading to adoption as a data warehouse in numerous countries.
DHIS2 dominates in Africa for:
- Routine health information systems
- Disease surveillance
- Supply chain tracking
- Program monitoring and evaluation
Critical detail: Scalable local EMR data-to-FHIR resource mapping was developed using the HAPI FHIR library, proving that interoperability between EMR systems and DHIS2 significantly fosters national eHealth architecture maturity.
What you need to know:
- DHIS2 has REST APIs for data exchange
- It supports FHIR integration through mediators
- Many countries run multiple DHIS2 instances (one per health program), requiring data aggregation strategies
- Understanding DHIS2’s data model helps you design compatible systems
3. OpenMRS and Bahmni
Notable open source EHR systems employed in Africa include OpenMRS and Bahmni platforms, which have played a crucial role in systematizing compilation of patient information and tracking spread of epidemics like Ebola outbreaks.
These aren’t just alternative EMRs—they’re integration endpoints. If your telemedicine or diagnostic platform needs to push data into facility-level records, OpenMRS/Bahmni compatibility matters.
Real-World Interoperability Implementation
Case Study: Ethiopia’s National Data Exchange
Ethiopia developed an eHealth Architecture-based health data exchange model leveraging HAPI FHIR to expose SmartCare EMR local data, which involves developing EMR and FHIR resource data element mapping strategy.
The results: Enhanced data quality examined using timelines, accuracy, completeness, and cost parameters over a 12-month period, with interoperability patterns producing enhanced HMIS data quality and establishing reusable data exchange modules with national impact.
Translation: They moved from manual paper registers to automated data flows between EMRs and national HMIS. That’s the transformation every African country is pursuing.
Case Study: South Africa’s COVID-19 Response
South Africa’s HRH system built a mesh of connected APIs facilitating data exchange with the National COVID Data Lake collecting information about health workers infected with the virus and the National Vaccine eRegistry determining health workers eligible for COVID vaccine.
The outcome: By end of 2021, 59% of healthcare workers in South Africa were vaccinated, compared to only 1 in 4 across Africa overall. Interoperability enabled rapid rollout.
Building Your Interoperability Strategy
Phase 1: Design with Standards from Day One
Don’t build proprietary data models then try to map to standards later. HL7 FHIR standard is particularly well adapted for exchanging and storing health data, while DICOM, CDA, and JSON can be converted to HL7 FHIR or vice versa for interoperability purposes.
Practical steps:
- Use FHIR resources (Patient, Observation, Encounter, etc.) as your data model foundation
- Even if you don’t expose FHIR APIs initially, structuring data in FHIR-compatible formats makes future integration easier
- Document your data mappings to national standards early
Phase 2: Implement Core Integration Points
Common DHIS2 integration use cases include synchronization of organization units and data elements across systems, exchange of aggregate data, pushing Tracker data into aggregate systems, and exchange of patient data.
Minimum viable interoperability:
- Organization unit registry sync (facilities, health worker lists)
- Aggregate reporting (monthly summaries, disease notifications)
- Patient identifier schemes that align with national systems
Phase 3: Participate in National Architecture
To move to Stage 3 maturity requires both national digital health strategies and implementation of interoperability and health data standardization across devices, systems, and platforms.
How to engage:
- Join national eHealth technical working groups
- Participate in standards development processes
- Align with national digital health strategies (38 African countries now have them)
The Business Case for Interoperability
1. Government and Donor Procurement
Public-private partnerships can play a vital role, with the Investing in Innovation Africa program successfully connecting African health tech startups with funding and strategic partnerships by supporting systems that enhance healthcare delivery and accessibility.
Interoperable systems win tenders. Non-interoperable systems create vendor lock-in that governments increasingly reject.
2. Network Effects
Once your system connects to national infrastructure, you become harder to replace. Success is not measured by app downloads but by integration into operational realities, with technology being offline-first and deeply embedded within the healthcare value chain.
3. Reduced Implementation Costs
When you can automatically pull facility lists, health worker registries, and patient identifiers from national systems, your deployment costs drop dramatically. No more manual data entry for setup.
The Standards You Can Ignore (For Now)
HL7 v2: Older standard, still used globally but FHIR is superseding it. Focus on FHIR.
CDA (Clinical Document Architecture): Relevant for document exchange but less critical in African context where structured data exchange is priority.
ICD-10/ICD-11: Important for disease classification but most African countries are still on ICD-10, with slow migration to ICD-11. Ensure you can support both.
SNOMED-CT, LOINC: Global terminology standards that matter less when most African systems use simpler local code lists. Map to these if required by donors, but don’t over-invest early.
Common Interoperability Mistakes
Mistake 1: Building APIs but Not Following Standards
Just because you have an API doesn’t mean you’re interoperable. The API must use standard data formats, not your custom JSON structure.
Mistake 2: Assuming One Integration Solves Everything
Most countries have more than one DHIS2 instance such as for different health programs, requiring synchronization of organization units and data elements across systems. You’ll need to handle multiple integration points, not just one national system.
Mistake 3: Waiting for Perfect Standards
Standards are evolving, implementations are messy, and documentation is incomplete. Deploy with best-effort compliance, then iterate as standards mature.
What Success Looks Like
You’ve nailed interoperability when:
- Your system can onboard at a new facility by pulling existing infrastructure data from national systems
- Reporting to government happens automatically, not through manual monthly spreadsheets
- Your patient data can move seamlessly if patients switch providers
- You’re included in national digital health architecture diagrams
The Future: Continental Standards
The African Medicines Agency intends to result in streamlined regulatory processes instead of having 54 national agencies each with its own regulatory requirements. Similar standardization is coming for health data.
The companies that win the next decade won’t be those with the best standalone products. They’ll be the ones that become part of the national and continental infrastructure.
Flashy features attract pilots. Standards win scale.
Be boring. Be compatible. Win.
Dr. Hamza Asumah 
Leave a comment