φ(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
Data Orchestration
Orchestration Connected systems Patient link set Practitioner crosswalk Permission lattice What each system holds Run ledger Ingest & mapping QA Data Store
System
Control panel Model monitoring Components
Governance
Registry & preflight Fairness screen Ambient consent gate Source attributes Retention Audit
Documentation
System documentation Implementation & setup guide Feature documentation Model documentation System architecture EMR connections Orchestration & identity Emulators & non-PHI setup Compliance & responsibility Attribution

Orchestration

Orchestration exists to hydrate the RAG data store at the heart of PHI AI. That store is the core of what frontier models read to enable AI securely and compliantly across your data universe — and keeping it hydrated is what holds connected systems in sync, where and when they need to be.

Close How this screen works
  • How this screen works. Pick the systems, name the purpose, bound the scope to a patient. The preflight tells you — before anything moves — which steps will refuse and why. A refusal names the bound that stopped it and links to the screen that fixes it. Reads are bounded at the source, writes at the target, by this role and the purpose: the narrowest wins, and nothing is unioned. How the bounds are decided.
  • These are emulators, not anyone's live system. Each of the fifteen examples below is an AI EMR emulator that is built from that vendor's own published specifications — its authentication model, the algorithm it signs with, whether it publishes Bulk Data Export, and exactly which resource types it advertises create for — and it refuses whatever the specification refuses. Every fact is cited in the connector chapter.
  • Each emulator has a real data store holding synthetic PHI. Physical data is genuinely moved and orchestrated during the demonstration — as close a representation of real PHI usage as it can be without real PHI.
  • Synthetic data only. Nothing here reaches a real EMR, and no record belongs to a real person.
  • Your visit is its own sandbox. The demonstration runs in a browser session: it starts with clean vendor corpora, and whatever the last visit moved is cleared on the way in. Nothing you orchestrate here outlives your visit — records moved during a session are swept two hours after it goes quiet, so no one else ever meets your run. Saved exchanges are the deliberate exception: they are the thing you come back to. Anonymous usage analytics — pages, timings and AI calls, with hashed identifiers and approximate location — are recorded and purged on a retention schedule.
  • Write paths are bought, not published. A certified API is what a vendor publishes to everybody, and for most of them that is read-only: eClinicalWorks, Altera, Veradigm, Greenway and ModMed sell or gate writes, and Epic enables them per health system and per resource. These are commercial services and products sold by the vendors themselves. This demonstration uses AI-generated EMR emulators to simulate a real PHI data orchestration experience. The commercial add-ons required for comprehensive integration can be licensed and revoked there.
  • Questions? Write to phi-ai@ryangomez.nyc.
●1. Wire the exchange nothing wired yet

Drag a system into a lane — or click it, or press Enter on it — and PHI AI sits in the middle doing the work. Each card carries the posture that decides its fate, read from that vendor's profile and never typed here.

No saved exchanges yet — wire one below, name it, and Save this exchange keeps it for next time. The wiring itself resets every visit.

Sources — read from
Targets — deliver to

Saved exchanges

A saved exchange keeps the whole decision — systems, purpose, scope and how it delivers — so it comes back whole rather than being rebuilt from memory. Loading one does not run it: preflight is decided again before anything moves, which is the point of saving a configuration rather than an approval.

None saved yet. Name one above and press Save this exchange.

In this exchange — unnamed; name it above to keep it

One-off Runs when you execute it, and finishes.

Sources — read from 1
Northside Health (Epic) :9101
auth
SMART Backend Services — RS384-signed JWT client assertion; public key registered with the client ID
bulk
Group-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
bulk export
Configure this connection →
Targets — deliver to 1
Northside Health (Epic) :9101
auth
SMART Backend Services — RS384-signed JWT client assertion; public key registered with the client ID
writes
DocumentReference create only, and only where the health system has licensed and enabled that write API (write APIs are enabled per resource and per flavor by each health system); no general FHIR create for historical clinical resources; MedicationRequest is read/search only over FHIR REST (order suggestions exist only as CDS Hooks); conditional create not documented — a confirmed run needs --allow-duplicates
creatable: DocumentReference, Condition, Observation, DiagnosticReport, ServiceRequest, MedicationRequest, AllergyIntolerance, Immunization, Procedure, Encounter conditional create
Configure this connection →
Recorded as integration.selection_changed. This purpose is the one the run asserts and every gate is decided against; it is separate from the access pill, which governs what you can see while you browse.
●2. Scope — review and confirm wire the exchange first

Nothing wired yet. Drag a system into Sources and one into Targets above, and this fills in with what that exchange would actually carry — per source, per resource type, and how much of it is heightened.

●3. Preflight confirm the scope first

Every line has to be checked before the exchange can run. Checking one records that you knew — it grants nothing: every step is decided again when the run starts, so a refusal stays a refusal.

Nothing is in scope — hold a patient in context, or choose a set on the scope step above go there →

The plan below is still computed and readable — the gate is what is closed, not the explanation.

1 decisions stand between the wiring and the write — one per system and action, not one per record: 1 allowed · 0 dry-run · 0 refused. Each decision is made once, by orch_decide, the one place a bound is evaluated; the ledger after the run shows the same decisions with their audit hashes.

4. Latest run

No run yet this session. The matrix appears after the first execution.

5. Run history

StartedByPurposeSourcesTargetsPatientsStatus AllowDry-runRefuseWithheld
No runs this session.

Synthetic patients; real decision mechanics. Delivery here is simulated over the session overlay — the platform's writer and the per-vendor emulators are the proof behind it.