Trust center
Regulatory posture for the ARKA platform, sourced from the in-repo FDA Pre-Submission (Q-Sub) package and supporting evidence. This page requests FDA feedback; it does not represent FDA approval, clearance, or endorsement.
Last updated: June 9, 2026
This page covers ARKA's FDA regulatory posture. For HIPAA, SOC 2, HITRUST, and data-security controls, see Security & Compliance. Module 3: ARKA does not store what your clinicians write.
Overview
ARKA Health, Inc. maintains a Pre-Submission (Q-Sub) package (version 1.0, June 9, 2026) requesting FDA written feedback on two software functions: ARKA-CLIN, designed to meet the four Non-Device Clinical Decision Support criteria under FD&C Act §520(o)(1)(E), and ARKA-INS, administrative-support software under §520(o)(1)(A). A reference-image viewer is documented as a separate display function outside the scope of that submission.
Package manifest: docs/regulatory/q-sub-draft/00_README.md · Final PDFs: docs/regulatory/q-sub-final/
Transparency Commitments for Software That Influences Clinical Ordering, v1.2 — published by ARKA Health
When you evaluate software that influences clinical ordering, you cannot verify whether appropriateness ratings carry published certainty distributions, whether payer criteria sit on the clinical path, or whether a vendor's performance number separates intervention from secular trend. These fifteen transparency commitments name what must be published and checked — so any buyer can ask any vendor the same questions.
Every published result in imaging utilisation is uncontrolled. So nobody can tell your finance team how much of a vendor's number was the intervention. There are no FHIR scopes, because there is no integration.
Each clause names the artefact that proves it and the check that enforces it. Version 1.2.0 · published 23 August 2026 · 9 live · 6 committed. Download PDF.
Clause 1 · Live since 2026-08-16
You publish every rating with a GRADE certainty and a conflict-of-interest class, and you publish the whole distribution — including the part that makes you look bad.
A vendor who will not publish how thin their evidence is is asking you to trust a black box.
Artefact: /evidence/methodology#how-certain
Enforced by:
CHECK-CERT-1Clause 2 · Live since 2026-08-16
You never let a payer-authored criterion influence a clinical appropriateness verdict — the count of payer-authored anchors on that path is zero.
If the clinical score is the payer's criteria with a white coat on, you bought utilisation management, not appropriateness.
Artefact: /data-flow#appropriateness-firewall
Enforced by:
no-payer-criteria-in-appropriatenessClause 3 · Live since 2026-08-09
You never automatically deny anything, and you never set a utilisation target.
An algorithm that can deny a scan or ratchet a target is a utilisation-pressure tool, not clinical decision support.
Artefact: /docs/ai-boundary
Enforced by:
never-auto-denyClause 4 · Live since 2026-08-09
You fix the measurement period in writing before the intervention is switched on, and you publish the analysis plan first.
Without a locked pre-period, any later claim of effect is storytelling — your finance team cannot verify it.
Artefact: /baseline
Enforced by:
CHECK-I5-LOCKClause 5 · Live since 2026-08-16
You publish your own corrections, dated, with the commit that fixed them.
A vendor that never corrects public claims is either perfect or opaque — and neither is credible.
Artefact: /evidence/methodology#corrections
Enforced by:
CHECK-CORR-2Clause 6 · Live since 2026-08-09
You never use anything a clinician writes for discipline, credentialing, or pay.
If free-text justification can reach HR or a bonus formula, clinicians will stop writing — and the mechanism dies.
Artefact: /security#what-we-dont-hold
Enforced by:
no-justification-for-disciplineClause 7 · Live since 2026-08-21
Identical input produces byte-identical output, and no language model writes clinical or patient-facing prose.
A recommendation you cannot regenerate is a recommendation you cannot audit.
Scope: byte-identical output applies only to deterministic and retrieval sources. Any site that enables a non-deterministic source must be recorded in the published register with the date and the site's acknowledgement. A site with a non-deterministic source enabled cannot reach the auto tier.
Artefact: /evidence/methodology#determinism-asset
Enforced by:
CHECK-SDM-1Clause 8 · Live since 2026-08-18
You publish research artefacts under an open licence with a resolvable identifier before you have customers.
A dataset that lives only in a private repo is not citable evidence — it is marketing copy with a spreadsheet attached.
Artefact: https://doi.org/10.5281/zenodo.22051812
Enforced by:
CHECK-BENCH-1Clause 9 · Committed — target 2026-09-30
You publish how often you interrupt clinicians, how often they accept, and what they said about it — including when the numbers are bad.
Every physician leader has been burned by alert fatigue; a published interrupt rate against a published ceiling is the scorecard they can hand a competitor.
Artefact: /api/aj/burden-report
Enforced by:
CHECK-BURD-1Clause 10 · Committed — target 2026-11-15
Ratings you are not confident about are reviewed by an independent multi-disciplinary panel constituted to the IOM standard, whose roster, conflicts, and decisions are public.
Who decides what is appropriate — and whether they are conflicted — is the question a medical director asks before they trust a rating.
Artefact: /governance/evidence-panel
Enforced by:
CHECK-CHARTER-PUBLISHClause 11 · Committed — target 2026-09-30
You monitor your own calibration and drift and publish the result, including when it gets worse.
A model that only publishes when it looks good is not monitoring — it is advertising.
Artefact: /monitoring
Enforced by:
CHECK-CAL-1Clause 12 · Live since 2026-08-23
You publish how often you decline to give a verdict at all, weighted by how often those scenarios are actually ordered, and the dated schedule on which your independent panel is reducing it.
A vendor who will not say how often they refuse to answer is selling confidence they do not have.
Artefact: /evidence/methodology#how-certain
Enforced by:
CHECK-ABST-1Clause 13 · Committed — target 2026-09-30
You never let the protocol engine see the payment rate. No reimbursement amount, payer identity, site-of-service payment differential or contract rate is an input to protocol candidate generation, gate evaluation, or the autonomy tier — and a test fails the build if one becomes reachable from that code path.
Every other party in the imaging chain has a reason to want the payment rate visible at protocol selection. A written, enforced refusal is the answer a compliance officer can forward.
Artefact: docs/protocol-payment-firewall.json
Enforced by:
CHECK-PROTO-2Clause 14 · Committed — target 2026-10-31
You never protocol a study without a human in the loop unless a named licensed physician at that site has signed the specific indication class, at a recorded version and date, and any auto-protocoled study can be reversed by a radiologist at any point before acquisition.
Who is responsible when it is wrong stays legible: a named physician drew the boundary; the engine stayed inside it; here is the reversal rate.
Artefact: lib/siteconfig/attestation.ts
Enforced by:
CHECK-AUT-1Clause 15 · Committed — target 2026-09-30
You never let the protocol engine read an image. Its inputs are the chart, the report text and the device record — and a reachability test fails the build if a pixel path becomes callable from the protocol module.
Criterion 1 of Non-Device CDS: reading a prior report is medical information; reading a prior DICOM study is image analysis. The gate stays on the report side of that line.
Artefact: docs/SCOPE_BOUNDARY.md
Enforced by:
CHECK-PROTO-8
Vendor questionnaire
Fifteen questions to ask any vendor whose software influences what a clinician orders. Published by ARKA Health, who answer all fifteen below. The blank vendor column comes first — that blank is the artefact. PDF · Plain text · CSV.
| Question | Your vendor's answer | ARKA's published answer | Where ARKA's answer is enforced |
|---|---|---|---|
| Q1 What proportion of your recommendations are supported by high-certainty evidence, and where is that published? | Yes. Every rating carries a GRADE certainty and a COI class; the full distribution is published in the certainty census (including the thin end). Artefact: /evidence/methodology#how-certain. | CHECK-CERT-1 | |
| Q2 How many of your clinical appropriateness anchors are authored by a payer, and where is that count published? | Zero. Payer-authored criteria never influence a clinical appropriateness verdict; the firewall count on that path is published. Artefact: /data-flow#appropriateness-firewall. | no-payer-criteria-in-appropriateness | |
| Q3 Does your tool ever automatically deny an order or set a utilisation target, and where is that prohibition published? | No. ARKA never automatically denies and never sets a utilisation target. Artefact: /docs/ai-boundary. | never-auto-deny | |
| Q4 Do you fix the measurement period in writing before the intervention is switched on, and where is that analysis plan published? | Yes. The pre-period is locked in writing and the analysis plan is published before the intervention is switched on. Artefact: /baseline. | CHECK-I5-LOCK | |
| Q5 Do you publish corrections to your own public claims, dated with the commit that fixed them, and where? | Yes. Corrections are dated, public, and tied to the fixing commit. Artefact: /evidence/methodology#corrections. | CHECK-CORR-2 | |
| Q6 Can anything a clinician writes into your tool be used for discipline, credentialing, or pay, and where is that prohibition published? | No. Justification text is never used for discipline, credentialing, or pay. Artefact: /security#what-we-dont-hold. | no-justification-for-discipline | |
| Q7 Can identical inputs regenerate identical outputs, and do language models write clinical or patient-facing prose in your product — where is that published? | Yes — identical input produces byte-identical output; no language model writes clinical or patient-facing prose. Artefact: /evidence/methodology#determinism-asset. | CHECK-SDM-1 | |
| Q8 Have you published research artefacts under an open licence with a resolvable identifier before you have customers, and where? | Yes. Research artefacts ship under an open licence with a resolvable identifier before revenue. Artefact: https://doi.org/10.5281/zenodo.22051812. | CHECK-BENCH-1 | |
| Q9 How often does your tool interrupt a clinician, against what published ceiling, and where is that published? | Yes. Interrupt rate, acceptance decomposition, and sentiment are published against published fire-rate ceilings (Alert Burden Report). Artefact: /api/aj/burden-report. | CHECK-BURD-1 | |
| Q10 Who is on your evidence panel, what are their conflicts, and where are their decisions published? | Yes. The independent evidence panel roster, conflicts, and decisions are public. Artefact: /governance/evidence-panel. | CHECK-CHARTER-PUBLISH | |
| Q11 Do you monitor and publish your own calibration and drift, including when it gets worse, and where? | Yes. Calibration and drift are monitored and published, including when they worsen. Artefact: /monitoring. | CHECK-CAL-1 | |
| Q12 What proportion of your recommendations does your system decline to make, and do you publish it? | Yes. The volume-weighted abstention rate among the most-ordered scenarios is published in the GRADE census, with a dated independent-panel burn-down. Artefact: /evidence/methodology#how-certain. | CHECK-ABST-1 | |
| Q13 Can your protocol engine see payment rates, payer identity, or contract rates at protocol selection, and where is the refusal published? | No. No reimbursement amount, payer identity, site-of-service differential, or contract rate is an input to protocol candidate generation, gate evaluation, or the autonomy tier; a reachability test fails the build if one becomes reachable. Artefact: docs/protocol-payment-firewall.json. | CHECK-PROTO-2 | |
| Q14 Does your system protocol studies without a human in the loop unless a named physician has signed that indication class, and where is that attestation published? | No. Auto-protocoled studies require a named licensed physician's signed attestation for the specific indication class at a recorded version and date; any auto-protocoled study can be reversed by a radiologist before acquisition. Artefact: lib/siteconfig/attestation.ts. | CHECK-AUT-1 | |
| Q15 Does your protocol engine read images, and where is the pixel-path firewall published? | No. Protocol inputs are the chart, report text, and device record only; a reachability test fails the build if a pixel path becomes callable from the protocol module. Artefact: docs/SCOPE_BOUNDARY.md. | CHECK-PROTO-8 |
Framework crosswalk
ARKA is not a certified Health IT Module and is not required to publish these attributes. Here they are. This crosswalk does not claim or imply certification, accreditation, or endorsement by ONC, CHAI, or the Joint Commission. Field names are the frameworks' own. CHAI Applied Model Card (JSON).
| Clause | Framework | Field name | ARKA artefact |
|---|---|---|---|
| 1 | CHAI Applied Model Card | OutcomesAndOutputs | /evidence/methodology#how-certain |
| 1 | ONC HTI-1 §170.315(b)(11) | Basis for recommendation | /evidence/methodology#how-certain |
| 2 | CHAI Applied Model Card | BiasMitigationApproaches | /data-flow#appropriateness-firewall |
| 2 | ONC HTI-1 §170.315(b)(11) | How output is generated | /data-flow#appropriateness-firewall |
| 3 | CHAI Applied Model Card | CautionedOutOfScopeSettings | /docs/ai-boundary |
| 3 | Joint Commission / CHAI Responsible Use of AI in Healthcare | AI policies & governance structures | /docs/ai-boundary |
| 4 | Joint Commission / CHAI Responsible Use of AI in Healthcare | Ongoing quality monitoring | /baseline |
| 5 | CHAI Applied Model Card | OngoingMaintenance | /evidence/methodology#corrections |
| 5 | ONC HTI-1 §170.315(b)(11) | Process for updating training data | /evidence/methodology#corrections |
| 6 | ONC HTI-1 §170.315(b)(11) | Clinician transparency statement | /security#what-we-dont-hold |
| 6 | Joint Commission / CHAI Responsible Use of AI in Healthcare | Patient privacy & transparency | /security#what-we-dont-hold |
| 7 | CHAI Applied Model Card | ModelType | /evidence/methodology#determinism-asset |
| 7 | ONC HTI-1 §170.315(b)(11) | How output is generated | /evidence/methodology#determinism-asset |
| 8 | CHAI Applied Model Card | PeerReviewedPublications | https://doi.org/10.5281/zenodo.22051812 |
| 8 | ONC HTI-1 §170.315(b)(11) | External validation and who performed it | https://doi.org/10.5281/zenodo.22051812 |
| 9 | ONC HTI-1 §170.315(b)(11) | Override and feedback capture | /api/aj/burden-report |
| 9 | Joint Commission / CHAI Responsible Use of AI in Healthcare | Ongoing quality monitoring | /api/aj/burden-report |
| 10 | ONC HTI-1 §170.315(b)(11) | External validation and who performed it | /governance/evidence-panel |
| 10 | Joint Commission / CHAI Responsible Use of AI in Healthcare | AI policies & governance structures | /governance/evidence-panel |
| 11 | CHAI Applied Model Card | OngoingMaintenance | /monitoring |
| 11 | ONC HTI-1 §170.315(b)(11) | How often validity and fairness are monitored in local data | /monitoring |
| 11 | Joint Commission / CHAI Responsible Use of AI in Healthcare | Ongoing quality monitoring | /monitoring |
| 12 | CHAI Applied Model Card | KnownRisksAndLimitations | /evidence/methodology#how-certain |
| 12 | ONC HTI-1 §170.315(b)(11) | Known failure modes | /evidence/methodology#how-certain |
| 13 | CHAI Applied Model Card | BiasMitigationApproaches | docs/protocol-payment-firewall.json |
| 13 | ONC HTI-1 §170.315(b)(11) | How output is generated | docs/protocol-payment-firewall.json |
| 14 | ONC HTI-1 §170.315(b)(11) | Clinician transparency statement | /throughput |
| 14 | Joint Commission / CHAI Responsible Use of AI in Healthcare | AI policies & governance structures | /throughput |
| 15 | CHAI Applied Model Card | CautionedOutOfScopeSettings | docs/SCOPE_BOUNDARY.md |
| 15 | ONC HTI-1 §170.315(b)(11) | How output is generated | docs/SCOPE_BOUNDARY.md |
Security questionnaire — paste-ready answers
The strongest security story for Modules 1 and 2 is that there is nothing to secure beyond a claims extract. Use these sentences verbatim in a vendor security review.
There are no FHIR scopes, because there is no integration.
Modules 1 and 2 run on a claims extract. No EHR integration, no FHIR scopes, no SMART launch, no PHI in a ledger row — member identifiers are SHA-256 hashed with a per-tenant salt at the ingestion boundary and never stored raw (invariant I1); dates of service are stored at month granularity in every aggregate table.
ARKA does not store justification text. No aj_ table may contain a column named text, justification, narrative, comment or body (invariant J6), and it is provable — `npm run aj:verify-no-text`. There is nothing for us to hand over, mine, or lose.
Full control narrative: Security → The strongest version of this answer. Attack-surface diagram: Data flow → Claims-extract path.
Firewall invariants (generated, not retyped)
Sourced from the three firewall.json artefacts CI emits — identical to /docs/ai-boundary.
IRE · docs/arka-ire/firewall.json · v1.0.0
- the appropriateness rating
- the approve/deny decision
- the protocol selection
- any safety gate
- anything written to an audit trail or a payer contract
TCOC · docs/arka-tcoc/firewall.json · v1.0.0
- PHI (MBI, HICN, SSN, raw memberId/patientId/beneficiaryId) in Row/Cell/Aggregate/Packet types
- unadjusted clinician comparison without riskAdjustment and reliability
- leaderboard, rank, bottom-N or worst-performers ordering on clinician-facing surfaces
- personally attributed dollar fields on PeerPacket
- UPDATE or DELETE on tcoc_baseline_locks
- non-deterministic Date.now / new Date() / Math.random / unordered Set-Map iteration in lib/tcoc
- Stat or Figure object literals without a provenance label
- throw from lib/tcoc except config.ts module-load validation
- joining justification (Module 3) text into peer or ledger aggregates
- joining clinician dispute free text into peer, ledger, stats, group, or incentive aggregates (I10)
- CDS Hooks imports from lib/tcoc (Module 2 is outside the EHR)
- peer imports of lib/tcoc/ledger/raw member-level rows
- peer or incentive import of lib/tcoc/calibration-ledger (outcome signals are claims facts, never a peer-comparison or contribution input)
- IRE (lib/aiie-v4/ire) imports from lib/tcoc/measures or lib/tcoc/stats — IRE is case-detail context only, never a measure/rate input
- Vol III §31.1 copy: 'improves appropriateness' / 'quality improvement' under components/tcoc or lib/tcoc
- an active variance class without an exported computation function and a test, a paused class without restart-trigger text, or a flipped class without dated statusHistory (CHECK-VAR-1)
- send/schedule delivery without requireLockedBaseline (invariant I11)
- Vol III §5.6 / §8.3 tone: outlier / bottom quartile / underperform / non-compliant / 'you must' / violation in peer copy or components/tcoc
- intervening on ordering behaviour before the LEAD benchmark is closed (measure-then-intervene)
- writing to an attribution assignment, HCC code, risk score or coding field outside the ingest boundary (no-attribution-or-risk-adjustment)
- documentation change whose effect is to increase a risk score or a billing level (no-coding-uplift-from-mdm-writeback)
- deriving a contribution figure from a beneficiary-attribution or risk-score field (contribution-attribution-is-not-beneficiary-attribution)
- ARKA setting a default, suggested, or ratcheted group utilisation goal (no-arka-set-utilisation-targets)
- ranking clinicians by unadjusted or absolute level rather than risk-adjusted change from own baseline (CHECK-GOAL-3)
- numeric redundancy window outside lib/tcoc/measures/duplicate-spec.ts (CHECK-DUP-1)
- duplicate figure on a public surface without a Provenance Chip and sensitivity label (CHECK-DUP-2)
- unreconciled duplicate cascade (CHECK-DUP-3)
- expansive duplicate exclusion (CHECK-DUP-4)
- the words savings, saved or ROI in the duplicate module or its rendered output (CHECK-DUP-5)
- per-clinician duplicate count on a clinician-facing artefact (CHECK-DUP-6)
- a payer-authored or utilisation-management source informing clinical appropriateness (no-payer-criteria-in-appropriateness)
- a default GRADE certainty assigned outside a matrix entry or test fixture (CHECK-GRADE-1)
- certaintyRationale copied from the clinical rationale or shorter than 40 characters (CHECK-GRADE-2)
- a certainty-history point with a change and neither panelRecordId nor content-commit SHA (CHECK-CERT-1)
- an artefact summary-statistic change without a named changelog row (CHECK-DIFF-1)
- a top-fifty abstention rate above the measured ceiling (CHECK-ABST-1)
- a certainty census renderer that shows only one series (CHECK-CERT-DUAL-1)
- unpublished panel decisions, including adverse decisions (panel-decisions-are-published-including-adverse)
- a conflicted chair or co-chair of the evidence panel (no-conflicted-chair)
- a knowledge-matrix certainty change without a signed panel-record decision row (CHECK-PANEL-1)
- a conflicted evidence-panel chair on a signed record (CHECK-PANEL-2)
- conflicted members constituting a majority of a panel session (CHECK-PANEL-3)
- a panel decision with an empty rationale (CHECK-PANEL-4)
- a panel record in which every decision raises certainty (CHECK-PANEL-5)
- a hand-edited evidence-panel review-queue ordering (CHECK-QUEUE-1)
- billing language in a clinical write-back template, UI copy or marketing (no-billing-language-in-clinical-writeback)
- write-back module reachable from attribution, ledger or incentive (no-writeback-in-attribution-or-incentive-path)
- published figures derived from note counts or note-write rate as clinician engagement (CHECK-CF-5)
- a commitment-device register row naming a JSON path that does not resolve (CHECK-CD-2)
- assigning a less favourable appropriateness rating because of care setting (no-care-setting-penalty)
- in-person evaluation in place of a study that the indication supports (no-in-person-evaluation-as-study-substitute)
- counting an in_person_evaluation recommendation as avoided spend (CHECK-IPE-SPEND-1)
AJ · docs/arka-aj/firewall.json · v1.0.0
- storing, logging, transmitting to a third party, or reading justification text
- joining justification text or its hash to any performance measure, peer packet, ledger cell, incentive computation or clinician-level aggregate
- blocking, delaying or conditioning an order signature
- requiring a minimum length, a structured taxonomy, or a selection in place of free text
- firing above the published ceilings
- raising a fire-rate ceiling in exchange for a commercial concession
- claiming an effect for a deployment where the record write is unavailable
Function map
Per the multiple-function analysis (Document 05), ARKA is a single platform with distinct software functions assessed separately:
- ARKA-CLIN — imaging appropriateness scores from structured data; ranked, evidence-cited options with reviewable basis. Regulatory basis presented: §520(o)(1)(E) Non-Device CDS (four criteria). Status requested: FDA concurrence (Question 1).
- ARKA-INS — benefit-eligibility determination, claims-based utilization/cost analysis, prior-authorization documentation (Da Vinci CRD/DTR/PAS), cost transparency, and scheduling. Regulatory basis presented: §520(o)(1)(A) administrative support. Status requested: FDA concurrence (Question 2).
- Reference viewer — displays previously acquired DICOM studies as non-diagnostic thumbnails. Documented as out of scope, walled off by
docs/SCOPE_BOUNDARY.mdand CI import guards.
ARKA-CLIN (Non-Device CDS)
Intended use (Document 03): ARKA-CLIN is intended for licensed health care professionals to support selection of clinically appropriate diagnostic imaging using structured clinical data. It presents ranked, evidence-cited imaging options drawn from published clinical guidelines and peer-reviewed literature, with the basis available for independent review. It does not acquire, process, or analyze medical images or physiological signals; does not provide time-critical alerts or triage; and does not place, cancel, or block orders.
Architecture (Document 02): rules-first engine — each appropriateness score is anchored to a published guideline; if no guideline-anchored rule fires, ARKA-CLIN returns no card. Appropriateness comes from the transparent AIIE 2.0 core; an optional glass-box EBM supplies calibrated concordance probability only (exact shape functions, Criterion 4). The system falls back to the rule-based faithful reference when the calibrator is unavailable. Inputs are structured FHIR R4 prefetch only; CI guards fail the build if image- or signal-processing code enters in-scope CDS paths.
Open FDA questions (Document 04) include concurrence on Non-Device CDS status, change-control expectations for the rule library and calibration-layer weights, and sufficiency of current guideline-concordance evidence (~87.5% concordance on a held-out signed-off scenario cohort — not presented as a clinical-outcome or clinical-performance claim; synthetic self-consistency is never equated with clinical validity).
ARKA-INS (administrative support)
ARKA-INS is intended for health care providers and qualified staff to determine health-benefit eligibility, analyze historical claims data, support prior-authorization documentation, and present cost-transparency and scheduling information — administrative functions under §520(o)(1)(A), not clinical diagnosis or treatment recommendations (Document 03). Detailed feature-level support is in Document 06 (06_INS_administrative_support_memo.md).
Supporting evidence
ARKA's AIIE engine is designed to operate independently of any single criteria licensor — drawing on peer-reviewed clinical literature, CMS Appropriate Use Criteria Program standards (PAMA §218(b)), and first-party machine-learning validation.
Attachments referenced in the Q-Sub package manifest:
- Model card —
ml-service/MODEL_CARD.md(Criteria 2 and 4) - Scope boundary —
docs/SCOPE_BOUNDARY.md(Criterion 1; viewer fenced out of CDS) - CI enforcement —
.github/workflows/go-live.yml,scripts/regulatory-checks.ts,scripts/lint-scope-boundary.ts,scripts/lint-cards.ts - Sandbox screenshots (5) —
docs/regulatory-evidence/sandbox-screenshots/ - Clinical sign-off log —
docs/CLINICAL_SIGN_OFF_LOG.md(pre-filing gate: in progress per manifest) - On-card FDA disclosure (v1.2.0) —
lib/compliance/fda-disclosure.ts - Render health snapshot —
docs/regulatory-evidence/render-health-2026-05-26.json(model loaded, catalog hashes recorded)
Pre-filing gates
From the Q-Sub package manifest — complete before submitting:
- Clinician sign-off — IN PROGRESS. At least one licensed clinician must review the rule library, citations, feature catalogue, and card language and sign a dated entry in
docs/CLINICAL_SIGN_OFF_LOG.md. - CDRH Portal account registered under the sponsor contact on file.
- PreSTAR2 v3.0 completed with "eSTAR COMPLETE" status before upload.
- Recommended: run FDA's Digital Health Policy Navigator for ARKA-CLIN and ARKA-INS separately and retain screenshots.
This package requests FDA feedback; it must never be described as FDA approval, clearance, registration, or endorsement.
Documentation
Full Q-Sub draft markdown: docs/regulatory/q-sub-draft/ · Final PDFs: docs/regulatory/q-sub-final/