# TibaLeta Implementation Map

## Phase 1 — Foundation, branding and architecture

Implemented TibaLeta brand tokens, logo mark, generated imagery, responsive public/dashboard layouts, explicit CI4 routes, service layer, MySQL schema, role filters, audit logs and production environment template.

## Phase 2 — Public website and authentication

Implemented Home, About, Services, How It Works, Find Care, practitioner profiles, For Practitioners, Partners, Resources, FAQ, Contact, Privacy, Terms, patient registration, practitioner registration, login/logout and password-reset flow.

## Phase 3 — Care request and geolocation

Implemented service selection, patient/family selection, address and browser geolocation capture, immediate/scheduled requests, care priority, pricing estimate and care-request persistence.

## Phase 4 — Smart dispatch and practitioner discovery

Implemented verified/online practitioner filtering, service filtering, distance calculation, ETA estimate, offer records with expiry, scheduled rematching command and public privacy-safe nearby API. Exact practitioner coordinates are used internally for dispatch but removed from public API output.

## Phase 5 — Practitioner portal

Implemented practitioner dashboard, online/offline state, request offers, accept/decline, visit schedule, professional profile, private credential uploads, clinical notes, prescriptions, lab requests, earnings/payout tables and telehealth/availability modules.

## Phase 6 — Home-visit workflow

Implemented accepted → en route → arrived → in progress → completed state transitions, patient live tracking screen, practitioner visit workspace, visit records, notifications and invalid-transition protection.

## Phase 7 — Clinical records

Implemented clinical encounter notes, vitals schema, conditions, allergies, medications, prescriptions and items, patient-facing health-record view, audit entries and restricted admin clinical metadata. Clinical narrative content is not displayed in the ordinary operations dashboard.

## Phase 8 — Payments and recurring care

Implemented payment ledger, provider-neutral payment service, M-Pesa/card gateway interfaces, payout ledger, recurring care packages/subscriptions and patient payment views. Live gateway calls require provider credentials.

## Phase 9 — Labs, pharmacy and partners

Implemented lab requests/results schema, home/facility collection status, prescription-to-pharmacy fulfilment, pharmacy orders, hospital/lab/pharmacy/insurer/corporate partner model, partner referral schema and role-restricted partner portal.

## Phase 10 — Telemedicine and mobile

Implemented appointments/telehealth session schema, practitioner/patient video-care surfaces, PWA manifest, responsive mobile interface and bearer-token mobile API for login, patient care requests/status and practitioner offers/actions. A native Flutter/React Native store binary is not bundled in this CI4 web repository; the API boundary is ready for one.

## Phase 11 — Insurance and corporate care

Implemented insurer/corporate partner types and partner/referral/payment integration boundaries. Actual claims submission, eligibility verification and corporate billing require contracts and APIs from the selected insurers/corporates.

## Phase 12 — Clinical routing support and analytics

Implemented a non-diagnostic triage-routing service hook, operational analytics service/dashboard and mobile/public API architecture. The triage rules are deliberately not a diagnosis engine and must be replaced/approved under clinical governance before production use. External AI models should be used only through governed, auditable workflows.

## Design assets

- `public/assets/images/tibaleta-home-care.png`
- `public/assets/images/tibaleta-practitioner-tablet.png`
- `public/assets/images/tibaleta-design-reference.png`
- `public/assets/images/tibaleta-mark.svg`

## Architecture

```text
Browser / PWA / Native Client
          |
   CI4 Routes + Filters
          |
Controllers / API Controllers
          |
Domain Services
 Auth | Dispatch | Clinical | Payments | Notifications | Analytics
          |
CI4 Models / Query Builder
          |
        MySQL
```

The initial application is intentionally a modular monolith. This keeps clinical transactions consistent while allowing high-volume capabilities—dispatch, notifications, payments or analytics—to be extracted into services later if scale requires it.
