φ(ai) PHI AI
Menu
Clinical workspace
Patients & charts PHI AI assistant Signature queue Ambient documentation Imaging worklist Summarization Inbox triage Patient instructions
Revenue & records
Claims & billing Prior auth & appeals Documentation gaps Release of information Sensitive categories
Population
Cohort builder No-show risk Scheduling optimization Trial pre-screening Quality measures Ingest & mapping QA Data Store
Integration
Source & target EMRs Source patient import Bulk import manager Streaming data Bulk export manager Streaming export
System
Control panel Model monitoring
Governance
Registry & preflight Fairness screen Ambient consent gate Source attributes EMR conformance Retention Audit
Documentation
System documentation Implementation & setup guide Feature documentation System architecture EMR connections Emulators & non-PHI setup Compliance & responsibility Attribution
Ryan GomezRole
Signed in — Ryan Gomez · System Administrator
You stay on this screen — each role sees it as their own permissions allow. The assistant thread and the patient in context start fresh.
Working archetypes — combinations people really hold
One role at a time — each role on its own
DocumentationDocs
System documentation Implementation & setup guide Feature documentation System architecture EMR connections Emulators & non-PHI setup Compliance & responsibility Attribution
Repository

Source & target EMRs

Where the data comes from and where writes go back. Each vendor's real integration seams are shown as you select it — the auth model, the bulk-export posture, and the write surface come from the platform's per-vendor capability profiles, not from a generic connector form.

Topology is configurable — the default is one system. By default the source EMR is the target EMR: records are ingested from your EMR and signed documentation writes back to that same chart of legal record. Splitting them below — reading from one system, delivering to another — is the migration and exchange configuration. And this pair is the demo's simplification: the platform itself supports many sources to many targets, each connection carrying its own vendor profile and its own independent SSO registration, so a health system can ingest from several EMRs and deliver to several destinations at once.

Source EMR — where records are ingested from

AuthenticationSMART Backend Services — RS384-signed JWT client assertion; public key registered with the client ID
Bulk exportGroup-level Bulk Data Export only; requires a Group FHIR ID from Epic; rate-limited to once per 24 hours per group and client; every kickoff is a full re-extract
Write surfaceNotes and observations writable; medication orders are read-only over FHIR REST (CDS Hooks suggestions only)
CredentialsThe signing keypair / client secret never enters this screen — it is referenced by file path on the server, mounted read-only, exactly as the platform does it.

Target EMR — where signed write-backs are delivered

Write posture for Epic: Notes and observations writable; medication orders are read-only over FHIR REST (CDS Hooks suggestions only). Nothing is written without a human signature (see the Signature queue), and a capability the vendor does not expose is refused, never approximated.
Saving re-renders the vendor seams and is audited.