AI agent architecture · Healthcare data · HIPAA compliance
How we structure product data for AI agents with HIPAA in mind
How we separate the product source of truth, referral documents, AI job persistence, corrections, and PHI-safe progress across an agentic healthcare workflow.
Building an agentic workflow for skilled nursing referrals made the database question more specific. We did not need one large store that the product and every agent could access. We needed clear ownership for business facts, documents, job execution, corrections, and every payload crossing those boundaries.
The architectural thesis
Keep business authority in the product and processing capability in the engine.
The core decision
Business authority and AI execution stay separate.
The product backend owns tenancy, users, residents, nurse edits, and the durable audit of those edits. The engine owns a narrower job: process the referral, retain execution state and structured evidence, and return a result for review.
A nurse correction is written to the product first, then mirrored into the engine so the job reflects the reviewed state.
The database that helps an agent finish a job is not necessarily the database that owns the business fact.
The engine proposes. The product commits.
The data path
The workflow moves references and reviewed facts—not the whole product model.
The backend uploads a referral packet, creates a job identifier, and gives the engine a claim-check reference with the small amount of facility context required for processing.
One referral crosses five controlled boundaries.
- AuthorityProduct DB
Identity, tenancy, resident, and reviewed truth.
- Claim checkBlob storage
Referral documents and job-scoped artifacts.
- CapabilityAI job
Extraction, assessment, evaluation, and evidence.
- DecisionNurse review
Correct, explain, accept, or remove a result.
- AuthoritySave + mirror
Product first; reviewed row mirrors back to the job.
Five data zones
We classify stores by purpose, not only by technology.
Every zone has an owner, a purpose, and a narrow crossing.
- Product
Authoritative product and clinical state.
- Owner
- Backend
- Allowed
- Tenants, residents, reviewed edits
- Document
Referral packets and extraction inputs.
- Owner
- Blob boundary
- Allowed
- Validated job references
- Execution
Job progress, evidence, and structured results.
- Owner
- AI engine
- Allowed
- Bounded job data
- Learning
Reviewed corrections used for retrieval.
- Owner
- Governed memory
- Allowed
- Provenance + masked embedding
- Integration
Contracts connecting product, engine, and UI.
- Owner
- API boundary
- Allowed
- Allowlisted fields only
Model context
Different agent stages need different levels of information.
OCR and extraction must process the referral itself. Downstream assessment stages receive a narrower structured view, with direct identifiers masked and date of birth converted to age where the clinical task permits it.
Context narrows as the workflow becomes more specific.
- SensitiveRaw referral
Approved document and OCR services process the packet.
- ExtractionClinical facts
Structured values are separated from document layout.
- ReductionMasked context
Identifiers and contact patterns are removed; DOB can become age.
- Need to knowAgent stage
Assessment receives only the context required for its task.
- GuardrailOutput scan
Narratives and embedding text are checked again.
Memory and learning
Job memory and reusable correction memory follow different lifecycles.
The orchestrator’s goal, plan, attempts, and decisions end with the current job. Reviewed corrections may enter a deliberate retrieval path with provenance, masking, embeddings, retention, and review.
A vector column does not make correction data anonymous.
Only reviewed corrections may cross the job boundary.
Audit without replication
Operational visibility should not become another clinical database.
One internal event is shaped into three narrow channels.
- Audit record
Who called which job route and what status returned.
- Owner
- Security log
- Allowed
- Method, path, caller signal, status
- Scrubbed trace
Job-scoped reasoning evidence with common identifiers removed.
- Owner
- Engine trace
- Allowed
- Bounded diagnostic context
- Progress event
Enough state for the interface to explain movement.
- Owner
- Queue
- Allowed
- Status, step, counters, timestamp
Architecture review
Seven questions keep each boundary honest.
The review starts with ownership and ends with evidence.
| Decision | Question | Evidence |
|---|---|---|
| Owner | Which system owns the fact? | Named source of truth |
| Transfer | Can a validated reference replace a copied document? | Narrow request contract |
| Context | Which stage genuinely needs raw clinical text? | Stage-specific projection |
| Authority | Is this a suggestion, review, or authoritative write? | Explicit write direction |
| Lifecycle | What persists, for how long, and who deletes it? | Retention and deletion rule |
| Observability | Can the event explain without copying clinical content? | Allowlisted schema |
| Vendors | Which services receive ePHI? | Agreement + configured safeguard |
What separation does not solve
A clean diagram is not the same as a compliant system.
Database separation sits inside a larger safeguard program.
- DesignClear data ownership
Product authority, engine capability, and bounded contracts.
- TechnicalAccess and evidence
Authorization, encryption, audit, integrity, and recovery.
- AdministrativeOperating discipline
Risk analysis, policy, training, vendor management, and incident response.
- PhysicalReal-world safeguards
Devices, workstations, facilities, continuity, and access procedures.
Encryption does not replace authorization. Masking does not automatically create de-identified data. A business associate agreement does not replace risk analysis. The final design must be validated against the organization’s role, data flows, contracts, and applicable legal guidance.
The principle I keep
Keep authority in the product and capability in the engine.
The product knows the organization, the resident, the reviewer, and the final decision. The engine knows the referral job, its tools, its evidence, and the limited state required to process it reliably. That separation lets an agent be capable without quietly becoming authoritative.
References