Web Development • HIPAA-Aware Healthcare Web • SEO • AI Search Optimization (407) 409-8383   |   [email protected]
HIPAA-aware Healthcare Web

Healthcare web that does not become the weak link.

Six pieces cover the whole span of healthcare on the web, and each has its own page to go deeper: HIPAA-aware practice sites kept out of PHI scope, custom patient portals wired to your EHR, encrypted intake, Section 1557 accessibility, tracking governance, and ongoing security upkeep. Take one, or take the set. We are candid about the line throughout. We own the code, the configuration, and the safeguards; your practice owns the compliance posture that no vendor can sell. The goal is simple: a healthcare site that strengthens your posture instead of undermining it.

// no website is HIPAA compliant on its own; compliance is an organizational posture across your whole practice. We build the technical layer to be HIPAA-aware, and we draw a clean line between what we own and what only your organization, your policies, and your signed agreements can carry.

HIPAA-AWARE PHI-SCOPE DISCIPLINE WCAG 2.2 AA BAA-GATED
The overview

Healthcare web is mostly discipline, not magic.

Most of what makes a healthcare site safe is not exotic engineering. It is deciding deliberately where protected health information is allowed to flow, and refusing to let it leak anywhere a contract and a risk analysis have not accounted for. That discipline runs through all six pieces below, from a public marketing site to a portal, from encrypted intake to tracking cleanup and ongoing upkeep. We encrypt everything in transit, we keep the public marketing layer out of PHI scope so it carries no patient data, and we route anything that does collect health information through infrastructure a covered vendor will sign a Business Associate Agreement for. The work is care, not cleverness.

The framing matters as much as the code. Compliance is organizational, so a web team's job is to make the website HIPAA-aware, strengthening your posture rather than becoming the part of it that fails. We hold a clean dividing line throughout: we own the technical layer, and your practice owns what only an organization can carry. Anyone who sells you the website as the whole answer is selling you something that does not exist.

Some of this is regulated ground where the facts are real and the hype is thick. The HHS Security Rule, the OCR online-tracking bulletin, the 2024 court decision in American Hospital Association v. Becerra, the December 2024 proposed Security Rule update, and Section 1557 are all genuine. We state them plainly and we never dress them up with invented numbers or guarantees. Where a rule is proposed rather than in force, we say so.

The line we hold

Every healthcare engagement runs on the same clean division of responsibility.

  • We own the code, config, integration, and documentation
  • We own MFA, encryption, audit logging, CSP, and consent enforcement
  • We own WCAG conformance and the conformance documentation
  • You own executing BAAs and your Security Risk Analysis
  • You own workforce training and breach determination
How we work

Map the PHI, then build around it deliberately.

We start by finding where health information actually flows, then we keep as much of your site as we can out of that flow entirely. What must touch PHI gets the full set of safeguards. What does not, stays simple. The result is a site that is easier to run safely because most of it never carries patient data in the first place.

// the marketing layer stays clean, the portal carries the weight

  1. Map where PHI flowsWe trace every place health information could enter, move through, or rest in your site, from an intake form to a portal message to a stray analytics tag. That map decides everything else. Most of a practice site can be kept out of PHI scope, and knowing exactly which parts cannot is the foundation of a safe build.
  2. Keep the marketing layer cleanThe public site (services, conditions, providers, locations, accepted insurance, FAQs) is built on a structured clinical-content model and deliberately carries no patient data. That keeps the largest, most public surface simple to run safely and far outside the reach of a Business Associate Agreement.
  3. Engineer the PHI surfacesWhere health information genuinely must be handled, we build the full technical layer: TLS everywhere, mandatory MFA, role-based access control, encryption in transit and at rest, tamper-evident audit logging, a hardened Content Security Policy, and EHR integration over FHIR R4 and US Core where a portal needs it.
  4. Gate the vendors and the trackersPHI is only allowed to reach infrastructure a covered vendor will sign a BAA for. We inventory tags and trackers, remove or server-side proxy anything that leaks health information, and enforce consent across the whole stack so a pixel never becomes the channel that hands data to a vendor you have no agreement with.
  5. Document and maintainWe hand over the technical layer documented: what is encrypted, what is logged, how consent is enforced, and how the accessibility posture was verified. From there an optional retainer keeps the patching, scans, drift checks, and monitoring current as dependencies age and the rules move.
Questions, answered honestly

Frequently asked questions

No. No website is HIPAA compliant on its own, and we will never tell you otherwise. Compliance is an organizational posture across your whole practice: administrative, physical, and technical safeguards working together, plus signed agreements, a Security Risk Analysis, workforce training, and breach procedures. What we build is the technical layer, and we build it to be HIPAA-aware so the site strengthens that posture instead of becoming the weak link. We own the code, the configuration, the integration, the audit logging, and the documentation. Your practice owns what no vendor can sell: executing the BAAs, running the organization-wide risk analysis, training staff, and determining and notifying on breaches.

We keep that line clean and visible on every engagement. We own the technical deliverable: encrypted transport, MFA, role-based access, encryption at rest where warranted, tamper-evident audit logging, a hardened Content Security Policy, consent enforcement, WCAG conformance, and the documentation of all of it. Your organization owns the posture a vendor cannot carry: signing Business Associate Agreements, conducting your Security Risk Analysis, training your workforce, and making breach determinations and notifications. We will not blur that line to close a sale, because blurring it is exactly how practices end up exposed.

A BAA obligation attaches the moment a vendor transmits, stores, or otherwise handles protected health information on your behalf. For the pieces we build that touch PHI, that conversation is real and we have it up front: we select BAA-eligible hosting and form processing, and we make sure PHI never lands in a tool that will not sign one. Your practice signs the agreements with the covered vendors; we build the technical deliverable so those agreements actually hold. We deliberately keep your public marketing layer out of PHI scope so most of that surface never needs a BAA in the first place.

Yes, and the difference is the whole point. A practice marketing site is the public layer: services, conditions, providers, locations, accepted insurance, and FAQs on a structured clinical-content model. We deliberately keep it out of PHI scope, so it carries no patient data, which keeps it far simpler to run safely. A patient portal is the opposite: it handles real ePHI, so it gets mandatory MFA, role-based access control, encryption in transit and at rest, tamper-evident audit logging, and EHR integration over FHIR. Many practices need only the marketing site first, and we are glad to say so when that is the honest scope.

It is real, and it is the most current pitfall in healthcare web. More than 100 million dollars in pixel-tracking settlements have landed since 2023, and the OCR online-tracking bulletin still binds authenticated and portal pages even after American Hospital Association v. Becerra vacated only the unauthenticated-page theory in 2024. A cookie banner is not a valid HIPAA authorization. We inventory every tag and tracker, remove or server-side proxy anything that leaks PHI, migrate you to privacy-first or BAA-backed analytics (note that GA4 will not sign a BAA), and enforce consent across the whole stack rather than just dropping a banner on the page.

We build to WCAG 2.2 AA, which also satisfies the WCAG 2.1 AA that HHS Section 1557 and Section 504 require, and we produce conformance documentation for keyboard access, contrast, alt text, labeled fields, and captions. Be clear on the hedge: we build to WCAG, but legal Section 1557 and ADA conformance also depends on your organization's ongoing process and content. The deadlines are extended: Section 1557 requires WCAG 2.1 AA by May 11, 2027 for organizations with 15 or more employees and May 10, 2028 for smaller ones, and DOJ ADA Title II lands April 26, 2027 and 2028. Accessibility is fully studio-deliverable, so it is often a clean standalone project.

Not yet. The December 2024 update (mandatory MFA, encryption at rest, network segmentation, scan and pen-test cadences, and annual verification) is a proposed rule as of mid-2026, not current law. We frame it honestly: it is proposed, and it is prudent to build to now because it is where the rules appear to be heading. The binding standard today is still the existing Security Rule, under which encryption is addressable rather than flatly mandatory. We build to the stricter posture anyway, because it is good engineering, but we will not call it a mandate before it is one.

Yes. Our Healthcare Security Maintenance retainer covers ongoing upkeep: dependency and security patching, roughly six-month vulnerability scans, annual penetration-test coordination, patch-window SLAs, CSP and tracker drift checks, backups, uptime and integrity monitoring, breach-readiness runbooks, and re-checking the accessibility and tracking posture as the rules change. Worth being plain about what this is and is not: it is security maintenance and monitoring, not a compliance sign-off. We do not issue a formal attestation, certification, or verification document, because that is a posture only your organization can hold.
The rest of the codex

Related services

This hub is the healthcare-specific layer on top of our core web work. If you want the same hand-built craft without the healthcare safeguards, start with Web Development. For the search and the AI sides of the same practice, the other hubs are here.

Further reading: What "HIPAA-compliant" actually means for a website (and what it does not).

Building or fixing a healthcare site and want it done honestly?

Tell us what you are working with. We will give you a straight read on what stays out of PHI scope, what needs the full technical layer, and exactly where the line sits between what we build and what your practice has to own.