DEV Community: Nazmul Huda

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

Nazmul Huda — Sun, 28 Jun 2026 04:30:20 +0000

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.

How do you build one platform for 20+ healthcare verticals across 140 countries?

Nazmul Huda — Sun, 21 Jun 2026 04:16:42 +0000

We just made BioMedixAI launch-ready: a single platform covering doctors,
hospitals, diagnostics, pharmacies, ambulance, OT, ICU/CCU/NICU, blood bank,
telemedicine, teleradiology, HR, accounting and more — designed to run in 140
countries at once.

That sentence hides a lot of hard architecture decisions. A few we made early:

Shared-schema multi-tenancy scoped by facilityId on every query — one codebase, many facilities, isolation enforced at the data layer.
Country & facility as first-class config, not hardcoded assumptions: currency, timezone, locale, phone/NID/license formats all resolve per facility — so "go live in another country" is data, not a rewrite.
Per-facility local time everywhere — billing accruals, daily reports and sequence numbers roll over at each facility's local midnight (DST included), never UTC.
Additive-only schema discipline — every new vertical ships as new tables, never breaking the ones already in production.

Building broad and correct at the same time is the real challenge. More
engineering notes to come.

What "production-ready" actually means for healthcare software

Nazmul Huda — Mon, 15 Jun 2026 04:40:44 +0000

In most apps, a small bug is an inconvenience. In healthcare software, the
same bug can mean a wrong dose, a missed warning, or a bill that's silently
off. So before we let BioMedixAI — an AI-native healthcare platform — anywhere
near a launch, we spent a full day doing nothing but trying to break it.

Here's what that day actually looked like, and the bugs that taught us the most.

1. Vital-sign thresholds, re-aligned to NEWS2

Early on, our "normal vs abnormal" vital-sign bands were reasonable but not
standard. In clinical software, "reasonable" isn't good enough.

We re-aligned every threshold to NEWS2 (National Early Warning Score) — the
scoring system hospitals use worldwide to catch a deteriorating patient early.
Pulse, blood pressure, respiratory rate, SpO₂, temperature: each now sits in
the exact band that produces the correct early-warning flag.

Lesson: in a regulated domain, don't invent your own constants. Find the
published standard and match it exactly — then write tests that assert the
boundaries (spo2 === 91 should escalate, 92 should not).

2. Timezones will betray you at midnight

Several of our "per day" features (bed-day billing accrual, daily reports,
sequence-number year prefixes) were quietly bucketing by UTC. For a
facility in UTC+6, that means a day "closes" six hours early — and a bill can
land on the wrong calendar day.

We moved everything to roll over at each facility's local midnight, DST
included. The fix isn't hard; noticing it is. The only reliable way we found
to catch these is to run the logic with the clock pinned to an awkward time
(23:30 local, last day of the month) and watch what bucket the row lands in.

3. Concurrency: the database is your last line of defense

Two requests admitting the same patient to the same bed at the same millisecond
shouldn't both succeed. App-level checks (SELECT then INSERT) lose this race.
The fix is a partial unique index that lets the DB reject the second write:

one bed → at most one ACTIVE admission, enforced in Postgres, not in Node.

Application guards are for friendly error messages. The database is for truth.

4. Access control is correctness, not a feature

Part of the audit was purely adversarial: log in as role X, try to read role Y's
data, and confirm we get a hard stop. A few endpoints were returning data they
shouldn't have. We also standardized on returning 404, not 403, for
cross-tenant IDs — a 403 quietly confirms the record exists, which is its own
small leak.

Takeaway

None of this makes a good screenshot. There's no "we did the security and
correctness properly" demo. But this is the work that earns a system the right
to stand next to someone's health data.

We'd rather be slow and correct than fast and sorry.

Building BioMedixAI in public. More notes as we go.