Verified against ChatGPT · 2026-08-14
Draft a telehealth intake form's questions so triage staff get answers they can actually act on
Builds the question set and branching logic for a telehealth intake form for one specific visit type, structured so answers are specific enough for triage staff to act on, with an explicit note that clinical staff must approve the final form and its urgent-symptom routing before it goes live.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are drafting the question set for a telehealth intake form for one specific visit type. The form needs to produce answers precise enough for triage staff to act on, not vague enough that a nurse has to call the patient back to ask what they actually meant.
VISIT TYPE
Same-day telehealth visit for a new skin rash.
WHAT TRIAGE STAFF NEED TO KNOW TO ROUTE THIS CORRECTLY
Need to know rash location, spread rate, whether there's fever, and whether the patient has any known allergy history.
SYMPTOMS OR SITUATIONS THAT SHOULD TRIGGER AN URGENT FLAG
Difficulty breathing, swelling of the face or throat, rash spreading rapidly within hours, or high fever.
EXISTING FORM FIELDS TO KEEP (if any)
Keep the existing insurance and pharmacy fields unchanged.
PATIENT POPULATION
General adult population, form needs to be usable on a phone, some patients may be filling it out for a child.
RULES
Write each question so the possible answers are specific enough to act on — prefer a structured choice (severity scale, duration bucket, yes/no with a specific follow-up) over an open free-text box for anything triage staff need to make a routing decision from, and reserve free text for things that genuinely can't be pre-structured ("anything else we should know"). Build explicit branching: state which answer to which question should trigger the urgent-flag path, and write the on-screen message the patient sees when that path triggers, directing them to call emergency services or a specific urgent line rather than simply submitting the form and waiting. Order the questions so anything relevant to the urgent-flag criteria appears early, not buried after a long series of demographic or insurance questions, so a patient in real distress doesn't have to complete unrelated fields first. Do not write a question that requires the patient to already know clinical terminology to answer correctly — describe what to look for in plain terms, not the name of the sign a clinician would use for it.
WHAT NOT TO DO
Do not write questions or branching logic that would let the form itself render a diagnosis or a treatment recommendation to the patient — the form's only job is to gather structured information and flag urgency; every non-urgent path should end in "this will be reviewed by your care team," not a suggested diagnosis or plan.
MANDATORY DISCLAIMER
Add a line, both to the practice and as on-screen text for the patient, stating that this intake form does not replace an emergency evaluation, that anyone experiencing a flagged urgent symptom should seek immediate care rather than waiting for form review, and that the full question set and urgent-flag logic must be reviewed and approved by clinical staff before this form is used with real patients.
OUTPUT FORMAT
1. The disclaimer.
2. The ordered question list, each with its answer format (structured choice options listed, or free text).
3. The branching logic table: trigger answer -> urgent flag -> patient-facing message shown.
4. A short note to clinical staff on what they specifically need to review before go-live.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Intake forms fail operationally in a specific, well-known way: open-ended free-text fields produce answers too vague for triage staff to act on directly, forcing a callback loop that defeats the purpose of an intake form in the first place — forcing structured-choice answers wherever a routing decision depends on the response, and reserving free text for genuinely unstructured information, is what closes that gap. Requiring explicit branching logic with a stated patient-facing message at the urgent-flag trigger matters because a form that silently "flags" something in a back-end field without telling the patient what to do next leaves a person with a real emergency sitting at their screen waiting for a callback instead of calling for help immediately, which is the actual harm this kind of form exists to prevent. Ordering urgent-relevant questions early rather than after routine demographic fields is a direct fix for a common form-design mistake: a patient in genuine distress filling out ten fields about insurance before reaching the question that would flag them is a real, documented failure pattern in badly sequenced intake forms. The instruction against clinical terminology in the questions themselves keeps the form usable by the patient population it's actually written for, since a triage question phrased in clinical language will get inconsistent, sometimes wrong answers from patients who don't recognize the term. The explicit ban on the form rendering any diagnosis or treatment suggestion is the safety-critical rule — an intake form's entire legitimate function is structured information-gathering and urgency flagging, and any drift toward the form appearing to offer clinical judgment on its own would mislead a patient about what they're interacting with, which is why clinical sign-off on the final logic is stated as mandatory before real use.
What you get back
Q3: Is the rash spreading noticeably within the last few hours? (Yes / No / Not sure) -> If Yes, and combined with reported facial or throat swelling, trigger urgent flag. Patient-facing message on trigger: "Based on your answers, this may need immediate attention. Please call 911 or go to the nearest emergency department now rather than waiting for this form to be reviewed."
Verified against
ChatGPT GPT-5.1 · 2026-08-14
Changelog
- 2026-08-14 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
