Integration conversations surface three terms at once: API, FHIR, and MCP. Asked "so which should we pick?", the honest answer is that these are not alternatives. They sit at different layers and coexist.
Disclaimer: General information. Specifications and adoption change; confirm current details when evaluating.
The Short Answer—Three Different Layers
| What it defines | In a phrase | Analogy | |
|---|---|---|---|
| FHIR | How medical data is represented | The shape of the data | The form's format |
| API | How data is handed over | The counter's specification | The submission window |
| MCP | How counters are presented to AI | Counters an AI can choose from | The signboard, written for AI |
Data shaped by FHIR, handed over by an API, with that counter presented to AI through MCP—all three hold at once.
FHIR—Defining the Shape
FHIR (Fast Healthcare Interoperability Resources), from HL7, is an international standard for representing medical data.
If every site and system names lab fields differently, uses different units, and orders them differently, the receiving side cannot interpret them. FHIR fixes a shared format.
FHIR defines content and structure, not delivery—the same FHIR data can travel as a file or over an API. Japan's national standardization work is adopting FHIR; see What Is the Government Standard EMR? and The EMR Information Sharing Service. SS-MIX2 sits at this same layer.
API—Defining the Handover
An API is the specification of a counter a system offers: query in this format, receive that format.
An API defines the procedure, not the content format—which is why "an API that returns FHIR data" is a coherent thing. See What Is an API? and EMR–ORCA Integration.
MCP—Defining How Counters Are Presented to AI
MCP (Model Context Protocol) standardizes how counters are laid out on the assumption that AI will use them.
The decisive difference from a conventional API: the AI decides which counter to use. With APIs, a developer scripts "in this situation, call this." With MCP, the list of counters and AI-readable descriptions are presented, and the AI chooses.
See What Is MCP? and What Is an MCP Server?.
One Request Through All Three—"Get the Latest HbA1c"
FHIR layer. The result is an Observation, with defined fields for what was measured (a LOINC code), the value, the unit, when, and for whom. HbA1c carries the same code across sites.
API layer. A counter accepts a patient ID and a test code and returns matching results—with defined invocation, authentication, and response format.
MCP layer. A tool—say get_lab_results—is presented to the AI with the description "takes a patient ID and a test item, returns recent results." Asked "what's the latest HbA1c?", the AI reads that, picks the tool, assembles the arguments, and calls it.
The division of labor becomes visible:
- Without FHIR → values come back, but field names differ per site and interpretation costs
- Without an API → nothing can be retrieved from outside the system at all
- Without MCP → retrieval works, but a human must script which API to call when
Comparison
| Dimension | FHIR | API | MCP |
|---|---|---|---|
| Defines | Data structure and meaning | The exchange procedure | How counters are presented to AI |
| Primary user | Systems, to each other | Human developers | The AI |
| How it is described | Humans read the spec | Humans read the docs | Presented in AI-readable form |
| Healthcare-specific? | Yes | No | No |
| Who standardizes it | HL7 (international) / national policy | Per service | Open specification originated by Anthropic |
| Cost of absence | Data does not line up across sites | Nothing is retrievable externally | AI cannot use it autonomously |
Only FHIR is healthcare-specific—worth remembering. API and MCP are industry-agnostic and say nothing about medical data structure.
"FHIR Makes MCP Unnecessary" Is Wrong—And So Is the Reverse
Misconception 1: "If it is FHIR-standardized, AI can use it." FHIR aligns the shape but does not decide which counter the AI uses, when. Autonomous use needs a layer that presents counters to AI.
Misconception 2: "With MCP, FHIR is unnecessary." If data retrieved through MCP is formatted differently per site, the AI struggles to interpret it and accuracy wobbles. Better-standardized data is easier for AI to handle.
They are complementary. The value of standardized data rises under AI, not falls.
What Weakness at Each Layer Looks Like
Weak FHIR layer → conversion work at every migration, and information sharing between sites stalls. See EMR Data Migration and EMR Vendor Lock-In.
Weak API layer → every peripheral integration becomes manual. Booking, web questionnaires, devices, payments—each isolated.
Weak MCP layer → you adopt AI and get an assistant that answers only in generalities. AI that cannot see internal data is not usable for charting.
How This Bears on EMR Selection
FHIR layer
- Do you support export in standard formats (HL7 FHIR / SS-MIX2)?
- On termination, can we receive patient data in a standard format?
API layer
- Is an integration API published? At what additional cost?
- What peripheral systems have you integrated in production?
MCP layer
- Do you plan to provide an AI integration counter (an MCP server or equivalent)?
- Can we configure what the AI may reference?
- Is the AI constrained so it cannot exceed staff permissions?
Asking the three separately sharpens the conversation. A single "do you support AI?" tends to produce an answer that never says which layer it is about.
See EMR Comparison 2026 and AI EMR Comparison 2026.
Conclusion
- FHIR, API, and MCP do not compete—they are layers
- FHIR = the shape of data (healthcare-specific), API = the handover (general), MCP = counters an AI can choose (general)
- In one request, FHIR carries meaning, the API carries retrieval, MCP carries the AI's choice
- Neither "FHIR replaces MCP" nor "MCP replaces FHIR" holds—standardized data pays off more under AI
- Symptoms differ by layer: weak FHIR → migration and sharing stall; weak API → manual integrations; weak MCP → AI stuck in generalities
- Ask vendors about the three layers separately
For details on AI Karte or to request a demo, please contact us.