The first three posts in this series were about the things that almost broke the practice and the architecture I'd build if I were starting today. The next seven posts are component-by-component walkthroughs of what that architecture actually looks like, starting with the part of the application that prospective patients touch first.
I call it the patient pipeline. It's the sequence of states a person passes through between the moment they click on a marketing page and the moment they become a patient who has had their first visit with me. There are five states in the pipeline as it currently exists, and most of what I do as a solo doctor depends on the pipeline working without me having to intervene at each step. When it does work, I spend my time on clinical care. When it doesn't, I spend my time on the phone with people who almost became patients and didn't quite get through the funnel.
This post is what I learned about each of the five states, in the order they happen.
The five states
A prospective patient at any given moment is in one of these states with respect to the practice:
- Visitor. They've landed on a marketing page (probably a city page, probably from a Google or AI-search referral, sometimes from a blog post). They have not yet identified themselves in any way.
- Eligible lead. They've filled out an eligibility form indicating they're interested and meet the practice's criteria (within service area, willing to pay out-of-pocket, looking for the kind of care I provide).
- Authenticated user. They've completed magic-link authentication and have an account in the database. Their email is verified. They have not yet booked.
- Onboarded patient. They've completed the intake questionnaire (medical history, medications, insurance for outside-the-practice services, emergency contact). They have a chart in DrChrono. They can self-schedule their first appointment directly into the calendar from this state.
- Active patient. They've had their first visit. The relationship has begun.
Each transition between these states is a separate piece of software. Each transition has a drop-off rate that's measurable, fixable, and worth measuring. The pipeline metaphor is useful because it makes the drop-offs visible. Without the metaphor, you tend to think of the application as "the patient portal" and you stop seeing the people who never got into the portal in the first place.
Eligibility
The eligibility form is the first place a prospective patient identifies themselves. It's also the place where the practice's real screening happens, before any clinical contact, before any time is spent on either side.
Eligibility for a telehealth psychiatry practice is not a marketing decision. There are specific criteria a prospect has to meet for the practice to be the right fit and for the practice to be able to legally and operationally take them on. Geography matters more than in most healthcare contexts: telehealth psychiatry is regulated state by state, and I'm licensed only in Florida and New Jersey, so a prospect in any other state is an automatic disqualification regardless of how good a fit they are clinically. Payment model matters: the practice is private-pay, and a prospect expecting insurance coverage for the visits themselves is not someone I can serve well within this model. Clinical fit matters in a way that's specific to psychiatry: a prospect in an acute crisis (active suicidal ideation, current psychosis, severe substance use) needs a higher level of care than outpatient telehealth can safely provide, and the eligibility form has to surface that distinction before they invest time in a relationship that can't actually treat them. Each of these criteria translates into questions on the eligibility form, and the form is long because the criteria are real.
The temptation in any conversion-optimization conversation is to shorten the form. For a marketing funnel that's the right move; for an eligibility funnel it isn't. The point of the eligibility form is to determine eligibility. If a prospect drops off because the form is asking real questions about whether they're a fit, that drop-off is correct. The wrong outcome is not a long form. The wrong outcome is a short form that lets unfit prospects through into the next stage of the pipeline, where they consume staff time on the way to discovering they were never eligible in the first place.
What's worth optimizing in the eligibility form is the experience of filling it out, not the length. The questions should be grouped in a way that respects the prospect's time. The hard-disqualifier questions go first: state of residence, presence or absence of an acute crisis, basic age-and-suitability check. If a prospect is in a state I'm not licensed in, I'd rather they find that out on the first screen than after they've typed their name and phone number. The same logic applies to the safety screen: a prospect in active crisis needs to be routed to a higher level of care immediately, not led further into a funnel that can't help them. Clinical context questions come next, with microcopy explaining why each question is being asked. Identifying information (name, email, contact info) goes after the prospect has cleared the screening gates, so the data capture is on people who could actually become patients. The membership-model acknowledgment sits near the end as a single explicit checkbox, framed so a prospect can self-disqualify gracefully if private-pay isn't right for them. Conditional logic hides questions that don't apply based on earlier answers, so the form doesn't appear longer than it has to.
The submission lands in an EligibilitySubmission row in the database with the timestamp, the prospect's responses, their referrer URL (which marketing page they came from), and their landing page (where they entered the funnel). The row is the source of truth for the lead. From there, eligible leads enter an automated nurture sequence that walks them through next steps over a few days: a welcome email, a what-to-expect-at-the-first-visit explanation, a calendar link to start the magic-link signup, follow-ups if they don't act. The sequence is templated and time-triggered; the application records each lead, queues the right emails, and tracks which leads convert into signups. Almost no manual touch is required between submission and the moment a prospect lands on the signup screen, which is the only sustainable way to operate the funnel as inbound volume grows.
The lesson I want to communicate to other solo doctors is the opposite of the standard SaaS conversion-funnel advice. Don't shorten an eligibility form to chase a higher submission rate. The form is doing real work. Make it pleasant to fill out, make the questions clear, hide irrelevant ones with conditional logic, but don't cut the screening that lets you say yes or no responsibly when someone reaches out.
Intake
The intake questionnaire is the second piece of the pipeline, and the one I've spent the most engineering time refining for user experience.
The clinical content of intake has been roughly constant since launch. There are things I need to know before the first visit to make the visit useful: current psychiatric medications, prior medication trials and what worked or didn't, current and past mental health diagnoses, current substance use including alcohol and cannabis, suicide and self-harm history with a current safety screen, prior hospitalizations or higher levels of care, primary care physician and any other treating clinicians, pharmacy of choice, validated symptom inventories (PHQ-9 for depression, GAD-7 for anxiety, AUDIT-C for alcohol use), and emergency contact information. The list is comprehensive because psychiatric intake is its own kind of comprehensive; getting to know a patient well enough to prescribe and manage care safely requires this baseline. Cutting the intake to make it shorter would either move the work into the first visit (turning a 30-minute initial psychiatric evaluation into a 60-minute history-taking session) or leave gaps that show up as missed safety signals later.
What has changed substantially since launch is how the questionnaire feels to fill out. The clinical questions are the same; the experience around them has been rebuilt.
Early-version intake was a single long form on a single page. It worked but it was demoralizing to look at. Patients would scroll through, see how many questions remained, and put off completing it for days. Some would start and stop. Some would finish but only after a phone call from the front desk reminding them. The completion rate was acceptable but the experience was unforced and impersonal.
The current version splits the same content across a progress-tracked sequence of short steps. Each step focuses on one category (medications, allergies, conditions, etc.), takes one to three minutes, and shows the patient where they are in the overall flow. Progress is saved continuously, so a patient who closes the tab halfway through can return later and pick up where they left off. The flow is mobile-friendly, which matters more than it sounds because a meaningful percentage of intakes are completed on phones. Branching logic hides irrelevant follow-up questions (a patient who answers "no" to "do you have any chronic conditions" doesn't see the eight follow-up questions about which conditions). Microcopy throughout the flow explains why each question is being asked, which makes the patient feel like a participant rather than a subject of a screening.
The technical pattern is straightforward. The intake is modeled as a state machine in the database, with one row per patient capturing which steps have been completed. The front-end renders the current step based on that state. Each step submission updates the row. Once all required steps are complete, the patient transitions from "authenticated user" to "onboarded patient" automatically. The transition fires a webhook into DrChrono to create the chart, and the patient lands on a self-scheduling screen where they pick their own first-visit time from the calendar. No phone call required, no separate scheduling email back-and-forth. The patient who has just finished intake is the patient most likely to book in the next ten seconds; the calendar should be on the next screen.
Two things I'd reinforce for any solo doctor designing intake:
The clinical content should be the clinical content. Don't compromise medical thoroughness for UX. A first visit goes much better when the baseline history is already on the chart, because the conversation can start at "here's what I want to work on today" instead of "tell me about your medications, prior trials, and hospitalization history."
The experience around the clinical content is where almost all of the engineering value lives. Splitting steps, saving progress, hiding irrelevant questions, explaining why each question matters, mobile-first rendering — none of these change what's asked, but together they meaningfully change how patients feel about answering. Patients who feel respected by the intake experience tend to show up to the first visit ready to engage. Patients who feel processed by the intake experience tend to show up cautious.
Magic-link onboarding
The signup flow uses magic-link authentication, which I covered in post #3 as the right choice for a patient population that logs in once a month. The mechanics are worth describing in more detail here because there are a few non-obvious things that affect conversion.
The user experience is: prospect enters their email, the application sends a one-time signed link to that email, the prospect clicks the link, the application validates the link and signs them in. There is no password to set, no password to remember, no password to phish. The link expires after fifteen minutes and is single-use.
The implementation details that matter:
The link should land at the destination page directly, not at a "click to verify" intermediate. The temptation in many magic-link libraries is to send users through a generic "Email verified, click here to continue" page after they click. Don't. The point of the magic link is that the click IS the verification; making the user click twice is a regression. The link should validate in the URL handler and immediately render the post-signup state.
The email itself should be branded but minimal. A one-paragraph explanation of why they're receiving the email, a single clear call-to-action button, the link as a fallback text URL below the button. Nothing else. Add additional content (welcome packet, what-to-expect overview) to the post-signup page, not the email.
The "first browser to see this email is now trusted" pattern is worth thinking about. After the magic link is used once, that browser gets a long-lived session token. The next time the user comes back from the same browser, they don't see the signup flow at all; they go straight to the patient portal. This is the move that makes magic-link feel as good as a password for returning users. Without it, every return visit triggers another email round-trip, which is unacceptable friction.
The fallback for "first browser to see this" is a separate flow: a user who clears their cookies, or uses a new device, sees a "sign in by email" page that triggers a fresh magic link. The link works because their email is the durable identifier; nothing depends on the specific device session.
There is one operational consideration. The entire auth flow depends on email delivery working. If your email vendor (SES, in my case) has an outage, your users can't sign in. The hardcoded fallback pattern from post #3 is especially important here: SES as primary, a secondary provider (Resend, in my case) for the auth path specifically. The fallback is wired statically in the code so that the configuration database being down doesn't break sign-in.
Returning-patient detection
This is the part of the pipeline that's hardest to get right and that I still don't think I have completely solved.
A patient who has been with the practice for six months should not, when they come back to the marketing site to look something up or check their dashboard, be treated as a new prospect. They should be recognized, signed in, and routed to the patient portal directly. The pattern that makes this work is straightforward in theory: persistent session cookie, check on every page load, send them to the right destination based on their current state.
In practice, the patterns that break this:
A patient who comes back from a different device (their phone vs the laptop they signed up on) doesn't have the cookie. The application has no way to know they're a returning patient until they identify themselves. The most graceful handling is to give them a clearly visible "sign in" link in the header, separate from the "become a patient" call-to-action, so they don't accidentally start the new-patient flow.
A patient who clears their cookies (some patients do this regularly as a privacy practice) has the same problem. Same handling: the visible "sign in" link is the rescue.
A patient who has signed up but not yet completed intake is in a weird in-between state. They are not a prospect; they have an account. They are also not an onboarded patient. The application needs to handle this state explicitly. In my application, if an authenticated user lands on a marketing page, the navigation rewrites to show their progress through the funnel ("Welcome back! Continue your intake →") rather than the new-patient framing. The technical mechanism is server-side: the layout component checks the session, identifies the user's current state, and renders accordingly.
A patient who has been deactivated (left the practice, never reactivated) needs separate handling. If they come back and try to sign in, they should get a "your account is on hold; please call to reactivate" message rather than either being treated as new or being silently signed in. The deactivation state is one I added late and that I'd add earlier next time.
The principle is: every authentication-related state needs an explicit branch in the routing logic. The default assumption that "logged in or not" is the only useful distinction is wrong. There are at least six states (visitor, eligible lead, in-progress signup, authenticated-but-not-onboarded, onboarded, deactivated) and the right page to land on depends on which one.
Funnel metrics
There are five numbers that I check on the patient pipeline and that I think any solo doctor should track:
Visitor-to-eligible conversion (visits to the marketing site that result in an eligibility submission). This is the headline marketing number. The right rate depends heavily on how much screening the eligibility form is doing; a long form serving real criteria will convert at a much lower rate than a three-field SaaS signup, and that lower rate is fine. What you want to watch is the trend, not the absolute level.
Eligible-to-authenticated conversion (eligibility submissions that result in completing the magic-link signup). This is mostly about email follow-up timing and quality, plus the integrity of the email-delivery path. If this drops sharply, check email deliverability first; SES warmup issues or domain reputation can suppress this number without any other symptoms.
Authenticated-to-onboarded conversion (signups that complete the intake). This is mostly about the intake experience. Watch for drop-off concentrated at a single step in the sequence; that points at a specific question or screen that's causing friction.
Onboarded-to-active conversion (intakes complete that result in a first appointment booked and attended). This is mostly about scheduling friction and the perceived urgency of the first visit. If it drops, the post-intake handoff is broken or the calendar is unfriendly.
Time-to-first-visit (median days between visitor-state entry and first-visit completion). This is the most useful single operational number. For a practice with low friction and high readiness, this should be under two weeks. For a practice with appointment scarcity or a confused intake flow, it can stretch to months without anyone noticing. Watching the median move tells you whether the pipeline is getting tighter or looser.
Get the screening right, get the intake experience right, get the returning-patient routing right, and most of the rest takes care of itself.
Next time
The next post covers what happens after a patient becomes active: charts, encounters, prescribing, document management, the system-of-record question (DrChrono in my case, integrated with the application rather than parallel to it). That's the clinical core. It's the largest and most consequential piece of the application surface, and it's where the gap between "the doctor's mental model" and "what the software does" is most expensive to get wrong.