# Usage: curl -sSL https://seed.show/healthcare.hipaa.us | bash -s <install-path>
# <install-path> is the directory where the file should land.

set -euo pipefail
[ -z "${1:-}" ] && {
  echo "install requires a path: curl -sSL https://seed.show/healthcare.hipaa.us | bash -s <install-path>" >&2
  exit 1
}
TARGET="$1"
mkdir -p "$TARGET"
DEST="$TARGET/seed-fold.P23nPl.folded.md"

cat > "$DEST" <<'PORTDOWN_3B0A584C'
<!--
This is a `.folded.md` archive — a directory packed into one markdown
file. The markers below are load-bearing; don't edit them directly.

To unpack (requires bash — if you have no shell, tell the user):
  1. curl -sSLf https://fold.dom.vin/skill | bash -s <INSTALL_DIR>
  2. <INSTALL_DIR>/fold/scripts/unfold <this-file>
     (or: unfold <this-file>  if fold/scripts is on your PATH)
-->

---
fold: true
marker: e1b2a4
at: 2026-05-07T16:16:07Z
root: seed-pack.D59ncm
---

<!--fold:e1b2a4@file path="README.md" mode="644"-->
# healthcare.hipaa.us

HIPAA compliance context for agents. Orientation only — not legal advice, not a compliance opinion. Use this to understand the framework before engaging with any PHI handling, BAA requirement, security safeguard, or breach response question.

**What not to do:** Do not render a compliance opinion. Do not tell a covered entity or business associate that they are compliant. Do not tell a user their specific situation is covered or not covered by HIPAA without recommending they confirm with counsel or a compliance officer. HIPAA facts are stable; their application to a specific fact pattern is a legal question.

---

## Mental model

HIPAA is a **privacy and security framework** built on three interlocking rules. Every compliance question maps to one of them. The Privacy Rule governs *what* may happen to PHI. The Security Rule governs *how* ePHI must be protected. The Breach Notification Rule governs *what must happen* when PHI is impermissibly used or disclosed.

**Privacy Rule** — governs who can use or disclose Protected Health Information (PHI) and under what conditions. Defines covered entities, what counts as PHI, when disclosure is permitted without authorization (treatment, payment, healthcare operations), and patient rights (access, amendment, accounting of disclosures). If the question is "can we share or use this information?" it's a Privacy Rule question.

**Security Rule** — governs administrative, physical, and technical safeguards for electronic PHI (ePHI). Applies *only* to ePHI (PHI stored or transmitted electronically) — not paper records. Specifications are either "required" (must implement as written) or "addressable" (must implement, or document why not reasonable and appropriate and implement an equivalent alternative). If the question is "how must this system protect health data?" it's a Security Rule question.

**Breach Notification Rule** — governs covered entity and business associate obligations when unsecured PHI is impermissibly used or disclosed. A breach presumption applies unless the covered entity or BA demonstrates a low probability that PHI was compromised, assessed via a four-factor risk analysis. If the question is "what must we do now that something went wrong?" it's a Breach Notification question.

---

## What agents get wrong

**1. PHI vs. PII — different frameworks, different obligations.**
PHI is health information that is linked (or linkable) to an individual's identity via any of the 18 HIPAA identifiers. HIPAA does not use the term PII. Agents conflate them and apply HIPAA analysis to non-health data or apply generic PII/GDPR/CCPA analysis to health data that requires HIPAA treatment. When health information is present, first ask: is this linked to one of the 18 identifiers? If yes, apply HIPAA. PII frameworks are a separate, parallel question — not a substitute.

The 18 PHI identifiers: names; geographic data smaller than a state (address, city, ZIP, county, precinct); dates other than year related to an individual (DOB, admission, discharge, death); phone numbers; fax numbers; email addresses; Social Security numbers; medical record numbers; health plan beneficiary numbers; account numbers; certificate/license numbers; vehicle identifiers and serial numbers including license plates; device identifiers and serial numbers; web URLs; IP addresses; biometric identifiers (fingerprints, voiceprints); full-face photographs and comparable images; any other unique identifying number, characteristic, or code.

**2. BAA scope is wider than most assume.**
A Business Associate (BA) is any person or entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity in the course of performing certain functions. The operative phrase is "on behalf of" — not "understands health data" or "is in healthcare." Cloud storage providers holding ePHI are BAs. Email providers routing messages containing PHI are BAs. Analytics platforms processing logs containing PHI are BAs. A BAA must be in place *before* PHI touches any of these systems. Standard SaaS terms do not constitute BAAs. Vendors without a BAA offering cannot lawfully receive PHI regardless of their security posture. Agents frequently miss this and assume a vendor's SOC 2 certification substitutes for a signed BAA — it does not.

**3. Minimum necessary — access permission is not use permission.**
Covered entities must make reasonable efforts to limit PHI use, disclosure, and requests to the minimum necessary to accomplish the intended purpose. "We have a BAA" and "the patient authorized access" do not open all PHI for all purposes. A clinician authorized to access a patient record for treatment cannot pull it for research without separate authorization. An analytics pipeline authorized to process claims for payment operations cannot also ingest diagnosis codes for product development. Agents building workflows routinely assume that downstream uses inherit the authorization for the initial access. They do not.

**4. "Addressable" does not mean "optional."**
The Security Rule's addressable specifications require implementation as written, or documented justification for why it is not reasonable and appropriate plus an equivalent alternative measure, or documentation that neither is needed given the specific environment. Failing to implement an addressable specification without documentation is a Security Rule violation. Commonly skipped without documentation: automatic logoff, encryption and decryption, audit controls for ePHI access. Agents reading "addressable" as "skip if inconvenient" are producing incorrect compliance assessments.

**5. De-identification is not a judgment call.**
HIPAA defines two and only two de-identification methods: Expert Determination (a qualified statistical expert certifies that risk of re-identification is very small) and Safe Harbor (removal of all 18 identifiers plus any other codes that could identify an individual, with no actual knowledge of remaining identifiability). "Looks anonymized" is not de-identification. Removing name and SSN while retaining ZIP, DOB, and diagnosis codes does not meet Safe Harbor. Agents treating de-identification as a generic data masking exercise consistently miss the standard. Once de-identified under a recognized method, the data is not PHI and HIPAA does not apply — but the de-identification method must be defensible.

**6. State preemption — HIPAA is a floor, not a ceiling.**
States can enact health privacy laws more protective than HIPAA, and those stricter laws preempt HIPAA where they conflict. California's Confidentiality of Medical Information Act (CMIA) and Genetic Information Privacy Act (GIPA) impose stricter consent requirements, different breach timelines, and private rights of action. New York's SHIELD Act layers additional requirements. Texas, Washington, and other states have enacted health-specific statutes since 2022 that impose obligations beyond HIPAA. Confirming HIPAA compliance has not confirmed state law compliance. Always flag this gap when assessing operations in a specific state.

---

## What AI is changing

**PHI in AI training data.** Using PHI to train, fine-tune, or improve an AI model is a use of PHI that must be authorized under the Privacy Rule. Training a model on patient records requires a valid authorization from each patient, a research waiver from an IRB or Privacy Board, or a determination that the data has been de-identified under the two recognized methods. Covered entities that share patient data with AI vendors for "model improvement" without a proper BAA and valid authorization are creating Privacy Rule exposure. OCR has explicitly flagged this in enforcement guidance.

**BAAs with AI vendors.** Feeding ePHI to a third-party AI model — including general-purpose LLMs — via API makes that vendor a Business Associate if the data is PHI. Many AI vendors offer BAA-covered tiers or products; standard consumer and developer tiers typically do not include a BAA. Agents that recommend integrating PHI-containing data with external AI APIs must check whether a BAA is in place for that specific product tier. A BAA with one product line of a vendor does not extend to all of that vendor's offerings.

**De-identification for AI datasets.** Health organizations are building AI training sets by attempting to de-identify EHR data. Safe Harbor de-identification of structured fields is well-understood; removing PHI from clinical notes and unstructured text is harder. Models trained on improperly de-identified data carry re-identification risk, particularly when the model can be queried to extract training data. Expert Determination de-identification — the other recognized HIPAA method — requires a qualified statistician to assess re-identification risk for the specific dataset and intended use. Generic NLP-based de-identification tools do not constitute Expert Determination without that assessment.

**What human oversight still owns.** OCR enforcement decisions, breach risk assessments, PHI authorization reviews, BAA negotiation, and state preemption analysis require legal judgment that AI cannot substitute for. The four-factor breach risk analysis (nature and extent of PHI involved; who used or could have used the PHI; whether PHI was actually acquired or viewed; extent to which risk has been mitigated) is a legal determination with enforcement consequences — AI assessment is at best preliminary input. BAA scope and adequacy require contract review. State preemption requires knowing which state health privacy statutes apply to a given operation. These are orientation inputs to human decision-making, not outputs from AI analysis.

---

## Stable reference facts

**Covered entity types**
- Health plans (insurance companies, HMOs, employer health plans, government programs including Medicare and Medicaid)
- Health care clearinghouses (entities that translate nonstandard health information into standard formats, or vice versa)
- Health care providers who transmit any health information in electronic form in connection with a covered transaction (even occasionally — a physician who submits a single electronic claim is a covered entity)

**Breach notification deadlines**
- Affected individuals: no later than 60 calendar days after discovery of the breach
- HHS: within 60 days for breaches affecting 500 or more individuals; annually by March 1 of the following calendar year for breaches affecting fewer than 500 individuals
- Media: for breaches affecting 500 or more residents of a state or jurisdiction, concurrent with individual notification
- Business associates: must notify covered entities without unreasonable delay, and no later than 60 days after discovery

**Business associate agreement minimum required contents**
A BAA must: describe permitted uses and disclosures of PHI by the BA; require the BA to not use or disclose PHI other than as permitted; require appropriate safeguards; require reporting of breaches and security incidents; require compliance with the Security Rule; address return or destruction of PHI at termination; and require downstream subcontractors to agree to the same restrictions.

**The four-factor breach risk assessment**
Before treating an impermissible use or disclosure as a reportable breach, a covered entity or BA must conduct a risk assessment covering: (1) the nature and extent of the PHI involved, including types of identifiers and likelihood of re-identification; (2) who used the PHI or to whom it was disclosed; (3) whether the PHI was actually acquired or viewed; (4) the extent to which the risk has been mitigated. If this assessment demonstrates low probability of compromise, the incident may not require breach notification — but the assessment must be documented.
<!--fold:e1b2a4@file path="failure-modes.md" mode="644"-->
# HIPAA Compliance Failure Modes

The most common HIPAA compliance failures — structural breakdowns that generate enforcement actions, breach notifications, and civil liability. Includes the enforcement pattern OCR typically follows for each.

---

## Failure mode 1: Missing or incomplete Business Associate Agreements

**What it is.** PHI is transmitted to, stored by, or processed by a vendor without a signed BAA in place, or with a BAA that does not cover the actual data flows.

**How it manifests.** A covered entity executes a BAA with a cloud storage vendor but not with the analytics platform that reads data from that storage. A BA uses a subcontractor to perform functions involving PHI without a downstream BAA (every subcontractor BA must also sign a BAA). An organization upgrades from one product tier to another — the BAA covered the old tier, not the new one. A general-purpose AI API is used to process clinical notes; no BAA exists because the AI vendor's standard tier doesn't offer one. The gap is often invisible until a breach investigation surfaces the data flow.

**Enforcement pattern.** OCR investigates BAA gaps as a Privacy Rule and Security Rule violation. Resolution agreements frequently require: a corrective action plan (CAP) mandating a comprehensive audit of all vendor relationships, BAA remediation for every identified gap, and annual BAA review. The covered entity or BA cannot shift liability to the vendor — both can be separately investigated and penalized. OCR has repeatedly held that the absence of a BAA is itself a violation, separate from whether any PHI was actually misused.

---

## Failure mode 2: Improper access controls and insufficient workforce training

**What it is.** ePHI is accessible to workforce members beyond what their roles require (minimum necessary failure), or workforce members who do handle PHI have not received required HIPAA training.

**How it manifests.** EHR systems with role-based access configured too broadly — billing staff can view clinical notes; administrative staff can access records for patients they have no treatment relationship with. No audit log review process to detect inappropriate access. Workforce members who click phishing links because they were never trained to recognize them, resulting in credential compromise and ePHI exposure. New hires who handle PHI before completing HIPAA training. Remote access to ePHI without VPN or multi-factor authentication.

**Enforcement pattern.** Workforce training and access control failures typically emerge from breach investigations — the breach is the presenting event, and investigation reveals the underlying control failures. OCR's CAPs for these cases require: updated and documented workforce training program with completion tracking; role-based access control audit and remediation with documentation of access decisions; implementation of audit controls to detect inappropriate access; and often a third-party monitoring arrangement. Workforce training violations are among the most frequently cited in OCR resolution agreements.

---

## Failure mode 3: Breach misclassification — security incident vs. reportable breach

**What it is.** A covered entity or BA discovers a security incident involving PHI and classifies it as a non-reportable security incident without properly conducting the four-factor breach risk assessment, resulting in failure to notify affected individuals, HHS, and potentially media.

**How it manifests.** An employee's laptop containing unencrypted ePHI is stolen. The organization concludes the thief was only interested in the hardware, not the data, and does not report. The four-factor analysis was never documented. An unauthorized user accesses a patient portal and views records; the organization determines it was probably an accidental login and doesn't investigate whether PHI was viewed. A ransomware attack encrypts ePHI; the organization pays the ransom and concludes no breach occurred because the data was "returned" — but access by the attacker was not assessed.

**Enforcement pattern.** Breach misclassification cases often surface when affected individuals learn of exposure through other channels and complain to OCR, or when OCR's breach portal reviews prompt follow-up. The enforcement problem is compounded: the original incident plus the failure to notify. OCR requires the four-factor risk assessment to be documented contemporaneously — a post-hoc assessment created after OCR inquiry is treated skeptically. CAPs require: a breach risk assessment policy and procedure; staff training on the four-factor test; documentation retention requirements. Notification failures carry separate penalty exposure beyond the underlying Security Rule violation.

---

## Failure mode 4: Social media and incidental disclosure violations

**What it is.** Workforce members disclose PHI through social media, public communications, or in settings where unauthorized individuals can overhear or observe — either directly or by confirming a patient's treatment status to someone who asks.

**How it manifests.** A nurse posts about a recognizable patient's condition on a personal social media account, even without using the patient's name (sufficient identifiers remain). A hospital employee responds to a media inquiry confirming that a named individual is a patient. A front-desk worker discusses a patient's appointment details in a waiting room where others can hear. A physician mentions a patient's condition to the patient's employer without authorization. Photographs taken in clinical settings that incidentally capture patient information on whiteboards or screens.

**Enforcement pattern.** Social media violations are frequently identified through patient or family complaints. OCR enforcement patterns for these cases include: workforce sanctions (the individual involved may be disciplined or terminated), and organizational sanctions if there was no workforce training or policy prohibiting the conduct, or if the policy existed but was not enforced. Covered entities have been held responsible for workforce member social media disclosures when the disclosure stemmed from a systemic failure in training and sanction policy. Minimum necessary applies to what workforce members share even within the organization.

---

## Failure mode 5: Impermissible use of PHI for marketing

**What it is.** A covered entity uses PHI to send marketing communications without a valid patient authorization, or relies incorrectly on the treatment/operations exceptions to marketing authorization requirements.

**How it manifests.** A covered entity receives remuneration from a pharmaceutical manufacturer to send patients messages about the manufacturer's drugs, classifying this as "health promotion" rather than marketing. A health plan sells member data to third-party wellness vendors who then contact members with product offers. A provider sends appointment reminders that include promotional content about elective procedures not related to the patient's treatment. A business associate uses PHI it holds on behalf of a covered entity to market its own products to patients.

**Enforcement pattern.** Marketing violations often originate from patient complaints or investigative journalism. OCR enforcement is particularly aggressive on financial remuneration cases — if the covered entity received payment (directly or indirectly) to communicate with patients about a product or service, the marketing authorization requirement almost always applies. CAPs typically require: audit of all current vendor arrangements involving patient outreach; written policies distinguishing treatment communications, healthcare operations communications, and marketing; and patient notification if impermissible marketing communications were sent. The covered entity cannot rely on its BA's assurance that a communication qualified as operations.

---

## Failure mode 6: Inadequate breach response and notification timing

**What it is.** A covered entity discovers a breach but fails to notify affected individuals within 60 calendar days of discovery, or fails to notify HHS, or provides notification that is incomplete — missing required content about what happened, what PHI was involved, what the entity is doing, and how individuals can protect themselves.

**How it manifests.** An organization discovers a breach but delays notification while conducting an investigation, hoping to narrow the scope of affected individuals — and the investigation extends past 60 days. A breach affecting 498 individuals (below the 500 threshold) is put in the annual log and never sent to individuals. A BA discovers a breach and delays notifying the covered entity because the BA wants to investigate first — but the 60-day clock runs from the BA's discovery, not the covered entity's. Notification letters are sent but do not include the required content elements (description of what happened, types of PHI involved, steps individuals can take to protect themselves, description of what the covered entity is doing, contact information).

**Enforcement pattern.** Late notification is one of the most straightforward HIPAA violations to establish — the discovery date and the notification date are both documented. OCR has brought enforcement actions for notification delays of weeks, not just months. The clock runs from "discovery" — which OCR interprets as when the covered entity knew or, by exercising reasonable diligence, should have known of the breach. Deliberate delay to investigate does not pause the clock. CAPs for notification failures require: incident response plans with explicit 60-day milestone tracking; breach notification templates that satisfy content requirements; and often a third-party incident response engagement for major breaches.
<!--fold:e1b2a4@file path="sources.md" mode="644"-->
# sources

Fetch these at task time. Ordered by importance. OCR enforcement guidance and penalty tables change — fetch before assessing any enforcement risk question.

1. HHS OCR — HIPAA Privacy Rule summary. Authoritative overview of covered entities, PHI definitions, permitted uses and disclosures without authorization (treatment, payment, operations), and patient rights:
   https://www.hhs.gov/hipaa/for-professionals/privacy/laws-regulations/index.html

2. HHS OCR — HIPAA Security Rule guidance. Required and addressable specifications, administrative/physical/technical safeguard categories, implementation standards:
   https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html

3. HHS — Breach Notification Rule. Breach presumption, four-factor risk assessment, notification deadlines, business associate obligations, the "unsecured PHI" definition:
   https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html

4. HHS — Business associate guidance and sample BAA language. Who qualifies as a BA, what a BAA must contain, model agreement language, subcontractor BA chain:
   https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/business-associates/index.html

5. HHS — De-identification guidance. Expert Determination and Safe Harbor methods, the 18 identifiers under Safe Harbor, re-identification risk framework:
   https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html

6. HHS — HIPAA FAQs for professionals. Authoritative Q&A on edge cases: minimum necessary standard, incidental disclosures, research exceptions, marketing, fundraising, psychotherapy notes:
   https://www.hhs.gov/hipaa/for-professionals/faq/index.html

7. HHS OCR — HIPAA enforcement actions and resolution agreements. Current enforcement priorities, recent penalty settlements, and corrective action plan patterns:
   https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/index.html

8. HHS OCR — Guidance on HIPAA and AI (check for new publications). OCR has issued guidance on AI vendor BAA requirements and use of PHI in model training. Fetch before advising on any AI/PHI integration question:
   https://www.hhs.gov/hipaa/for-professionals/special-topics/index.html
<!--fold:e1b2a4@end-->
PORTDOWN_3B0A584C

# ── post ──
MARKER=$(awk '/^---$/ { f++; if (f==2) exit; next } f==1 && /^marker:[[:space:]]/ { sub(/^marker:[[:space:]]+/, ""); print; exit }' "$DEST")
[ -z "$MARKER" ] && { echo "seed: archive has no marker — corrupt" >&2; exit 1; }
awk -v m="$MARKER" -v outdir="$TARGET" '
  BEGIN {
    # Match <!--fold:<m>@file path="X"--> with an optional mode attr after
    # the path (fold emits  mode="644"  on executables).
    file_re = "^<!--fold:" m "@file path=\"([^\"]+)\"( mode=\"[0-9]+\")?-->$"
    end_re  = "^<!--fold:" m "@end-->$"
  }
  $0 ~ end_re { if (current) close(current); exit }
  $0 ~ file_re {
    if (current) close(current)
    line = $0
    sub(/^<!--fold:[^@]+@file path="/, "", line); sub(/".*$/, "", line)
    current = outdir "/" line
    dir = current; sub(/\/[^\/]*$/, "", dir)
    if (dir != current) system("mkdir -p \"" dir "\"")
    printf "" > current
    next
  }
  current { print >> current }
' "$DEST"
SEED_EXTRACTED=$(find "$TARGET" -type f -not -path "$DEST" 2>/dev/null | wc -l)
if [ "$SEED_EXTRACTED" = "0" ]; then
  echo "seed: archive contained no files — refusing to delete the source" >&2
  echo "  archive preserved at: $DEST" >&2
  exit 1
fi
rm -f "$DEST"

echo "" >&2
echo "✓ seed unpacked → $TARGET ($SEED_EXTRACTED files)" >&2
find "$TARGET" -type f | sort | while IFS= read -r _sf; do
  echo "  ${_sf#${TARGET}/}" >&2
done
echo "" >&2
if [ -f "$TARGET/SKILL.md" ]; then
  echo "This seed contains a skill (SKILL.md). Install it in your agent's skills directory." >&2
  echo "" >&2
fi
echo "Install the seed skill if not already installed:" >&2
echo "  https://seed.show/skill" >&2
echo "" >&2
echo "Publisher prompt:" >&2
sed 's/^/  /' >&2 <<'__SEED_PROMPT_END_AC1F2B__'
You have HIPAA compliance context across three files. Read README.md for the mental model and the six most common agent errors (BAA scope, minimum necessary, de-identification, addressable specs, state preemption, and the new AI/PHI section). Read failure-modes.md for the six enforcement patterns OCR follows. Fetch sources.md and pull the HHS OCR sources relevant to the question before assessing anything. Orientation only — never render a compliance opinion. Ask what HIPAA situation to work through.
__SEED_PROMPT_END_AC1F2B__
exit 0