ARKA AI Governance & Clinical Accountability Package
Submission package for hospital AI governance committees — mapped to Joint Commission/CHAI RUAIH (Sept 17, 2025) with crosswalks to ONC HTI-1 predictive DSI transparency, NIST AI RMF, and FDA Non-Device CDS / CMS AUC anchors.
Last updated: July 24, 2026
Published governance policy
Standing Evidence Panel Charter
No clinical criterion or modality rating is promoted on a single-clinician approval. ARKA's standing panel includes radiology, primary care, an evidence methodologist with GRADE expertise, and a patient representative.
- Quorum requires approvals from at least three distinct roles, including the evidence methodologist and at least one non-radiology member.
- Members disclose employment, financial, research, society, payer, vendor, and institutional interests annually and again for every reviewed item.
- A relevant item-level conflict requires recusal; that reviewer cannot vote, chair the item, or count toward quorum.
- The panel meets at least quarterly, re-reviews material releases and new safety evidence, and preserves an immutable disclosure and decision trail.
Read the complete public Evidence Panel Charter. The version-controlled source is maintained at docs/governance/EVIDENCE_PANEL_CHARTER.md.
Joint Commission / CHAI RUAIH · Sept 17, 2025
ARKA AI Governance & Clinical Accountability Package
Generated July 24, 2026 · Public submission for hospital AI governance committees
CMO plain-language version
ARKA-CLIN is FDA Non-Device Clinical Decision Support that surfaces patient-specific imaging appropriateness at order entry from structured FHIR — it does not analyze medical images or physiological signals.
It cannot block, cancel, or place orders; it is silent when no guideline fires, and the ordering clinician retains full responsibility for every decision (on-card disclosure v1.2.0).
Accountability is split by design: your ordering clinicians and AI governance committee own clinical adoption; ARKA maintains change-controlled rule-library and model-weight releases with a named accountable owner [TG-5 role], and supplies this packet plus quarterly QBR governance summaries after go-live.
Quality is monitored continuously — live validation dashboard, override/feedback KPIs, near-miss QI review, monthly drift review during pilots (weekly in shadow mode), and quarterly fairness summaries at enterprise scale.
Human-in-the-loop & not-sole-basis policy
ARKA is decision support, not a decision maker. Across the payer reviewer flow it is structurally impossible for ARKA to be the sole basis for a denial: the software may auto-approve an order or route it to clinical review, but it may never auto-deny.
Every adverse determination — deny, modify, or downgrade — requires an explicit action by a licensed-physician reviewer, recorded with reviewer identity, licensure credential, and timestamp. The reviewer API rejects any adverse determination that is not attributed to a human physician, and the reviewer dashboard displays the policy on every screen: “ARKA supports the reviewer; it is not the sole basis for any denial. Adverse determinations are made by a licensed clinician (Cal. SB 1120 / CMS-0057-F).”
Each disposition is written to an immutable, append-only audit record (ins_reviewer_decisions) capturing the order, ARKA’s score and cited factors, the human decision, the reviewing physician’s identity and credential, and the rationale. This satisfies the human-review requirements of California SB 1120 (the Physicians Make Decisions Act — a licensed physician, not an algorithm, must make medical-necessity determinations) and the prior-authorization transparency and turnaround requirements of CMS-0057-F.
RUAIH seven elements
Mapped to the Joint Commission and CHAI Guidance on the Responsible Use of AI in Healthcare (RUAIH). Expand each element for committee questions, ARKA responses, and evidence links.
1AI policies & governance structures
What committees ask
Who owns AI change control on the vendor side? How are model and rule updates governed, release-noted, and communicated to our committee?
ARKA response
ARKA-side change control covers the rule library and optional glass-box EBM concordance calibrator — updates follow the documented Q-Sub change-control process (open FDA Question 3 on /trust) with release notes to your team. A named accountable owner holds vendor-side governance accountability [TG-5 role]. Customer-side: ARKA furnishes this public submission packet for your AI governance committee and a quarterly QBR governance summary (measured-vs-modeled variance, change-control review, fairness/drift — docs/customer-success/QBR_AGENDA_TEMPLATE.md) aligned with post-go-live success cadence on /outcomes.
Evidence
2Patient privacy & transparency
What committees ask
Does ARKA touch PHI? What persists? What do clinicians see on the card about AI involvement?
ARKA response
Yes — ARKA processes structured FHIR in-context at order entry via CDS Hooks as your Business Associate. PHI is transient in the request path only; identifiers are hashed before persistence, and there is no bulk PHI export from the EHR. Federated analytics returns encrypted aggregate query results — never row-level patient records. Every CDS card renders the canonical FDA Non-Device CDS disclosure (lib/compliance/fda-disclosure.ts, v1.2.0) so clinicians see that the recommendation supports — not replaces — their judgment.
Evidence
3Data security & data-use protections
What committees ask
What is your security posture? Is PHI used in model training? Is the demo environment safe?
ARKA response
Full privacy and security policy suite adopted and operating; business associate agreement ready for execution; annual NIST 800-30 risk analysis complete. ARKA does not claim SOC 2 attestation before the auditor's report is issued. On issuance, the report will be available to customers and prospects under NDA. No PHI in model training, evaluation, or analytics — synthetic or de-identified data exclusively (ARKA-PRIV-002). The public demo is 100% synthetic with zero PHI records; a quarterly officer-signed attestation (ARKA-DEMO-001) verifies the environment.
Evidence
4Ongoing quality monitoring
What committees ask
How do you monitor performance, overrides, drift, and fairness after go-live?
ARKA response
A live, re-runnable validation dashboard publishes synthetic-cohort metrics today (subgroup tab: age, sex, modality). Override and feedback rates are first-class KPIs on /outcomes. Near-miss cards feed QI review — weekly champion readouts during pilot shadow mode, then monthly with clinical governance. Drift monitoring: monthly score-distribution review during pilots (weekly during shadow mode); quarterly at enterprise scale. Quarterly QBR includes a fairness/drift summary (Measured ROI vs the modeled case (variance shown explicitly, both directions), roadmap, model/rule-library change log review, subgroup/fairness monitoring summary, renewal economics).
Evidence
5Voluntary, blinded reporting of AI safety events
What committees ask
How do clinicians report unsafe or unexpected AI behavior? Will you participate in industry safety reporting?
ARKA response
ARKA commits to a documented AI-safety-event intake path: the CDS Hooks feedback endpoint (POST /api/cds-services/feedback) logs accept/override actions without PHI in free text; override rates are tracked as a safety signal. During pilots, customers receive a visible incident/issue log alongside weekly readouts. ARKA will participate in voluntary blinded reporting programs as they mature [program name — TG when joined] — we do not claim membership in any program until formally enrolled.
Evidence
6Risk & bias assessment
What committees ask
What are known failure modes? How do you assess subgroup fairness and contain harm?
ARKA response
The validation dashboard subgroup tab publishes age, sex, and setting/modality slices on the guideline-concordance holdout today (~87.5% concordance — not a clinical-outcome claim; synthetic self-consistency is plumbing only). Tier-2/3 subgroup validation plans are documented in ARKA-PROSPECT-01 (IRB status: protocol drafted). Known failure modes and mitigations are published on /docs/model-limitations. Harm containment is architectural: non-blocking design, no order authority, silent when no rule fires, rules-only floor if model refinement is unavailable.
Evidence
7Education & training
What committees ask
What training do ordering clinicians, champions, and UM staff receive? How is card language governed?
ARKA response
Training is role-based and short by design (the tool adds no screens): 15-minute ordering-clinician orientation (what a card is, how to see the reasoning, how to give feedback), 45-minute session for champions/UM, plus quick-reference sheet. Communication templates for go-live announcements are provided. Model or rule-library changes follow the documented change-control process in the Q-Sub package and are release-noted to your team. Card language follows the CDS Card Language Style Guide (docs/CDS_CARD_LANGUAGE_STYLE_GUIDE.md) — enforced by CI (scripts/lint-cards.ts) with clinical sign-off on changes. A physician-champion letter template is provided (Champion Toolkit) — ARKA pre-formats the letter so your sponsoring physician's submission is a 20-minute task, not a writing project.
Evidence
Crosswalk — ONC HTI-1 predictive DSI
ARKA furnishes the 31 source-attribute set for predictive DSIs (45 CFR 170.315(b)(11)) so your certified-EHR team can meet transparency obligations when enabling ARKA as a third-party DSI. Full skeleton: docs/governance/HTI1_SOURCE_ATTRIBUTES.md.
| Their requirement | ARKA response or artifact |
|---|---|
| 45 CFR 170.315(b)(11) — certified health IT must support 31 source attributes for predictive DSIs enabled in the EHR | ARKA supplies predictive-DSI source-attribute documentation (31 attributes) to support the hospital's certified-EHR transparency obligations (45 CFR 170.315(b)(11)). FAVES-aligned summary included. Full attribute skeleton: docs/governance/HTI1_SOURCE_ATTRIBUTES.md. |
| Intended use, cautioned out-of-scope use, and maintenance commitments | Public model limitations page + Trust center Q-Sub intended-use statements + feature rationale catalogue. |
| Training data provenance and demographic representation | Model card (under NDA) + ARKA-PRIV-002 (no PHI in training) + synthetic-cohort disclosure on validation dashboard. |
| Validity and fairness performance in testing | Live validation dashboard with subgroup tab (age, sex, modality) on synthetic cohort; Tier-2/3 plans in ARKA-PROSPECT-01. |
Crosswalk — NIST AI Risk Management Framework
| Their requirement | ARKA response or artifact |
|---|---|
| Govern — policies, roles, and accountability | This governance packet + Trust center Q-Sub package + scope boundary (docs/SCOPE_BOUNDARY.md) with CI import guards + named accountable owner [TG-5 role]. |
| Map — context, intended use, and risk identification | Regulatory rationale memo (/docs/regulatory-rationale) + model limitations brief + Q-Sub intended-use statements on /trust. |
| Measure — evaluate, analyze, and monitor | Validation dashboard (/cds-hooks-demo/validation) + outcomes KPI framework + subgroup/fairness tab + drift review cadence. |
| Manage — prioritize, respond, and recover | CDS feedback endpoint + near-miss library + pilot incident log + documented rollback runbook on /implementation + override KPI on /outcomes. |
Crosswalk — FDA Non-Device CDS & CMS AUC anchor
ARKA-CLIN is designed to remain Non-Device CDS; any future feature that would exceed §520(o)(1)(E) triggers the documented regulatory decision process before build (see SCOPE_BOUNDARY CI guards).
| Their requirement | ARKA response or artifact |
|---|---|
| FD&C Act §520(o)(1)(E) criteria 1–4 (Jan 2026 CDS guidance) | Regulatory rationale memo with per-criterion analysis — /docs/regulatory-rationale. |
| FD&C Act §520(o)(1)(A) — ARKA-INS administrative support | Trust center function map + Q-Sub Document 06 administrative-support memo. |
| PAMA §218(b) AUC structure + CMS program-status monitor | Regulatory standing page with honest program-status chips — /compliance/regulatory-standing. |
| Scope boundary — features that would exceed Non-Device CDS | ARKA-CLIN is designed to remain Non-Device CDS; any future feature that would exceed §520(o)(1)(E) triggers the documented regulatory decision process before build (see SCOPE_BOUNDARY CI guards). |
Committee deck insert — model limitations
From /docs/model-limitations — copy into your AI governance committee deck.
Model Limitations & Oversight — ARKA (for committee decks)
ARKA-CLIN reports ~87.5% guideline concordance on a held-out, human-signed-off scenario cohort. Not a clinical-performance or outcome claim — concordance with signed-off guidelines only.
- Evidence ladder: Tier 1 published (concordance); Tier 2 retrospective in progress; Tier 3 prospective planned.
- Safety design: Non-blocking; no order authority; silent when no rule fires; rules-only floor if the glass-box calibrator is unavailable.
- Criterion 4: Exact EBM shape-function contributions + cited guideline on every card for independent review — not for time-critical triage.
- Oversight loop: Clinician final call; override/feedback KPI; near-miss QI review; monthly score-distribution review in pilots; change control with release notes.