We started by trying to solve one problem: semantic search across clinical data. We ended up building the semantic foundation for ontology-driven clinical applications.

Initially, we used SKOS to represent and harmonise medical terminologies. As the project evolved, we expanded beyond terminology management by introducing domain and application ontologies capable of describing clinical concepts, data relationships, and application behaviour.

As we began storing and governing the terminology knowledge, we realised the same semantic foundation could support much more than search. The project also required additional information to represent business rules and application logic, which extended beyond terminology harmonisation alone. That naturally shifted the project toward a broader ontology-based approach capable of connecting clinical concepts, coding systems, application data, and business behaviour within a shared semantic model.

We also discovered that managing a growing clinical knowledge graph required an interface that domain experts could use to navigate and maintain concepts and relationships safely.

Why clinical search needs meaning, not just matching words

Consider a seemingly simple request:

Find all patients diagnosed with head and neck cancer during the past three years.

Clinical records may contain diagnoses such as “salivary gland cancer,” “laryngeal cancer,” “oropharyngeal cancer”, or more specific forms of tongue cancer. Depending on the governed cohort definition, all of these may belong to the requested clinical category. The same condition may also be recorded using different synonyms, abbreviations, languages, or coding systems.

A conventional database can filter records by date, but it cannot determine which coded diagnoses belong to the requested clinical category unless those relationships have already been modelled. A terminology graph provides the clinical hierarchy and mappings, while the application data model connects those concepts to patients, diagnosis events, and dates.

The same limitation applies to text search. Matching words is not the same as understanding clinical meaning.

Connecting clinical terminologies

Healthcare standards help address this problem, but each serves a different purpose. ICD provides an international classification for recording and reporting diseases. SNOMED CT offers a more detailed clinical terminology designed to represent information captured during patient care. Mondo brings together disease concepts and mappings from multiple sources and is particularly valuable in research and rare disease contexts.

In addition to the concepts themselves, the platform preserves terminology versions, source provenance, mapping status, and applicable licensing information, allowing the knowledge used by the system to remain traceable.

The objective is not necessarily to use every available terminology. It is to select the relevant ones and create governed mappings between concept schemes, distinguishing exact, close, broader, narrower, and related mappings, together with synonyms, preferred labels, and translations.

Clinical concepts do not always map one-to-one

The mapping itself is often more complex than connecting identical concepts across coding systems. For example, SNOMED CT may represent Type 2 diabetes mellitus with diabetic nephropathy as a single clinical concept, while another terminology separates diabetes and the kidney complication into individual concepts, or only provides a broader diabetes with complications category. Resolving these differences requires clinically reviewed mappings rather than simple one-to-one relationships.

Building the semantic foundation

SKOS provided the foundation for harmonising medical terminologies and representing governed relationships between concept schemes. Those relationships were represented as RDF triples within a larger clinical knowledge graph, where they could be queried through SPARQL and reused by downstream applications.

From clinical meaning to search results

When a user searches for a broader clinical concept, the system can expand the query to include relevant narrower concepts, synonyms, translations and mapped codes. Combined with the application data model, this allows the system to identify the corresponding clinical records and produce more complete and explainable results than literal text matching alone.



Making clinical knowledge manageable

The technical model was only part of the challenge.A clinical knowledge graph can contain thousands of concepts, mappings, synonyms, translations and hierarchical relationships. Managing this information directly through RDF files or database interfaces is impractical for most domain experts.

A suitable interface must help users understand the structure of the knowledge graph, navigate relationships, identify incomplete or conflicting mappings, review proposed changes and safely maintain the model over time.

To address this, we built a knowledge management platform that gives authorised users a clearer way to explore and maintain concepts and relationships, while supporting the governance required for clinically meaningful knowledge.

From semantic search to ontology-driven applications

As the project evolved, we began modelling selected parts of the application using ontologies. For example, a module used by a physician to record ultrasound findings can be described through a machine-readable model defining the required clinical concepts, fields, permissible values and relationships.

The semantic model, together with validation constraints and presentation metadata, can be interpreted by the application to configure forms and guide data capture. Because captured information is linked to governed clinical concepts from the outset, it becomes available for semantic search without requiring a separate retrospective terminology mapping step.

Using the semantic model during data capture

This creates an important shift. The ontology is no longer used only to interpret data after it has been recorded. Together with validation constraints and presentation metadata, it also helps shape how data is captured by determining which fields are presented, which values are permitted and how the captured information is connected to governed clinical concepts.

The result is a foundation that can support semantic search, multilingual terminology management, standardised data capture, interoperability and faster development of new clinical modules, all based on the same shared clinical meaning.



What we would do differently today

One of the biggest lessons from the project was that structured knowledge, represented in a knowledge graph and connected through ontologies, can support far more than semantic search. The same semantic foundation can support structured data capture, validation, selected business rules and parts of application behaviour. Looking back, we would design the knowledge graph from the beginning as a shared foundation for both search and ontology-driven applications, rather than treating it as a search-specific component.