FHIR and MCP are both technical standards increasingly discussed in the same breath when clinical AI integration comes up, and they are easy to conflate despite solving genuinely different problems. Understanding the distinction clearly matters for judging what any specific product's integration claims actually promise.
Defining the two standards precisely
FHIR exchanges structured patient and healthcare-system data, the standard covered in detail elsewhere in this content series, allowing systems to share medicines, observations, conditions and results in a common format. MCP enables an AI agent to access external tools and knowledge resources, also covered in detail elsewhere in this series, allowing a developer's AI system to draw on another organisation's curated content or capability without a bespoke integration for each one.
How the two could plausibly work together
In a combined architecture, FHIR supplies the patient context, the specific data about the individual in front of the clinician. MCP supplies the medical knowledge, the trusted external content the reasoning system draws on to interpret that context. The underlying reasoning system combines both, connecting the specific patient's data to relevant, trustworthy medical knowledge. And the EHR remains the location for review and action, the place where a clinician actually sees, evaluates and acts on whatever the combined system has produced.
AMBOSS as the clearest current worked example
AMBOSS illustrates both halves of this combination directly. Its stated healthcare-integration vision, covered in detail elsewhere in this content series, is built on FHIR, aiming to connect patient context from the EHR to its own knowledge base. Its separate developer strategy, its MCP server, opens that same curated knowledge base for other companies' AI agents to draw on independently, a genuinely distinct move covered in its own dedicated article in this series.
Why neither standard, alone, establishes clinical safety
It is worth being direct about a point that is easy to lose amid genuinely impressive technical architecture: neither FHIR nor MCP, on its own, guarantees anything about clinical safety. FHIR can transmit incorrect data entirely faithfully; the standard governs how data moves, not whether the data itself is accurate. And MCP can retrieve a genuinely reliable source that is then misinterpreted, summarised inaccurately, or stripped of important context by whatever reasoning system is using it. The reasoning and governance layers sitting on top of both standards remain entirely essential regardless of how well-engineered the underlying data-exchange plumbing is.
An outline of the ideal architecture
A genuinely safe combined system would need, at minimum, several distinct layers working together: access to the minimum necessary patient data for the specific task at hand, rather than unrestricted record access by default; curated, jurisdiction-appropriate knowledge, matched to the specific healthcare system the clinician is working within; explicit reasoning constraints, limiting what kinds of conclusion the system is permitted to draw from the combined data; citation preservation, maintaining a clear, traceable link back to the original source throughout; clinician approval as a genuine, non-bypassable checkpoint before anything becomes part of the formal record; and a complete audit trail, allowing any specific recommendation to be traced back to exactly what data and knowledge informed it.
The UK opportunity this points towards
For the UK specifically, this combined architecture suggests a genuine, if currently unbuilt, opportunity: FHIR-based access to NHS patient data, UK-guideline grounding supplying the trusted medical knowledge layer, local formulary and trust-policy information layered on top for genuinely local relevance, and a UK-native knowledge service such as iatroX, or a comparable platform, supplying that guideline-grounded layer specifically, rather than importing a US-oriented knowledge base into a UK clinical context wholesale.
Why this distinction is worth understanding regardless of which specific product a clinician uses
FHIR and MCP are not, on their own, marketing terms that guarantee safety or quality; they are plumbing standards that make certain kinds of integration technically possible. Any specific product's actual safety depends entirely on the reasoning, governance and human-oversight layers built on top of that plumbing, and a clinician evaluating any AI tool's integration claims is well served asking directly about those layers, not simply noting that FHIR or MCP is mentioned in the product description.