Healthcare Website Design

Since 2023, HIPAA enforcement around pixel tracking violations alone has resulted in over $100 million in fines. Google Analytics, without proper configuration, can constitute a violation on pages where patients interact with health-related content.

HHS requires covered recipients of federal financial assistance to meet WCAG 2.1 Level AA. In May 2026 it extended the deadlines by one year: May 11, 2027 for recipients with 15 or more employees and May 10, 2028 for smaller recipients. Private practices may have other accessibility obligations regardless.

What triggers lawsuits: - Missing alt text on images

• Insufficient color contrast
• Inaccessible forms and date pickers
• Non-keyboard-navigable interfaces
• Auto-playing media without controls

Overlay widgets like accessiBe do not make a website compliant. Courts consistently confirm that true accessibility requires fixing issues in the source code.

Protected Health Information includes: - Patient names, addresses, dates of birth, Social Security numbers

• Medical records, lab results, treatment history
• Billing and payment records
• IP addresses when combined with health-related page visits
• Appointment scheduling data
• Form submissions containing health information

If your contact form asks about symptoms or insurance, that submission is PHI.

Built-in accessibility enforcement. SvelteKit's compiler warns about accessibility issues during development. Missing alt text, improper heading hierarchy, inaccessible click handlers. The framework catches these before they reach production. This isn't an afterthought plugin; it's core to how Svelte works.

Smaller bundles, faster loads. A typical SvelteKit site ships around 42KB of JavaScript compared to 120KB+ for React-based frameworks. Faster sites perform better for seniors and patients on mobile devices with slower connections. Speed directly impacts both user experience and SEO.

Server-side rendering without hydration delays. No "frozen" page states while JavaScript initializes. Pages are immediately interactive. Critical for accessibility and user experience, especially for visitors using assistive technologies.

No plugin vulnerabilities. Unlike WordPress, there's no stack of third-party plugins creating security exposure. The attack surface is minimal. Every dependency is intentional and auditable.

HIPAA-compliant hosting options. SvelteKit deploys to AWS, GCP, Azure, or specialized healthcare hosting like Healthcare Blocks with proper BAA coverage. Though with the "no PHI on server" approach, standard hosting works fine for marketing sites.

Traditional headless CMS platforms like Contentful explicitly prohibit PHI in their services. Sanity offers HIPAA compliance only on enterprise plans costing $60,000-80,000 annually.

For healthcare clients, I use either: Self-hosted solutions like Directus or Payload CMS deployed on HIPAA-compliant infrastructure. You control the data, the encryption, and the access.

Custom CMS built into the same codebase as the frontend. No external API calls, no separate vendor agreements, no data leaving your compliant environment.

Privacy requirements for mental health are stricter than general healthcare. Patients seeking therapy are especially vulnerable to stigma. Your website needs to respect that sensitivity.

Key considerations: - No Google Analytics on any page (I use Plausible or Fathom)

• HIPAA-compliant appointment scheduling (Jane App, SimplePractice)
• Secure contact forms that encrypt submissions
• Design that builds trust without clinical coldness

My work with Korawells wellness clinic demonstrates this approach. We examined every aspect of the site through a HIPAA lens. The contact form uses Jotform's HIPAA-compliant tier with signed BAA. The site runs on Railway for hosting and CMS, but we ensured no part of the website collects or stores PHI. Even form fields have autocomplete disabled to prevent browsers from caching sensitive health information.

For multi-provider clinics, the web presence needs to handle: - Provider directories with individual bio pages

• Service descriptions by specialty
• Patient portal integration (or clear pathways to it)
• Insurance information and new patient workflows
• Location and contact information optimized for local search

The technical requirements scale with the data you handle. A marketing-only site without patient data has lighter compliance needs than one with online intake forms.

Telehealth web design requires integration considerations beyond typical healthcare sites: Video infrastructure choices. Daily.co offers native HIPAA compliance with better developer experience than alternatives. Twilio sunsetted their programmable video platform.

EHR integration patterns. HL7 FHIR standards for data exchange. API-first architecture that connects with Epic, Cerner, or practice management systems.

Remote patient monitoring. Web Bluetooth API for connected devices. Secure data transmission from wearables and home health equipment.

Home care clients include seniors and family members making care decisions. The website must be: - Highly accessible (WCAG 2.1 AA minimum)

• Clear about services, coverage areas, and caregiver qualifications
• Easy to contact with minimal form friction
• Mobile-optimized for family members researching on phones

For healthcare consultants and medical advisors, the website often serves as a credibility signal before high-stakes engagements. These sites need to convey authority without the clinical coldness of typical medical websites.

De Becker Code exemplifies this balance: sophisticated motion design and premium positioning that reflects the expertise being offered, while maintaining the trust signals healthcare audiences expect.

Application hosting: For most healthcare projects, I use Railway for the application layer. Fast deployments, straightforward scaling, and modern developer experience. When PHI storage is required on the server, I deploy to Fly.io with their HIPAA BAA, which provides compliant infrastructure without the complexity of configuring AWS/GCP from scratch.

Database: PostgreSQL on the same platform as the application, encrypted at rest. For projects needing separate database infrastructure, Fly.io's managed Postgres with BAA coverage handles compliance requirements.

CDN and static assets: Cloudflare for performance. Static marketing content doesn't require BAA coverage since no PHI is involved.

Forms: Jotform Gold/Enterprise tier with signed BAA for any form collecting health information. For the Korawells project, this handled contact forms asking about services. All form fields have autocomplete disabled to prevent browser caching of PHI.

Analytics: Plausible or Fathom for privacy-respecting analytics that don't collect personal data. No BAA required because they don't capture IP addresses or create PHI. If you need detailed analytics comparable to GA4, PostHog is my recommendation. They offer a BAA for healthcare clients, but even without one, PostHog works fine as long as you're not collecting PHI (which you shouldn't be on a marketing site anyway).

Email: Google Workspace with HIPAA BAA for most practices, Paubox for encrypted patient communications, or Microsoft 365 with BAA and proper configuration.

Video: Doxy.me for turnkey telehealth (free tier includes BAA), Daily.co for custom video implementations requiring branded experiences.

Practice management: SimplePractice, Jane App, or TherapyNotes handle scheduling, intake, documentation, and patient portals with built-in compliance.

CMS: I build content management directly into the SvelteKit application rather than using external headless CMS platforms. This eliminates third-party vendors from the PHI chain and keeps all content within your controlled infrastructure.

We map your compliance requirements: - What patient data will the website collect?

• Which vendors and platforms must integrate?
• What's your current HIPAA posture?
• Accessibility requirements based on funding sources

I design the technical approach: - Hosting and infrastructure recommendations

• CMS and content management strategy
• Third-party integrations with BAA verification
• Data flow documentation

Visual design that reflects your practice: - Accessibility baked into the design system

• Brand identity that distinguishes you from template sites
• User experience optimized for patient needs

Custom build on SvelteKit: - Server-side rendered pages for performance

• Forms integrated with HIPAA-compliant handlers
• Analytics configured for compliance
• Thorough accessibility testing

• Documentation of compliance measures
• Staff training on content management
• Ongoing support options

• Signed BAA
• Data encryption at rest and in transit
• Network firewalls and intrusion detection/prevention
• Physical security of data centers
• Regular vulnerability scanning and penetration testing
• Automated backups with encryption
• Disaster recovery and business continuity plans
• Detailed audit logs
• Role-based access controls

If your healthcare website is a static marketing site that does not collect, store, or transmit PHI (no forms, no patient portals, no login areas), standard hosting may suffice. However, any page that collects PHI (contact forms with health info, appointment scheduling, patient intake) needs HIPAA-compliant infrastructure.

Google has explicitly stated that GA4 does not meet HIPAA requirements and does not offer a BAA. Using Google Analytics on pages where users log in, submit forms, book appointments, or interact in ways linked to health-related services can constitute a HIPAA violation.

Since 2023, HIPAA enforcement around pixel tracking violations has resulted in over $100 million in fines.

1. Marketing pages (no PHI): Use Plausible or Fathom. They don't collect personal data, so no BAA is required
2. Pages with forms: Either exclude from analytics entirely, or use PostHog with BAA
3. Patient portals / authenticated areas: No third-party analytics, or enterprise-tier tools with BAA and proper configuration

• Encryption of data at rest and in transit
• Signed BAA with the form builder vendor
• Access controls with role-based permissions
• Audit trails tracking form submissions and access
• Secure data storage in HIPAA-compliant data centers
• Automatic session timeouts
• Multi-factor authentication for admin access
• Disabled autocomplete on sensitive fields to prevent browsers from caching health information locally

For custom-built healthcare websites using SvelteKit, you can integrate HIPAA-compliant form solutions through: 1. HIPAAtizer embeds which can be embedded into any website regardless of CMS

1. Server-side form handling that processes form data through your own HIPAA-compliant server, encrypting before storage
2. API integrations connecting to HIPAA-compliant backends like Directus or Payload CMS for form data storage

• In 2024, over 4,100 ADA website accessibility lawsuits were filed in federal courts
• Healthcare is among the top targeted industries
• Plaintiff attorneys use automated scanning tools to identify non-compliant sites
• Penalties for Section 504 violations can include suspension or termination of federal funding, including Medicare and Medicaid reimbursements

The Web Content Accessibility Guidelines are organized around four principles (POUR): Perceivable

• Alt text for all images and graphics
• Captions for videos and audio content
• Sufficient color contrast (4.5:1 for normal text, 3:1 for large text)
• Content adaptable to different screen sizes and orientations
• No information conveyed through color alone

Operable

• Full keyboard navigation (no mouse-only interactions)
• No content that flashes more than 3 times per second
• Skip navigation links
• Descriptive page titles and link text
• Sufficient time to read and interact with content
• Touch target minimum size (44x44 CSS pixels per WCAG 2.2)

Understandable

• Clear, readable language
• Consistent navigation across pages
• Form labels, instructions, and error messages
• Predictable page behavior

Robust

• Semantic HTML structure
• Compatible with screen readers and assistive technologies
• ARIA attributes used correctly when needed

Tools like accessiBe and similar overlay widgets do not make a website WCAG 2.1 AA compliant. Courts and accessibility experts consistently confirm that true accessibility requires addressing issues in the source code.

• Identify all points where PHI will be collected, stored, or transmitted
• Determine which compliance frameworks apply (HIPAA, ADA, Section 504, state laws)
• Inventory all third-party vendors/tools that will be used
• Obtain signed BAAs from all vendors that will touch PHI
• Conduct or review a HIPAA risk assessment
• Define data flow architecture showing how PHI moves through the system

• HIPAA-eligible hosting with signed BAA
• Data encryption at rest (AES-256) and in transit (TLS 1.2+)
• Firewall, intrusion detection, and DDoS protection
• Automated encrypted backups with tested recovery procedures
• Access controls with multi-factor authentication
• Audit logging enabled and retained per policy

• WCAG 2.1 AA compliance integrated from design phase
• Semantic HTML structure throughout
• Keyboard navigation fully functional
• Color contrast meets minimum ratios
• All images have meaningful alt text
• All videos have captions and transcripts
• Forms have proper labels, instructions, and error handling
• Skip navigation links implemented
• No auto-playing media
• Touch targets meet minimum size requirements
• Responsive design tested across devices

• No Google Analytics on pages that collect PHI
• HIPAA-compliant analytics tool implemented with BAA
• No third-party pixels/cookies on PHI-adjacent pages
• IP address collection disabled or anonymized where required
• Cookie consent mechanism in place

• Professional accessibility audit completed
• Penetration testing and vulnerability scan completed
• Incident response plan documented and tested
• Staff trained on HIPAA policies and procedures
• Ongoing monitoring and compliance review schedule established
• Accessibility statement published on the website