A Letter to the Healthcare IT Community
This week, Tim Cook published his farewell letter as Apple CEO. In it, he reflected on how Apple's products had touched lives in ways that defied description — a mother saved by her Apple Watch, a photograph captured at the summit of a mountain that seemed impossible to climb. He spoke of shared humanity, and of the privilege of leading a company that ignites imaginations and enriches lives.
Reading Tim's letter, I found myself thinking not about consumer electronics, but about healthcare. Because the same transformation that Apple brought to how we interact with technology is now quietly, powerfully, underway in how healthcare systems interact with each other — and soon, with intelligent agents that can reason over clinical data in real time.
That transformation has a name: HL7 FHIR.
And after 20 years of working with healthcare interoperability standards — from the early days of HL7v2, HL7 CDA to HL7 FHIR, designing and building Healthier SG FHIR API and Data Grid serving Singapore's Healthier SG transformation — I believe we are at an inflection point. FHIR is no longer just a better way to exchange messages between hospital systems. It is becoming the foundational layer upon which the next generation of healthcare will be built: a generation defined by data liquidity, AI-native clinical workflows, and a new universal protocol layer that connects human clinicians and AI agents to the same trusted data.
Let me explain why.
Part 1: The Interoperability Problem Is Not Technical — It's Business
For decades, healthcare IT has been trapped in a paradox. We have more clinical data than ever, yet it remains locked inside hundreds of proprietary systems, each speaking its own dialect. Every time two systems need to talk, someone builds a bespoke integration — custom mappings, custom APIs, custom testing. Each such integration will not only introduce huge amount of integration effort, it also leads to potential issue of semantic data drift.
This is not a technology problem. It is an business problem - Data is the most important asset of any healthcare organisation. It is broken because there has never been a universal agreement on what a patient record looks like, how you ask for one, or where the boundaries of a clinical concept begin and end.
All the business process and rules are all built upon data to record the state change, enforce data integrity and maintain data quality. If we do not put focus and attention on data, then we are just simply pursuing the project as ticking the box as project completed.
HL7 FHIR fixes this. Not partially, not theoretically — practically.
FHIR defines a common data model for clinical resources: Patient, Observation, MedicationRequest, Encounter, CarePlan, Condition, Procedure — each with a standardised structure, a RESTful API contract, and a well-defined set of search parameters. When two systems speak FHIR, they are not just exchanging data — they are sharing a common understanding of what that data means.
This is what I mean by interoperability. Not the ability to move bytes from point A to point B. The ability to move meaning.
Part 2: Data Liquidity — From Locked Vaults to Flowing Rivers
Once you standardise the data model, something remarkable happens: data becomes liquid.
In the old world, clinical data sits in application databases — structured for the application that created it, accessible only through the application's own interface. Extracting it for analytics, research, or even basic care coordination requires custom ETL pipelines, data warehouses, and reconciliation logic that is expensive to build and brittle to maintain.
In the FHIR world, every clinical record is a resource with a URL. It can be created, read, updated, searched, and subscribed to through a universal API. A patient's medication history is not buried in a vendor-specific schema — it is a collection of MedicationRequest resources that any authorised system can query using standard search parameters. A lab result is an Observation with a LOINC code. A diagnosis is a Condition with a SNOMED CT code.
This is data liquidity: the ability for clinical information to flow freely, safely, and meaningfully across organisational boundaries without losing its clinical fidelity.
I have seen this firsthand. When we implemented the Healthier SG FHIR API Platform at Synapxe, we enabled the same FHIR data flow seamlessly between different systems - from upper stream end-user facing systems, and store in central national data repositories, and seamlessly flow to other national systems for reporting and analytics. What changed was the accessibility of the data, because FHIR provided a common language that every application could understand and exchange easily.
And this is just the beginning. I recently used Claude Code to generate millions of FHIR resources — patients, encounters, observations, medication requests, and care plans, complete with SNOMED CT, LOINC, and RxNorm coding , and all these data are interlinked through FHIR's resource reference — it took less than a minute of prompting to create script which can generate any number of records as you requested. Previously, this kind of test data preparation would take days or weeks of manual work by the engineer and also requiring the engineer have good knowledge on SNOMED CT, LOINC and RxNorm. FHIR's structured, standardised nature makes it inherently machine-friendly — not just for data exchange, but for data prearation, validation, and reasoning
Part 3: The Agentic Era — Why FHIR Is the Foundation for AI in Healthcare
Now we arrive at what I believe is the most consequential development in healthcare IT since FHIR itself: the convergence of FHIR and agentic AI through the Model Context Protocol (MCP).
Let me unpack this.
What Is MCP?
The Model Context Protocol, originally developed by Anthropic and now adopted as an open standard with support from Google, Microsoft, OpenAI, and others, defines how AI agents discover and interact with external tools and data sources. Think of MCP as a universal adapter: it tells an AI agent what tools are available, what each tool can do, and how to invoke it — all through a standardised interface.
In the words of one industry expert, MCP is like "FHIR for AI" — just as FHIR standardised how healthcare systems exchange data, MCP standardises how AI interacts with those systems.
Why FHIR + MCP Is a Game Changer
Here is the key insight: FHIR's resources are inherently self-describing. A FHIR server's CapabilityStatement tells you exactly which resources it supports, which operations are available, and which search parameters are valid. A FHIR StructureDefinition tells you the exact shape of every resource — its fields, data types, cardinality, and validation rules. A FHIR OperationDefinition tells you the input and output parameters of every extended operation.
This means an AI agent, connected to a FHIR server through MCP, can discover the server's capabilities at runtime. It does not need hardcoded knowledge of the API. It does not need custom integration code. It reads the CapabilityStatement, understands what is available, and begins reasoning over the data.
This is exactly what I have built in my open-source project, fhir4java-agents. The server exposes its FHIR resources and operations as MCP tools — just three MCP tools are sufficient for an AI agent to perform full CRUD operations, execute FHIR searches, and invoke extended operations across any supported resource type. The agent does not need separate tools for Patient, Observation, or CarePlan. It discovers the resource types dynamically and interacts with them through a unified interface.
The implications are profound:
For clinicians: Imagine a physician asking an AI assistant, in natural language, to pull up a patient's recent lab results, cross-reference them with current medications, and flag potential drug interactions — all sourced directly from the FHIR server, with full provenance and audit trail. No custom dashboard development. No data extraction pipeline. The agent reads FHIR resources, reasons over them, and presents findings in context.
For care coordination: An AI agent could monitor incoming FHIR Subscription notifications — new lab results, changed medication orders, updated care plans — and proactively alert the care team when clinical thresholds are breached or when care plan goals are at risk.
For population health: Multiple AI agents, each connected to different FHIR endpoints across different institutions, could collaboratively analyse anonymised population data to identify emerging health trends, evaluate intervention effectiveness, or optimise resource allocation — all while respecting data sovereignty because the agents query the data where it lives rather than centralising it.
The Architecture: A Universal MCP Layer
The architecture I envision — and have been building toward — looks like this:
At the base layer, you have FHIR-compliant data platforms storing clinical resources in standardised formats. These platforms support profile-based validation, terminology binding (SNOMED CT, LOINC, RxNorm), and configuration-driven resource management.
Above that sits the MCP layer — a set of MCP servers that expose FHIR capabilities as discoverable tools. Each MCP server can run as a native plugin within the FHIR server (for performance-critical operations) or as an external service in any language — Python, Node.js, Go — communicating over JSON-RPC or HTTP+SSE transport. This hybrid plugin architecture means the system is extensible without being fragile. A new clinical decision support algorithm can be deployed as an MCP plugin without restarting the FHIR server. A machine learning model for sepsis prediction can be wrapped as an MCP tool and made instantly discoverable by any connected agent.
At the top layer, AI agents connect to the MCP layer and dynamically discover available capabilities. These agents can be general-purpose clinical assistants or specialised agents focused on specific workflows — medication reconciliation, discharge planning, surgical scheduling. Because MCP provides a standardised discovery mechanism, agents can be composed and orchestrated without tight coupling.
This is not science fiction. This architecture is running today. I demonstrated it in my recent blog post and video (see the demo to illustrate how AI agent is interacting with the data), showing how an AI agent connected to fhir4java-agents through MCP can create patients, query observations, and manage care plans — all through natural language interaction, with the MCP layer handling tool discovery and FHIR server handling data integrity.
The User Interaction Shift: Transition from fixed menu driven interaction towards natural fluid AI driven interaction
For Healthcare IT vendor/solution: The future of Healthcare IT system will slowly transition towards headless EHR product where the primary focus is to manage the backend data platform to achieve the flexible data model for future readiness, and enforce strong data validation and business control to ensure data integrity and quality, and robust AI enabled APIs through universal MCP layer with strong control on security and audit trail to guard the safe and appropriate use of data, whereas the user interfaces can leverage on the robust capabilities of AI agent which can create any UI on the fly, and any user can save his/her personalised skills to launch pre-configured and preferred user interface.
There will be some healthcare specific AI agents available in the market with the ability to interact with any backend systems. These healthcare specific AI agents will provide out of box integration with SmartOnFHIR to perform authentication and authorisation.
Part 4: What This Means for Singapore and Beyond
Singapore is uniquely positioned to lead this transformation. We have practical HL7 FHIR implementation experience, we have designed and implemented more than 10 native HL7 FHIR based systems for production usage. Our Healthier SG implementation received inaugural HL7 FHIR DevDays in 2024, see the Synapxe news here. We have a passionate team promoting HL7 FHIR within Synapxe and MOH, We have a centralised healthcare IT infrastructure through Synapxe that manages the public healthcare IT estate. And we have a forward-looking AI governance framework through IMDA's Model AI Governance Framework that can guide the responsible deployment of agentic AI in clinical settings.
The pieces are in place. What is needed now is the conviction to connect them.
FHIR is not just a technical standard. It is an instrument for business transformation as outlined below
- It is a framework for project delivery transformation - from ticking the box as "project completed" to "data transformation is done"
- It is a means for cost discipline — turning what would otherwise be millions in fragmented, one-off integration spend into a governed, reusable, and scalable capability.
- It is a platform for data liquidity — making clinical information accessible wherever it is needed, in real time, without sacrificing governance or security
- It is a platform for the agentic future — providing the self-describing, machine-readable data layer that AI agents need to operate safely and effectively in clinical environments.
A Personal Reflection
I started my journey with HL7 standards in 2006 when I started to join a healthcare startup company working on EHR/PHR. I have since been involved with HL7, IHE, ISO TC215, and HITC — drafting and reviewing healthcare interoperability standards for the company I worked for and for Singapore.
Through all of this, one conviction has remained constant: standards matter. Not because they are fashion, but because they enable innovation, and unlock value. When everyone agrees on how a Patient resource looks, engineers stop spending months on data mapping and start spending days on clinical value. When AI agents can discover capabilities through a standard protocol, developers stop building custom integrations and start building intelligent workflows.
Tim Cook wrote that Apple's products fit into real lives — that technology should serve humanity, not the other way around. I believe the same is true for healthcare IT. FHIR, MCP, and agentic AI are not ends in themselves. They are means to an end that matters deeply: better care for real patients, delivered by empowered clinicians, supported by intelligent systems that earn and deserve our trust.
The future of healthcare interoperability is not about connecting systems. It is about connecting knowledge. And that future is here.
