Most FHIR integrations stall on the same two things: the payloads are enormous and the authorization dance is specific to each vendor. This one answers both — FHIRPath expressions travel with the request so a search can return two fields instead of a bundle, and the SMART-on-FHIR path is demonstrated end to end against the Epic sandbox rather than described. Note that `create`, `update` and `delete` are in the tool list: the scopes you grant are what decides whether an assistant can write to a chart, so scope the client narrowly before you point it at anything real.
An MCP server from WSO2 that sits between an assistant and a FHIR API server. It speaks stdio, SSE or streamable HTTP, authenticates against the FHIR server using SMART-on-FHIR, and covers the standard interactions — capability discovery, search, read, create, update and delete — for any resource type the server supports. The README demonstrates it against both a public HAPI FHIR server with no authorization and the Epic sandbox with the full OAuth 2.0 authorization code flow.
- `get_capabilities` — what a resource type supports: its search parameters and custom operations
- `search` — a standard FHIR search on a resource type, returning the matching bundle
- `read` — one resource instance by type and id, optionally narrowed with search parameters or a custom operation such as `$everything`
- `create` — persist a new resource from a JSON payload
- `update` — replace an existing instance's content with a complete payload
- `delete` — remove a specific resource instance
- `get_user` — the authenticated user's own FHIR resource, returned as a short profile with fields such as `id`, `name` and `birthDate`
- Response filtering with FHIRPath: `search` and `read` accept `response_filter_fhirpaths`, so a request can come back as `Patient.name` and `Patient.birthDate` instead of whole resources
Python 3.8+, `uv`, and a reachable FHIR API server. `FHIR_SERVER_BASE_URL` is the one variable you must set. Authorization is on by default and expects `FHIR_SERVER_CLIENT_ID`, `FHIR_SERVER_CLIENT_SECRET` and `FHIR_SERVER_SCOPES`; against a public server such as HAPI you instead set `FHIR_SERVER_DISABLE_AUTHORIZATION` to `True`, which is also what the README asks for when running locally through Docker or Docker Compose. `FHIR_SERVER_ACCESS_TOKEN` bypasses the OAuth flow with a token you already hold — the README limits that to local stdio use and warns against it once the server is reachable over a network. Transport defaults to streamable-http on `FHIR_MCP_HOST` and `FHIR_MCP_PORT`, out of the box `localhost` and `8000`, and `--transport` switches to stdio or sse. Package `fhir-mcp-server` (0.10.0) on PyPI, run with `uvx`, from source, or as a container. Apache 2.0.
One command plus a key — uvx fhir-mcp-server, then supply credentials