NHID-Clinical v1.3 Specification

AI voice agents in healthcare payer–provider administrative calls frequently operate without disclosing their automated nature at the outset of a call. Staff share operational data — provider credentials, claim details, eligibility information — before realizing they are talking to a machine.

This creates a window of ambiguity — what this proposal calls impersonation latency — where sensitive information changes hands without informed consent or clear accountability.

The problem is not that AI is making these calls. It is that AI is making these calls while appearing to be human.

1. The interval. t(connect) is session start; t(disclosure) is the first valid IDG-01 disclosure event. The difference is impersonation latency, reported in seconds and in completed turns.
2. The exposure. IL measures the interval — the harm is what moved inside it. Pre-disclosure PHI exposure counts phi_accessed fields timestamped before t(disclosure). PDX-01 fires when that count exceeds zero.
3. The two are independent. A call can have a long interval and zero exposure (poor practice, no breach), or a short interval and non-zero exposure (critical). Reporting one without the other misstates the risk.
4. No disclosure at all. IL is right-censored at call end and reported as IL ≥ call duration, never as a missing value.
5. Not included. IL(detection) — when a person subjectively realizes they are talking to a machine — is not machine-observable and is excluded from conformance evaluation.

Reference Conceptual model of how the measurement is defined, drawn in the site’s own diagram system. The turn positions are illustrative, not a recording of a specific call and not a distribution — for interval figures computed from a committed corpus, see the shadow evaluation guide.

An AI voice agent should identify itself as automated before any operational data is exchanged. That disclosure should be clear, immediate, and not contingent on being challenged.

Everything else in this proposal flows from that single principle.

Four of the five controls act on the call. The fifth does not — it records what the other four did. That difference is structural, not a matter of emphasis, and it is the distinction this diagram exists to make. These are suggested behaviors and a testable baseline, not mandatory requirements.

Everything below this paragraph is output. Two real scenarios from the governance evaluation corpus were replayed through evaluate_all — the same function the conformance suite and the hosted API call — and the action, reason code and violations recorded verbatim. Nothing here is written by hand, and a test regenerates it and fails if this page and the engine ever disagree.

The following diagram illustrates the disclosure gate in a standard eligibility workflow.

1. The agent opens the call by stating that it is an automated system. This is the utterance IDG‑01 evaluates.
2. The representative acknowledges and asks for the NPI.
3. The turn is submitted to the policy engine as evaluate_all(session, event).
4. The engine returns a PolicyDecision: CONTINUE_AI, reason code IDG01_DISCLOSURE_CONFIRMED.
5. Only then does the interaction cross the disclosure gate. The NPI is supplied and the administrative exchange proceeds.

Two branches are drawn beneath the gate for the cases where it does not clear: a request for protected data before any disclosure (DENY_DATA, PDX01_PHI_GATE_TRIGGERED) and a disclosure the representative interrupted before it was heard (DISCLOSE_IDENTITY, IDG01_DISCLOSURE_INTERRUPTED). ATR-01 runs beneath all of it and records every turn without changing any of them.

Reference Conceptual model of the control in a standard workflow, drawn in the site’s own diagram system. It is not a recording of a specific call — for engine output replayed from real corpus scenarios, see the Trust Gateway above.

The five controls do not run as a chain of gates. Every one of them evaluates the same turn independently, and the composite decision is whichever result is most restrictive. The figure below is generated by replaying the governance evaluation corpus through the engine, so the counts beside each rung are measured rather than asserted.

These controls address the specific operational friction that motivated this proposal. They are observable, testable in context, and achievable without significant architectural changes in most systems.

They are also the minimum set that would meaningfully change the impersonation latency problem — not a comprehensive AI governance framework.

This proposal applies to B2B administrative voice workflows — AI systems calling payer offices on behalf of providers, vendors, or plan administrators. It does not apply to patient-facing calls, clinical decision support, or internal tooling.

This proposal does not define a compliance program. There is no certifying body, no audit process, and no enforcement mechanism. NHID-Clinical evaluates declared identity, authorization context, and interaction policy; it does not replace an underlying identity provider or cryptographic identity infrastructure. The Implementation Registry is self-attestation only — vendors list themselves and link their own live conformance metrics; NHID-Clinical does not verify or certify entries. The full proposal document contains more detail for interested practitioners.

v1.3 addresses observable behavior — disclosure timing, deceptive artifacts, escalation path, audit logging. It does not address caller authorization. Because NPIs are public, a malicious AI can trivially impersonate a provider unless a cryptographic authorization handshake is enforced — NHID-Auth v2 (released June 2026, CC BY 4.0) addresses this with Ed25519 provider-signed agent passports and NPI binding. NHID-Clinical v1.3 tells you the caller was automated; NHID-Auth v2 tells you the caller was authorized.

Five-layer trust architecture →  ·  Regulatory alignment matrix →