For Agents
Search and create FHIR-style Patient and Observation records to integrate clinical data exchange into a healthcare workflow.
Install Jentic One Beta
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Open Health Hub 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%2Fopenhealthhub.com%2Fopenhealthhub" | shStep 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%2Fopenhealthhub.com%2Fopenhealthhub" | sh
jentic register # connects your agent to your Jentic One instanceJentic 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 an agent can do with Open Health Hub API.
Search the patient register using FHIR-style query parameters such as identifier, name, or birthdate
Create a new Patient resource with demographic and identifier data for downstream clinical workflows
Retrieve a single Patient resource by ID for record review or clinical decision support
GET STARTED
Use for: Search for a patient by identifier in the Open Health Hub, Create a new patient record with demographics and an external identifier, Retrieve the full Patient resource for a specific ID, List all observations recorded for a given patient
Not supported: Does not handle appointment scheduling, e-prescribing, or billing - use for FHIR-style Patient and Observation exchange only.
Open Health Hub exposes a FHIR-shaped REST API for exchanging core clinical data between healthcare applications. It supports searching and creating Patient resources and recording or retrieving Observation resources such as vital signs and lab values. Authentication is by API key in the X-API-Key header, and the resource model follows FHIR conventions so that records can be passed into FHIR-compatible EHRs and analytics tools without remapping.
Search Observation resources to surface vital signs, lab values, and questionnaire responses for a patient
Record a new Observation resource against a patient as part of a care or remote monitoring flow
Patterns agents use Open Health Hub API for, with concrete tasks.
★ Remote Patient Monitoring Data Capture
A remote monitoring application can record blood pressure, weight, or symptom-questionnaire responses by POSTing Observation resources tied to a Patient. Because the schema is FHIR-aligned, the same payload can be relayed into a downstream EHR or analytics warehouse without remapping. New patients can be created via POST /Patient at enrolment time.
Create a new Patient with the supplied demographics, then POST an Observation resource for systolic blood pressure of 138 mmHg referencing the new patient ID.
Patient Lookup for a Care Coordination App
Care coordinators can search GET /Patient by identifier or name to find an existing record before creating a new one. Once found, GET /Patient/{id} returns the full demographic block used to populate a care plan UI. The FHIR-style response keeps the integration portable across other FHIR systems.
Search GET /Patient by identifier 'NHS:9876543210' and, if a record is returned, fetch GET /Patient/{id} to return the patient's name, date of birth, and gender.
Population Health Observation Reporting
Analysts running population-level reports can pull observations through GET /Observation filtered by code or date range to assemble a cohort view. The FHIR Observation shape carries code, valueQuantity, and effective date so downstream tools can compute trends without bespoke parsing.
Call GET /Observation with code=85354-9 (blood pressure) and a date range covering the last 30 days, then return the count and average systolic value.
AI Agent Clinical Data Exchange via Jentic
Clinical agents that read or write patient data can call Open Health Hub through Jentic so the X-API-Key never enters the prompt. Jentic returns the FHIR resource payload as a structured object and the agent can decide what subset to surface to the user, with full audit logging at the platform layer.
Use Jentic to search for 'find a patient by identifier in open health hub', execute GET /Patient with the identifier query, and return the matching Patient resource ID.
5 endpoints — open health hub exposes a fhir-shaped rest api for exchanging core clinical data between healthcare applications.
METHOD
PATH
DESCRIPTION
/Patient
Search patients
/Patient
Create a patient
/Patient/{id}
Get a patient by ID
/Observation
Search observations
/Observation
Create an observation
/Patient
Search patients
/Patient
Create a patient
/Patient/{id}
Get a patient by ID
/Observation
Search observations
/Observation
Create an observation
What agents get from Jentic-routed access to this vendor.
Setup
Wiring the Open Health Hub API by hand means managing its X-API-Key header, following its FHIR-style Patient and Observation resource shapes, and handling paging yourself for clinical reads. Through Jentic you install once, import the Open Health Hub API from the API Directory, store the key once, and your agent calls it.
Permission scoping
Open Health Hub puts the patient id in the URL path (/Patient/{id}), so a rule can pin your agent to reads for one patient record. You choose the operations it may call, so writes like creating a Patient or posting an Observation are not included unless you add them.
Credential isolation
Your Open Health Hub API key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
Intent-based discovery
Agents search Jentic by intent such as 'find a patient' or 'record a vital sign', and Jentic returns the matching Open Health Hub operation with its FHIR-aligned input schema so the agent calls the right endpoint without browsing the reference docs.
Alternatives and complements available in the Jentic catalogue.
Specific to using Open Health Hub API through Jentic.
What authentication does the Open Health Hub API use?
API key authentication via the X-API-Key request header. Through Jentic the key is stored in your Jentic One instance and injected at request time, so it is never exposed to the agent or logged in clear text.
Can I record patient vital signs with the Open Health Hub API?
Yes. POST /Observation accepts a FHIR Observation resource referencing a Patient, including code, valueQuantity, and effectiveDateTime fields. This is the standard path for vitals, weight, and questionnaire responses.
What are the rate limits for the Open Health Hub API?
The published spec does not state a hard rate limit. Treat the API as fair-use, batch large patient or observation imports, and contact Open Health Hub for production-grade quota agreements before high-volume use.
How do I search for a patient by identifier with the Open Health Hub API through Jentic?
Search Jentic for 'find a patient by identifier in open health hub', load GET /Patient, and execute it with an identifier query parameter (e.g. NHS:9876543210). Jentic adds the X-API-Key header from the vault.
Is the Open Health Hub API FHIR-compatible?
The resource shapes for Patient and Observation follow FHIR conventions, so payloads can be relayed into FHIR-compliant EHRs and analytics systems with minimal mapping. Verify the exact FHIR version against the Open Health Hub developer documentation before relying on niche elements.
What clinical resources are available through the Open Health Hub API?
The current spec exposes Patient (search, create, get) and Observation (search, create), totalling 5 endpoints. Other FHIR resources are not part of this OpenAPI surface.
Can I limit what my agent is allowed to do with the Open Health Hub API?
Yes. Because you self-host Jentic One, your own rules decide which Open Health Hub operations and credentials your agent may use. Since the patient id sits in the URL path (GET /Patient/{id}), you can pin the agent to reads for a single patient record, and you pick exactly which operations it can call. Write operations like POST /Patient or POST /Observation stay off unless you explicitly allow them.