Ahealthcarewebsitethatbookspatientsandpassesaccessibilityreview

What HIPAA actually requires on a marketing website

HIPAA governs PHI — protected health information. A marketing site collecting only a name, email, and a general inquiry ('I'd like to book a consultation') is typically not in scope. The moment a form asks a patient to describe symptoms, upload records, or reference a specific condition, that data becomes PHI and requires a Business Associate Agreement with the form provider, TLS 1.2+ encryption in transit, and AES-256 encryption at rest.

The practical approach: keep marketing forms light and clinical intake separate. I route general inquiries through a standard contact form, then connect clinical intake to a HIPAA-compliant vendor — Jotform Healthcare, Formstack Health, or your EHR's own intake module. I build to that boundary on every healthcare project. No marketing contact form in my builds attempts to do clinical intake work.

One thing worth clarifying: HIPAA compliance is not a website certification. There is no badge or stamp. It is a set of technical and administrative controls applied to the parts of your operation that touch PHI. Your BAA with your form vendor, your hosting provider's security posture, and your staff training all matter as much as the website itself.

The six pages a medical practice website needs

Six pages carry most of the patient decision-making load. Services: what you treat, written in plain language a non-specialist can scan in 30 seconds. Providers: individual bios with credentials, specialties, languages spoken, and a direct booking link. Each provider bio page is its own local SEO asset. Locations: address, hours, parking, transit, and accessibility notes for each site. Booking: either an embedded widget from your scheduler or a clean, direct call-to-action pointing to it. Insurance: which plans you accept, what the billing process looks like, and who to call with questions. Patient resources: intake forms, pre-visit instructions, and billing FAQs.

Everything else — blog, news, press — is optional and depends entirely on whether your team has bandwidth to maintain it. Sites fail when they try to serve ten audiences and half those pages go stale within six months.

Specialty-specific considerations that generic agencies miss

A dermatology practice and a psychiatry practice need fundamentally different site structures. Dermatology patients expect before-and-after treatment galleries, clear procedure descriptions with recovery timelines, and photo-forward provider pages. Psychiatry patients need privacy-first language, minimal clinical jargon, a clear explanation of what the first session looks like, and HIPAA-compliant messaging options. Mental health practices also need to think carefully about chatbots — a general-purpose AI chatbot handling triage questions on a psychiatry site is a liability, not a convenience.

Pediatric sites need a dual audience: parents making booking decisions and children who will visit the office. Physical therapy sites need a patient education section — exercise libraries, post-procedure instructions — that keeps patients engaged between visits. I ask about specialty workflow early in the discovery call and build the information architecture from there, not from a generic healthcare template.

Real proof: Reevia and 2M+ records synced for a veterinary network

Reevia provides CRM and data integration services to one of Brazil's largest veterinary networks. Their challenge was not dissimilar to what many healthcare practices face: four separate systems, no unified view of patient (or in their case, animal patient) data, and a manual reconciliation process that introduced errors. I built an integration layer that synced 2M+ records from four systems into a single HubSpot source of truth, with under 50 seconds source-to-destination latency, in four weeks.

The direct lesson for healthcare website projects: the technical infrastructure behind a patient-facing site matters as much as the design. Booking widgets that do not sync to your EHR create double-entry work. Forms that live outside your HIPAA boundary create compliance exposure. The site is the front door; the integrations are the plumbing. I build both to work together from day one.

Page speed and Core Web Vitals in a clinical context

More than 70% of healthcare searches happen on mobile. A site that takes four seconds to load on a 4G connection loses the patient before the first page renders — not just to a slower experience, but to a competitor whose site loaded faster. Core Web Vitals (LCP, CLS, INP) are both a Google ranking signal and a patient experience metric. A slow site in a high-intent search context is a business problem, not just a technical one.

Every healthcare site I build is tested against Lighthouse and WebPageTest on mobile before launch. I use Next.js for static generation of provider and service pages, serve images at correct sizes through next/image, and load third-party booking widgets asynchronously so they do not block the initial paint. The result: fast, accessible, and ranked.

Healthcare website pricing and what each tier covers

Starter at $2,999 covers up to eight pages — services, providers, locations, booking integration, patient resources, and a contact form with the correct HIPAA boundary. Business at $7,999 adds custom provider bio pages with specialty-specific layouts, a full patient resources hub, multilingual support, and compliant form routing. Corporate at $11,999 and above handles multi-location architecture, a scalable provider directory, deep EHR integrations, and insurance acceptance pages at scale.

Timeline: three to four weeks start to launch on every tier. The 14-day money-back guarantee and one-year bug warranty apply across all tiers. Every engagement is Work Made for Hire — once you pay, the code is yours. I am not a clinical writer; you or your marketing lead provides medical copy. I handle layout, structure, technical delivery, and integration.