Are these APIs suitable for handling protected health information?

They return real clinical data, so treat every read as protected health information. Access is limited to the scopes the authorising practice grants, and you remain responsible for handling the returned data in line with your own compliance obligations.

How should an agent pace requests against these clinical systems?

Neither spec declares explicit rate limits, so pace reads conservatively, honour any 429 responses with exponential backoff, and avoid unbounded patient searches during clinical hours by narrowing with parameters such as _lastUpdated or _count.

Eyefinity APIs for AI Agents

Q: Can an agent write data or handle scheduling and billing through these APIs?

No. Both interfaces are read-only. They do not support clinical writes, appointment scheduling, or billing. They are intended for reading patient records from Eyefinity optometry EHR systems, not for modifying them.

HealthcareEhr EmrJentic-Generated SpecsOAuth 2.0Agent Ready

www.eyefinity.com·Developer portal → fhirapi.eyefinity.com

Eyefinity API Catalog

2 APIs across 1 product group. All share one credential.

Healthcare2

Eyefinity Optometry EHR FHIR APIRead patient demographics, conditions, procedures, observations, medications, allergies, immunisations and care plans from Eyefinity Optometry EHR over FHIR R4 with OAuth 2.0.~27 endpoints Eyefinity EHR FHIR APIRead patient demographics and clinical conditions from Encompass EHR through a FHIR R4 interface, with OAuth 2.0 authorisation against the Eyefinity authority server.~4 endpoints

Which Eyefinity API should I use?

I want to...	Use	Why
Full patient chart with medications, allergies, procedures, observations, immunisations and care plans	Eyefinity Optometry EHR FHIR API	The Optometry EHR FHIR API spans 27 endpoints across the full clinical resource set, so it covers medication reconciliation and complete chart reads.
Patient demographics and clinical conditions from Encompass EHR	Eyefinity EHR FHIR API	This slimmer 4-endpoint interface exposes only Patient and Condition reads against Encompass, which is enough when the workflow needs demographics and diagnoses only.
Confirm which FHIR resources a deployment exposes before reading	Eyefinity EHR FHIR API	It exposes the FHIR /metadata capability statement so an agent can verify supported interactions before issuing reads.

Install Jentic One Beta

Connect the Eyefinity APIs to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Eyefinity APIs, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.

Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.

Why Jentic?

What agents get from Jentic-routed access to this vendor.

Setup

Wiring the Eyefinity FHIR APIs by hand means running the OAuth 2.0 flow against fhirauthority.eyefinity.com, pointing at the fhirapi.eyefinity.com R4 base, and mapping FHIR search parameters across each clinical resource yourself. With Jentic you install Jentic One once, add either Eyefinity API from the Jentic directory, store the OAuth credential once, and your agent calls both.

Permission scoping

Both APIs put the resource id in the URL path, such as /Patient/{id}, and both surfaces are read-only. Because your Jentic One instance is self-hosted, your own rules decide which operations and credentials the agent may use, so you can pin it to just the Patient, Condition, or medication reads it needs and keep everything else off limits.

Credential isolation

FAQs

Specific to using Eyefinity APIs through Jentic.

Does Eyefinity publish official OpenAPI specifications for these APIs?

No. Eyefinity does not publish OpenAPI specifications for its FHIR interfaces. Jentic generates and maintains the specs for both the Optometry EHR and Encompass EHR APIs, validates them against the live services, and keeps them agent-ready.

What is the difference between the two Eyefinity FHIR APIs?

The Eyefinity Optometry EHR FHIR API spans 27 endpoints across a wide resource set including procedures, observations, medications, allergies, immunisations, and care plans. The Eyefinity EHR FHIR API is a slimmer 4-endpoint interface to the Encompass EHR that exposes only Patient and Condition reads plus the capability statement. Choose the wider one for complete charts and the slimmer one when demographics and diagnoses are enough.

Do both APIs share the same authentication?

Yes. Both use the OAuth 2.0 authorization-code flow against the same Eyefinity authority server at fhirauthority.eyefinity.com. The scopes each practice grants determine what a given token can read, so access can differ between deployments even with a shared auth model.

Can an agent write data or handle scheduling and billing through these APIs?

BOOK A DEMO

Start Connecting APIs to Your AI Agents

Browse thousands of APIs and connect them all to your agent with Jentic One. One layer, one credential — every API your agent needs.

Book a Demo

For Agents

APIs2 in catalogue

Endpoints31 indexed

AuthOAuth 2.0 — 1 credential for all 2 APIs

ProvenanceJentic-generated specs

An agent can read patient charts from Eyefinity optometry EHR systems over FHIR R4: look up patients by demographics, pull their conditions, procedures, observations, medications, allergies, immunisations, and care plans, and assemble a unified clinical summary. Reads are scoped to the practice that authorised the OAuth 2.0 token.

Eyefinity is an optometry-focused EHR provider whose FHIR R4 endpoints expose clinical reads for practices running its Optometry EHR and Encompass platforms. Both APIs are read-only clinical interfaces authorised against the same Eyefinity authority server, differing only in how much of the patient record each one surfaces.

Use for: Reading patient demographics, conditions, and wider clinical resources from Eyefinity optometry EHR systems over FHIR R4 with OAuth 2.0

Not supported: clinical writes, billing, appointment scheduling, bulk data export, insurance claims

Credentials: Both APIs use the same OAuth 2.0 authorization-code flow against the Eyefinity authority server at fhirauthority.eyefinity.com, so a single credential model covers both, though the scopes granted by each authorising practice determine what each token can read.

Step 1: Jentic One Host machine

# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Feyefinity.com" | sh

Step 2: Agent machine

# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Feyefinity.com" | sh
jentic register       # connects your agent to your Jentic One instance

Jentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.

What AI Agents Can Do with Eyefinity

Each workflow spans multiple Eyefinity APIs. Jentic routes each operation to the right API automatically.

Verify capability then read the full chart

Start against the Encompass interface to read the FHIR capability statement and confirm supported resources, then fall through to the wider Optometry EHR interface to assemble a complete patient chart including conditions, medications, allergies, and care plans. Both reads are gated by OAuth 2.0 tokens scoped by the authorising practice.

Example prompt:

Call GET /metadata on the Encompass interface to confirm exposed resources, then read Patient, Condition, MedicationRequest, and AllergyIntolerance from the Optometry EHR interface and merge them into one chart summary.

APIs used

Eyefinity EHR FHIR API + Eyefinity Optometry EHR FHIR API

Match a patient across both Eyefinity EHR interfaces

Look up a patient by name and birth date on either interface, then use the resolved FHIR id to pull demographics and conditions from one API and the richer medication and care-plan resources from the other. Useful when a practice runs both Encompass and Optometry EHR deployments.