Ghasi eHealth
In development · pre-launch
- · AI-first by design
- · Offline-first by design
Enterprise eHealth platform — clinical, diagnostics, pharmacy, imaging, RCM, patient engagement. FHIR R4-first, multi-tenant, event-backed. Designed for national-scale rollout.
- Period
- 2025 — present
- Domain
- Healthcare / Public Sector
- Stack
- API Gateway · IAM
- Per-surface BFFs
- Event Bus
- AI Gateway
- FHIR R4
- HL7v2 · DICOM
- DDD · Outbox
Most eHealth deployments are stitched together from unrelated point products — a separate EHR, pharmacy, lab, radiology, billing, and patient portal, each with its own identity, audit, and tenancy story.
Ghasi eHealth replaces that pattern with one platform, one governance model, and FHIR R4 as the canonical clinical semantic layer. External formats (HL7 v2, DICOM, X12) integrate through adapters at the edge.
Offline-first and AI-first are not features tacked onto the platform — they are architectural posture baked in from the domain layer up. Clinicians capture vitals, record notes, and manage cases in facilities with intermittent or no connectivity; the client holds a local outbox and reconciles when the network returns. AI-assisted clinical decision support, documentation, and diagnostic coding run through a single AI Gateway with provenance metadata attached to every generated artifact, with full HIPAA-mode PHI routing enforcement.
The layers, ports, and integration patterns are real — drawn from the live architecture baseline. Service names, identity providers, and external vendors are anonymized or labelled by role so the diagram reads as the posture, not as a deployment manifest. Hover any layer label on the left for context; right-edge annotations call out the load-bearing decisions.
— 01 —
FHIR R4 as the canonical clinical model, not "FHIR-as-export."
CostBigger upfront semantic work.
WinOne source of truth across EHR, lab, pharmacy, imaging, and external integrations.
— 02 —
Database-per-service with strict no-cross-DB-reads.
CostData joins must traverse APIs or events.
WinEach bounded context is independently deployable and ownable; no shared schema politics.
— 03 —
Centralized authorization in `access-policy`, never UI-only.
CostEvery service makes a policy call.
WinPolicy is auditable and testable in isolation.
— 04 —
Single API gateway as the only public HTTP entry.
CostAn extra hop and a deployment surface to operate.
WinRouting, auth, rate limiting, and contracts are enforced at one boundary.
— 05 —
Offline-first client architecture with local outbox and per-aggregate conflict resolution.
CostConflict policies must be declared per aggregate; sync is non-trivial.
WinThe platform works in rural clinics, field settings, and facilities where connectivity is absent or unreliable.
— 06 —
Single AI Gateway as the sole egress point to LLM and AI providers.
CostEvery AI call routes through one service.
WinModel selection, cost ceilings, PHI redaction, HIPAA-mode routing, and provenance logging are enforced at one boundary — not scattered across services.
- 25+ bounded contexts mapped; platform + clinical + interop + engagement domains.
- Six client surfaces wired: clinician desktop, patient mobile, staff mobile, admin web, pharmacy, and a read-only patient portal fallback.
- Local infra parity: full stack runs on a developer laptop.
- Designed for staged rollout in donor-funded and public-sector programs; first deployment cohort under preparation.
Founder, lead architect, primary contributor. Authored the architecture baseline, the BC context map, the FHIR-first decision, and most of the service catalog.
The patient-chart aggregator service is fan-out heavy and would benefit from a CQRS read model materialized off domain events instead of synchronous calls. Planned for the next architecture pass.