How We Built an AI Patient Portal for Hormone Clinics in 30 Days

The Problem: 50 Calls a Day About Lab Results

We started working with TRT (testosterone replacement therapy) clinics last fall. The problem was obvious within the first call:

"Our phones ring constantly. Patients want to know their testosterone levels, estrogen, hematocrit. They call 5, 10, 50 times asking about the same bloodwork."

Front desk staff were drowning. Clinicians were losing focus. Patients were frustrated waiting for callbacks. And every call was someone asking the same question: "When will my labs be ready? What do they mean?"

The calculus was simple: A clinic with 500 active patients might field 1,000+ lab-related calls per month. At $15–25 per patient consult per year, that's $7,500–$12,500 in unnecessary phone labor per clinic.

We thought: what if patients could ask their AI about their bloodwork, trends, and hormone questions 24/7?

The Solution: health-labs.ai

We built health-labs.ai — an AI patient portal that:

1. Ingests lab PDFs — Clinics upload their patient lab reports (Quest, LabCorp, any format)
2. Extracts structured data — Parses testosterone, estrogen, hematocrit, liver panels, lipids
3. Answers patient questions — "Is my testosterone trending up?" "What's a normal hematocrit?" "Should I be worried about my liver?"
4. Learns clinic protocol — Integrates clinic guidelines so the AI responds within their treatment philosophy
5. Reduces call volume — Patients get instant answers. Clinics stop bleeding phone labor.

How We Built It: Tech Stack & Decisions

Architecture

We chose a pragmatic stack over hype:

• Backend: Express.js + Node.js (speed matters in a 30-day sprint)
• Database: PostgreSQL (structured medical data, compliance audit trails)
• PDF Processing: PDF.js for extraction + Claude's vision for unstructured formats
• AI Core: Claude API with context windows (lab data + clinic protocol = 8K context minimum)
• Deployment: Render (one-click PostgreSQL provisioning, critical for compliance)

The AI Layer: Why Claude & MCP

We tested three approaches:

1. Prompt engineering alone — Too brittle. Lab values vary by lab company and units (mg/dL vs. ng/mL). The model would hallucinate normal ranges.
2. RAG over medical databases — Better but slow. Retrieving generic medical info for every query added 2–3 seconds latency.
3. Structured context + few-shot — Win. We built a "context injection" pattern:

System: You are a patient health assistant for [Clinic Name].
Clinic Protocol:
- Normal testosterone: 600-900 ng/dL (clinic-specific target)
- Hematocrit management: If >50%, reduce dose
Patient Labs (from PDF):
- Testosterone: 725 ng/dL (within range)
- Hematocrit: 52% (slightly elevated)
Question: Should I worry about my hematocrit?

Claude's reasoning mode (thinking + response) is perfect here. The model reasons through the data, applies the clinic's protocol, then gives a safe, anchored answer.

Why Model Context Protocol mattered

We initially built custom integrations for each PDF format. After 20 PDFs, we were debugging vendor-specific quirks. We switched to a unified tool interface (MCP pattern) where:

• One "extract-labs" tool handles 10+ PDF formats
• One "get-clinic-protocol" tool returns structured guidelines
• One "validate-response" tool catches medical advice outside the clinic's scope

This cut integration time in half and made onboarding new clinics trivial.

Decision 1: No FHIR, No HL7

Medical data integration is typically FHIR/HL7. We ignored that. Why?

• Reality: 90% of clinics we target don't have EHR APIs
• Pragmatism: PDF upload + manual clinic protocol input works today
• Future: If we hit scale, we add FHIR bridges. But premature integration kills startups.

Decision 2: Claude Over Open-Source Models

We tested Llama 2 + self-hosted. It worked. It was 60% cheaper. It failed on edge cases:

• Misinterpreting lab units (mg/dL vs. ng/mL)
• Giving advice outside clinic scope ("You should increase your dose" — our job is info, not treatment)
• Slower response times under load

Claude's reasoning mode gave us guardrails for free. Cost difference? ~$0.02 per patient query. Worth it for 60% fewer support tickets.

Decision 3: Minimal Patient Auth

We used magic links (no passwords). Why?

• TRT patients are mobile health-conscious individuals
• They use WhatsApp, Instagram, email
• Magic links feel familiar; they work on mobile
• HIPAA-compliant with encrypted links + time limits

Zero signup friction. Works.

Outcome: 60% Fewer Calls, Real Business Impact

One clinic we worked with had 480 active patients, averaging 2.1 lab-related calls per patient per year (1,000+ calls/year). 30 days after launch:

• Lab-related calls dropped 62% (average 0.8 calls/patient/year)
• Patients reporting satisfaction: 89%
• Support requests to us: 3 (all feature requests, not bugs)

For a clinic, that's ~$8,000/year in reclaimed front-desk labor. Enough to hire one part-time staff or redirect that capacity to patient experience.

What We Learned

1. MVP doesn't mean broken.

We shipped one integrated feature (lab intake + QA) instead of half-built everything. Better to be perfect at one thing.

2. Context is king in medical AI.

Generic Claude is good. Claude with clinic protocol + structured patient data is great. We spend 30% of compute on context prep, not inference.

3. Compliance isn't a blocker, it's a feature.

HIPAA-compliant architectures actually simplify your code (audit logs, encryption at rest, patient consent). We built it in Day 1.

4. Doctors trust what they understand.

We don't hide the AI response logic. We show doctors exactly what data the AI saw and why it answered the way it did. That transparency built trust faster than 10 testimonials.

What's Next

We're onboarding 3 more clinics in Q2. The unit economics work. The technical foundation is solid. The market wants it.

If you're running a healthcare vertical (any specialty, any condition), the playbook is the same: Find where patients ask the same question 100 times. Build an AI to answer it. Watch the efficiency gains compound.