Open governance framework · v1.3 · Practitioner-led · not an accredited standard, certification, or regulatory requirement · seeking shadow-evaluation partners

Healthcare AI voice · provider–payer calls

Know who your AI voice agents are before they exchange healthcare operations data.

NHID-Clinical is an open, testable control and evidence layer for provider-to-payer AI calls.

Run an observe-only shadow evaluation Read the specification

5 controls · 1148 passing tests · machine-readable traces · open implementation

A shadow evaluation runs against call traces you already hold. Observe-only and non-intercepting: it does not sit in the call path and requires no vendor changes. It is time-bounded, and it produces a baseline showing where identity was disclosed, where protected data moved, where calls escalated to a human, and what audit evidence exists today. Handling those traces still carries your existing privacy, security and contractual obligations.

Open specification · testable controls · not a certification, not an accredited standard, and not a regulatory endorsement. Working reference implementation; no production-scale deployment. Seeking the first shadow-evaluation partners.

The five trust obligations, and what carries each Five obligations mapped to what actually carries each one. DISCLOSE — State non-human identity before operational exchange — is carried by IDG-01. AUTHORIZE — Prove the caller was permitted to act — is carried by NHID-Auth v2. SCOPE — Keep protected data inside what was disclosed and granted — is carried by PDX-01 · DBC-01. AUDIT — Record every turn, whatever the outcome — is carried by ATR-01. OBSERVE — Measure before enforcing — is carried by Shadow evaluation. Three map to controls in this specification, drawn solid. Two do not: AUTHORIZE is addressed by NHID-Auth v2, a separate optional document, and OBSERVE is a deployment practice rather than a control. Both are drawn with a dashed edge so the gap between the vocabulary and the implemented control set is visible rather than implied. OBLIGATION CARRIED BY DISCLOSE IDG-01 AUTHORIZE NHID-Auth v2 SCOPE PDX-01 · DBC-01 AUDIT ATR-01 OBSERVE Shadow evaluation

Reference Solid rows are v1.3 controls. Dashed rows are not: AUTHORIZE is NHID-Auth v2, a separate document, and OBSERVE is a deployment practice.

  • 1 · Disclose
  • 2 · Authorize
  • 3 · Scope
  • 4 · Audit
  • 5 · Observe

A conceptual trust pathway, not a deployed system architecture.

What this governs

The moment a non-human actor crosses an organizational boundary

NHID-Clinical does not govern the AI model — not its training, not its clinical reasoning, not its outputs. It governs one specific moment: when an automated caller acting for one organization reaches a person at another, and asks them for something.

The organizational boundary NHID-Clinical governs Two organizations sit side by side. On the left, a provider organization runs an AI voice agent; the model behind that agent, its training and its clinical reasoning sit inside that organization and are explicitly outside NHID-Clinical's scope. On the right, a payer organization is represented by a person answering the call. Between them runs the organizational boundary. NHID-Clinical applies at that boundary only, and asks five questions of the crossing: who is this agent, who authorized it, what scope does it hold, did it disclose that it is automated, and what record exists of what happened. PROVIDER ORGANIZATION The model itself Training, clinical reasoning, outputs Not governed here AI voice agent — acting for the provider PAYER ORGANIZATION A person, answering the phone ORGANIZATIONAL BOUNDARY NHID-Clinical Who is this agent? Who authorized it? What scope does it hold? Did it say it is automated? What record exists? Applies at the crossing only. Everything either organization does internally is out of scope. The five questions map to the five controls: IDG‑01, PDX‑01, DBC‑01, EIT‑01 and ATR‑01.

This is why the framework is small. A boundary crossing is observable from a call recording either side already holds, which is what makes the controls testable without changing anyone’s systems — and what keeps the scope honest about everything it does not reach.

Regulatory pressure

Different jurisdictions are approaching synthetic voice from different directions

These are separate instruments with separate scopes, triggers and legal mechanisms. They do not add up to one healthcare AI voice rule, and none of them requires NHID-Clinical. What they share is a direction of travel: when a person is dealing with an automated system, they are increasingly entitled to know.

Regulatory reference points, what each establishes, and what it does not
InstrumentIn forceWhat it establishesWhat it does not
California AB 2905
Cal. Pub. Util. Code §2874		 1 Jan 2025 Covered automatic dialing-announcing devices must tell the called person when a prerecorded message uses an artificial voice. Does not govern every conversational AI call, and is not healthcare-specific.
FCC 24‑17
TCPA declaratory ruling		 8 Feb 2024 AI-generated voices fall within the TCPA's existing restrictions on artificial or prerecorded voice calls. Does not create a disclosure standard for provider–payer administrative calls.
EU AI Act Art. 50(1)
Disclosure of AI interaction		 2 Aug 2026 People must be informed when they are interacting directly with an AI system, unless that is obvious in the circumstances. Does not specify how disclosure is verified, scoped, or evidenced on a call. Article 50(2), on machine-readable marking of synthetic content, is a separate obligation on a separate timetable and is not what NHID-Clinical addresses.

NHID-Clinical addresses the operational control point these instruments leave open: establishing identity, disclosure, authorization and evidence before sensitive workflow actions occur. It does not make any system legally compliant, and nothing here is legal advice.

The problem

A verified phone number does not tell you the caller is allowed to act for that provider.

Telephony authenticates the number. Identity systems authenticate the account. Neither establishes that this caller may act for that organization on this call — and on an administrative call, operational data starts moving early.

Without a control baseline

  1. 1CALL CONNECTS
  2. 2PHONE NUMBER / TELEPHONY SIGNAL
  3. 3ORGANIZATION / ACCOUNT SIGNAL
  4. 4AI AGENT SPEAKS
  5. 5OPERATIONAL DATA MAY ALREADY BE EXCHANGED

With NHID-Clinical

  1. 1CALL CONNECTS
  2. 2IDENTITY DISCLOSUREIDG-01
  3. 3PRE-DATA EXCHANGE GATEPDX-01
  4. 4AUTHORIZATION / SCOPEDLG-01
  5. 5DECEPTIVE-BEHAVIOR CHECKDBC-01
  6. 6ESCALATION IF NEEDEDEIT-01
  7. 7AUDIT TRACEATR-01

Impersonation latency

The interval between a voice agent entering an interaction and the receiving party establishing that the caller is a disclosed, authorized non-human actor. In the left-hand sequence that interval runs until the call ends, because nothing in it ever establishes the fact. The controls on the right exist to close it and to make it measurable.

This is a measurement concept defined by this project for its own use. It is not an established industry term or a published metric.

Read the control definitions

The control layer

Five checks on every AI-agent call, and a sixth when you opt in.

Each control is triggered by something observable on the call, returns one decision, and records a reason code in the machine-readable trace. The decisions and reason codes below are the ones the reference engine actually emits — read the control definitions or the normative text. Mapped, not certified.

The five canonical controls plus the opt-in delegated-authority gate, with the call behaviour that triggers each, the decision it returns, and the reason codes it records
ControlTrigger — observable on the callDecisionEvidence — reason code in the trace
IDG-01Identity Disclosure Gate Agent speaks before any disclosure is recorded for the call. DISCLOSE_IDENTITY IDG01_DISCLOSURE_MISSING · IDG01_DISCLOSURE_CONTRADICTED
PDX-01Pre-Data Exchange Gate Protected data is requested or supplied on the call. DENY_DATA PDX01_PHI_GATE_TRIGGERED · PDX01_DISCLOSURE_NOT_SEQUENCED
DBC-01Deceptive Behavior Check Agent speech carries impersonation phrasing or a deceptive-artifact flag. LOG_ONLY DBC01_ARTIFACT_DETECTED · DBC01_IMPERSONATION_PHRASE_DETECTED
EIT-01Escalation Implementation Test Caller asks for a human, or an escalation outcome is recorded. ESCALATE_HUMAN EIT01_NO_ESCALATION_PATH · EIT01_ESCALATION_NOT_HONORED
ATR-01Audit Trail Requirements Every evaluated event, checked for the required audit fields. LOG_ONLY ATR01_AUDIT_FIELDS_MISSING · ATR01_AUDIT_COMPLETE
DLG-01Delegated Authority Gate opt-in A signed delegation is presented for the call. CONTINUE_AI DLG01_DELEGATION_VERIFIED · DLG01_NO_DELEGATION_PRESENTED

The five canonical controls always run. DLG-01 is evaluated only when a deployment configures delegated authority; absent a delegation it returns DLG01_NOT_EVALUATED and changes nothing.

Built in the open — every claim below is checkable

  • 1148 automated tests
    Conformance and invariant suite, run on every change — see the runs
  • Versioned specification
    v1.3, five named controls — read it
  • Deterministic engine
    Same inputs produce the same decision, every time — how it works
  • FHIR R4 AuditEvent
    Audit records in a standard healthcare schema — see an example
  • Open simulator
    Run the controls against a call yourself —
1148 Passing tests every collected test executed, in the open repo
5 Controls IDG-01 · PDX-01 · DBC-01 · EIT-01 · ATR-01, plus the bot-to-bot rule
FHIR AuditEvent R4 base spec v4.0.1 — no named IG conformance claimed
Open CC BY 4.0 NIST comment on public record

Simulator

The open simulator demonstrates NHID-Clinical controls.

Sit at a payer desk and watch an AI caller reveal itself too late. The zero-latency modules, dashboard, knowledge base, and evaluation records are all open — no account, no signup, nothing to install.

Run the controls yourself

The simulator is education and demonstration — not the framework itself, and not a certification.

Evidence

One call in, a decision and a reason code out.

The engine is deterministic: the same input produces the same decision every time. Below is an actual evaluation, not an illustration — an agent asking for a member ID before disclosing that it is automated.

Input — one turn of a call

speech_text  "Hi, this is Morgan from provider
              services. Can I get the member ID?"
turn_count   0
phi_accessed ["member_id"]
disclosure   (none recorded)

Output — evaluate_all()

action       DENY_DATA
reason_code  PDX01_PHI_GATE_TRIGGERED
next_state   GATE_BLOCKED

violations
  IDG-01  critical  identity not disclosed
  PDX-01  critical  PHI requested before
                    disclosure

Reproduce it: evaluate_all() in src/nhid_policy_engine_v1.py, or run the same scenario in the . The decision is recorded in a machine-readable trace and, where audit is enabled, emitted as a FHIR R4 AuditEvent.

See the evidence pack

Shadow evaluation

Measure what your AI callers establish today, without changing anything.

A time-bounded, observe-only assessment against call traces you already hold. It is non-intercepting: the controls run over recorded interactions, not in the live call path.

  1. 01

    OBSERVE

    Analyze call traces or logs you already hold. Nothing is inserted into the call path and no production workflow changes.

  2. 02

    EVALUATE

    Run the NHID-Clinical controls against those observed interactions, using the same deterministic engine the conformance suite exercises.

  3. 03

    EVIDENCE

    Produce measurable findings: per-control outcomes, where identity was disclosed, where protected data moved, and implementation recommendations.

On data handling. Call traces are operational records and may contain protected information. A shadow evaluation does not remove any privacy, security or contractual obligation attached to that data — scope, access and retention are agreed before anything is shared, and the assessment can run against de-identified or sampled traces. We will tell you what is needed and why before you send anything.

Run an observe-only shadow evaluation Read the evaluation guide
Who it's for Payers Providers AI vendors Regulators Researchers

Two ways in

Pick the path that matches your job

Both start free. Neither requires a commercial relationship to get value.

Developer pathway

You are building an AI agent, or integrating one, and need to show it behaves.

  1. Read the controls. Five deterministic checks, each observable on a real call.
  2. Run the conformance suite against your engine and read the per-control verdicts.
  3. Try the live API — demo routes need no key. Send a VAPI or Twilio payload.
  4. Wire it in using the reference implementation, adapters, and trace schema.
  5. List your implementation in the self-attested registry when you are ready.
Start building

Enterprise pathway

You are a payer, provider organization, or health system receiving or operating AI agent traffic.

  1. Run a shadow evaluation on your own call logs. Observe-only, no vendor changes.
  2. Measure your baseline — how long is your impersonation latency today?
  3. Review the evidence pack and decide what to require of your vendors.
  4. Register your agents so identity, ownership, and scope are enumerable.
  5. Operate continuously with monitoring, evidence generation, and enterprise integration.
Start a shadow evaluation

Visualizing the Five-Layer Trust Stack

The architecture in one picture: each layer is testable on its own, and together they turn "trust me" into a verifiable pathway. Click a layer to see what it does and where to try it.

The five-layer trust stack, in cross-section Five layers, drawn bottom to top. Layer 1, STIR/SHAKEN, authenticates the carrier number and emits an attestation on the call leg. Layer 2, NHID-Clinical v1.3, is this framework: it establishes the behavioural disclosure baseline and emits a PolicyDecision with a reason code. Layer 3, NHID-Auth v2, is an optional extension adding cryptographic authorization through a signed agent passport. Layer 4, FHIR AuditEvent R4, emits an audit bundle per turn. Layer 5, OpenTelemetry, carries traces, spans and latency. Beneath all five sits layer 0, the NPI gap: no cross-organization authorization exists for AI agents today, which is the problem the stack is assembled to address. Only layer 2 is NHID-Clinical itself; layer 3 is its optional extension and the rest are existing standards it emits into. CONTROL PURPOSE EVIDENCE EMITTED 5 OpenTelemetry Observability & metrics Traces, spans, latency 4 FHIR AuditEvent R4 Audit logging AuditEvent bundle per turn 3 NHID-Auth v2 Cryptographic authorization Signed agent passport 2 NHID-Clinical v1.3 Behavioural disclosure baseline PolicyDecision + reason code 1 STIR/SHAKEN Carrier number authentication Attestation on the call leg 0 The NPI gap — no cross-organization authorization for AI agents ■ NHID-Clinical v1.3 · ■ NHID-Auth v2, optional extension · ■ existing standards this stack emits into

Reference Architectural model of how the layers relate. Layer 2 is specified and implemented in this repository; layer 3 is released as a separate document; layers 1, 4 and 5 are existing standards and are not provided by NHID-Clinical.

The authoritative definitions live in the specification.

This is an open voluntary reference implementation, not a product or certification. Layer definitions and control text are normative only in the v1.3 specification.

Mapped to & aligned with

NIST AI RMF 1.0Map & Measure functions EU AI Act Art. 50(1)Disclosure of AI interaction ISO/IEC 42001Annex A transparency FHIR R4AuditEvent evidence STIR/SHAKENCarrier authentication

Key tools

Simulator

Run the v1.3 controls against call scenarios in real time.

Specification (v1.3)

The full control set: IDG-01, PDX-01, DBC-01, EIT-01, ATR-01, and the event schema.

Read the specification →

Live demo call

Hear the disclosure controls trigger in a real voice call, with a step-by-step script.

Try the live demo →

Shadow Evaluation Guide

The structured evaluation process for payers — no vendor changes required.

View the guide →

Evidence Pack

Guarantees, a worked failure trace, and the audit-readiness model for procurement.

Review the evidence pack →

What it is

  • — A voluntary, testable behavioral baseline for AI voice agents making administrative calls to payers
  • — An open reference implementation: policy engine, conformance test suite, audit trace schema
  • — Scoped to B2B provider-to-payer administrative voice workflows only

What it is not

  • — A regulatory requirement or accredited standard
  • — A certification body or compliance guarantor
  • — An identity verifier (v1.3 standardizes observable disclosure and trace behaviors; cryptographic authorization is documented but not yet solved)

NIST AI Safety Institute — Public Comment

Submitted to NIST docket NIST-2025-0035

NHID-Clinical was submitted as a public comment to NIST's AI-agent security docket in January 2026. This is a public comment — not an endorsement, not a standard. It puts the problem on the record.

Comment ID: NIST-2025-0035-0026  ·  January 12, 2026

CAISI's RFI drew 932 public comments before closing March 9, 2026 — this is one of them, not a uniquely selected or vetted submission.

View on Regulations.gov →

Get involved

Read the specification. Run a shadow pilot. Tell us where it breaks.

Whether you think it is right, wrong, incomplete, or misses the real problem — that feedback shapes the next version.

Read the evaluation guide →

About the project

An operational AI governance framework for non-human actor accountability — disclosure, delegated authority, and auditability of AI-operated interactions in healthcare AI workflows.

NHID-Clinical was created by Brianna Baynard, who worked directly in healthcare payer operations — live eligibility, claims, and prior-authorization phone lines. She was on the receiving end of hundreds of calls from AI voice agents acting for provider offices, including agents that disclosed their automated status only after PHI had been exchanged, or not at all. NHID-Clinical documents those failure patterns and defines a testable baseline for addressing them. It is published openly under CC BY 4.0 and was submitted as a public comment to NIST (NIST-2025-0035-0026).

"I sat in the exact seat that payer representatives are in today — receiving calls from systems that sounded human, exchanged sensitive data, and only later admitted they were automated. That firsthand experience showed how much friction, wasted time, and unnecessary risk this creates on both sides."

This is a voluntary, open framework — not an official standard, not a certification program, and not backed by any organization. It documents a specific operational gap and defines a practical, testable way to reduce it.

Current status: Practitioner-led open framework, developed independently. Submitted to the NIST AI Safety Institute (docket NIST-2025-0035-0026). No organizations have adopted or piloted it in production yet.

Because public comments to federal dockets are public record, this submission is independently indexed by Google and AI search tools and surfaces when searching her name or NHID-Clinical — it's a findable public document, not a hand-picked citation. Worth keeping in context: NIST's RFI drew 932 public comments before it closed in March 2026, so this is one submission among many, not a unique distinction.

If you work in payer operations, provider offices, or voice AI platforms and see similar patterns, your feedback would be genuinely appreciated.

contact@nhid-clinical.org

For a one-page overview aimed at leadership and procurement teams, see the Executive Brief.

Other work by the maintainer

The maintainer has also created the AI Governance Map, a separate project with its own repository and deployment. It is not part of NHID-Clinical, and nothing on this site depends on it.

Technical stack

The trust stack for B2B healthcare voice AI.

The Trust Stack for B2B Healthcare Voice

STIR/SHAKEN verifies the phone number. NHID-Clinical verifies the AI agent behind the call and what it is authorized to do.

The Five-Layer Stack

Layer Purpose Key Standards NHID Role
Layer 0: NPI Gap Public NPI spoofing risk NPPES IDG-01 + NHID-Auth v2
Layer 1: STIR/SHAKEN Carrier number authentication RFC 8224 Complementary
Layer 2: NHID-Clinical v1.3 Behavioral disclosure baseline Voluntary proposal Core (IDG-01, PDX-01, DBC-01, EIT-01) + ATR-01
Layer 3: NHID-Auth v2 Cryptographic authorization NHID-Auth v2 (reference implementation) Authorization proof
Layer 4: FHIR AuditEvent Healthcare-native logging HL7 FHIR R4 ATR-01 compliance
Developers → Run the reference implementation

The Framework at a Glance

Every component of NHID-Clinical on one map — the proposal, the v1.3 controls, the technical stack, pilot tooling, regulatory alignment, and the v2 authorization layer (NHID-Auth).

The framework, arranged on the four reader journeys NHID-Clinical v1.3 at the top, branching into the site's four journeys. Understand covers the scope boundary, the five controls and regulatory alignment. Evaluate covers shadow evaluation, the evidence pack and the conformance suite. Implement covers the reference implementation, the integration ladder and NHID-Auth v2. Validate and adopt covers the front-desk walkthrough, the Trust Gateway and the FAQ. Colour marks the role a destination plays — framework, measurement, implementation, or surrounding context — not the destination itself. Every node links to the page it names. NHID-Clinical v1.3 Voluntary behavioural baseline UNDERSTAND Scope boundary Five controls Regulatory alignment EVALUATE Shadow evaluation Evidence pack Conformance suite IMPLEMENT Reference implementation Integration ladder NHID-Auth v2 VALIDATE & ADOPT Front-desk walkthrough Trust Gateway FAQ ■ framework · ■ measurement · ■ implementation · ■ context

Reference A map of this site, arranged on its four journeys. Each node links to the destination it names.

The open framework

Specification, control catalog, reference implementation, conformance tests, and regulatory mapping for AI agent identity, authorization, disclosure, and audit evidence in healthcare voice workflows.

What the framework contains

Seven components, all open

Each is independently usable. You can adopt the controls without the reference implementation, run the conformance suite against your own engine, or read the regulatory mapping on its own.

01

Specification

The v1.3 normative document: the problem, the behaviors, the sequence of interaction, scope boundaries, and known gaps.

Read the specification → 02

Control catalog

IDG-01, PDX-01, DBC-01, EIT-01, and ATR-01 — what each control checks, what a pass looks like, and where to try it.

Browse the controls → 03

NHID-Auth

The v2 cryptographic authorization layer: Ed25519 agent passports, provider-signed delegation, and offline verification.

Read about NHID-Auth → 04

Reference implementation

A pure-Python policy engine with no runtime dependencies, TypeScript middleware, voice-platform adapters, and a PowerShell module.

See the implementation → 05

Conformance test suite

Machine-readable, deterministic pass/fail tests. Same inputs, same verdict — every time, for anyone who runs them.

Run the tests → 06

Technical stack

The five-layer trust stack, from carrier authentication through behavioral disclosure to audit and observability.

See the stack → 07

Regulatory alignment

How the controls map to NIST AI RMF, the EU AI Act, ISO/IEC 42001, CMS-0057-F, HIPAA documentation, and state AI laws.

Read the mapping →

What is open, and what it costs

The framework is the whole of it.

The specification, control catalog, conformance tests, and reference implementation are open under CC BY 4.0. You can implement all of it yourself and never talk to us.

There is no hosted product to buy, no managed service, and no organization operating this in production that we can point you to. If that changes it will be said plainly here, with names.

ⓘ The specification is never paid. No tier, plan, or contract gates the specification, the control catalog, or the conformance test suite.

Start with the framework

Read it, run it, and tell us where it breaks.

Read the specification →The v1.3 normative document. Run the tests →Deterministic pass/fail conformance. Contribute →Issues, discussions, pull requests.

NHID-Clinical is a voluntary open framework — not an accredited standard, certification, or regulatory requirement. Everything on this page is published under CC BY 4.0.