EHR and FHIR Integration

Bidirectional EHR integration through the connector runner - from FHIR resource support to handling browser-only systems.

Amigo integrates with electronic health record systems through the connector runner. Clinical data flows in both directions: from the EHR into the world model (so the voice agent has context during calls), and from the world model back to the EHR (so information captured during calls reaches the clinical record after verification).

The world model sits between the agent and the EHR as a buffer that absorbs throughput mismatches, quality differences, and availability gaps. The agent reads from and writes to the world model's clean projected state. The connector runner handles the messy reality of getting data in and out of external systems at whatever rate they can handle.

How Clinical Data Flows

The end-to-end data flow follows a consistent path regardless of the EHR system:

EHR system
  --> Connector runner polls for new/changed records
    --> Data written as events in the world model
      --> Entity projections computed from events
        --> Voice agent receives patient context during calls

And in the reverse direction:

Voice agent captures information during a call
  --> Event written to world model at voice confidence (0.5)
    --> Review loop evaluates accuracy via LLM judge
      --> Confidence upgraded if verified
        --> Three-layer confidence gates check outbound eligibility
          --> Verified data synced back to EHR

Data captured from a phone call never writes directly to the EHR. It always passes through the confidence gates described in the Connector Runner documentation.

FHIR Resource Support

For EHR systems that support FHIR (Fast Healthcare Interoperability Resources), the connector runner provides:

• Patient search - Find patients by name, date of birth, identifier, or other demographics

• Resource CRUD - Create, read, update, and delete FHIR resources

• Bundle import - Import FHIR bundles for bulk data loading

Entity Types

The world model organizes clinical data into entity types that map to common healthcare concepts. Each entity type is a computed projection of the events associated with it.

Supported entity types

Entity Type	What It Represents	Common Sources
Patient	A person receiving care	EHR demographics, voice call identification
Practitioner	A provider or care team member	EHR provider directory
Location	A physical site (clinic, hospital, office)	EHR location registry
Appointment	A scheduled visit	EHR scheduling system, voice agent booking
Encounter	A completed or in-progress visit	EHR encounter records
MedicationOrder	A prescription or medication instruction	EHR pharmacy module
LabResult	A laboratory test and its result	EHR lab system
InsurancePlan	A patient's insurance coverage	EHR benefits module, voice-captured updates

These entity types are not a fixed schema. The world model's open schema design means new entity types can be created as needed without migration. The types listed above are the most common starting points for healthcare deployments.

Data Flow into the Voice Agent

Data flows to the voice agent through three channels (ambient, queried, extracted) described in the World Model page.

Handling External System Limitations

Common EHR integration challenges and how Amigo handles them

Real-world EHR integrations face problems that no API specification can solve:

Browser-only systems. Some EHRs have no API at all. The only way to book an appointment or check eligibility is to log into a web portal and click through forms. The platform handles this through T4 browser-tier tool execution - automated browser sessions that navigate the portal, fill forms, and extract confirmation data. The agent stays on the call with the patient while this runs in the background.

Throughput mismatches. An AI agent can handle dozens of concurrent calls, each generating scheduling requests, insurance checks, and record updates. The EHR backend may only handle a fraction of that throughput. The world model absorbs the mismatch: the agent writes its intent as events at voice confidence, and the connector runner drains the outbound queue at whatever rate the external system can accept. The patient gets an immediate confirmation from the world model; the EHR gets the write when it can handle it.

Downtime and crashes. EHR systems go down for maintenance, crash under load, or silently reject writes. The connector runner's reconciliation loop catches unsynced events and retries them. The world model holds the verified state regardless of whether the EHR has received it yet. No data is lost because the agent's intent is captured in the event store before the external write is attempted.

Stale or conflicting data. An EHR might return cached data from hours ago. A FHIR query might show an appointment slot as available that was booked 30 seconds earlier by another system. The world model's confidence-based resolution handles this: when the EHR returns stale data, the most recent high-confidence event wins. When two systems disagree, the conflict is visible in the event log and resolvable.

Partial failures. A scheduling workflow might require writing to the appointment system, updating the patient record, and notifying the provider. If step two fails, the world model tracks what succeeded and what didn't. The connector runner retries the failed step without re-executing the ones that already completed.

Inconsistent data formats. Different EHR systems represent the same concept differently. One calls it "appointment_type", another calls it "visit_category", a third stores it as a free-text field. The world model normalizes this: entity resolution and projection functions map heterogeneous inputs to a consistent internal representation. Agents and analytics see uniform entities regardless of which EHR the data came from.

Custom EHR Integrations

Not all EHR systems support FHIR. The connector runner also supports custom integrations through configurable polling endpoints and data mappings. For systems with no API at all, T4 browser-tier tools can automate portal interactions. The polling loop, content-hash deduplication, entity resolution, and confidence gates work the same way regardless of the underlying connection method.

Developer Guide - For API endpoints, SDK examples, and integration details, see the FHIR in the developer guide.