How to build a telehealth platform, Part 2: designing intake

What intake is for

A clinician reviewing an asynchronous case has four questions: is this the person they say they are and have they consented; is the treatment appropriate for them; is anything present that makes it unsafe; and is there enough documented to meet the standard of care. Intake exists to answer those four questions, in that order, with no gaps. Everything else — tone, brand, illustration — is in service of getting complete, honest answers.

The design failure is treating intake as a form to be completed rather than an instrument to be read. Forms optimize for completion; instruments optimize for the reader. A clinician who has to reconstruct a history from free text takes minutes and asks for more information; one who reads a structured case decides in seconds. That difference, multiplied by every encounter, is the throughput of your program.

The anatomy of a good intake

Branching: ask only what this patient needs to answer

Branching is how an intake stays short and stays complete at the same time. A patient who reports no medications should not see a list of interaction questions; a patient who reports a history of pancreatitis in a GLP-1 intake should see follow-up questions immediately — and the protocol may route them to a live visit before they finish. The branches come from the protocol: each catalog treatment has a defined set of exclusion criteria and follow-ups, and the intake schema encodes them.

• Gate questions first. The two or three answers that most often exclude a patient (pregnancy, a specific history, a specific medication class) go early, so ineligible patients learn quickly and clinicians never see cases that could not proceed.
• Follow-ups attach to the answer that triggered them. The clinician should see the branch that was taken, not just the leaf answers.
• Red flags do not wait for the end. Protocol-defined answers escalate immediately — to a live visit, to emergency guidance, or to a decline with a reason — with the intake so far preserved.
• Every path ends in a complete case. Branches remove irrelevant questions; they never remove required ones.

Validation at the API boundary

Validate twice. In your interface, for the patient’s experience — inline, forgiving, with clear copy. At the API boundary, for the clinician’s — strict, schema-driven, and impossible to bypass. On Lithos an encounter’s intake_data is validated against the required keys configured for your organization at onboarding, so a case missing a required element is rejected with a 422 — one error per failing field — before it enters a physician’s queue rather than pausing later as escalated with patient_information_required.

POST /v1/encounters
{
  "patient_id": "pat_test_01HX9N4K8RBGFYPQ7T2VDSCMWZ",
  "encounter_type": "initial",
  "intake_data": {
    "height_inches": 65, "weight_lbs": 210,
    "current_medication": "metformin 500mg twice daily",
    "allergies": "sulfa",
    "medical_history": "type 2 diabetes since 2020, controlled",
    "pregnancy_status": "not_applicable",
    "contraindication_mtc": false, "contraindication_men2": false, "contraindication_pancreatitis": false
    // …the branch this patient took
  }
}
// 422 { "errors": [ … one per failing field … ] } if a required key is missing — nothing reaches a physician

Enumerations over free text wherever the clinical meaning allows. “Yes / No / Not sure” beats a text box; a coded medication list beats “I take a blood pressure pill.” Free text still has a place — the patient’s own description of the goal is clinically useful — but it is a supplement to structure, not a substitute.

What to leave to the visit

Not everything belongs in intake. Nuanced questions where the answer depends on a conversation, anything the patient is likely to misunderstand, and anything the state requires a clinician to ask live all belong to the encounter itself. The clinician can message the patient, request a photo, or convert to a synchronous visit; an intake that tries to pre-empt all of that becomes long, and long intakes get abandoned or answered carelessly. The rule: intake collects what the protocol requires and what a patient can answer reliably alone. The clinician handles the rest.

Never ask twice

The second-biggest intake mistake after treating it as a form is treating every encounter as the first. A renewal should open with the record already populated — history, medications, allergies, prior decisions — and ask only what changed: weight, side effects, adherence, anything new. This is where the patient record earns its keep, and where agent-run check-ins shine: a well-structured follow-up takes ninety seconds and lands in front of the clinician as a diff against the last visit. See refilling medication with AI.

Measuring intake

• Completion rate, by step. Where patients leave tells you which question is unclear or intrusive.
• “Needs more information” rate. The share of encounters a clinician sends back. Above a few percent, the schema is missing something the protocol needs.
• Time to decision. From submission to the clinician’s signature. Structured intakes move this from hours to minutes in async programs.
• Escalation rate. Red flags caught by the intake versus by the clinician. Higher is better; it means the branches are doing their job.

Frequently asked questions