How To Make Healthcare Practice Website HIPAA Compliant

Making an existing healthcare website HIPAA compliant requires securing every touchpoint where Protected Health Information (PHI)—including patient names, email addresses, phone numbers, IP addresses paired with health searches, and appointment details—is collected, transmitted, stored, or analyzed. An existing healthcare website usually does not need to be rebuilt from scratch to improve HIPAA compliance. But simply adding SSL, a privacy policy, a cookie banner, or a “HIPAA-compliant form” is not enough.

The practical objective is to identify every place where PHI/ePHI can be created, collected, transmitted, stored, or disclosed, then secure those workflows and ensure the vendors touching that information are contractually and technically appropriate.

As of 2026, HHS states that the current HIPAA Security Rule remains in effect; proposed modifications to strengthen the Security Rule have not replaced the existing rule.

Start With the Website Data Flow

For a medical, dental, healthcare practice, example data flow could like this:

Website Component	Typical HIPAA Concern	What To Do
Contact form	Patient may enter symptoms, diagnosis, treatment request	Use secure PHI-capable form/service + appropriate BAA
Appointment request	Identity + healthcare request	Treat as potentially PHI + appropriate BAA
Patient portal/login	Very high PHI exposure	Isolate and tightly control tracking/scripts + appropriate BAA
Live chat/chatbot	Patients disclose health information	HIPAA-compliant vendor + appropriate BAA
SMS/texting	Appointment/health information	HIPAA-compliant workflow and vendor + appropriate BAA
Email notifications / Mail-to forms	PHI can be sent into ordinary inboxes	Avoid sending PHI in ordinary notification emails + appropriate BAA
Call tracking	Call recordings/numbers may contain PHI – The tracking of the phone numbers and where you store it is a problem by itself. Phone number of a caller (patient) is a PHI	Review vendor and BAA requirements + appropriate BAA
Google Analytics Standard Version	Data may be disclosed externally – Google analytics is not HIPAA compliant – You will have to look at at a replacement or a middelware.	Evaluate configuration and what data is transmitted + appropriate BAA
Google Ads tags	Advertising identifiers/tracking	Remove or isolate from PHI-sensitive workflows
Meta Pixel	Third-party disclosure risk	Generally keep away from PHI-sensitive pages/workflows + appropriate BAA
Session replay/heatmaps	May capture forms or patient behavior	Disable on sensitive areas unless appropriately controlled + appropriate BAA
Embedded scheduling	Patient/appointment information	Review data flow and vendor relationship + iFrames can add security risks and can pass PHI inverdently + appropriate BAA from the scheduling app.
CRM	Stores leads that may contain health information	Appropriate safeguards + BAA when BA relationship exists
Hosting/CDN	May maintain/transmit website data/logs/IP Addresses of patients	Determine whether ePHI reaches provider + appropriate BAA
WordPress plugins	Can send data to external vendors – this is a very common risk and big issue with websites that use Plugins or embedded apps.	Determine whether ePHI reaches the plugin and apps + appropriate BAA
Backups	May contain form/database PHI	Encrypt and access-control + appropriate BAA
Website administrators	Can potentially access PHI	Least privilege, MFA, logging, audit controls + appropriate BAA
Marketing agency	May access leads, forms or analytics	Determine whether agency is a business associate + appropriate BAA

HHS specifically requires regulated entities to assess risks to all ePHI they create, receive, maintain, or transmit. A documented risk analysis is foundational to Security Rule compliance.

The 10-Step Conversion Process

1. Perform a HIPAA website risk assessment. Inventory pages, forms, scripts, cookies, pixels, plugins, hosting, analytics, chat, scheduling, CRM, call tracking, email, SMS, backups and administrators. Document exactly where data goes.
2. Separate ordinary marketing pages from PHI-sensitive workflows. A page showing “Our Doctors” is fundamentally different from an appointment-request page or patient-portal login. HHS recognizes that tracking technology on many unauthenticated public pages may not involve PHI, whereas authenticated pages generally present significantly greater PHI concerns.
3. Remove unnecessary trackers from sensitive pages. Appointment forms, portal login/registration, symptom questionnaires, payment pages, secure messaging and similar workflows should not indiscriminately load Meta pixels, advertising tags, session-replay software or third-party scripts.
4. Replace insecure forms. Do not have a standard website plugin collect patient information and simply email the completed form to frontdesk@practice.com. A better architecture is encrypted submission → protected application/database → authenticated staff access. Email alerts can say something like “New secure inquiry received — log in to view” rather than containing the patient’s health information.
5. Review every vendor and obtain appropriate BAAs. HIPAA requires written business-associate arrangements when an entity is acting as a business associate involving PHI. The contract must restrict permitted uses/disclosures and impose appropriate safeguards and obligations.
6. Implement strong security controls. Website systems handling ePHI should have access controls, audit controls, integrity protections, authentication and transmission security. HHS expressly identifies these technical safeguards in the Security Rule.
7. Harden administrative access. Require individual accounts, MFA, least-privilege permissions, rapid revocation of former employee/vendor access, secure password management and separate privileged accounts. HHS’s healthcare cybersecurity guidance specifically recommends MFA, unique credentials, vulnerability mitigation and prompt credential revocation.
8. Encrypt appropriately and secure infrastructure. Use HTTPS/TLS, protect stored sensitive information, patch the CMS/server/plugins, scan for vulnerabilities, protect administrative interfaces, maintain secure backups and implement appropriate monitoring. HHS’s healthcare cybersecurity goals identify strong encryption and vulnerability management as high-impact controls.
9. Create policies and incident procedures around the website. Define who can access patient inquiries, how long information is retained, how vendors are approved, how access is terminated, how incidents are investigated and how potential breaches are handled. HIPAA requires policies, procedures and documentation—not merely technology.
10. Document and periodically reassess the system. Keep the website architecture, vendor inventory, BAAs, risk assessment, remediation decisions, access procedures and incident documentation current. HIPAA compliance is an ongoing operational process rather than a one-time website certification.

One of the Biggest Risks: Marketing Tracking

A healthcare website might have:

Website → Google Tag Manager → Google Analytics → Google Ads → Meta Pixel → call tracking → CRM → marketing agency

while simultaneously collecting:

Patient → treatment page → appointment request → name + phone + requested treatment

That combination needs careful analysis.

HHS states that regulated entities cannot use tracking technologies in ways that impermissibly disclose PHI. Where a tracking vendor receives PHI as a business associate, the necessary HIPAA conditions—including an appropriate BAA and permitted disclosure—must be satisfied.

There is an important legal nuance: after a June 20, 2024 federal court decision, HHS’s position cannot simply be read to mean that an IP address + visiting a public webpage about a health condition automatically constitutes PHI in every case. HHS’s current guidance reflects that limitation.

Practice Manager’s Dilemma

We have a 4 location medical practice, what are my options? We have just spent $7600 revamping our website, it took us 4 months go go live. Our auditor says we are at risk with 5 BAAs with different companies and the company who created the website has no BAA. They have built medical websites, but they are not HIPAA compliant. we are still using standard free Google analytics and Meta Pixels?

Using PatientGain’s SPOC app in conjunction with SPoSA You can address the current stated HIPAA concern.