Why self-hosted web analytics for healthcare websites is a different build
For a hospital or clinic that needs traffic data without sending patient-adjacent browsing to third-party ad tools, self-hosted Matomo is the main fit. It runs on the organization's own servers, keeps visitor data under its control, and offers the consent-exemption configuration, server-side controls and access settings that a healthcare review will ask about. The build is different from the general case because the analytics server itself becomes a system the organization must safeguard, and because the public marketing site and the authenticated patient portal need to be measured under separate rules. The HIPAA Security Rule (45 CFR Part 164 Subpart C) applies to covered entities, such as health plans, clearinghouses and covered providers, and to their business associates, for all electronic protected health information they create, receive, maintain or transmit. Whether a tracking record counts as ePHI depends on what it reveals, such as a page path that identifies a specialty clinic, a condition or a portal login. That question belongs to the privacy officer and counsel, and it should be answered before any tag is deployed. There is no HIPAA certification. HHS states that no Security Rule standard requires certifying compliance, so any vendor claiming a HIPAA certificate for its analytics product is making a claim the reader should challenge. The reader should instead ask for the analytics vendor's or implementer's documented safeguards, and for the business associate terms that apply if a third party hosts or supports the server. Regulators also look beyond HIPAA. France's CNIL fined Hopital Prive de la Loire EUR 500,000 on 3 September 2026 under GDPR Articles 32 and 34, finding that external access to its patient record system lacked VPN and multi-factor authentication and that access control ignored the care team's need to know. The same questions apply to the analytics console: who can view portal-adjacent reports, how administrator access is granted and removed, and whether dashboards expose page-level detail. For public pages only, Plausible and Umami can be considered as lighter options, but healthcare teams should treat them as candidates for brochure content, not for any section that touches patient access, and should confirm each product's current feature set before deciding.
Which HIPAA and privacy requirements shape the analytics build
This table maps each requirement that applies to a healthcare analytics server to its source, what it asks for, and what it means for the server, admin access, logs and backups. Read it as a checklist for scoping, then confirm with your privacy officer and counsel which rules apply to your entity. The main takeaway is that the analytics platform is in scope only if it touches ePHI, so keeping patient-identifying data out of collection is the most effective way to limit the build.
| Requirement | What it asks for | What it means for the analytics build |
|---|---|---|
| Security Rule scope (45 CFR 164.302) | Covered entities and business associates must protect electronic protected health information they create, receive, maintain or transmit. | If the analytics server receives page URLs or events that reveal a patient, condition or appointment, it is in scope. Confirm whether your tracking data can be ePHI before you go live. |
| Standards and specifications (Appendix A to Subpart C) | 18 standards across administrative, physical and technical safeguards, with 36 implementation specifications: 14 required and 22 addressable. | Map each standard to a server control: role-based admin access, host hardening, log review and backup testing. Keep the mapping in a document an assessor can read. |
| Unique user identification (164.312, required) | Each person accessing ePHI systems must have a unique identifier. | No shared admin logins on the analytics server or its database. Use named accounts tied to your identity provider and remove accounts when staff leave. |
| Emergency access procedure (164.312, required) | A documented way to reach ePHI systems during an emergency. | Document break-glass access to the analytics host and database, who may use it, and how use is logged and reviewed. |
| Automatic logoff (164.312, addressable) | Session termination after inactivity, or a documented reasonable alternative. | Set session timeouts on the dashboard and SSH sessions. If you choose a different measure, record why and what replaces it. |
| Encryption and decryption (164.312, addressable) | Encryption of ePHI where it is reasonable and appropriate, with a documented alternative if not. | Encrypt the database volume, backups and traffic to the dashboard. Document the decision for any component you do not encrypt. |
| Addressable decision rule (164.306(d)) | For each addressable specification, assess whether it is reasonable and appropriate, document the outcome, and implement an equivalent measure if needed. | Keep a written decision record for every addressable item in the analytics build, including the reason for each choice. |
| Business associate contract (164.314(a)(2)(i)) | Contracts must require compliance with the Security Rule, flow terms to subcontractors that handle ePHI, and report security incidents. | If a partner or hosting provider can access the analytics data, require these terms in the contract. Confirm the flow-down to any cloud or CDN provider. |
| GDPR Articles 32 and 34 (as cited in the CNIL fine) | Article 32 requires appropriate security for personal data. Article 34 requires communicating breaches to affected people in high-risk cases. | Cited in the 2026 CNIL fine for external access without VPN or multi-factor authentication. Require MFA and VPN-based remote access to the analytics admin interface for EU patient sites. |
| No HIPAA certification | HHS states that no standard requires certifying compliance and that private certifications do not prevent a later finding of violation. | Do not describe the analytics server as HIPAA certified. Ask any partner for evidence of controls and documentation, not a certificate. |
What to exclude from collection on patient-facing sites
Decide exclusions before you deploy the tracking snippet, not after the first report exposes a problem. Treat any page where a visitor is, or may be, a patient as a candidate for exclusion: appointment booking, symptom checkers, patient portal login and results pages, billing and payment pages, and pages that confirm a referral or a test. Search terms also need a rule. A query such as a condition name or medication typed into the site search can reveal health information about a visitor, so decide whether internal search is collected at all and, if it is, whether the query text is stored. In Matomo, page exclusion and query parameter exclusion are configured per site, and the same settings should be documented in your data map so that the exclusion list can be reviewed by someone other than the original administrator.
Strip what the URL and the browser send. Query strings often carry appointment identifiers, referral codes, or account references, so list the parameters your analytics platform should drop before storage and test them with real links from your templates. Referrer headers can reveal the page a visitor came from, such as a condition-specific page on a partner site, so decide whether referrers are kept at the domain level only or removed. Avoid custom dimensions, custom variables, and event labels that hold health information, including condition, department, clinician, or visit type. A dimension named for a clinical service is a health data point even if it contains no name. Features that identify individuals or record behavior, such as User ID, heatmaps, or session recording, are generally excluded on these sites. Matomo's ePrivacy FAQ states that adding these features removes the CNIL exemption from consent, so they would require a separate legal basis and assessment. Confirm the final list with your privacy counsel and, where the HIPAA covered entity or business associate analysis applies, with the security officer, because the regulator and the counsel decide what counts as protected health information in your setup.
Separating public pages from authenticated portals
Public marketing, service and location pages carry no authenticated patient context, so analytics can run here under a narrower and easier-to-document configuration. The purpose is usually traffic measurement, content performance and campaign attribution. The scope should still be written down, because a public page that links to a portal login or appointment form can start to reveal health interest.
- Analytics status: Analytics may run, provided no page content, query strings or form fields reveal a condition, service line or appointment.
- Identifiers: Use anonymous or pseudonymous visitor IDs, with IP anonymization enabled and no User ID.
- Retention: Set raw visit retention to the shortest period the marketing team can justify, and document it.
- Report access: Marketing and communications staff can see aggregated reports, without visitor-level logs.
- Third parties: Confirm that no ad pixels or external tag managers load on these pages.
Confirm with your privacy and legal team whether any consent requirement applies in your jurisdictions, and confirm in your environment which Matomo identity and access options your edition supports.
The authenticated patient portal is where health context is most likely to appear in URLs, page titles and events. Many teams choose to exclude it from analytics entirely, or to run it as a separate Matomo site with a stricter configuration. Either choice should be a documented decision, not a default inherited from the public site template.
- Analytics status: Often excluded by default, or limited to uptime and error signals that do not include patient-level content.
- Identifiers: No User ID, no account numbers, no appointment or diagnosis values in custom dimensions, and no session recording.
- Retention: Keep any portal metrics on a short schedule that matches the policy agreed for portal logs.
- Report access: Restrict to a named group in the platform team, with access reviewed on a fixed schedule.
- Separation: Use a separate Matomo site ID so portal data never mixes with public reporting, and confirm the tag is absent from pages that render patient data.
Before enabling any portal tracking, ask your implementation partner to show the tracked URLs and event names in a test environment, and confirm how your Matomo version handles access rights for each site.
Clinician and staff intranets, including scheduling tools, internal knowledge bases and clinical reference pages, are internal systems with their own access rules. Analytics here is usually about tool adoption or content use, not visitor behavior. Because staff members are workforce users rather than visitors, the justification, scope and reporting audience differ from the public site.
- Analytics status: Run only where an internal purpose is documented, and never on pages that display patient records.
- Identifiers: Avoid user-level identifiers that tie a staff member to a clinical task, and prefer aggregated page-level counts.
- Retention: Align with the internal retention schedule for workforce systems, which may differ from public data.
- Report access: Limit to the team that owns the intranet, and keep it out of general management dashboards.
- Network placement: Host the analytics server on a segment that matches the intranet's security zone, with logging of administrator access.
Confirm with your security and HR teams which internal data categories apply, and check whether your deployment must run without outbound connections.
Separate Matomo sites help keep data apart, but the access model decides who can actually read it. Public, portal and staff reports should sit in different access groups, each with a named owner and a review cycle. Confirm how your Matomo edition handles user roles and whether it supports the identity integration your organization requires, because this is an environment-specific check.
- Group design: Create one group for public marketing reporting, one for portal operations and one for intranet owners.
- Least privilege: Grant view access to aggregated reports by default, and limit administrator rights to a small platform group.
- Joiner and leaver: Tie group membership to your identity lifecycle process, so departed staff lose access quickly.
- Sizing: Confirm the server sizing for the combined traffic, since Matomo publishes separate sizing guidance for different pageview volumes.
- Audit trail: Keep records of who changed site configuration, tracked URLs or retention settings.
Ask your partner to document the access matrix and the review procedure as part of the handover.
Which open-source analytics platforms fit a healthcare site
Healthcare sites need analytics that keep visitor data on servers the organization controls and out of ad platforms. The options below differ in license, runtime requirements and how much of the feature set you must verify before a patient-facing site uses them. Each card names one decision to make before selecting a platform.
Matomo as the default candidate
Matomo is the platform most healthcare teams evaluate first because its self-hosted Community edition is licensed under GPLv3 and can run entirely inside your own hosting. Matomo's requirements FAQ lists PHP 8 with MySQL 5.5 or later or MariaDB for Matomo 5, while Matomo 6.0.0 needs PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer. The current stable release is 5.14.1, and 6.0.0 is in beta, so pick the line your team can support and confirm it against your change control.
Plausible for simple public pages
Plausible can suit a small set of public informational pages, such as location, service and appointment information, where you need only page-level traffic. Confirm its self-hosted feature set, its database requirements and whether it offers the user access controls, audit logging and session handling your HIPAA risk analysis expects. Features that depend on a cloud service, or that are offered only in the hosted version, are outside what a self-hosted deployment can be relied on to provide.
Umami for minimal page measurement
Umami is a lightweight option for measuring page views and referral sources on static public content. Its simplicity is useful when you want the smallest possible collection footprint, but it also means fewer administrative controls. Ask the vendor or your own testing to confirm how user accounts are created and removed, how the admin interface is protected, where the database stores visitor data and what logs the application keeps, since each of these affects your safeguards.
Excluding Matomo heatmaps and session recording
Matomo's paid Heatmap and Session Recording plugin is excluded from this healthcare design. It is sold per user under the InnoCraft EULA rather than the GPL, and recording clicks, scrolls and sessions on pages where patients enter health information creates a high risk of capturing protected health information. Matomo's ePrivacy guidance also notes that heatmaps and session recordings remove the audience measurement exemption in France, which is a separate reason to avoid them on patient-facing sites.
Confirming the HIPAA safeguards per platform
No open-source analytics platform is HIPAA certified, and HHS states that no Security Rule standard requires certification. Your evidence is your own risk analysis, the access controls, audit logs, encryption and backups you configure, and the business associate contract if a vendor hosts or supports the platform. Put each candidate through the same checklist of unique user identification, automatic logoff, encryption in transit and at rest, and emergency access before comparing features.
How a healthcare analytics rollout moves from risk review to live tagging
This sequence takes a healthcare organization from an inventory of its patient-facing pages and portals to a documented, audited analytics server that collects only what the risk review allowed.
Scope the sites and inventory the data
The team lists every public site, patient portal, booking flow and app that may carry analytics tags, and records which pages are authenticated, which carry health context in URLs or forms, and which third-party scripts already load. DeployOpen typically runs this with the compliance lead, the web owner and the privacy officer. The output is a signed scope document and a data inventory that names each page group, its owner and the data it could expose. The phase is complete when the sponsor signs the scope in writing.
Record the risk analysis and addressable decisions
The covered entity reviews the analytics platform against the HIPAA Security Rule, including the addressable implementation specifications in the technical safeguards, and documents for each whether it is reasonable and appropriate to implement. Where a specification is not adopted, the record states the reason and the equivalent alternative measure. This is the entity's own decision, and DeployOpen prepares the evidence for it rather than making it. The output is a risk analysis record that the privacy and security leads approve.
Execute hosting and business associate contracts
Before any patient-related data reaches the server, the organization confirms where the analytics server runs, who administers it and which subcontractors touch it. A business associate contract must require Security Rule compliance, flow the same terms to subcontractors handling ePHI, and require reporting of security incidents. The output is an executed contract set, a hosting location record and a subcontractor list. Ask counsel to confirm the contract terms against 45 CFR 164.314.
Build and harden the analytics server
The engineering team installs the chosen platform in the organization's own environment, configures separate application and database tiers as sized for expected traffic, enforces encryption in transit and at rest, enables unique user identification, automatic logoff and an emergency access procedure, and restricts administrative access. Logging and backup settings are configured and tested. The output is a hardening record, a configuration baseline and a restore test result, all stored with the risk analysis.
Write exclusion rules and audit every tag
Engineers define which URL paths, page templates and form fields are never tracked, including authenticated portal pages, appointment and results pages, and any field that could reveal a condition or treatment. Each tag is compared against the exclusion list, and any third-party script that sends data to an ad platform is removed or blocked. The output is a tag inventory with an owner and a reason for every tag, plus signed exclusion rules. Confirm that the audit also covers CDNs and embedded widgets.
Run a staged go-live with a tag crawl
The analytics tags are first enabled on a non-production copy and then on a limited set of public pages. A crawler then walks the site to confirm that tags fire only where approved and that no excluded page sends a request to the analytics server or any other vendor. Access to the analytics dashboards is granted through the organization's identity provider with role-based groups. The output is a crawl report with zero unapproved requests, an access list and a go-live approval.
Review access and tag drift after launch
After go-live, the team reviews dashboard accounts, admin rights, server logs and the tag inventory on a schedule the organization sets. Site changes often add new scripts, so each release triggers a tag check against the approved list. The output is a post-launch review record listing access changes, tag drift found and fixes applied, which feeds the next risk analysis update. Ongoing checks can be covered by a support retainer if the organization wants them outsourced.
Evidence auditors and regulators ask for from the analytics stack
This table maps each piece of evidence an assessor or regulator may request to the analytics component that produces it. Read it as a checklist for the analytics server, tag manager and vendor files, and confirm each item with your compliance lead before the review.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Risk analysis record | ePHI locations, threats and risks for the analytics server, including the database and backups | Your risk analysis, informed by the server inventory and the data flow diagram for each tracked site |
| Access control lists and admin logs | Who holds analytics administrator, super user and report access, and when access changed | Matomo user management and the web server or database audit logs, exported to your central log store |
| Encryption configuration | TLS settings on the public tracking endpoint and admin login, and encryption of database storage and backups | Web server TLS configuration, database and disk encryption settings, and backup tool configuration |
| Backup and restore test records | That analytics data and configuration can be recovered within your stated objectives | Backup job logs plus dated restore test reports stored with the platform runbook |
| Business associate agreements | Contractual terms covering any vendor that can access ePHI, including subcontractors | Your contract file, reviewed against the terms in 45 CFR 164.314 (confirm with counsel which vendors qualify) |
| Tag and exclusion inventory | Which pages and fields are tracked, and confirmation that patient, portal and form pages are excluded | Tag manager export, site configuration exclusion lists and the change record for each rule |
| Retention settings | How long raw visit data and reports are kept, and how deletion is carried out | Platform data retention configuration and deletion job logs |
| Third-party tag review | Whether ad, social or session replay scripts load on any page that could reveal health context | Tag manager version history, page source scans and browser network test records |
Common questions about healthcare web analytics cost, effort and compliance
Does HIPAA certify Matomo or any self-hosted analytics platform?
No. There is no HIPAA certification for software or for organizations. HHS states that no Security Rule standard requires an entity to certify compliance, and that HHS does not endorse or recognize private certifications. Compliance is shown through your own risk analysis, safeguards and documentation, which the HHS Office for Civil Rights can review through complaints, compliance reviews and audits. Treat any vendor claim of HIPAA certification as a question to challenge. Ask instead what evidence supports the configuration you run, such as hardening records, access logs and documented policies, and how it maps to the Security Rule standards. HHS FAQ on certification covers the原 position in HHS's own words.
Do we need a business associate agreement for a self-hosted analytics server?
It depends on who can access electronic protected health information on that server. If your own workforce runs the analytics platform on infrastructure you control, and no outside party can access the data, a business associate contract may not be needed for that platform. If an implementation partner, hosting provider or support vendor can reach the data, or if the analytics data could contain ePHI, a business associate contract under 45 CFR 164.314(a)(2)(i) is the usual instrument. It requires Security Rule compliance, flow-down to subcontractors that handle ePHI, and incident reporting. Confirm the classification with your privacy officer and counsel before work starts, and write the access boundary into the scope.
What are the cost drivers and what should a quote include?
Cost falls into a few lines: a one-time implementation, recurring infrastructure, recurring operations and support, and internal staff time. Infrastructure and operations recur, while planning, configuration, integration and documentation are mostly one-time. The main drivers are the number of sites and portals, whether authenticated areas are separated, the identity integration, hosting in your own cloud or data center, backup and monitoring requirements, and how much evidence you need for assessments. Sizing matters: Matomo's requirements FAQ sizes a single server with at least 4 CPUs, 8 GB of RAM and 250 GB of SSD for up to 1 million pageviews a month. A quote should list deliverables, exclusions, responsibilities for each party, hosting assumptions, support terms and acceptance criteria.
How long does a healthcare analytics rollout take, and what drives the timeline?
The timeline depends on scope and approvals more than on the software install. The main drivers are the number of properties, whether portal pages need an event exclusion model, identity and network integration, the risk analysis and policy review your organization requires, and how many approval gates your change process has. Installing Matomo itself is straightforward on the published requirements, but the work of deciding what to collect and proving it is excluded is what takes time. Ask any partner for a written schedule tied to the fixed scope and named milestones, and ask which of those milestones depend on your internal reviews.
What does our team need to provide before an implementation partner starts?
Expect to provide a named technical owner, a privacy or compliance contact, access to the hosting environment or a clear target, identity provider details for any portal access, and a list of sites and sections in scope. You should also supply your current tag inventory, the pages that must be excluded (such as login, appointment, billing and results pages), your retention and access policy, and your incident contacts. Decisions on what counts as ePHI, which roles can see reports and how long data is kept need to come from your organization, not the implementer. Agree these inputs in the written scope so delays are visible early.
Can our internal IT team run a self-hosted analytics platform after go-live?
Often yes, if the team already operates web applications, a PHP and database stack, backups and patching. The recurring work includes platform updates, database maintenance, archiving jobs, access reviews, log retention, backup restore tests and monitoring. Matomo 6.0.0 requires PHP 8.1 or newer and MySQL 8.0 or newer or MariaDB 10.6 or newer, so plan for version upgrades. Confirm your team's capacity for these tasks and their on-call coverage. If capacity is thin, a retainer for upgrades, monitoring and documentation is an alternative, and DeployOpen offers ongoing support and upgrades on that basis.
Do NIS2 or GDPR change the build for a European healthcare website?
Yes, they can. NIS2 Annex I lists health as a sector of high criticality, including healthcare providers and manufacturers of certain medical devices, so the operator's security obligations may extend to the systems that support patient services. GDPR Articles 32 and 34 require appropriate security and breach handling, and in September 2026 France's CNIL fined a hospital EUR 500,000 for external access without VPN and multi-factor authentication. For analytics, that means strong access control on the analytics server and no patient data in tracked URLs or events. Confirm with local counsel whether your organization falls under NIS2 national law and how consent rules apply to your analytics settings.
What to ask an implementation partner before hiring one
Start with the HIPAA Security Rule, because it is where partners most often overstate what they can offer. Ask for examples of past work where the partner mapped a self-hosted analytics server to the Security Rule standards in 45 CFR 164.308, 164.310 and 164.312, and ask what evidence they produced: configuration baselines, access reviews, backup restore records and change logs. Then ask them to state in writing that they do not hold or offer HIPAA certification. The HHS FAQ on certification is short and worth sharing with the partner beforehand. A partner who promises a HIPAA certificate, or a seal, has misunderstood the rule, and that misunderstanding will show up later in your evidence file.
Ask how the partner documents addressable decisions. For each addressable implementation specification in the technical safeguards, such as automatic logoff or encryption, the rule requires a written assessment of whether it is reasonable and appropriate, and if it is not, a documented reason and an equivalent measure. Ask for a sample decision record from a previous engagement, with the reasoning, the owner who signed it and the review date. Also ask how the partner separates public and portal tagging, including who writes the tag exclusion rules, how they are tested on authenticated pages, and what happens when a page moves between the two zones. Request a written test script that proves exclusions work before go-live, and ask who keeps it current after changes. Finally, ask who holds administrator credentials for the analytics host and database, how those credentials are stored and rotated, whether your staff hold break-glass access, and how backups and security patches are scheduled and tested, with restore tests you can observe. Close the conversation by reading the written fixed scope line by line, confirming what happens after go-live (support hours, patch windows, response expectations and upgrade handling), and confirming who signs the business associate terms that cover the partner's access to electronic protected health information.
