What is NHID-Clinical?
NHID-Clinical is a voluntary, practitioner-led open framework (v1.3) that addresses a specific problem in healthcare payer–provider voice workflows: AI voice agents that interact with payer staff without disclosing they are automated systems.
It is not an official standard, certification program, or regulatory requirement. It is an independent, practitioner-led effort to name the problem and define a testable baseline for shared expectations.
It also does not evaluate model fairness, clinical safety, or output quality — those remain separate governance responsibilities. See the scope boundary note for what stays out of scope and how NHID-Clinical integrates underneath those programs.
What problem does it address?
Impersonation latency — the gap between when an AI voice agent begins a call and when the person on the other end realizes they are not speaking to a human.
An AI calls as "Sarah from Dr. Smith's office," handles several minutes of normal workflow conversation, and only admits "I'm an automated system" when challenged. By then, sensitive operational data has already been exchanged — without clear consent or accountability.
Who created this?
Brianna Baynard, after working in healthcare payer operations and personally experiencing these calls from AI systems that presented as human. It is an individual volunteer effort, not backed by any organization or standards body.
Is this mandatory?
No. Completely voluntary. Payers, providers, and vendors can choose to reference it, adapt it, or ignore it entirely.
What does the proposal actually suggest?
Four behaviors for AI voice agents in B2B healthcare administrative calls:
- Identify as an automated system before any operational data is exchanged
- Avoid behavioral patterns designed to sound human (fake breathing, filler sounds, etc.)
- Provide a clear, easy path to a human when requested
- Maintain basic logs of the interaction
The full proposal document has detailed discussion of each. Download the PDF →
Who is this for?
- Payers receiving AI calls from providers or vendors
- Providers and vendors building AI voice agents
- Operations and compliance teams who want clearer expectations
It does not apply to patient-facing calls, internal tools, or clinical decision AI.
How is this different from HIPAA or TCPA?
Those regulations cover patient data privacy and consumer call consent. Neither specifically addresses the B2B scenario where an AI agent calls a payer office on behalf of a provider — which is where the impersonation latency problem actually occurs.
This proposal is designed to address a gap, not replace existing rules.
Why are NPIs a security risk in voice calls?
NPIs are public identifiers. Anyone can find a provider's NPI in the NPPES registry and use it when calling a payer. Without a real-time authorization check, a caller can claim to be from that practice and request operational data — claim status, eligibility, authorization details — and the payer's system has no mechanism to refuse.
NHID-Clinical v1.3 addresses the disclosure side: did the caller identify as an AI? v2 addresses the authorization side: is this AI actually delegated by the provider it claims to represent? The goal is that a payer can know not just that they're talking to an AI, but that the AI truly represents the provider it claims to. The reference implementation includes 1148 passing tests to ensure deterministic policy evaluation.
Can I get feedback on my implementation?
Informal peer feedback is available on a limited basis. Email contact@nhid-clinical.org with your context. This is not certification or formal assessment.
What is the NIST connection?
NHID-Clinical was submitted as a public comment to NIST docket NIST-2025-0035 (AI-agent security) in January 2026. Comment ID: NIST-2025-0035-0026. This is a public comment — it does not imply NIST endorsement or recognition.
How can I give feedback or get involved?
Email: contact@nhid-clinical.org GitHub: github.com/NHID-Clinical/NHID-Clinical/discussions
Real-world experience from payers and implementers is what this proposal most needs.
Get involved
Questions? Disagreements? We want to hear them.
The most useful feedback is honest — including "this doesn't match what we actually see."
Community
NHID-Clinical is an open proposal, not a finished standard. The most useful thing you can do is tell us where it is wrong.
Where the conversation happens
Everything is public. There is no mailing list to join and nothing gated behind a form.
Discussions
Open questions, disagreements about the controls, and "has anyone seen this in the wild" reports.
Open Discussions ↗Issues
Specification defects, reference-implementation bugs, and concrete change proposals.
Open Issues ↗Run a shadow evaluation
The single most valuable contribution is measurement against real traffic. A Tier‑0 shadow evaluation is observe‑only: nothing is enforced, no vendor changes are required, and you keep your own data. It is a 90‑day engagement whose technical core is a 2‑4 week measurement sprint using the Shadow Pilot Kit.
We are actively looking for the first partners. If that might be your organization, book a conversation — it is the fastest way to find out whether this is a fit.
Contribute to the specification
- Challenge a control. If IDG‑01, PDX‑01, DBC‑01, EIT‑01 or ATR‑01 does not survive contact with your workflow, that is worth an Issue.
- Bring counter-examples. Call patterns the heuristics misclassify are more useful than agreement.
- Port an adapter. Six vendor adapters exist; a seventh for your platform is a self-contained contribution.
- Review the claim boundaries. If anything on this site overclaims, say so — see claim-boundaries.md.
Honest status. NHID-Clinical is a practitioner-led open proposal under CC BY 4.0. It is not an accredited standard, a certification program, or a regulatory requirement, and there is no external certification authority. Conformance testing is self-administered.
How to read a status label
Not everything here stands in the same place. A deterministic engine with a passing test suite and a registry that does not yet exist are both described on this site, and the difference matters more than any feature list. Six labels are used, and they mean exactly this:
- Verified Measured evidence exists and the measurement can be re-run.
- Implemented Code exists, runs, and the conformance suite covers it.
- Reference A working primitive, deliberately not deployed infrastructure.
- Conceptual A documented production path that has not been built.
- Research A research component, explicitly not a product capability.
- Future Does not exist. Named so it cannot be mistaken for shipped.
The labels are not marketing tiers. Each one corresponds to a standing recorded in claim-boundaries.md, and a test fails if the two ever disagree.