HOPITEL
One care journey. Multiple interfaces. One shared foundation.
- My contribution
- Primarily backend development
- Outcome & status
- Academic prototype
Care information can become fragmented.
A patient may need to find a facility or department, arrange an appointment, attend a consultation and later access test results. When these steps are disconnected, people repeat information and can struggle to understand where to go next.
HOPITEL was conceived as a web and mobile platform connecting patients, doctors and healthcare facilities in Benin. The goal was to explore a more continuous journey, not to claim a deployed healthcare service.
From finding a service to accessing results.
The described journey starts with a patient searching for a facility or service, including a location-aware search. It then connects appointment requests with consultations and access to patient information and test results.
The scope discussed also covered accounts and roles for patients, doctors, facility administrators, a general administrator and laboratory staff. PDF results with a code, messaging, notifications and a conversational assistant using a RAG approach were also mentioned. These items describe the proposed scope; available material does not establish each one as completed and tested.
Building the backend layer in a team project.
My contribution was primarily backend development: API work, application logic, data handling, access rules and service integration. In a healthcare context, permissions matter because patients, clinicians, laboratory staff and administrators need different access to sensitive information.
This was a two-person thesis project. The web and mobile interfaces and the broader feature set were team work; I do not attribute every screen or module to myself.
Two clients, one API and a shared data layer.
The documented stack pairs a React web interface and a Flutter mobile app with a Django REST Framework API and PostgreSQL. JWT authentication was part of the described architecture.
Both clients can use the same backend contract. The API receives requests, applies application rules and permissions, and works with the shared database. This separation makes it possible to maintain distinct web and mobile experiences without duplicating the core rules.
- InterfacesFlutter mobile + React web
- APIDjango REST Framework
- Application logicRules, roles & data exchange
- DataPostgreSQL
An academic prototype presented for a bachelor’s thesis.
The project was built as a pair and presented at the bachelor’s thesis defence at INSTI in Lokossa on 8 July 2026. My role in that team was mainly on the backend.
The work demonstrates a proposed web-and-mobile architecture around a real care-coordination problem. It does not establish clinical use or measured outcomes.
An academic prototype, not a hospital service.
HOPITEL was not validated in a healthcare facility. No hospital deployment, patient adoption, medical impact or time saving is claimed. Hosting a prototype is not the same as operating it in a clinical environment.
The available project notes describe a wide feature scope, but do not verify which individual modules were fully implemented and tested. The work is not presented as a security audit, a clinically validated product or an offline-ready service. Exchanges about local and hosted environments, registration, email and data consistency are documented; a specific resolved incident is not.
A shared backend can give separate interfaces one set of rules and data.
ABOUBAKAR ADRAMANE