HIPAA Compliant Web Development
Healthcare websites that actually meet the regulation, not just claim to. We build on BAA-covered infrastructure with encrypted data handling, compliant analytics, and audit trails that hold up under review.
What HIPAA Actually Requires for a Website
Most articles about HIPAA web compliance get the basics wrong. They conflate SSL certificates with full compliance, or assume a privacy policy checkbox makes a contact form HIPAA-ready. It does not.
HIPAA's Security Rule defines three categories of safeguards: administrative, physical, and technical. For a website, the technical safeguards are where most organizations fail. The regulation requires access controls, audit controls, integrity controls, and transmission security for any system that touches protected health information (PHI).
A standard WordPress site on shared hosting with a contact form plugin does not satisfy these requirements. Neither does a Squarespace site with a HIPAA badge in the footer. Compliance is a function of architecture, not decoration.
We build websites where every component that handles PHI is covered by a Business Associate Agreement, encrypted in transit and at rest, and backed by audit logs that record who accessed what and when.
Technical Implementation
Business Associate Agreements
- BAA procurement with hosting, CDN, and form processors
- Vendor risk assessment for every third-party integration
- BAA tracking register with renewal schedules
- Subcontractor chain of custody documentation
Encrypted Form Handling
- TLS 1.2+ for all form submissions
- AES-256 encryption at rest for stored submissions
- PHI routed to HIPAA-eligible endpoints only
- No PHI in URL parameters, query strings, or referrer headers
Compliant Analytics
- GA4 configured with server-side tagging to strip PII
- IP anonymization and User-ID features disabled
- Enhanced measurement features audited for PHI leakage
- Consent management with granular opt-in controls
Audit Logging
- Immutable access logs for all PHI interactions
- Timestamped records of form submissions, edits, and deletions
- Admin action tracking with user identification
- Log retention policies aligned to state and federal requirements
Infrastructure That Qualifies
Not every cloud provider or hosting platform will sign a BAA. And a BAA alone does not make the platform compliant. You need to configure it correctly.
AWS offers BAA-eligible services, but only specific ones: S3, EC2, RDS, Lambda, and about 150 others listed in their HIPAA Eligible Services Reference. Spinning up a random EC2 instance does not automatically fall under the BAA. You have to use the eligible services, configure encryption, and enable CloudTrail logging.
AWS with BAA
We deploy on BAA-covered AWS services with encryption enabled by default, VPC isolation, and CloudTrail audit logging. S3 buckets configured with server-side encryption and versioning for any stored PHI.
Aptible
Purpose-built for HIPAA workloads. Aptible handles encryption, network isolation, and audit logging at the platform level. We use it for healthcare applications that need database-backed form storage and patient portals.
Compliant CDN Configuration
CDN caching must be configured to never cache PHI. We set cache-control headers, exclude authenticated routes, and ensure form responses are never stored at the edge. Cloudflare and AWS CloudFront both support BAA-eligible configurations with the right settings.
Network Security
VPC segmentation isolates PHI-handling services from public-facing static assets. Security groups restrict access to known ports and IPs. All inter-service communication is encrypted with TLS, and database connections require SSL certificates.
Form Handling and Data Flow
Forms are where most healthcare websites break compliance. A visitor fills out a contact form that asks about their condition, treatment history, or insurance. That submission now contains PHI. Where it goes next determines whether you are compliant.
Encrypted Submission Pipeline
- Form data encrypted in the browser before transmission
- Server-side validation without logging PHI to application logs
- Submissions routed to HIPAA-covered storage, not email
- Confirmation messages that do not echo back PHI
PII Scrubbing
- Analytics events stripped of name, email, phone, and condition data
- Form field values excluded from dataLayer pushes
- URL parameters sanitized before analytics processing
- Server-side tag manager filters applied before data reaches GA4
Consent Management
- Granular consent for analytics, marketing, and functional cookies
- Consent state persisted and auditable
- Default-off for all non-essential tracking
- State-specific consent requirements mapped and enforced
Safe URL Architecture
- No PHI in URL paths or query parameters
- Condition and treatment pages use generic slugs, not patient queries
- Referrer headers scrubbed to prevent PHI leakage to third parties
- Form thank-you pages contain no submitted data in the URL
Mistakes We See Constantly
These are real configurations we have found during security audits of healthcare websites. Each one represents a potential HIPAA violation and a breach notification waiting to happen.
Google Forms for Patient Intake
Google will not sign a BAA for Google Forms. Full stop. If you are collecting PHI through a Google Form, you are transmitting protected data to a service with no compliance coverage. We have seen rehab centers, therapy practices, and medical offices doing exactly this.
Standard Contact Forms Without Encryption
A WordPress contact form plugin that emails submissions to your Gmail account fails on multiple levels: the form processor has no BAA, the data is transmitted without end-to-end encryption, and Gmail is not HIPAA-covered unless you have Google Workspace with a BAA and specific configuration.
Analytics Tracking PHI
Default GA4 configurations capture page URLs, search queries, and form interactions. If a patient navigates to /conditions/opioid-addiction and then fills out an intake form, that browsing path combined with their IP address could constitute PHI. Server-side tagging with PII filters is not optional for healthcare sites.
No BAA with the Hosting Provider
Your hosting provider stores your application, your database, and your form submissions. Without a BAA, they have no legal obligation to protect that data under HIPAA. Shared hosting platforms, most page builders, and many popular managed WordPress hosts do not offer BAAs.
Live Chat with No Compliance Layer
Patients will share health information in chat. If your live chat widget runs through a service without a BAA, those conversations are a liability. Most popular chat widgets, including Drift, Intercom, and Zendesk Chat, require specific enterprise plans and configurations to be HIPAA-eligible.
Unencrypted Email Notifications
When a form submission triggers an email to your admissions team, that email often contains PHI in plain text. Standard SMTP does not guarantee encryption end to end. We configure notifications that alert staff to new submissions without including PHI in the message body, directing them to a secure dashboard instead.
Frequently Asked Questions
Does my healthcare website need to be HIPAA compliant?
If your website collects, transmits, or stores any protected health information, yes. This includes contact forms that ask about conditions or treatment history, appointment scheduling systems, patient portals, and any intake forms. A simple brochure site with no forms or data collection may not fall under HIPAA, but the moment a visitor can submit health-related information through your site, compliance applies.
What is a BAA and do I need one with my hosting provider?
A Business Associate Agreement is a legal contract between a covered entity (your practice) and any vendor that handles PHI on your behalf. You need a BAA with your hosting provider, your form processing service, your email marketing platform, and any other third party that touches patient data. Not all hosting providers will sign a BAA. AWS, Google Cloud, Microsoft Azure, and Aptible are among the platforms that offer BAA-eligible configurations.
Can I use Google Analytics on a HIPAA-compliant website?
You can use GA4 on a healthcare website, but only with specific safeguards. Google will not sign a BAA for GA4, so you must ensure no PHI reaches Google's servers. This means implementing server-side tagging to strip identifying information before data leaves your infrastructure, blocking PII from URL parameters, scrubbing form field data from analytics events, and disabling User-ID and enhanced measurement features that could capture PHI.
How long does it take to build a HIPAA-compliant website?
A typical HIPAA-compliant healthcare website takes 8 to 14 weeks from kickoff to launch. The compliance layer adds roughly 2 to 4 weeks compared to a standard website build. That time covers BAA procurement, encrypted form infrastructure, analytics configuration with PII scrubbing validation, security testing, audit log verification, and documentation of technical safeguards. Practices with patient portal or EHR integration needs should plan for 12 to 20 weeks.
Building a Healthcare Website That Needs to Be Compliant?
We will walk through your requirements, identify where PHI flows, and scope a build that meets the regulation without slowing down your team.
Get In Touch