Healthcare websites carry a heavier responsibility than almost any other product category. A patient booking an appointment, searching symptoms, or managing their care online deserves a product that is accurate, trustworthy, accessible, and protective of their most sensitive personal information. This checklist is designed to help teams deliver all four.
Understanding HIPAA in the Web Context
HIPAA — the Health Insurance Portability and Accountability Act — governs how Protected Health Information (PHI) is collected, stored, transmitted, and disclosed. On the web, PHI can be collected through appointment booking forms, symptom checkers, patient portals, contact forms, and even analytics tracking that captures IP addresses alongside health queries.
The key principle is: any data that can identify an individual and relates to their health condition, treatment, or payment for healthcare is PHI and falls under HIPAA. This has direct implications for which analytics tools you can use, how your forms store data, and what your third-party integrations are permitted to do.
Important
This checklist is a practical guide, not legal advice. Before launching a healthcare product that handles PHI, work with a HIPAA compliance specialist and your legal team. The consequences of a HIPAA breach — both regulatory and reputational — are severe.
Section 1 — Data & Privacy Compliance
- All forms that collect PHI use HTTPS with TLS 1.2 or higher — verified in browser tools, not assumed
- Standard Google Analytics replaced with a HIPAA-compliant analytics solution (e.g., Matomo self-hosted, or Google Analytics with PHI-stripping measures in place)
- BAA (Business Associate Agreement) signed with every third-party vendor that may process PHI, including your CRM, email platform, and hosting provider
- Privacy Policy clearly describes what health data is collected, how it is used, and the patient's rights under HIPAA and applicable state law
- Cookie consent mechanism deployed — with analytics and tracking cookies off by default, requiring explicit opt-in
- Data retention periods defined and documented: how long is form data kept? Who has access? When is it deleted?
- Contact forms do not store PHI in URL parameters — this data can appear in server logs, referrer headers, and browser history
Section 2 — Accessibility (WCAG 2.1 AA)
Healthcare websites have a higher accessibility obligation than most. Your patients include elderly users, users with visual impairments, users with cognitive disabilities, and users under physical or emotional stress at the moment of use. WCAG 2.1 Level AA is the minimum — many healthcare providers are held to higher standards by state law.
- All text meets 4.5:1 contrast ratio against its background — tested with an automated tool and verified manually on real device screens
- Screen reader tested on NVDA (Windows) and VoiceOver (Mac/iOS) — not just automated axe scans
- All interactive elements reachable and operable via keyboard alone, in a logical tab order
- Medical information structured with proper heading hierarchy — patients navigating with assistive technology depend on this
- Any medical imagery has descriptive alt text that conveys the clinical meaning, not just the visual description
- Patient portal login tested at 200% zoom without horizontal scrolling or content loss
- Error messages in forms are clear, descriptive, and announce correctly to screen readers using aria-live
- Time-limited sessions (for security) warn users in advance and allow extension — session timeouts that cut off a patient mid-form are a significant accessibility and usability failure
Section 3 — Clinical Content Standards
- All medical claims, drug information, and treatment descriptions reviewed and approved by a licensed clinician before publication
- Content includes clear "last reviewed" dates — patients need to know when information was verified
- No content makes diagnostic claims that should be made by a physician — symptom checkers and health calculators include explicit "this is not medical advice" statements
- Emergency information (crisis lines, emergency department locations) is visually prominent and accessible without navigating deep into the site
- Drug dosage information, allergy information, and contraindication data are never displayed without the recommendation to consult a healthcare provider
Section 4 — Patient Portal UX
Patient portals are among the most used — and most hated — healthcare digital products. They fail not because the engineering is wrong, but because the UX treats patients as database records rather than people trying to manage their health. These points address the most common failure modes.
- Test results and appointment summaries are written in plain language, with medical terms explained contextually
- Lab results include reference ranges and brief plain-English interpretation, not just numbers
- Appointment booking flow takes no more than 3 steps: select, confirm, receive confirmation
- Prescription refill requests include expected processing time and a way to follow up if delayed
- The portal works fully on mobile — the majority of patient portal access is now on smartphones
- Secure messaging with care team has clear delivery confirmation and expected response time guidance
Portal task completion (before)
Before
51%
After
93%
Accessibility audit score
Before
62/100
After
97/100
Support calls for portal help
Before
340/month
After
94/month
Patient satisfaction (portal)
Before
3.1/5
After
4.6/5
“When we rewrote our lab results display in plain English and added reference ranges with brief explanations, support call volume dropped by half in the first month. Patients were calling not because the portal was broken, but because they couldn't understand what they were looking at.”
— Director of Digital Health, Regional Hospital Network