HIPAA

How does Areev detect Protected Health Information?

Areev detects PHI using regex patterns covering all 18 HIPAA Safe Harbor identifiers, with optional NER model inference for higher accuracy. When the HIPAA policy is active, this context database blocks grains containing PHI at write time unless valid consent exists, protecting AI memory from unauthorized health data storage.

The 18 identifiers include names (3 formats: honorific, last-first, bare full name), geographic data (zip codes, street addresses, city+state), dates beyond year (including dates of birth), ages over 89, phone numbers, fax numbers, email addresses, SSNs (dash, space, dot, and compact formats), medical record numbers, IP addresses, credit cards, and additional identifiers. Detection is hardened against evasion: Base64 payloads are decoded and scanned, Unicode homoglyphs are NFKC-normalized, and zero-width characters are stripped. The dual-source detection (regex + NER) reports confidence scores and detection source for each match.

import requests

# On-demand PHI detection
resp = requests.post("http://localhost:4009/api/memories/default/detect-pii", json={
    "content": "Patient John Smith, DOB 1955-03-15, MRN 12345678"
})
detections = resp.json()  # PHI patterns with confidence scores

areev detect-pii "Patient John Smith, DOB 1955-03-15, MRN 12345678"

How does the BAA gate work (164.308(b))?

When tiered storage is configured with the HIPAA policy, Areev requires explicit acknowledgment of a Business Associate Agreement (BAA) with the cloud sub-processor. Without baa_acknowledged: true, the HIPAA policy blocks tiered storage entirely — PHI cannot leave the local storage tier without a BAA in place.

This autonomous memory system records a DpaAcknowledged audit event at engine startup that captures both the GDPR Art. 28 DPA and HIPAA 164.308(b)(1) BAA references. The hipaa_baa_registry compliance check verifies that the BAA acknowledgment is present whenever tiered storage and the HIPAA policy are both active. This prevents AI agent memory from silently exfiltrating PHI to cloud storage without the required legal framework.

# Configure tiered storage with BAA acknowledgment
areev serve --http 0.0.0.0:4011 \
  --policy hipaa \
  --warm-backend s3 --warm-bucket my-phi-bucket \
  --baa-acknowledged

POST /api/memories/default/verify/run HTTP/1.1
Host: localhost:4009
# Response includes hipaa_baa_registry check status

How does minimum necessary access work (164.514(d))?

Areev enforces the HIPAA minimum necessary standard through policy-level access controls and Zanzibar-style authorization tuples. The policy engine restricts recall operations to return only grains the requesting user is authorized to access in this context database.

Enforcement follows four steps: policy check (user has appropriate role for PHI access), authz check (Zanzibar tuple grants read permission), consent check (data subject has granted processing consent), and audit (every access, granted or denied, is logged). Failed access attempts produce AccessDenied audit events with the principal, permission, and resource, providing the audit controls required by HIPAA 164.312(b). LLM reranking is hard-blocked under the HIPAA policy to prevent PHI from being sent to external services.

Minimum necessary enforcement:
  1. Policy check: user has appropriate role for PHI access
  2. Authz check: Zanzibar tuple grants read permission
  3. Consent check: data subject has granted processing consent
  4. Audit: every access (granted or denied) is logged

Access denied -> AccessDenied audit event (HIPAA 164.312(b))

What HIPAA-specific compliance checks does Areev run?

Areev includes 8 HIPAA-specific compliance verification checks that are evaluated when the HIPAA policy preset is active. These complement the 39 core checks (encryption, erasure, audit, blind index, policy, authz) which also satisfy HIPAA requirements.

Each check maps to a specific HIPAA section, ensuring this AI memory system can produce audit-ready evidence for each regulatory requirement. The checks cover Safe Harbor 18 identifier detection (hipaa_safe_harbor, §164.514(b)(2)), minimum necessary principle (hipaa_minimum_necessary, §164.514(d)), emergency break-glass access (hipaa_emergency_access, §164.308(a)(7)), breach lifecycle tracking (hipaa_breach_notification, §164.400-414), BAA registry (hipaa_baa_registry, §164.308(b)), session audit events (hipaa_session_management, §164.312(a)(d)), encryption-based access controls (hipaa_access_controls, §164.312(a)), and workforce training tracking (hipaa_workforce_training, §164.308(a)(5)).

Related

• Policy: Configuring the HIPAA policy preset
• Encryption: AES-256-GCM encryption details
• Audit Trail: HIPAA 164.312(b) audit controls
• Compliance: Full compliance verification overview