MamaOpe Medicals · Digital health · Clinical decision support
HealthNavi
Engineering clinical decision-support software for real-world healthcare environments.
- My role
- Core engineer on the MamaOpe product team
- Status
- Piloted in clinics
- Areas
- Software & Product Engineering, AI & Machine Learning, Healthcare & Biomedical, Research & Innovation, Mobile & Web Applications
- Stack
- Python · FastAPI · TypeScript · React · PostgreSQL
- symptomatic patients in the evaluation study
- 168symptomatic patients in the evaluation studySource: Babirye et al., VeriXiv 2026 (preprint)
- sensitivity for pneumonia (NPV 95.2%)
- 92.3%sensitivity for pneumonia (NPV 95.2%)Source: Babirye et al., VeriXiv 2026 (preprint)
- sensitivity for TB (NPV 97.9%)
- 89.5%sensitivity for TB (NPV 97.9%)Source: Babirye et al., VeriXiv 2026 (preprint)
- health facilities in Kampala, Apr – May 2025
- 5health facilities in Kampala, Apr – May 2025Source: Babirye et al., VeriXiv 2026 (preprint)
The problem
Pneumonia and tuberculosis remain leading causes of death in low- and middle-income countries, and their symptoms overlap with each other and with conditions such as bronchitis and asthma.
Frontline clinicians often work with heavy patient loads, limited specialist support and limited diagnostic infrastructure. The gap between published guidelines and bedside practice is widest exactly where the stakes are highest.
Context
HealthNavi is MamaOpe Medicals' clinical software product. It is designed to support clinical judgement, not replace it: the app itself states that it does not provide a medical diagnosis.
HealthNavi is a separate product from Empirico. HealthNavi owns the clinical workflow and user experience; it calls the Empirico model service for knowledge retrieval and AI-generated guidance.
The solution
A conversational, web- and mobile-accessible application in which clinicians enter symptoms, vital signs and routine clinical findings, and receive ranked, guideline-grounded differentials and next-step recommendations with references.
Responses are grounded in curated sources, including the Uganda Clinical Guidelines and the British National Formulary, rather than the language model's general training data.
The system design implements HL7 FHIR R5 resources, ICD-10 and SNOMED CT coding and LOINC mappings so it can integrate with health information systems.
Architecture
- 01
HealthNavi app
React / TypeScript web app and Android client
- 02
HealthNavi backend
FastAPI · auth · PostgreSQL · chat history
- 03
Empirico model service
Separate API for retrieval and generation
- 04
Evidence retrieval
Embeddings + vector search over curated guidelines
- 05
LLM
Gemini, prompted with retrieved evidence
- 06
Structured response
Ranked differentials, next steps, references
HealthNavi calls Empirico as an outside service. They are separate products with separate codebases.
What I did
Application engineering
- Developed and maintained frontend features in TypeScript/React and backend services in Python/FastAPI.
- Implemented clinical workflow features backed by PostgreSQL, including patient-context capture and conversation history.
AI integration
- Integrated the application with the Empirico model service: request/response workflows, streaming responses and error handling.
- Worked on evidence retrieval and context handling so answers carry their supporting references.
Reliability & infrastructure
- Containerised services with Docker and supported deployments across environments.
- Worked on request management, rate limiting and concurrency controls to keep the service responsive under load.
Quality & evaluation
- Tested application functionality and evaluated the consistency of AI-assisted responses against clinical reference answers.
- Co-authored the published performance-evaluation study of the system.
Engineering decisions
- Separate the clinical app from the model service
- Keeping retrieval and generation in Empirico, behind an API, lets the clinical application evolve its workflow independently while the knowledge layer is improved, evaluated and reused by other products.
- Ground every answer in curated guidelines
- Retrieval over national and international guidelines makes responses traceable to a source a clinician can check, which is essential for trust in a clinical setting.
- Support judgement, don't replace it
- The product is presented as decision support, both in the app and in the study. Outputs are ranked differentials with recommendations, leaving the clinical decision with the clinician.
Challenges
- Connectivity in low-resource facilities
- The evaluation identified dependence on connectivity as a barrier and clinicians requested offline functionality. That feedback now shapes the product roadmap.
- Balancing sensitivity against over-diagnosis
- The system was tuned for screening: it catches most true cases but flags more patients than clinicians do. Using the first-ranked diagnosis greatly improved agreement with clinicians, pointing to where ranking and calibration work matters most.
Outcomes
- Evaluated in a mixed-methods study at five health facilities in Kampala, Uganda (April – May 2025), with 168 symptomatic patients and interviews with 10 clinicians.
- High sensitivity and negative predictive value for both TB and pneumonia, supporting use as a screening aid; lower specificity indicated over-diagnosis, which the study reports openly.
- Clinicians described the system as fast and intuitive.
- Piloted in healthcare settings in Uganda. A pilot in Zambia is under way.
- Published on Google Play as an Android app for healthcare professionals.
Screens
Technologies
- Python
- FastAPI
- TypeScript
- React
- PostgreSQL
- Docker
- Gemini
- RAG
- HL7 FHIR R5
- Android
What I took away
In clinical software, trust is a feature: references, honest framing and predictable behaviour matter as much as model quality.
Testing in real clinics finds problems no test suite will: connectivity, workflow fit and how clinicians actually read a ranked list.