The problem: healthcare AI agents handle PHI every session
A patient asks your clinical AI assistant about their medication schedule. The agent responds correctly. Three days later, the same patient returns with a follow-up question. The agent has no memory of the prior session. The patient repeats themselves. The clinical workflow breaks.
This is the state of most healthcare AI deployments today — and it's not a product failure. It's a compliance decision made without a good alternative.
Healthcare AI teams face a genuine constraint: AI agent memory requires storing what agents learned, and what agents learn in clinical contexts is PHI. Patient names, dates of birth, diagnoses, medication histories, appointment preferences — all protected under HIPAA.
Most teams choose one of two inadequate paths:
- Delete everything after each session. Compliant, but clinically useless. Every session starts from zero. The agent can't build the longitudinal understanding that makes AI assistants actually valuable in healthcare.
- Store raw session data. Functional, but a HIPAA violation waiting to happen. Raw PHI in an AI memory store, without access controls, audit logs, and retention enforcement, is an exposure incident with a fuse.
There's a third path. It requires a specific approach to how PHI is handled before it reaches storage — and it's what makes HIPAA-compliant persistent AI memory possible.
Why deletion doesn't work for clinical AI
The "just delete it" approach seems safe. It's not sustainable for clinical use cases.
Consider what persistent memory actually enables for a healthcare AI agent:
- A patient mentions they're allergic to penicillin. The agent never asks again.
- A patient prefers morning appointments. The agent factors this into scheduling recommendations automatically.
- A chronic care patient has been managing their condition for 18 months. The agent has context on their history, not just today's chief complaint.
- A high-anxiety patient responded poorly to a specific communication style. The agent adapts without the patient having to explain their preferences again.
None of this works if memory is session-scoped. The clinical value of AI assistants in longitudinal care — the entire rationale for deploying them — requires cross-session continuity.
Deleting PHI after every session doesn't protect patients. It just makes the AI tool so limited it's not worth using.
Deterministic tokenization: cross-session continuity without PHI storage
The solution is to transform PHI into tokens before storage — using a deterministic process that produces the same token for the same input every time.
This matters for a specific reason: same patient, same token. If "John Smith DOB 1974-03-19" always hashes to PAT-7f3a2c, then the agent can retrieve all memories associated with that patient across every session — without ever storing "John Smith" or "1974-03-19" in the memory database.
How it works:
- Session data arrives with raw PHI embedded in context.
- PII detection identifies protected fields: names, DOBs, MRNs, diagnoses, medication names tied to individuals.
- HMAC-SHA256 tokenization maps each identified PII element to a deterministic token using a secret key. Same input → same token, always.
- Redacted context is stored: PHI is replaced with tokens or redaction markers. The memory database never contains raw PHI.
- Retrieval uses the same tokenization process. The agent presents the patient identifier → gets the same token → retrieves all memories associated with that token.
The patient's longitudinal context is preserved. The memory store contains no PHI. HIPAA-covered entities can audit exactly what was stored and retrieved for each token.
Implementation: writing HIPAA-safe memory with the TCL API
Trace Continuity Labs applies tokenization at the infrastructure layer. When your agent writes a memory, PII detection and tokenization happen before anything reaches storage. Here's a complete example:
Step 1: Write memory — PII is tokenized automatically
const response = await fetch("https://tracecontinuity.com/v1/memories", {
method: "POST",
headers: {
"Authorization": "Bearer mnm_your_api_key",
"Content-Type": "application/json"
},
body: JSON.stringify({
agent: "clinical-intake",
content: "Patient Jane Doe (DOB: 1982-07-14, MRN: 4422981) reports penicillin allergy. Prefers morning appointments. Currently on lisinopril 10mg.",
retention: "365d"
})
});
const memory = await response.json(); // memory.id — the stored memory ID // Stored content: "Patient [NAME_TOKEN_a3f9] (DOB: [DATE_TOKEN_b7c1], MRN: [MRN_TOKEN_d2e8]) reports penicillin allergy. Prefers morning appointments. Currently on lisinopril 10mg." // Governance event logged: pii_redacted, 3 PII types detected, token prefixes recorded
What happened: The API received raw PHI, detected three PII elements (name, DOB, MRN), tokenized each one deterministically using HMAC-SHA256, stored the redacted version, and created an immutable governance event recording what was detected and redacted. No raw PHI touched storage.
Step 2: Retrieve memory — tokens match across sessions
// In a new session, three months later:
const response = await fetch("https://tracecontinuity.com/v1/memories", {
headers: {
"Authorization": "Bearer mnm_your_api_key"
}
});
const { memories } = await response.json(); // Returns: "Patient [NAME_TOKEN_a3f9] reports penicillin allergy. Prefers morning appointments." // Same token a3f9 — deterministic. The agent retrieves this patient's history without PHI.
Step 3: Demonstrate deterministic token matching
The critical property for cross-session clinical continuity: same patient identifier always produces the same token.
// Verify determinism — this is what enables cross-session retrieval
const crypto = require("crypto");
function tokenizePii(value, type, secretKey) { const normalized = value.toString().toLowerCase().trim(); const hmac = crypto.createHmac("sha256", secretKey); hmac.update(${type}:${normalized}); return ${type.toUpperCase()}_TOKEN_${hmac.digest("hex").substring(0, 8)}; }
// Session 1 — March: const token1 = tokenizePii("Jane Doe", "NAME", process.env.TOKENIZATION_KEY); // → "NAME_TOKEN_a3f91c7b"
// Session 2 — June (completely separate session): const token2 = tokenizePii("Jane Doe", "NAME", process.env.TOKENIZATION_KEY); // → "NAME_TOKEN_a3f91c7b" (identical)
// The agent can retrieve Jane's memories from any session using the same token. // No PHI stored. No PHI transmitted in memory retrieval. Full longitudinal context.
console.log(token1 === token2); // true — deterministic matching confirmed
This is the property that makes HIPAA-compliant persistent memory work: the agent's memory retrieval path never requires PHI. The tokenization step at write time creates the bridge.
Audit trail compliance: what HIPAA actually requires
HIPAA's Security Rule (45 CFR § 164.312(b)) requires covered entities to implement audit controls — hardware, software, and procedural mechanisms that record and examine activity in systems containing PHI.
For AI agent memory specifically, that means audit records for:
- Every write — what was stored, what PII was detected and redacted, when, by which agent
- Every read — what memory was retrieved, when, in response to which agent/session
- Every deletion — when a retention policy triggered a deletion, or a patient exercised a deletion right
Trace Continuity logs every PII detection event to a tokenization_events table with: pii_type, token_prefix (8 chars only — not the full token), tenant_id, and occurred_at. Raw PHI never appears in audit logs. Full tokens never appear in audit logs. The audit trail is queryable by CISO or compliance team without exposing protected data.
# Example: audit query via API — what PII types were processed in the last 30 days?
(Available to admin tier; returns aggregate counts by pii_type — no PHI, no full tokens)
curl -X GET "https://tracecontinuity.com/v1/usage" \
-H "Authorization: Bearer mnm_your_admin_key"
Response includes:
{
"total_memories": 1847,
"memories_pii_redacted": 412,
"api_calls_this_period": 9334,
"tier": "enterprise"
}
The governance layer ensures your audit trail is HIPAA-ready without your team having to design or maintain the audit schema.
Retention policy enforcement
HIPAA requires that PHI not be retained longer than necessary for the purpose for which it was collected. For clinical AI memory, this typically means retention tied to clinical episode or relationship duration.
When writing a memory, pass a retention parameter:
// Clinical session memory — retain for 1 year
body: JSON.stringify({
agent: "clinical-intake",
content: "...",
retention: "365d" // Auto-expired after 365 days
})
// Acute care note — short retention body: JSON.stringify({ agent: "urgent-care-bot", content: "...", retention: "30d" })
TTL enforcement happens at the infrastructure layer — not via a cron job your team has to maintain. Records are automatically expired. Deletion events are logged.
What this means for your HIPAA BAA
If you're deploying AI agents in a covered entity context, your memory infrastructure provider needs to sign a Business Associate Agreement (BAA). That requires the provider to demonstrate safeguards for PHI it handles.
Trace Continuity's architecture is designed with this in mind:
- PHI is tokenized before storage — the data at rest contains no raw PHI
- Audit logs record PII detection events without retaining PHI
- Retention policies are enforced at the infrastructure layer with documented deletion events
- Multi-tenant isolation prevents cross-organization data access architecturally, not by convention
Contact support@tracecontinuity.com to discuss BAA terms for enterprise healthcare deployments.
Try it live
The Playground lets you test PHI tokenization in real time — submit text containing patient data and see exactly what the tokenization layer produces before storage. No API key required for the demo.
For full API access:
- Get your API key → — free tier available, no credit card required
- API documentation → — complete reference with healthcare-specific examples
- See pricing for healthcare teams → — enterprise plans with BAA available