Digital health concept Ghana
A thoughtful concept for connecting patients with care, prescriptions, pharmacy delivery and urgent transport — in one clearer journey.
For the past year I have been thinking about the steps a person in Ghana takes to get medical attention: finding a qualified doctor, arranging a consultation, getting a valid prescription, locating a pharmacy that has the medicine, arranging delivery, and knowing where to turn when urgent transport is needed. Today these steps are handled by separate people and services, and the patient is left to coordinate all of it.
I want to connect those steps in one organised journey, and give doctors, pharmacists and service partners mobile tools to deliver their part. I am not proposing to replace doctors, pharmacists, hospitals or emergency services. My aim is to make it easier for people to reach qualified providers, and easier for those providers to coordinate care.
I have used the year to challenge the idea, work through the practical problems and plan a version that can be built in phases and tested in the real world. The prototype below is the first visible result.
Five roles share one live order. Start as the patient and book a doctor. Then use the tabs to act as the doctor, the pharmacy, the courier and the admin team, and watch the order move forward. The panel beside the phone shows what the platform records at each step: order status, where the money sits, and the audit trail.
Everything here is simulated. People, prices and pharmacies are fictional, payments are pretend, and nothing is medical advice.
One connected platform with role-based mobile experiences. Each step below is something you can try in the demo above.
A patient registers, searches for an available verified doctor and books a consultation. Unverified doctors cannot be booked.
The doctor assesses the patient remotely when clinically appropriate, records the encounter, and gives advice, a referral or a prescription when justified.
An authorised pharmacy verifies the prescription, confirms stock and price, and prepares the order.
A suitable courier collects the order, gives status updates and records proof of delivery with an order-specific PIN.
The patient confirms receipt or raises a dispute. Payment settlement follows the agreed, provider-supported rules.
The platform helps connect the patient or care team with a verified ambulance partner. It never shows a request as confirmed until a provider accepts it.
For medicine delivery I will work with courier partners rather than buy a fleet. For ambulance services I will partner with authorised providers and keep human dispatch oversight. Emergency calling must stay available even if the app or its integrations are down, which is why the emergency button sits at the top of the patient home screen.
One feature I consider essential is payment protection for pharmacy orders. The pharmacy's eligible payout stays pending until the agreed delivery and dispute conditions are met, to the extent supported by a payment provider's product and legal arrangement. Patients see the order total, delivery status, dispute window and refund status clearly. If a patient reports a missing, incorrect or damaged order, the relevant amount is held where possible while the case is reviewed, and the platform records the evidence and the resolution.
I will not assume that a normal payment gateway provides escrow, or that the company can legally hold customer funds itself. Both points must be confirmed with a suitably authorised provider and Ghanaian legal counsel.
The demo follows these states. The two-hour inspection window for ordinary deliveries is a policy hypothesis I want to validate. It never removes the separate route for suspected counterfeit medicines, adverse reactions or other serious safety concerns, and the demo includes that route.
I intend to build a sustainable business with transparent fees and written agreements. Potential revenue streams are:
Ambulance-related fees would only be considered where lawful and contractually appropriate. I will not assume that publicly funded emergency services can be commercialised through commissions. The business will not sell patient information or influence clinical decisions to increase medicine sales.
Illustration, not a forecast: on a GHS 100 consultation with a 20% platform share, the platform earns GHS 20 and the doctor receives GHS 80. At 1,000 consultations a month that is GHS 20,000 in gross platform revenue, before payment fees, taxes, refunds, support, staffing and hosting. The demo's ledger uses the same 20% split.
The first target markets are Accra and Kumasi. I will recruit a limited network of verified doctors, participating pharmacies and delivery partners, then test the service in defined coverage areas. The platform will not promise availability where a verified provider or delivery partner is not actually available.
| Stage | Focus | Outcome |
|---|---|---|
| 1. Validate | Patient and provider interviews, regulatory and payment discovery | Confirmed requirements and partner interest |
| 2. Build | Android app, backend, appointments, consultations and admin tools | Testable telemedicine MVP |
| 3. Connect | Approved pharmacy workflow, delivery and payment protection | Controlled pharmacy and delivery pilot |
| 4. Evaluate | Pilot measurement, support procedures, ambulance-partner readiness | Evidence for expansion decisions |
The pilot aims to recruit 10–15 doctors, 5–10 pharmacies and 100–200 invited patients, and to reach at least 85% consultation completion, at least 90% fulfilment of accepted orders, full payment reconciliation and zero serious unresolved payment discrepancies at sign-off. The six-month schedule is a planning estimate, not a commitment.
My initial development budget is GHS 60,000–150,000. For planning I use GHS 120,000 as a working scenario, subject to quotations and regulatory discovery. It is meant to fund a lean Android-first MVP with a small team, managed third-party services and a limited pilot, not a nationwide healthcare and logistics operation.
| Workstream | Planning allocation |
|---|---|
| Discovery, requirements and UX/UI (the prototype above is the first output) | GHS 10,000 |
| Android application | GHS 28,000 |
| Backend API and database | GHS 24,000 |
| Admin and provider interfaces | GHS 12,000 |
| Video, payment and delivery integrations | GHS 10,000 |
| Testing, security and QA | GHS 10,000 |
| Initial legal and regulatory advice | GHS 8,000 |
| Hosting and third-party services during development | GHS 3,000 |
| Pilot onboarding and operational testing | GHS 5,000 |
| Contingency reserve | GHS 10,000 |
| Total working scenario | GHS 120,000 |
Indicative, not a supplier quotation. It excludes ambulance fleet purchases and may not cover ongoing operating costs, extensive integrations, insurance, marketing or unexpected compliance requirements. The scope must be reduced if quotations exceed the approved budget. I will use milestone-based contracts with clear deliverables and code ownership.
Healthcare needs more than good software. Before public launch I will work with qualified Ghanaian advisers and the relevant authorities to confirm the requirements that apply to the platform's actual operating model.
At this stage I want to build relationships with people and organisations who can help turn this concept into a tested, responsible business:
After a year of thinking, weighing the practical challenges and connecting the different services into one model, I believe the next step is to move from concept to disciplined execution. I know this needs the right partners, regulatory guidance, careful product development and evidence from real users. I am not claiming every challenge is solved. I am presenting a clear direction, a phased plan, a working prototype and a willingness to build responsibly.
I would welcome the chance to discuss the concept, test the assumptions and explore how we can build a sustainable solution together.
Abraham Karikari · abkarikari23@gmail.com · WhatsApp: +233 20 128 3577
This document describes an early-stage business concept and planning assumptions. Pricing, budget, timeline, market demand, partner participation and regulatory pathways require validation before investment or public launch. No specific provider or regulatory approval is implied. The prototype uses fictional data and simulated payments.