14 Sep
A health system security review used to open with one question: does the agent support MCP? Most vendors clear that bar now, since Model Context Protocol has moved from a novelty to something buyers expect by default. The review used to end there too. Increasingly, it doesn’t.
The next question catches teams flat: once the agent reads a patient’s record, what happens to that data? Does it get cached? Does it leave the health system’s environment? Does it get sent to a model provider? Does any of it end up in a training set? Most teams that built for the MCP checkbox never answered that second question, because nothing in the FHIR authorization model they relied on required it.
What does MCP actually change in how an agent touches FHIR data?
Model Context Protocol gives an AI agent a standardized way to call external tools instead of requiring custom code for every EHR integration. A developer points an agent at an MCP server that already knows how to speak FHIR R4, and the agent calls tools by name, such as retrieving patient observations or listing medications, while the server handles the underlying FHIR query. That standardization is why it’s spreading so fast through procurement conversations: once one buyer asks whether a vendor’s agent supports MCP, the next buyer asks the same question, and it becomes a checkbox, as REST API support once was.
The problem is that MCP standardizes the calling convention, not the governance around what the agent does with what it retrieves. A tool call that pulls a patient’s medication list is the same tool call whether the result gets used once and discarded or gets logged, cached, and forwarded somewhere else. MCP doesn’t distinguish between those outcomes, and neither does the FHIR layer underneath it.
What does FHIR's authorization model actually cover?
FHIR itself is explicit about this boundary. HL7’s own FHIR specification states plainly that FHIR “is not a security protocol, nor does it define any security-related functionality,” and instead relies on external frameworks, chiefly OAuth 2.0 through the SMART App Launch Implementation Guide, to authorize which client may access which resource. That authorization answers a narrow, specific question: may this client read this resource? It says nothing about what the client is allowed to do with the resource once the read succeeds.
This isn’t a gap anyone forgot to close. It’s a deliberate scope boundary. FHIR was built to standardize exchange, and access control was deliberately left to standards built for that purpose, like OAuth and SMART on FHIR. Those standards were designed with a human user or a defined application in mind, not an autonomous agent that reads a resource, reasons over it, and potentially acts on an inference drawn from it.
What happens after an agent reads the record?
Once an agent has a FHIR resource in hand, several things can happen to it that a read-access grant never addressed. The agent’s runtime might keep a copy in context for a later turn. The content might get forwarded to a third-party model provider as part of a prompt. It might get logged somewhere for debugging and sit there indefinitely. It might feed an inference the agent presents to a clinician without ever surfacing which source data produced it. None of these outcomes required a second authorization check, because the authorization model only gates the read.
For a buyer’s security team, that’s precisely the exposure they’re trying to close before signing. HIPAA’s minimum necessary standard already asks covered entities and their business associates to limit use and disclosure of protected health information to what’s reasonably needed for the purpose at hand. An agent that reads a full patient record to answer one narrow question, and has no documented boundary on what it retains afterward, is a difficult thing for a compliance team to sign off on, regardless of how well it performs technically.
Why are buyers asking about this now?
Regulatory attention on what AI does with health data, not just whether it can access it, is already moving in this direction. ONC’s HTI-1 Final Rule, published in the Federal Register, introduced transparency and risk management requirements for predictive decision support interventions built into certified health IT, requiring source attribution and documentation of how a predictive tool arrives at its output. That rule applies to certified DSI functionality specifically, not to every AI agent a vendor might sell, but it signals where buyer expectations are heading. A security team that has spent two years absorbing DSI transparency requirements for embedded algorithms is not going to wave through an external agent with no equivalent documentation simply because it wasn’t legally required to have one.
Procurement conversations tend to catch up to regulatory direction before regulation catches up to the technology causing it. That’s exactly what’s happening with agent data governance right now.
| What FHIR’s authorization model covers | What it does not cover |
|---|---|
| Whether a client may read a specific resource, via OAuth 2.0 and SMART on FHIR scopes | Whether the agent retains a copy of that resource after the read |
| Which resource types and fields a scope grants access to | Whether the content is forwarded to a third-party model provider |
| Audit and provenance tracking of access events, via FHIR AuditEvent and Provenance resources | Whether the data is used to train or fine-tune a model |
| Consent-based token issuance in patient-directed workflows | Whether an inference drawn from the data is logged, retained, or surfaced without its source |
What should a startup be able to show a buyer today?
Before a security review asks the second question, a team benefits from already knowing the answer. That starts with knowing exactly what the agent actually calls, not what the integration was designed to call in theory.
- A documented list of every FHIR resource type and field the agent’s MCP tools actually retrieve during a typical session, not just the ones it was designed to use.
- A written retention policy stating whether retrieved data persists after the session ends, and for how long, if at all.
- A clear answer on whether any retrieved content is sent to a third-party model provider, and under what data processing terms.
- A statement on whether any retrieved data is used for model training, fine-tuning, or evaluation, separate from serving the immediate request.
- An audit trail that ties each inference the agent produces back to the specific resources it drew from.
The fastest way to build the first item on that list honestly is to look at the actual FHIR resources the agent pulls, not the resources the integration spec says it should pull. Hgear’s free FHIR Viewer lets a team load a synthetic or de-identified FHIR bundle and see exactly which resources and fields are present, which is the same view a security reviewer will eventually want documented. Building that documentation against synthetic data first means the answer is ready before a real patient record is ever involved.
Want to see what your agent's data footprint actually looks like?
Hgear’s free FHIR Viewer is built for exactly this kind of pre-review check. Load a synthetic or de-identified FHIR bundle, see the resources and fields directly, and build the documentation a buyer’s security team will ask for before they ask for it.
FAQs
Model Context Protocol, or MCP, is a standard that lets an AI agent call external tools, such as FHIR data sources, without custom integration code for every system. It has become common enough in healthcare AI procurement that vendors now report seeing it as a default question in RFPs, similar to how REST API support once became a standard checkbox.
No. HL7's FHIR specification states that FHIR itself is not a security protocol and relies on external frameworks like OAuth 2.0 and SMART on FHIR to authorize access to a resource. That authorization governs whether a read is permitted, not what happens to the data afterward, including whether it's retained, forwarded to a model provider, or used for training.
The minimum necessary standard requires covered entities and business associates to limit use and disclosure of protected health information to what's reasonably needed for a specific purpose. An AI agent that retrieves broader data than a given task requires, without a documented boundary on retention or downstream use, creates a gap that security teams are increasingly unwilling to approve without evidence.
HTI-1, finalized by ONC and published in the Federal Register in January 2024, introduced transparency and risk management requirements for predictive decision support interventions built into certified health IT, including source attribution and documented risk management practices. It applies specifically to certified DSI functionality, but it reflects the direction procurement and compliance expectations are moving for AI more broadly.
The most reliable method is inspecting the actual FHIR resources and fields the agent's tool calls retrieve during real usage, rather than relying on the integration's original design spec. Hgear's free FHIR Viewer lets a team do this against synthetic or de-identified FHIR bundles, producing the same resource-level view a buyer's security team will eventually ask to see.
No. Evaluating what an agent retrieves and how it behaves should be done against synthetic or de-identified data first. That avoids exposing real protected health information during development and testing, and it still produces an accurate picture of the agent's data footprint since the FHIR structure is the same regardless of whether the underlying data is real or synthetic.
ISO 27001:2022 Certified
Aigilx health specializes in developing Interoperability solutions to create a healthcare ecosystem and aids in the delivery of efficient, patient-centric and population-focused healthcare.
