Loading…
Loading…
Implementation
ARKA embeds through standard CDS Hooks and SMART on FHIR — the same paths your EHR team already uses for non-prod app registration. No custom interface engine, no image pipeline, and no bulk PHI export.
Rollback
If you dislike it, you turn off one hook. There is no data migration, no schema change, and no residue.
ARKA attaches as a CDS Hooks service registration and a SMART on FHIR app record. Full deactivation is deregistering those entries in EHR configuration — one analyst, no interface-engine rebuild, no order-set rollback. Scope it to one department or one hook, or turn the whole thing off.
After you turn the hook off, the justification text stays in the chart because it is a clinical record entry, and that is correct. ARKA keeps only the receipt — hash, length, timestamp — and that receipt is unused once the hook is gone.
If ARKA is unreachable at order time, the order proceeds.
The EHR does exactly what it did before ARKA existed: no card renders, no order is delayed or blocked. ARKA cannot place, cancel, modify, or hold orders. A rules-only fallback also covers ML-service outages so guideline-anchored cards continue without the optional model.
Land motion
Volume VIII §9.2 ranks third among all your differentiators: "For the first product there are no FHIR scopes, because there is no integration."
There are no FHIR scopes, because there is no integration.
Modules 1 and 2 need none of these scopes. The land motion is a claims extract. The table of CDS Hooks / IRE read scopes is below, after data governance and the data-flow diagram. Skip to the FHIR scope table.
Committees
Buyers know their own committees. We do not publish a single blended go-live number. Each row is one gate: what it decides, a duration range we can source (or unknown), the artefact ARKA hands it, and whether Modules 1 and 2 — claims extract, no EHR — require it at all. The column that says not required is the argument.
| Committee | M1 Module 1 — Attribution & Variation Ledger | M2 Module 2 — Peer Comparison Engine | M3 Module 3 — Accountable Justification | M4 Module 4 — Indication Reconstruction | M5 Module 5 — Coverage / Gold-Card Bridge | Typical duration | ARKA artefact |
|---|---|---|---|---|---|---|---|
Security review Whether ARKA's trust boundary, architecture, and control posture are acceptable for the data that will actually move — a batch claims extract for Modules 1 and 2; a live CDS Hooks / SMART connection for Modules 3 and 4. | Required | Required | Required | Required | Required | 1–3 weeksIllustrative §1 table · Information Security / architecture. Typical calendar weeks from a complete packet (dossier + BAA draft + data request + baseline addendum). Not a measured ARKA deployment cycle. | Security & compliance package |
Privacy / HIPAA Whether the BAA, field list, hashing boundary, retention, deletion, and subprocessors are acceptable before any member-level extract or live FHIR session leaves the institution. | Required | Required | Required | Required | Required | 1–3 weeksIllustrative §1 table · Privacy / HIPAA / BAA review. Typical calendar weeks from a complete packet (dossier + BAA draft + data request + baseline addendum). Not a measured ARKA deployment cycle. | Data-flow & PHI statement |
Clinical informatics governance EHR app review, FHIR scope negotiation, CDS Hooks registration, SMART launch, and interface-engine change control. Modules 1 and 2 never attach to the EHR, so this seat does not vote on the land motion. Module 5's gold-card export is a file, not a hook. For Module 3, this seat also decides whether to enable the considered-and-deferred note write-back: a named physician leader must approve enablement in writing (site, date, scope, Clause 10.5) before the feature may turn on — recorded in docs/governance/WRITEBACK_ENABLEMENT_LOG.md. | Not required | Not required | Required | Required | Not required | unknown ARKA has not closed an EHR-committee cycle. A point estimate here would be a guess; the land motion does not wait on this seat. | AI governance packet |
Value analysis Whether the spend, evidence posture, and intended use are acceptable for a departmental or enterprise purchase. This is a procurement seat, not an EHR-app board — it still meets for a claims-only deal. | Required | Required | Required | Required | Required | unknown No value-analysis cycle has closed. The VAC packet exists; a duration does not, and we will not invent one. | Value Analysis Committee packet |
Contracting / legal MSA, BAA, baseline-lock addendum, exit language, and the written commitments that justification text is never used for discipline, credentialing, or compensation. | Required | Required | Required | Required | Required | 2–6 weeksIllustrative §1 table · Contract / procurement. Typical calendar weeks from a complete packet (dossier + BAA draft + data request + baseline addendum). Not a measured ARKA deployment cycle. | Vendor portal |
IRB Human-subjects determination when a study is involved — QI / quality-assessment, expedited minimal-risk, or full board. The commercial land of Modules 1 and 2 (claims extract, no study) does not require this seat. | Not required | Not required | If a study | If a study | If a study | unknown Duration depends on the site's QI vs. expedited vs. full-board classification. ARKA has not closed an IRB cycle; planning bands by pathway live in docs/human-gates/HG-03_IRB_STUDY_PACKET.md and are not a duration for this gate. | Evidence methodology (study status) |
Data-governance committee Who may see whose rate. Small-cell suppression at n < 11, no ranking at any transparency level, clinician vs. medical-director surfaces, retention, and the dispute path. This seat owns the risk thesis for Modules 1, 2, and the Module 5 gold-card export. | Required | Required | Not required | Not required | Required | 1–2 weeksIllustrative §1 table · Data governance / analytics stewardship. Typical calendar weeks from a complete packet (dossier + BAA draft + data request + baseline addendum). Not a measured ARKA deployment cycle. | What we will never do |
Data governance
For a risk-bearing buyer this section matters more than the FHIR scopes. Each statement is generated from the never-do catalog or a firewall artefact and names the check that proves it. A claim with a linter behind it is a different kind of statement from one without.
| Actor | May see | May not see | Check |
|---|---|---|---|
| Attributed clinician | monthly peer packets comparing a clinician to top performers (not the mean, not a rank). The ledger query returns that clinician's own risk- and reliability-adjusted rows plus organisation aggregates (filterCellsForCaller in lib/tcoc/ledger/query.ts). | No leaderboard, no rank, no bottom-N. No personally attributed dollar figure in a clinician-facing artefact. Peer names, other clinicians' case lists, and ranks are out of the response. | CHECK-I3-RANK; CHECK-I4-DOLLARS |
| Medical director / quality lead | The organisation distribution and organisation-level dollar model. filterCellsForCaller returns the full tenant set, unsorted by rate. | No leaderboard, no rank, no bottom-N. An ordered leaderboard with names is forbidden on every surface, including this one. | CHECK-I3-RANK |
Who may see whose rate is the ledger role split in filterCellsForCaller: a clinician sees their own risk- and reliability-adjusted rate; a medical director sees the distribution, never sorted by rate. No leaderboard, no rank, no bottom-N. No personally attributed dollar figure in a clinician-facing artefact. Enforced by CHECK-I3-RANK and CHECK-I4-DOLLARS.
CHECK-I3-RANK · linter · never-do no-leaderboard
The default transparency level is blinded-distribution — The distribution is shown without names; each clinician sees only their own position on their packet. Ranking is not available at any of aggregate-only, blinded-distribution, named-to-leadership, named-to-group. No leaderboard, no rank, no bottom-N. Enforced by CHECK-I3-RANK and CHECK-GOAL-3.
CHECK-I3-RANK · linter · never-do no-leaderboard
Locked baselines, ledger aggregates, and delivery audit rows are retained for the contract term plus 6 years (or longer if law requires), aligned with security-evidence retention (45 C.F.R. § 164.316). baseline locks that are append-only and hash-chained. Aggregates and lock rows remain as long as the analysis must remain replayable. Small cells (n < 11) are suppressed and the suppression is stated. Lock immutability is enforced by CHECK-I5-LOCK; the 6-year floor is the contractual term in docs/arka-tcoc/BASELINE_ADDENDUM.md clause 7, and CHECK-DOSSIER-2 fails if that file and this sentence drift.
CHECK-I5-LOCK · linter
Justification text is never used for discipline, credentialing, or compensation. justification text and its hash cannot be joined to peer, ledger, stats, group, or incentive aggregates. Enforced by CHECK-I10-JUSTIF in scripts/lint-tcoc.ts; CHECK-J5-JOIN / CHECK-J5-BRIDGE in scripts/lint-aj-firewall.ts; aj_ schema forbid.
CHECK-I10-JUSTIF · linter · never-do no-justification-for-discipline
ARKA measures which clinician's ordering behaviour changed against a locked pre-period, and exports that measurement. ARKA never uses, alters or influences the assignment of beneficiaries to clinicians, and never derives a contribution figure from a field that determines attribution or risk score. The two are computed from disjoint inputs and the build proves it. deriving a contribution figure from a beneficiary-attribution or risk-score field (contribution-attribution-is-not-beneficiary-attribution). ARKA does not compute, influence, or recommend changes to beneficiary attribution or to risk-adjustment coding. Attribution and risk scores are read-only inputs supplied by your organisation. We measure avoided utilisation against the attribution and risk model you give us, and we publish the specification of how we use them. Enforced by CHECK-INC-1 and CHECK-INC-2 in scripts/lint-tcoc.ts; the disjoint-input proof in docs/attribution-firewall.json; Clause 8 in docs/arka-aj/DEPLOYMENT_AGREEMENT_CLAUSES.md.
CHECK-INC-1 · linter · never-do contribution-attribution-is-not-beneficiary-attribution
ARKA can auto-approve; it can never auto-deny. adverse determination (deny / modify / downgrade) only with a verified licensed-physician reviewer identity. adverse determinations require a human licensed-physician reviewer identity with a verified NPI; automation may only auto-approve or route to clinical review; ARKA-IP may recommend a second review and may never cancel, convert, hold or set the status of an order. Enforced by evaluateReviewerAuthorization in lib/ins/reviewer-queue.ts; lint:never-deny (CHECK-ND-1…CHECK-ND-8); lib/arka-ip/never-deny.ts; IRE decision-surface test.
CHECK-ND-1 · linter · never-do never-auto-deny
A payer-authored or utilisation-management source may inform a coverage determination and may never inform clinical appropriateness. The two field sets are disjoint and the build proves it. a payer-authored or utilisation-management source informing clinical appropriateness (no-payer-criteria-in-appropriateness). No payer-authored or utilisation-management source may inform a clinical appropriateness rating. Verdict A (score.ts and the knowledge matrix) and Verdict B (lib/coverage) are computed from disjoint field sets in docs/appropriateness-firewall.json; the clinical engine cannot reach lib/coverage, lib/pa, lib/davinci or lib/ins even transitively; no ModalityRating carries a payer_um / payer_utilization anchor.. Enforced by CHECK-APPR-1 in scripts/lint-tcoc.ts; CHECK-FW-1..3 in lint:sources / lint:coverage / lint:scope; the disjoint-input proof in docs/appropriateness-firewall.json; Clause 9 in docs/arka-aj/DEPLOYMENT_AGREEMENT_CLAUSES.md.
CHECK-APPR-1 · linter · never-do no-payer-criteria-in-appropriateness
No ARKA surface, artefact, metric, export, contract clause or piece of marketing may reference evaluation-and-management coding, billing level, code selection or reimbursement in connection with the considered-and-deferred note — and the build fails if one does. The one-page write-back brief at /api/compliance/writeback-brief (also on /compliance/regulatory-standing#writeback-brief) states what the note is, who authors it, what ARKA never sees, counts or is paid for, the five rules with the check that enforces each, the Clause 10 mirror of each rule, and the enablement record. Every claim in that brief is traced under CHECK-WBB-1.
CHECK-WBB-1 · linter · never-do no-billing-language-in-clinical-writeback
Data flow
Generated from the live flow graph, not drawn. Identifiable data crosses only the CDS Hooks session and the Module 3 chart write; federated outcomes and calibration aggregate without moving identifiable data.
Scopes
Volume VIII §9.2 ranks third among all your differentiators: "For the first product there are no FHIR scopes, because there is no integration."
Modules 1 and 2 need none of these scopes. The land motion is a claims extract. The rows below are the CDS Hooks / IRE read scopes, generated from the live prefetch configuration. A withheld class degrades or abstains — it never fails silently.
| Resource | SMART scope | Why the engine needs it | If withheld | M1 / M2 |
|---|---|---|---|---|
| AllergyIntolerance | patient/AllergyIntolerance.rs | Contrast and other allergies support premedication or modality-change context in the chart. | Degrade. Degrade — contrast and other allergy context is omitted and the miss is recorded. | Not required |
| Condition | patient/Condition.rs | Active conditions define the differential the order is working — core structured indication material. | Degrade. Degrade — completeness is recorded as degraded and the missing class is written to the degradation array; scoring continues on remaining structured context. | Not required |
| Device | patient/Device.rs | Implanted devices and MRI conditionality matter to indication completeness and modality choice context. | Degrade. Degrade — implanted-device and MRI-conditionality context is omitted and the miss is recorded. | Not required |
| DiagnosticReport | patient/DiagnosticReport.rs | Pathology reports (known malignancy) change staging-protocol framing for the indication. Prior radiology reports change protocol context (e.g. delayed-phase follow-up) for the reconstructed indication. | Degrade. Degrade — prior radiology and pathology reports are omitted from Phase B; the miss is recorded. | Not required |
| DocumentReference | patient/DocumentReference.rs | Clinical notes are the richest narrative source for Phase B (mechanism, red flags, functional impact). | Degrade. Degrade — Phase B narrative notes are skipped; reconstruction stays structured_only and the miss is recorded. | Not required |
| Encounter | patient/Encounter.rs | ED vs inpatient vs ambulatory changes the decision frame for the reconstructed indication. | Degrade. Degrade — setting (ED / inpatient / ambulatory) is omitted from the reconstructed indication and the miss is recorded. | Not required |
| ImagingStudy | patient/ImagingStudy.rs | Recent imaging-study metadata (identifiers and timestamps, not pixels) lets the engine see prior exams in the episode without a PACS pull. | Degrade. Degrade — prior-study metadata is an empty bundle; scoring continues without that context and the miss is logged, not silent. | Not required |
| MedicationRequest | patient/MedicationRequest.rs | Active meds (anticoagulation, metformin, nephrotoxics) enrich mechanism and prior-treatment context. | Degrade. Degrade — active-medication context (anticoagulation, metformin, nephrotoxics) is omitted and the miss is recorded. | Not required |
| Observation | patient/Observation.rs | Recent labs (WBC, lactate, CRP, troponin, D-dimer, LFTs, lipase, INR, hCG, eGFR) change study territory and urgency framing. Vitals (HR, BP, SpO₂, temp, RR, FiO₂) ground acuity and exam-finding elements for Phase A. | Degrade. Degrade — labs and vitals are omitted from the indication; the miss is recorded. The engine does not invent values. | Not required |
| Patient | patient/Patient.rs | Age and administrative sex gate reconstruction and every card; the Patient resource is the session context token, not a chart dump. | Abstain. Abstain — reconstruction does not start and the EHR receives no card. The order still proceeds. | Not required |
| Procedure | patient/Procedure.rs | Recent procedures and surgeries frame implant/post-op status relevant to the indication. | Degrade. Degrade — recent procedure and implant/post-op context is omitted and the miss is recorded. | Not required |
| ServiceRequest | patient/ServiceRequest.rs | Prior completed imaging orders are the duplicate and redundancy window; the in-flight draft order arrives from hook context, not this prefetch key. | Degrade. Degrade — prior completed ServiceRequests become an empty bundle; the in-flight order still comes from CDS Hooks context. The miss is recorded. | Not required |
The write-back path is one narrow, named case: Module 3 accountable justification, posting the clinician's words to the chart as a ServiceRequest annotation under the clinician's SMART token (`user/ServiceRequest.u`, with `user/ServiceRequest.write` as the v1 fallback). That is not a prefetch scope, and it is not requested for Modules 1 and 2.
Security
Penetration test: first independent test scheduled Q4 2026; engagement letter shareable under NDA; executive summary shared with customers post-remediation.
HIPAA — Privacy, Security & Breach Notification Rules Program in force
Full privacy and security policy suite adopted and operating; business associate agreement ready for execution; annual NIST 800-30 risk analysis complete.
SOC 2 — Security, Availability, Confidentiality In progress
Readiness assessment complete against the 2017 Trust Services Criteria (2022 points of focus). Type I examination targeted December 2026; Type II report mid-2027.
HITRUST e1 — Essentials, 1-Year Validated Roadmap active
44-requirement e1 tier selected as the appropriate entry certification; MyCSF self-assessment Q1 2027, validated assessment H1 2027. ~80–90% control overlap with the SOC 2 program lets one evidence body serve both.
2025 HIPAA Security Rule NPRM Adopted as baseline
The December 2024 OCR proposal's heightened specifications are ARKA's internal baseline today: mandatory MFA, universal encryption, asset inventory and network map, six-month vulnerability scans, annual penetration testing, segmentation, 72-hour restore capability.
Access control
ARKA processes structured FHIR resources in the EHR's context at the moment of order as your Business Associate — transiently in the CDS Hooks / SMART request path, not bulk-exported or warehoused as raw charts. ARKA does NOT ingest image pixels. Only de-identified order features and scoring outcomes persist (SHA-256–hashed order and patient keys, age buckets, ICD-10/CPT codes, AIIE scores, and scrubbed factor metadata), redacted CDS decision-log fingerprints, federated aggregate query audit metadata, and standard security event logs — encrypted in transit and at rest, with append-only audit logging. Model improvement uses federated analytics on de-identified or aggregated signals — row-level patient records never leave the institution in federated queries.
Customers are notified at least 30 days before ARKA adds a PHI-touching subprocessor — aligned with BAA subcontractor flow-down and customary objection rights.
| Subprocessor | Function | Data touched | BAA | Region |
|---|---|---|---|---|
| Vercel, Inc. | Edge / application hosting (Next.js, CDS Hooks & API routes) | Structured FHIR prefetch and CDS context processed transiently in the request path — no PHI persisted at the edge | Required before production PHI | United States (primary: iad1) |
| Supabase, Inc. | PostgreSQL data tier (tenant-isolated databases, row-level security) | De-identified audit rows, hashed identifiers, AIIE scores, security event logs — encrypted at rest | Required before production PHI | United States |
| Render Services, Inc. | Optional ML inference service (when ML_SERVICE_URL is configured) | Structured order features for AIIE scoring in the CDS request path — rule-based fallback when unset or unreachable | Required before production PHI | United States |
Effort
A "free" pilot that consumes 200 hours of a customer's analyst time is not free.
Integrated modules — 40 hours
The integrated modules (CDS Hooks / SMART on FHIR) cost 40 analyst hours.
Claims-only baseline — 0 hours
The claims-only baseline motion costs 0 analyst hours.
Rollout path
Each phase lists what ARKA delivers and what your team provides — typical imaging pilots complete in six to eight weeks after agreements are signed.
Week 0
ARKA does
Execute MSA and BAA, share the 21-document security package from our Trust Center, provision sandbox credentials, and seed your security questionnaire responses from the published controls on /security.
You provide
Procurement and security reviewers to execute agreements, complete the vendor questionnaire, and approve sandbox access for the integration team.
Weeks 1–2
ARKA does
Provide CDS Hooks discovery URL, SMART on FHIR launch parameters, and registration checklists. ARKA consumes structured FHIR order-select context from the EHR prefetch bundle — no image pixels, no bulk PHI export.
You provide
Your EHR/integration team registers ARKA as a CDS Hooks service and SMART on FHIR app in non-production — designed for Epic, Oracle Health (Cerner), and athenahealth after customer-specific validation. Typical lift: one analyst, light ARKA support.
Weeks 2–4
ARKA does
Map service lines and payer mix, narrow pilot scope to one department and one payer, tune auto-clear thresholds toward 35–40%, and align card copy with our CDS Card Language Style Guide (supportive, non-coercive, evidence-first).
You provide
Clinical and revenue-cycle sponsors to confirm pilot boundaries, approve threshold targets, and sign off on in-flow card wording before shadow mode.
Weeks 4–6
ARKA does
Run shadow mode alongside live traffic, publish validation metrics and drill-down rows, and complete conformance checks against CDS Hooks and Da Vinci CRD expectations.
You provide
Clinical champion reviews shadow cards against local practice patterns, logs sign-off, and confirms the pilot KPI baseline before production enablement.
Weeks 6–8
ARKA does
Enable ARKA in production for the agreed pilot scope, monitor API latency and card delivery, and report ROI and utilization metrics through the observability dashboards.
You provide
Change-control approval for production CDS registration, a named on-call contact for the first two weeks, weekly readouts with your champion and rev-cycle lead, and confirmation that the rollback runbook is delivered and walked through before production enablement.
Risk controls
Rollback, downtime behavior, service levels, and alert-fatigue guardrails — documented before go-live for health-IT and clinical reviewers.
Rollback protocol — ≤2 business hours, zero EHR rebuild
If you dislike it, you turn off one hook. There is no data migration, no schema change, and no residue. ARKA attaches as a CDS Hooks service registration and a SMART on FHIR app record. Full deactivation is deregistering those entries in EHR configuration — one analyst, no interface-engine rebuild, no order-set rollback. Scope it to one department or one hook, or turn the whole thing off. After you turn the hook off, the justification text stays in the chart because it is a clinical record entry, and that is correct. ARKA keeps only the receipt — hash, length, timestamp — and that receipt is unused once the hook is gone. We commit to a documented rollback runbook delivered before go-live and a ≤2-business-hour assisted rollback SLA.
Failure behavior — fail-open by design
If ARKA is unreachable at order time, the order proceeds. The EHR does exactly what it did before ARKA existed: no card renders, no order is delayed or blocked. ARKA cannot place, cancel, modify, or hold orders. A rules-only fallback also covers ML-service outages so guideline-anchored cards continue without the optional model.
Go-live service levels
Availability targets, incident response tiers, and scoring latency commitments are shared during contracting and documented in the MSA SLA exhibit. During the first two production weeks: daily check-ins and a named on-call engineer.
Named implementation engineer
Every deployment is assigned a named ARKA implementation engineer — one accountable human from Phase 1 through 90 days post-go-live, present in weekly readouts (also the escalation point in the SLA).
Alert-fatigue guardrails
ARKA is silent unless a guideline fires (zero-click baseline measured on the pilot scorecard); card volume thresholds are reviewed weekly during the pilot; any card class exceeding agreed volume or override thresholds is tuned or retired via the shadow-mode review loop with your clinical champion (Phase 3). Override/feedback rates are a first-class KPI on /outcomes, not an afterthought.
Change management & training
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.
Integration boundary
Structured FHIR only — ARKA reads the CDS Hooks prefetch bundle (Patient, ServiceRequest, Condition, Coverage, and related R4 resources your EHR already exposes at order-select).
No image pixels — DICOM, PACS, and pixel-level analysis are out of scope; ARKA is a Non-Device CDS layer on structured order context.
PHI processed transiently as your BA — structured FHIR in the CDS Hooks / SMART request path only; identifiers are hashed before persistence, and there is no bulk PHI export from the EHR. See our data-flow & PHI statement.
Your team
A typical single-department imaging pilot needs three named owners plus an optional rev-cycle partner — not a dedicated project squad.
EHR integration analyst
~20–40 hours (weeks 1–4)
Registers CDS Hooks services and the SMART app in non-prod and production, validates prefetch scopes, and attends one ARKA working session per week during connect and configure.
Security / privacy reviewer
~8–12 hours (week 0)
Reviews the BAA, security questionnaire, and data-flow statement; approves sandbox and production network paths with your CISO or delegate.
Clinical champion (CMIO or service-line lead)
~4–8 hours (weeks 2–6)
Defines pilot scope, approves card copy and auto-clear thresholds, reviews shadow-mode output, and signs the clinical go-live log.
Revenue-cycle / denials lead (optional but recommended)
~2–4 hours (weeks 4–8)
Supplies baseline denial and clean-claim metrics, validates KPI definitions, and co-owns the weekly pilot readout with finance.
Next steps
Download the Implementation Dossier, review the pilot scope, and walk security through the published compliance package.
Implementation
ARKA embeds through standard CDS Hooks and SMART on FHIR — the same paths your EHR team already uses for non-prod app registration. No custom interface engine, no image pipeline, and no bulk PHI export.
Rollback
If you dislike it, you turn off one hook. There is no data migration, no schema change, and no residue.
ARKA attaches as a CDS Hooks service registration and a SMART on FHIR app record. Full deactivation is deregistering those entries in EHR configuration — one analyst, no interface-engine rebuild, no order-set rollback. Scope it to one department or one hook, or turn the whole thing off.
After you turn the hook off, the justification text stays in the chart because it is a clinical record entry, and that is correct. ARKA keeps only the receipt — hash, length, timestamp — and that receipt is unused once the hook is gone.
If ARKA is unreachable at order time, the order proceeds.
The EHR does exactly what it did before ARKA existed: no card renders, no order is delayed or blocked. ARKA cannot place, cancel, modify, or hold orders. A rules-only fallback also covers ML-service outages so guideline-anchored cards continue without the optional model.
Land motion
Volume VIII §9.2 ranks third among all your differentiators: "For the first product there are no FHIR scopes, because there is no integration."
There are no FHIR scopes, because there is no integration.
Modules 1 and 2 need none of these scopes. The land motion is a claims extract. The table of CDS Hooks / IRE read scopes is below, after data governance and the data-flow diagram. Skip to the FHIR scope table.
Committees
Buyers know their own committees. We do not publish a single blended go-live number. Each row is one gate: what it decides, a duration range we can source (or unknown), the artefact ARKA hands it, and whether Modules 1 and 2 — claims extract, no EHR — require it at all. The column that says not required is the argument.
| Committee | M1 Module 1 — Attribution & Variation Ledger | M2 Module 2 — Peer Comparison Engine | M3 Module 3 — Accountable Justification | M4 Module 4 — Indication Reconstruction | M5 Module 5 — Coverage / Gold-Card Bridge | Typical duration | ARKA artefact |
|---|---|---|---|---|---|---|---|
Security review Whether ARKA's trust boundary, architecture, and control posture are acceptable for the data that will actually move — a batch claims extract for Modules 1 and 2; a live CDS Hooks / SMART connection for Modules 3 and 4. | Required | Required | Required | Required | Required | 1–3 weeksIllustrative §1 table · Information Security / architecture. Typical calendar weeks from a complete packet (dossier + BAA draft + data request + baseline addendum). Not a measured ARKA deployment cycle. | Security & compliance package |
Privacy / HIPAA Whether the BAA, field list, hashing boundary, retention, deletion, and subprocessors are acceptable before any member-level extract or live FHIR session leaves the institution. | Required | Required | Required | Required | Required | 1–3 weeksIllustrative §1 table · Privacy / HIPAA / BAA review. Typical calendar weeks from a complete packet (dossier + BAA draft + data request + baseline addendum). Not a measured ARKA deployment cycle. | Data-flow & PHI statement |
Clinical informatics governance EHR app review, FHIR scope negotiation, CDS Hooks registration, SMART launch, and interface-engine change control. Modules 1 and 2 never attach to the EHR, so this seat does not vote on the land motion. Module 5's gold-card export is a file, not a hook. For Module 3, this seat also decides whether to enable the considered-and-deferred note write-back: a named physician leader must approve enablement in writing (site, date, scope, Clause 10.5) before the feature may turn on — recorded in docs/governance/WRITEBACK_ENABLEMENT_LOG.md. | Not required | Not required | Required | Required | Not required | unknown ARKA has not closed an EHR-committee cycle. A point estimate here would be a guess; the land motion does not wait on this seat. | AI governance packet |
Value analysis Whether the spend, evidence posture, and intended use are acceptable for a departmental or enterprise purchase. This is a procurement seat, not an EHR-app board — it still meets for a claims-only deal. | Required | Required | Required | Required | Required | unknown No value-analysis cycle has closed. The VAC packet exists; a duration does not, and we will not invent one. | Value Analysis Committee packet |
Contracting / legal MSA, BAA, baseline-lock addendum, exit language, and the written commitments that justification text is never used for discipline, credentialing, or compensation. | Required | Required | Required | Required | Required | 2–6 weeksIllustrative §1 table · Contract / procurement. Typical calendar weeks from a complete packet (dossier + BAA draft + data request + baseline addendum). Not a measured ARKA deployment cycle. | Vendor portal |
IRB Human-subjects determination when a study is involved — QI / quality-assessment, expedited minimal-risk, or full board. The commercial land of Modules 1 and 2 (claims extract, no study) does not require this seat. | Not required | Not required | If a study | If a study | If a study | unknown Duration depends on the site's QI vs. expedited vs. full-board classification. ARKA has not closed an IRB cycle; planning bands by pathway live in docs/human-gates/HG-03_IRB_STUDY_PACKET.md and are not a duration for this gate. | Evidence methodology (study status) |
Data-governance committee Who may see whose rate. Small-cell suppression at n < 11, no ranking at any transparency level, clinician vs. medical-director surfaces, retention, and the dispute path. This seat owns the risk thesis for Modules 1, 2, and the Module 5 gold-card export. | Required | Required | Not required | Not required | Required | 1–2 weeksIllustrative §1 table · Data governance / analytics stewardship. Typical calendar weeks from a complete packet (dossier + BAA draft + data request + baseline addendum). Not a measured ARKA deployment cycle. | What we will never do |
Data governance
For a risk-bearing buyer this section matters more than the FHIR scopes. Each statement is generated from the never-do catalog or a firewall artefact and names the check that proves it. A claim with a linter behind it is a different kind of statement from one without.
| Actor | May see | May not see | Check |
|---|---|---|---|
| Attributed clinician | monthly peer packets comparing a clinician to top performers (not the mean, not a rank). The ledger query returns that clinician's own risk- and reliability-adjusted rows plus organisation aggregates (filterCellsForCaller in lib/tcoc/ledger/query.ts). | No leaderboard, no rank, no bottom-N. No personally attributed dollar figure in a clinician-facing artefact. Peer names, other clinicians' case lists, and ranks are out of the response. | CHECK-I3-RANK; CHECK-I4-DOLLARS |
| Medical director / quality lead | The organisation distribution and organisation-level dollar model. filterCellsForCaller returns the full tenant set, unsorted by rate. | No leaderboard, no rank, no bottom-N. An ordered leaderboard with names is forbidden on every surface, including this one. | CHECK-I3-RANK |
Who may see whose rate is the ledger role split in filterCellsForCaller: a clinician sees their own risk- and reliability-adjusted rate; a medical director sees the distribution, never sorted by rate. No leaderboard, no rank, no bottom-N. No personally attributed dollar figure in a clinician-facing artefact. Enforced by CHECK-I3-RANK and CHECK-I4-DOLLARS.
CHECK-I3-RANK · linter · never-do no-leaderboard
The default transparency level is blinded-distribution — The distribution is shown without names; each clinician sees only their own position on their packet. Ranking is not available at any of aggregate-only, blinded-distribution, named-to-leadership, named-to-group. No leaderboard, no rank, no bottom-N. Enforced by CHECK-I3-RANK and CHECK-GOAL-3.
CHECK-I3-RANK · linter · never-do no-leaderboard
Locked baselines, ledger aggregates, and delivery audit rows are retained for the contract term plus 6 years (or longer if law requires), aligned with security-evidence retention (45 C.F.R. § 164.316). baseline locks that are append-only and hash-chained. Aggregates and lock rows remain as long as the analysis must remain replayable. Small cells (n < 11) are suppressed and the suppression is stated. Lock immutability is enforced by CHECK-I5-LOCK; the 6-year floor is the contractual term in docs/arka-tcoc/BASELINE_ADDENDUM.md clause 7, and CHECK-DOSSIER-2 fails if that file and this sentence drift.
CHECK-I5-LOCK · linter
Justification text is never used for discipline, credentialing, or compensation. justification text and its hash cannot be joined to peer, ledger, stats, group, or incentive aggregates. Enforced by CHECK-I10-JUSTIF in scripts/lint-tcoc.ts; CHECK-J5-JOIN / CHECK-J5-BRIDGE in scripts/lint-aj-firewall.ts; aj_ schema forbid.
CHECK-I10-JUSTIF · linter · never-do no-justification-for-discipline
ARKA measures which clinician's ordering behaviour changed against a locked pre-period, and exports that measurement. ARKA never uses, alters or influences the assignment of beneficiaries to clinicians, and never derives a contribution figure from a field that determines attribution or risk score. The two are computed from disjoint inputs and the build proves it. deriving a contribution figure from a beneficiary-attribution or risk-score field (contribution-attribution-is-not-beneficiary-attribution). ARKA does not compute, influence, or recommend changes to beneficiary attribution or to risk-adjustment coding. Attribution and risk scores are read-only inputs supplied by your organisation. We measure avoided utilisation against the attribution and risk model you give us, and we publish the specification of how we use them. Enforced by CHECK-INC-1 and CHECK-INC-2 in scripts/lint-tcoc.ts; the disjoint-input proof in docs/attribution-firewall.json; Clause 8 in docs/arka-aj/DEPLOYMENT_AGREEMENT_CLAUSES.md.
CHECK-INC-1 · linter · never-do contribution-attribution-is-not-beneficiary-attribution
ARKA can auto-approve; it can never auto-deny. adverse determination (deny / modify / downgrade) only with a verified licensed-physician reviewer identity. adverse determinations require a human licensed-physician reviewer identity with a verified NPI; automation may only auto-approve or route to clinical review; ARKA-IP may recommend a second review and may never cancel, convert, hold or set the status of an order. Enforced by evaluateReviewerAuthorization in lib/ins/reviewer-queue.ts; lint:never-deny (CHECK-ND-1…CHECK-ND-8); lib/arka-ip/never-deny.ts; IRE decision-surface test.
CHECK-ND-1 · linter · never-do never-auto-deny
A payer-authored or utilisation-management source may inform a coverage determination and may never inform clinical appropriateness. The two field sets are disjoint and the build proves it. a payer-authored or utilisation-management source informing clinical appropriateness (no-payer-criteria-in-appropriateness). No payer-authored or utilisation-management source may inform a clinical appropriateness rating. Verdict A (score.ts and the knowledge matrix) and Verdict B (lib/coverage) are computed from disjoint field sets in docs/appropriateness-firewall.json; the clinical engine cannot reach lib/coverage, lib/pa, lib/davinci or lib/ins even transitively; no ModalityRating carries a payer_um / payer_utilization anchor.. Enforced by CHECK-APPR-1 in scripts/lint-tcoc.ts; CHECK-FW-1..3 in lint:sources / lint:coverage / lint:scope; the disjoint-input proof in docs/appropriateness-firewall.json; Clause 9 in docs/arka-aj/DEPLOYMENT_AGREEMENT_CLAUSES.md.
CHECK-APPR-1 · linter · never-do no-payer-criteria-in-appropriateness
No ARKA surface, artefact, metric, export, contract clause or piece of marketing may reference evaluation-and-management coding, billing level, code selection or reimbursement in connection with the considered-and-deferred note — and the build fails if one does. The one-page write-back brief at /api/compliance/writeback-brief (also on /compliance/regulatory-standing#writeback-brief) states what the note is, who authors it, what ARKA never sees, counts or is paid for, the five rules with the check that enforces each, the Clause 10 mirror of each rule, and the enablement record. Every claim in that brief is traced under CHECK-WBB-1.
CHECK-WBB-1 · linter · never-do no-billing-language-in-clinical-writeback
Data flow
Generated from the live flow graph, not drawn. Identifiable data crosses only the CDS Hooks session and the Module 3 chart write; federated outcomes and calibration aggregate without moving identifiable data.
Scopes
Volume VIII §9.2 ranks third among all your differentiators: "For the first product there are no FHIR scopes, because there is no integration."
Modules 1 and 2 need none of these scopes. The land motion is a claims extract. The rows below are the CDS Hooks / IRE read scopes, generated from the live prefetch configuration. A withheld class degrades or abstains — it never fails silently.
| Resource | SMART scope | Why the engine needs it | If withheld | M1 / M2 |
|---|---|---|---|---|
| AllergyIntolerance | patient/AllergyIntolerance.rs | Contrast and other allergies support premedication or modality-change context in the chart. | Degrade. Degrade — contrast and other allergy context is omitted and the miss is recorded. | Not required |
| Condition | patient/Condition.rs | Active conditions define the differential the order is working — core structured indication material. | Degrade. Degrade — completeness is recorded as degraded and the missing class is written to the degradation array; scoring continues on remaining structured context. | Not required |
| Device | patient/Device.rs | Implanted devices and MRI conditionality matter to indication completeness and modality choice context. | Degrade. Degrade — implanted-device and MRI-conditionality context is omitted and the miss is recorded. | Not required |
| DiagnosticReport | patient/DiagnosticReport.rs | Pathology reports (known malignancy) change staging-protocol framing for the indication. Prior radiology reports change protocol context (e.g. delayed-phase follow-up) for the reconstructed indication. | Degrade. Degrade — prior radiology and pathology reports are omitted from Phase B; the miss is recorded. | Not required |
| DocumentReference | patient/DocumentReference.rs | Clinical notes are the richest narrative source for Phase B (mechanism, red flags, functional impact). | Degrade. Degrade — Phase B narrative notes are skipped; reconstruction stays structured_only and the miss is recorded. | Not required |
| Encounter | patient/Encounter.rs | ED vs inpatient vs ambulatory changes the decision frame for the reconstructed indication. | Degrade. Degrade — setting (ED / inpatient / ambulatory) is omitted from the reconstructed indication and the miss is recorded. | Not required |
| ImagingStudy | patient/ImagingStudy.rs | Recent imaging-study metadata (identifiers and timestamps, not pixels) lets the engine see prior exams in the episode without a PACS pull. | Degrade. Degrade — prior-study metadata is an empty bundle; scoring continues without that context and the miss is logged, not silent. | Not required |
| MedicationRequest | patient/MedicationRequest.rs | Active meds (anticoagulation, metformin, nephrotoxics) enrich mechanism and prior-treatment context. | Degrade. Degrade — active-medication context (anticoagulation, metformin, nephrotoxics) is omitted and the miss is recorded. | Not required |
| Observation | patient/Observation.rs | Recent labs (WBC, lactate, CRP, troponin, D-dimer, LFTs, lipase, INR, hCG, eGFR) change study territory and urgency framing. Vitals (HR, BP, SpO₂, temp, RR, FiO₂) ground acuity and exam-finding elements for Phase A. | Degrade. Degrade — labs and vitals are omitted from the indication; the miss is recorded. The engine does not invent values. | Not required |
| Patient | patient/Patient.rs | Age and administrative sex gate reconstruction and every card; the Patient resource is the session context token, not a chart dump. | Abstain. Abstain — reconstruction does not start and the EHR receives no card. The order still proceeds. | Not required |
| Procedure | patient/Procedure.rs | Recent procedures and surgeries frame implant/post-op status relevant to the indication. | Degrade. Degrade — recent procedure and implant/post-op context is omitted and the miss is recorded. | Not required |
| ServiceRequest | patient/ServiceRequest.rs | Prior completed imaging orders are the duplicate and redundancy window; the in-flight draft order arrives from hook context, not this prefetch key. | Degrade. Degrade — prior completed ServiceRequests become an empty bundle; the in-flight order still comes from CDS Hooks context. The miss is recorded. | Not required |
The write-back path is one narrow, named case: Module 3 accountable justification, posting the clinician's words to the chart as a ServiceRequest annotation under the clinician's SMART token (`user/ServiceRequest.u`, with `user/ServiceRequest.write` as the v1 fallback). That is not a prefetch scope, and it is not requested for Modules 1 and 2.
Security
Penetration test: first independent test scheduled Q4 2026; engagement letter shareable under NDA; executive summary shared with customers post-remediation.
HIPAA — Privacy, Security & Breach Notification Rules Program in force
Full privacy and security policy suite adopted and operating; business associate agreement ready for execution; annual NIST 800-30 risk analysis complete.
SOC 2 — Security, Availability, Confidentiality In progress
Readiness assessment complete against the 2017 Trust Services Criteria (2022 points of focus). Type I examination targeted December 2026; Type II report mid-2027.
HITRUST e1 — Essentials, 1-Year Validated Roadmap active
44-requirement e1 tier selected as the appropriate entry certification; MyCSF self-assessment Q1 2027, validated assessment H1 2027. ~80–90% control overlap with the SOC 2 program lets one evidence body serve both.
2025 HIPAA Security Rule NPRM Adopted as baseline
The December 2024 OCR proposal's heightened specifications are ARKA's internal baseline today: mandatory MFA, universal encryption, asset inventory and network map, six-month vulnerability scans, annual penetration testing, segmentation, 72-hour restore capability.
Access control
ARKA processes structured FHIR resources in the EHR's context at the moment of order as your Business Associate — transiently in the CDS Hooks / SMART request path, not bulk-exported or warehoused as raw charts. ARKA does NOT ingest image pixels. Only de-identified order features and scoring outcomes persist (SHA-256–hashed order and patient keys, age buckets, ICD-10/CPT codes, AIIE scores, and scrubbed factor metadata), redacted CDS decision-log fingerprints, federated aggregate query audit metadata, and standard security event logs — encrypted in transit and at rest, with append-only audit logging. Model improvement uses federated analytics on de-identified or aggregated signals — row-level patient records never leave the institution in federated queries.
Customers are notified at least 30 days before ARKA adds a PHI-touching subprocessor — aligned with BAA subcontractor flow-down and customary objection rights.
| Subprocessor | Function | Data touched | BAA | Region |
|---|---|---|---|---|
| Vercel, Inc. | Edge / application hosting (Next.js, CDS Hooks & API routes) | Structured FHIR prefetch and CDS context processed transiently in the request path — no PHI persisted at the edge | Required before production PHI | United States (primary: iad1) |
| Supabase, Inc. | PostgreSQL data tier (tenant-isolated databases, row-level security) | De-identified audit rows, hashed identifiers, AIIE scores, security event logs — encrypted at rest | Required before production PHI | United States |
| Render Services, Inc. | Optional ML inference service (when ML_SERVICE_URL is configured) | Structured order features for AIIE scoring in the CDS request path — rule-based fallback when unset or unreachable | Required before production PHI | United States |
Effort
A "free" pilot that consumes 200 hours of a customer's analyst time is not free.
Integrated modules — 40 hours
The integrated modules (CDS Hooks / SMART on FHIR) cost 40 analyst hours.
Claims-only baseline — 0 hours
The claims-only baseline motion costs 0 analyst hours.
Rollout path
Each phase lists what ARKA delivers and what your team provides — typical imaging pilots complete in six to eight weeks after agreements are signed.
Week 0
ARKA does
Execute MSA and BAA, share the 21-document security package from our Trust Center, provision sandbox credentials, and seed your security questionnaire responses from the published controls on /security.
You provide
Procurement and security reviewers to execute agreements, complete the vendor questionnaire, and approve sandbox access for the integration team.
Weeks 1–2
ARKA does
Provide CDS Hooks discovery URL, SMART on FHIR launch parameters, and registration checklists. ARKA consumes structured FHIR order-select context from the EHR prefetch bundle — no image pixels, no bulk PHI export.
You provide
Your EHR/integration team registers ARKA as a CDS Hooks service and SMART on FHIR app in non-production — designed for Epic, Oracle Health (Cerner), and athenahealth after customer-specific validation. Typical lift: one analyst, light ARKA support.
Weeks 2–4
ARKA does
Map service lines and payer mix, narrow pilot scope to one department and one payer, tune auto-clear thresholds toward 35–40%, and align card copy with our CDS Card Language Style Guide (supportive, non-coercive, evidence-first).
You provide
Clinical and revenue-cycle sponsors to confirm pilot boundaries, approve threshold targets, and sign off on in-flow card wording before shadow mode.
Weeks 4–6
ARKA does
Run shadow mode alongside live traffic, publish validation metrics and drill-down rows, and complete conformance checks against CDS Hooks and Da Vinci CRD expectations.
You provide
Clinical champion reviews shadow cards against local practice patterns, logs sign-off, and confirms the pilot KPI baseline before production enablement.
Weeks 6–8
ARKA does
Enable ARKA in production for the agreed pilot scope, monitor API latency and card delivery, and report ROI and utilization metrics through the observability dashboards.
You provide
Change-control approval for production CDS registration, a named on-call contact for the first two weeks, weekly readouts with your champion and rev-cycle lead, and confirmation that the rollback runbook is delivered and walked through before production enablement.
Risk controls
Rollback, downtime behavior, service levels, and alert-fatigue guardrails — documented before go-live for health-IT and clinical reviewers.
Rollback protocol — ≤2 business hours, zero EHR rebuild
If you dislike it, you turn off one hook. There is no data migration, no schema change, and no residue. ARKA attaches as a CDS Hooks service registration and a SMART on FHIR app record. Full deactivation is deregistering those entries in EHR configuration — one analyst, no interface-engine rebuild, no order-set rollback. Scope it to one department or one hook, or turn the whole thing off. After you turn the hook off, the justification text stays in the chart because it is a clinical record entry, and that is correct. ARKA keeps only the receipt — hash, length, timestamp — and that receipt is unused once the hook is gone. We commit to a documented rollback runbook delivered before go-live and a ≤2-business-hour assisted rollback SLA.
Failure behavior — fail-open by design
If ARKA is unreachable at order time, the order proceeds. The EHR does exactly what it did before ARKA existed: no card renders, no order is delayed or blocked. ARKA cannot place, cancel, modify, or hold orders. A rules-only fallback also covers ML-service outages so guideline-anchored cards continue without the optional model.
Go-live service levels
Availability targets, incident response tiers, and scoring latency commitments are shared during contracting and documented in the MSA SLA exhibit. During the first two production weeks: daily check-ins and a named on-call engineer.
Named implementation engineer
Every deployment is assigned a named ARKA implementation engineer — one accountable human from Phase 1 through 90 days post-go-live, present in weekly readouts (also the escalation point in the SLA).
Alert-fatigue guardrails
ARKA is silent unless a guideline fires (zero-click baseline measured on the pilot scorecard); card volume thresholds are reviewed weekly during the pilot; any card class exceeding agreed volume or override thresholds is tuned or retired via the shadow-mode review loop with your clinical champion (Phase 3). Override/feedback rates are a first-class KPI on /outcomes, not an afterthought.
Change management & training
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.
Integration boundary
Structured FHIR only — ARKA reads the CDS Hooks prefetch bundle (Patient, ServiceRequest, Condition, Coverage, and related R4 resources your EHR already exposes at order-select).
No image pixels — DICOM, PACS, and pixel-level analysis are out of scope; ARKA is a Non-Device CDS layer on structured order context.
PHI processed transiently as your BA — structured FHIR in the CDS Hooks / SMART request path only; identifiers are hashed before persistence, and there is no bulk PHI export from the EHR. See our data-flow & PHI statement.
Your team
A typical single-department imaging pilot needs three named owners plus an optional rev-cycle partner — not a dedicated project squad.
EHR integration analyst
~20–40 hours (weeks 1–4)
Registers CDS Hooks services and the SMART app in non-prod and production, validates prefetch scopes, and attends one ARKA working session per week during connect and configure.
Security / privacy reviewer
~8–12 hours (week 0)
Reviews the BAA, security questionnaire, and data-flow statement; approves sandbox and production network paths with your CISO or delegate.
Clinical champion (CMIO or service-line lead)
~4–8 hours (weeks 2–6)
Defines pilot scope, approves card copy and auto-clear thresholds, reviews shadow-mode output, and signs the clinical go-live log.
Revenue-cycle / denials lead (optional but recommended)
~2–4 hours (weeks 4–8)
Supplies baseline denial and clean-claim metrics, validates KPI definitions, and co-owns the weekly pilot readout with finance.
Next steps
Download the Implementation Dossier, review the pilot scope, and walk security through the published compliance package.