Healthcare
Selling an AI agent to a hospital? Here is what their reviewer needs.
Inhold gives their reviewer the answers: where patient data lives, which agents may read it, how purpose limits work and what evidence proves each decision. The AWS install is still in build.
Inhold is being built. No customers yet. Repo goes public 9 Nov 2026.
Start with the review
The questions are much the same for prior authorization, clinical documentation and revenue cycle agents. A prior authorization agent needs clinical notes to draft a request. A clinical documentation agent may need the same notes for another purpose. The reviewer needs to know which purpose permits each read.
Who signs the agent in? Can a billing agent read PHI? Where is the key? What happens after a clinician corrects an output? Can the reviewer inspect a denied read?
See the Security answers for each status and the HIPAA map for evidence files. The AWS install is still in build.
Local labels
What the tagger can see
From the tagger source, public on 9 Nov. Detection happens at write time without a network call.
| Label | Patterns in v0 | Limit |
|---|---|---|
| PHI | MRN, date of birth, ICD-10, NPI and member or policy id. | Person names need the optional local name model, and on synthetic test sets it still misses some. Addresses and free-text dates are not detected. Sending a subject with each patient write makes the item PHI whatever the tagger finds. |
| PII | SSN, email and phone. | These are pattern matches, not complete identity detection. |
| Caller labels | Merged with detected labels. A purpose's default labels also apply, and an item with a subject is always PHI. With no label from any source, the item gets internal. | A caller can add labels and cannot remove detected ones. |
Synthetic demo hospital
A prior authorization correction, and a refused billing read
The demo hospital is Contoso General Hospital (synthetic). Every patient, person and organization in the demo is synthetic. No real hospital or patient data is used.
The prior authorization agent is allowed
The prior authorization agent stores synthetic charts as memory. Its reads under prior_auth are allowed and logged, and it uses them to draft a letter.
A person corrects it
The nurse adds the missing conservative therapy detail. The correction records a diff, becomes a draft skill, and needs a named approver's sign-off before the agent uses it.
The billing agent is denied the same PHI
The billing purpose excludes PHI. Search withholds the notes; direct reads are refused and logged. Trying the prior authorization purpose does not grant the billing agent that purpose.
The reviewer gets the export
The demo exports the policy, audit chain and control evidence as a zip. The pack includes a verification result. In the demo pack it reads ok: true, with anchors signed by a synthetic demo key. This is a synthetic demonstration, not a customer deployment.
Sources: the demo and the answer bank in the repo.
Questions
Questions from the hospital side
How do I pass a hospital security review with an AI agent?
Answer three questions with evidence: where the agent's memory lives, who can read it and how the hospital would know. Inhold's planned AWS install puts the memory in the hospital's own cloud account, and v0 already exports a policy file, an audit chain and a 164.312 map for their reviewer.
Is SOC 2 enough to sell an AI agent to a health system?
Often not. SOC 2 covers your company's controls, while the hospital reviewer also asks where their patients' data sits and who can read it. Inhold is built to answer that part, with the AWS install still in build. Inhold itself has no SOC 2 report yet.
Which PHI does Inhold label?
Inhold labels MRN, date of birth, ICD-10 codes, NPI and member ids as PHI, and SSN, email and phone as PII, locally when each item is written. Person names need the optional local name model, which still misses some; addresses and free-text dates are not detected.