Install Jentic One Beta

Connect the Orion Health FHIR R4 API to your agent

Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Orion Health FHIR R4 API, 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.

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%2Forionhealth.io%2Forion-health" | 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%2Forionhealth.io%2Forion-health" | 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.

Capabilities

What an agent can do with Orion Health FHIR R4 API.

Search and retrieve patient demographics through GET /Patient and GET /Patient/{id}

Pull a patient's active conditions and problems via GET /Condition

Retrieve vitals and lab results from GET /Observation and GET /Observation/{id}

List allergies and immunizations using GET /AllergyIntolerance and GET /Immunization

GET STARTED

Start building with Orion Health FHIR R4 API

Explore with Jentic One

View OpenAPI Document

Use Cases

Patterns agents use Orion Health FHIR R4 API for, with concrete tasks.

★ Care Coordination Patient Summary

Care managers building a single-page patient summary can stitch together GET /Patient, /Condition, /Observation, /MedicationRequest, /AllergyIntolerance, and /Immunization into one snapshot. Because the API follows FHIR R4, the same client logic works against any conformant payer or HIE.

GET /Patient/{id} followed by parallel reads of /Condition, /Observation, /MedicationRequest, and /AllergyIntolerance filtered by patient id, then merge into a single summary.

Medication Reconciliation

Pharmacists and care teams reconciling the active med list before discharge can pull /MedicationRequest, /MedicationAdministration, /MedicationDispense, and /MedicationStatement to compare orders against what was actually given and what the patient reports taking.

Fetch /MedicationRequest, /MedicationAdministration, and /MedicationStatement for the patient and flag any drug appearing in only one of the three lists.

Lab Results Subscription Alternative

Population-health programs that need to react to new lab values can poll GET /Observation filtered by category and date for cohorts of interest, e.g., diabetic patients with elevated A1c. The R4 search semantics keep the polling efficient.

GET /Observation?code=4548-4&date=gt2026-05-01 to surface elevated A1c results since May 1 across the panel.

Provider Directory Lookup

Care navigators routing referrals can use /Practitioner, /PractitionerRole, /Organization, /Location, and /HealthcareService to find an in-network provider with the right specialty at the right facility. The same data underpins payer provider directories.

GET /PractitionerRole?specialty=cardiology&location=site-123 and return the practitioners with matching availability.

Agent-Driven Clinical Lookups via Jentic

Clinical-ops agents can answer 'what's on this patient's allergy list' or 'list active medications' through Jentic without learning FHIR R4 search semantics. Jentic exposes the 41 operations by intent and isolates the OAuth token in the vault.

Use Jentic to search 'list active medications for a patient', load the GET /MedicationRequest schema, and execute with patient id and status=active.

Key Endpoints

41 endpoints — jentic publishes the only available openapi specification for orion health fhir r4 api, keeping it validated and agent-ready.

METHOD

PATH

DESCRIPTION

GET

/Patient

Search patients

GET

/Patient/{id}

Retrieve a patient

GET

/Condition

Search conditions

GET

/Observation

Search observations and lab results

GET

/MedicationRequest

Search medication orders

GET

/AllergyIntolerance

Search allergies

GET

/Encounter

Search encounters

GET

/metadata

Retrieve FHIR capability statement

GET

/Patient

Search patients

GET

/Patient/{id}

Retrieve a patient

GET

/Condition

Search conditions

GET

/Observation

Search observations and lab results

GET

/MedicationRequest

Search medication orders

GET

/AllergyIntolerance

Search allergies

GET

/Encounter

Search encounters

GET

/metadata

Retrieve FHIR capability statement

Why Jentic?

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

Setup

Wiring the Orion Health FHIR R4 API by hand means running its OAuth 2.0 flow, refreshing tokens, and mapping each FHIR resource path yourself. Through Jentic you install once, import Orion Health from the API Directory, store the credential once, and your agent calls it.

Permission scoping

You choose which Orion Health FHIR operations the agent may call, so you can limit it to the resource reads it needs, such as searching Patient records or reading Condition, Observation, and MedicationRequest resources, while any resources you do not list stay out of the allowed set unless you add them.

Credential isolation

Your Orion Health OAuth 2.0 tokens are stored once, encrypted, by your own Jentic One instance and refreshed and injected at execution time. They never enter the agent's prompt, logs, or context.

Intent-based discovery

Agents search Jentic by intent such as 'find a patient by name and date of birth' or 'list active medications', and Jentic returns the matching FHIR operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

FAQs

Specific to using Orion Health FHIR R4 API through Jentic.

Why is there no official OpenAPI spec for Orion Health FHIR R4 API?

Orion Health publishes a developer portal but not a maintained OpenAPI document. Jentic generates and maintains this spec so that AI agents and developers can call Orion Health FHIR R4 API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

What authentication does the Orion Health FHIR R4 API use?

It uses OAuth 2.0 (declared as the OAuth2 security scheme), aligned with SMART-on-FHIR conventions. Through Jentic the access token is stored encrypted in the vault and refreshed transparently at execution.

Can I retrieve a patient's medication list with the Orion Health API?

Yes. GET /MedicationRequest returns active and historical medication orders, /MedicationAdministration returns what was given, and /MedicationStatement returns what the patient reports taking - all filterable by patient id.

What are the rate limits for the Orion Health FHIR R4 API?

The OpenAPI spec does not declare numeric rate limits. Orion Health applies per-tenant limits that depend on the deployment - confirm with the integration owner before running large cohort polls.

How do I build a patient summary through Jentic?

Search Jentic for 'retrieve a patient summary', load the schemas for /Patient, /Condition, /Observation, /MedicationRequest, and /AllergyIntolerance, and execute each filtered by patient id. Merge the results into the summary view.

Does the Orion Health API support write operations?

Yes for some resources - POST /Patient and PUT /Patient/{id} are present. Most other resources expose read-only GET operations in this spec; write capability for additional resources depends on the deployment configuration.

Can I limit what my agent is allowed to do with the Orion Health FHIR R4 API?

Yes. Because Jentic One is self-hosted, you set the rules that decide which Orion Health FHIR operations and credentials your agent may use. You can restrict it to just the reads it needs, such as searching Patient records or reading Condition, Observation, and MedicationRequest resources, and any resource you do not list stays outside the allowed set. The OAuth 2.0 token is held by your own instance and injected only when an operation you have permitted runs.

Orion Health FHIR R4 API

Name: Orion Health FHIR R4 API
Brand: Orion Health FHIR R4 API
Availability: InStock

Agent-ready OpenAPI document · curated by JenticHealthcareEhr Emroauth241 EndpointsREST

Know of an official OpenAPI document? Contribute it →

For Agents

Read FHIR R4 patient, clinical, medication, and provider resources from Orion Health's HIE and EMR platforms.

Use for: Search for a patient by family name and birth date, Retrieve all active conditions for a patient, List recent lab observations for a patient, Find allergies on file for a specific patient

Not supported: Does not handle claims processing, payment posting, or eligibility checks - use for FHIR R4 clinical reads and patient demographic operations only.

Jentic publishes the only available OpenAPI specification for Orion Health FHIR R4 API, keeping it validated and agent-ready. Orion Health is a global health-tech vendor whose FHIR R4 API exposes patient, clinical, encounter, and provider resources from its Health Information Exchange and EMR platforms. The 41 endpoints span Patient, Condition, Observation, AllergyIntolerance, Immunization, Procedure, DiagnosticReport, MedicationRequest, MedicationAdministration, MedicationDispense, Encounter, CarePlan, CareTeam, Appointment, ServiceRequest, Practitioner, Organization, and other FHIR resources, with OAuth 2.0 authorization. It is suitable for agent-driven clinical lookups, care-coordination tools, and SMART-on-FHIR style integrations.

Jentic One on Github View OpenAPI Document