Healthcare Patient Intake Forms

Most clinics still hand new patients a clipboard. Forms get filled badly, scanned later, retyped into the EHR, and the appointment starts cold. A digital intake form replaces the clipboard with structured data — insurance, medications, medical history, reason for visit — gated by patient identity, saved as a draft if the patient steps away, and waiting in the chart before the appointment starts.

This guide walks through a working 6-page FlexForm intake setup: login_page with email OTP, identity, insurance with insurance-card upload, medical history with conditional follow-ups, current medications, and reason for visit. Every element type referenced exists in the FlexForm schema today. Where the practice needs to think carefully — HIPAA scope, BAA, data residency — the post calls that out honestly rather than overclaiming.

The 6-page structure

Single-page intake forms feel short on the screen but punish the patient who needs to pause. Six pages, each with a clear purpose, make partial saving feel natural and let the patient finish on the second sitting without losing context.

Step 1 — Generate the form

The AI generator handles the heavy lifting. A workable prompt:

"Create a 6-page patient intake form:
 page 1 - login page, email OTP
 page 2 - full name, DOB, phone, home address
 page 3 - insurance carrier, policy number,
          upload front of insurance card
 page 4 - medical history checkboxes: diabetes,
          hypertension, asthma, heart disease,
          cancer history, allergies. For each
          ticked condition, ask for diagnosis year
          and current medication.
 page 5 - current medications (free text),
          allergies (checkboxes + other)
 page 6 - reason for today's visit, review screen
Turn on partial saving."

The AI picks login_page for page 1, checkboxes for the history conditions, and adds long_answer follow-ups gated by element-level conditional rules — each follow-up only renders when its parent checkbox is ticked. Conditional rules use the contains operator on the checkboxes value.

Step 2 — Configure the login_page (email OTP)

FlexForm's login_page element supports two auth methods: Google OAuth and email OTP. For a public-facing patient intake, email OTP is the right default — patients enter their email, receive a six-digit code, and verify before the rest of the form opens.

The verified email becomes the session's user_email and travels with the submission record. If the patient returns later from a different device, signing back in with the same email resumes the same draft — getOrCreateAuthSession reuses the existing draft instead of starting a new one.

Step 3 — Insurance card upload

The file_uploader element opens the platform's native picker — on iOS and Android phones it launches the camera or photo library; on desktop it opens the file dialog. Patients can capture a photo of their insurance card directly without leaving the form.

Per-file size limit comes from the plan:

Step 4 — Medical history with conditional branches

The medical-history page is where intake forms go wrong: ask too little and the provider walks in cold; ask too much of every patient and completion craters. Conditional branches give every patient the short version unless they tick something that needs detail.

The pattern: a single checkboxes element listing chronic conditions, with a long_answer element per condition that is hidden by default and shown only when its parent checkbox is ticked. Conditional rules use the contains operator:

history_checkboxes → contains "Diabetes"   ⇒ show "Diabetes details"
history_checkboxes → contains "Hypertension"⇒ show "Hypertension details"
history_checkboxes → contains "Asthma"     ⇒ show "Asthma details"
history_checkboxes → contains "Other"      ⇒ show "Other condition details"

A healthy patient ticks nothing, sees four fewer fields, and completes the page in 15 seconds. A patient with two ticked conditions answers exactly the two follow-ups the provider needs. The conditional rules evaluate client-side so the form behaves the same way in the web embed, the public hosted URL, and the mobile SDK.

Step 5 — Partial saving and the 30-day window

Patients fill intake forms in awkward moments — in a waiting room, between meetings, while a kid is napping. Partial saving turns the form into something they can finish over two sittings without losing state.

With enablePartialSaving: true on the form settings, every page navigation writes the answers to the form_sessions row, indexed by the authenticated email. The session lives for 30 days, then expires. The submission record only appears on the form_submissions table after the patient hits Submit on the review page — the two tables are separate by design so the provider sees only finalized intake, not abandoned drafts.

A note on HIPAA

FlexForm is a structured data-capture and form-rendering tool. It is not, by itself, the answer to whether a workflow is HIPAA-compliant. HIPAA compliance depends on the full handling of Protected Health Information: where the database is hosted, who has access, what Business Associate Agreement is in place with each vendor, how data is transmitted to the EHR, and the practice's downstream policies.

Practices intending to handle PHI through any form tool — FlexForm included — should review the platform's data-residency and BAA options on the Enterprise plan and confirm the full chain with their compliance counsel before going live. Don't take an SEO blog post's word for it on a regulatory question; verify with the vendor directly.