PrimeMaxing

What

An AI-driven health analytics platform that interprets blood biomarker data — organ-system scores, diagnostic visualization, and personalized recommendations — with multi-tenant infrastructure for clinics, clinicians, and patients.

Why it was hard

The interesting part of the product (LLM analysis of lab results) and the dangerous part (PHI) want to live in the same place. Every architectural choice is really a choice about where patient data is allowed to exist.

What I decided

Split the system at the PHI boundary. The static frontend holds nothing; everything patient-shaped lives behind Cognito in Lambdas, DynamoDB, and one audited S3 bucket — and the clinical engine in that path runs on the Python standard library alone, zero dependencies.

What happened

Running a pilot deployment with a partner clinic onboarding initial patient users, and demoing to healthcare organizations for contract opportunities.

The boundary is the architecture

PrimeMaxing is a React 18 single-page app served from S3 + CloudFront, with auth through Cognito (OIDC) and a backend of purpose-specific Lambdas defined in CDK: presigned S3 uploads, PDF lab-report processing, and a clinical recommendation engine. The deployment splits cleanly into a public half and a PHI half, and the design work went into making that split hard to violate by accident.

The static side is exactly that — static. No patient data is ever rendered into it, cached by it, or logged through it. File movement uses presigned URLs, so lab reports travel browser-to-bucket without transiting an application server that could log them. Inside the boundary, a dedicated audit stack (CDK) wires CloudTrail data-event logging over the PHI bucket and the doctor–patient access-grants table, encrypted with a rotating KMS key — every read of patient data leaves a record.

The decision that looks strange until it doesn’t

The clinical recommendation engine — the Lambda that turns biomarker values into organ-system scores and supplement guidance — is written in pure Python standard library. Zero external dependencies. That is an unusual constraint to place on the most product-critical code, and it is deliberate: this is the one function that always touches patient data, so it is the one function where a compromised transitive dependency would be a reportable breach rather than a bad day. The supply chain for that code path is the Python interpreter, full stop. It also keeps cold starts small and makes the engine trivially testable — the pytest suite runs against plain functions with no cloud in the loop.

LLMs near PHI

The LLM layer follows the same rule: models see sanitized inputs, not identities. Persistent-memory chat is built on context injection over MCP with PII stripped before anything reaches a model, and prompt changes are gated by LLM-as-judge regression testing — a change to the analysis prompt has to beat the incumbent on a scored evaluation set before it ships. Treating prompts like code, with tests, is what makes it safe to iterate on the medically interesting part quickly.

Multi-tenant clinics

The platform is multi-tenant from the schema up: clinics are tenants, clinicians get scoped access to their patients through explicit access grants (the same table CloudTrail watches), and patient users see only themselves. The pilot clinic runs on the same infrastructure as individual users — no fork, no special case.

This page is architecture and design reasoning only — no patient data, no screenshots of patient data, by rule. The live demo runs on synthetic data.