Healthcare Website Design

What is healthcare website design?

Healthcare website design is the planning and build of the public website for a practice, clinic or hospital, the pages patients use to find care, book, pay and reach a portal. It covers information architecture, accessible templates, provider data, scheduling links and a privacy design that keeps health information away from marketing tools.

Where the website ends and the app begins

• The public website: Hours, locations, find a doctor, services, prices, insurance lists and the entry points to booking, bill pay and the portal.
• The signed-in application: The portal, messaging and results behind a login, which follow the patient app design rules and carry clearer HIPAA duties.
• The seam: Booking widgets, portal sign-in and bill pay pull from live systems, so the website has to hand off cleanly and keep trackers off those pages.

Which federal rules reach a provider's public website?

Accessibility, privacy and price rules all apply to public pages, depending on who runs the site. These are the ones to plan for.

• Section 504: Hospitals and many Medicare or Medicaid providers receive HHS federal financial assistance, and 45 CFR 84.84 requires their websites and mobile apps to conform to WCAG 2.1 Level AA.
• Section 504 dates: An interim final rule published on 11 May 2026 moved compliance to 11 May 2027 for organizations with at least 15 employees and to 10 May 2028 for smaller ones.
• ADA Title II: The DOJ rule also adopts WCAG 2.1 AA for state and local government entities, which covers public hospitals and county clinics.
• Hospital price transparency: CMS rules at 45 CFR Part 180 require hospitals to post a machine-readable file of standard charges and a consumer-friendly display of shoppable services.
• HIPAA on forms and tools: When a form, chat or booking tool creates, receives or maintains ePHI for a covered entity, the Security Rule at 45 CFR Part 164 Subpart C applies to it.

Health apps that sit outside HIPAA answer to the FTC instead: its Health Breach Notification Rule, 16 CFR Part 318, applies to personal health record vendors and related entities.

Are tracking pixels allowed on a healthcare website?

Tracking pixels are allowed only where they do not disclose PHI to a vendor without a permitted basis. OCR's bulletin on online tracking technologies says a covered entity may share PHI with a tracking vendor only under a business associate agreement for a permitted purpose or with a valid HIPAA authorization.

OCR's position on consent banners is direct: a banner that asks visitors to accept or reject cookies is not a valid HIPAA authorization. A cookie banner can still meet state privacy law, but it does not make a pixel on a portal or booking page lawful under HIPAA.

One part of that guidance no longer stands. In June 2024, in American Hospital Association v. Becerra, a federal court in the Northern District of Texas vacated the portion that treated an IP address combined with a visit to an unauthenticated public page about a health condition as PHI, and HHS withdrew its appeal.

Pages behind a login are a different matter. Portal, scheduling and bill pay pages tie activity to a known patient, so the safe design is to keep advertising and analytics tags that lack a business associate agreement off them entirely. State health privacy laws can also restrict tracking on public pages.

How to audit the tags already on a site

• 1. Crawl and record: Load each page type, including sign-in, booking and bill pay, and record every network request to a third-party domain.
• 2. Read the tag manager: List each tag, its trigger and the pages it fires on, since triggers set to all pages are the usual way a pixel reaches the portal.
• 3. Check the payload: Look at what each request sends, such as page URL, search terms, form values and identifiers.
• 4. Match to agreements: Mark which vendors have signed a business associate agreement and which have not.
• 5. Remove or restrict: Take unagreed tags off pages tied to patients and health searches, then retest after each marketing release.

Which pages must work on launch day?

• Home: What you treat, who you serve and the next action: find a doctor, book, call or pay a bill.
• Find a doctor: Filters for specialty, location, language and insurance, with profiles that match the scheduling system.
• Locations and hours: Address, parking, transit and after-hours instructions that match the call center script.
• Services: One page per service line in plain language, with conditions treated and how to get a referral.
• Patient resources: Pre-visit instructions, accepted insurance and links to the portal and bill pay that never send PHI by email.
• Prices: For hospitals, the shoppable services display and a link to the machine-readable file.
• Policies: The Notice of Privacy Practices, an accessibility statement with a way to report a barrier, and a website privacy notice that describes any tracking.

How do you build the site in four workstreams?

Treat the site as four workstreams that run side by side rather than a set of page templates. Each one needs an owner.

• 1. Find care: Model providers, locations and services in one data source, feed find-a-doctor and profile pages from it, and add the hospital price display where it applies.
• 2. Access for all: Build templates to WCAG 2.1 AA at minimum, write in plain language, and test with a keyboard and a phone screen reader before visual polish.
• 3. Protect health data: Inventory every form, widget and script. Route any field that collects health information to a tool covered by a business associate agreement, and keep marketing tags off authenticated and booking pages.
• 4. Connect systems: Link scheduling, portal sign-in and payments to the live systems, and name who updates hours, closures and provider lists.

Provider data to keep in one source

Find-a-doctor pages break when profile data lives in several places. Hold these fields in one source that the website, scheduling and the call center all read.

• Identity: Name, credentials, photo and National Provider Identifier.
• Practice: Specialties, conditions treated, locations and the days seen at each.
• Access: Languages spoken, new patient status, accepted insurance plans and whether telehealth visits are offered.
• Booking: The scheduling system ID, so the profile button opens the right calendar.

A pre-launch privacy and accessibility checklist

Run this checklist on a staging copy with production tags loaded, because many tracking problems only appear once the real tag manager runs.

• Script inventory: Every third-party script is listed with its vendor, purpose, pages it loads on and whether a business associate agreement covers it.
• Authenticated pages: Portal, booking and bill pay pages load no advertising or analytics tags without an agreement in place.
• Form routing: Contact forms ask only for what marketing needs, and any symptom, history or upload field goes to a HIPAA-ready tool.
• Session replay: Recording tools are off, or masked, on every page that can show health information.
• Keyboard path: Every menu, filter and form works without a mouse, with a visible focus indicator.
• Screen reader: Headings, labels, error messages and the find-a-doctor results read correctly on VoiceOver and TalkBack.
• Contrast and zoom: Text meets AA contrast and the layout holds at 200 percent zoom and 320 pixels wide.
• Statements: The accessibility statement and privacy notice are linked from every page footer.

Where healthcare websites fail patients

• Brochure first: Large photography with no find-a-doctor, hours or booking leaves the visitor with nothing to do.
• Health history in a contact form: A marketing form that collects symptoms becomes a store of PHI the marketing stack was not built to protect.
• Pixels left on the portal: A tag added for an ad campaign fires on the patient sign-in page and sends visit data to an advertising platform.
• Missing price files: A hospital that omits the machine-readable file or shoppable display misses a CMS requirement.
• Mouse-only menus: A menu that opens only on hover, or an unlabeled search box, blocks keyboard and screen reader users.
• Hand-kept provider lists: A PDF roster goes stale when a clinician leaves, and patients try to book someone who no longer practices there.

How Agnotic can help

A public health website succeeds when its provider data, privacy design and accessibility hold up under real patient use. Agnotic Technologies builds that kind of site for practices and health systems: a single source for providers and locations, accessible templates, scheduling and portal hand-offs, and a tag plan that keeps trackers off pages that touch health information.

Agnotic can also audit an existing site against the checklist above and fix the scripts, forms and templates that fail.

Sources

• eCFR: 45 CFR 84.84, web and mobile accessibility (Section 504)
• Federal Register: Section 504 compliance date extension (May 2026)
• HHS OCR: Use of online tracking technologies by HIPAA covered entities and business associates
• CMS: Hospital price transparency
• W3C: Web Content Accessibility Guidelines (WCAG) 2.1
• 45 CFR Part 164 Subpart C: HIPAA Security Rule safeguards
• FTC: Health Breach Notification Rule