As Model Context Protocol rapidly gains traction in the LLM ecosystem, many teams are eager to see these capabilities integrated natively into EHR platforms.

We are optimistic that MCP-native capabilities will eventually become standard within EHRs. But the important point is this:

We do not have to wait.

Thanks to SMART on FHIR, we can build MCP-enabled applications today, whether they are launched inside the EHR through EHR Launch or deployed as standalone applications.

In both cases, the app receives:

An access token with scoped permissions
Clinical context such as the selected patient

That context can be preserved and propagated downstream into the MCP flow. The result is highly relevant, secure, and controlled interaction with FHIR resources and other tools.

Clearing Up a Major Misconception

One of the most common misunderstandings about MCP is the belief that LLMs directly invoke external tools.

They do not.

The app, referred to as the Host with a Client in MCP terminology, is always in charge.

This architectural distinction is critical for governance, security, and compliance, especially in healthcare.

How the Flow Works

Below is a simplified conceptual explanation of how MCP bridges an EHR-integrated app, an LLM, and external tools such as FHIR APIs. This describes the high-level interactions rather than every technical nuance.

Step 1: SMART on FHIR Authentication
The app obtains an access token using the SMART on FHIR flow. This token includes scoped permissions and user context.

Step 2: Tool Discovery
The app requests the list of available tools from the MCP Server.

Step 3: Model Reasoning
The app sends the user’s prompt along with the tool metadata to the LLM. The LLM reasons about whether it needs to use a tool to fulfill the request.

Step 4: Controlled Tool Execution
If a tool call is required, the app executes it. Not the LLM. The app asks the MCP Server to retrieve data or perform an action, such as querying a FHIR server for patient information.

Step 5: Response Construction
The app receives the structured results, passes them back to the LLM for synthesis, and then surfaces the final response to the user.

Why This Separation Matters

In this architecture, the app holds:

The orchestration logic
The user session
The access token
The clinical context

This separation ensures that:

The app maintains full control
All operations occur within the user’s scoped permissions
The LLM operates with contextual grounding
The system remains auditable and secure

This design is particularly well-suited for interactive, point-of-care tasks where user context is essential.

What About Population Health?

The flow described above operates within a user context and is ideal for real-time clinical interactions.

For system-level use cases such as population health, backend SMART on FHIR flows can be leveraged differently. In those scenarios, applications operate without an interactive user session and can support broader analytics and automation use cases.

That deserves a deeper dive in a separate discussion.

Why This Is a Big Deal

MCP adoption is accelerating because it solves a structural problem.

LLMs are powerful, but without structured access to real-time data, they are limited. SMART on FHIR already provides authenticated, scoped access to clinical data. MCP provides the standardized bridge between LLM reasoning and those tools.

FHIR structures the data.
SMART secures the access.
MCP orchestrates the interaction.

Together, they create a powerful and secure foundation for clinical copilots.

Building in the Real World

At Prompt Opinion, we are actively building and testing this architecture with our own FHIR servers.

If you are exploring similar integrations, whether for clinical decision support, workflow automation, or advanced analytics, we would welcome the opportunity to compare approaches, exchange demos, or dive deeper into the architectural details.

The stack is evolving quickly. Collaboration will shape how it matures.

MCP is Spreading Fast and Catching up with FHIR