Fetching latest headlines…
Building a 447-system healthcare OS in one codebase — the architecture behind BioMedixAI
NORTH AMERICA
🇺🇸 United StatesJune 28, 2026

Building a 447-system healthcare OS in one codebase — the architecture behind BioMedixAI

0 views0 likes0 comments
Originally published byDev.to

It started with a failed ambulance call at 2 AM and turned into a question I couldn't shake: why does every healthcare facility run 8 disconnected tools instead of one nervous system?

Over the last cycle we shipped BioMedixAI — an AI-native healthcare operating system unifying 447+ management systems on a single multi-tenant platform. Here's the engineering reality behind that sentence.

The stack

Backend: NestJS (TypeScript) — 103 modules, 151 Prisma models, 132 migrations
Frontend: Next.js 15 (App Router / RSC), Tailwind + shadcn/ui, PWA-installable
Data: PostgreSQL 16 — shared-schema multi-tenancy, every query scoped by facilityId, with Row-Level-Security as a DB-level backstop
Standards: FHIR R4 (read), HL7 v2 ADT/ORU, ICD-10 with ICD-11 crosswalk, SNOMED + LOINC
Three hard problems we had to solve

One person, many roles. A doctor who also owns a diagnostic center is one identity with stacked roles — never duplicate accounts. Roles attach to a Person, modules activate per facility.
Cross-facility patient identity. A portable Universal Health ID (UHID) the patient can claim and carry across any facility — their data follows them, not the institution.
Tenant isolation at scale. Application-layer scoping on every query, plus flag-gated Postgres RLS so a bug in one layer can't leak across tenants.
The full series — multi-tenancy patterns, the "modality-aware status set" trick, surgical live-DB migrations without dropping 40 FKs — is coming. Follow along.

👉 Live platform: https://www.biomedixai.com/

What's the most fragmented part of healthcare software you've had to integrate? I'd love war stories in the comments.

Comments (0)

Sign in to join the discussion

Be the first to comment!