For clinics, hospitals and health tech companies whose websites collect more than a phone number. We find every page where PHI enters, then build forms, booking, portal logins and chat so that data reaches only vendors under a BAA, with hosting, email and backups covered the same way.
HIPAA does not attach to a website as a whole. It attaches wherever the site creates, receives or transmits protected health information for a covered entity or business associate.
General content carries little HIPAA exposure by itself:
The exception is third-party code that records what a visitor types or selects on those pages.
Our website design and development team already builds healthcare sites with provider profiles, appointment requests and patient resources. On a HIPAA build we add a data-flow inventory before design starts, so every form field and script has a known destination and a contract behind it.
Submissions post over TLS to a backend covered by a BAA, are encrypted at rest and never travel in an email body. Staff receive a notice with a link instead of the answers. Fields are limited to what the workflow uses, and spam filtering runs on the server rather than through a third-party script.
We embed a scheduling vendor that signs a BAA, or build booking against your practice management or EHR API. Reason for visit is optional or a fixed list, and confirmation pages show nothing analytics tools could read. Reminder texts follow our HIPAA compliant SMS API design.
Login and registration pages are unauthenticated, yet OCR's bulletin treats the credentials and registration details typed there as identifiable. We keep tracking scripts off those pages, add multi-factor sign-in, lock out repeated failures and end idle sessions.
A chat box on a provider's site collects whatever visitors type, symptoms included. Either the chat vendor signs a BAA, or the widget is limited to general questions with a visible notice not to share health details. Our HIPAA compliant chatbot page covers the AI version.
Microsoft includes its HIPAA BAA by default through its Product Terms and Data Protection Addendum for covered entities and business associates, and Google lists Gmail under its Cloud BAA. A BAA does not fix a misconfigured mailbox, so we also set encryption and forwarding rules.
| Aspect | Where OCR's guidance stands | How we build it |
|---|---|---|
| Public page visit plus IP address | Vacated by the court on June 20, 2024 | Analytics configured to capture no form input |
| Booking or symptom pages without login | Still in force: what visitors type or select can be PHI | No third-party tags; first-party, server-side counts only |
| Portal login and registration pages | Still in force: credentials and sign-up details are identifiable | No marketing or analytics tags at all |
| Pages behind the portal login | Still in force: tracking there generally has access to PHI | No third-party tracking; audit logging instead |
| Mobile apps | Still in force | Same rules applied to app SDKs |
| Vendor receiving PHI | Needs a BAA, and the disclosure must be permitted | Vendors without a BAA stay off PHI pages |
OCR issued its tracking bulletin on December 1, 2022 and revised it on March 18, 2024. On June 20, 2024, the US District Court for the Northern District of Texas vacated only the part treating an IP address plus a visit to an unauthenticated page about health conditions as PHI. HHS appealed, then withdrew the appeal on August 29, 2024, so the rest of the bulletin stands. Google, for its part, states that it does not offer a BAA for Google Analytics and that authenticated pages should not carry its tags.
HHS guidance says a cloud provider that stores ePHI is a business associate even when the data is encrypted and the provider has no key. Our HIPAA Cloud Hosting runs on AWS with a signed BAA, and our managed web hosting supports regulated workloads with encryption, access controls and audit logging.
The Security Rule requires a data backup plan and a disaster recovery plan under 164.308(a)(7); testing them is addressable. We run daily backups with restoration checks and keep the copies encrypted under the same BAA as production.
Security Rule documentation, such as policies and assessments, must be retained six years under 164.316(b)(2). Access logs for the portal support the audit-control standard at 164.312(b), and we agree their retention period with you before launch.
Accessibility is a civil rights obligation that sits apart from HIPAA, and for many healthcare organizations it now has fixed dates.
HHS's May 2024 Section 504 rule requires recipients of HHS federal financial assistance to make web content and mobile apps conform to WCAG 2.1 Level A and AA. An interim final rule published May 11, 2026 moved compliance to May 11, 2027 for recipients with 15 or more employees and May 10, 2028 for smaller ones.
The Section 1557 rule at 45 CFR 92.204 requires covered entities to make health programs delivered through information and communication technology accessible, and requires recipients' websites and apps to meet Section 504.
WCAG 2.1 AA is a design input from the first wireframe: contrast, keyboard paths, labeled fields, errors a screen reader announces, and accessible booking and portal flows. Patient PDFs used to access services get the same treatment.
Provider, service and location pages written and laid out for patients, responsive and quick to load.
Intake, contact and appointment flows connected to BAA-covered systems or directly to your EHR.
An inventory of every script on PHI pages, with removal or replacement plans and a tag-governance rule for marketing teams.
Login, registration and reset pages with multi-factor sign-in, lockout and session timeouts.
BAA-covered hosting, mailbox configuration and restores that have been tested, not assumed.
Our security testers probe forms, portal pages and APIs before go-live, then retest after fixes.
We list every form field, script, embed and integration, and trace where each piece of data ends up.
Each vendor that would receive PHI is confirmed under a BAA or removed from PHI pages.
Wireframes and visual design with accessibility checks built in, reviewed with the staff who handle patient calls.
Development, EHR or scheduling integration, hosting setup and email configuration.
Penetration testing of PHI-handling pages, automated and manual accessibility checks, and a final tag scan.
A monitored launch, then patching, backups and a tag review whenever marketing adds a tool.
Project realities: The schedule depends mostly on how many third-party tools touch PHI and how quickly vendors confirm BAA terms. We give a plan once the data-flow inventory is complete.
The people who design the pages, write the code and review HIPAA exposure work in one architect-led team, with HIPAA compliance consulting on call.
We run the hosting tier we recommend, including a BAA-backed AWS option, so the site and its infrastructure answer to one team.
The company that builds the site can also test it, which shortens the fix-and-retest loop before launch.
Since 2008 we have delivered 250+ projects across 10+ countries and served 5,203+ clients on four continents.
Give us your site address and the forms that matter most. We will return a list of PHI touchpoints, the vendors receiving data, and the fixes in priority order.
Prefer email? info@xcodefixglobal.com
Talk to the specialist who would scope the work — not a call-centre script.
Ask us directlyEvery place the site handles PHI has to be protected and contracted. Forms, booking, portal logins and chat send data only to systems under a BAA, over TLS, stored encrypted, with access logged. No tracking code reads PHI pages, hosting and email sit under BAAs, and the whole flow appears in your HIPAA risk assessment.
Only the parts that handle PHI for a covered entity or business associate. A brochure site with no forms and no tracking on sensitive pages carries little exposure. Once you add intake forms, online booking, a portal or chat, those features are in scope, along with any third-party code that runs on them.
For general pages, often yes. For PHI, ask whether the builder will sign a BAA covering form submissions and storage. If it will not, keep PHI forms off the builder and embed a form or scheduling service that does sign one, with no builder analytics running on that page.
The Security Rule lists encryption as addressable, so you either put it in place or record why an alternative is reasonable and appropriate. In practice, forms that collect PHI should submit over TLS, store data encrypted and never send answers in plain email. We also remove fields the workflow does not use, which shrinks what could leak.
On general pages, with care. Google states that it does not offer a BAA for Google Analytics, that HIPAA-covered customers must not use it in ways that give Google access to PHI, and that authenticated pages should not be tagged. We keep it off booking, form and portal pages entirely.
Yes, if the host stores or processes PHI, such as form submissions, portal data or backups. HHS treats a cloud provider holding ePHI as a business associate even when the data is encrypted and the provider has no key. A host that refuses a BAA should only serve pages that never touch PHI.
For recipients of HHS federal financial assistance, the Section 504 rule requires WCAG 2.1 Level AA. After a May 2026 interim final rule, compliance is due May 11, 2027 for organizations with 15 or more employees and May 10, 2028 for smaller ones. Building to the standard now avoids a second redesign.
Both, in different ways. The covered entity owns its compliance program and risk analysis. A developer or host that handles PHI becomes a business associate with its own obligations under a BAA. A developer that never touches PHI still shapes compliance through what it builds, which is why we document every data flow we create.
