Patient Intake Software: Digital Forms, Consent and E-Signature

Patient intake software collects a patient's details, history, consent and insurance before the visit, through digital forms that change based on earlier answers. Off-the-shelf tools start around US$55 a month: IntakeQ's Forms Only plan is US$54.90. Build your own when intake is part of a product you sell, or when your workflow, integrations or audit needs go beyond a form tool.

If you would rather have it built for you, see how RAITHub would build this below.

What should patient intake software do?

Six jobs, and a tool that skips any of them pushes the work back onto reception staff.

Feature	What it does	What makes it hard
Digital intake forms	Demographics, history, medications, allergies, reason for visit	Mobile-first layouts, save and resume, accessibility for older patients and screen readers
Conditional-logic form builder	Staff edit questions and rules ("show this if that") without a developer	Versioning: an answer must stay tied to the exact form version the patient saw
Consent capture and e-signature	Treatment, privacy and financial consents, signed and stored	Proving who signed what text, when, and keeping the record unaltered
Insurance card upload	Front and back photos, member ID, payer	Image size and orientation on phones, malware scanning, storing files outside the public web root
Pre-visit reminders	SMS or email links to complete intake before the visit	Keeping health details out of the message text; patient contact preferences
Audit log of views	A record of who opened which patient's intake, and when	Logging reads, not only edits, on every screen and export

For the wider health engineering picture (HIPAA, GDPR, FHIR and patient portals), read our guide to building health software.

What do patient intake tools cost?

Form-first tools are cheap; full check-in platforms quote by demo.

Product	Published price	Notes
IntakeQ	Forms Only US$54.90/month; Practice Management US$84.90/month; low-volume plans from US$29.90 (IntakeQ pricing)	E-signatures, form reminders and a BAA on the forms plan; booking, client portal and claims on the practice plan
Jotform	Free, then US$39, US$49 and US$129/month (Jotform pricing)	HIPAA features are listed as available only from the Gold plan and on Enterprise
Phreesia	Not published; demo required (Phreesia)	Self check-in, benefits verification, copay collection and scheduling

Prices checked on 2 October 2026; confirm on each vendor's page. Note the Jotform row: a general form builder may need a higher tier before it is suitable for health data, so compare plans on the features you actually need, not the entry price.

Buy, build or hire?

Option	Examples	Choose this when	Watch out for
Off-the-shelf intake tool	IntakeQ, Phreesia, or the intake module of your practice management system	You run a practice and want intake live this month	Intake data sits in another vendor; check exports, API access and how it reaches your records system
No-code form builder	Jotform on a plan with health features	Your forms are simple, volumes are low, and staff will maintain them	Plan tier, data agreements, and logic that gets brittle as forms grow
Custom build	Your own web app or PWA with a form engine, e-signature and audit log	Intake is part of a product you sell, it must write into your own data model, or you need view-level audit and role rules a tool cannot give you	You own security, uptime, form versioning and support

Doing it yourself with a no-code builder: a competent office manager can set up a basic intake form, consent and reminder in 1–3 days. The main risk is not the form; it is where the data goes afterwards, and whether every vendor in that chain has the agreements your adviser requires.

How does a conditional-logic intake form work?

Each question can carry a rule that decides whether it is shown. The same rules must run on the server, because a browser can be bypassed: the server decides which questions were visible, rejects answers to hidden ones, and enforces required fields on the visible ones.

The TypeScript below is a minimal, dependency-free version. Rules may only reference earlier questions, which prevents circular logic and lets the server evaluate the form in one pass.

type Answer = string | number | boolean | string[]

type Condition =
  | { questionId: string; equals: Answer }
  | { all: Condition[] }
  | { any: Condition[] }

interface Question {
  id: string
  label: string
  type: 'text' | 'number' | 'yesno' | 'choice'
  required?: boolean
  options?: string[]      // for 'choice'
  maxLength?: number      // for 'text'
  showIf?: Condition      // may reference earlier questions only
}

interface IntakeForm {
  formId: string
  version: number         // answers are stored against this exact version
  questions: Question[]
}

function matches(cond: Condition, answers: Record<string, Answer>): boolean {
  if ('all' in cond) return cond.all.every((c) => matches(c, answers))
  if ('any' in cond) return cond.any.some((c) => matches(c, answers))
  return answers[cond.questionId] === cond.equals
}

function checkType(q: Question, value: unknown): string | null {
  switch (q.type) {
    case 'text':
      if (typeof value !== 'string') return 'must be text'
      if (q.maxLength !== undefined && value.length > q.maxLength) return 'is too long'
      return null
    case 'number':
      return typeof value === 'number' && Number.isFinite(value) ? null : 'must be a number'
    case 'yesno':
      return typeof value === 'boolean' ? null : 'must be yes or no'
    case 'choice':
      return typeof value === 'string' && (q.options ?? []).includes(value)
        ? null
        : 'is not one of the options'
  }
}

type Result =
  | { ok: true; formId: string; version: number; answers: Record<string, Answer> }
  | { ok: false; errors: Record<string, string> }

// Run on the server for every submission. Never trust the client's view
// of which questions were visible.
export function validateIntake(form: IntakeForm, raw: Record<string, unknown>): Result {
  const clean: Record<string, Answer> = {}
  const errors: Record<string, string> = {}
  const known = new Set(form.questions.map((q) => q.id))

  for (const key of Object.keys(raw)) {
    if (!known.has(key)) errors[key] = 'is not on this form'
  }

  for (const q of form.questions) {
    // Visibility uses only answers already accepted, so a forged answer to a
    // hidden question can never unlock later questions.
    const visible = q.showIf ? matches(q.showIf, clean) : true
    const value = raw[q.id]
    const empty = value === undefined || value === null || value === ''

    if (!visible) {
      if (!empty) errors[q.id] = 'was answered but is hidden'
      continue
    }
    if (empty) {
      if (q.required) errors[q.id] = 'is required'
      continue
    }
    const problem = checkType(q, value)
    if (problem) errors[q.id] = problem
    else clean[q.id] = value as Answer
  }

  return Object.keys(errors).length > 0
    ? { ok: false, errors }
    : { ok: true, formId: form.formId, version: form.version, answers: clean }
}

// Example: the medication question appears only if the patient says yes.
const form: IntakeForm = {
  formId: 'new-patient',
  version: 3,
  questions: [
    { id: 'takesMeds', label: 'Do you take any medication?', type: 'yesno', required: true },
    {
      id: 'medList',
      label: 'Which medications?',
      type: 'text',
      required: true,
      maxLength: 2000,
      showIf: { questionId: 'takesMeds', equals: true },
    },
  ],
}

validateIntake(form, { takesMeds: false, medList: 'x' })
// { ok: false, errors: { medList: 'was answered but is hidden' } }

Three details matter in production. Store the form version with every submission, so a later edit to the form cannot change what a past answer meant. Publish forms as immutable versions rather than editing in place. And if you use a schema library such as Zod for the static parts, test its defaults carefully; our write-up of the Zod 4 partial() default-values bug shows how a validation library can quietly fill in values you did not send.

Is an electronic signature on a consent form legally valid?

In the US, generally yes for many records, but the rules depend on the document, the state and the context.

General information; confirm with your adviser. This is not legal advice. Which consents can be signed electronically, and what disclosures you must give first, depends on your jurisdiction and the type of consent. Ask a qualified lawyer.

The federal ESIGN Act says a signature or record relating to a covered transaction "may not be denied legal effect, validity, or enforceability solely because it is in electronic form" (15 U.S.C. 7001). It defines an electronic signature as "an electronic sound, symbol, or process, attached to or logically associated with a contract or other record and executed or adopted by a person with the intent to sign the record" (15 U.S.C. 7006). The same section 7001 sets conditions, including consumer-consent disclosures, where a law requires information to be given to a consumer in writing. State laws, many based on the Uniform Electronic Transactions Act (Uniform Law Commission), add their own rules.

For engineering, that definition points to what to record: evidence of intent to sign, and a firm link between the signature and the exact record. A practical consent record stores:

• the consent document's ID, version and a hash of its exact text
• who signed (the patient, or a named guardian or carer acting for them)
• the signature itself (typed name, drawn image or checkbox), with the time and the authenticated session
• the action that showed intent, such as a button labelled "Sign and agree"
• withdrawal, as a new record, never as an edit or delete

Outside the US, e-signature and consent rules differ. Do not assume the ESIGN position transfers to the UK, EU, Australia or elsewhere.

How do you log who viewed a patient's intake?

Write an append-only event for every read, not only every change, from the server, at the point the data is returned. In the US, the HIPAA Security Rule's audit controls standard asks covered entities and business associates to "implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information" (45 CFR 164.312(b)). What exactly you must log and keep is for your compliance adviser; the table is a sensible engineering baseline.

Event	Record
Intake viewed	Actor ID and role, patient ID, submission ID, time, request ID
Insurance card image opened or downloaded	As above, plus the file ID; signed URLs that expire in minutes
Export or print	As above, plus the format and the number of records
Consent signed or withdrawn	Consent version and text hash, signer, relationship to patient
Form version published	Editor, old and new version, a diff of the rules

Keep the log in a table the application can insert into but never update or delete, and never write the health answers themselves into it, only IDs. Our audit log design guide shows the schema and a tamper-evident hash chain.

What does a custom intake system cost to build?

Knack's market guide puts a basic patient-facing app covering intake forms, scheduling and a simple portal at $40,000–$80,000 (Knack HIPAA app cost guide). That is a third-party figure, not a RAITHub price. The biggest drivers are the form builder (a fixed form is far cheaper than an editor staff can use), the number of consent types, and where intake data has to go: a practice management or EHR integration is usually the largest single line. The MVP cost estimator gives a rough scope.

Why RAITHub for this

• Health scheduling, built for a client. RAITHub's 8 client projects include a healthcare scheduling app. It has not shipped a regulated health product, and says so.
• Access control in production. Sundor Skin, a B2B wholesale platform, runs 146 PostgreSQL tables behind row-level security with 88 permission codes and 12 staff roles, the same shape of problem as reception, clinician and billing access to intake.
• Validation you can trust. This site runs 400+ tests, and its team diagnosed and wrote up the Zod 4 partial() default-values bug. TheSkinProof, the founder's own venture, runs 750+ tests across 217 API endpoints.
• Data handling inside your controls. We sign NDAs and DPAs and work inside your controls; production and patient data stay in your own covered cloud account, and development uses synthetic data. See the HealthTech page.

When you don't need us

• You run a practice and need intake forms next week: use your practice management system's intake module or a tool like IntakeQ.
• Your forms are short and rarely change: a no-code builder on a suitable plan will do.
• You need a native iOS or Android check-in app. RAITHub builds web apps and installable PWAs, which run on tablets in a waiting room and on patients' phones.
• You need a vendor to decide what your consents must say. That is your lawyer's job; RAITHub builds what they specify.

How RAITHub would build this

• Form engine: versioned forms with conditional logic, validated on the server as in the sample above, and a staff editor with preview.
• Consent and e-signature: versioned consent text, signer and relationship, intent capture and withdrawal records, to the wording your lawyer approves.
• Uploads and reminders: insurance card upload to private storage with expiring links, and SMS or email reminders that carry a link, not health details.
• Audit and access: role-based access with row-level security, and an append-only log of every view, download and export.
• Timeline and handover: a fixed-scope MVP in 4–6 weeks; 6–12 weeks if intake must sync into a practice management or EHR API. You receive automated tests and CI, handover docs and runbooks, and full IP under NDA.

Next step: book the free 15-minute technical audit, then get a written fixed quote, or a plain answer that a bought tool fits better. Please do not send patient data in the first message. The build service is described on the MVP development page.

Frequently asked questions

What is patient intake software?

Software that collects a patient's details, medical history, consents and insurance information before or at check-in, usually through digital forms sent by link or completed on a tablet, replacing paper forms and manual data entry.

How much does patient intake software cost?

IntakeQ's Forms Only plan is US$54.90 a month and its Practice Management plan US$84.90. Jotform lists HIPAA features from its US$129 Gold plan. Check each vendor's pricing page, as prices change.

Are e-signatures valid on patient consent forms?

In the US, the ESIGN Act says a record cannot be denied legal effect solely because it is electronic, and state laws add rules. Some consents and contexts have extra requirements, so confirm with a lawyer for your jurisdiction.

Why validate intake forms on the server if the form already has logic?

Because the browser can be bypassed. The server must decide which questions were visible, reject answers to hidden ones and enforce required fields, or bad and unexpected data reaches the patient record.

Do I need to log who viewed a patient's intake?

For health data it is a sound baseline, and US rules require audit controls for systems holding electronic PHI. Log reads, downloads and exports as well as edits. Your compliance adviser decides the exact scope and retention.

Can patients complete intake on their phones?

Yes. A mobile-first web app or installable PWA works on any phone through a link, with no app-store download. RAITHub builds web apps and PWAs, not native apps.

Should I build my own intake software or buy it?

Buy it if you run a practice with standard forms. Build it when intake is part of a product you sell, must write into your own data model, or needs audit and access rules a tool cannot give you.