4 options to Integrate Copilots with EHRs
Every major EHR will support some form of chat-based interface sooner rather than later. The real question is not whether copilots will exist, but how they will be architected.
There are four primary integration options emerging. The key differentiators are:
What data can the interface access
What actions can it perform
What large language models can it support
How open the ecosystem is to innovation
Below is a breakdown of the four dominant options.
Option 1: EHR-Native Chat Interfaces
In this model, the EHR vendor builds the copilot entirely within its own platform. The interface, the orchestration, and often the LLM integration are controlled by the EHR.
This is the most vertically integrated and closed model.
Pros:
Full access to all available EHR data and services
Deep workflow integration
Strong control over compliance and governance
Cons:
User experience locked into the EHR’s design paradigm
Limited or no flexibility in choosing the LLM
Minimal room for third-party innovation
This model maximizes control and tight integration, but limits ecosystem flexibility.
Option 2: EHR-Supported MCP Server
In this model, the EHR exposes its data and capabilities through a Model Context Protocol server. External copilots can connect to the MCP endpoint to retrieve context and invoke tools.
Here, the EHR acts as a structured tool provider rather than the UI owner.
Pros:
Decouples the user interface and LLM from the EHR
Enables third-party innovation in UI, orchestration, and analytics
Preserves structured, governed access to EHR capabilities
Cons:
Only data and functionality exposed through the MCP server are accessible
Vendor-to-vendor variability in MCP implementation may create inconsistencies
This approach balances openness with governance, but remains dependent on what the EHR chooses to expose.
Option 3: Independent MCP Servers
In this scenario, the EHR does not provide an MCP server. Instead, third-party developers build their own MCP layer. These servers consume data from the EHR using public APIs, typically FHIR, or private interfaces, and then expose that data to LLM-driven applications.
This creates a modular architecture where apps, MCP servers, and LLMs are independently developed.
Pros:
Maximum modularity across UI, tooling, and models
Encourages innovation at every layer of the stack
Greater flexibility in model selection and orchestration
Cons:
Limited to data accessible via APIs
Write-back capabilities may be restricted
Dependent on API performance and completeness
This model is attractive for organizations seeking flexibility and faster innovation cycles, especially when real-time write access is not mission-critical.
Option 4: Bulk Export into an External System
In this model, EHR data is periodically exported in bulk into a separate infrastructure environment. That environment hosts its own FHIR server and MCP layer, which then connects to LLMs, analytics systems, and downstream applications.
This architecture is particularly strong for analytics-heavy use cases.
Pros:
Full control over database infrastructure, applications, and LLMs
Excellent for population health, cohort analytics, and retrospective analysis
Scales effectively for large datasets
Cons:
Not ideal for real-time, point-of-care use cases
Requires reliable extraction and synchronization pipelines
Adds operational overhead
This model excels when near-real-time interaction is not required and analytical depth is prioritized over immediate workflow integration.
Choosing the Right Model
These four approaches are not mutually exclusive. Large health systems may adopt multiple strategies simultaneously:
Native copilots for tightly integrated workflows
MCP-based integrations for third-party applications
Independent MCP layers for modular innovation
Bulk export environments for analytics and research
The architectural choice depends on the use case. Point-of-care clinical decision support requires low latency and deep integration. Population health analytics benefits from scale and data control. Administrative automation may fall somewhere in between.
What Comes Next
Over the coming weeks, we will share deeper dives into these integration strategies, particularly Options 3 and 4, where modular infrastructure and interoperability play a central role. At Darena Health, we have developed interfaces that support these models while addressing many of their inherent limitations around data access, performance, and workflow alignment. As this space evolves, new integration patterns will undoubtedly emerge.
Are there other strategies we should be considering?
If you are exploring how to bring LLM-powered copilots into healthcare workflows, whether through building, piloting, or early-stage ideation, we would welcome the opportunity to connect and exchange insights.