As of June 2026, I am now the Interim Chief Executive Officer of IHRIM — the Institute of Health Records and Information Management. I am no stranger to IHRIM, having been a member for 14 years, seven of which I spent serving as Associate Director of Education between 2016 and 2023. Stepping into this new role feels like both a homecoming and a significant increase in responsibilities. I am grateful to the board for trusting me to take the reins after more than 10 years under the previous chief executive.

The role brings with it two further appointments: National Director for IFHIMA — the International Federation of Health Information Management Associations — and a position on the CIC board of FEDIP, the Federation for Informatics Professionals. Both roles present an opportunity to extend beyond IHRIM’s membership to the wider informatics profession and to international audiences.

IHRIM represents records managers, clinical coders, data quality teams, and information governance professionals at a moment when the NHS depends on these skills to realise its digital ambitions. Readers of this blog will know that I have argued that standards, interoperability, and well-governed patient data are not peripheral to healthcare but central to it. They form the foundation on which everything else is built.

In addition to these new responsibilities, there is another appointment I am particularly excited about. On behalf of my day job, I am beginning as a Liaison Representative to ISO/TC 215 — Health Informatics. ISO/TC 215 is the international technical committee responsible for standardisation in health informatics, facilitating the capture, exchange, and use of health-related data across the healthcare system. For someone whose work has always centred on clinical terminology and interoperability, contributing at this level is a genuine privilege. I am just at the start of my ISO journey, but I am sure it will generate many interesting discussions.

Alongside all of this, I am working towards (finally) submitting my application for FEDIP Leading Practitioner. Progressing from Advanced Practitioner after more than six years on the register at this level is a little daunting, but if not now, then when?

None of this happens by accident, and while the imposter syndrome is real, I am grateful for these opportunities. I am indebted to my colleagues, managers, mentors, and the broader community who have shaped my thinking, taught me how to love health informatics, and, crucially, have faith in me to perform well in these roles. As always, there is still so much more work to do, but I look forward to the challenge and will be happy if I can move the dial forward, even if only by a little bit.

Best wishes,

Michael

“While a SNOMED code may appear to a researcher as a data point, to an individual, it may represent a diagnosis that changed their life, the loss of a loved one, or a condition never disclosed to family”

This line from the HDRS Digital Ecosystem Analysis report stood out to me. The independent technology review was published today. Commissioned by Wellcome and authored by members of the Emrys Health consortium, it focuses on health data ethics. Importantly, it underscores a key point long recognised by terminologists: the granularity and accuracy of clinical coding have a profound human impact beyond mere technical details.

The report is well-constructed and contains actionable recommendations. However, while it acknowledges unresolved vocabulary issues, it does not fully convey the depth of terminological expertise and the long-term effort required to address them.

Vocabulary As Critical Infrastructure

The report rigorously analyses the UK’s health data research infrastructure, examining systems, platforms, and data assets from patient encounters to research outcomes. It outlines six layers: source systems, source data processing, data assets, asset integration, researcher access, and service provision. Importantly, vocabularies serve as a key asset overlaying these layers, as they are required for federated analytics and consistent interpretation.

Although SNOMED CT became the mandatory clinical terminology for the NHS in England in 2018, the HDRS analysis here reveals an unexpected technological gap:

“Standard vocabularies (dm+d, SNOMED CT subsets) are applied variably and rarely present in source data.”

This lack of consistent terminology is critical because achieving HDRS’s goal of federated analytics requires semantic consistency across all nodes. While SNOMED CT is standard in primary care, secondary care institutions largely use ICD-10 and OPCS-4, which are designed primarily for statistical and payment purposes rather than clinical detail. These codes are often applied retrospectively, rather than during patient encounters, resulting in fewer than 7% of national outpatient records including diagnosis codes. This highlights a significant gap in consistent coding that must be addressed for to improve data completeness.

Using varied vocabularies forces researchers into complex negotiations when working across cohorts. The issue persists and is harder to detect after federation. The report cites pathology results often returned in formats incompatible with native data models and stored as text. Without consistent SNOMED CT or LOINC codes for lab data, NLP extraction becomes the only option, increasing the risk of provenance issues for regulatory-grade evidence.

The OMOP Question

Turning to data harmonisation, the OMOP CDM is a common data model gaining traction. This shift is encouraging. OMOP establishes a unified analytical framework. It allows varied datasets to communicate through a shared language—the standardised vocabularies—for research purposes.

UK researchers face a core challenge due to OMOP’s US-focused vocabulary structure: it uses RxNorm rather than dm+d and prioritises OHDSI SNOMED extensions over the UK’s Clinical Extension. These differences make mapping UK-specific data—such as dm+d drug codes, local SNOMED subsets, and NHS Data Dictionary entries—difficult because direct mappings are often missing or incomplete. Achieving alignment with OMOP vocabularies requires ongoing creation of custom mappings, resolution of ambiguous correspondences, and repeated validation against both OMOP and UK source standards. This work is complex and demands ongoing input from technical and terminology experts.

This is not meant as a criticism of OMOP, which provides essential infrastructure. However, OMOP is not an off-the-shelf, ready harmonisation fix. Deep terminological work is required beforehand to correctly configure the pipeline and ensure the quality of its vocabulary mappings in national contexts.

NLP, LLMs, and the Provenance Problem

A central technology gap is the abundance of important data in unstructured formats, like clinical notes and letters. LLM extraction and NLP are suggested remedies.

While NLP and LLM tools are promising, the report does not sufficiently address the critical risk: machine-extracted SNOMED CT concepts differ fundamentally in provenance from those recorded by clinicians. Clinician-recorded assertions are direct observations, while machine-generated ones are probabilistic inferences. Treating both types of data equally in regulatory settings could lead to serious errors. Recognising this difference is essential to responsible terminology governance.

Terminology governance must do more than select concepts; it must also track how they’re asserted. This is essential, not optional.

Filling in the Gaps

The HDRS report identifies minimum information standards as the main approach to achieving research-ready data assets. Although this is logical, these standards currently address structure rather than meaning. For effectiveness, the standards must specify not only data fields like ‘diagnosis code’ but also define mandatory vocabulary standards, versions, and value set constraints. Otherwise, semantic interoperability could be undermined by the use of inexact or inconsistent coding.

Vocabulary management is a moving target: clinical terminologies are updated as concepts, hierarchies, and descriptions change. Any mapping or value set risks becoming outdated over time. This constant evolution requires continuous governance, with trained terminologists who can interpret clinical intent behind every code change.

From Infrastructure to Meaning

The HDRS report makes a strong case for seeing health data research infrastructure as a coordinated public good, a view that is vital for informatics professionals.

Robust vocabulary governance must be included in any true research infrastructure. The report’s six-layer model will only succeed if its vocabulary layer receives equal focus with compute, access, and governance. Otherwise, a Trusted Research Environment lacking precise terminology remains only superficially ready for research, comparable to a locked cabinet holding ambiguously labelled contents.

Although the report correctly emphasises the human origins of data, we must also acknowledge our responsibility for maintaining semantic clarity. Precisely coded data, ongoing governance, and careful mapping honour the individuals represented. Infrastructure programmes must explicitly recognise and support this ongoing obligation.

The HDRS Digital Ecosystem Analysis is available via Wellcome. Anyone involved in health data research, terminology, or informatics should read it in full.

Author: Michael Harwood-Jones AdvFEDIP FHRIM MBCS

Michael is a specialist in controlled clinical vocabularies with almost two decades of experience in health classification, terminology, and information standards. His background includes roles in hospital administration, informatics, internal audit, education, and standards development.

Share

This briefing for Health Information Management (HIM) professionals stresses that the SPR is primarily a challenge of trust and governance, not technology. Key concerns that arose from previous efforts included the potential for commercial exploitation, critiques that pseudononymisation was insufficient to protect patient privacy, a lack of transparency, and the use of opt-out rather than opt-in consent. The culmination of these failures was severe erosion of both public and professional trust.

To avoid repeating past failures, the SPR must resolve critical issues such as the ambiguous legislative framework for secondary uses, the unresolved question of data controllership, and the absence of a robust "trust framework layer" to govern data use, correction, and deletion across systems.

Successful implementation by the 2028 target requires deep engagement by health information management professionals to develop the knowledge and skills necessary to facilitate, as well as challenge, the development of the SPR at the technical and legislative levels, ensuring that patient records are accurately maintained and securely stored.

Legislative Changes: What’s New?

The NHS Modernisation Bill, announced in the King’s Speech on 13 May 2026, introduces a formal legislative framework for a national Single Patient Record (SPR) in England. The proposed legislation gives the Secretary of State authority to establish and operate the SPR through statutory regulations, including the power to enforce financial penalties for non-compliant organisations. The legislation does not create new powers for secondary uses, such as research, planning, and AI development. These must continue to rely on existing legal gateways.

Rather than replacing existing systems, the SPR will consolidate information from Summary Care Records, Shared Care Records, and Electronic Patient Records. The architecture aims to scale locally led integration to the national level.

The NHS has been exploring and safely testing three primary technical models alongside existing shared care record suppliers:

• Shared Care Record – hub-and-spoke: This model links existing regional shared care records through a central application programming interface (API).

• Central integration model: A centrally managed data store that connects to multiple care settings across the NHS.

• Virtual data layer: A background orchestration layer that connects existing health systems to provide a unified, joined-up view for users without centrally storing the data.

Industry perspectives strongly advocate for a federated or hybrid model that builds on existing local Shared Care Records, rather than attempting a highly disruptive “greenfield” centralised replacement. Experts suggest utilising open standards (such as openEHR and HL7 FHIR) and establishing an open platform with a Clinical Data Repository (CDR) to unify and govern data independently of specific vendor systems.

Ming Tang, interim chief digital and information officer at NHS England, has said that the SPR will not store data in a single centralised repository, instead describing it as “a set of Lego bricks” that will connect different systems. This is a significant qualification to the programme’s branding that carries real technical and governance implications. The patient record may be singular in name, but it will be distributed by design.

Patients are expected to begin accessing their records through the NHS App in 2028, though many aspects of patient control—what they will see, how errors are corrected, and how proxy access works—remain unresolved.

The Trust Problem is the Central Problem

The new legislation focuses on improving direct patient care; however, success will depend on addressing ongoing concerns about data governance, confidentiality, and accountability.

The SPR is not purely a technology project. While data sharing can promote the common good, the tension between the technical benefits of centralised health data and the ethical need to maintain patient consent must be balanced. Previous attempts to centralise patient data within the NHS have faced controversies over protecting individual autonomy from commercial exploitation.

The failed care.data scheme and its successor, General Practice Data for Planning and Research (GPDPR), both faced backlash from the public and professionals, not because the technology was undeliverable, but because trust was not established and stakeholder engagement lagged behind technical ambition. care.data used an opt-out rather than opt-in consent model, and transparency about data flows was insufficient. The much-maligned National Project for IT (NPfIT) demonstrated the same pattern — build first, ask for confidence later — at far greater cost. The SPR risks repeating it. Legislation can mandate powers, but it cannot manufacture confidence.

The central challenge is not what the SPR can do technically, but whether it can earn and maintain trust, accountability, and effective governance. GPs want clarity on confidentiality, controllership, and liability before engaging. Research from Understanding Patient Data, published in May 2025, found that 61% of the public believes a single patient record already exists. That figure suggests the gap between public expectations and clinical reality has never been properly bridged.

The Trust Framework Layer

Charles McCay, an information standards architect and advisor to the Professional Record Standards Body (PRSB), has identified a structural gap in current discussions about the SPR. Responding to linked work on health and care data integration, he observed that a “Single Patient Record” has “charming simplicity” — but that there needs to be “a layer of trust frameworks above that which describe how and why the information will be used, how it will be protected and shared, and what the options are for correction/deletion.” The key question he raises is: who can make changes or deletions, how do they propagate, and will the data be removed from every downstream score and vector database?

Legal records and banking risk scores have long grappled with what happens to personal data once it enters a system—who can amend it, remove it, and how deletions propagate. The NHS equivalent is more complex. When a record is “deleted” from an SPR, will it be removed from every downstream store, analytics pipeline, and vector database where it may have been embedded for AI inference? These are not hypothetical concerns. AI systems, especially those using embeddings and semantic search, often ingest clinical records in ways that do not allow clean deletion. A patient exercising their right to erasure under GDPR may find the information has left traceable footprints in systems without preserved provenance. Once clinical data is ingested into an AI model, the assumption that it can be cleanly separated from the direct care record is technically questionable.

Possible solutions include:

• IHE XDS Collaboration Agreements provide a framework for governing document sharing across institutional boundaries — establishing who may access what, under what conditions, and with what audit obligations.

• W3C Verifiable Credentials offer a cryptographic mechanism for attaching machine-readable trust assertions to data: who issued it, what consent was given, and under what conditions it may be used.

Neither is a complete answer on its own, but both are more mature than the current NHS conversation. These questions require urgent attention because once the system architecture is set, retrofitting governance will be more difficult.

Data Controllership and Governance

Data controllership is the most significant unresolved legal question facing the programme. Currently, GP practices are data controllers for their patients’ records. Once data enters the SPR, that responsibility must be allocated, but none of the proposed models specifies how to do so. Three options are under consideration:

• joint controllership between NHS England or its successor within the Department of Health and Social Care (DHSC) and local providers

• a centralised, single national controller

• or a federated governance structure that maintains local accountability under national standards and mutual audit.

The timing is complicated by the planned abolition of NHS England and transfer of many data and technology functions to DHSC. Centralising control of NHS data within government, rather than at arm’s length, raises concerns about data sovereignty, the concentration of power, and dependence on major technology suppliers. Independent governance scrutiny is not a nice-to-have here. It is a precondition for professional and public trust.

In April 2026, the British Medical Association (BMA) called for GPs to retain control of SPR data, reflecting these anxieties. GPs are not obstructing progress. They are insisting on clarity that has not been provided. The relationship between the SPR and the Federated Data Platform (FDP) adds a further layer of unresolved complexity: the FDP was designed for population analytics; the SPR is a live clinical record. These are different use cases with different latency, accuracy, and governance requirements.

Clinical Engagement and Professional Resistance

The NPfIT experience showed what happens when technical execution outpaces stakeholder engagement and semantic governance: a technically deployable system clinicians do not trust and therefore do not use. Staff uncertain about what the record contains, how it was assembled, or their legal responsibilities will default to caution, which means falling back on the fragmentation the SPR aims to address.

If GPs are not satisfied that safeguards and operational support are sufficient, national implementation will not happen. Not due to formal refusal, but because the system will not function as intended when clinicians do not trust the data or governance mechanisms.

The BMA has noted that effective implementation depends not only on technology but also on organisational and cultural factors: clinical leadership, sustained investment, workforce support, and workflow redesign. Supporting the workforce means providing practical help to frontline staff as they adapt to new systems, including dedicated training on SPR usage, ongoing digital literacy support, structured change management, and accessible technical helpdesks.

Workforce Requirements and Digital Upskilling

The SPR demands a fundamentally different relationship with data from every clinician who uses it. At a minimum, frontline staff need to understand what the record contains, how it was derived, where it may be incomplete or inaccurate, and their responsibilities when acting on it. That is a data literacy requirement — not a software training requirement. The distinction matters. Training people to navigate an interface is far simpler than equipping them to critically appraise information assembled algorithmically from multiple sources, each with its own coding practices, data quality characteristics, and governance history.

More specifically, the health information management professionals need to build key capabilities and make operational shifts across five core skill areas.

1. Digital confidence and AI literacy

The workforce must understand how to use new technologies. The 10 Year Health Plan emphasises that technological advancements are useless if the workforce lacks the training and access to use them properly.

2. Knowledge of health data standards

Support for real-time or event-driven data exchange will depend on timely, reliable data flows and standards-based approaches. Sufficient knowledge of standards, such as HL7 FHIR, SNOMED CT, and openEHR, will be essential to engage meaningfully with procurement, implementation design, and data quality assurance. This includes understanding semantic interoperability and the need for data to be comparable across systems. Terminology is particularly important here. An SPR not coded consistently—allowing free text where structured data should exist and lacking proper SNOMED CT coverage across care settings—will present a disconnected picture disguised as a unified one. The semantic governance failure of NPfIT was structural, not incidental.

3. Operational workflow integration

The SPR must be embedded in real-world clinical workflows reliably, without creating additional administrative burdens. This requires a workforce capable of maintaining high data quality so that clinicians can trust the information they see.

4. Cross-boundary information governance

Often cited as the rate-limiting step, the workforce must navigate and manage complex cross-boundary information governance. Fluency in information governance and data protection legislation, such as GDPR and the Data Protection Act 2018, will be essential to understanding the specific legal gateways governing patient access and secondary use.

5. Change management and system innovation

Health information managers will need to develop strong leadership, workflow redesign, and change management capabilities to translate all of this into successful delivery.

The question is whether the programme will be resourced to deliver them and whether workforce development will be treated as a genuine precondition rather than a parallel workstream that slips when budgets are tight.

Scope Creep and the Secondary Use Risk

The government’s explicit delimitation — that the SPR legislation creates no new powers for secondary uses — is welcome, but insufficient on its own. The SPR will be one of the most comprehensive linked datasets about the English population ever assembled. Pressure to use it for planning, research, and AI development will be intense and come from directions that are hard to resist. The boundary is easier to draw in statute than to maintain in practice.

Historical resistance to programmes like care.data was not irrational. It reflected a well-founded concern that the boundary between direct care and broader data use was managed opaquely and without meaningful patient agency. The ongoing blurring between these purposes risks distracting from and ultimately undermining the SPR’s primary aim.

International Evidence

Denmark and Estonia offer the most instructive comparators. Both maintain meaningful patient control, including granular consent management and accessible correction workflows, while preserving mandatory data flows for direct care. Neither sacrifices care coordination for privacy, nor privacy for efficiency. Transparent access logs, clear dispute pathways, and preserved emergency access are features of both systems. They show that the perceived trade-off between patient agency and clinical utility is largely a design problem rather than an inherent tension.

Conclusions

The SPR’s viability depends on three things being addressed before the architecture is finalised. Governance of how information is used, protected, shared, corrected, and deleted across all systems must be designed in parallel with the technical infrastructure, not retrofitted afterwards. Data controllership must be clearly defined and set out in statute, not left to secondary regulations whose content is yet to be determined. Finally, the workforce — clinical and administrative — must be active participants in designing a system they will actually use and trust.

The 2028 timeline is tight. Delivery and trust-building will be more demanding than passing the legislation itself. The informatics community — terminologists, standards specialists, and clinical informaticists — has a specific and substantive contribution to make across all three areas. That contribution needs to be articulated clearly within the current policy window, whilst the architecture remains open and the governance frameworks are still being written.

Author: Michael Harwood-Jones AdvFEDIP FHRIM MBCS

Michael is a specialist in controlled clinical vocabularies with almost two decades of experience in health classification, terminology, and information standards. His background includes roles in hospital administration, informatics, internal audit, education, and standards development.

Subscribe now

The Problem Meaning

Pneumonia is a common medical diagnosis, causing almost 600K hospital admissions in England alone during the 2024–25 FY. Most people have heard of it and have a general understanding, even if not detailed knowledge. The OED defines pneumonia as “Inflammation of the parenchyma of the lung, esp. of infectious (chiefly bacterial or viral) origin”. Simple, right? However, a 2017 study by Priya Daniel et al., published in the BMJ, found that more than half of patients clinically coded as community-acquired pneumonia (CAP) were misdiagnosed due to differences in how clinicians use that term.

Patients seen by non-respiratory specialists were often labelled with pneumonia despite not fulfilling all the criteria for this diagnosis, as applied by more specialist chest physicians. This is a real-world illustration of how terms can shift meaning across contexts.

Terminology has always struggled with shared meaning. Two clinicians using the same word in subtly different ways is not trivial. This ambiguity is not merely linguistic; it is structural. In modern healthcare systems, where health information is recorded and shared in massive digital infrastructures, that ambiguity scales.

The goal of semantic interoperability is to ensure systems do not merely exchange data but genuinely understand one another. It has driven decades of biomedical informatics research. Clinical terminologies have, in different ways, tried to provide a shared, stable meaning for clinical concepts. But a list of terms, however comprehensive, does not provide shared definitional meaning in any useful sense. Terms need structured, computable definitions. For example, computable phenotype definitions support reproducible queries of EHR data from multiple systems and can be replicated consistently and at scale. Not only is this more efficient than manual processing, but it also ensures that the identified populations share similar features, which is crucial for clinical quality measurement, health improvement, and research.

Enter Description Logics.

What Are Description Logics?

Description Logics (DLs) are a family of logic-based knowledge representation languages. They first emerged in the 1980s from research aimed at developing expressive yet decidable logics based on First-Order Logic (FOL).

DLs are decidable fragments of first-order logic, equipped with a formal, logic-based semantics. They are designed to represent the terminological knowledge of an application domain in a structured, formally well-understood way by describing domain notions in terms of expressions built from atomic concepts and roles.

DLs are not simply notation. They carry a precise, unambiguous semantics that makes their content interpretable by both humans and machines. They are widely used in ontological modelling and serve as a primary underpinning of the Web Ontology Language (OWL), and their application to clinical terminology dates to systems such as GALEN in the early 1990s.

Why First-Order Logic Is Not Enough

First-order logic is the formal language of contemporary mathematics. It is highly expressive, capable of representing complex relationships, quantification over variables, and logical combinations of arbitrary depth. However, this expressivity comes at a cost. Once ternary relations (involving three or more entities simultaneously) are included, FOL becomes undecidable. This means algorithms cannot evaluate whether a statement is true or false in finite time. For knowledge representation systems performing automated inference, this limitation is a practical barrier.

Description Logics solve this problem by deliberately restricting FOL. The critical restriction is binary: DLs permit only binary relations—relationships between exactly two entities at a time. They also operate, by default, under an Open-World Assumption (OWA) and optionally reject the Unique Name Assumption (UNA). The result is a family of logics less expressive than full FOL, but that preserve decidability. This ensures that a reasoner terminates with an answer in finite time.

This deliberate trade-off is the heart of DL design: sacrificing expressivity to guarantee tractability. Different DL languages make this trade-off in slightly different ways, which is why DLs are a family of languages rather than a single formalism.

The Building Blocks

A DL knowledge base is constructed from three fundamental kinds of entities.

Concepts (also called classes) represent sets of individuals — all instances of a given category. For example, a concept for Lung disorder represents the set of all lung disorders; the concept Patient represents the set of all patients. In formal terms, concepts correspond to unary predicates: properties that apply to a single entity.

Roles (also called properties or attributes) represent binary relations between two entities. The role Finding site relates a clinical finding to the anatomical structure in which it occurs; the role Causative agent relates a disorder to the culprit organism or substance. Roles correspond to binary predicates.

Individual names represent specific, named instances within the domain — a particular patient named “John Smith”, or a specific clinical encounter with a known identifier. Individual names correspond to constants in logic.

From these three building blocks, complex expressions can be assembled using concept constructors.

Boolean constructors allow:

• Conjunction (intersection) — an individual must belong to concept A and concept B

• Disjunction (union) — an individual belongs to A or B.

• Negation (complement) — all individuals that are not A

Role restrictions allow statements about roles:

• Existential restriction states that some instance of a role has a specified value.

• Universal restriction states that all instances of a role have a specified value.

These are often expressed as “some” and “only”, respectively.

Together, these constructors allow a terminology author to express nuanced definitions. A headache can be formally defined as an ache in the head, using |Finding site|. Pneumococcal pneumonia is a pneumonia with |Causative agent| Streptococcus pneumoniae. These are not narrative descriptions. They are computable definitional statements.

Structuring Knowledge: TBox, ABox, and RBox

A DL knowledge base is customarily divided into three components, referred to as boxes.

The Terminological Box (TBox)

The TBox contains axioms that describe concepts and their relationships — the domain’s schema. TBox statements are universal: they apply to all instances of a concept. The statement “pneumonia is a lung disorder” is a TBox axiom. So is a full equivalence definition: “Pneumococcal pneumonia is equivalent to a pneumonia with a causative agent that is Streptococcus pneumoniae.” SNOMED CT’s defining relationships are TBox statements.

The Assertional Box (ABox)

The ABox contains axioms about specific, named individuals. “John Smith’s current problem is an instance of pneumonia” is an ABox statement. In SNOMED CT’s application as a reference terminology within patient records, the codes used to document a clinical encounter function as ABox statements: they assert that this particular clinical situation is an instance of the specified concept.

The Relational Box (RBox)

The RBox contains axioms about the roles themselves — role inclusions, role equivalences, transitivity declarations, and role chains. The statement that parentOf is a subrole of ancestorOf is an RBox axiom: every pair of individuals related by parentOf is also related by ancestorOf.

The TBox/ABox distinction maps roughly onto the schema/data distinction in relational databases — a useful analogy for orientation, though it should not be pushed too far.

The Open World Assumption

Perhaps the most important, and most frequently misunderstood, characteristic of DL systems is the Open World Assumption (OWA).

Traditional databases operate under a closed-world assumption: if a fact is not recorded, it is assumed to be false. For example, if no record of a patient’s blood pressure measurement exists, the system assumes the patient has none. The completeness of the record is taken for granted.

DL systems operate on the opposite assumption. If a statement is not explicitly false, it is treated as unknown rather than false. The OWA acknowledges that knowledge is typically incomplete.

A DL ontology does not describe a single, complete state of the world; it constrains which states are possible, whilst leaving many things unspecified. DL semantics consider all the possible situations (states of the world) where the axioms of an ontology would hold, and a logical consequence is an axiom that holds in all of those situations.

For clinical terminology, this is not an arbitrary design choice. It reflects clinical reality. The absence of a finding in a patient’s record does not mean the finding is absent in the patient. A missing result is not a normal result. The OWA is honest about what is known and unknown in a way that closed-world systems are not, and that honesty matters when systems make inferences about patient care.

Making Knowledge Computable

The power of Description Logics lies not in representational expressivity alone, but in the automated reasoning that expressivity supports. Modern DL reasoners — software systems such as HermiT, ELK, and FaCT++ — can evaluate DL knowledge bases and return correct answers in finite time. Three basic reasoning services are central.

Subsumption determines whether one concept is necessarily a subconcept of another — whether all instances of concept C are always instances of concept D. If pneumococcal pneumonia is defined as a type of pneumonia with a specific causative agent, the reasoner determines that it is both a type of pneumococcal infection and lung disorder, without either relationship being explicitly authored.

Instance checking determines whether a specific individual is necessarily an instance of a given concept, given the knowledge base’s axioms.

Consistency checking determines whether a knowledge base is non-contradictory — whether any possible state of the world could satisfy all its axioms simultaneously. An inconsistent knowledge base is one in which no such state exists. Every axiom holds trivially in a system with no possible models, which is precisely why inconsistency renders a knowledge base useless.

In practice, the most consequential reasoning service in SNOMED CT is auto-classification: the automatic assignment of concepts to their correct positions in the polyhierarchy based on logical definitions. Without auto-classification, maintaining SNOMED CT’s polyhierarchy of more than 350,000 active concepts, each with multiple direct parents, would require manually assigning every parent-child relationship. This would be infeasible and error-prone on a scale that would undermine the reliability of the terminology.

Description Logics in Practice: SNOMED CT

SNOMED CT is built on a DL foundation, specifically using a profile of OWL 2 known as OWL 2 EL. The EL profile is less expressive than the full OWL 2 DL specification. For example, it excludes disjunction and class negation, among other constructors. However, it offers substantially more efficient reasoning for large terminologies. ELK, the primary classifier used with SNOMED CT and accessed via a terminology server, achieves classification times measured in seconds for the full International Edition, where a more expressive reasoner might require hours.

SNOMED CT combines the OWA with the Unique Name Assumption (UNA): the default presumption that two things with different names must be distinct entities. The Fully Specified Name (FSN) is the description type that is unique across all concepts, implying that every active SNOMED CT concept represents an idea that differs from all other active concepts. This is a foundational requirement for a reference terminology that must be cited unambiguously across systems and jurisdictions.

Several DL features warrant attention in the context of SNOMED CT.

Concrete Domains

Concrete domains facilitate classification and relationship inference by allowing references to concrete objects, such as numbers, alongside predefined predicates for those objects.

The use of concrete domains in SNOMED CT provides a standardised method for incorporating concrete attribute values into components, resulting in several key advantages:

Formal definition of concepts within SNOMED CT that rely on concrete values

Sophisticated reasoning capabilities for concepts defined in part by concrete attributes

Enhanced machine accessibility to numeric data, aiding in both comparison and calculation

A more efficient computational approach to number representation compared to the use of individual concepts

Existential restriction

Existential restrictions (or existential quantification) is a logical constant which is interpreted as “there exists”, “there is at least one”, or “for some”. It is the role restriction used throughout SNOMED CT’s defining relationships. For example, a disorder with a |Finding site| of the femur is defined to involve some instance of the femur, not necessarily only the femur. All current SNOMED CT defining relationships use existential restriction.

Universal restriction — stating that all instances of a role have a specified value — is theoretically available within OWL 2 EL but is not currently used in concept authoring.

General Concept Inclusions (GCIs)

GCIs are the most general form of TBox axiom, allowing complex concept expressions on both sides of an inclusion.

GCIs in SNOMED CT support concepts with multiple non-sufficient partial definitions, such as traumatic or non-traumatic injury, where neither definition alone is sufficient to fully define the concept.

When authoring concepts, terminologists determine necessary conditions to identify a set of properties that sufficiently convey the meaning of the Fully Specified Name (FSN). Concepts are considered defined only if necessary conditions fully represent the FSN; otherwise, they are regarded as primitive. GCIs provide sufficient conditions without being necessary for every instance. This enables the refinement of broad concepts, such as secondary disorders, that are otherwise challenging to define using standard SNOMED CT attributes, and allows the classifier to identify subtypes based on sufficient conditions, even if those conditions are not universal across all instances.

Furthermore, GCIs permit the representation of disjunctive content within the OWL EL profile, bypassing its inherent expressive limitations. For instance, while a disorder like secondary osteoporosis may be caused by either a drug or a disease, current primitive definitions often lead to incomplete subconcepts. But using GCIs to represent such disjunctions, the classifier can automatically assign all subconcepts, improving the completeness of the taxonomy.

Transitive roles

Transitive properties are an important part of modelling concepts in SNOMED CT and facilitate efficient subsumption testing, allowing inferences to propagate across chains of relationships. The |Is a| attribute in SNOMED CT is transitive: if disorder B is a subtype of disorder A, and disorder C is a subtype of disorder B, the reasoner infers that C is also a subtype (descendant) of A without this relationship needing to be explicitly modelled by the author. Simply switching between SNOMED CT’s stated and inferred views illustrates this chain.

Role chaining

Property chaining, also known as role chaining, is a transitivity concept involving multiple distinct attributes. This mechanism enables logical inference across roles that are both different and interconnected.

In SNOMED CT, this is exemplified by the chain linking |Has active ingredient| to |Is modification of|. By linking these attributes, the system can support reasoning between the substance and product hierarchies, ensuring that substances and their active ingredients are correctly subsumed.

Consider the case of amoxicillin sodium and amoxicillin: since the former is not a subtype of the latter, a concept defined by the |Has precise active ingredient| of amoxicillin sodium would not automatically classify under products containing amoxicillin. Such an organisation of the taxonomy would be counterintuitive, but the established role chain between |Has active ingredient| and |is modification of| resolves this and ensures appropriate subsumption.

The Limits of Description Logics

An intellectually honest account of DL must acknowledge what it does not do well.

A significant contribution to this question comes from Rector, Schulz, Rodrigues, Chute and Solbrig, in their analysis of the ICD-11 Common Ontology project. Their paper — “On beyond Gruber” — draws a fundamental distinction between invariants and generalisations.

An invariant is a statement that admits no exceptions and holds across all possible conformant models.

A generalisation is a statement that is true in most cases but defeasible — admitting exceptions.

Description Logics and OWL are designed for invariants.

The statement “myocardial infarction is defined as necrosis of part of the myocardium due to ischaemia” is invariant: it holds by definition without exception. By contrast, “myocardial infarction is characterised by acute chest pain” is a generalisation — typically true, but not universally so. Atypical presentations exist. OWL cannot represent this distinction. Every OWL axiom is treated as an invariant, holding in all conformant models.

The practical consequence is that terminology systems must be thoughtful about what they represent in OWL and elsewhere. Clinical signs, symptoms, typical presentations, statistical associations — these are generalisations. They belong in frame-based systems or other representational frameworks that can handle defeasible knowledge.

This is not a criticism of Description Logics. It clarifies their proper scope. DLs provide formal, computable, unambiguous semantics for invariant terminological knowledge. That is a precisely defined and enormously valuable function. The limits of OWL are not failures — they are the boundaries of a deliberately constructed formal system.

Why This Matters: Semantic Interoperability

The case for Description Logics in health informatics rests ultimately on what they enable. Semantic interoperability requires more than shared codes. It requires a shared, computable, formally specified meaning.

A terminology without formal semantics is a shared vocabulary. That is useful, but limited. A system that cannot classify, infer, check consistency, and reason cannot be trusted to support clinical decision-making, cohort identification, population health analysis, or federated data queries at scale.

Consider a federated query across multiple hospital systems seeking all patients with a diagnosis of bacterial pneumonia. If “bacterial pneumonia” is defined logically — as a pneumonia with a causative agent that is a bacterium — then a DL reasoner can identify every concept subsumed by that definition, regardless of which specific code was used to document the encounter. Without DL, this requires manually curating every piece of code in scope, which introduces delays, inconsistencies, and the permanent risk of incompleteness. With DL, classification is a consequence of the definitions.

The same principle applies across the clinical data ecosystem: from FHIR value set expansion to cross-map validation, from post-coordination in electronic health records to interoperability between national editions and SNOMED CT extensions. Every one of these use cases depends on computable meaning, powered by Description Logics.

Vadim Peretokin’s recent LinkedIn post makes the point sharply: meaning does not survive successive FHIR calls when processed by a large language model. A model operating over serialised FHIR JSON reads natural-language labels — display text, narrative strings, human-readable codings. The formal logical definition of a coded concept is not accessible to it. What looks like semantic processing is pattern-matching over strings.

This is not a FHIR problem. It is a semantic grounding problem. The formal foundation that DLs provide is not an academic concern. It is the difference between systems that share strings and systems that share knowledge.

Conclusion

The infrastructure of formally grounded terminology is in place. What is needed now is a professional community with sufficient fluency in these foundations to use that infrastructure well. To author definitions that the reasoner can correctly classify, to understand what a General Concept Inclusion implies, to recognise when a clinical statement is an invariant and when it is a generalisation, and to know what OWL can and cannot represent.

Clinical terminology does not maintain itself. Nor does semantic interoperability arise by accident. Both require a professional community that understands the logic beneath the language.

Author: Michael Harwood-Jones AdvFEDIP FHRIM MBCS

Michael is a specialist in controlled clinical vocabularies with almost two decades of experience in health classification, terminology, and information standards. His background includes roles in hospital administration, informatics, internal audit, education, and standards development.

Share

Key Sources

Baader, F., Horrocks, I. and Sattler, U. (2007) “Description Logics”, in van Harmelen, F., Lifschitz, V. and Porter, B. (eds.) Handbook of Knowledge Representation. Elsevier.

Krötzsch, M., Simančík, F. and Horrocks, I. (2012) “Description Logics”, IEEE Intelligent Systems, 27(3), pp. 48–54. Department of Computer Science, University of Oxford.

Rector, A., Schulz, S., Rodrigues, J-M., Chute, C.G. and Solbrig, H. (2019) “On beyond Gruber: ‘Ontologies’ in today’s biomedical information systems and the limits of OWL”, Journal of Biomedical Informatics.

Standardised medical language provides a structured foundation for modern digital healthcare by ensuring that clinical meanings remain consistent across different technology platforms. While Hippocrates’ historical efforts began this journey, contemporary systems such as SNOMED CT now use logical relationships to convert medical records into computable data suitable for artificial intelligence. This semantic clarity is vital because naming errors or fragmented data can lead to dangerous clinical mismanagement and significant economic losses for health systems.

To bridge the gap between human clinical practice and technical data science, specialised clinical terminologists perform the essential work of authoring, mapping, and governing these complex vocabularies. These systems provide a deterministic grounding layer that reduces errors, supports advanced research, and enables the safe deployment of automated health tools. Ultimately, adopting universal terminological standards is a critical prerequisite for achieving a high-quality, interoperable, and future-ready digital infrastructure for healthcare.

Introduction

Terminology concerns language use and the definition of meaning. For most, this sounds niche—something for linguists or philosophers. But in healthcare, precise language can mean the difference between a patient receiving the right treatment and the wrong one. It also distinguishes health data that can be shared and acted upon from data that are kept in silos. As health systems adopt digital records and AI systems intended to assist with administration and frontline care, terminology must be treated as infrastructure, not an afterthought.

A Legacy of Language

Medical terminology has a long history. Some 2,500 years ago, Hippocrates and his followers developed the first structured vocabulary for diseases, procedures, and outcomes. Many words we use today, like symptom, diagnosis, therapy, and trauma, are attributed to their work. This vocabulary allowed medicine to shift from narrative superstition to a system of structured observation. This was not just about semantics; it formed the foundation for building, sharing, and advancing clinical knowledge.

Nowadays, we use digital records instead of parchment, but the need for shared clinical meaning remains. Incomplete or misunderstood clinical terminology can lead to medical mismanagement and patient harm.

A 2022 Lancet study found that up to 80% of surveyed patients with central diabetes insipidus (a fluid regulation disorder) had experienced a situation where healthcare staff had confused their condition with diabetes mellitus[1]. The 2009 case of Kane Gorny is the starkest example. He died from dehydration in an NHS hospital in London after his fluids were restricted due to this confusion[2]. Though extreme, this case shows the real dangers of imprecise language. Ultimately, this led to a campaign to rename the condition[3].

Confucius understood this long before the digital age:

“If names are not rectified, speech will not accord with reality.”

If we do not name things properly, things will go wrong.

From a Fragmented State of Nature to a Digital Commonwealth

In the 17th century, Thomas Hobbes wrote about the power of language and definitions. He spoke of speech as a means to transition man from his natural, isolated state to collaborative societies. Although his writings were political, we can use Hobbes’ philosophical framework as a lens to view our current situation. We want to move health data from fragmented to unified and need a shared contract on what words mean.

Healthcare workers across GP practices, hospitals, and countries record the same idea differently. Information quality varies. Medical records reside in digital infrastructure but are often split across systems. Silos and terminological differences cause meaning to leak when exchanging data. We can send humans around the far side of the moon, but sharing GP records across borders remains a challenge.

Semantic interoperability—what Hobbes called “apt imposing of names”—is not just a nice-to-have. It is essential to the NHS 10 Year Plan’s goal of a single, seamless patient record. It is also crucial to the European Health Data Space and to the deployment of AI. AI consumes structured meaning and needs an ontological framework to avoid hallucinations. Without semantic interoperability, we build on sand.

The Royal College of Physicians highlighted this in its digital and AI position statement. A lack of structured data and standardisation in electronic records is a major interoperability barrier and clinical risk. In its survey, 51% of respondents said data issues block clinical AI in the NHS[4].

What Are Clinical Terminologies?

ISO standard 17117 defines standardised clinical terminology as a systematically organised, computer-processable resource. It arranges words and phrases into concepts. The key point is that concepts are more than words. Concepts are the clinical ideas—the units of meaning—behind the language. If language changes, meaning remains.

Clinical terminologies come in two distinct flavours.

• Interface terminology is used at the point of care. Clinicians enter it into a system, which then displays a readable format. Interface terminologies are flexible, localised, and user-friendly.

• Reference terminology is the hub connecting the interface. It provides logical definitions and extensive content. Reference terminologies typically map to other standards and code systems.

The two types work together. The interface helps clinicians enter data. The reference standardises how data is stored, managed, and analysed for clinical and administrative use.

SNOMED CT: Logic-Based Terminology in Practice

SNOMED CT is the most comprehensive clinical health terminology worldwide. It is used in more than 80 countries, is multi-lingual, and is logic-based. This last feature sets it apart from many other code systems.

SNOMED CT content consists of three main parts:

• Concepts - each represents a distinct clinical idea and is assigned a unique numeric identifier

• Descriptions - are the terms used in everyday practice by healthcare workers to order tests, document findings, and describe the care they give to patients

• Relationships - the secret sauce. Logical, hierarchical links connecting concepts and enabling machines to reason over data

SNOMED CT uses a formalism called Compositional Grammar, based on description logic. Take appendicitis: the word breaks down into ‘append’ (appendix) and ‘itis’ (inflammation). Humans infer meaning this way. In SNOMED CT, the appendix is a |Finding site| and inflammation is an |Associated morphology|. This creates a computable definition for machines, and also enables a description logic classifier – a specialised reasoning tool – to automatically compute the hierarchical structure (subsumption relationships) of concepts within an ontology.

These hierarchies have the |Is a| relationship at their core. It represents parent-child relationships, showing one thing as a type of another, and encoding that relationship. SNOMED CT is polyhierarchical: a concept can have multiple parents and children, reflecting the multi-dimensional nature of medical knowledge.

The result: terminology that can power intelligent clinical decision support and not just flat code lookups.

📖 You can Read more about formal semantics in action in a previous article I wrote here

The Unseen Architect

Terminology does not maintain itself. Someone has to author, map, configure, and update these systems — and that work requires a very particular blend of skills.

ISO 22287 recognises three levels of clinical terminologist: technical specialist, specialist, and advanced specialist. In practice, many organisations rely on a single person covering elements of all three.

Terminologists sit at the intersection of clinical expertise and technical knowledge. On the clinical side, most come from nursing, medicine, pharmacy, allied health, or health information management backgrounds. They understand clinical language, how it is documented in systems, and how the resulting data is intended to be used. On the technical side, they work with terminology servers, authoring platforms, and mapping tools, alongside standards such as HL7 FHIR. They are familiar with principles such as Cimino’s Desiderata and know when to pre- or post-coordinate. Critically, they are also facilitators — running governance meetings, negotiating between clinical and digital teams, and translating requirements into implementable solutions.

📖 For a deeper dive into the role of the terminologist, refer to my previous article on the topic here

The day-to-day work falls into several streams.

• Authoring

• Mapping

• Release Management

• Implementation & Tooling Support

• Quality Assurance

All of these areas warrant an in-depth article of their own, but authoring and mapping are the two least recognisable to non-specialists.

Authoring

When a new concept is required — a new disorder, procedure, drug, device, etc. — the terminologist evaluates the request, thoroughly researches the domain, constructs a formal definition using appropriate relationships and attributes, adds all relevant synonyms, and prepares it for inclusion in a future release. It is painstaking, expert work — and when it is done well, it is largely invisible to the clinicians and systems that depend on it.

Mapping

Translating codes between vocabularies to allow data to move between environments. The classic example is SNOMED CT to ICD-10 for billing and reporting. Precise one-to-one matches are the goal, but achieving perfect equivalence is not always possible when design structures and use cases differ; the terminologist must determine the most appropriate and meaningful fit. Maps must also be re-validated with every release, as the source terminology evolves.

📖 More articles on mapping

• Troubleshooting Terminology Maps

• The 3 Critical Phases of High-Quality Terminology Mapping

What Terminology Is Not

A common misconception: terminology is not the same as clinical coding. Both involve encoding health data, but terminologies aim to capture clinical reality at the point of care. This allows real-time analytics and interoperability. Clinical coding, such as ICD-10, summarises past events for statistical and administrative purposes.

They are complementary tools, not competitors — each serving a distinct purpose in the information lifecycle from point of care to population-level reporting.

📖 Read more about the role of the clinical coder in a previous article I wrote here

The Cost of Getting It Wrong

Information sharing and semantic clarity matter for their own sake. But rigorous terminology governance also makes economic sense, in addition to considerations of patient safety.

Poor terminology governance drives medical errors, lost revenue, and missed data-sharing opportunities. Lack of interoperability introduces risk through information gaps. Patients must repeat their history to each new clinician, risking omission of key details. An OECD study found these patients show a 15% drop in trust in their clinician. This shows patient satisfaction declines when information flow is poor.

The same OECD study estimates the cost of misdiagnosis, underdiagnosis, and overdiagnosis at 1.8% of GDP. For the UK, that could mean up to £55 billion in cash terms[5,6].

The benefits of doing it right are just as big. Frontier Economics estimated that patient data sharing in the EU is worth €10.7 billion each year. This includes a 14% rise in clinical trial activity and 64,000 extra quality-adjusted life years for cancer patients[7].

Closer to home, an NHS trust in London piloted an SNOMED CT-assisted coding tool. They identified missing conditions in 35% of inpatient spells and made coding improvements in nearly half of the cases[8]. This means more than better reimbursement. There is better visibility, resource allocation, and patient safety. Proper terminology governance stops the garbage-in, garbage-out cycle.

Terminology Must Be an Upfront Consideration

Modern healthcare ambitions — single patient records, AI-enabled care, seamless cross-border data exchange — all depend on standardised clinical terminology. It improves consistency in frontline documentation, powers clinical decision support, supports safer information exchange, and enhances the accuracy and integrity of clinical datasets. The financial and patient safety implications of poor terminology governance are real and quantifiable.

As AI systems become increasingly embedded in clinical workflows, the need for a reliable semantic foundation becomes more urgent, not less. Terminologists are doing the essential, often invisible work of making data semantically reliable — providing the ontological framework that supports grounded, trustworthy intelligent systems.

The key message is this: terminology must be considered from the outset of any digital health project, not retrofitted once problems become visible. Having terminology expertise present from the start prevents costly rework later — and, more importantly, protects the integrity of the data on which clinical decisions and, increasingly, AI recommendations depend.

Conclusion

Standardised medical language provides a structured foundation for modern digital healthcare by ensuring that clinical meanings remain consistent across different technology platforms. While Hippocrates’ historical efforts began this journey, contemporary systems such as SNOMED CT now use logical relationships to convert medical records into computable data suitable for artificial intelligence. This semantic clarity is vital because naming errors or fragmented data can lead to dangerous clinical mismanagement and significant economic losses for health systems.

To bridge the gap between human clinical practice and technical data science, specialised clinical terminologists perform the essential work of authoring, mapping, and governing these complex vocabularies. These systems provide a deterministic grounding layer that reduces errors, supports advanced research, and enables the safe deployment of automated health tools. Ultimately, adopting universal terminological standards is a critical prerequisite for achieving a high-quality, interoperable, and future-ready digital infrastructure for healthcare.

Author: Michael Harwood-Jones AdvFEDIP FHRIM MBCS

Michael is a specialist in controlled clinical vocabularies with almost two decades of experience in health classification, terminology, and information standards. His background includes roles in hospital administration, informatics, internal audit, education, and standards development.

Share

Additional references:

[1] https://www.thelancet.com/journals/landia/article/PIIS2213-8587(22)00219-4/abstract

[2] https://www.bbc.co.uk/news/uk-england-london-18814487

[3] https://www.endocrinology.org/endocrinologist/146-winter-22/general-news/renaming-diabetes-insipidus/

[4] https://www.rcp.ac.uk/policy-and-campaigns/policy-documents/the-rcp-view-on-digital-and-ai-report/

[5] https://www.oecd.org/en/publications/building-people-centred-digital-health-systems_a1df0046-en/full-report.html#contact-d5e1312

[6] https://commonslibrary.parliament.uk/research-briefings/sn02783/

[7] https://www.frontier-economics.com/uk/en/news-and-insights/news/news-article/?nodeId=20346

[8] https://www.magonlinelibrary.com/doi/abs/10.12968/bjhc.2022.0135

Terminology maps enable semantic interoperability by linking equivalent terms across different standards, classifications, and coding schemes. They facilitate data exchange and cross-searching, improving information retrieval precision and recall by removing the need for keyword guesswork. These maps also enable clinical data collected at the point of care to be repurposed for secondary functions, including statistical aggregation, reimbursement, research, and public health surveillance.

Mapping is also essential for maintaining the utility of historical data as terminologies evolve. Mapping can prevent the costly accumulation of legacy data by linking retired codes to modern systems, thereby facilitating data migration, research, and longitudinal comparability.

Creating a successful terminology map requires a structured lifecycle approach to ensure data integrity and safety. The following guidelines explain how to produce a high-quality map in accordance with recognised international mapping principles. These principles align terminology to enable consistent knowledge integration, reliable decision support, and accurate use of secondary data.

The workflow for developing a terminology map has three phases: planning, development, and maintenance. This process keeps maps accurate as resources change.

Phase 1: Planning

The planning phase lays the groundwork for a map that is useful, scalable, and sound.

• Define a clear purpose: First, assess if a map is necessary, and if one does not already exist that you can leverage. Each map must serve one clear purpose. Using a single map for multiple purposes, such as clinical care and billing, can cause errors and lead to clinical harm.

• Develop scenarios: Each map should have a single, clearly stated purpose, with supporting scenarios that outline its requirements. To support this, develop specific business scenarios, or “use cases.” These should describe who will use the map, how data will be exchanged, and the requirements that will be met.

• Determine the mapping scope: Start with a narrow scope to gather feedback and refine your process before scaling up. Prepare the source system by considering language, ambiguity, and synonyms.

• Establish explicit directionality: It is essential to define the map’s direction. Because most maps are one-way (unidirectional), translating from a specific source to a target, they must never be used in reverse. If a map should work both ways (bidirectional), state this clearly. True bidirectional maps are rare. If you need to translate both ways, build and maintain two separate one-way maps.

• Select appropriate tools and formats: Build maps in a machine-processable format. Avoid spreadsheets because they introduce errors, complicate tracking, and hinder collaboration.

Phase 2: Development

During development, teams link concepts between systems while documenting their decisions.

• Assemble a knowledgeable team: Mapping is not a solo task. It should be managed by a dedicated team. Team members need a strong understanding of the source and target resources. When possible, involve the creators or custodians of the terminologies to ensure accurate mapping of their codes.

• Track versions and set rules: Terminology systems often update. State the exact versions of both source and target resources used to build the map.

• Establish rules and heuristics: The team must write down the mapping rules and conventions they will use. They must also agree on how strictly to follow each resource’s rules, including how to handle conflicts or missing concepts. This ensures consistency and reproducibility among specialists.

• Define relationships and equivalence: Two systems rarely match perfectly. Establish mapping patterns, such as one-to-one or one-to-many relationships, and state the cardinality of each mapping. The map should also show how closely concepts match, whether exact, broader, narrower, or unmatched. Any loss or gain of clinical meaning must be clearly stated, and its risk assessed.

• Identify mapping correlations: State relationships such as narrow-to-broad or broad-to-narrow. You may skip this for terminology-to-classification maps, where users expect information to be lost as granular concepts move to broader codes. In these cases, assigning individual correlation IDs is not useful. However, this decision must be documented in the user guidance and clearly explained.

• Implement consensus management: Deciding the meanings of medical terms is subjective, so disagreements among map developers will arise. Set up a formal process to manage this, such as an expert panel or dual independent authoring, to resolve differences.

• Ensure transparency: Document all automated and manual methods used to create the map for future reproducibility.

Phase 3: Maintenance (Ongoing Use)

A terminology map is a living tool and needs ongoing attention as source and target systems evolve.

• Implement a Quality Assurance (QA) plan: Every project needs a QA plan with thorough testing and validation. Maps must be tested with candidate data and reviewed by experts. Use findings to improve the map and update project documentation with new heuristics. Decide on acceptability standards on a case-by-case basis, considering the expected level of human intervention. The best practice is to compare the mapped output to the original data, the ‘ground truth’, such as the original medical record, to check accuracy.

• Finalise documentation: For ongoing use, make all guidelines and rules available. The documentation must explain the map’s data structures, formats, and licensing. Clear guides help prevent misinterpretation of the map.

• Commit to maintenance activities: Terminology systems update regularly, so maps will degrade over time if neglected. Update and maintain maps regularly to keep up with new versions of source and target terminologies. Set up a formal maintenance plan to track version control, retire old codes, and add new ones.

• Foster continuous improvement: Long-term success needs user feedback. As the map is used in real settings, apply feedback to fix errors and improve performance. Having a dedicated development and maintenance team will ensure this is performed effectively.

Summary

Terminology mapping must be treated as a structured, three-phase lifecycle: planning, development, and continuous maintenance. A successful map must start with a clearly defined, single-purpose scope, be built by a knowledgeable team using explicit rules and consensus management to ensure consistency, and be supported by rigorous Quality Assurance against the ‘ground truth’. Because terminology systems constantly evolve, neglecting the final maintenance phase means your map will inevitably degrade, jeopardising the integrity of your clinical data.

Referenced Sources:

1. ISO/TR 12300:2014(E) Health informatics — Principles of mapping between terminological systems

2. WHO-FIC Classifications and Terminology Mapping - Principles and Best Practice

3. Data Mapping and Its Impact on Data Integrity (AHIMA)

4. Challenges and issues in terminology mapping: a digital library perspective

5. Ontology mapping: Advancing data interoperability (SciBite)

6. Ontology mapping: Finding the right automated approach (SciBite)

7. SNOMED CT Mapping Guide

Photo by Towfiqu barbhuiya on Unsplash

The question of which additional diagnoses (aka ‘other diagnoses’ or ‘secondary diagnoses’) should be coded is one of the most persistent debates in clinical coding. It sits at the intersection of clinical documentation, information governance, data quality, and the purpose of classifications themselves.

NHS organisations are struggling to meet their coding commitments due to a shortage of trained clinical coders. Consequently, there is growing interest in using AI and related technologies to automate some of this workload to support departments. However, as discussed in this recent post by Joakim Edin, such technologies can struggle to determine if a code assignment is necessary for an episode of care. This has led me to revisit my earlier ideas on “relevance”, drawn from my years as a clinical coding auditor. If the sector moves toward more AI-assisted coding, being able to scrutinise outputs is paramount; otherwise, we risk creating our own “children of the magenta”.

This article explores why relevance is so difficult to define and how inconsistent practices distort datasets.

Data Quality Starts With Purpose

Data are considered high-quality when they serve their intended purpose and fulfil user requirements: right data, right time, right outcome. However, data quality (DQ) is not a fixed ideal; it is always contextual.

DQ can be measured against many criteria, but the generally accepted dimensions include accuracy, completeness, consistency, validity, timeliness, and uniqueness[1].

Completeness is the key metric regarding relevance, but how is this defined? According to the DAMA-DMBOK, completeness can be considered in terms of requirements or metadata. Specifically, completeness of requirements means that the dataset includes everything requested and nothing more[2].

Also important is that the data are processed correctly and legally. Data minimisation is a key principle of information governance (IG), and means that the data you collect is:

• Adequate for your stated purpose

• Relevant to that purpose

• Limited to what is necessary for that purpose

Therefore, having a clear purpose is essential, as it defines the scope of data collection, shapes quality metrics, and informs the design of governance controls. Data makers benefit from clear boundaries, while data takers know the limits of intended use (especially when using the data for other purposes). This can avoid wasted time and frustration from misusing data, like attempting to change a lightbulb while standing on a swivel chair.

In clinical coding, accuracy not only reflects the documented diagnoses and procedures for an episode of care but also ensures that these assignments comply with the applicable coding rules, conventions, and standards. Collectively, these rules form a DQ framework that instructs which data are required.

Coding quality is often measured according to three dimensions:

1. Individual codes: Are the codes correct and specific enough?

2. Sequencing of codes: Are the codes in the right order to support analysis?

3. Totality of codes: Are all the relevant codes assigned that accurately describe the episode of care?

The totality of codes most closely resembles our definition of completeness, meaning that it contains all relevant information while excluding background information and inactive problems. In other words, the totality of codes is a bit like Goldilocks; it has to be “just right”, else overall data quality may be compromised.

Much like Goldilocks, the concept of ‘totality of codes’ can be difficult to satisfy. This illustrates the heart of the relevance dilemma. Coders often rely on judgment rather than objective criteria when deciding whether a condition is “relevant”. Coding standards state what should be recorded, but local interpretation shapes what is actually captured. This subjective process risks variation and undermines the intended purpose of coding.

Coding Shifts: Globally Defined, Locally Applied

Discussions concerning the relevance of additional diagnoses are not new, yet coding practices still vary widely across countries, regions, and even organisations in the same jurisdiction. This inconsistency complicates comparative analysis and can undermine trust in secondary uses of data. A recent study published in the American Journal of Epidemiology found that over a third of patients treated with COVID-specific antivirals lacked a corresponding ICD-10 code[3]. Meanwhile, another study published in the British Journal of Cancer highlights the huge limitations of an over-reliance on hospital episode statistics (HES) for comorbidity research[4].

These studies are timely; they demonstrate that clinical coding cannot be all things to all people. As demand for data grows, efforts to meet those requests often lead us away from our original purpose.

Accordingly, a clear, shared definition of relevance is essential for accurate, useful datasets and the effective automation of coding processes. This demands more than just coding everything documented; overcoding can undermine data quality and mislead performance metrics.

The ICD-10 Instruction Manual (vol.2) states the following regarding additional diagnoses:

Other conditions are defined as those conditions that coexist or develop during the episode of health care and affect the management of the patient. Conditions related to an earlier episode that have no bearing on the current episode should not be recorded.

An episode of care is not intended to be a full medical record; it should not include conditions that did not affect the patient’s management in that episode. Here, ‘relevant’ refers to conditions that had a material impact on the care delivered during the episode. However, the criteria for applying this definition of relevance differ across countries [5,6].

Across the UK, hospital morbidity coders assign ICD-10 5th Edition codes in accordance with a set of national clinical coding standards published by NHS England. These standards have been adopted by the home countries but are adapted and expanded as needed to accommodate differences in national reporting requirements. For example, Scottish Morbidity Records (SMRs) only support recording five other significant conditions.

The main standard regarding additional diagnoses is DGCS3: Comorbidities, accompanied by Appendix 1: Comorbidities list, which lists conditions that must always be coded, regardless of the reason for the encounter. This includes many common chronic illnesses such as diabetes, heart disease, and dementia, as well as health-related factors such as smoking and obesity. Outside this mandated list, however, guidance becomes vague: coders are tasked with assigning any relevant diagnosis, with relevance determined locally[7]. This often leads to the familiar mantra: “If it’s documented, it must be relevant.”

The 2014 national audit report ‘The Quality of Clinical Coding in the NHS’ popularised this approach. It asserted that only the clinicians involved in a patient’s care can determine which comorbidities or other conditions are relevant. This statement has been interpreted widely as an instruction to code everything documented. However, this is at odds with the general principles for accurate code selection, which advise coders to use the minimum number of codes and to skip background information and problems that are no longer active[7].

While this approach to capturing a broader clinical picture may seem thorough, it also risks amplifying noise by inflating the number of irrelevant codes, thereby diverging from the DQ definition of completeness and the governance principle of minimisation. Crucially, Hospital Episode Statistics (HES)—a curated data warehouse containing records of all NHS hospital inpatient, outpatient, and emergency attendances in England—stores only 20 diagnoses per episode; anything beyond that limit is not included in the final dataset that reaches researchers. This places a significant limitation on researchers using this dataset, but also emphasises the need for more. mature data practices amongst coders.

Across the NHS, “depth of coding” is an oft-cited performance indicator, but it can be a misleading metric. Despite its name, depth-of-coding is a paradoxically flat measure. It is simply the average count of additional diagnosis codes assigned. It reflects very little about real coding quality. Spamming codes for symptoms and historical conditions can easily distort this metric and the datasets from which it is derived.

This sort of over-coding can hide mistakes. If enough irrelevant codes are added and not handled correctly in audits, they can distort accuracy percentages, masking serious problems that may lurk beneath the surface.

Lost in Translation: Understanding Classifications & Abstraction

A further wrinkle is that not all clinically relevant information can be meaningfully represented in classifications.

To understand relevance, we must return to the purpose of classifications. Classifications exist to support aggregation—the grouping of similar cases to enable statistical analysis. They are not designed to capture every detail of a patient’s history.

In the 19th century, this was described as the “combination of observations”: the idea that summing individual data points provides insight by discarding unnecessary detail[8].

This process of abstraction is fundamental to using classifications like ICD‑10, where the first step in coding is to abstract the key information from the clinical record. This is also what differentiates classifications from terminologies such as SNOMED CT. Terminologies support detailed clinical documentation; classifications are designed for statistical reporting.

ICD‑10 prioritises conditions of public health importance, in other words, what we want to count. Common conditions or those of special importance have specific codes; everything else is grouped into broader categories. These design differences can help guide sound decisions about whether a code is relevant, since a classification, like ICD-10, is intended for statistical analysis and aggregation, not for capturing highly granular detail.

Sometimes, a clinically important issue has to be coded with a vague code that doesn’t really capture its clinical meaning. Take the example of a past stroke. Clinically, this may be highly relevant. However, in the absence of any residual effects, the only ICD‑10 code that can be assigned is Z86.7 Personal history of diseases of the circulatory system. Clearly, this code does not explicitly represent a previous stroke, and the same code could be used for anything from a major haemorrhage to a harmless naevus. To anyone analysing the data without access to the clinical record, the meaning of this code is ambiguous. Herein lies the recurrent challenge: the clinical relevance is real, but the coded representation is too vague to be useful. The relevance gets lost in the translation. This can lead to a casemix or reimbursement system that rewards providers based on assumptions about code usage rather than the clinical reality.

When deciding whether to code an additional diagnosis, we must consider not only whether the information is clinically relevant, but also whether the classification can convey it in a way that genuinely supports secondary use.

Towards a More Meaningful Interpretation of Relevance

Relevance in clinical coding cannot be reduced to “if it’s documented, code it.” Nor can it rely solely on clinician judgment without reference to the purpose of classifications and an understanding of their limitations. We must emphasise the purpose of clinical coding, and by understanding the basic principles of classification–including its inherent limitations–users can produce high-quality data.

A more meaningful approach requires:

• Understanding the purpose and limitations of classifications

• Prioritising conditions that affect the current episode of care

• Avoiding background or inactive problems

• Considering whether the coded representation will be meaningful in secondary uses

• Ensuring that coding depth reflects quality, not quantity

Ultimately, a balance must be struck between capturing what actually matters, avoiding unnecessary noise from overuse of junk ICD-10 codes, and. As the sector moves toward ICD‑11 and more sophisticated data models, clarity on relevance will become even more important.

This is not about coding more or less, but about having a clear definition of what we code. Leaving what is relevant to be determined locally essentially lets trusts mark their own homework. Trusts that are well-resourced and technically mature will be able to maximise their coding throughput, and will be rewarded for it. Meanwhile, less capable organisations are left behind. It widens the divide and contributes to the inconsistencies plaguing the data. Evidence of the lack of persistence in chronic condition coding has been reported in the literature for years, and that’s just for the mandatory conditions we all know we are supposed to be coding, never mind the fuzzier stuff.

Ultimately, the solution doesn’t lie in simply adjusting what we code. Changes to the APC data model are needed to ensure that the data collected can serve the growing number of use cases without affecting the integrity of the datasets. If AI is going to replace the need for manual extraction of information from the clinical record, then the value of a clinical coder can be reinvested in high-quality curation and labelling of context-mature data sets.

Clinical coding is not a transcription exercise. It is an act of abstraction, interpretation, and judgment. These are valuable skills that only humans can bring. Getting relevance right is essential if we want coded data to truly serve its purpose.

I’ll sum it up with a quote from Antoine de Saint-Exupery:

Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.

Author: Michael Harwood-Jones AdvFEDIP FHRIM MBCS

Michael is a specialist in controlled clinical vocabularies with almost two decades of experience in health classification, terminology, and information standards. His background includes roles in hospital administration, informatics, internal audit, education, and standards development.

Share

Additional References:

1. King, T. and Schwarzenbach, J. (2020). Managing Data Quality: A Practical Guide.

2. DAMA International (2017). DAMA-DMBOK : Data Management Body of Knowledge. 2nd ed., p 161.

3. Hendrix, N., Parikh, R.V., Taskier, M., Walter, G., Phillips, R.L. and Rehkopf, D.H. (2025). Natural Language Processing Improves Reliable Identification of COVID-19 Compared to Diagnostic Codes Alone. PubMed. Available at: https://doi.org/10.1093/aje/kwaf162

4. Zucker, K., McInerney, C., Glaser, A., Baxter, P. and Hall, G. (2025). Why NHS hospital co-morbidity research may be wrong: how clinical coding fails to identify the impact of diabetes mellitus on cancer survival. British Journal of Cancer, [online] 133(8), pp.1137–1144. Available at: https://doi.org/10.1038/s41416-025-03136-9

5. IHACPA. (2024). ICD-10-AM/ACHI/ACS Twelfth Edition - ACS 0002 Additional Diagnoses Fact Sheet. [online] Available at: https://www.ihacpa.gov.au/resources/icd-10-amachiacs-twelfth-edition-acs-0002-additional-diagnoses-fact-sheet

6. ICD-10-CM Official Guidelines for Coding and Reporting FY 2026, pp 110–111. Available at: https://www.cms.gov/files/document/fy-2026-icd-10-cm-coding-guidelines.pdf

7. NHS England, National Clinical Coding Standards ICD-10 5th Edition for Morbidity Coding (2026), p 12 & 36. Available at: https://nhsengland.kahootz.com/t_c_home/view?objectId=69953776

8. Stigler, S.M. (2016). The seven pillars of statistical wisdom. Cambridge, Massachusetts: Harvard University Press.

Illustration by VectorElements on Unsplash

The NHS 10 Year Plan sets out the need for “high-quality, interoperable health data”[1]. Not only is this data essential to achieving the ambition of a single patient record that ensures patients receive “seamless care”, but it will also be used to train the AI algorithms the NHS intends to adopt to support frontline clinical workflows and reduce back-office bureaucracy.

AI tools can seem ubiquitous, especially in healthcare, but despite the hype, many of these products do not graduate from the pilot phase. A study by MIT, reported in Forbes, suggests that up to 95% of AI projects are shelved. More recently, Becker’s reported that some US healthcare organisations are dialling back their AI projects because they fail to scale, demonstrate benefits, or generate a return on investment. Indeed, it has been argued that the deployment of sustainable AI requires Learning Health Systems (LHSs) to keep AI aligned with clinical reality. However, LHSs can succeed only when they are built on strong data foundations[2].

Against this backdrop of technological advancements and ambitious policy initiatives, terminologists are quietly going about their day-to-day work. These specialists operate at the intersection of clinical practice, data science, and digital technology. They develop the concept models, mappings, and governance processes needed to ensure that clinical vocabulary is consistently represented. They connect clinicians, informaticians, and software developers to make clinical meaning semantically interoperable (i.e., data shared across different IT systems maintains a consistent meaning).

Yet despite their central role in digital transformation, the contributions of terminologists remain underrecognised and poorly understood within the UK health sector. The Federation for Informatics Professionals in Health and Social Care (FEDIP) does not include terminology roles within its occupational architecture, and none of its professional bodies–those being AphA, BCS, CHIME, IHRIM, Socitm or CILIP–explicitly represent the terminology workforce. Not only does this mean there is a lack of dedicated career support for terminology workers, but also that there are limited opportunities to participate in wider workforce initiatives and that their contributions are less visible.

This article argues that terminologists are the invisible backbone of healthcare data. It describes the benefits of their work and the challenges they face, while exploring why their work matters and deserves the same recognition as other professionalised informatics roles.

Definition

ISO 22287:2024 defines the role of terminologists in healthcare organisations as:

the selection, authoring, and deployment and use of terminology subsets, data sets and maps; developing and managing terminology management processes and health information management-related policies; performing terminology business analysis; and supporting the adoption, planning and deployment of terminologies

This standard broadly defines terminology specialists into three categories:

• Terminology Technical Specialist

• Terminology Specialist

• Advanced Terminology Specialist

These categories are defined by the specific roles, requirements, and skills. For simplicity, this article will use the term “terminologist” to refer to all levels of specialists working in this field, since this is the job title most commonly used in the UK.

A terminologist is a health informatics specialist who designs and manages digital vocabularies for electronic health records (EHRs), decision support tools, and analytics and reporting platforms. They translate complex medical concepts into computable formats, enabling consistent data capture and reliable semantic interoperability across IT systems. Maintaining a database of standardised clinical terms ensures that information can be recorded accurately and unambiguously. This precision helps clinicians record patient details and healthcare activities clearly and consistently.

What Do Terminologists Actually Do?

While specific tasks will vary according to the exact role and organisation, most terminologists focus on five main areas:

• Authoring: Terminologists create, define, and maintain the building blocks of clinical terminology, including concepts, descriptions, and relationships. ‘Authoring’ may involve the addition, modification, or deprecation of existing terms, according to editorial principles.

• Mapping: Hospitals and clinical systems often use locally defined codes or interface terminologies. Terminologists create and validate mappings between these legacy systems and mandated national/international terminology standards, facilitating data sharing and enabling consistent analysis and reporting.

• Release Management: Terminology does not remain static; terminologists manage its evolution through change requests, release cycles, and coordinated stakeholder reviews. A well-governed release management process ensures teams make updates accurately and maintain clinical safety.

• Implementation & Tooling Support: Terminologists collaborate with EHR teams to build value sets, templates, and decision-support artefacts. Their involvement ensures clinical content is structured correctly from the outset, reducing the need for costly rework. They develop tooling test plans and verify tooling integrity.

• Ongoing Quality Assurance: Terminologists monitor and analyse coding quality, applying a quality assurance framework in clinical projects or in operational contexts to resolve ambiguities and support best practices for recording health information. This ensures that clinicians, researchers, and health systems have access to reliable and meaningful data.

Skills and knowledge

Terminologists bring together a unique blend of expertise. This dynamic role integrates linguistic expertise with analytical skills, attracting professionals interested in health language and the influence of technology on patient outcomes. This distinctive skill set is uncommon, underscoring the need to clarify professional pathways and to increase recognition of the terminologist’s role.

• Clinical understanding: Most terminologists come from nursing, medicine, pharmacy, allied health professions (AHPs), or health information management (HIM) backgrounds. This provides them with insight into clinical workflows, clinical information systems, and the use of terminology in practice. Knowledge of medical language, anatomy, and physiology is required.

• Terminology theory and standards: Apply standards (e.g. ISO 704:2022, Terminology work – Principles and methods) and follow terminology principles, such as Cimino’s Desiderata for Controlled Medical Vocabularies, as well as editorial guidelines to evaluate, define, map, and implement concepts in a clinically valid and consistent manner.

• Technical capability: Terminologists often work with terminology servers (software that stores and manages standard vocabularies), authoring tools (software used to create and maintain terminology content), and mapping software to transform content and support system integration. Database management and analytical techniques, such as SQL, are an asset.

• Stakeholder engagement: Collaboration with clinicians, other informaticians—such as software developers and data teams—and national and international standards bodies is essential to bridge the gap between clinical language and technical requirements. This requires strong communication, clinical validation, and governance facilitation skills.

Why Terminologists Matter

Modern initiatives like EHR adoption, HL7 FHIR integration, and data-driven improvements all depend on standardised clinical terminology. Terminology must be an upfront consideration in these projects; it must not be allowed to slip into the background. Having terminology expertise present from the start prevents costly rework. Financial implications of poor terminology governance can include the high cost of medication errors[3], loss of hospital revenue through poor data recording[4], or loss of economic benefit due to failure to share data[5].

Terminologists promote consistency in frontline documentation, configure clinical decision support tools, support safer information exchange, enhance the accuracy of reporting and the integrity of clinical datasets. Some key benefits of terminologists include:

• Ensure semantic interoperability by designing and maintaining clinical vocabularies that underpin the safe flow of meaningful data among systems, providers, and care settings.

• Model clinical content accurately from the outset, supporting safer workflows and maximising EHR effectiveness.

• Govern terminology through robust release management processes, ensuring clinical validation, improving data quality and reducing risk. Poor terminology governance can lead to inconsistent term use and misclassification, resulting in incorrect clinical decision support triggers.

• Support EHR and digital programmes by building value sets, templates, and decision-support artefacts that help to keep high-quality records.

• Strengthen data reliability for research, commissioning, population health, and regulatory reporting.

• Resolve ambiguity and enhance the consistency and quality of health records by reducing duplication in problem list entries and supporting more accurate clinical coding.

• Facilitate transfer of patient information by ensuring FHIR messages, shared care records, and cross‑organisational data exchange are meaningful and reliable.

• Support AI-readiness, as structured, computable clinical data is a prerequisite for safe AI deployment. Terminologists can support entity linking, data labelling, and model validation initiatives.

The Impact of a Terminologist

The role of a terminologist extends beyond managing vocabulary. It ensures that language bridges gaps among clinicians, providers, regulators, researchers, and governments. Effective terminology management, professional collaboration, and consistent language fuel the cognitive engine of the EHR.

Why This Role Is Becoming Even More Important

Digital healthcare is evolving rapidly, and demand for terminologists is growing. As the adoption of SNOMED CT accelerates across care settings, organisations will need to build their terminology capabilities. Cloud‑based terminology services with real‑time FHIR integration are also becoming more widespread, increasing the use of structured data in communications and clinical decision support. However, significant challenges persist, such as keeping pace with clinical innovation, ensuring semantic interoperability across legacy systems, and managing governance at scale.

Key Challenges

Balancing Precision with Flexibility

Terminological work demands exactness, yet language is flexible. Terms in one language may lack direct equivalents in another, making it a challenge to balance precision with translations that are natural and clinically appropriate.

Staying Current with Industry-Specific Terminology

Healthcare constantly incorporates new terminology to describe advancements, reflect improved understanding, or address problematic associations. This makes keeping terminology up to date and users informed about changes a demanding task.

Maintaining up-to-date terminologies ensures accuracy and clarity, but requires detailed terminology research, which involves identifying the most precise definitions. Therefore, terminologists must consult medical literature, clinical guidelines, academic research, pharmaceutical manuals, and other authoritative sources to determine accurate definitions. In some cases, they review historical journals to trace the origins and evolution of terms.

Frequently, consulting industry experts or subject-matter experts (SMEs) is essential to understand the nuances of a term. When working in international contexts, collaboration with linguists and translators may also be necessary to determine how a term is translated across languages.

Ideally, all information would be available, but this is rarely the case, necessitating compromises between terminological purity and pragmatism.

Ensuring Consistency Across Large Volumes of Content

Healthcare is a vast field that requires precise vocabulary for effective communication. Ensuring every term is accurate, reproducible, and clear is challenging. Ongoing collaboration with clinicians, translators, terminologists, and health information managers helps maintain relevance.

Opportunities

Despite these challenges, new opportunities are emerging. The profession is expanding beyond traditional boundaries and requires a workforce prepared to meet increasing demand. Integrating terminologists into EHR and digital teams ensures consistent terminology governance, thereby improving clinical and administrative workflows, system design, optimisation, and interoperability.

Terminologists can advance the adoption of terminologies by providing training and guidance that aligns with standards and reduces variation. Demand for terminologists to support EHR implementations in NHS trusts is increasing, and these specialists are also well positioned to lead in AI-ready data and research informatics.

Rewards of Being a Terminologist

Despite inherent challenges, the work of a terminologist is rewarding as it promotes clarity, consistency, and accuracy within global healthcare systems.

• Enhancing Global Communication: Terminology underpins precise global health communication. Effective terminology management ensures consistent representation of patient data. This supports direct patient care and supplies reliable data for audits and research, improving outcomes across generations.

• Building Expertise: Terminologists continually expand their knowledge in specialised fields by engaging deeply with the language of medicine across historical and contemporary contexts. This ongoing learning renders the work both intellectually stimulating and impactful.

Why Professional Recognition Matters

Poor terminology governance is more than a technical issue; it can lead to inconsistent data, flawed analytics, and patient‑safety risks associated with clinical decision support tools. The consequences of ambiguous and unclear language in complex healthcare settings are well-documented[6,7].

As the NHS and global health systems become increasingly data‑driven, the work of terminologists is fundamental to supporting safe, effective, and interoperable care. Yet, in the UK, the profession lacks:

• standardised competency frameworks

• formal career pathways

• recognition in workforce planning

A Call to Action

To achieve a healthcare system characterised by seamless data flow, safe and trustworthy artificial intelligence, and reliable information for clinicians, investment in terminologists is essential. Raising awareness is the initial step, but formal recognition must also follow. It is therefore critical to acknowledge and support this profession at present.

• Include terminologists in workforce planning, job families, and digital capability frameworks.

• Invest in capacity and capability by funding dedicated terminology roles within EHR and data teams.

• Give them a seat at the table in EHR design, optimisation, and interoperability workstreams.

• Integrate and embed terminologists into programme governance and ensure structured change‑control processes and clinical oversight are in place.

• Champion the profession: Support national efforts to define competencies, career pathways, and professional registration.

Advocating for professional training and career pathways will ensure future terminologists can advance safer, interoperable, and data-driven healthcare.

Conclusion

Terminologists are essential to healthcare. It is time to formally recognise their expertise and support their development. Without this, progress in interoperability will slow, patient safety may be at risk, and AI innovations may not yield results. Healthcare organisations, policymakers, and leaders must advocate for, invest in, and formally include terminologists as a part of the informatics professions. Now is the time to provide terminologists with the recognition, training pathways, and resources required to drive safe, future-ready healthcare.

For healthcare professionals interested in pursuing a career as a terminologist, there are a few things you can do to build on your clinical experience or familiarity with clinical workflows, such as:

• Engage in electronic health record projects, coding quality initiatives, or data governance activities. This career path rewards curiosity, precision, and a commitment to enhancing healthcare through improved data quality.

• Pursue training in health informatics or terminology. For example, complete SNOMED CT courses to develop authoring and implementation skills. The free SNOMED CT Foundation Course offers a practical starting point.

Author: Michael Harwood-Jones AdvFEDIP FHRIM MBCS

Michael is a specialist in controlled clinical vocabularies with almost two decades of experience in health classification, terminology, and information standards. His background includes roles in hospital administration, informatics, internal audit, education, and standards development.

Share

Additional references:

[1] www.gov.uk. (2025). Fit for the future: 10 Year Health Plan for England (accessible version), Chapter 8: powering transformation - GOV.UK. [online]

[2] Curcin, V., et al (2025). Learning Health Systems provide a glide path to safe landing for AI in health. Artificial Intelligence in Medicine, [online] https://doi.org/10.1016/j.artmed.2025.103346

[3] BMJ (2020). 237+ million medication errors made every year in England - BMJ Group. [online] BMJ. Available at: https://www.bmj.com/company/%20newsroom/237-million-medication-errors-made-every-year-in-england/

[4] Grant Thornton UK LLP. (2018). The implications of poor data recording in hospitals. [online] Available at: https://www.grantthornton.co.uk/insights/the-implications-of-poor-data-recording-in-hospitals/

[5] Frontier Economics. (2023). Understanding the value of international healthcare data sharing for the EU. [online] Available at: https://www.frontier-economics.com/uk/en/news-and-insights/news/news-article/?nodeId=20346

[6] Berger, S., Grzonka, P., Hunziker, S., Frei, A.I. and Sutter, R. (2025). When shortcuts fall short: The hidden danger of abbreviations in critical care. Journal of Critical Care, [online] Available at: https://doi.org/10.1016/j.jcrc.2025.155236

[7] Aronson, J.K. and Ferner, R.E. (2005). Clarification of Terminology in Drug Safety. Drug Safety, 28(10) [online] Available at: https://doi.org/10.2165/00002018-200528100-00003

In “Choruses from The Rock”, T. S. Elliot wrote[1]:

Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?

If Elliot were writing today, he might also have asked, ‘Where is the information we have lost in data?’ These lines set the stage for considering the roles of terminology, ontology, and classification in digital health, highlighting their relationships and the trade-offs involved. If ontology is knowledge and terminology is information, then classification is data.

Classification, or more precisely statistical classification, is a type of terminological resource that groups and organises information into predetermined categories based on shared characteristics. Bowker and Star describe classification systems as “a set of boxes (metaphorical or literal) into which things can be put to then do some kind of work”[2].

In healthcare, this “some kind of work” encompasses a range of statistical and non-statistical activities, including health research, data analysis, and reimbursing hospitals for the care they provide. Disease classifications have been essential tools for epidemiologists and statisticians for centuries, enabling the routine collection of mortality and morbidity data to inform decision-making at the local, national, and international levels.

What is Classification?

Classifications provide us with a tool for interpreting large amounts of information in a format that can be easily tabulated, aggregated, analysed, and interpreted. The format ensures the information is comparable, consistent, and easy to manipulate. Classifying involves grouping people or things according to common characteristics. In developing a classification, there are two main points to consider:

• Deciding what markers of difference are important and the groups they form

• Defining the categories within each group and their boundaries, i.e., how the categories relate to each other[3]

Categories refer to the listed entries that identify the classes of ‘things’ that the classification is interested in counting. Classifications are often presented as hierarchies, so that categories may function at multiple levels: they can be further divided into subcategories or grouped into larger sections (or chapters) that support traversal of the hierarchy [4]. Categories are usually assigned a code (alphabetical or numeric) that uniquely identifies each category and indicates its position within the overall hierarchy [5].

In health classifications, a category may refer to a disease, an organism, a procedure, or a symptom. The two primary health classifications in use in the United Kingdom are ICD-10 and OPCS-4; these are used in hospitals for clinical coding of diagnoses and procedures, respectively.

Mutually Exclusive, Collectively Exhaustive

Categories in classifications are meant to be mutually exclusive and collectively exhaustive (MECE), allowing data aggregation to a predefined level for statistical and non-statistical uses.

• Mutually exclusive means each category is defined so no item can appear in more than one category. Every counted thing belongs to a single category.

• Collectively exhaustive means all categories together fully cover the domain. Nothing is omitted; every relevant concept fits into a category.

MECE helps classifications meet Bowker and Star’s other key criteria: consistency and completeness.

Consistency relies on rules that guide users in applying the classifications in practice. For example, ICD-10 provides inclusion and exclusion terms in its Tabular List, which help users determine whether a particular category is correct, as well as an Alphabetical Index for searching.

Completeness in classifications uses residual categories for items that do not fit elsewhere.

• Categories designated as “Other specified” or that use the acronym NEC (Not Elsewhere Classified) behave as a catch-all to complete an exhaustive list of subtypes and can be used to classify things that have a specific meaning, but that are not explicitly represented by any other category.

• Categories designated as “Unspecified” or that use the acronym NOS (Not Otherwise Specified) are used to classify circumstances where insufficient detail is available to assign another better-defined category.

icd.who.int. (n.d.). ICD-10 Version:2016. [online] Available at: https://icd.who.int/browse10/2016/en#/

Everything In Its Right Place

This notion of completeness can be difficult to grasp. Classification systems provide a framework that groups many specific concepts together. While this reduces overall detail, the result is still an organised structure representing a wide range of clinical information.

Classifications are smaller and less granular than terminologies; therefore, how can they be ‘complete’? Whereas terminology concerns clinical reality, classifications concern abstractions and generalisations. Therefore, a single category may subsume numerous individually specified concepts, resulting in a reduction in information resolution, but providing a ‘home’ for them nevertheless.

In the International Classification of Diseases (ICD), emphasis has been placed on conditions considered most important for public health monitoring. High-profile diseases such as diabetes mellitus, ischemic heart disease, and even COVID-19 benefit from explicit representations, whereas less significant disorders may only appear as inclusion terms under a less specific name. Consider how in ICD-11, the term ‘late-onset asthma’ is merely an inclusion under the code CA23.32 Unspecified asthma, uncomplicated. Clearly, late-onset asthma is not unspecified, but, for classification purposes, it has been homed here[6]. This is sometimes referred to as the ‘shoreline’, with terms that qualify for their own code being said to be ‘above the shoreline,’ while those relegated to inclusions only are ‘below the shoreline’[7].

Case-mix Classifications

Classification can occur at multiple levels of abstraction to provide outputs suitable for a range of business requirements. Another well-known NHS classification is the Healthcare Resource Groups (HRGs), a casemix system organised into chapters and categories indicating resource use levels. Casemix is a classification method that assigns episodes of care to highly aggregated, but clinically meaningful, resource-homogeneous groups. Rather than manual allocation, HRG codes are assigned by a software application (known as a ‘grouper’) that ingests ICD-10 and OPCS-4 codes, along with other episode data, to determine the correct HRG code. NHS organisations primarily use HRGs to determine provider reimbursement, but they may also be used to support other high-level analyses[8].

Why Classifications Matter

Why use classifications if terminology already structures information? The answer is in the details. Terminologies are highly granular, offering an enormous number of individual, specific concepts, enabling clinicians to record exactly what they need to. However, this expressivity can hinder statistical analyses, as variations in the terms clinicians choose can make it challenging to identify trends. The strength of classifications is that they group granular concepts into manageable “buckets” of meaning that are well-suited to secondary uses such as analysing population health, determining reimbursement, or tracking mortality rates. Standardised categories designed to support specific, predetermined use cases enable researchers and policymakers to make valid comparisons across datasets.

Bringing It All Together

Clinical terminology forms the foundation of high-quality health data. It covers granular concepts—findings, diagnoses, procedures, and events—supporting precise clinical documentation at the point of care. Terminology targets specificity and necessary clinical detail for individual care.

Ontology powers up terminology. An ontological framework represents meaning in a computable format, enabling systems to infer and trigger intelligent actions, such as clinical decision support. Clinicians receive recommendations or relevant information to support timely treatment and can reinforce clinical guidelines.

Classification supports aggregation by grouping clinical data for reporting or analysis. Distinctly, classification categories are mutually exclusive and collectively exhaustive, ensuring data can be consistently grouped, but it sacrifices fine clinical detail for broader categories. Unlike terminology or ontology, classification is designed for counting and comparison, though terminologies and ontologies can be mapped to classifications to support the Collect Once, Use Many Times (COUMT) principle.

In summary, these three pillars work in concert:

• Terminology ensures precision at the point of care.

• Ontology provides the intelligence to use that data for decision support.

• Classification supports aggregated data for reporting and population health.

The below infographic provides some additional detail on how each tool functions, where its strengths lie, and why using them in isolation is not a good idea.

Information, Knowledge & Data

Conclusion

Effective management of computerised health information rests upon three essential pillars: Terminology, Ontology, and Classification.

• In Part 1, I introduced the concepts of terminology, which ensures precision at the point of care, and ontology, which builds on this to enable computer systems to reason and drive intelligent actions.

• In Part 2, I expanded the scope to classification, a system composed of mutually exclusive and collectively exhaustive categories that is well-suited for aggregation and population-level health analysis.

Crucially, I have argued for why all three are essential components of a mature digital health system. While each technology can be applied individually to achieve specific goals, the maximum benefits emerge from their joint use. When utilised in concert, these three distinct but complementary tools are fundamental for achieving consistent, high-quality, and semantically interoperable health data.

Author: Michael Harwood-Jones AdvFEDIP FHRIM MBCS

Michael is a specialist in controlled clinical vocabularies with almost two decades of experience in health classification, terminology, and information standards. His background includes roles in hospital administration, informatics, internal audit, education, and standards development.

Share

Additional References:

[1] Cs.aau.dk. (2018). T.S. Eliot on Knowledge and Exploration. [online] Available at: https://people.cs.aau.dk/~matteo/notes/quotes-ts-eliot.html [Accessed 23 Dec. 2025].

[2] Bowker, G.C. and Star, S.L. (1999). Sorting Things Out: Classification and Its Consequences. Cambridge, Mass.: Mit Press, [Ca.

[3] Guyan, K. (2025). The Rainbow Trap. Bloomsbury Academic.

[4] Nations, U. (2022). UNSD — Best Practices. [online] Un.org. Available at: https://unstats.un.org/unsd/classifications/bestpractices/ [Accessed 23 Dec. 2025].

[5] Hoffmann, E. and Chamie, M. (2003). Standard statistical classifications: Basic principles. Statistical Journal of the United Nations Economic Commission for Europe, 19(4), pp.223–241. doi:https://doi.org/10.3233/sju-2002-19401.

[6] Who.int. (2025). ICD-11 for Mortality and Morbidity Statistics. [online] Available at: https://icd.who.int/dev11/l-m/en#/http%3a%2f%2fid.who.int%2ficd%2fentity%2f577724120 [Accessed 23 Dec. 2025].

[7] Chute, C.G. and Çelik, C. (2021). Overview of ICD-11 architecture and structure. BMC Medical Informatics and Decision Making, 21(S6). doi:https://doi.org/10.1186/s12911-021-01539-1

[8] NHS Digital. (n.d.). HRG grouping. [online] Available at: https://digital.nhs.uk/services/secondary-uses-service-sus/payment-by-results-guidance/sus-pbr-reference-manual/hrg-grouping.

In this first article, I’ll introduce the concepts of terminology and ontology, describing what they are, their key characteristics, purposes, and uses in the healthcare context, including how the two can work together. In the next instalment, I will cover classifications and show why we need all three.

Background

As early as the 1990s, the handling of computerised health information that supports both direct and indirect patient care has followed three distinct stages: terming, encoding, and grouping[1]. Computers and technology have advanced significantly in the intervening decades, accelerated most recently by the advent of generative artificial intelligence (GenAI). Yet, despite this progress, the paradigm has largely remained unchanged, and these methods continue to constitute a significant component of information management strategies in healthcare systems worldwide. Three key technologies support these processes:

• Terminology for precise terming, supporting clinical practice and patient care

• Ontology for knowledge encoding, structuring the relationships between concepts

• Classification for aggregation and grouping, enabling business activities and analysis

Each technology, or pillar, plays a different but complementary role in the information lifecycle, from point-of-care to population-level reporting.

Terminology

If names are not rectified, speech will not accord with reality; when speech does not accord with reality, things will not be successfully accomplished.

– Confucius, Analects 13.3

Terminology refers to the specialised vocabulary and technical language employed within a domain[2], providing the precision necessary for effective communication and knowledge transfer among professionals. Medical terminology, for instance, constitutes a structured lexicon that articulates clinical concepts, relying on consistent word structures (such as roots, prefixes, and suffixes) to specify diseases, procedures, anatomy, and physiological processes.

Terminologies are composed of many individual concepts and may be arranged in a hierarchy or taxonomy based on shared properties or other certain characteristics. A concept is a unique, unambiguous representation of an idea within a knowledge domain. Each concept has a unique identifier, like a URI or code, and may include attributes, definitions, and synonyms. While terminology allows for relationships between concepts, extensive structuring and rigorous modelling of these relationships are the domain of ontology, not terminology.

Standardised clinical terminology refers to a systematically organised, computer-processable resource that arranges words and phrases into a set of concepts that consistently and uniformly represent their meanings[3]. This standardisation facilitates a consistent approach to indexing, storing, retrieving, and structuring medical record content, thereby minimising variation in how clinical data is captured and encoded, enabling semantic interoperability in electronic health records (EHRs).

Terminologies come in two distinct flavours: interface terminologies and reference terminologies.

• Interface terminology is a collection of healthcare words and phrases that allows clinicians to record precisely what is wrong with the patient at the point of care without losing detail. Supports interactions between clinicians and the electronic health record by facilitating data entry, user communication, and can present stored information back to users in a human-readable format.

• Reference terminology consists of well-defined concepts and their relationships, providing a standardised reference framework for comparing and aggregating healthcare data. Terms are connected through defined relationships and qualified by attributes, supporting precise interpretation. These relationships and attributes may be represented within information models and leveraged for data analysis, research, and clinical decision support[4].

Interface terminologies are commonly mapped to reference terminologies: the interface supports clinicians in data entry, while the reference structure standardises how that data is stored, managed, and analysed for clinical and administrative purposes.

Examples of clinical terminologies in widespread use are SNOMED CT, the world’s most comprehensive general clinical terminology, and LOINC (Logical Observation Identifiers Names and Codes), a common language for identifying health measurements, observations, and documents in medical laboratories.

In contrast to classifications, terminologies are non-exhaustive meaning that new terms are required to be added to ensure that new diseases and medical procedures, as well as changes to existing terminology, can be accommodated.

Section Summary

Terminologies are fundamental to high-quality health data, providing granular concepts that emphasise specificity and clinical reality. Their high expressivity enables precise documentation, supporting individual patient care.

Clinical terminologies can capture health information across all aspects of care, including symptoms, signs, investigations, diagnoses, procedures, and social care. Generally, terminology should encompass all required elements of a medical record. Some terminologies have broad coverage: findings, diagnoses, procedures, drugs, and devices (e.g. SNOMED CT). Others focus on specialist topics such as genomics and provide greater detail within a narrow scope (e.g. LOINC).

Ontology

If terminology describes the terms used in an area of knowledge, then ontology defines them. Gruber famously defined ontology as “an explicit specification of a conceptualization”[5]. More simply put, an ontology is a vocabulary of terms, together with the relationships between the terms.

The term ‘ontology’ originates in philosophy, where it refers to the study of being or existence. In the 1980s, the term was adopted by the AI community to describe computational models that enable automated reasoning. Today, there is growing interest in ontologies due to the recognition that capturing knowledge is key to building large, robust AI systems. Ontologies encode domain knowledge, making it processable by computers and reusable[6].

In general, ontologies include the following kinds of concepts:

• The entities that exist in the specified domain, called ‘classes’.

• The properties, or attributes, that characterise the classes

• The relationships that exist between them[7]

Ontologies are often equated with taxonomic hierarchies of classes, class definitions, and the ‘is a’ relation. They provide the logical rules and semantic framework that allow computers to “reason” over the data. For example, it allows a computer to understand that a “Femur” is a type of “Bone” and is part of the “Leg”. This machine-readable, logic-based structure relies on description logic languages like the Web Ontology Language (OWL).

The underlying structure of SNOMED CT is ontological and it uses a description logic profile. However, there are many other examples of medical ontologies such as the Gene Ontology and the Mondo Disease Ontology.

Formal Semantics in Action

If that still sounds rather abstract, let’s walk through an example using the SNOMED CT concept 74400008 |Appendicitis (disorder)|. Take the word ‘appendicitis’, it is formed from the root ‘append’, denoting the appendix, and the suffix ‘-itis’, meaning inflammation. Through this process of decomposition, a human can infer that appendicitis is inflammation of the appendix. However, in an ontology, such as SNOMED CT, this knowledge must be rendered within the conceptual model using the appropriate attribute values. By stating the relationship between the concepts for the appendix (Finding site) and inflammation (Associated morphology) we create a formal definition that expresses the equivalent meaning to appendicitis. This is a simple example of how terminology systems with ontological foundations can transform human-readable terms into structured, logic-based representations, enabling meaningful and accurate computer processing.

Ontology enables meaningful inferences.

Section Summary

• Once data is captured using precise terminology, its utility can be significantly enhanced by ontology.

• More than a list of terms; clinical ontologies are a formal, explicit specifications of the healthcare domain knowledge and define the relationships, properties, and constraints between clinical concepts.

• The ontological properties inherent in structured terminologies, like SNOMED CT, enable computers to understand the meaning of recorded terms and to reason over electronic health record data, thereby powering automated inference that can trigger intelligent actions, such as clinical decision support.

Conclusion

The foundation of computerised health information management remains rooted in three critical stages: terming, encoding, and grouping, supported by Terminology, Ontology, and Classification. Terminology provides the necessary granular concepts for precise clinical documentation and individual patient care. Ontology then builds on this by formally specifying the relationships between concepts, enabling computers to reason over the data and power intelligent actions like clinical decision support. These methods are fundamental for ensuring consistent, high-quality, and semantically interoperable health data worldwide.

Author: Michael Harwood-Jones AdvFEDIP FHRIM MBCS

Michael is a specialist in controlled clinical vocabularies with almost two decades of experience in health classification, terminology, and information standards. His background includes roles in hospital administration, informatics, internal audit, education, and standards development.

Share

Additional References:

[1] Stuart-Buttle, C.D., Read, J.D., Sanderson, H.F. and Sutton, Y.M. (2025). A language of health in action: Read Codes, classifications and groupings. Proceedings of the AMIA Annual Fall Symposium, [online] p.75. Available at: https://pmc.ncbi.nlm.nih.gov/articles/PMC2233183/ [Accessed 16 Dec. 2025].

[2] Merriam-webster.com. (2018). Definition of TERMINOLOGY. [online] Available at: https://www.merriam-webster.com/dictionary/terminology.

[3] Iso.org. (2025). Available at: https://www.iso.org/obp/ui/en/#iso:std:iso:17117:-1:ed-2:v1:en [Accessed 21 Dec. 2025].

[4] Nih.gov. (2025). Health Data Standards and Terminologies: A Tutorial. [online] Available at: https://www.nlm.nih.gov/oet/ed/healthdatastandards/02-300.html.

[5] Ontology by Tom Gruber, 2009. https://tomgruber.org/writing/definition-of-ontology.pdf

[6] David Patrick Stuart (2016). Practical ontologies for information professionals. London: Facet Publishing, Cop.

[7] W3.org. (2025). OWL Web Ontology Language Use Cases and Requirements. [online] Available at: https://www.w3.org/TR/webont-req/ [Accessed 21 Dec. 2025].

TL;DR ICD-11 adoption in the UK depends on successful integration with NHS workflows and a clear demonstration of benefits over costs. Variation in processes across the four nations complicates the transition; thus, a compelling case for change is critical.

Key points

• A published roadmap and formal approval are essential prerequisites for ICD-11 adoption, outlining NHS requirements, timelines, and necessary support for system changes.

• Ongoing reforms to English health services will influence the ICD-11 transition process. The abolition of NHS England and the transfer of its responsibilities to the Department of Health and Social Care, involving significant workforce reductions, are disrupting teams and may change how new standards are formally adopted.

Background

The International Classification of Diseases (ICD) is a globally recognised, health classification system developed and maintained by the World Health Organization (WHO). It provides a framework for standardised recording, analysis, interpretation, and comparison of data on health conditions, injuries, and causes of death. ICD is built of standard units of meaning, called codes, that are instrumental to effective health service management, data analysis, and study of epidemiology, enabling the:

• monitoring of disease prevalence

• tracking of emerging health trends

• efficient allocation of resources

• planning of public health interventions

The 11th revision (ICD-11) was endorsed by the World Health Assembly in 2019, and formally came into effect on January 1st 2022. This latest version features a revised structure that reflects advances in the life sciences and current medical diagnostic criteria. Postcoordination, which allows combining codes for more detailed descriptions, and cluster coding, which groups related codes, are key technical enhancements that enable clinical concepts to be recorded with greater specificity compared to previous versions.

At present, the NHS mandates the use of ICD‑10 5th Edition (2016) under ICD-10 Information Standard SCCI0021 for coding all hospital episodes. Causes of death are also coded using ICD-10 in the IRIS software, which automates coding for the majority of cases in accordance with internationally agreed-upon rules.

ICD-10 has served reliably but has limitations in capturing modern clinical concepts, prompting a shift toward ICD-11. Field trials ran from 2017 to 2018, with findings reported in January 2020. Since then, open discussion on ICD-11 progress has been limited, and implementation remains in its preliminary stages.

The NHS is a mature health system that relies on a diverse ecosystem of technical and information standards to support its data pipeline and business operations. Adopting ICD-11 in the UK depends on how well it integrates with these existing workflows. Furthermore, differences in health service structures across England, Scotland, Wales, and Northern Ireland add complexity and require coordinated planning.

Governance

The UK is planning its transition to ICD-11, but no firm date has been set. The move faces challenges, including the need for technical system upgrades and adjustments to support new workflows. Clear benefits and cost considerations are essential to gain governance approval.

The adoption of ICD‑11 requires formal approval within the UK’s information standards framework. Responsibility lies with the Secretary of State for Health and Social Care, but authority is delegated to the Data Alliance Partnership Board (DAPB) and subsequently to the Data Assurance Board (DAB), which reviews and approves new or updated standards[1].

The UK WHO‑FIC Collaborating Centre is housed within NHS England’s Transformation Directorate and provides leadership on morbidity coding matters. Meanwhile, the Office for National Statistics (ONS) leads on mortality statistics, ensuring death registrations align with international standards.

This multi-layered governance ensures ICD‑11 adoption will be thoroughly evaluated within broader policy priorities.

The Climb Ahead

Transitioning to ICD‑11 is not a simple upgrade. It requires:

• Developing a national roadmap to replace ICD‑10 with ICD‑11 as the mandated information standard

• Securing approval from governance boards to publish ICD‑11 formally

• Allocating resources and support for NHS organisations and suppliers to adapt systems and workflows

• Training frameworks to prepare coders, analysts, and clinicians for the new classification

This transition coincides with major reforms in England’s health services, further complicating the adoption of ICD-11. The government’s abolition of NHS England, with a two-year transition to the Department of Health and Social Care, is expected to impact up to 18,000 jobs[2]. These changes create uncertainty for teams responsible for digital and data standards and alter the established approval pathways for implementing new information standards.

Morbidity Coding

Although no official roadmap or timeline has been published yet, we do know that planning is underway. Business case development in England is ongoing to secure funding for implementation. Collaboration occurs through two key groups:

• The Digital Vocabularies UK Strategy Board, which addresses strategic WHO‑FIC matters

• The UK Classifications Technical Advisory Board, which focuses on technical issues

A national training framework is also planned and will be informed by an upcoming training needs assessment. Training will initially target central teams across the devolved administrations, with wider rollout to follow as implementation plans progress[3].

Mortality Statistics

Various agencies are involved in the production of mortality statistics across the UK.

• In England and Wales, the ONS is responsible for coding registered causes of death, and currently uses ICD-10.

• National Records of Scotland (NRS) also uses ICD-10 to code deaths occurring within Scottish borders. An NRS medical coder reviews this coding before it is finalised for analysis.

• NISRA (Northern Ireland Statistics and Research Agency) does not code its own cause-of-death data and relies on ONS to undertake this work on their behalf. ONS returns coded cause-of-death data monthly. NISRA publishes provisional weekly stats based on a lexical analysis which are reviewed quarterly and revised using the completed ICD-10 coding.

At a recent Health Statistics User Group meeting, the ONS confirmed that it will move to ICD-11, but is unable to provide a timeline. A team within ONS is leading on ICD-11 implementation for mortality statistics, and includes representatives from NRS, and NISRA. Current discussions are focussed on whether ICD-11 will affect trend and time-series analyses of specific causes of death. It was said that a period of dual-coding would be necessary to ensure that the transition to ICD-11 does not disrupt this[4].

Another key challenge for the ONS is that its existing infrastructure is currently incompatible with ICD-11 extension codes. The ONS has begun assessing the impact of using extension codes throughout the death statistics lifecycle, considering effects on cause coders, analysts, and the users of published statistics.

The ONS is developing tools to enable ICD-11 implementation. They will continue to test and refine their approach to using extension codes as ICD-11 encoded data becomes available [5].

Partial Adoption

Scotland has taken a notable step by implementing ICD‑11 Chapter 06 Mental, behavioural or neurodevelopmental disorders within its mental health services since November 2022. However, ICD‑11 is not yet integrated into national data flows, meaning coders still rely on ICD‑10. To bridge this gap, Scotland developed a lookup tool mapping ICD‑11 codes to ICD‑10 equivalents[6].

Conclusion

ICD-11 offers the potential for more comprehensive and adaptable health data. While ICD-10 remains the foundation for both mortality and morbidity reporting, preparatory activities are in progress, supported by established governance structures, business case development, and planned training initiatives.

However, several key challenges emerge from the UK’s progress:

1. Approval needed: Formal approval is necessary from information standards boards (like DAPB/DAB), along with a strong business case proving benefits outweigh costs.

2. Systems coordination: The NHS’s use of diverse technical standards and the variance in systems across devolved administrations requires coordinated national planning.

3. Governance changes: English health service reforms create uncertainty, potentially complicating the approval process.

4. Technical gaps: Systems and infrastructure must adapt to ICD‑11’s technical requirements, such as extension codes.

5. Training needs: A national training framework is required to prepare coders, analysts, and clinicians.

6. Partial adoption is not an option: Scotland has implemented one chapter of ICD-11 since November 2022, demonstrating a practical, though not yet fully integrated, start to ICD-11 use that depends on workarounds.

ℹ️ More Information

• Interested parties can follow updates on ICD‑11 adoption via the Terminology and Classifications Delivery Service page on the NHS England Delen website: https://nhsengland.kahootz.com/t_c_home/view?objectID=67558064

• For more information on ICD-11 in general, I can recommend this BMC Medical Informatics and Decision Making special supplement on ICD-11: https://link.springer.com/journal/12911/volumes-and-issues/21-6/supplement

Reminder: NHS England has opened the ICD-11 MMS Impact Assessment Questionnaire, allowing anyone with an interest to provide feedback on anticipated impacts.

Author: Michael Harwood-Jones AdvFEDIP FHRIM MBCS

Michael is a specialist in controlled clinical vocabularies with almost two decades of experience in health classification, terminology, and information standards. His background includes roles in hospital administration, informatics, internal audit, education, and standards development.

Share

Additional references

1. “Governance of information standards - NHS England Digital.” NHS Digital, https://digital.nhs.uk/data-and-information/information-standards/governance. Accessed 11 December 2025.

2. “Billions to be redirected back into patient care with NHS reform”. Department of Health and Social Care, 11 November 2025, https://www.gov.uk/government/news/billions-to-be-redirected-back-into-patient-care-with-nhs-reform. Accessed 11 December 2025.

3. Bracewell, Lynne, and Myer Glickman. UK WHO-FIC Collaborating Centre Annual Report 2025. 2025, https://www.who.int/news-room/events/detail/2025/10/13/default-calendar/who-fic-network-annual-meeting-2025. Accessed 11 December 2025.

4. Health Statistics User Group, Webinar on Mortality Statistics-11th December 2025, https://www.statsusernetwork.ons.gov.uk/event/webinar-mortality-statistics-11th-december-2025

5. Quayle, Gemma, et al. ICD-11 implementation activities for mortality statistics in England and Wales. 2025, https://www.who.int/news-room/events/detail/2025/10/13/default-calendar/who-fic-network-annual-meeting-2025. Accessed 11 December 2025.

6. “Mental health: implementing the International Classification of Diseases 11th edition.” The Scottish Government, The Scottish Government, 10 October 2022, https://www.gov.scot/publications/mental-health-implementing-the-international-classification-of-diseases-11th-edition/. Accessed 11 December 2025

TL;DR – Successfully leveraging terminology maps requires initial groundwork to confirm the map’s trustworthy origin, verify its precise version and edition compatibility with your data, and assess its suitability for your specific use case. Never underestimate the complexity of health classification systems; always consult with an expert to ensure accurate data interoperability and reduce the risk of critical misinterpretation.

When thinking about applying a map to your data, I recommend following these four preliminary actions to make a successful start:

• Establish Provenance

• Ensure Compatibility

• Assess Map Type and Scope

• Seek Expert Guidance

I’ll expand on each of these topics below ⬇️

What is a map?

ISO 21564:2025 defines a terminology map as a

“device which provides an index from one term to another, sometimes using rules that allow translation from one representation to another indicating degree of equivalence”

In plain English, maps convert codes from one vocabulary into another, so that data can be standardised or exchanged in a format that makes sense to the receiver.

When deploying a map, you must first consider its origin. Do you know if it is from a trustworthy source? Terminology mapping can be a challenging process, so you’ll want to know whether appropriately qualified people created the map you have, with a high standard of quality assurance. You can check out the SNOMED CT Mapping Guide for more details on the mapping process itself

SNOMED International publishes maps linking SNOMED CT to other international standards. National Release Centers (NRCs), responsible for distributing SNOMED CT within countries, may also publish maps to national code systems. Always use reputable sources for high-quality maps.

ℹ️ More information → https://www.snomed.org/maps

“But our terminology is in another castle”

So you have a map from a trusted source - great! Next, we need to check that the map is compatible with the code systems used to record our data. This can mean checking:

• The last versioned date of the map

• That the map is for the correct edition

Terminologies and other clinical coding systems are updated as medical knowledge and health care methods evolve. To remain relevant, these systems must add, remove, and update content. Release schedules vary by product, and some have better mechanisms for tracking these changes. Make sure the map is contemporaneous with the data you are working with, or you’ll have to deal with deleted, inactive, or otherwise non-existent codes.

Also, confirm your map matches the edition of the code system used. For instance, some countries create national ICD-10 modifications—such as ICD-10-CM. To ensure valid comparisons, verify that the map is built for the applicable source and target editions. Note that a modification produced by one country may also be used in other jurisdictions.

Limit break

Maps are a tried-and-tested way to convert data recorded in one standard to another and have been the backbone of data interoperability for decades. However, they are not without their foibles and limitations. SNOMED International publishes maps using several specification types to support the requirements of different mapping use cases. Consequently, you’ll need to assess whether the map’s intended application suits your purpose.

Simple maps are - as the name implies - simple, and usually represent a ‘one-to-one’ relationship between the source and target code systems. Complex and extended maps may require extra consideration, as they often involve multiple targets and have baked-in rules, making the mappings less straightforward to resolve.

ℹ️ More information → https://docs.snomed.org/snomed-ct-specifications/snomed-ct-release-file-specification/reference-set-release-file-specification/5.2-reference-set-types/5.2.3-map-reference-sets

Be careful not to assume that similar-sounding maps are the same. For instance, the SNOMED CT to ICD-10 map from SNOMED International provides a single conceptual match except in specific logical scenarios. In contrast, the classification map produced by NHS England presents users with multiple alternative map targets that require human intervention to resolve. Map development is use-case-driven, so the method and guiding principles used to generate the map may differ, even when it’s for the same two code systems. Always review the relevant documentation to confirm the intended use case and the map’s design features.

“It’s dangerous to go alone.”

Maps are valuable tools, but as in orienteering, you also need a compass to navigate the terrain, or you might end up going in circles. Here, your compass is a friendly expert who understands the code system(s) in use and can help you move in the right direction. All clinical terminologies and health classification systems have unique features and editorial principles that shape how data are represented. This shouldn’t be underestimated—so, to reduce the risk of misinterpretation, always reach out for advice when needed.

This article highlights some key initial steps for validating the use of a terminology map for healthcare research or analysis. I’ve kept things simple and brief, but I hope this will be a useful starting point for any folks considering using a terminology map in their project. If there’s anything you’d like to add that might help, or if you’d like to know more about this topic, please leave a comment or reach out.

Author: Michael Harwood-Jones AdvFEDIP FHRIM MBCS

Michael is a specialist in controlled clinical vocabularies with almost two decades of experience in health classification, terminology, and information standards. His background includes roles in hospital administration, informatics, internal audit, education, and standards development.

Share