Security & trust
We can't see your PHI — and we can prove it.
The first question a payer or provider security team asks is the simplest: can your people see our data? Most vendors answer with a policy. HealthNext answers with the architecture — the boundary, the gate, the audited override, and a record an auditor can re-verify without trusting us are properties of how the system runs, not features layered on top.
Who can see the data
Standing access is none. Emergency access is audited.
These are two different things, and buyers usually hear them conflated. No HealthNext operator has standing access to your clinical data. The one clinical override that exists — emergency break-glass — is loud by design: it is justified, scoped, and sealed to the evidence chain the moment it fires.
- Operator accessNone by default. No HealthNext role in the shipped access policy can read a clinical record. Service principals are scoped to operational metadata — reports, tasks, events — with no PHI surface at all.
- Clinician break-glassAn emergency-treatment override exists for the roles that need it. It requires a written justification, is scoped to emergency treatment, and lifts minimum-necessary only for that session — every activation sealed to the audit chain.
- What leaves the boundaryDe-identified operational metrics, never PHI. No external foundation model — OpenAI, Anthropic, Google — is in the PHI path. Inference runs on the in-boundary model.
How it holds
Six controls, each enforced — not described.
In-boundary by construction
The data plane runs inside your own cloud account or a single-tenant dedicated instance. Agents and the served model execute next to your data, not in a shared multi-tenant service. PHI and PHI-derived artifacts stay inside your boundary; only de-identified operational metrics leave it.
A PHI gate that blocks, not redacts
Protected health information is stopped at a fail-closed gate before it can reach a place it should not be — including model training. The gate defaults to denial: if classification is uncertain, the data does not pass. And if the audit write fails, an allow is downgraded to a block — there is no unaudited egress path.
Audited break-glass, never silent access
The only way a clinician sees a full record outside minimum-necessary is an emergency-treatment break-glass — and it is never quiet. It demands a justification, is scoped to emergency treatment, and writes the principal, the reason, the correlation id, and the timestamp to the evidence chain at the moment it is used. Access you can prove was justified beats access nobody can see.
De-identified by construction, not just redacted
Data leaving the boundary toward analytics or model paths is de-identified with a one-way tokenizer that keeps no reverse map — the token cannot be turned back into the value it replaced. Dates, ages, and ZIPs are generalized to the HIPAA Safe Harbor rules, and minimum-necessary field projection means a role sees only the fields its purpose requires.
An auditor can verify it without trusting us
Every governed action is written to a hash-chained, Ed25519-signed, write-once (WORM) record. The verifier is dependency-free and runs offline: an auditor checks the chain and the signatures against a public key, with no call back to HealthNext and no login to our dashboard. Tampering breaks the chain, visibly.
A human holds every adverse decision
Agents assemble evidence, draft, and route. People decide. Any decision that adversely affects a member or claim is proposed and held — it executes only when a named human supplies the approval for that exact step, and the held decision is sealed before it runs. The control is structural, not a setting that can be quietly switched off.
Verify without trusting us
The record re-verifies offline, against a public key.
Sovereignty is not just where the data lives — it is who can independently check the record. HealthNext exports the evidence bundle with the public key and the records, and a small, dependency-free verifier recomputes the hash chain and checks every Ed25519 signature. A payer's compliance team can re-verify the chain on their own machine, with no HealthNext dashboard and no call back to us.
The signing and offline-verify mechanism is real today. The published verifier CLI and its spec are on the near-term roadmap; per-tenant key custody is documented honestly with it.
- Append-onlyA governed decision is added to the record, never altered or deleted. The chain is write-once.
- Ed25519-signedEach record is signed with the deployment's per-tenant key. A changed byte invalidates the signature.
- Offline-verifiableThe verifier recomputes the chain and checks signatures against a public key — no server, no trust in us.
Exit rights
Sovereignty includes getting your data back.
A boundary you can't leave is not a boundary. The same design that keeps your data home makes leaving clean — data returned, deletion proven, and the tamper-evident record retained on your side for the window the law requires.
- On termination, your data is returned and securely destroyed — your boundary, your data, your call.
- You keep the tamper-evident evidence chain for the legal retention window. The record that proves what happened outlives the engagement, by design.
- No model lock-in: the model is forked for you and served on an endpoint you control. There is no external token meter holding the work hostage.
How we talk about compliance
Diligence-safe by default.
We hold ourselves to claims a buyer's security team can verify. That discipline is part of the product — and it is rendered live in the Trust Center, where any control claiming “Implemented” is automatically downgraded unless it carries both an enforcing code path and a signed evidence anchor. The board cannot be faked green.
Open the live Trust Center- We state posture we can back. We do not claim SOC 2, HITRUST, or other attestations we have not earned.
- Compliance language describes how the architecture is built — "by construction," "by design," "fail-closed" — not external certifications.
- Access claims describe the access policy that ships. A custom deployment policy is yours to set; we describe the default we stand behind.
- Demo environments use synthetic data only. No real PHI is present in any demo or marketing surface.
Bring your security team. We built this for their questions.
Walk through the boundary, the PHI gate, the break-glass audit, the evidence chain, and the deployment model with the people who have to sign off.