Skip to content
Asmar.
§ CS-02 — Ghasi eHealth

Ghasi eHealth

In development · pre-launch

Enterprise eHealth platform — clinical, diagnostics, pharmacy, imaging, RCM, patient engagement. FHIR R4-first, multi-tenant, event-backed. Designed for national-scale rollout.

Period
2023 — present
Domain
Healthcare / Public Sector
Stack
  • NestJS
  • Kong
  • Keycloak
  • NATS
  • FHIR
  • HL7v2
  • DICOM
The brief

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.

Architecture at a glance

Anonymized to remove proprietary details. The pattern is real; the specifics aren't the part that matters here. Hover any layer label for context.

Decisions & tradeoffs
  1. 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.

  2. 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.

  3. 03

    Centralized authorization in `access-policy`, never UI-only.

    CostEvery service makes a policy call.

    WinPolicy is auditable and testable in isolation.

  4. 04

    Kong 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.

Outcome & scope
  • 25+ bounded contexts mapped; platform + clinical + interop + engagement domains.
  • Six client surfaces wired: clinician web, desktop (Electron), patient mobile (Expo), pharmacy, lab, patient portal.
  • 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.
My role

Founder, lead architect, primary contributor. Authored the architecture baseline, the BC context map, the FHIR-first decision, and most of the service catalog.

What I'd do differently

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.

← All case studies

Designing something similar?

Explore other work