Skip to main content
The Epic integration connects Aperium to an Epic FHIR R4 endpoint. It is Aperium’s first compliance-bearing connector: every tool call that touches protected health information (PHI) writes a hashed-patient-id audit record before returning. Agents can search and read a patient’s chart and — with approval — write a small set of clinical resources. An admin configures the connection once and it is shared tenant-wide.
This connector handles PHI. It is built around HIPAA and SMART-on-FHIR expectations, and PHI access fails closed when audit is not wired up (see below). Configure it only with the appropriate compliance review for your organization.

​
How it connects

Epic authenticates through SMART Backend Services — a JWT-bearer client_credentials flow (RS256 / RS384 signing). There is no interactive login and no refresh token: Aperium re-runs the JWT-bearer exchange to renew access. An admin supplies the SMART Backend Services connection profile: client ID, key id (kid), FHIR base URL, token endpoint, audience, the signing private key (PEM), signing algorithm, and JWT lifetime. Credentials are stored encrypted against the tenant and TLS verification is always on.

​
PHI audit

Every PHI-touching tool call emits an audit record before any FHIR request is made — one record per chart query, one per matched patient on a panel search, one per keyed detail read. The record carries a 16-character SHA-256 prefix of the patient id (patient_id_hash), never the raw FHIR id, plus the operation, tenant, user, and correlation id.
Audit fails closed: if no audit emitter is wired up, a PHI tool call raises an error rather than proceeding. The non-PHI capability statement read (get_metadata) is the only tool that emits no audit record.

​
What agents can read

Sixteen read tools:
  • Patient panel — search patients across the tenant panel.
  • Per-patient chart searches — observations, encounters, conditions, medication requests, medication statements, medication administrations, and diagnostic reports, each anchored on a patient FHIR id.
  • Keyed detail reads — get patient, get encounter, get condition, get diagnostic report.
  • Non-PHI reads — the FHIR capability statement (get_metadata) and a patient summary (the IPS $summary operation).

​
What agents can write

Four write tools, all approval-gated — the agent must surface the change for a human to approve before it executes:
  • Create an observation.
  • Create an appointment.
  • Update an appointment’s status.
  • Create a communication.
Bulk export ($export) and the remaining FHIR resource types (allergies, immunizations, procedures, documents, care plans, goals, coverage, EOB) are not part of this connector today.