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).
Architecture
Clinical CDS Hooks path 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. 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.
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.
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).
Architecture
Clinical CDS Hooks path 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. 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.
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.
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.