Apache-2.0 · Published pricing · BAA available
The Open-Source FHIR Server for AI-Native Health Apps
Epic, Oracle Health and HL7v2 in. FHIR, SQL and MCP out. One governed clinical data layer for your applications and your AI agents. Self-host it under Apache-2.0, or let us run it for you with a signed BAA.
Free hosted tenant, no credit card. Or self-host in 5 minutes.
Example agent session. A clinician asks how a patient's blood pressure has trended over the last 30 days. The agent calls the fhir_r4_search MCP tool, and the server verifies its token, checks its SMART scope, evaluates its access policy, runs the search and records an AuditEvent. The agent answers with four readings, trending down from 134 over 88 to 122 over 80.
Built on the open standards your stack already speaks
- HL7 FHIR R4
- SMART on FHIR
- OAuth 2.0
- OpenID Connect
- Model Context Protocol
- SQL on FHIR
- HL7v2
- FHIRPath
How it fits
One clinical data layer between your systems of record and everything you build
Point EHRs, HL7v2 interfaces and other FHIR servers at Haste Health. What comes out is a single, normalized FHIR R4 API for your applications, your analysts and your AI agents.
AI-native
Agents are first-class clients, held to first-class rules
Every project serves a Model Context Protocol endpoint beside its REST API. Agents get typed tools and real FHIR schemas instead of a scraped UI, and each call they make is authenticated, authorized and audited like any other request.
Tools generated from your server
14 MCP tools cover search, read, write, history, batch and transaction. Their schemas come from your live CapabilityStatement, so agents only see what your deployment supports.
An identity for every agent
Each agent is its own OAuth client with SMART scopes and access policies. Give one read-only access to three resource types, not the keys to the dataset.
The same guardrails as people
Tool calls pass through the same scope checks, policy engine and audit trail as a REST request. There is no side door for AI.
Errors an agent can fix
Errors carry the FHIR OperationOutcome behind them wherever there is one, so an agent can see what was wrong, correct its request and try again.
How has David Williams' blood pressure trended over the last 30 days?
{
"method": "tools/call",
"params": {
"name": "fhir_r4_search",
"arguments": {
"resourceType": "Observation",
"search_parameters": {
"code": "85354-9",
"date": "ge2026-09-04",
"patient": "kin5pxcy85546rjhqjwzk9l9bn"
}
}
}
}Four readings since September 4, trending down from 134/88 to 122/80 mmHg.
{
"resourceType": "Bundle",
"type": "searchset",
"total": 4,
"entry": [{
"resource": {
"resourceType": "Observation",
"id": "f3n8wq2ktz6m1yc9d4hv7xbj5a",
"status": "final",
"code": { "coding": [
{ "system": "http://loinc.org", "code": "85354-9" }
] },
"subject": { "reference": "Patient/kin5pxcy85546rjhqjwzk9l9bn" },
"effectiveDateTime": "2026-10-02T09:12:00Z",
"component": [{
"code": { "coding": [
{ "system": "http://loinc.org", "code": "8480-6" }
] },
"valueQuantity": { "value": 122, "unit": "mmHg" }
}
// + diastolic (LOINC 8462-4), 80 mmHg
]
}
}
// + 3 more entries, same shape
]
}Works with Claude, Gemini and any other client that speaks MCP, and with the same OAuth 2.0 flows your applications already use.
Platform
Everything a production FHIR backend needs, already built
The plumbing most healthcare teams end up writing themselves ships in the box.
Proof
Fast under load, and tested against the specification
A Rust core keeps latency low and throughput high without oversized infrastructure, and every claim about FHIR support is backed by a test you can read.
- Create and update latency
- <10ms
- Writes per second
- >25k/s
- Typical search response
- <50ms
- Memory footprint per instance
- <100MB
Benchmarked on a single machine with Postgres 18 and a Synthea-generated dataset, 10 threads.
Conformance
154 / 155FHIR resource types pass every check
- Passes every check (154)
- Known issue, published: Bundle
- automated checks
- 11,667
- search parameters
- 1,606
- search backends
- 2
Each square is one resource type with its own TestScript, run in CI against both PostgreSQL and Elasticsearch. Known gaps are published, not hidden.
Security and governance
The controls a security review asks for, on by default
Clinical data needs more than an API key. Haste Health ships its own identity provider, policy engine and audit trail, and applies them to people, services and autonomous agents alike.
Single sign-on
Federate login to Okta, Azure, Auth0, Keycloak or Google over OpenID Connect.
Hardened sign-in
TOTP-based MFA, argon2 password hashing and CSRF-protected authentication flows.
Scoped tokens
OAuth 2.0 with PKCE, client credentials and refresh tokens. SMART scopes are checked on every request.
Attribute-based policies
FHIRPath rules evaluated per request, for users, client applications and custom operations.
Audit trail in FHIR
Requests can be recorded as AuditEvent resources that name the caller, the action and the outcome.
Immutable history
Every write creates a new version. Resource history is immutable at the storage layer.
Open source
Yours to run, with or without us
Everything we build lands in the Apache-2.0 repository, with no feature gates and no license key. The hosted service runs the same server, on the same storage schema, that you can run yourself.
Build on an open foundation for clinical data and AI
Start on a free hosted tenant in under a minute, self-host in five, or book a demo and talk it through with the founder.