TWO44 built a HIPAA-compliant patient intake web application for a multi-location ABA therapy provider using Next.js, TypeScript, PostgreSQL with AES-256 encryption at rest, TLS 1.3 in transit, role-based access control, MFA for all users, comprehensive audit logging, and Business Associate Agreements with AWS and all PHI-touching vendors. The intake module captures insurance cards, guardian consent, and clinical history without storing PHI in browser localStorage or application logs.

Use cases

Building HIPAA-Compliant Web Apps for ABA Therapy Intake

How TWO44 built a secure, HIPAA-compliant patient intake web application for a multi-location ABA therapy provider — covering tech stack, authentication, BAA setup, and encrypted PHI handling.

Building HIPAA-Compliant Web Apps for ABA Therapy Intake

The Problem: Paper Intake and Consumer Tools Put PHI at Risk

A growing ABA therapy provider with clinics across North Carolina needed a web-based patient intake system. Parents were emailing insurance cards to a shared Gmail inbox. Intake coordinators photographed ID cards on personal phones. Session waitlists lived in Google Sheets without access controls. Every one of these workflows is a HIPAA violation waiting for an OCR complaint.

The clinic director had three non-negotiable requirements: parents must complete intake online before the first appointment, every byte of PHI must be encrypted and auditable, and the system must scale across multiple locations without duplicating patient records. Off-the-shelf form builders like Typeform and Jotform do not sign BAAs on standard plans. Generic WordPress plugins fail technical safeguard audits. The clinic needed a purpose-built, HIPAA-compliant web application — not a workaround.

Common mistakes at this stage include storing intake PDFs in Dropbox without a BAA, using Firebase or Supabase without HIPAA-eligible configuration, and logging form submissions to console output that captures patient names. We have documented these pitfalls in our 7 HIPAA mistakes ABA clinics make guide.

TWO44's Solution: Security-First Intake Architecture

We architected and deployed a HIPAA-compliant intake module as part of a broader therapy operations platform for the client. The approach followed a security-first sequence: define the PHI boundary, select BAA-eligible infrastructure, implement technical safeguards, then build intake workflows on top.

Tech stack: Next.js 14 with TypeScript on the frontend, server-side rendering for sensitive forms (no PHI in client bundles), PostgreSQL on AWS RDS with encryption at rest, S3 with server-side encryption for document uploads, and Redis for session management with encrypted payloads.

Authentication: Parents receive a unique, time-limited intake link tied to a referral ID — no account creation required for the first visit. Staff authenticate via email + password with mandatory MFA (TOTP). Role-based access control limits intake coordinators to their assigned location. Sessions expire after 15 minutes of inactivity per HIPAA recommendations.

BAA setup: We executed Business Associate Agreements with AWS (BAA covers RDS, S3, CloudWatch), our email provider (transactional only — no PHI in subject lines), and the hosting platform. A vendor inventory spreadsheet tracks agreement dates and renewal deadlines. No third-party analytics or error tracking touches PHI without a signed BAA.

Intake workflow: Multi-step form with progress saving server-side (never in localStorage). Captures guardian demographics, insurance details with card photo upload, clinical history, consent signatures with timestamp and IP audit trail. Uploaded files are virus-scanned, encrypted, and stored with object-level access policies. Intake status dashboards let coordinators track completion per location.

For deeper technical requirements, see our HIPAA web application technical requirements guide and developer compliance guide.

Proof of Work: Multi-Location ABA Deployment

This intake module is live as part of the therapy operations platform we built for Autizum, a multi-location ABA provider in North Carolina with clinics in Greensboro, Sanford, and Apex. The platform handles intake, session scheduling, ADOS assessment management, and parent notifications — all within a single HIPAA-compliant architecture.

Measurable outcomes (de-identified):

  • 100% of new patient intake moved from paper/email to encrypted digital forms within 90 days of launch
  • Intake completion time dropped from 45 minutes (in-clinic paper) to 12 minutes (parent self-service at home)
  • Zero PHI exposure incidents across 18 months of operation and two mock HIPAA audits
  • Audit logs capture every intake access event — satisfying OCR documentation requirements

We visit client locations in North Carolina for on-site training and compliance reviews. The intake system integrates with the broader autism therapy software platform we offer to ABA clinics evaluating digital transformation.

Key Benefits

  • HIPAA Technical Safeguards Built In

    AES-256 encryption at rest, TLS 1.3 in transit, MFA, RBAC, and 6-year audit log retention — not bolted on after launch.

  • Signed BAAs With Every Vendor

    Complete vendor inventory with AWS, email, and hosting BAAs documented and renewal-tracked.

  • Parent-Friendly Intake Flow

    Time-limited secure links let parents complete intake at home — reducing lobby wait times and data entry errors.

  • Multi-Location Ready

    Location-scoped access controls and centralized patient records without duplicate profiles across sites.

FAQ

Frequently asked questions

Straight answers about delivery, SEO approach, and working with TWO44.

A HIPAA-compliant web application implements administrative, physical, and technical safeguards including AES-256 encryption at rest, TLS 1.3 in transit, role-based access controls, multi-factor authentication, comprehensive audit logging with 6-year retention, and signed Business Associate Agreements with every vendor that touches PHI.