--- title: Patient Forms | Avara description: Build customizable patient intake forms with the Operations form builder — components, conditional logic, flags, and skim viewing. --- ## Overview Patient forms power digital intake, consent, and pre-visit questionnaires. Forms are built and maintained in **Operations** using the **form builder** — a drag-and-drop editor where you assemble questions, layout, and logic without writing code. Once a form is published, attach it to an [appointment type](/clinical-platform/appointment-types/#intake-forms/index.md) so patients can complete it after their appointment is booked (or during check-in on [office tablets](/clinical-platform/office-tablets/index.md)). ## Form Builder The form builder lives under **Operations**. Open an existing form or create a new one, then drag components onto the canvas and reorder them as needed. You can move any top-level block freely, and for **multiple choice** and **select all that apply** questions you can reorder individual answer options within the list. ## Form Components Avara form building is built from a set of **form component primitives**. Each type exists to capture a specific kind of patient input or improve how the form reads on screen. ### Input Components **Short response** Single-line text for brief answers — names, dates, phone numbers, or short free-text responses. Use when you expect a word or phrase, not a paragraph. **Long response** Multi-line text for narrative answers — symptom descriptions, medical history details, or open-ended comments. Use when patients need room to explain in their own words. **Multiple choice** A list of options where the patient selects **one** answer. Ideal for branching logic, categorical questions, or forced single selections (for example “Have you been diagnosed with cancer?” → Yes / No). **Select all that apply** A list of options where the patient can choose **multiple** answers. Use for checklists — current medications, prior procedures, or symptoms that may overlap. **Signature** Captures the patient’s electronic signature for consents, acknowledgments, and policy agreements. Required for forms that need a documented attestation before submission. ### Layout and Aesthetics **Header** Section titles that break long forms into scannable blocks — for example “Medical History” or “Insurance Information.” Headers improve readability without collecting data. **Description** Instructional or explanatory text between questions. Use descriptions to clarify what you’re asking, provide examples, or set expectations before the patient answers. **Image** Embedded images for branding, diagrams, or visual instructions (for example anatomical references or office wayfinding). Images make forms clearer without adding answer fields. ## Conditional Questions Conditional logic keeps forms **brief on the surface** while still capturing **detailed information when it matters**. When a patient answers a question a certain way, follow-up questions can appear based on that response — and those follow-ups can nest as deeply as you need. Patients only see the branches that apply to them. **Example:** “Have you been diagnosed with cancer?” - **No** → No follow-up; the form moves to the next top-level question. - **Yes** → “What type?” (select all that apply) → For each type selected, show specific questions about that diagnosis (treatment history, dates, ongoing care, and so on). This pattern avoids overwhelming every patient with every question while still supporting complex clinical intake when answers warrant it. ## Required Questions Mark individual questions as **required** when an answer is mandatory before the patient can submit the form. Required fields ensure critical data — consents, identifiers, safety screens — is never skipped accidentally. Patients cannot submit until all required questions are answered. ## Flag Answer for Operations Flag answers when a specific response should **stand out to your team** without someone reading every submission line by line. If a patient answers a flagged question in the configured way, the response is highlighted in the **calendar** and in the patient’s **forms** view for staff. Care coordinators and front-office staff see important information at a glance — allergies, high-risk history, urgent symptoms — improving operational efficiency and reducing missed context. **Patients are not notified that an answer was flagged.** Flags are internal operational signals only — they do not appear when a patient views their own completed form in the patient portal. ## Form Viewer Staff review completed forms in the **form viewer**. **Skim mode** shows only questions the patient answered, hiding unanswered branches and empty fields. Skim mode makes intake review much faster when you only need the relevant responses. Staff can **turn skim mode off** at any time to view the **entire form**, including questions the patient skipped and all answer choices that were presented. **Flags** appear in the staff form viewer (full and skim views) so your team can spot flagged answers quickly — they are never shown to the patient. ## Assigning Forms to Appointments After you build a form in Operations, attach it to one or more [appointment types](/clinical-platform/appointment-types/#intake-forms/index.md). Patients receive the form to complete once their appointment is booked — reducing day-of paperwork and ensuring intake is done before they arrive when your workflow allows. You can assign different forms to different appointment types so each visit category collects the right information.