Skip to content

Architecture at a Glance

graph TB
  subgraph "Clients"
    Mobile[Mobile App]
    Portal[Customer Portal]
    Partner[Partner Integrations]
    Admin[Admin SPA]
  end

  subgraph "API Tier"
    CA[clinical-api]
    AdminApi[admin-api]
  end

  subgraph "Workflow Tier"
    Orch[orchestrator]
    AI[ai-review]
    HR[human-review]
  end

  subgraph "Platform Tier"
    Auth[auth]
    Cons[consent]
    UM[user-management]
    Notif[notifications]
  end

  subgraph "External"
    DERM[DERM AI]
    Email[Email / Slack]
    Google[Google OIDC]
  end

  subgraph "Storage"
    DB[(MySQL per-service)]
    Cache[(Redis Streams)]
    S3[(S3 — image storage)]
  end

  Mobile --> CA
  Portal --> CA
  Partner --> CA
  Admin --> AdminApi
  AdminApi --> Auth
  AdminApi --> Google
  AdminApi -.-> CA
  AdminApi -.-> AI
  AdminApi -.-> HR
  CA --> Auth
  CA --> Orch
  CA --> Cons
  Orch --> AI
  Orch --> HR
  Orch --> Cons
  AI --> DERM
  AI --> CA
  HR --> CA
  Notif --> Email
  CA --> Notif
  CA --> UM
  CA --> S3
  CA --> DB
  Orch --> DB
  AI --> DB
  HR --> DB
  Cons --> DB
  Auth --> DB
  UM --> DB
  AdminApi --> DB
  AdminApi --> Cache
  Orch --> Cache
  AI --> Cache
  HR --> Cache
  Notif --> Cache

The platform is built as a small set of focused services that each own a clear piece of the clinical workflow. They communicate over a shared event bus (Redis Streams) and each owns its own database, so a fault in one service doesn't take down the others.

External traffic flows through clinical-api — the system of record. From there the workflow engine (orchestrator) decides what happens next based on the customer's configured flow: AI review, human review, both, or neither. All data is encrypted at rest, every action is audited, and every patient's data can be selectively erased on request (GDPR Article 17).

External integrations are limited to:

  • DERM AI (Skin Analytics' core dermatology AI) — receives image data, returns diagnoses
  • Email / Slack — for clinician and operational notifications
  • Google OIDC — used only for SA staff sign-in to the internal admin console (the admin-api BFF brokers the OIDC flow; customer traffic does not touch Google)

The architecture is deliberately small and well-bounded. There is no monolith; there is no single point of failure beyond the database for any one service. New services or workflows can be added without touching existing code paths.