cd /news/ai-products/what-production-ready-actually-means… · home topics ai-products article
[ARTICLE · art-27586] src=dev.to ↗ pub= topic=ai-products verified=true sentiment=↑ positive

What "production-ready" actually means for healthcare software

BioMedixAI, an AI-native healthcare platform, underwent a full-day adversarial audit to ensure production readiness. The team aligned vital-sign thresholds with the NEWS2 standard, fixed timezone issues by using local midnight, and implemented database-level constraints to prevent race conditions. They also hardened security by returning 404 instead of 403 for cross-tenant IDs.

read2 min publishedJun 15, 2026

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.

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

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.

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.

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.

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.

── more in #ai-products 4 stories · sorted by recency
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/what-production-read…] indexed:0 read:2min 2026-06-15 ·