ALL PROJECTS/CUREAXIS

Overview

CureAxis is a multi-tenant, HIPAA-regulated healthcare SaaS built at AmalAxis. It gives clinics a Patient Portal, a clinician-facing Clinical Workspace, a Platform Admin console for operators, and a metered Developer API for third parties building on top of its clinical AI. The platform spans six repositories — two Django backends and four single-page/console apps — and serves patients, care teams, and platform operators from one codebase while keeping every tenant's protected health information (PHI) cryptographically and logically isolated.

Walkthrough

3 short product films — swipe or use the arrows to move between them.

01 / 0330-Second Pitch

Problem

Healthcare software has to hold two opposing properties at once: many tenants sharing one system for operational efficiency, and absolute certainty that one tenant can never see, decrypt, or aggregate another tenant's PHI. A single leaked key or a query on the wrong database is a reportable breach. On top of that, tenants range from small clinics on a shared database to high-isolation customers with a fully dedicated database, so every read and write must resolve the correct data plane before it touches a routed table. CureAxis had to make that isolation the default behaviour of the framework itself — enforced in middleware, the ORM router, the database, and the serializer — while still delivering ambient AI scribing, EHR interoperability, patient self-service, and a billable public API.

System Design

How It Works

01/04
01

Tenant-scoped request and PHI access

How every request resolves its tenant, binds the correct data plane, and returns only permitted, decrypted, audited PHI.

  1. 1An SPA request reaches nginx, which maps the request origin/subdomain to the tenant header
  2. 2OrgContextMiddleware resolves the tenant from subdomain, header and JWT and cross-validates them, returning a fail-closed 403 on mismatch
  3. 3It binds the tenant id, member role and permissions, the tenant data-plane database alias, and the PostgreSQL RLS session GUCs
  4. 4The DRF viewset gates the caller through the Redis-cached RBAC permission catalogue and phi_guard field-group checks
  5. 5The routed queryset executes under the bound alias with RLS, and encrypted PHI columns are decrypted with the per-tenant DEK
  6. 6The permissioned serializer drops out-of-scope fields and PHIAuditMiddleware records a fail-closed audit entry before the response returns
02

Ambient clinical scribe

How a clinical encounter becomes a signed, EHR-ready SOAP note through provider-abstracted transcription and AI generation.

  1. 1A clinician opens an encounter in the Clinical Workspace and captures the consultation audio
  2. 2The STT factory selects Deepgram or ElevenLabs for the tenant and returns a transcript
  3. 3The transcript is sent to the OpenAI-backed SOAP generator to draft a structured clinical note
  4. 4The clinician reviews, edits and digitally signs the note; a second provider can co-sign
  5. 5Signing finalises the record as immutable, and the encounter can be pushed to the connected EHR over FHIR R4
03

Developer API capability call

How a third-party client exchanges a scoped API key for a short-lived service-JWT and consumes clinical AI on a separate compute plane.

  1. 1A developer creates a scoped, reveal-once API key (sk_test or sk_live) in the Developer Console
  2. 2The client exchanges the key at the control plane for a short-lived service-JWT (Contract-alpha, HS256, under 300s)
  3. 3The client calls a compute-plane capability under /api/service/v1 — soap.generate, report.analyze, lab.analyze, drug.interaction or transcription — with the JWT
  4. 4The service API verifies the token audience and scope, meters the call, and returns the analysis synchronously in the same response
04

Patient self-service via portal and voice

How patients enrol, book and pay across the web portal and a voice channel gated by server-side identity verification.

  1. 1A patient activates their account with an enrolment code in the Patient Portal, or calls the Twilio phone line
  2. 2On the voice channel, an ElevenLabs agent verifies the caller by date of birth before any PHI tool is allowed to run
  3. 3The patient books or confirms an appointment through the shared booking service, which enforces availability and double-booking guards
  4. 4Invoices are paid inline through Stripe Connect and reconciled against the patient account balance by webhook

Key Features

  • Three-layer tenant isolation: data-plane routing, PostgreSQL row-level security, and per-tenant AES-256-GCM envelope encryption
  • Fail-closed PHI audit middleware and a hardened tenant trust boundary with subdomain-to-JWT cross-validation
  • Ambient AI clinical scribe: Deepgram/ElevenLabs transcription feeding OpenAI SOAP-note generation with sign/co-sign immutability
  • EHR interoperability via a SMART-on-FHIR authorization server (S256 PKCE), FHIR R4 pull/push and CureAxis-as-FHIR-server
  • Metered Developer API with reveal-once keys, RFC 6749 client credentials and short-lived scoped service-JWTs over a separate compute plane
  • Patient self-service across web plus a Twilio/ElevenLabs voice channel with server-side DOB verification before PHI access
  • Stripe Connect patient billing with control-plane tenant subscriptions, auto-charge and usage-quota metering
  • Capability-based RBAC with a Redis-cached permission catalogue, TOTP MFA, SAML IdP and OIDC/AD workforce SSO

Outcomes

  • A working three-layer isolation model supporting both shared-database and fully dedicated-database tenants from a single codebase
  • A fail-closed security posture confirmed and regression-tested by a 23-agent whole-codebase deep analysis across DEK isolation, the tenant trust boundary and the SMART-on-FHIR flow
  • A cleanly separated Developer API — two planes, reveal-once keys, short-lived scoped service-JWTs — that exposes clinical AI to third parties (including a Flutter reference client) without touching PHI storage
  • CVE-annotated dependency pinning and multi-stage non-root Docker images with Trivy/SBOM/cosign supply-chain provenance across both backends

More work

AirAds preview
ADTECH PLATFORM

AirAds

Map-based discovery — the right nearby business, right now

VIEW PROJECT