Intake Forms

Patient onboarding forms for GLP-1, NAD+, and Microdose products.

Overview

YourEra operates three separate React SPA intake forms, each tailored to a specific product line. All three are hosted on CloudFront/S3 at intake.hisera.com with product-specific paths.

Deployment

Infrastructure

Architecture (Per Intake)

┌───────────────────────────────────────┐
│  intake.hisera.com (CloudFront + S3)  │
│  React SPA (Vite)                     │
└────────────┬──────────────────────────┘
             │
┌────────────▼──────────────────────────┐
│  intake-api.hisera.com (ECS)          │
│  Intake Gateway                       │
├───────────┬───────────┬───────────────┤
│  Stripe   │  Canvas   │  Google       │
│  Payment  │  Patient  │  Places       │
│  API      │  Creation │  Autocomplete │
└───────────┴───────────┴───────────────┘

GLP-1 Weightloss

The GLP-1 intake is the primary product intake with 19 steps. It collects patient demographics, medical history, body metrics, and payment information for Semaglutide and Tirzepatide prescriptions.

Step Flow (19 Steps)

NAD+ Wellness

The NAD+ intake is a 23-step form for the NAD+ 200 mg/mL subcutaneous injection wellness protocol. It includes unique screening steps for G6PD deficiency, CKD, and cancer treatment history that are not present in the other intakes.

Unique Steps

• G6PD/CKD Screening — Screens for glucose-6-phosphate dehydrogenase deficiency and chronic kidney disease (contraindications)
• Cancer Treatment — Active cancer treatment screening (contraindication for NAD+)
• Informed Consent — Detailed consent for subcutaneous injection protocol
• Primary Reason — Why the patient is seeking NAD+ therapy (anti-aging, energy, cognitive, etc.)
• Symptoms — Current symptoms that NAD+ may address

Product Details

Microdose

The Microdose intake is a 22-step form with unique medication preference selection and a diabetes medications disqualifier step.

Unique Steps

• Diabetes Medications — Screens for current diabetes medications (disqualifier for microdose program)
• Medication Preference — Patient selects their preferred medication form factor

Shared Steps

The remaining steps follow the same pattern as the GLP-1 intake: account creation, demographics (DOB, sex, phone), address with autocomplete, payment checkout, medical history questions, ID upload, and confirmation.

Payment

All three intakes use Stripe for payment processing. The checkout step uses Stripe's PaymentElement (embedded, not redirect) to collect card details and create a SetupIntent that saves the card for future charges.

Payment Flow

1. Intake frontend requests a SetupIntent from the Intake Gateway
2. Stripe PaymentElement renders in-page for card collection
3. Patient enters card details and confirms
4. Card is saved as a Stripe PaymentMethod attached to the customer
5. PaymentMethod ID is stored in the Integration Service payment_holds table
6. Card is charged later when the prescription is approved (via orchestrator)

Discount Codes

Patients can enter a discount code during checkout. The code is validated against Stripe coupons via the POST /validate-coupon endpoint on the Intake Gateway. The coupon ID in Stripe must match the code the patient enters.

Authentication

The intake forms support two authentication methods for the account creation step. The deployed (production) version and development version use different providers.

Production (Deploy Repo)

• Google OAuth — Google Sign-In for one-click account creation
• Email OTP — Email verification code for non-Google users

Development (Dev Repo)

• Clerk — Clerk authentication provider for local development

Draft Persistence

All intake forms implement client-side draft persistence using localStorage. Patient progress is saved automatically as they fill out the form, so they can resume later if they close the browser.

Implementation

• Debounced Save — Form state is saved to localStorage with a 1-second debounce to avoid excessive writes
• beforeunload Flush — A beforeunload event handler flushes any pending debounced save to ensure data is preserved on page close
• Local useState — Each field uses local useState with a generation counter to handle async state correctly
• Debounced Fetch — Address autocomplete uses a 300ms debounced fetch to avoid excessive Google Places API calls

Debounce Utility

// utils/debounce.js
export function createDebouncedFn(fn, ms) {
  let timer;
  const debouncedFn = (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), ms);
  };
  const cancelFn = () => clearTimeout(timer);
  return [debouncedFn, cancelFn];
}

ID Verification

The ID upload step supports multiple methods for capturing and verifying government-issued identification. The system attempts barcode scanning first, falls back to OCR, and allows manual upload as a last resort.

Verification Methods

1. PDF417 Barcode Scan — Uses zxing-wasm to scan the PDF417 barcode on the back of US driver's licenses. This is the fastest and most accurate method.
2. OCR Fallback — If barcode scanning fails, tesseract-wasm performs optical character recognition on the ID image to extract text fields.
3. Manual Upload — If both automated methods fail, the patient can manually upload a photo of their ID. OCR is attempted on the uploaded image.

Extracted Fields