HIPAA compliant online form builder for clinics using AI chat

Using a HIPAA compliant online form builder with an AI chat agent: what to keep out of chat, and how to hand patients to a proper intake form.

A HIPAA compliant online form builder needs more than a padlock icon: the vendor has to sign a business associate agreement with you before any patient data goes in. If your clinic site also runs an AI chat agent, the safest design is simple. Keep health details out of the chat, and send patients to a covered intake form by link.

Why chat is the risky door

Forms are structured. You know every field, where it is stored and who gets the notification. Chat is open text. A visitor asking about opening hours can follow up with "I've had chest pain since Tuesday and I'm on metformin" in the next message, and your agent has now received health information tied to a person who may have given a name, a phone number or an email address.

Whether a given message counts as protected health information depends on your role and on whether it is identifiable, and that is a question for your compliance lead or counsel. Operationally you do not need the legal answer to act. You need a rule: the chat agent answers general questions and collects contact details for a callback. Anything clinical goes to the intake form or to a human.

This is also how we scope the website AI chat agent for clinics. It is trained on your pages, PDFs and FAQs, answers visitors, captures and qualifies leads and books calls. It is not your medical record system, and the setup should make that boundary hard to cross by accident.

What stays out of chat and what the agent can do

Draw the line in writing before anyone configures anything. This is the routing map we start from.

Visitor says	Agent does	Where it goes
Asks hours, location, parking, accepted insurers (as listed on your site)	Answers from your pages and FAQs	Stays in chat
Wants to become a new patient	Collects name, phone or email, preferred contact time	Callback form, then staff
Wants to book a call	Books the slot, no reason for visit beyond a category	Calendar
Describes symptoms, medications, diagnoses	Stops, shows a short notice, links to intake form	Covered intake form
Asks for test results or records	Declines, explains how to request them	Patient portal or staff
Sounds like an emergency	Tells them to call emergency services	Off the website entirely

The fifth row matters most in practice. Teams plan for the symptom description and forget that people also paste in lab values and ask the bot to interpret them.

Step by step: moving patients from chat to intake

Decide your two forms. One is a low-risk callback or inquiry form that collects only contact details and a non-clinical category (new patient, existing patient, billing, other). The other is the full clinical intake, which lives on a tool you have a signed BAA with.
Write the agent's boundaries. In the agent's instructions, list what it must not request: symptoms, diagnoses, medications, insurance IDs, dates of birth, anything from a chart. Also tell it what to say when a visitor volunteers that information anyway: thank them, say the chat is not the right place for health details, and give the intake link.
Add a short notice at the start of the chat. One or two sentences: this assistant answers general questions, please do not share health information here, use the secure form for that. Keep it plain.
Build the callback form. Fields: name, phone, email, preferred time, category dropdown. No free text box titled "Tell us what's wrong." If you need a message field, label it "Anything we should know about scheduling?"
Link the clinical intake from the agent. Give the agent exactly one URL for it and tell it to use that URL only. Put the link on a custom subdomaiin such as intake.yourclinic.com so patients see your name, not a vendor's.
Pass context without passing PHI. Add a query parameter such as ?source=chat&topic=new-patient so staff know where the patient came from. Never put a name or a symptom in the URL.
Test with hostile scripts. Paste fake symptoms, fake medication lists and a fake lab result into the cht. Confirm the agent declines, shows the notice and gives the link. Repeat after every change to its instructions or knowledge base.
Review weekly. The agent is retrained weekly on your content, so review a sample of conversations at the same cadence. Decide who can read transcripts and how long they are kept, and write that down.

Choosing the tool for the clinical form

This is where the keyword question gets answered honestly. Qwenvo is a free form builder that our team builds, and it has no HIPAA offering. If the form collects symptoms, history, insurance numbers or anything else that identifies a patient alongside health information, do not use it for that form.

Jotform lists HIPAA features on its paid plans, so it is a common starting point. Read its current documentation, confirm you get a signed BAA, and check that the specific plan you pick includes the HIPAA features. We compare the options in more depth in our guide to Jotform alternatives for HIPAA.

Whatever you choose, verify these before you launch:

Check	Why it matters
Signed BAA in hand, not a marketing page	Required before PHI is stored by the vendor
Which plan includes the HIPAA features	Often a paid tier only
Where files and submissions are stored, and for how long	Retention and deletion are your responsibility too
Who gets notification emails and what is in them	Email is the most common leak path
Access controls and audit trail	You need to know who opened what
Whether integrations (Zapier, Sheets, Slack) are covered	A covered form feeding an uncovered spreadsheet is not covered

That last row catches more clinics than anything else. The form can be perfect and the webhook can still send the payload to a place with no agreement behind it.

Where Qwenvo does fit

Plenty of clinic traffic involves no health information at all, and a free builder is a good match there. Qwenvo works well for the callbaack form above, a general contact form, a patient satisfaction survey that asks about waiting times and friendliness, a newsletter signup, or a job application for front desk staff. The free account includes webhooks, a custom domain, no Qwenvo badge, teammates, custom design and CSS, and AI triage with routing rules, which other builders put behind paid plans.

Here the hidden fields are what tie the form to the chat. Add a source hidden field and fill it from the URL so every callback request is tagged as coming from chat. The AI triage can sort requests by category and priority and email up to 5 addresses, so billing questions go to billing and new patient requests go to the front desk.

Build the callback form free

Keep the limits in mind. Qwenvo is hosted in the United States, launched in October 2026 so it has few reviews yet, and it has no HIPAA offering. If your callback form could drift into clinical territory, start with the covered tool.

What the handoff payload looks like

When the agent captures a callback request, the payload your staff system receives should be boring. This is an illustrative example of the shape to aim for:

{
  "source": "website_chat",
  "topic": "new_patient",
  "name": "Jordan Rivera",
  "phone": "+1 555 0100",
  "preferred_time": "weekday mornings",
  "page": "/services/primary-care",
  "notes": ""
}

There is no reason for visit, no medication, no date of birth. If you see a notes field filling up with symptoms, tighten the agent's instructions and the label on that field. A good test is to ask whether the payload would embarrass you if it landed in the wrong inbox.

If you send this to Slack or a CRM, make sure the destination is somewhere contact deails are already allowed to live. Qwenvo posts submissions to any URL through a webhook, which makes Zapier, Make and n8n work, but the receiving side is still youur responsibility.

See how webhooks work

Mistakes we see in clinic setups

The agent invents a reassurance. If it is not instructed otherwise, it may answer "that sounds like it could be..." Instruct it to never interpret symptoms.
The intake link is buried. Put it in the first reply to anything that sounds clinical, not after three exchanges.
Transcripts forwarded by email. Daily chat summaries sent to a shared inbox can carry exactly what you were trying to avoid.
A second "temporary" form. Someone builds a quick Google Form for referrals. Keep an inventory of every form on the site and what it collects.
Old knowledge base content. A PDF with patient examples uploaded as training material. Review what the agent is trained on before it goes live.

Questions teams ask

Can the chat agent ever collect a date of birth or insurance number?

We would not configure it to. Those identifiers combined with a health context are where risk concentrates. Collect them on the covered intake form, after the patient has been handed off.

Is a callback form with a name and phone number a HIPAA problem?

It depends on context, and your compliance lead should decide. A bare inquiry with contact details and a category like "new patient" is much lower risk than one that includes a reason for visit. Keep it minimal and keep clinical wording out of the labels.

Can I use Qwenvo for the full patient intake?

No. Qwenvo has no HIPAA offering, so use a vendor that will sign a BAA for any form that collects PHI. Use Qwenvo for the non-clinical forms around it.

Does a custom domain make a form compliant?

No. A domain such as intake.yourclinic.com builds trust and keeps your branding consistent, but compliance comes from the agreement, the configuration and your own handling of the data.

Next step

Open your clinic site and write down every place a visitor can type free text, including the chat widget. Mark each one as "may receive health information" or "should not." Then rewrite the chat agent's instruuctions to match that list, and run the hostile test script from step 7 before you go live.

Start with the intake template