MCP for FHIR
MCP Server for FHIR
Model Context Protocol gives LLM agents a structured way to call into external systems. For a FHIR backend the question is not whether MCP works but where the access boundary sits when the caller is an autonomous agent. Fire Arrow gives the agent a scoped service identity, a deterministic tool surface, and audit per call.
What you can build
- Agent identity is a real identity
The agent runs as a service account with documented scope. Every call is attributable in the audit log, in the same shape as a human action.
- Tool surface follows the access model
The MCP tool catalog mirrors the FHIR operations the agent's role permits. Read, search, and write tools each respect the same rule chain a REST client does.
- Validation does not move into the agent
Argument validation, search-parameter blocklists, and property filters stay on the server. The agent cannot widen access by constructing a clever tool call.
How it works
- 1 Agent authenticates
The MCP server authenticates to Fire Arrow as a service account, normally via OIDC or Microsoft Entra ID. The credential resolves to a Device or Practitioner identity scoped to the agent's role. Where OIDC is not available for the agent's runtime, an API token tied to the same identity is supported and rotated frequently.
- 2 Tool catalog resolves
MCP exposes only the tools the role permits: read, search, create, update, delete on the resources the role has rules for.
- 3 Tool call runs
Each MCP tool call becomes a Fire Arrow request. Authorization runs against the standard rule chain; the result is the data the role is allowed to see.
- 4 Audit captures the call
The audit log records the agent identity, the tool, the resource and operation, and the rule that matched. The on-behalf-of identity (where applicable) is captured alongside.
Who this is for
Engineering teams building MCP-based agentic workflows on top of clinical data, and security architects evaluating the access model when an LLM is in the request path.
Clinical applicability
An MCP-enabled assistant helps a clinician triage a patient inbox. The agent reads recent Encounter and Observation resources, drafts a Communication resource for review, and never sees data outside the clinician's care team scope.
Why MCP and FHIR fit naturally
MCP defines tools, resources, and prompts as the surfaces an agent calls into. A FHIR backend already exposes a typed, structured API surface with discoverable operations. The mapping from FHIR operations to MCP tools is mechanical: each FHIR operation an agent's role permits becomes a tool with typed arguments and typed results.
The interesting work is not in exposing the tools but in keeping the access boundary intact when an LLM constructs the calls. The boundary lives on the Fire Arrow side: the rule chain, the validators, the search-parameter blocklists. The MCP layer translates between the agent's intent and the typed call shape; it does not adjudicate access.
Agent identity and on-behalf-of
Two patterns work. The first is the agent acting as itself: a service account with its own role, narrower than any human role. This fits background tasks (summary generation, alerting, batch reasoning).
The second is the agent acting on behalf of a clinician: the clinician's identity flows into the agent's session, and the agent inherits the clinician's role for the duration. This fits foreground assistants (inbox triage, note drafting). The audit log captures both identities so the on-behalf-of relationship survives review.
What the agent should not be able to do
The agent should not be able to widen access by constructing a search with unintended parameters. Search-parameter blocklists are declared on the role, so the MCP tool surface inherits them; an agent that tries to use _filter or _include on a property-filtered role gets a 403 the same way a REST client would.
The agent should not be able to side-channel data through clever embeddings either. Property filters strip values from authorized responses before the agent sees them. The model never embeds what the role does not permit.
FAQ
Do I need a separate MCP runtime?
Yes. MCP is a protocol; the runtime that exposes the tool catalog and handles the agent's transport is a separate component. Fire Arrow is the backend the MCP runtime calls into, with a service-account identity and a defined access scope.
Can the agent run write operations?
Yes if the role has write rules for the relevant resources. Write operations follow the same rule chain as read operations and the same audit log captures them.
How is the on-behalf-of identity captured?
The agent's session can carry an additional identity claim that resolves to a FHIR Practitioner, RelatedPerson, or Patient. The audit log records both the agent identity and the on-behalf-of identity. The role used for the call is the on-behalf-of identity's role.
What stops the agent from leaking data through embeddings?
The agent only ever embeds what the role can see. Property filters and search-parameter blocklists run server-side, before the response leaves Fire Arrow. The model cannot embed what was never in the response.
How does this differ from a regular API integration?
Mechanically it does not. The differences are in identity (the caller is non-human), in audit (the agent identity and on-behalf-of identity are both captured), and in the assumption that the agent will construct calls in ways a human would not. The rule set is built with that assumption in mind.
