Pilot readiness
What it takes to run a real pilot. Stated honestly.
Most healthcare AI demos collapse in diligence because the certifications are claimed and the regulated depth is missing. This page is the opposite: what a HealthNext pilot install actually requires, the identity wiring that is configuration and not a rebuild, and the regulated machinery that lives in the code — the consent engine, the 42 CFR Part 2 carve-out, audited break-glass, and a record your auditors can re-verify offline. Designed for diligence. No certifications we do not hold.
The pilot checklist
Seven things a pilot needs — and where each one really stands.
Three honest states. Ready is enforced in code today. Config at install means the integration point exists and is wired to your environment. Roadmap is what we have not built yet — said plainly, never dressed up as a badge.
- Config at install
Your identity provider, wired
Sign-in authenticates against YOUR directory — Okta, Entra ID, Ping, ADFS — via OIDC or SAML. The adapter is built; install points it at your IdP. No HealthNext-owned credentials for your staff.
- Config at install
A signed BAA against an in-boundary architecture
The BAA is signed before any PHI flows. It is honest to sign because the architecture is in-boundary by construction — PHI stays in your account and no HealthNext operator has standing access to it.
- Config at install
A connected source system
A pilot connects one real queue — a prior-auth, claims, or appeals feed over X12 / FHIR / Da Vinci. The parsers and governed reads are real; the connection to your system is the install step.
- Ready
The PHI gate, on by default
Protected data is stopped at a fail-closed gate before it can reach a place it should not — including model training. Deny-by-default: uncertain classification does not pass. This is enforced in code today.
- Ready
A human on every adverse decision
Any decision that adversely affects a member or claim is proposed and held — it executes only when a named human approves that exact step, and the held decision is sealed before it runs. Structural, not a setting.
- Ready
An offline-verifiable evidence chain
Every governed action seals to a hash-chained, Ed25519-signed, write-once record your auditors can re-verify offline against a public key — no HealthNext dashboard, no call back to us.
- Roadmap
SOC 2 / HITRUST attestation
We do not hold these today and we do not claim them. The posture is audit-ready by construction; the formal attestations are on the path, stated as roadmap — never as a badge we have not earned.
Bring your own identity provider
Wiring your IdP is configuration — not a rebuild.
Your security team will not let a vendor mint credentials for your staff. They should not have to. HealthNext authenticates against the directory you already run, through a pluggable adapter that speaks both modern OIDC and the SAML estate healthcare still lives on. At install, it points at your IdP. There is no fork, no special build — one codebase, your identity provider.
The SAML signature-validation step is wired with your IdP signing certificate at install; until it is, SAML sign-in fails closed. We never imply a verification we are not performing.
- OIDCAuthorization Code + PKCE with real JWKS signature verification and issuer / audience / nonce binding. Works against Okta, Entra ID, Auth0, Ping, and Google via standard OIDC discovery.
- SAML 2.0SP-initiated Web-Browser SSO: a compliant AuthnRequest, an Assertion Consumer Service that maps your attribute statements to roles. The IdP signing certificate and XML-signature validation are wired at install — and until they are, sign-in fails closed.
- Group → roleYour IdP groups map to console roles by configuration. A pilot allowlist scopes access to named principals so the first pilot is exactly the people you intend — no one else.
- Single-tenantEach deployment is one tenant. A verified principal is mapped to that tenant from configuration, never from the request — there is no cross-tenant addressing to get wrong.
The depth that lives in the code
The regulated machinery most demos never show you.
These are not promises on a slide. Each one is enforced in the system your pilot runs on — and each is the kind of thing a payer's compliance officer asks for and rarely gets.
A consent engine, not a checkbox
CMS-0057-F Patient Access, Provider Access, and Payer-to-Payer exchange are modeled as first-class authorization scopes, resolved against FHIR Consent provisions and Da Vinci ATR member attribution. Access is a resolved decision with a purpose-of-use, not a flag.
The 42 CFR Part 2 carve-out
Substance-use-disorder records carry heightened federal confidentiality beyond ordinary HIPAA. HealthNext treats Part 2 — alongside genetic and behavioral-health data — as a special-protection class that is BLOCKED at egress to any destination not explicitly managed for it. The carve-out is in the gate, not a policy PDF.
Minimum-necessary, by field
A role sees only the fields its purpose requires. Minimum-necessary projection (45 CFR §164.502(b)) is applied as the record is read, and the projection is part of the sealed run record — so you can prove a role only ever saw what it was entitled to.
De-identified without a reverse map
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. Dates, ages, and ZIPs generalize to HIPAA Safe Harbor. De-identification, not redaction you can undo.
Audited break-glass, never silent
The only way a clinician sees a record outside minimum-necessary is an emergency-treatment break-glass — and it is loud. It demands a justification, is scoped to emergency treatment, and writes the principal, reason, correlation id, and timestamp to the evidence chain the moment it fires.
Re-verify the record without trusting us
Export the evidence bundle with the public key and a small, dependency-free verifier recomputes the hash chain and checks every Ed25519 signature on your own machine. Tampering breaks the chain, visibly. Trust is replaced with verification.
Every control above maps to its enforcing code path in the live Trust Center, where any control claiming “Implemented” is downgraded automatically unless it carries both an enforcing code path and a signed evidence anchor. The board cannot be faked green.
Data residency
Your data stays in your boundary — and leaving is clean.
The data plane runs in your own cloud account or a single-tenant dedicated instance. PHI and PHI-derived artifacts stay inside it; only de-identified operational metrics leave. No external foundation model is in the PHI path — inference runs on the in-boundary model.
- PHI and PHI-derived artifacts never leave your account. Only de-identified operational metrics do.
- No external foundation model — OpenAI, Anthropic, Google — sits in the PHI path. Inference is in-boundary.
- On exit, your data is returned and securely destroyed; you keep the tamper-evident chain for the legal retention window.
- No model lock-in: the model is served on an endpoint you control, with no external token meter holding the work hostage.
How we talk about this. We state posture we can back — “designed for,” “ready for,” “audit-ready by construction” — and never a certification, customer, or pilot result we do not have. Demo environments use synthetic data only; no real PHI is present on any public surface. The fastest way to trust a vendor is to read its gaps, so we hand a buyer's technical lead the gap register unprompted.
Bring your security team. Start the pilot conversation.
Walk the boundary, the identity wiring, the consent engine, the break-glass audit, and the evidence chain with the people who have to sign off — then scope a pilot on one real queue.