Connecting Epic / Oracle Health / another FHIR R4 system

Before you start

Expect the vendor side of onboarding to be the long pole — days to weeks of waiting on your EHR IT or interface team, not engineering effort on our side. We handle our side of each integration (app registration, signing keys, conformance testing) before your practice starts; the steps below are what we need from you and your EHR vendor.

Connecting Epic

1. Your Epic team locates our app on your system's Downloads page using our Client ID (requires a staff member with "Able to Purchase Apps?" permission).
2. Your organization signs the open.epic API Subscription Agreement (a one-time, org-level agreement if you don't already have one on file for another app).
3. Your team uploads or configures our JWKS URL or public key for your instance — this is a separate credential per environment, so non-production and production are configured independently.
4. Confirm the granted scopes explicitly: Appointment.Read, Encounter.Read, DocumentReference.Create, Patient.Read/$match, Practitioner.Read. Write access to DocumentReference is not implied by read access — confirm it directly.
5. Confirm which note type(s) (by LOINC code) your organization allows filed via API, and whether you accept preliminary or final document status from third-party apps — some organizations restrict external apps to preliminary, requiring a clinician co-sign inside Hyperspace.
6. Agree on the encounter-binding approach: Epic has no Encounter.Create, so we resolve to an existing encounter via your appointment/check-in workflow. Confirm your organization's Encounter search parameters against your live or non-production system directly with us.
7. Sign off on the write-back approach: the filed note carries a "Follow-Up Actions" section for your staff to act on — we do not place orders on your behalf by default. See Sending to your EHR for the clinician-facing explanation.
8. We run our conformance test suite against your non-production environment, then cut over to production credentials and re-run it with a designated test patient before enabling real encounters.

Connecting Oracle Health (Cerner)

1. Obtain your Tenant ID (via Oracle Health Hosting for RHO/Global tenants, or Cerner Central for CHO tenants).
2. File (or have us file on your behalf) a Service Request — "Cerner Ignite APIs for Millennium" — referencing our App ID and Client ID, requesting FHIR URL provisioning for your tenant.
3. Complete the PECA compliance form for your organization if applicable.
4. Complete SMART application setup/activation inside your PowerChart/FirstNet configuration, and provision our System Account (client ID + secret, or JWKS) scoped to your tenant.
5. Confirm granted scopes explicitly (system/{Resource}.read|write, no wildcards) for every resource we need: Appointment, Encounter, Patient, Practitioner, DocumentReference, and MedicationRequest/Communication if you use those paths.
6. Confirm the Encounter creation policy — Oracle Health, unlike Epic, supports Encounter.Create. Decide whether we create the encounter at recording start or your workflow always pre-creates it, and confirm your location vs. serviceProvider convention (the two are mutually exclusive on create).
7. Provide Location IDs for your site(s) — these are not self-discoverable via the API.
8. We run the conformance suite against your non-production tenant, confirm your production root URL (including regional variant — .ca./.eu./.au. — for your data residency), then cut over to production with a test patient before enabling real encounters.

Connecting another FHIR R4 system

1. Obtain the vendor's SMART on FHIR backend-services registration details: fhirBaseUrl, token endpoint, clientId, and either a jwksUri we host or a client secret.
2. We fetch the server's /metadata capability statement and check, per resource, whether create is actually declared — we never assume DocumentReference/ServiceRequest/MedicationRequest/Appointment write support just because the resource type appears in search results.
3. We run the full conformance suite against the vendor's sandbox if one exists; if not, we run the read-only portion (schedule pull, capability check) against production first, and stage the write portion behind manual approval for your first encounters.
4. The connection is created with vendor type Generic FHIR R4 and confirmed with Test connection in Settings before activation.

What to send us

Sandbox vs. production

Every connection is validated against the vendor's sandbox or non-production environment first, using our conformance test suite. We only cut over to production credentials — and re-run the same suite with a designated test patient — after that passes. Treat sandbox success as necessary, not sufficient: vendors, especially Epic, explicitly disclaim that sandbox behavior predicts production behavior exactly.

Testing a connection

Every connection in Settings has a Test connection button, available to any signed-in user. Use it before activating a connection for real encounters, and again after any credential rotation or EHR-side maintenance window. A failure here is the first thing to check when a provider reports a write-back failure — see Troubleshooting: EHR connection test fails.