Loading…
Loading…
Compliance
A single, linkable artifact for privacy and security reviewers — what crosses each integration hop, what we never touch, and exactly what we persist.
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. See our Regulatory Rationale memo and federated privacy governance in the compliance package. Safeguards are documented under ARKA-SEC-004 (encryption), ARKA-SEC-005 (audit logging), ARKA-SEC-011 (classification & retention), and ARKA-PRIV-002 (de-identification).
Dossier
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.
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.
Architecture
Clinical CDS Hooks path, Module 3 justification write path (receipt only to ARKA), and payer Da Vinci mirror — each hop labels what crosses the boundary and what does not.
1. Clinician orders imaging in the EHR
Crosses: User action only — no data leaves the EHR yet.
Does NOT: No ARKA involvement at this step.
2. CDS Hooks / SMART on FHIR request
Crosses: Structured FHIR prefetch: age bucket, sex, ICD-10 indication, CPT/modality, coverage context, hook tokens.
Does NOT: NOT image pixels, NOT DICOM, NOT bulk chart export, NOT persisted raw MRNs.
3. ARKA appropriateness engine (AIIE)
Crosses: In-memory scoring on structured codes and context; de-identified audit row written (hashed keys, scores, scrubbed factors).
Does NOT: NOT pixel ingestion, NOT bulk chart export, NOT persisted raw MRNs or free-text notes.
4. CDS card returned to EHR
Crosses: Appropriateness recommendation card with FDA Non-Device CDS disclosure — rendered inline in the ordering workflow.
Does NOT: NOT a separate portal login, NOT an image viewer.
1. Clinician
Crosses: Decides to compose a justification in the order workflow.
Does NOT: No ARKA storage of free text at this step.
2. EHR modal (L1 compose surface)
Crosses: Justification text is composed in the EHR UI with the clinician's own credentials.
Does NOT: Text is not persisted by ARKA — only a receipt may leave this step.
3. EHR FHIR server (chart write)
Crosses: Annotation / note written to the chart under the clinician's token — the text lives in your record.
Does NOT: ARKA is not the system of record for the justification text.
4. ARKA receipt only
Crosses: From the modal to ARKA: { hash, length, timestamp } only — so the mechanism can be shown to have been present.
Does NOT: NOT the justification text, NOT a text column, NOT anything to hand over, mine, or lose.
1. Da Vinci DTR / PAS request
Crosses: Structured prior-auth payload: CPT, ICD-10, coverage member/plan identifiers required for the UM workflow.
Does NOT: NOT bulk claims history, NOT unrelated clinical records.
2. ARKA appropriateness & medical-necessity check
Crosses: AIIE scoring, denial-risk factors, documentation gap flags against payer rules — de-identified outcomes logged.
Does NOT: NOT image review, NOT automated final coding assignment.
3. Auto-clear or reviewer queue
Crosses: PAS response (approved / pended / denied with specific AIIE-tied reasons) or routed to human reviewer with structured summary.
Does NOT: NOT boilerplate denials — reasons tie to documented AIIE factors.
Modules 1 & 2
There are no FHIR scopes, because there is no integration. A separate attack surface from CDS Hooks — batch claims in, aggregates out, no EHR write-back.
There are no FHIR scopes, because there is no integration.
Item 27
The coverage runtime may read the structured indication the clinical engine produced. The clinical engine may not read anything the coverage runtime knows. Payer criteria decide whether something is paid; they do not decide whether it is appropriate.
Inbound
At order entry, ARKA receives only what your EHR exposes through standard CDS Hooks prefetch or SMART on FHIR — processed in the request path and not bulk-exported.
Structured FHIR prefetch bundle
Patient demographics reduced to age bucket and administrative sex; ServiceRequest with CPT/modality; Condition with ICD-10 indication codes; Coverage when exposed — no DICOM, no imaging studies, no free-text clinical notes.
CDS Hooks context tokens
Hook instance UUID, hook type (order-select / order-sign), user and patient FHIR references for in-session correlation — processed transiently in the BA request path; identifiers are hashed before any persistence.
Da Vinci DTR / PAS payloads (payer path)
Structured prior-auth request: CPT, ICD-10, coverage identifiers, and documentation responses required by the payer workflow — no bulk claims history export.
Out of scope
ARKA is a Non-Device CDS layer on structured order context — not an imaging platform or data warehouse.
Image pixels or DICOM
No PACS integration, no pixel-level analysis, no radiology object storage — appropriateness reasoning runs on codes and structured clinical context only.
Bulk PHI export
No nightly MRN dumps, no chart extracts, no replication of the EHR record store — data moves only in the CDS Hooks / SMART response cycle at the moment of order.
Persisted raw identifiers
Names, MRNs, birth dates, addresses, telecom, practitioner names, and raw FHIR resource bodies are stripped before write — only irreversible SHA-256 hashes and coarse age buckets survive in storage.
Persistence
Production persistence is de-identified by design. Retention tiers follow ARKA-SEC-011; de-identification methods follow ARKA-PRIV-002.
De-identified AIIE scoring audit (`ins_aiie_audit`)
Hashed order/patient keys, ICD-10 array, CPT, AIIE scores (clinical score, denial risk, MNAI tier), and scrubbed factor payload — no raw FHIR ids.
Redacted CDS decision-log fingerprints
Hook type, age bucket, sex, indication ICD-10, modality CPT, urgency, rule findings, ML flags/scores, card count, FDA disclosure version, latency — never patient name, MRN, birthDate, or free-text notes. Default retention: 18 months.
Imaging metadata lake (`arka_lake.imaging_orders`)
Institution-scoped de-identified order metadata: hashed keys, age bucket, sex, codes, modality, scrubbed report conclusions — row-level rows never leave the institution in federated queries.
Federated query audit (`arka_lake.federated_query_log`)
Aggregate query metadata only — query kind, CPT, epsilon budget, institution count, noisy result value — no PHI in log rows.
Module 3 justification receipts (`aj_justification_receipts`)
Hash, character length, timestamp, write status, lane, and hashed clinician/order keys only — no text, justification, narrative, comment, or body column. The clinician's words live in the EHR chart under their credentials.
Security and access audit trails
Append-only record-level access, admin actions, and deployment events — retained six years per 45 C.F.R. § 164.316.
Infrastructure
Production runs on U.S. cloud infrastructure. BAAs with each PHI-touching subprocessor are required before production PHI flows (ARKA-SEC-009).
Vercel (edge / application hosting)
Stateless request handling for CDS Hooks and API routes — no PHI persisted at the edge; BAA required before production PHI.
Supabase (PostgreSQL data tier)
Tenant-isolated databases with row-level security for de-identified audit and lake tables — BAA required before production PHI.
Render (optional ML inference)
Structured order features for AIIE scoring when ML_SERVICE_URL is configured — rule-based fallback when unset; BAA required before production PHI.
Hosting and subprocessors are documented in ARKA-SEC-009, the subprocessor list, and the security FAQ.
Safeguards
Every safeguard below maps to an adopted policy in the compliance package — not a marketing claim.
Encryption in transit and at rest
AES-256 at rest across databases, object storage, and backups; TLS 1.2+ in transit (1.3 preferred); keys in managed KMS — no persistent plaintext ePHI in storage.
Immutable audit logging
Append-only audit trail for record-level access, admin actions, and deployments; alerting on anomalous access and exports; weekly security review.
Least-privilege access
MFA on all production systems, role-based access from a documented matrix, quarterly reviews, and logged ticketed support access to customer tenants only.
De-identification before analytics
Model training, evaluation, and analytics use synthetic or de-identified data exclusively, with disclosure-risk review on outputs. Customer PHI de-identification occurs only where the BAA expressly permits it.
Full control pillars and hard numbers on Security & Compliance → Controls.
Download
Download the PDF handout or request the complete 21-document compliance package for legal and security diligence.
ARKA is Non-Device Clinical Decision Support under FD&C Act §520(o)(1)(E). The ordering clinician retains full responsibility for the final decision. Regulatory rationale.
Compliance
A single, linkable artifact for privacy and security reviewers — what crosses each integration hop, what we never touch, and exactly what we persist.
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. See our Regulatory Rationale memo and federated privacy governance in the compliance package. Safeguards are documented under ARKA-SEC-004 (encryption), ARKA-SEC-005 (audit logging), ARKA-SEC-011 (classification & retention), and ARKA-PRIV-002 (de-identification).
Dossier
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.
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.
Architecture
Clinical CDS Hooks path, Module 3 justification write path (receipt only to ARKA), and payer Da Vinci mirror — each hop labels what crosses the boundary and what does not.
1. Clinician orders imaging in the EHR
Crosses: User action only — no data leaves the EHR yet.
Does NOT: No ARKA involvement at this step.
2. CDS Hooks / SMART on FHIR request
Crosses: Structured FHIR prefetch: age bucket, sex, ICD-10 indication, CPT/modality, coverage context, hook tokens.
Does NOT: NOT image pixels, NOT DICOM, NOT bulk chart export, NOT persisted raw MRNs.
3. ARKA appropriateness engine (AIIE)
Crosses: In-memory scoring on structured codes and context; de-identified audit row written (hashed keys, scores, scrubbed factors).
Does NOT: NOT pixel ingestion, NOT bulk chart export, NOT persisted raw MRNs or free-text notes.
4. CDS card returned to EHR
Crosses: Appropriateness recommendation card with FDA Non-Device CDS disclosure — rendered inline in the ordering workflow.
Does NOT: NOT a separate portal login, NOT an image viewer.
1. Clinician
Crosses: Decides to compose a justification in the order workflow.
Does NOT: No ARKA storage of free text at this step.
2. EHR modal (L1 compose surface)
Crosses: Justification text is composed in the EHR UI with the clinician's own credentials.
Does NOT: Text is not persisted by ARKA — only a receipt may leave this step.
3. EHR FHIR server (chart write)
Crosses: Annotation / note written to the chart under the clinician's token — the text lives in your record.
Does NOT: ARKA is not the system of record for the justification text.
4. ARKA receipt only
Crosses: From the modal to ARKA: { hash, length, timestamp } only — so the mechanism can be shown to have been present.
Does NOT: NOT the justification text, NOT a text column, NOT anything to hand over, mine, or lose.
1. Da Vinci DTR / PAS request
Crosses: Structured prior-auth payload: CPT, ICD-10, coverage member/plan identifiers required for the UM workflow.
Does NOT: NOT bulk claims history, NOT unrelated clinical records.
2. ARKA appropriateness & medical-necessity check
Crosses: AIIE scoring, denial-risk factors, documentation gap flags against payer rules — de-identified outcomes logged.
Does NOT: NOT image review, NOT automated final coding assignment.
3. Auto-clear or reviewer queue
Crosses: PAS response (approved / pended / denied with specific AIIE-tied reasons) or routed to human reviewer with structured summary.
Does NOT: NOT boilerplate denials — reasons tie to documented AIIE factors.
Modules 1 & 2
There are no FHIR scopes, because there is no integration. A separate attack surface from CDS Hooks — batch claims in, aggregates out, no EHR write-back.
There are no FHIR scopes, because there is no integration.
Item 27
The coverage runtime may read the structured indication the clinical engine produced. The clinical engine may not read anything the coverage runtime knows. Payer criteria decide whether something is paid; they do not decide whether it is appropriate.
Inbound
At order entry, ARKA receives only what your EHR exposes through standard CDS Hooks prefetch or SMART on FHIR — processed in the request path and not bulk-exported.
Structured FHIR prefetch bundle
Patient demographics reduced to age bucket and administrative sex; ServiceRequest with CPT/modality; Condition with ICD-10 indication codes; Coverage when exposed — no DICOM, no imaging studies, no free-text clinical notes.
CDS Hooks context tokens
Hook instance UUID, hook type (order-select / order-sign), user and patient FHIR references for in-session correlation — processed transiently in the BA request path; identifiers are hashed before any persistence.
Da Vinci DTR / PAS payloads (payer path)
Structured prior-auth request: CPT, ICD-10, coverage identifiers, and documentation responses required by the payer workflow — no bulk claims history export.
Out of scope
ARKA is a Non-Device CDS layer on structured order context — not an imaging platform or data warehouse.
Image pixels or DICOM
No PACS integration, no pixel-level analysis, no radiology object storage — appropriateness reasoning runs on codes and structured clinical context only.
Bulk PHI export
No nightly MRN dumps, no chart extracts, no replication of the EHR record store — data moves only in the CDS Hooks / SMART response cycle at the moment of order.
Persisted raw identifiers
Names, MRNs, birth dates, addresses, telecom, practitioner names, and raw FHIR resource bodies are stripped before write — only irreversible SHA-256 hashes and coarse age buckets survive in storage.
Persistence
Production persistence is de-identified by design. Retention tiers follow ARKA-SEC-011; de-identification methods follow ARKA-PRIV-002.
De-identified AIIE scoring audit (`ins_aiie_audit`)
Hashed order/patient keys, ICD-10 array, CPT, AIIE scores (clinical score, denial risk, MNAI tier), and scrubbed factor payload — no raw FHIR ids.
Redacted CDS decision-log fingerprints
Hook type, age bucket, sex, indication ICD-10, modality CPT, urgency, rule findings, ML flags/scores, card count, FDA disclosure version, latency — never patient name, MRN, birthDate, or free-text notes. Default retention: 18 months.
Imaging metadata lake (`arka_lake.imaging_orders`)
Institution-scoped de-identified order metadata: hashed keys, age bucket, sex, codes, modality, scrubbed report conclusions — row-level rows never leave the institution in federated queries.
Federated query audit (`arka_lake.federated_query_log`)
Aggregate query metadata only — query kind, CPT, epsilon budget, institution count, noisy result value — no PHI in log rows.
Module 3 justification receipts (`aj_justification_receipts`)
Hash, character length, timestamp, write status, lane, and hashed clinician/order keys only — no text, justification, narrative, comment, or body column. The clinician's words live in the EHR chart under their credentials.
Security and access audit trails
Append-only record-level access, admin actions, and deployment events — retained six years per 45 C.F.R. § 164.316.
Infrastructure
Production runs on U.S. cloud infrastructure. BAAs with each PHI-touching subprocessor are required before production PHI flows (ARKA-SEC-009).
Vercel (edge / application hosting)
Stateless request handling for CDS Hooks and API routes — no PHI persisted at the edge; BAA required before production PHI.
Supabase (PostgreSQL data tier)
Tenant-isolated databases with row-level security for de-identified audit and lake tables — BAA required before production PHI.
Render (optional ML inference)
Structured order features for AIIE scoring when ML_SERVICE_URL is configured — rule-based fallback when unset; BAA required before production PHI.
Hosting and subprocessors are documented in ARKA-SEC-009, the subprocessor list, and the security FAQ.
Safeguards
Every safeguard below maps to an adopted policy in the compliance package — not a marketing claim.
Encryption in transit and at rest
AES-256 at rest across databases, object storage, and backups; TLS 1.2+ in transit (1.3 preferred); keys in managed KMS — no persistent plaintext ePHI in storage.
Immutable audit logging
Append-only audit trail for record-level access, admin actions, and deployments; alerting on anomalous access and exports; weekly security review.
Least-privilege access
MFA on all production systems, role-based access from a documented matrix, quarterly reviews, and logged ticketed support access to customer tenants only.
De-identification before analytics
Model training, evaluation, and analytics use synthetic or de-identified data exclusively, with disclosure-risk review on outputs. Customer PHI de-identification occurs only where the BAA expressly permits it.
Full control pillars and hard numbers on Security & Compliance → Controls.
Download
Download the PDF handout or request the complete 21-document compliance package for legal and security diligence.
ARKA is Non-Device Clinical Decision Support under FD&C Act §520(o)(1)(E). The ordering clinician retains full responsibility for the final decision. Regulatory rationale.