# Healthcare, PHI, and PII: Using Blueprint Safely

Blueprint helps you plan and deliver **digital measurement and tagging** (GA4, GTM, frameworks, implementation guides). Use it to **design tracking that does not capture PHI** on your client’s website. Blueprint itself is not subject to healthcare data rules for *customer/patient* info, because you are not handling the healthcare org’s patient data in the app—you are handling **your** client and project info.

---

## 1. Client and project info in Blueprint: use what you need

- **Client names, project names, company names, domains, stakeholder names:** These are **your** engagement and project data, not the healthcare org’s patient/customer data. Use them freely so the app works (e.g. “Acme Health – GA4”, “Sarah Chen – Marketing”).
- **Notes, implementation guides, frameworks:** Describe scope, events, and handoff in normal consulting terms. No need to anonymize client or project identity inside Blueprint.

**What must stay out:** **Patient or end-user PHI/PII**—information that identifies or describes the healthcare org’s patients or website users (e.g. patient records, clinical details, identifiable health information). Do not paste that into Blueprint.

- **AI Extract:** Text you paste or import is sent to an AI provider. **Do not paste documents that contain patient PHI or end-user PII** (e.g. meeting notes with patient details, RFPs with identifiable health information). Use high-level or anonymized summaries for extraction. Normal project briefs and RFPs that describe scope and objectives (without patient data) are fine.

If your organization requires a BAA for systems that touch PHI, Blueprint stays out of that scope when you use it only for client/project info and never put patient or end-user PHI in it.

---

## 2. Design measurement on the client’s website to be PHI/PII-free

The **events and parameters** you define in Blueprint (and later implement on the healthcare org’s site in GA4, GTM, etc.) must not capture or expose **patient or end-user** PHI or PII.

- **Event and parameter names and values:** Avoid anything that could hold or imply health conditions, diagnoses, treatments, medications, or identifiers (e.g. MRN, full DOB, precise location in a small population). Prefer generic names: e.g. `form_submit`, `cta_click`, `video_progress`, `location_search` with non-identifying dimensions only.
- **Cross-domain and identity:** If you link domains or use identifiers, ensure you have a clear legal basis, consent where required, and that no PHI is passed. For patient-facing portals, tracking is often minimal or prohibited; use Blueprint to document only what is approved.
- **Consent and tagging:** Blueprint does not implement consent or tag suppression. Document in your implementation guides and checklist that consent must be implemented in your CMP/tag manager and that tags must not fire before appropriate consent.

Use the **Measurement Framework** and **Implementation Guides** to define a **PHI-free taxonomy** and to get privacy/compliance review before go-live.

---

## 3. Governance and compliance

- **Privacy and compliance review:** Use Blueprint’s framework export and implementation checklist to show exactly what will be measured. Have privacy, compliance, or legal review the plan (events, parameters, domains) before implementation.
- **Checklist:** Include steps such as: “Confirm no PHI/PII in event/parameter definitions”, “Privacy/compliance sign-off obtained”, “Consent and tag suppression verified before go-live.”
- **BAAs and platforms:** Blueprint does not store PHI when used as above. BAAs and data processing terms apply to the systems that *do* process data (e.g. GA4, GTM, your CMS). Ensure those are in place for the environments where data is collected.

---

## 4. Quick reference

| Do | Don’t |
|----|--------|
| Use client names, project names, and stakeholder info in Blueprint—you need them for the app | Put **patient** or **end-user** PHI/PII in Blueprint (e.g. patient records, identifiable health info) |
| Use Blueprint to design tracking that does not capture PHI on the client’s website | Design events or params that could hold health data or identifiers on the site |
| Paste project briefs and RFPs into AI Extract when they don’t contain patient/PHI | Paste meeting notes or docs that contain patient/end-user PHI into AI Extract |
| Get privacy/compliance sign-off on the **measurement plan** (what goes on the website) | Assume Blueprint itself needs a BAA—it’s for your client/project info, not patient data |
| Document consent and tag suppression in guides and checklist | Rely on Blueprint to enforce consent (it doesn’t) |

---

For full product guidance, see [BLUEPRINT_GUIDE.md](BLUEPRINT_GUIDE.md) and [USER_GUIDE.md](USER_GUIDE.md).