NHID-Clinical is an open reference implementation and proposed control model for receiver-side governance of inbound healthcare AI agents.
It governs the identity disclosure, authorization, and auditability of AI-operated interactions across organizational boundaries — not the AI model itself.

Built from direct payer operations experience — the impersonation latency problem, seen firsthand on live eligibility, claims, and prior-authorization lines.
Not a standard. Not a certification. Not a product. An open, testable reference for the ecosystem.

Website · Simulator · Specification · v2 Identity · Discussions

_{The NIST badge links to a public comment submitted to a NIST RFI docket — not a NIST endorsement, adoption, or certification.}

Designed to support the transparency obligations described in EU AI Act Article 50; mapped to NIST AI RMF 1.0.

NHID-Clinical targets one specific failure: an AI voice agent begins operating and requesting sensitive information before the receiving party can verify it is non-human and properly authorized. That window is impersonation latency — and in payer–provider calls it routinely covers member IDs, NPIs, dates of birth, and claim data. It delivers five concrete, testable controls, a per-call Call Authorization Score (CAS), and an optional cryptographic layer (NHID-Auth v2) for proving delegated authority. It does not address fairness, clinical safety, or model quality — those stay separate by design.

Who it's for: security reviewers · healthcare compliance teams · AI voice vendors · payer / provider pilot teams.

Pick your path — each is runnable today:

🔍 Reviewers & security teams — read the boundaries, then run the tests.

1. Skim what it is / is not and the claim boundaries
2. pip install -r requirements.txt && python -m pytest tests/ -v → 446 passing
3. Inspect the five controls in src/nhid_policy_engine_v1.py and the Enforcement Profile
4. Read the Conformance Test Suite — each case asserts an expected policy action

🛠 AI voice vendors — see the controls fire, then find your integration points.

1. Run the Governance Simulator
2. Send a native call payload to a demo adapter — no key required (see Live API)
3. Map your call flow to the controls via the Developer guide

🏥 Payers & providers — review the controls, then scope a shadow pilot.

1. Read the controls and the For Payers framing
2. Pick one workflow (eligibility, claim status, prior auth)
3. Run the Tier 0 Shadow Pilot Kit on your own logs — observe-only, 2–4 weeks

Is — an operational AI-governance framework with two layers:

• a governance / accountability layer — AI-caller disclosure (IDG-01, DBC-01), no-data-before-disclosure sequencing (PDX-01), human escalation (EIT-01), and machine-readable audit (ATR-01), evaluated by a deterministic conformance test suite; and
• a non-human-actor identity and delegated-authorization layer — NHID-Auth v2: NPI-anchored, scoped, revocable delegation with per-call binding (reference design).

Is not — it does not govern the AI model (accuracy, bias, drift, clinical safety, output quality — out of scope by design). It is not a universal AI-identity system, an autonomous-agent framework, an accredited standard, or a certification.

See docs/positioning.md for the full category thesis, docs/terminology.md for controlled vocabulary, and docs/claim-boundaries.md for what may and may not be claimed.

NHID-Clinical sits beside the healthcare and identity stack; it replaces none of it:

• FHIR / SMART on FHIR — audit substrate. NHID-Clinical emits FHIR R4 AuditEvent; FHIR carries the data, NHID-Clinical governs the AI actor exchanging or requesting it.
• OAuth 2.x / OIDC — transport/client authorization ("may this client call this API"); NHID-Auth authorizes the specific interaction ("was this call delegated, in this scope"). Two separate checks; neither substitutes for the other.
• IAM platforms — govern actors you provision; NHID-Clinical governs a counterparty's agent you never provisioned, arriving with no login step.
• AI governance frameworks (NIST AI RMF, ISO/IEC 42001) — meta-frameworks NHID-Clinical maps to as evidence targets, not competitors.

NHID-Clinical evaluates declared identity, authorization context, and interaction policy; it does not replace an underlying identity provider or cryptographic identity infrastructure.

Healthcare differentiation — three load-bearing design choices: NPI-anchored delegation (the provider's NPI is the delegation trust root), FHIR-compatible audit evidence, and a risk model validated against payer–provider operational workflows.

The governance gap is well documented; large-scale production evidence is still limited. The strongest next step for most organizations is a focused shadow pilot on their own traffic — the Tier 0 Shadow Pilot Kit makes that a 2–4 week exercise.

For a one-page overview aimed at hospital, payer, compliance, and procurement leaders, see the Executive Brief.

Standards alignment (mapped, not certified): Explicitly supports EU AI Act Article 50 transparency obligations for AI systems interacting with humans. Mapped to NIST AI RMF 1.0 Map and Measure functions for identity disclosure and risk. Aligns with ISO/IEC 42001 Annex A controls on system transparency and auditability.

_{Clean vector visualization of the trust verification pathway — conceptual, not a product diagram.}

An honest maturity snapshot. NHID-Clinical is a working reference implementation, not a production-scale product.

Available today

• Deterministic policy engine with 343 passing tests
• Live v1.3 conformance API — demo and vendor routes need no key; VAPI and Twilio adapters accept native call payloads
• Tier 0 Shadow Pilot Kit — measure impersonation latency on your own call logs in 2–4 weeks
• Conformance Test Suite and a per-call Call Authorization Score (CAS)
• Documented Enforcement Profile — how each control's PolicyDecision maps to a receiver action (a documented layer over the five controls, not a sixth control)
• NHID-Auth v2 cryptographic authorization layer, published as public reference code

In progress

• First shadow-evaluation partners (observe-only, no vendor changes)
• Raster brand assets and expanded interoperability adapters

Not yet

• Production-scale deployments (see Phase 5 findings below)
• A certification, accreditation, or standard
• Any regulatory endorsement

This is a voluntary framework — not an accredited standard, certification, or regulatory requirement.

Date: July 30, 2026 | Status: Reference implementation validated; production readiness assessment complete

Phase 5 targeted-edge-case testing (15 healthcare scenarios) confirmed heuristic boundaries of the v1.3 engine:

Conclusion: v1.3 engine is internally consistent and deterministic. Baseline capabilities (IDG-01 presence, PDX-01 timing, EIT-01 escalation) are production-ready. DBC-01 and IDG-01 quality gaps are documented and scoped to Phase 2 ML/NLP enhancement.

Current maturity level: Internal Tool / Proof of Concept with Live Infrastructure
Not yet: Limited Pilot (operational readiness required)

Critical gaps blocking release (4–6 weeks remediation required):

1. 🔒 Security assessment — Input validation, encryption, attack surface untested
2. ⏱️ Load testing — Scalability and latency under concurrent requests unknown
3. 👁️ Monitoring & observability — Production visibility, alerting, incident runbook missing
4. 🏥 HIPAA compliance — Business Associate Agreement, Data Processing Agreement not drafted
5. 📋 Audit trail specification — Format, retention, immutability, access control undefined
6. 🔑 Authentication & authorization — API key rotation, rate limiting, per-customer isolation untested

Known limitations (documented): DBC-01 @ 40% on subtle deception, IDG-01 @ 20% on vague disclosure. Both deferred to Phase 2 ML/NLP work. IDG-01 and PDX-01 baseline (presence + timing gate) remain stable and suitable for pilot.

Recommendation: Do not release to GA. Proceed to limited pilot (2–3 customers, 4 weeks) only after addressing critical gaps and obtaining legal/compliance sign-off. See Architecture Review Visual Summary for detailed go/no-go criteria and timeline.

Timeline to production: 12–14 weeks (remediation → pilot → post-pilot review → GA), not immediate.

See Phase 5 Findings and Architecture Review for full technical analysis.

Date: July 30, 2026 | Status: Evidence package complete (2–3 week sprint, ~57 hours)

Instead of 4–6 week enterprise hardening, Phase 6 focused on credibility evidence for pilot evaluation and portfolio demonstration:

Engine Validation:

• ✅ 361 passing unit tests (comprehensive rule coverage)
• ✅ 25-scenario evaluation corpus (81.2% detection, 0% false positives)
• ✅ Live endpoint tested against noncompliant VAPI payload
• ✅ Deterministic — same input always produces same output

Governance Readiness:

• ✅ Strong rules: DBC-01 (100%), EIT-01 (100%)
• ✅ Acceptable rules: IDG-01 (71.4%), PDX-01 (66.7%) — edge cases documented
• ✅ Audit trail spec: Format, retention, immutability, HIPAA compliance complete
• ✅ Monitoring spec: Pilot dashboard, alert thresholds, weekly reporting

Portfolio Positioning:

• ✅ Not an enterprise product: Minimal surrounding infrastructure
• ✅ Production-validated engine: Deterministic policy enforcement battle-tested
• ✅ Pilot-ready: Suitable for 2–3 customer evaluation (4 weeks)
• ✅ Evidence-backed: Test results, corpus, detection rates, governance statement

• tests/evaluation_corpus_v1.json — 25 scenarios, 99 turns
• docs/EVALUATION_CORPUS_REPORT_v1.md — Detection rates, false-positive analysis
• docs/NHID_AUDIT_EVENT_SPEC_v1.0.md — Formal spec (schema, retention, compliance)
• docs/NHID_METRICS_AND_OBSERVABILITY_v1.md — Pilot monitoring & alerting
• docs/ARCHITECTURE_OVERVIEW_PILOT_READY.md — Executive brief + go/no-go criteria

v1.1 Engine: ✅ Frozen — no further policy engine changes planned
v1.2 Infrastructure (Phase 2, if pilot opportunity appears):

• Implement ATR-01 (audit trail enforcement)
• Add NLP semantic scoring for IDG-01/DBC-01
• Enterprise monitoring + SLA + HIPAA BAA signing

v2.0 Identity Layer: NHID-Auth v2 (reference code in src/agent_identity.py, 60+ passing tests)

Plus ATR-01 (audit trail) — every call must produce a machine-readable trace.
18-case CTS suite · same inputs → identical output · 446 Python tests passing (+ 66 TypeScript middleware tests)

Try the Governance Simulator →

The controls don't just detect — they emit a receiver action. Each call turn evaluates to a single PolicyDecision, and when several controls fire at once a fixed Enforcement Ladder selects the most-protective action for the receiving system to execute. This is documented behavior of the deterministic engine, not a sixth control — full spec in docs/enforcement-profile.md.

flowchart LR
    C["Five controls<br/>IDG-01 · PDX-01 · DBC-01<br/>EIT-01 · ATR-01"] --> D["PolicyDecision<br/>evaluate_all()"]
    D --> L["Enforcement Ladder<br/>DENY_DATA → ESCALATE_HUMAN →<br/>DISCLOSE_IDENTITY → LOG_ONLY → CONTINUE_AI"]
    L --> A(["Receiver action"])
    D --> E["Evidence<br/>ATR-01 · FHIR AuditEvent"]
    D --> CAS["CAS<br/>downstream score"]
    CAS -. low score routes to .-> HR(["Human review"])

    classDef box fill:#0F172A,stroke:#14B8A6,stroke-width:2px,color:#F1F5F9
    classDef acc fill:#064E3B,stroke:#10B981,stroke-width:2px,color:#D1FAE5
    class C,D,L,E,CAS box
    class A,HR acc

_{Precedence: DENY_DATA > ESCALATE_HUMAN > DISCLOSE_IDENTITY > LOG_ONLY > CONTINUE_AI. CAS may route a call to human review, but it never overrides the PolicyDecision.}

Full technical architecture →

_{Without a baseline: disclosure after PHI moves, no audit trail. With v1.3: early disclosure, verification checkpoint, human escalation, sealed audit.}

How the controls play out on a real call — the same sequence the CTS suite and live adapters evaluate.

flowchart TD
    Start(["Call Starts"]) --> Disclosure{"IDG-01<br/>Identity disclosed<br/>before any PHI?"}
    
    Disclosure -->|No| Deny["DENY_DATA<br/>IDG-01 + PDX-01"]
    Deny --> Escalate{"EIT-01<br/>Human escalation<br/>requested?"}
    
    Disclosure -->|Yes| PHI["PHI exchange allowed<br/>PDX-01 + DBC-01 checks"]
    PHI --> HumanCheck{"EIT-01<br/>Human handoff<br/>requested?"}
    
    HumanCheck -->|Yes| Escalate
    HumanCheck -->|No| Complete(["Call Completes"])
    
    Escalate -->|Honored| Handoff["Human handoff<br/>path available"]
    Escalate -->|Not honored| FailEsc["EIT-01 Fail"]
    
    Handoff --> Audit
    FailEsc --> Audit
    Complete --> Audit["ATR-01<br/>Machine-readable<br/>audit trail sealed"]
    
    Audit --> End(["End of Call"])

    classDef start fill:#0F172A,stroke:#14B8A6,stroke-width:2px,color:#F1F5F9
    classDef decision fill:#1E2937,stroke:#67E8F9,stroke-width:2px,color:#F1F5F9
    classDef deny fill:#7F1D1D,stroke:#EF4444,stroke-width:2px,color:#FEE2E2
    classDef ok fill:#064E3B,stroke:#10B981,stroke-width:2px,color:#D1FAE5
    classDef audit fill:#0F172A,stroke:#14B8A6,stroke-width:2px,color:#A5F3FC

    class Start,End start
    class Disclosure,Escalate,HumanCheck decision
    class Deny,FailEsc deny
    class PHI,Handoff,Complete ok
    class Audit audit

No signup or API key required for demo and vendor adapter routes.

curl -s -X POST https://gfvq4swdtf.execute-api.us-east-1.amazonaws.com/prod/v1/adapters/vapi/check \
  -H "Content-Type: application/json" \
  -d @tests/demo_scenarios/vapi_noncompliant.json | python -m json.tool

New here? 5-minute quickstart · v2 integration guide (Tier 0 → Tier 2)

git clone https://github.com/NHID-Clinical/NHID-Clinical.git
cd NHID-Clinical
pip install -r requirements.txt
python -m pytest tests/ -v

Expected: 446 passing in ~3.0s (~18 skip without a running server). Live demos and full docs on nhid-clinical.org.

NHID-Clinical/
├── schema/          # Event schema (JSON Schema Draft 2020-12)
├── src/             # Policy engine + NHID-Auth v2 non-human-actor identity/delegation layer
├── tests/           # CTS (YAML) + pytest harness + demo scenarios
├── traces/          # 10 canonical failure traces
├── adapters/        # VAPI, Twilio, Vonage, Retell, Amazon Connect
├── functions/       # AWS Lambda handler
├── docs/            # Quickstart, integration guides, knowledge archive
└── specs/           # PDF artifacts (Overview, Core Spec, Blueprint)

v1.3 verifies disclosure behavior. v2 verifies authorization: Ed25519 agent passports, NPI binding, scoped delegation (max 3 hops), revocation, and call-SID nonce binding. Reference code in src/agent_identity.py.

python -m pytest tests/test_identity.py -v
python examples/issue_and_verify.py

Details →

We are seeking the first shadow evaluation partners — 90 days, observe-only, no vendor changes required. Start small: the Tier 0 Shadow Pilot Kit produces usable impersonation-latency and CAS data from your own call logs in 2–4 weeks.

For Payers → · GitHub Discussions · contact@nhid-clinical.org

Brianna Baynard AI Governance & Security Researcher · AIGP · ISC² CC · WGU Cybersecurity

Creator and project lead for NHID-Clinical. Background in healthcare payer operations, identity-verification workflows, and regulated-data environments. NHID-Clinical grew out of direct experience observing operational gaps in healthcare AI voice workflows, and is maintained as an open reference implementation for technical review — feedback and criticism are welcome.

LinkedIn · GitHub · Project website