What Makes a Form Builder HIPAA Compliant?

“HIPAA compliant” is not a certification a vendor earns and displays like a badge. HHS says so directly: “there is no standard or implementation specification that requires a covered entity to ‘certify’ compliance,” and no private organization’s certification “absolve[s] covered entities of their legal obligations under the Security Rule” (HHS OCR FAQ). What actually determines whether a form builder belongs in a patient intake workflow is narrower and checkable: does the vendor sign a business associate agreement (BAA), and does its product implement the specific technical safeguards in the Security Rule (45 CFR 164.312)?

Most vendor roundups skip that distinction and hand you a feature checklist: encryption, access controls, a BAA somewhere. None of them map those features to the actual regulatory text, and none address the proposed 2025 update that would make encryption and multi-factor authentication mandatory rather than “addressable” (90 FR 898; as of August 2026, still a proposed rule with no final rule published). A practice evaluating a form builder, or the form tool bundled into its EHR, needs to be able to ask about each safeguard by name rather than settle for a claim on a sales page.

This guide works from primary sources: the Security Rule at 45 CFR 164.312 and 164.306, the business associate definition at 45 CFR 160.103, the January 2025 Security Rule NPRM, and the HIPAA pages published directly by Google Workspace, Jotform, and Formstack. Current as of August 2026.

What “HIPAA compliant” actually means for software

No federal agency certifies software as HIPAA compliant. HHS’s Office for Civil Rights (OCR) FAQ states plainly: “there is no standard or implementation specification that requires a covered entity to ‘certify’ compliance,” and OCR “does not endorse or otherwise recognize private organizations’ ‘certifications’ regarding the Security Rule,” adding that an outside “certification” does not “preclude HHS from subsequently finding a security violation” (HHS OCR FAQ).

That means a “HIPAA Compliant” badge on a form builder’s marketing page is a claim, not a credential. What holds up in an OCR investigation is whatever the vendor actually implemented: the BAA it signed, the safeguards it built, the documentation behind both. The exposure for getting this wrong is real. Civil money penalties are tiered by culpability, and for a violation the covered entity “did not know and, by exercising reasonable diligence, would not have known” about, the statutory range runs from $100 to $50,000 per violation, capped at $1,500,000 for identical violations within a calendar year (45 CFR 160.404(b)(2)); those figures are adjusted annually for inflation (45 CFR 160.404).

When a form tool becomes a business associate

Under 45 CFR 160.103, a business associate is an entity that “creates, receives, maintains, or transmits protected health information” on behalf of a covered entity (45 CFR 160.103). A form builder collecting patient intake data, symptoms, insurance details, medical history, meets that definition the moment a patient submits a form containing PHI. There’s no volume or feature threshold; the definition turns on what the vendor’s systems touch, not on how the practice happens to use the tool.

Once that’s true, the Security Rule requires a BAA before PHI moves through the vendor’s systems. 45 CFR 164.502(e)(1)(i): “A covered entity may disclose protected health information to a business associate and may allow a business associate to create, receive, maintain, or transmit protected health information on its behalf, if the covered entity obtains satisfactory assurance that the business associate will appropriately safeguard the information” (45 CFR 164.502). The companion administrative requirement, 45 CFR 164.308(b), makes the same demand of covered entities and requires those satisfactory assurances to be documented through a written contract or other arrangement that meets 164.314(a) (45 CFR 164.308(b)(3)) (45 CFR 164.308). Practically: if a form vendor won’t sign a BAA, a covered entity cannot lawfully put PHI into that vendor’s forms, regardless of how good the encryption is.

The Security Rule safeguards, mapped to form features

45 CFR 164.312 sets the technical safeguards a covered entity, and by extension its business associates, must address (45 CFR 164.312). Each specification is either Required (must implement) or Addressable (must assess whether it’s reasonable and appropriate, implement it if so, or document an equivalent alternative under 45 CFR 164.306(d)(3)) (45 CFR 164.306). Addressable does not mean optional; it means the entity has to make and document a reasoned decision.

Read the full regulation text alongside your vendor’s answers to these questions rather than taking a summary at face value. For how Rehabilitation Health approaches these controls platform-wide, see our security page.

Where the rules are heading: the 2025 proposed update

In January 2025, HHS published an NPRM titled “HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information” (90 FR 898) (Federal Register). Per HHS OCR’s own fact sheet, the proposal would: remove the required/addressable distinction and make nearly all specifications required, with limited exceptions; require encryption of ePHI at rest and in transit, with limited exceptions; require multi-factor authentication, with limited exceptions; and require vulnerability scanning at least every six months plus penetration testing at least once every 12 months (HHS OCR fact sheet).

Industry coverage often calls this “the 2026 HIPAA Security Rule update,” a label that refers to when a final rule was expected, not to a separate rulemaking: the January 2025 NPRM is the only proposal on the books. As of August 2026, it remains a proposed rule; HHS has published no follow-on proposal and no final rule. For a form builder specifically, the practical takeaway is that encryption, currently a documented addressable decision, would become non-negotiable, and any vendor without MFA on admin access would need to add it. Ask a vendor now whether encryption at rest and MFA are already standard, not something they’d add only after a final rule forces the issue.

Why consumer form builders fall short for intake

General-purpose form builders can be used in a HIPAA-compliant way, but usually not on the plan or account tier a practice defaults to.

Google Forms. Google’s admin help states that customers “who are subject to HIPAA and wish to use certain Google Workspace or Cloud Identity services listed on the HIPAA Included Functionality list must enter a Business Associate Amendment (BAA) with Google,” and that “customers who have not signed a BAA with Google must not use PHI in Google Workspace or Cloud Identity services” (Google Workspace Admin Help). Google’s HIPAA Included Functionality list, dated by Google “as of August 31, 2026,” names Google Drive, “including Google Docs, Google Forms, Google Sheets, Google Slides, and Google Vids,” as included (Google HIPAA Included Functionality). Google Forms can be covered, but only under a Workspace or Cloud Identity BAA an admin has signed; a free personal account has no BAA path because it isn’t a Workspace or Cloud Identity customer.

Jotform ties HIPAA features to plan tier. Its own HIPAA FAQ states “our HIPAA compliance feature is available only with Gold plan,” and that a signed BAA goes only to “covered entity customers that have enabled HIPAA compliance features in their account,” which requires a Gold or Enterprise plan (Jotform HIPAA FAQ); current as of August 2026.

Formstack takes a different path: HIPAA compliance is delivered through a dedicated account setup, “we will create a special account for you (or convert an existing account),” paired with Formstack’s standard BAA, data encryption, user-level permissions, and audit logging (Formstack HIPAA); current as of August 2026.

A signed BAA is necessary but not sufficient for intake. A generic form builder with a BAA still doesn’t link a response to the patient’s chart, still can’t tell a structured clinical answer from a block of free text, and wasn’t built to route intake into a treatment record; that’s a workflow gap, not a compliance gap, but it’s real. CuratoForm, the healthcare form builder from Rehabilitation Health that runs standalone or as part of PrismEHR (/form-builder/), signs a BAA with every customer rather than gating HIPAA features to a higher-priced plan, and closes the workflow gap by mapping submitted responses to the correct patient record when run alongside PrismEHR.

Questions to ask about your EHR’s built-in forms

An EHR’s bundled forms module can look like the simpler choice because it’s already included. Before treating that as settled, ask:

• How deep does the conditional logic go? Can a question’s visibility, or its wording, change based on an earlier answer, or does the tool only support showing or hiding whole sections?
• Does the form tool work standalone, for uses outside the patient chart such as referral intake or general inquiries, or is it locked to one workflow?
• Can forms be triggered automatically by an event, like a scheduled appointment, or does staff have to send each one manually?
• Where do answers land: as a scanned PDF, as note text a clinician has to re-key, or as structured data the system can query later?

These aren’t compliance questions; they’re the difference between a forms feature and a forms product. A BAA and encrypted storage are the baseline, not the differentiator, once every vendor in the conversation has them.

Form links and PHI exposure

A form is only as safe as the link that opens it. If a submission or pre-fill link carries PHI in the URL itself, a patient’s name or details embedded in a query string, that data can end up in browser history, server logs, or link-preview caches that a vendor’s Security Rule safeguards were never designed to reach. Evaluate how a form tool builds and distributes links: whether identifying information rides in the URL or only in the authenticated payload behind it, and whether a link is reusable and anonymous, appropriate for a general intake form, or scoped to a single patient, which needs a stronger control on who can open it.

CuratoForm’s link design follows that separation: static reusable links, useful for automated workflows such as a scheduled appointment triggering an intake form, alongside patient-scoped links for a specific individual. Submitted responses tie back to the right chart through patient object mappings rather than through identifying data placed in the URL.

AI in intake forms

If a form builder uses AI, to summarize a response, draft note text, or flag something for provider review, that AI vendor is itself a subcontractor handling PHI, and the same BAA chain applies. 45 CFR 164.502(e)(1)(ii) extends a business associate’s obligations to any subcontractor that creates, receives, maintains, or transmits PHI on its behalf (45 CFR 164.502), which in practice means the AI vendor needs its own BAA in the chain, not just the form builder. Ask a vendor directly whether its AI features run on infrastructure covered by a BAA, or whether they’re carved out.

The other question is clinical rather than contractual: does AI-generated content enter the patient’s record automatically, or does a clinician review it first? CuratoForm’s AI report engine mixes raw response values, such as demographics, with AI-generated sections, such as draft subjective documentation and flags for provider review, operating under BAAs already in place with its AI vendors; AI-generated content is reviewed by a clinician before it enters the record. An AI summary that’s wrong and lands directly in a chart note unreviewed is a materially different risk than one a clinician reads before signing off.

Evaluation checklist

A form builder that signs a BAA on every plan, keeps PHI out of its links, and ties responses to the right patient record isn’t offering a nice-to-have; it’s covering ground a lot of “HIPAA compliant” tools quietly gate behind a higher tier. CuratoForm does that as a standalone tool or built into PrismEHR, where raw responses and AI-generated content can populate clinical notes directly rather than sitting in a separate inbox someone has to reconcile by hand. If your practice is weighing a switch, read it alongside what Medicare actually expects in PT documentation; intake is the first record in the chart, and it should hold up to the same scrutiny as the notes that follow. See how it fits physical therapy practices.