Built to be defensible, not just compliant-sounding.
"We anonymize your data" is a marketing sentence. This page is the engineering behind ours: the rules the relay enforces, what each vendor can and cannot receive, and where your data actually lives.
Why the bar is this high
Tracking pixels on health sites are an active enforcement target.
HHS OCR
OCR's online-tracking guidance treats "this person visited a health page" — IP address plus page URL — as a disclosure that needs either a BAA or authorization. Ad networks sign neither.
FTC
The FTC charged both companies over sharing health data with ad platforms — under the FTC Act and the Health Breach Notification Rule, which apply even to businesses HIPAA doesn't cover.
Civil courts
Hospitals and telehealth companies have paid multi-million-dollar settlements over the exact data path the standard Meta pixel and GA tag create. The disclosure is per-page browsing — which is why minusPHI never forwards it.
The four hard rules
Enforced in code on every event — not policies, properties.
Only enumerated event names forward; within them, only whitelisted fields survive, and every value is scrubbed. An unknown field is dropped, never "passed through just in case" — so a new vendor field can't quietly start leaking.
A page classified as anything but public marketing — including "unknown" — is suppressed. Any error suppresses. A health-condition term anywhere in the URL suppresses, because the visited-condition signal is the sensitive fact.
IP addresses are dropped entirely, not truncated. Hashed names, emails and phone numbers don't go out either: the FTC treats hashing as not de-identification, and so do we.
An independent assertion inspects every outgoing event and confirms it's clean before it leaves — separate from the classifier that let the event through. If the check trips, the event is suppressed. Clean by construction, verified by a second opinion.
What each destination can receive
The complete matrix — there is no fine print below it.
| Signal | Google Analytics (GA4) | Meta (Conversions API) |
|---|---|---|
| Page views | ✓ origin + path, marketing pages only | ✓ origin only — never which page |
| Traffic sources | ✓ referrer origin, health-gated | — |
| Conversions | ✓ Lead / Schedule / Contact | ✓ Lead / Schedule / Contact |
| Local intent | — | ✓ directions clicks (FindLocation) |
| Scroll & form-start | ✓ | ✕ never |
| Ad-click ID (gclid / fbclid) | conversions only, opt-in | conversions only, opt-in |
| IP / device / cookies | ✕ never | ✕ never |
| Name / email / phone — hashed or not | ✕ never | ✕ never |
| Identity field | random first-party ID | hash of a random ID — not contact info |
Per-page browsing — "this person viewed the HIV-testing page" — is the disclosure at the center of every pixel lawsuit. The relay cuts the URL on every Meta-bound event down to the bare domain, and the self-check rejects any event whose URL still carries a path. What Meta gets is activity volume and conversions; per-page browsing cannot be reconstructed from it.
Where your data lives
Raw events touch exactly one place — and it's BAA-eligible.
The tag posts events directly to the relay on AWS — the one environment where raw, pre-de-identification events may exist, operable under the AWS Business Associate Addendum. No third-party proxy sits in the path.
The CDN at the edge serves only assets that can't contain patient data — this website, the dashboard, the tag's JavaScript file. Patient traffic never flows through it.
Your GA4 secret and Meta access token are encrypted at rest with a customer-managed AWS KMS key, and dashboard sign-in uses passwordless email codes — no passwords to breach.
Everything legally load-bearing lives in one isolated module with no network or database
access: event in, verdict out — forward with a clean payload, or
suppress. That makes it exhaustively unit-testable, and it is: the de-identification
core is covered by an extensive automated test suite that runs on every change, including
adversarial cases like PII smuggled inside nested fields and condition terms in URLs.
HIPAA & BAAs
We'll sign one — and our job is to make sure Google and Meta don't need to.
Because the relay may receive website events before de-identification, minusPHI can act as a business associate and will enter into a Business Associate Agreement with customers who require one. Email hello@minusphi.com to request it.
A BAA is required when a vendor receives PHI. The relay's entire purpose is to make sure Google and Meta never do: events are de-identified to HIPAA Safe Harbor before either sees anything, and sensitive pages are suppressed outright.
What this isn't
The limits, stated plainly.
minusPHI is engineering, not counsel. It controls exactly what data leaves your site; your compliance program — policies, risk analyses, training — is still yours to run.
Visitor retargeting inherently requires handing Meta the browsing data this product exists to protect, so it's off the table. Vendors promising HIPAA-safe retargeting are fudging one of the two.
Consent pop-ups ask patients to approve the leak; minusPHI removes it. The two can coexist, but a banner alone doesn't stop a pixel from reporting page views to an ad network.
Show this page to your compliance officer. Then take five minutes to install it.
Start freeNo credit card required · BAA available on request