DEV Community: Dhruv Jain

Two-stage AI triage: Claude on Bedrock plus a conformal ML ensemble, on DynamoDB and Vercel

Dhruv Jain — Mon, 29 Jun 2026 06:02:05 +0000

Solace assigns an emergency-department acuity level (ESI) from a patient's own words and then refines it at the bedside. I wanted a model that helps a clinician without ever pretending to make the call. Here is how the triage brain works, and how it sits on DynamoDB and Vercel.

Stage one: narrative ESI on intake

A patient describes what is wrong by voice or text, in any of 20+ languages (speech runs through Amazon Transcribe and Polly). Amazon Bedrock (Claude) reads that narrative and produces a provisional ESI before any vitals exist. This is what powers the calm spoken result the patient hears and the first sort of the live clinician queue.

Everything runs inside AWS managed services covered by the Business Associate Agreement, so patient text never leaves the BAA boundary.

Stage two: refinement at the bedside

When vitals are entered, a stacked ensemble (LightGBM, XGBoost, CatBoost, and an MLP) refines the ESI. Two things make it usable in a real department:

SHAP attributions, so a clinician sees which features drove the score instead of a black-box number.
Split-conformal prediction sets, so the model can say "I am not sure" with a real coverage guarantee rather than a fake confidence percentage.

A deterministic safety floor sits on top: the system never down-triages a life threat, regardless of what the model thinks.

Where it lives

The refined ESI, the conformal set, and the top features are written back onto the patient record in DynamoDB, so the clinician cockpit reads a single, current source of truth in milliseconds. The cockpit and the patient app both deploy on Vercel and call the FastAPI-on-Lambda backend that fronts DynamoDB.

The model never overrides the clinician. It hands them a defensible starting point, shows its work, and gets out of the way.

I created this content for the purposes of entering the H0: Hack the Zero Stack hackathon. #H0Hackathon

Shipping a HIPAA-grade health app on Vercel + DynamoDB + Lambda

Dhruv Jain — Mon, 29 Jun 2026 06:01:04 +0000

Solace is an AI patient intake and triage app for emergency departments. Here is the full stack and why each piece is where it is. The whole thing runs on AWS managed services with the human-facing apps on Vercel.

The request path

Patient phone / Clinician (Vercel SPA)
        -> CloudFront + WAFv2
        -> API Gateway (HTTP)
        -> Lambda (FastAPI, arm64 container)
        -> DynamoDB, S3, Bedrock, Transcribe, Polly

Cross-cutting: KMS CMK, Secrets Manager, CloudTrail, CloudWatch, EventBridge, SNS.

Why Vercel for the front door

A patient checks in by scanning a QR code in the waiting room, with no app and no account. The patient app and the clinician terminal are static, edge-cached shells on Vercel that load fast on a weak waiting-room connection, then call the AWS backend. Branch-based atomic deploys mean I can ship the marketing site, the patient app, and the clinician app independently.

Compute

One FastAPI service (via Mangum) packaged as an ARM64 container image on AWS Lambda, 2048 MB, 60s timeout, Python 3.12 on AL2023, behind an HTTP API Gateway. The trained ML artifacts are baked into the image so cold starts do not pay a model-download tax. The registry is ECR.

Data

Amazon DynamoDB is the primary datastore: about 30 tables, on demand, CMK-encrypted, with TTL on transient state (idempotency keys, session nonces, hot audit records). The live queue is a GSI on hospital_id + created_at. Media lives in S3 with presigned delivery and public access blocked.

Security and compliance

Because it is healthcare:

One CMK (alias/solace) encrypts every DynamoDB table, the media bucket, the CloudTrail bucket, and Secrets Manager.
WAFv2 on CloudFront runs Amazon IP Reputation, Known Bad Inputs, the OWASP Common Rule Set, and a rate-based rule capped at 50,000 requests per 5 minutes per IP (tuned for hospital NAT). Shield Standard is on.
Every AI call routes through AWS Bedrock, Transcribe, and Polly, all covered by the AWS Business Associate Agreement, so no patient data leaves the BAA boundary and there are no separate vendor BAAs to chase.
Clinicians authenticate by SMART-on-FHIR (OAuth + PKCE) or a PIN. IAM is least-privilege with an MFA permission boundary.

The point of the architecture is that a managed-service stack lets a small team ship something HIPAA-grade that still scales, rather than choosing between fast and real.

I created this content for the purposes of entering the H0: Hack the Zero Stack hackathon. #H0Hackathon

Designing DynamoDB for an emergency department (access patterns first)

Dhruv Jain — Mon, 29 Jun 2026 05:56:33 +0000

I built Solace, an AI-native patient intake and triage app for emergency departments, on Amazon DynamoDB and Vercel. This post is about the part that's easy to get wrong: the data model.

Why DynamoDB for an ED

An emergency department is the textbook DynamoDB workload. Traffic is bursty and unpredictable (a quiet floor, then six ambulances, then quiet again). Reads have to be single-digit-millisecond because the live patient queue refreshes on every arrival and a clinician is staring at it. And the access patterns are known in advance: look a patient up by id, a queue up by hospital, an encounter up by patient. That is exactly the shape DynamoDB is built for, and exactly the shape a relational database punishes you for under load.

Access patterns first, schema second

I did not drop a normalized relational schema into DynamoDB. I listed every read the product actually performs, then built a deliberate multi-table design around them. About 30 tables, all on demand (PAY_PER_REQUEST) so I never plan capacity, all encrypted with one customer-managed KMS key.

The most important one:

solace-patients: partition key patient_id, plus a GSI on hospital_id (hash) and created_at (range).

That single GSI is the live queue. Query by hospital, sorted by arrival time, in milliseconds. The clinician cockpit reads it on every refresh.

Three decisions that mattered

Exactly-once intake without transactions. A patient on a flaky waiting-room connection will double-submit. Instead of a distributed transaction, the client sends a stable idempotency key and I store it in a TTL'd solace-idempotency table. The same key lands once and returns the cached response on a retry. The TTL evicts the record after 24 hours, so there is no cleanup job.
Self-expiring sessions. solace-intake-nonces uses DynamoDB TTL as the session lifetime. The database is the garbage collector.
Append-only audit, hot and cold. solace-audit-log is write-only with a 90-day TTL for hot access, and every record is also archived to S3 as CMK-encrypted JSONL with a lifecycle transition to Glacier, which is how I meet the HIPAA six-year retention requirement.

The Vercel half

The patient intake SPA and the clinician terminal deploy on Vercel as static, edge-cached shells that talk to the AWS backend (FastAPI on Lambda in front of DynamoDB). Fast to load on bad hospital Wi-Fi, atomic branch-based deploys.

The payoff: the live queue and the EHR match return in single-digit milliseconds with zero capacity planning, and the design scales from one ED to many hospitals by adding partitions, not by re-architecting.

I created this content for the purposes of entering the H0: Hack the Zero Stack hackathon. #H0Hackathon