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.
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
ARKA attaches via CDS Hooks service registration and a SMART on FHIR app record. Full deactivation = deregistering those entries in EHR configuration — a config change by your analyst with our engineer on the line, not a build project. No order data, order sets, or clinical content in your EHR is modified by ARKA, so there is nothing to rebuild after rollback. Rollback can be scoped (one department, one hook) or total. 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 or slow, the EHR proceeds exactly as it did before ARKA existed: no card renders, no order is delayed or blocked. ARKA cannot place, cancel, modify, or hold orders (see /trust intended use). A rules-only fallback also covers ML-service outages: guideline-anchored cards continue without the optional model refinement.
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 PDF, 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.
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
ARKA attaches via CDS Hooks service registration and a SMART on FHIR app record. Full deactivation = deregistering those entries in EHR configuration — a config change by your analyst with our engineer on the line, not a build project. No order data, order sets, or clinical content in your EHR is modified by ARKA, so there is nothing to rebuild after rollback. Rollback can be scoped (one department, one hook) or total. 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 or slow, the EHR proceeds exactly as it did before ARKA existed: no card renders, no order is delayed or blocked. ARKA cannot place, cancel, modify, or hold orders (see /trust intended use). A rules-only fallback also covers ML-service outages: guideline-anchored cards continue without the optional model refinement.
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 PDF, review the pilot scope, and walk security through the published compliance package.