Loading…
ARKA Clinical Decision Support is designed to meet all four criteria for Non-Device CDS under FD&C Act §520(o)(1)(E) and FDA's January 2026 final guidance on Clinical Decision Support Software. Recommendations support, not replace, the clinician's judgment. Every recommendation is anchored in a published guideline or peer-reviewed source, with the basis available for independent review. CLIN emphasizes imaging appropriateness at order entry.
This recommendation is intended to support, not replace, clinical judgment. It is generated by ARKA, software designed to meet the four criteria for Non-Device Clinical Decision Support under FD&C Act §520(o)(1)(E) and FDA's final guidance on Clinical Decision Support Software (January 2026). The clinician is responsible for the final decision.
For associate CMO / compliance
There are no FHIR scopes, because there is no integration. Modules 1 and 2 run on a claims extract — no EHR integration, no SMART launch, no PHI in a ledger row. You gate AI and CDS into production. The questions are hard: Will it auto-deny? What is the fire-rate ceiling? What will the vendor never do? You buy the never-do list, the AI boundary, and a governance packet your committee can vote on.
Your scorecard
The KPIs your board and leadership team track — where imaging leakage shows up first.
The problem
Benchmark-backed pain points tied to the metrics you own.
Never auto-deny
Any path that looks like automated coverage denial fails governance — and may fail state law.
Published ceilings
Committees ask how often cards fire and what happens when ceilings trip. Silent drops fail audit.
AI boundary
Stochastic proposers must not touch ratings, decisions, or audit fields — you need that firewall in writing and in code.
The fix
Each lever maps to a pain above — same order, same grid, so the pairing is obvious.
Generated from the three firewalls — what ARKA will never do, published for governance review.
Stochastic / deterministic firewall rendered from the IRE firewall manifest — readable by committee and engineer.
Sample Module 3 governance packet: fire-rate ceilings, never-auto-deny, and the mechanism floor — ready for committee.
The numbers
Modeled or published figures — labeled with their basis.
Never
auto-deny
enforced never-deny firewall
Published
fire-rate ceilings
Mechanism Ledger / AJ defaults
Packet
governance leave-behind
sample PDF for committee
Evidence
What we bring to the conversation — sourced from the ARKA buyer playbook.
Pushback
The concerns we hear most — and how we address them.
No. Language models may propose coded elements with provenance; they never produce ratings, approve/deny, protocol selection, or audit fields.
Start at /governance/never-do and /docs/ai-boundary — then the governance packet for the vote.
Fire-rate ceilings are enforced in code and published; a suppressed card is a recorded event, never a silent drop.
Your agenda
Three questions to put on the table — we'll answer with your data, not generic slides.
Question 1: What does your AI governance committee require in a submission packet?
Question 2: Is never-auto-deny a written policy today?
Question 3: Who owns fire-rate and override monitoring after go-live?
Explore
Jump into the modules most relevant to your seat.
30-minute governance review: never-do list, AI boundary, fire-rate ceilings, and the sample packet.
Quick answers
No — never-auto-deny is a hard rule, linted and documented on the never-do surface.
Download the sample governance packet, then review /governance/never-do and /docs/ai-boundary.
30-minute governance review: never-do list, AI boundary, fire-rate ceilings, and the sample packet.
