HIPAA compliant forms and patient intake

What makes a form HIPAA compliant #

HIPAA does not certify forms, form builders or any other software. It sets rules for the organisations that handle PHI and for their vendors. So the useful question is not "is this form compliant?" but "is every step this submission takes covered?" Follow one intake form from start to finish and there are six steps:

A form tool or an intake app #

A form tool collects answers. An intake app collects answers and then does the work that follows: matching the form to the patient and the appointment, putting it in front of the right person, reminding the patient who has not finished, and checking that consents are on file before the visit closes. The difference shows up in steps four to six of the table above, which is where most PHI leaks happen.

If your intake is a single questionnaire read by one clinician, a form tool that signs a BAA can be enough. Once a second person, a file upload or a reminder is involved, the form is the smallest part of the job.

What a patient intake form should collect #

HIPAA's minimum necessary principle applies to what you ask as much as to who sees it: collect what the visit needs, not everything a template from another practice asked for. A typical intake splits into a handful of parts, and each one is easier to protect when it is its own record rather than one long PDF.

• Demographics and contact details. Name, date of birth, address, phone, email, preferred contact method, emergency contact.
• Insurance. Payer, member and group numbers, the subscriber if it is not the patient, and photos of the card front and back. Store the images in secure file fields, not as email attachments.
• Reason for visit and history. Current concern, medications, allergies, relevant history. This is the most sensitive part; limit who can read it to the clinical roles that need it.
• Consents and acknowledgements. Acknowledgement of your Notice of Privacy Practices, consent to treatment, financial responsibility, and separate consent to text messages if you send SMS reminders. Each one is a record: which document, which version, when it was signed, by whom.
• Authorizations, only when you need them. A HIPAA authorization to release records to a third party is a separate form with required elements of its own: what will be disclosed, by whom and to whom, the purpose, an expiry date or event, the patient's signature and date, and statements about the right to revoke. Do not fold it into general intake.

Build patient intake on Tadabase AI #

Start from the Patient Intake & Scheduling template at tadabase.com/templates/patient-intake-scheduling. It is a complete front-desk app rather than a single form, so steps four to six of the checklist are already designed in. What it installs:

• Five roles. Front desk / admin (scoped to its own clinic), Provider (own day and own patient panel, with SSN and member ID hidden), Patient (a portal for their own records only), Org admin / compliance (consent versions, read-only audit log review, the only role permitted to run compliance exports), and a public intake / booking role with no login.
• Eleven tables, row-level security on every one. Clinics, providers, patients, appointment slots, appointments, intake forms, insurance, consents, reminders, a waitlist and an audit log. Intake forms, insurance and consents each have file fields for uploads.
• A public form that cannot read. The public intake role creates clinic-scoped records and sees nothing beyond open appointment slots. A new patient who starts intake gets a draft form and a portal login created for them.
• Twenty-one workflows. A submitted form is marked complete and routed to that clinic's front desk for verification; patients with a visit tomorrow and unfinished forms get a nudge; reminders go out at 48, 24 and 2 hours; text reminders are sent only to patients who have consented and not opted out, and an opt-out cancels pending texts immediately; when a visit is completed, the app checks that signed HIPAA and treatment consents are on file.
• Notifications without PHI. The internal "intake submitted" email identifies the patient by record number and form type and links to the verification queue. The patient nudge says forms are outstanding and links to the portal. Neither carries answers.
• An audit log that records field names, not patient data, appended whenever a patient record is created or changed and never edited by hand.
• Six AI agents, including an intake verification assistant that points the front desk to missing or inconsistent answers (suggestions only, it never edits) and a compliance assistant for consents and the audit trail. Agents work under the permissions of the person using them.

Then turn on the HIPAA controls, in this order:

1. Get on a HIPAA-eligible plan before real patient data goes in. On HIPAA-eligible plans we sign a BAA and run your app on BAA-covered AWS infrastructure.
2. Switch HIPAA on for the app. It is a setting in the Compliance Center or the app's settings, not a rebuild, and it works on an app you have already changed. Turning it on also sets auto-logoff, two-factor sign-in for app users and a password policy.
3. Classify the PHI. Flag the tables and fields that hold it: patients, intake forms, insurance and consents at minimum. You cannot log or mask what you have not flagged.
4. Make every upload field a secure file field, so an insurance card or ID can only be opened by a logged-in user whose role allows it.
5. Read the role rules and adjust them to your practice. If billing staff should see insurance but not history, that is a field rule on a role, enforced on the server, not a hidden column.
6. Publish through the gate. A HIPAA-flagged app is checked before every publish: PHI tables flagged, deny-by-default row-level security on each, secure file fields, access logging on, BAA-covered hosting. If a check fails, the publish is blocked and the remaining controls are listed.

Once it is live, the PHI access log on HIPAA-eligible plans records who read or changed PHI: the user, the action, the table, the record, the source IP, the result and the names of the fields touched. Values are never written to the log, and exporting it is limited to trusted roles. App users are unlimited on every plan, so every front-desk person gets their own login and every patient gets a portal without changing the price.

Six intake mistakes that leak PHI #

• Emailing the submission. The form is covered; the inbox it lands in, and every inbox it is forwarded to, often is not. Send a link to the record instead.
• PHI in reminder texts. "Your cardiology follow-up with Dr. Patel" over SMS is PHI on an unencrypted channel. Send the time and a portal link, and only to patients who consented to texts.
• Uploads with public links. An insurance card in an ordinary file bucket is one shared link away from the open web.
• A public form that can read. If the page that creates a submission can also list submissions, anyone with the URL can try. The public role should be write-only.
• One login at the front desk. The audit trail then records that "front desk" opened 300 charts, which proves nothing.
• Consents without versions. When the Notice of Privacy Practices changes, you need to know who signed which edition. Store the version with every signature.

Common questions #

Is there such a thing as a HIPAA compliant form builder? There are form builders that sign a BAA and encrypt submissions. That makes them usable in a compliant setup; it does not make your intake compliant. You still need to cover where the submissions go next, who reads them and how that is logged.

Do I need a BAA with my form vendor? Yes, if it stores or transmits PHI for you, even if its staff never look at the data. The same goes for the email or SMS service that sends your notifications.

Can I email a fillable PDF to patients and have them send it back? Patients may send you their own information by email, but the returned PDF then lives in an inbox, outside your access controls and audit trail. A portal link keeps the answers in one protected place.

Can patients sign consents online? Yes. HIPAA allows electronic signatures. In the Patient Intake & Scheduling template, patients sign consents from their portal and each consent is stored as its own record with the document and the date.

Can I send appointment reminders by text? Yes, with care. Keep the message to the time and a link, and send texts only to patients who have consented; the template checks consent and opt-out before every text.

I already have a practice app. Do I have to start over to add intake? No. On Tadabase AI you can add the intake tables to an existing app or describe the change, then switch HIPAA on for that app and clear the publish gate.

Where to start #

Write down the parts of your intake and who needs to read each one; that list drives the roles and the PHI classification. Then copy the Patient Intake & Scheduling template at tadabase.com/templates/patient-intake-scheduling, trim the fields to what your visits need, and send yourself through the public form as a test patient. The healthcare page at tadabase.com/healthcare shows the Compliance Center and the publish gate, and the HIPAA checklist on this blog covers the parts of compliance that sit outside the app. Every account starts on the free plan; talk to us about a HIPAA-eligible plan before real patient data goes in.