A hospital agent that cannot reach the record is a chatbot with good intentions. The moment it can reach the record, two engineering questions decide whether it works and whether it is safe: how does the model connect to its tools, and what shape is the clinical data those tools return? As of July 2026 the industry has converged on two standards, one for each question — the Model Context Protocol for the connection, and HL7 FHIR for the data. This guide maps how they fit, drawing on the specifications themselves, and then turns to the seam between them, which is where the security work lives. As of July 2026.
Two problems, two standards
The single most useful thing to hold onto is that these standards are not competitors. FHIR answers what does clinical data look like: it models health information as discrete, addressable resources — a Patient, an Observation, a MedicationRequest — exposed over a RESTful API for exchange between systems 4. The Model Context Protocol answers how does a model reach a tool: it is an open standard for secure, two-way connections between data sources and AI tools, so a model builds against one protocol instead of a bespoke connector for every system 1. In a working hospital agent, MCP sits above FHIR: an MCP tool wraps a FHIR call, and the Model Context Protocol in health IT becomes the way an agent reaches data that FHIR has already put into a common shape.
What MCP standardizes
MCP's value is consolidation. A model that speaks the protocol can reach any system that exposes an MCP server, which collapses the classic integration problem — a separate connector per data source — into a single interface 1. Two facts matter for a hospital adopting it. First, governance: in December 2025 the protocol was contributed to the Linux Foundation's newly formed Agentic AI Foundation, giving it vendor-neutral stewardship rather than single-company control 3 — the kind of continuity a hospital committing to a standard needs to see. Second, the specification is dated and versioned, and it carries explicit authorization and security rules rather than leaving them to implementers 2. That second fact is easy to skip past and is the one that keeps a connection from becoming a liability, as the security section below makes concrete.
What FHIR and SMART standardize
FHIR fixes the shape of the data; SMART App Launch fixes who may touch which parts
of it. SMART layers OAuth 2.0 over FHIR so a client application receives precisely
scoped access — which resource types it may read or write, for which patient, under
whose authorization — and it defines a backend-service pattern for automated
clients with no human at the keyboard, plus a discovery document at
.well-known/smart-configuration where a server advertises its capabilities
5. For an agent, the scope is the point. A read-only grant over two
resource types is a modest risk; a broad write grant is a large one. SMART is where
that boundary is declared, which is why it belongs in any serious conversation
about agent integration rather than being treated as backend detail. This access
layer is also what a retrieval-augmented
generation pipeline draws
on when it grounds a model's answers in real record content.
How they compose in practice
The stack is not theoretical. A peer-reviewed open-source framework wraps HL7 FHIR resources as Model Context Protocol tools, giving a model declarative access to FHIR data through JSON configuration rather than per-EHR hardcoded retrieval logic — a demonstration that MCP-over-FHIR is buildable and reusable 6. A separate study took the stack into a live hospital: researchers connected an LLM through MCP tools to the real EHR and had it answer infection-control questions, reaching near-perfect accuracy on simple retrieval 7. Together these establish the practical point — the plumbing works, today, on real data.
A single query, end to end
It helps to trace one request through the whole stack. A clinician asks the agent a question; the model decides it needs record data and calls an MCP tool exposed by its client 1. The MCP server behind that tool receives the call, validates that the access token was issued for it 2, and translates the request into a FHIR read against the resources its SMART scope permits 5. The FHIR server returns structured resources — the addressable, reference-linked objects that are the point of the standard 4 — and the model reasons over them to answer. Every layer in that path is a standard doing one job: MCP carries the call, the token guards the authority, SMART bounds the scope, FHIR shapes the data. The peer-reviewed MCP-FHIR framework 6 and the real-hospital MCP study 7 are, in effect, two implementations of this same path — one built to be reusable across records, the other proven against a live one. Seeing the request as a chain makes the security duties fall into place: each handoff is a point where authority can be checked or can leak, and the stack is only as safe as its weakest handoff.
Interoperability does not mean easy
Standardized access removes one hard problem and exposes another. A benchmark that grounded 2,931 real-world clinical questions in the HL7 FHIR standard found that "the practical challenges of retrieving data from intricate FHIR resources and the difficulty of reasoning over them" both critically limit how well agents answer 8. FHIR resources are deeply nested and reference-linked; walking them to assemble a clinically correct answer is a reasoning task the protocol cannot do for you. The same real-hospital study that nailed simple retrieval degraded on a complex, time-dependent calculation 7. The lesson for anyone scoping an agent: interoperability gets the data to the model in a common shape, and getting the right data assembled correctly is a separate capability that current agents have only partly earned. It is worth keeping the two failure surfaces distinct. A retrieval that returns the wrong resource is a plumbing problem the standards can help fix; a retrieval that returns the right resources and draws the wrong clinical conclusion is a reasoning problem no protocol addresses. Confusing the two is how a team over-invests in integration and under-invests in evaluation.
The seam is where security lives
Connecting a model to a live record is exactly where the risk concentrates, and three duties sit at that seam. Authorization. The MCP specification requires a server to validate access tokens and accept only tokens issued specifically for it, guarding against the confused deputy problem in which a server is tricked into wielding another service's credentials 2. Skip that, and a standardized connection becomes a standardized way to escalate. Prompt injection. Once a model retrieves record content and can call tools, hidden instructions inside that content can steer its actions — the risk OWASP ranks first in its LLM Top 10 9, and the reason prompt injection in clinical systems becomes a first-order concern the moment MCP is in the loop. Excessive agency. OWASP names a distinct risk for agents granted more functionality, permissions, or autonomy than a task requires — "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs" 10. The mitigation is the mirror image of the SMART scope discussion: grant the least capability the task needs, and no more. None of these is solved by adopting a protocol. The protocol makes connection easy; safety is designed on top of it, a theme our guide on agent safety frameworks develops into a full control map.
How access composes: two permission systems
An agent on this stack is governed by two permission systems at once, and getting them to agree is much of the security work. SMART scopes decide what the client may ask the FHIR server for — which resource types, which patients, read or write 5. MCP tool permissions decide what the model may invoke through its server, and the specification's insistence that a server accept only tokens issued for it is what stops one tool's authority from leaking into another's 2. The failure mode to design against is a mismatch: a generous SMART scope behind a loosely permissioned MCP tool hands a model more reach than anyone intended, and the confused-deputy problem is what happens when a server acts on authority that was never meant for the caller. The discipline that resolves it is least privilege applied twice — the narrowest SMART scope the task needs, wrapped in an MCP tool that exposes only the operations that scope supports. When the two permission systems are scoped to the same small job, the blast radius of a manipulated prompt or a buggy plan stays bounded; when they drift apart, the gap between them is the vulnerability. This is the concrete version of the excessive-agency warning 10: agency is granted, in practice, one scope and one tool permission at a time.
Questions to ask before you build
Framing the decision as questions keeps a team honest about what the standards do and do not deliver.
| Layer | The question to answer | Where the standard helps |
|---|---|---|
| Data | Which FHIR resources does the task genuinely need? | FHIR resource model 4 |
| Access | What is the narrowest SMART scope that still works? | SMART App Launch 5 |
| Connection | Does each MCP server accept only tokens meant for it? | MCP spec authorization 2 |
| Reasoning | Has the agent been tested on your data's complexity, beyond simple lookups? | FHIR agent benchmarks 78 |
| Autonomy | What is the least agency the task requires? | OWASP excessive agency 10 |
| Governance | Who stewards the standards you are betting on? | Agentic AI Foundation 3 |
How to read this guide
Two cautions. Standards move: the MCP specification is dated for a reason, FHIR and SMART are versioned, and the specific security rules cited here are current as of July 2026 and will be revised. And adopting a standard differs from implementing it correctly — most of the failures in practice come from misconfigured scopes and over-broad tool permissions rather than from the specifications themselves. For how these pieces show up inside real systems, see our guide on EHR-integrated agents; for the wider deployment picture, see our AI in healthcare statistics. We revisit this page on a 180-day cycle and whenever the MCP specification, a FHIR release, or the OWASP lists are revised.
Sources and method
This guide is grounded in primary specifications and studies: the Model Context Protocol introduction 1 and dated specification 2, its move to Linux Foundation governance 3, the HL7 FHIR resource model 4 and SMART App Launch access framework 5, a peer-reviewed MCP-FHIR framework 6, a real-hospital MCP study 7, a FHIR question-answering benchmark 8, and two OWASP risk definitions 910. Every claim traces to the source cited beside it, and each citation was checked to resolve before publication.