Try Interactive Demo
No-code database platforms are transforming the way web apps are…
Template Marketplace
Use Knack’s Patient Portal Template to give patients, providers, and…
A complete EHR for solo mental health practitioners. Manage patient…
Knack’s Telemedicine App Template gives healthcare providers, clinics, and independent…

What Are HIPAA-Compliant Forms? Requirements and Examples

  • Written By: Samantha Suser
What Are HIPAA-Compliant Forms? Requirements, Examples, How to Build Them

HIPAA-compliant forms are not just digital versions of paper intake packets. They are a specific category of tool that meets federal requirements for collecting, storing, and protecting protected health information (PHI). Most healthcare organizations use forms every day without fully knowing which ones qualify as HIPAA-compliant and which ones create compliance risk. This guide covers the requirements, the most common form types, and how Knack Health handles each layer so healthcare teams can build them without writing code.

Key takeaways

  • A HIPAA-compliant form must be backed by a signed BAA, encryption at rest and in transit, access controls, and audit logs. Any form missing one of these is not compliant regardless of how it looks.
  • Common HIPAA-compliant form types include patient intake forms, authorization forms, release of information forms, consent forms, and referral forms.
  • Paper forms and general-purpose digital tools like Google Forms do not meet HIPAA requirements by default.
  • The form itself is not what makes a workflow compliant. The infrastructure behind the form, including where the data lands and who can access it, is what determines compliance.
  • Knack Health lets healthcare teams build HIPAA-compliant forms connected to a structured database, role-based access controls, and automated workflows, all within a HIPAA-ready environment.
  • Confirming that a vendor will sign a BAA is the single most important step before any form collects patient data.

What makes a form HIPAA-compliant?

A HIPAA-compliant form is a digital or paper form used to collect protected health information. It must satisfy the requirements of HIPAA’s Privacy Rule, Security Rule, and, where applicable, the Breach Notification Rule. Four technical requirements define the floor for any digital form that handles PHI.

Signed Business Associate Agreement (BAA). Any vendor whose platform hosts, processes, or transmits a form submission containing PHI is a business associate under HIPAA. That vendor must sign a BAA before the form goes live with real patient data. A BAA is not optional and cannot be replaced with a general data processing agreement or terms of service clause. Confirming BAA availability, and specifically confirming it is included on the plan you are actually purchasing, is the first step in evaluating any form tool. Many platforms offer a BAA only on their most expensive tier.

Encryption at rest and in transit. The platform must protect data in transit as it moves between the patient’s device and the server. It must also protect data at rest in storage. Both requirements must be on by default, not configured after the fact. Specifically, a form that transmits over an unencrypted connection, or stores submissions in an unencrypted database, does not meet the Security Rule regardless of other features.

Access controls. Not every staff member should see every form submission. Specifically, HIPAA’s minimum necessary standard requires organizations to limit PHI access to what each role actually needs. A form platform must support role-based permissions so that front-desk staff, clinicians, billing teams, and administrators each have access scoped to their function.

Record logs. HIPAA requires that access to and changes in PHI be logged: who accessed a record, when, and what changed. Consequently, a form platform without audit logging creates a compliance gap that cannot be closed with other controls.

These four requirements apply to the system behind the form, not just the form itself. A form built in a non-compliant tool does not become compliant because it looks professional or uses medical terminology. In short, compliance follows the data infrastructure, not the design.

The most common types of HIPAA-compliant forms in healthcare

HIPAA applies to a wide range of forms used in healthcare settings. Understanding which form types are covered, and what each one needs to include, helps organizations audit their current workflows and identify where compliance gaps exist.

Patient intake forms

A patient intake form collects the demographic, insurance, and medical history information a provider needs before a first visit. Because these forms collect identifiable health information, they are subject to HIPAA from the first field. Common elements include full name and date of birth, contact information and emergency contacts, insurance details and policy numbers, medical history and current medications, allergies, and consent for treatment.

The intake form is typically the first point where PHI enters a healthcare organization’s systems. Consequently, the platform handling intake submissions must have a BAA in place before any patient data is collected. For a detailed field-by-field guide to building a compliant intake form, the patient intake form guide covers the full setup. The HIPAA-compliant patient forms post also covers what components specifically make patient forms compliant.

Authorization forms

An authorization form documents a patient’s explicit permission for a healthcare provider to use or disclose their PHI for a specific purpose. HIPAA’s Privacy Rule requires a valid authorization for uses and disclosures that fall outside treatment, payment, and healthcare operations. Common examples include authorization to release records to another provider, authorization to share information with a family member, authorization for marketing communications, and authorization for research use of medical records.

Release of information forms

A release of information (ROI) form is the mechanism by which a patient requests or authorizes the transfer of their medical records to another party. ROI forms are one of the highest-volume HIPAA form types at most healthcare organizations, particularly those with referral networks or patients transferring between providers.

ROI workflows also create one of the more common compliance gaps. The form itself may be compliant, but the method of transmission (fax, unencrypted email, paper mail) may not be. A HIPAA-compliant ROI process requires not only a compliant form but a compliant delivery pathway for the records being released. For a deeper look at automating this process, the release of information guide covers workflow automation for ROI.

Consent forms

Consent forms document a patient’s agreement to a specific treatment, procedure, or policy. Common consent forms in healthcare include consent for treatment, consent for telehealth services, consent to photograph or record, and acknowledgment of the Notice of Privacy Practices (NPP).

The NPP acknowledgment is particularly worth noting. HIPAA requires that covered entities provide patients with a Notice of Privacy Practices. Practices must also make a good-faith effort to obtain the patient’s written acknowledgment of receipt. The acknowledgment itself is not an authorization. Nevertheless, your organization must collect it, store it, and make it auditable as a HIPAA-required record.

Referral forms

A referral form transmits patient information from one provider to another to coordinate care. Because referral forms include diagnosis codes, treatment history, insurance information, and contact details, they are among the most PHI-dense forms in a typical healthcare organization’s workflow.

Referral forms are also one of the most common sources of HIPAA violations. The transmission step, sending the form to the receiving provider, often happens via fax or unencrypted email, which creates unauthorized disclosure risk. A HIPAA-compliant referral process requires a compliant form, a compliant transmission channel, and a BAA with any intermediary that handles the data in transit. Additionally, a specific look at building a referral tracking workflow, the patient referral tracking guide covers the database structure and workflow automation.

Internal administrative forms

Not all HIPAA-compliant forms are patient-facing. Internal forms are also subject to HIPAA requirements when they contain or reference identifiable patient information. Staff forms for documenting PHI, flagging compliance issues, reporting incidents, or managing care coordination all qualify. Examples include incident report forms, prior authorization requests, care coordination checklists, and internal transfer forms.

 

Why paper forms and generic digital tools fall short

Paper forms are not inherently non-compliant, but they create operational compliance challenges that are especially difficult to manage at scale. Transmitting paper forms by fax or mail creates additional exposure. Furthermore, auditing access to paper records is significantly harder than auditing access to a digital system with built-in logging.

Generic digital form tools typically fail one or more of the four HIPAA requirements. This includes Google Forms on free plans, standard web contact forms, and general-purpose survey tools. Specifically, most do not offer a BAA on their standard plans, do not provide audit logs, and do not enforce field-level access controls. A form that looks secure because it uses HTTPS is still not HIPAA-compliant if the submissions land in an inbox with no BAA coverage and no access restrictions.

The Google Forms HIPAA guide covers this in more detail. Specifically, it outlines the conditions under which a paid Google Workspace account can and cannot be used for PHI collection. The short version: free Google Forms is never compliant, and even the paid version has significant functional gaps for clinical workflows.

What HIPAA-compliant forms require from your organization (not just your platform)

A common misconception is that choosing a HIPAA-compliant form platform transfers compliance responsibility to the vendor. In practice, it does not. HIPAA divides responsibility between the covered entity (your organization) and the business associate (the vendor). The vendor’s BAA covers their infrastructure. Your organization is still responsible for the administrative safeguards.

In practice, that means your organization must:

  • Conduct and document a risk analysis covering the systems that handle PHI, including your forms platform
  • Train staff on how to handle PHI collected through forms, including who can access submissions and under what circumstances
  • Establish and document data retention policies for form submissions
  • Have breach notification procedures in place in case PHI collected through a form is exposed
  • Confirm that every integration connected to your forms platform, such as automation tools, EHR connections, or analytics platforms, is also covered by a BAA or excluded from PHI flows

The platform handles the technical safeguards. Your organization handles the administrative safeguards. Both are required, and neither substitutes for the other. For a full breakdown of both layers, the HIPAA compliance cornerstone covers the complete framework.

How Knack Health handles HIPAA-compliant forms

Standalone HIPAA-compliant form builders deliver secure data collection and stop there. Knack Health goes further, connecting forms to a structured database, role-based access controls, automated workflows, and staff-facing portals, all within the same HIPAA-ready environment.

For organizations evaluating where Knack Health fits relative to standalone form tools, the HIPAA-compliant form builder comparison covers the full landscape.

Here is how Knack Health handles each of the four compliance requirements at the form layer.

BAA. Every Knack Health HIPAA plan includes a signed Business Associate Agreement. Specifically, you do not need a separate negotiation or a higher-tier upgrade to get it. For a complete explanation of what a BAA requires and why it is non-negotiable, the BAA explainer covers the legal and operational details.

Encryption. Knack Health encrypts all data at rest and in transit as part of the platform infrastructure. Encryption is not a configuration option or a plan-gated feature. Knack Health includes it on every HIPAA plan by default.

Access controls. Role-based access controls in Knack Health operate at three levels. Page-level controls which sections of the app a user can reach. Record-level controls which records within a section a user can see. Field-level controls which specific fields within a record a user can view or edit. This means a front-desk coordinator can access scheduling fields without ever seeing clinical notes, and a billing administrator can access insurance data without accessing diagnosis history. The platform enforces the minimum necessary standard at the infrastructure level, not through staff policy alone.

Record logs. Knack Health logs every access to and change of a record, including form submissions, with user attribution and timestamps. The platform retains these logs for compliance review as part of its SOC 2 Type II compliance posture.

Beyond the four baseline requirements, Knack Health gives healthcare teams two capabilities that standalone form tools do not: a connected relational database and automated workflows. When a patient submits a form, the submission goes directly into a structured record in Knack Health’s database. That record connects to whatever other patient data, staff assignments, or workflow triggers your organization needs. There is no export step, no third-party sync, and no separate data store to manage. Everything lives in one HIPAA-compliant environment.

Knack Health HIPAA plans start at $499/mo. Confirm current plan details directly at knack.com/health/.

How to build HIPAA-compliant forms in Knack Health

The build process in Knack Health does not require coding experience. Healthcare teams can describe a workflow in plain language using the AI app builder, or build directly with the drag-and-drop interface. Either path produces a working form connected to a structured database in a HIPAA-ready environment.

The general shape of a HIPAA-compliant form build in Knack Health looks like this. Treat it as a process guide: exact screens and steps evolve as the product updates.

Step 1: Define what data the form needs to collect. Before building, identify what fields are necessary for the form’s purpose. HIPAA’s minimum necessary standard applies to form design: collect only what your organization actually needs for the stated purpose, and nothing beyond that. For an intake form, that typically means demographics, insurance, medical history, and consent. For an authorization form, it means the specific elements required for a valid HIPAA authorization.

Step 2: Build the form using Knack Health’s form builder or AI app builder. The drag-and-drop form builder supports text fields, dropdowns, checkboxes, date pickers, file uploads, electronic signatures, and conditional logic. Conditional logic is particularly useful for HIPAA-compliant forms. It lets you show or hide fields based on a patient’s earlier responses, which reduces unnecessary data collection and improves the experience.

The AI app builder in Knack Health lets you describe the form in plain language and generate a working form with a connected database structure. For example: “Build a patient intake form for a behavioral health clinic that collects demographics, insurance information, presenting concerns, and consent for treatment, with a separate staff view for reviewing submissions.”

Step 3: Configure role-based access. Once the form is built, define who can access submissions and what they can see. Assign roles for each user type in your organization and configure page-level, record-level, and field-level permissions. This is the step that enforces the minimum necessary standard at the system level.

Step 4: Connect the form to workflows. Knack Health lets you set up automated workflows that trigger on form submission. These can route notifications to the right staff member, update a patient record, flag a submission for review, or trigger a follow-up task. Connecting the form to a workflow is what separates a data collection event from an operational system.

Step 5: Verify the BAA and confirm your plan covers HIPAA. Before any real patient data enters the system, confirm that your Knack Health plan includes HIPAA coverage and that the BAA is in place. This is a prerequisite, not an afterthought.

Some organizations want to go further than storing individual form submissions. They want a full patient registry connected to intake forms. The HIPAA-compliant patient registry guide covers how to structure longitudinal patient data in Knack Health.

FAQ

What is a HIPAA-compliant form?

A HIPAA-compliant form is a form used by a healthcare organization to collect protected health information in a way that meets the technical and administrative requirements of HIPAA. At the digital infrastructure level, that requires a signed BAA with the form vendor, encryption at rest and in transit, role-based access controls, and audit logs. The form design itself is secondary to the infrastructure behind it.

Yes. HIPAA applies to paper records as well as digital ones. Organizations must store paper forms containing PHI securely, restrict access to authorized staff only, and manage them according to data retention and breach notification policies. The Security Rule’s specific technical safeguard requirements apply to electronic PHI (ePHI), but the Privacy Rule applies to all PHI regardless of format.

Free Google Forms is not HIPAA-compliant under any circumstances. Paid Google Workspace accounts can sign a BAA in the Admin Console. However, even with a BAA in place, Google Forms has significant gaps for healthcare use: no per-response audit logging, no field-level access controls, and no native e-signature. For clinical intake and patient data collection, it is not a suitable tool.

Consent forms document a patient’s agreement to treatment or a specific procedure. Authorization forms document a patient’s permission for a covered entity to use or disclose their PHI for a specific purpose outside treatment, payment, or healthcare operations. Both are required in different circumstances under HIPAA’s Privacy Rule. Authorization forms have specific required elements; missing any of them invalidates the authorization.

No. A HIPAA-compliant form platform covers the technical safeguards for the data it handles. Your organization remains responsible for the administrative safeguards: conducting a risk analysis, training workforce members, establishing data retention policies, and having breach notification procedures in place. The platform’s BAA transfers some vendor-side responsibility to the vendor, but it does not transfer your organization’s compliance obligations.

Every tool in your workflow that creates, receives, maintains, or transmits PHI needs its own BAA with your organization. A BAA with your forms platform does not extend to integrations. If you connect your forms to a CRM, an EHR, or an automation platform, each connection needs to be evaluated for HIPAA compliance. Where a connection handles PHI, it must be covered by a separate BAA.

Start with the four baseline checks. First, does your form vendor have a signed BAA with your organization? Second, does the platform encrypt data at rest and in transit by default? Third, does it enforce role-based access controls on form submissions? Fourth, does it provide audit logs on access and changes? If any answer is no, the form is not compliant regardless of how the interface looks or what healthcare templates the vendor offers.