canonical: https://jentic.com/apis/orionhealth.io/orion-health # Orion Health FHIR R4 API 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. ## For AI agents Read FHIR R4 patient, clinical, medication, and provider resources from Orion Health's HIE and EMR platforms. ## Scope Does not handle claims processing, payment posting, or eligibility checks - use for FHIR R4 clinical reads and patient demographic operations only. ## Capabilities - 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 - Surface medication orders and administrations from /MedicationRequest, /MedicationAdministration, /MedicationDispense, and /MedicationStatement - Walk encounters, care plans, and appointments via /Encounter, /CarePlan, /CareTeam, /EpisodeOfCare, and /Appointment - Look up providers and locations through /Practitioner, /PractitionerRole, /Organization, and /Location ## Use cases ### 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. Example prompt: 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. Example prompt: 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. Example prompt: 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. Example prompt: 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. Example prompt: 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 | 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 | ## Key resources - **Patient** — Search and read patient demographic resources - **Clinical** — Condition, Observation, AllergyIntolerance, Immunization, Procedure, DiagnosticReport - **Medications** — MedicationRequest, MedicationAdministration, MedicationDispense, MedicationStatement - **Encounters and Care** — Encounter, CarePlan, CareTeam, EpisodeOfCare, Appointment, ServiceRequest, Task - **Provider Directory** — Practitioner, PractitionerRole, Organization, Location, HealthcareService, InsurancePlan - **Documents** — DocumentReference for clinical documents - **Metadata** — FHIR capability statement ## Why Jentic - **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 handling:** 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. - **Discovery method:** 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. ## Related APIs - **Epic FHIR API** — Epic exposes a FHIR R4 surface from one of the largest US EHR footprints. - **athenahealth API** — athenahealth offers cloud EHR and revenue cycle APIs covering similar clinical resources. - **Stedi Healthcare API** — Stedi Healthcare handles X12 claims and eligibility transactions that complement FHIR clinical reads. ## FAQ ### 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.