An Engineer's Perspective on Building AI-Ready Interoperability Platforms
In a previous article, Structured Data is Dead. Long Live Structured Data, I described how we created a semantic layer over FHIR to support AI-driven capabilities in a proof-of-concept Risk Stratification system.
The response prompted a number of follow-up questions, many of them less about AI itself and more about the architectural decisions behind it: Why use FHIR narratives? Why are embeddings useful? What role does retrieval play? Why does chunking matter? And what exactly changes when agents are introduced into the architecture?
This article explores some of those questions from an engineer’s perspective. It is less about AI models and more about the information architecture required to make them useful.
TL;DR
🏛️ Interoperability standards provide the foundation.
📖 FHIR narratives bridge structured data and AI.
🧠 Embeddings enable semantic retrieval.
🧩 Chunking is an information architecture challenge.
🔍 Retrieval often matters more than generation.
🤖 Agents build on retrieval and orchestration.
🏗️ AI is an interface, not an architecture
FHIR gives us structure, not retrieval
FHIR is exceptionally good at representing information consistently. Combined with terminology standards such as SNOMED CT, it provides both structural and semantic interoperability, allowing systems to exchange information reliably whilst preserving meaning.
However, consistency of representation is not the same thing as discoverability. Whilst FHIR excels at modelling and exchanging information, it does not inherently provide a mechanism for exploring that information in the same way that people think about it.
Whilst some users may naturally think in terms of resources, APIs and coded concepts, many care professionals are more likely to ask questions such as, “Have there been any indicators of deterioration over the last month?” or “Are there any patterns that suggest increased support may be required?” Information may be stored as structured resources, but it is often interpreted as a narrative. People piece together observations, events, assessments and contextual information to understand what has happened, what is happening now and what may require attention.
These questions span multiple resource types, coded concepts, narratives and time periods. They are questions about context, relationships and meaning. FHIR remains the source of truth, but the architectural challenge is enabling that truth to be retrieved and explored in a way that feels natural to the people using it.
Why FHIR narratives mattered
Why not just use the FHIR JSON?
One of the more important design decisions was to build the semantic layer from FHIR narratives rather than directly from the FHIR JSON representation of the source data model.
At first glance, using the JSON itself seems like the obvious approach. After all, FHIR resources are already machine-readable, highly structured and semantically rich. Why not simply generate embeddings from the resource contents or provide the raw JSON directly to an AI model?
The more we explored this approach, the more we realised that FHIR’s strength as an interoperability standard also creates challenges for semantic retrieval.
FHIR is designed for systems rather than humans. Whilst the structure is well defined, much of the meaning of a resource exists outside the JSON itself and is defined through StructureDefinitions, terminology bindings, profiles and implementation guidance.
For example, a Condition resource contains both clinicalStatus and verificationStatus. Structurally, they appear remarkably similar. Both are represented as CodeableConcepts and may contain apparently simple values such as active or confirmed. Yet they represent entirely different concepts. One describes the lifecycle of the condition, whilst the other describes confidence in the diagnosis. Understanding that distinction requires knowledge of the underlying FHIR model rather than the JSON structure alone.
Similar patterns appear throughout the specification. A blood pressure reading stores its systolic and diastolic measurements within Observation.component rather than the polymorphic Observation.value[x]. An AllergyIntolerance resource contains both type and category, terms that appear linguistically similar but represent entirely different concepts. Even modifierExtension, which can fundamentally alter the interpretation of a resource, is structurally little more than another JSON property unless the consumer understands the rules associated with it.
None of this is a criticism of FHIR. These characteristics are a natural consequence of a sophisticated interoperability model capable of representing complex healthcare information. However, they do highlight an important distinction between interoperability and semantic retrieval.
There was also a practical consideration. FHIR resources can be verbose. Structural elements, identifiers, metadata, coding systems and terminology bindings all consume tokens, many of which contribute little to the semantic meaning we were ultimately trying to retrieve.
For retrieval purposes, we were less interested in reproducing the complete structure of a resource and more interested in capturing the meaning represented by that structure.
FHIR narratives as a semantic bridge
FHIR resources already contain a narrative representation through the text.div element. These narratives provide a human-readable view of the underlying structured data, remaining fully aligned to the source resource whilst making the information more accessible to both people and AI systems.
In many respects, they perhaps act as a semantic compression layer over the resource. Much of the clinically or operationally relevant meaning has already been distilled into a form designed for human consumption, whilst retaining a clear relationship with the underlying structured representation.
This made them a natural bridge between machine-readable interoperability standards and natural language processing techniques.
Rather than generating semantic representations directly from raw data model or complex FHIR JSON structures, we used the FHIR narratives themselves as the foundation. Every semantic representation therefore maintained a clear lineage back to a structured and governed source, whilst providing a representation far better suited to semantic retrieval and similarity search.
Conceptually, the progression looked something like this:
flowchart LR
subgraph SD[Structured Data]
direction TB
A(Operational Data Standard) --> B(FHIR R4)
B --> C(Narrative Representation)
end
subgraph SEM[Semantic Layer]
direction TB
D(Embeddings) --> E(Vector Store)
E --> F(Semantic Representation)
end
C --> D
classDef base fill:#437c9f,stroke:#2f5f79,color:#ffffff,stroke-width:1px;
classDef highlight fill:#6dc067,stroke:#437c9f,color:#1f2d1f,stroke-width:1.2px;
classDef group fill:#ffffff,stroke:#437c9f,color:#2f5f79,stroke-width:1px;
class A,B,C,D,E base;
class F highlight;
class SD,SEM group;
style SD rx:10,ry:10
style SEM rx:10,ry:10
linkStyle default stroke:#437c9f,stroke-width:1.2px;
FHIR remained the source of truth throughout. The semantic layer simply provided another way of discovering and relating information already contained within the platform.
There is, however, an important caveat. Meaningful FHIR narratives do not simply appear by magic. Whilst the FHIR specification provides a place for human-readable narrative through the text.div element, generating high-quality narratives that accurately reflect the underlying structured data requires deliberate implementation effort.
In our case, creating useful narrative representations formed an important part of the architecture. The quality of the semantic layer depended heavily on the quality of the narratives from which it was derived. Fortunately, there are libraries and tooling options that exist to support narrative generation, reducing the amount of custom development required. Even so, producing narratives that are both faithful to the source data and useful for semantic processing should not be viewed as a free capability.
As with many aspects of interoperability, the standard provides the framework. Realising its full value still requires thoughtful implementation.
Embeddings are really about proximity
Embeddings convert text into numerical representations known as vectors. Whilst technically accurate, that description does not immediately explain why they are useful.
A better way of thinking about embeddings is to imagine a vast library organised by meaning rather than alphabetical order. Books discussing similar subjects naturally end up on neighbouring shelves, even when their titles use very different language.
The same principle applies within a vector space.
Terms such as “reduced appetite”, “poor oral intake” and “missed meals” may use different wording, but they often describe very similar underlying observations. Their vectors therefore tend to occupy similar positions because the underlying meaning is similar.
This is what makes embeddings powerful. They allow systems to retrieve information based on semantic similarity rather than exact matches.
In health and care settings, where the same concept may be described in many different ways, this capability becomes particularly valuable.
The challenge nobody talks about: chunking
When people discuss semantic architectures, the conversation often focuses on embeddings, vector databases and language models. In practice, one of the more interesting challenges we encountered was deciding what should actually be embedded in the first place.
This is where chunking becomes important.
The concept sounds deceptively simple. Before content can be embedded and stored within a vector index, it first needs to be divided into manageable pieces. The question is how large those pieces should be and, perhaps more importantly, where their boundaries should sit.
The answer has a significant impact on retrieval quality.
Larger chunks provide rich context and preserve the relationships between observations, events and narrative descriptions. However, they can also dilute meaning. An embedding generated from a large section of text may become a broad representation of several concepts rather than a precise representation of any one concept.
Smaller chunks create the opposite effect. Retrieval can become much more precise, but at the cost of context. Information that is meaningful when read as part of a wider narrative can become fragmented when broken into smaller sections, making it harder to understand how individual observations relate to one another.
This proved particularly relevant when working with care information. A behavioural change, an eating pattern or a triggering event rarely exists in isolation. The significance of an observation often depends on what happened before it, what happened afterwards and the wider circumstances in which it was recorded. In many cases, context was every bit as important as the observation itself.
One of the more surprising lessons from the project was that chunking felt far more like an information architecture problem than a machine learning problem. The challenge was not simply dividing content into smaller pieces. It was finding a way to preserve meaning, narrative flow and contextual relationships whilst still enabling effective retrieval.
As with many aspects of information architecture, there was no universally correct answer. The optimal approach depended on the nature of the data, the questions being asked and the outcomes we were trying to support. Finding that balance took considerably more thought, experimentation and iteration than we had initially anticipated.
Retrieval matters more than generation
When AI is discussed, the conversation often begins with the language model. Which model should we use? How accurate is it? How many parameters does it have?
During the project, we found ourselves asking a slightly different question: How does the model know which information it should use in the first place?
For all their capabilities, language models can only work with the information available to them at the moment a question is asked. In health and care environments, that creates an obvious challenge. Information changes continuously. New observations are recorded, risks evolve, assessments are updated and circumstances change over time. Relying solely on a model’s training data would clearly be insufficient.
What ultimately matters is not what the model knew when it was trained. What matters is whether it can find the right information when it needs it. This is where Retrieval Augmented Generation (RAG) becomes interesting.
At its heart, RAG is a relatively simple architectural pattern. Rather than expecting a language model to answer a question using only its pre-trained knowledge, relevant information is first retrieved from authoritative sources. That retrieved context is then supplied to the model, allowing it to generate a response grounded in current information.
Conceptually, the process looks something like this:
flowchart LR
A(User Question) --> B(Semantic Retrieval)
B --> C(Relevant Context)
C --> D(FHIR Repository)
D --> E(Language Model)
E --> F(Response)
classDef base fill:#437c9f,stroke:#2f5f79,color:#ffffff,stroke-width:1px;
classDef highlight fill:#6dc067,stroke:#437c9f,color:#1f2d1f,stroke-width:1.2px;
class A,B,C,D,E base;
class F highlight;
linkStyle default stroke:#437c9f,stroke-width:1.2px;
One of the reasons RAG has become so popular is that it allows organisations to keep the source of truth entirely outside the language model itself. The model does not hold the data. It does not become the repository and it does not replace existing systems. Instead, relevant information is retrieved from authoritative sources when required and supplied to the model as context. This means that operational systems remain the source of truth, whilst responses can be grounded in current information, traced back to source records and regenerated as the underlying data changes.
For us, the semantic layer became a critical part of that retrieval process. Traditional search approaches often depend on exact matches, predefined queries or carefully curated business rules. The semantic layer enabled something different. Questions, observations, risk descriptions and narratives could all be represented within the same semantic space, making it possible to retrieve information based on meaning rather than specific wording.
In effect, the semantic layer became the bridge between structured interoperability data and AI. It transformed retrieval from a purely technical search problem into a semantic one.
Perhaps the most surprising lesson was how often retrieval quality mattered more than model sophistication. It is tempting to focus on the latest language model, but even the most capable model will struggle if it is provided with incomplete, irrelevant or misleading context. Conversely, a relatively modest model supplied with accurate and relevant information can often produce remarkably useful results.
Looking back, the difficult part was rarely generating an answer. The difficult part was finding the right context from which that answer could be generated.
From RAG to agents
The emergence of Agentic AI introduces another interesting evolution in this architecture. Whilst RAG focuses on retrieving information and generating responses, agents introduce planning, orchestration and decision-making capabilities.
The term agent is often used quite loosely, but it can be helpful to think of an agent as an AI-driven process that uses tools to achieve a particular objective. Rather than simply answering a question, an agent can break a task down into a series of steps, determine which information sources are required, retrieve relevant context, perform additional analysis and then synthesise the results into a final response.
Viewed this way, agents behave less like search interfaces and more like digital co-ordinators. Their role is not simply to retrieve information, but to orchestrate interactions between information sources, retrieval mechanisms and language models in order to achieve a desired outcome.
This becomes particularly interesting when viewed through an architectural lens. Agents are not replacing information systems, nor are they becoming systems of record. Instead, they sit above existing capabilities, co-ordinating the flow of information between them. In many respects they resemble another integration layer, albeit one capable of reasoning about the task it is trying to complete.
The semantic layer therefore becomes even more important. Agents still need reliable mechanisms for discovering information, preserving context and grounding their actions in authoritative sources. Without those foundations, the quality of the agent’s output is limited by the quality of the information it can access.
This brings us back to a familiar theme. Whether the consumer is a search interface, a language model or an agent, success ultimately depends on retrieval. An agent without effective retrieval is largely guessing. An agent with access to relevant, trustworthy context is able to reason over information that is grounded in the underlying data.
An example agent workflow
Consider a question such as: “Are there any emerging concerns for this individual over the last four weeks?”
An agent might begin by identifying the subject of the query before retrieving semantically relevant Observation data. It may then retrieve related Risk data, review historical information, identify recurring patterns and assemble the resulting context into a coherent view of the available evidence. Only then does the language model become involved in generating a response.
Conceptually, the workflow might look like this:
flowchart LR
A(User Question) --> B(Agent)
B --> C(Retrieve Data)
C --> D(Identify Relevant Patterns)
D --> E(Review Historical Context)
E --> F(Assemble Evidence)
F --> G(Generate Response)
classDef base fill:#437c9f,stroke:#2f5f79,color:#ffffff,stroke-width:1px;
classDef highlight fill:#6dc067,stroke:#437c9f,color:#1f2d1f,stroke-width:1.2px;
class A,B,C,D,E,F base;
class G highlight;
linkStyle default stroke:#437c9f,stroke-width:1.2px;
The important point is that the language model is only one component within a broader workflow. The outcome depends just as heavily on retrieval, orchestration, information architecture and context management as it does on AI.
Risk stratification as a practical example
This became particularly apparent during work on a proof-of-concept risk stratification capability.
Risk records contained authored professional knowledge describing indicators, triggers and behavioural changes. Observation data contained records of what had actually occurred.
Both were represented within the same semantic space.
Risk descriptions became semantic representations of authored professional knowledge, whilst Observation records became semantic representations of recorded events. This allowed observations to be compared against known indicators based on meaning rather than exact wording.
The proof-of-concept Risk Stratification System was therefore able to surface patterns, clusters and alignments that might otherwise have remained difficult to identify using conventional reporting approaches.
Importantly, the proof-of-concept Risk Stratification System was not attempting to diagnose conditions or predict outcomes. It was identifying relationships within the available information and presenting those relationships in a structured and traceable manner.
Professional judgement remained central throughout.
AI is an interface, not an architecture
Perhaps the most important lesson from the work was that AI itself was rarely the most difficult part of the solution.
The harder challenges were architectural. How should information be represented? How should meaning be preserved? How should context be maintained? How should provenance be retained? And, perhaps most importantly, how should information be retrieved in a way that remains both useful and trustworthy?
What struck me was that these are not new questions. They are the same questions interoperability specialists, information architects and integration engineers have been wrestling with for years. The technologies may have changed, but the underlying challenges feel remarkably familiar.
Viewed through that lens, AI begins to look less like a revolutionary new architecture and more like another consumer of information. Traditional systems consume APIs, databases and messages. AI systems consume context. The fundamental requirement is the same: information must be represented, organised and exposed in a way that allows it to be consumed safely and effectively.
That context still has to come from somewhere. In our case, FHIR remained the source of truth, the semantic layer provided a representation of meaning, and retrieval provided the mechanism for assembling relevant context at the point it was needed. The language model sat on top of that architecture, acting as a natural language interface rather than the centre of the solution itself.
For me, that was perhaps the most interesting lesson from the project. The success of the AI capabilities owed far less to the language model than to the information architecture surrounding it. The real challenge was not teaching AI how to generate an answer. It was ensuring that the answer could be grounded in meaningful, relevant and traceable information.
Ultimately, that feels much closer to an engineering problem than an AI problem.
The data used in the project to which this article relates was sourced exclusively from datasets that are known or assured to be synthetic, or have been intentionally created for illustrative purposes. The AI Risk Stratification System described is a proof-of-concept, has never been used in any real-life scenarios and was created solely to demonstrate the concepts described in the article.
