Semantics in action: a guide for representing clinical data elements with SNOMED CT

Abstract

Background

Clinical data is abundant, but meaningful reuse remains lacking. Semantic representation using SNOMED CT can improve research, public health, and quality of care. However, the lack of applied guidelines to industrialise the process hinders sustainability and reproducibility. This work describes a guide for semantic representation of data elements with SNOMED CT, addressing challenges encountered during its application. The representation of the institutional data warehouse started with the guidelines proposed by SNOMED International and other groups. However, the application at large scale of manual expert-driven representation led to the development of additional rules.

Results

An eight-rule step-by-step guide was developed iteratively through focus groups. Continuously refined by usage and growing coverage, they are tested in practice to ensure they achieve the desired outcome. All rules prioritize maintaining semantic accuracy, which is the main goal of our strategy. They are divided into four groups which apply to understanding the data correctly (Context), and to using SNOMED CT properly (Single concepts first, Approved post-coordination, Extending post-coordination).

Conclusions

This work provides a practical framework for semantic representation using SNOMED CT, enabling greater accuracy and consistency by promoting a common method. While addressing challenges of large-scale implementation, the guide supports the drive from data centric models to a semantic centric approach, leveraging interoperability and more effective reuse of clinical data.

Background

Semantic interoperability in healthcare is held back by the incapacity to generate both semantically rich and easily computer-processable data. Data is often represented with use-case specific models, without explicit metadata representing its semantics. This inevitably leads to continuous low levels of interoperability. Attempts at building a global terminology have led to very broad coverage and important challenges at keeping global coherency [1].

Hospital-wide semantic representation is a major challenge, as a precise, contextual, and consistent representation of clinical information is necessary. At Geneva University Hospitals, a large hospital consortium, the institutional data warehouse (DWH) is a NoSQL database. It holds data generated by operational activities in near real time and is populated from multiple source systems. Over 150 ′000 data elements are stored in collections with varying ad hoc structures which often don’t accurately portray their intended meaning. The collection names, variables, and their assigned value sets are often unclear [2]. The most deterministic approach is to represent the meaning of data as it is acquired. Data models, however, most often represent data as it will be used. Additionally, data models often do not refer explicitly to a strong semantic ontology, limiting proper reuse of clinical data [3]. When representing data elements, one must first understand them, as slight variations can change the meaning drastically. Formularies, for example, contain information surrounding the label, often lost when storing data. Considering the data element’s acquisition context requires human interpretation by accessing the patient record. Since meaning goes beyond the label of a data element, a proper semantic description often cannot be done at that level.

Tools to support automatic semantic annotations have been shown to be lacking [4, 5]. The structure of clinical databases is not sufficient to allow these processes without information loss, and manual correction and verification is necessary [6, 7]. Therefore, though time- and resource-consuming, manual representation can become a real asset to leverage data accurately and consistently.

SNOMED Clinical Terms (SCT) is one of the most comprehensive explicit formal representations of meanings in healthcare [8, 9]. It contains more than 360,000 concepts, three million relations [10], and a compositional grammar allowing for post-coordination (PC) [11]. PC limits combinatorial explosion while allowing to represent an almost infinite number of concepts [12]. As there are often multiple ways to express the same thing, a consistent approach is important to limit redundancy [13]. As a unique contender to leverage semantic interoperability in healthcare, SCT’s adoption has been growing steadily [14,15,16,17,18,19], but its implementation has been slow [20, 21]. This requires a clear, reproducible guide to reach maximal efficiency, and a learning process to become familiar with using SCT. Existing guidelines, which are discussed in further detail in Sect. " Comparison to existing guidelines", do not cover all bases.

The main contribution of this work is a set of pragmatic rules for semantic representation of clinical data with SCT. It summarises the work of the team dedicated to this process, with various levels of seniority, clinical knowledge, and experience with SCT. We describe the elaboration of new rules through an iterative process and demonstrate practical examples. We hope that by sharing this process and its outcome, the necessity for human intervention and manual representation can be demonstrated. Furthermore, a common, DWH-agnostic, approach to semantic representation can lead to homogenous outcomes in heterogenous settings. This has the potential to contribute a significant improvement to semantic interoperability, particularly in multi-institutional settings. A semantically centred approach to leveraging real world clinical data can better support care processes, research and public health [22].

Methods

The guide presented in this work results from a long-term semantic representation effort with the goal of bringing semantics to the institutional DWH. As this process grew organically in scale and complexity, it was gradually complexified and rules were defined in focus groups. The creation of the guide depends on two core elements: a framework to teach and harmonise semantic competency within the team, and a creation cycle allowing the curation of a set of rules.

Competency building

The process to teach the use of SCT is based on three pillars designed to be followed in order. First, newcomers follow the basic training courses and documentation made openly available and curated by SNOMED International (SI) [23]. These are sufficient for one-dimensional representation such as a patient problem list value set [24]. The second pillar is made of internal documentation and practical work. These give trainees a deeper understanding of tasks focused on real data and local specificities, and the ability to semantically represent data. Finally, more advanced SI courses, such as the Authoring Course [25], are proposed for core members. These allow the person to discuss rules with the team and participate in the rule creation cycle described hereafter. Newcomers are supervised closely by a more experienced team member and moved on to more complex task when deemed sufficiently proficient.

This framework is designed to ensure production of a harmonised, stable guide by ensuring every participant in the discussion has a common background and vision.

Rule creation cycle

As more complex data elements are encountered in the process, PC becomes unavoidable. When items such as medical forms are added, SI’s rules become too restrictive, so task-specific rules must be agreed upon to maintain coherence. The creation cycle acts as a framework necessary to avoid losing track of an increasing number of internal rules. Indeed, the work started with a very open approach to semantic representation. It then evolved somewhat erratically over time, until the first set of rules emerged organically, and the harmonisation process started.

The cycle revolves around weekly focus groups comprising of team members which participate in the semantic representation effort. During focus groups, problematic situations and potential solutions are discussed. They are made up of a varying amount of people (2–5 depending on the team’s setup at that time) with heterogenous backgrounds (clinical, billing, bioinformatics, IT, students). The more experienced members all have proficient experience with SNOMED CT, including certification given by SNOMED International such as the Authoring Certification. Topics are defined based on the questions or problems each team member is currently working on. When an issue is identified, existing guidelines are thoroughly assessed to determine if they can solve the problem, and applied if that is the case. If the scope of existing guidelines is not sufficient, a new rule is necessary. For this reason, existing guidelines and ours were not formally compared on the same cases. When a consensus is reached through debate, it is put into practice, and evaluated for coherence with previous rules. This ensures the intended meaning is maintained and unambiguous. If satisfactory, it is added to the list, or re-discussed as needed. Earlier work is also reviewed with new rules to ensure they comply with previous versions. This process is repeated (Fig. 1) until rules are sufficiently tested, and constant evolution has led to the current guide.

Fig. 1

Cycle describing the method of elaboration of the guide

To accommodate the constraints of a relatively small soft-funded team with a high-turnover rate and limited time and resources, prioritization follows the Pareto principle [26, 27]. Most frequently instantiated collections are represented first, and only the data elements which account for around 80% of instances are represented. For example, data collections with high instances and clinical value such as the patient problem list and laboratory procedures were among the first done. The data elements in these collections are then ordered by count from largest to smallest, and manual representation is done until at least 80% of instances are covered. As work is done in parallel on separate tasks, no inter-annotator agreement studies are carried out. Specific problems are discussed during focus groups, and only unanimously agreed-upon outcomes are validated.

Results

The competency building framework and rule creation cycle have been applied for the past 4 years [2], resulting in the following set of rules. They apply first to fully understanding the data element’s meaning, then to representing that meaning accurately (Fig. 2). The rules are grouped into four categories: 1) Context, 2) Single concepts first, 3) Approved post-coordination, and 4) Extending post-coordination, which each contain two subrules. Semantic accuracy is the foundation of our strategy and the intended outcome of the guide’s application. This principle extends to all the following rules, and examples of how semantic inaccuracy can lead to meaning loss are given throughout. Most of the rules apply to more complex tasks, so concern mainly post-coordination. We follow an order of priorities, grouped into the four categories mentioned above, to use the simplest and least number of codes possible and to ensure consistency. A quick guide summarizing the rules and a detailed example of the application of the guide is available in Appendix A.

Fig. 2

A summary of the rules established and their intended sequence. After understanding the context (steps 1 and 2), the corresponding SCT expression is derived from one of the following steps depending on the complexity of the data element

Context

Context encompasses both the clinical acquisition context, i.e., patient and medical service characteristics, and the structural context, i.e., how fields are structured in a clinical form. Both are equally important to consider. When an unclear data element is encountered, context is needed to define it before representation.

Structural context

When representing fields from a clinical form, the following situation was encountered in the DWH: a form called “PF_0886”, with an id of “FORMIDOC_90” and label of “suites” (roughly translated to “what happens next”). Without further investigation, this field could be incorrectly represented as “308273005 |Follow-up status (finding)|”. However, after opening the EHR and finding the correct form (Obstetrics service—Pregnancy record) at the correct section (Post Partum), it can be correctly understood and represented (Fig. 3).

Fig. 3

Complete understanding achieved through visualisation of the data element’s structural context (translated from French)

Sometimes a data element encountered seems simple to represent, but is ambiguous or lacking detail, and context is needed to disambiguate it. The label “breast”, for example, can have different meanings when located in two different forms, once as a checkbox and once as part of a drop list. It is easy to represent both as “76752008 |Breast structure (body structure)|”, but that would be incorrect (Fig. 4). Although both are part of an “oncological history” section, one is about the patient, the other about the patient’s family.

Fig. 4

The term “breast” has different meanings depending on context in the electronic health record (translated from French)

Clinical acquisition context

The environment in which data is acquired plays an important role in the meaning attached to it. One example is the language used by the caregiver and the system. Most of our database is in French, but the most complete version of SCT is the International Edition, which only includes English descriptions. SCT is described as language-independent but was created by an English-speaking team, and therefore has an English-biased concept segmentation. If concepts are sufficiently defined, their relations should unambiguously convey the intended meaning. However, considering the large number of primitive concepts with little or no stated attribute relations, errors remain possible. Specific care must be taken to avoid semantic shifts to properly represent French expressions in English concepts while conserving meaning. Even words which are lexically identical can be semantically opposites, and just translating the labels of data elements can lead to major errors. For example, in English, nyctalopia is defined as the inability to see in low light, or night-blindness [28]. In French, it is the opposite, as nyctalopie is the ability to see in low light [29]. Abbreviations can also mean different things, such as BAV, which in French can mean “Bloc auriculo-ventriculaire” (233917008 |Atrioventricular block (disorder)|) or “baisse de l’acuité visuelle” (13164000 |Reduced visual acuity (finding)|). The temptation to use the first code which comes to mind must be resisted and the context understood first.

Single concepts first

It is important to be as precise as possible by choosing the most granular code, preferably with single concepts first. Granularity increases as one descends a hierarchy, as children are refinements of their parents [30, 31]. There are different ways to ensure use of single codes first to avoid unnecessary PC.

Exploration

The first is by exploring SCT’s poly-hierarchy and inferring attributes from parent concepts. One concept often has multiple parents, to which it is linked by “is a “ relationships [30], and multiple descendants which are linked to it by the same relationship. By exploring the parents, children of neighbouring branches, and semantically similar terms (“tree-walk” [12]), the most appropriate concept to use can be located [32]. When deciding which concept to use, choosing the correct hierarchy, and paying close attention to the synonyms, descriptions, and relationships is very important. For example, take the French term “thrombaphérèse”. When searching for the equivalent concept with “thrombapheresis” or “thrombopheresis”, no results appear in SNOMED CT’s browser. However, by searching for a similar term such as “plasmapheresis”, then exploring its parents and its children, the appropriate term of “plateletpheresis” can be found (Fig. 5).

Fig. 5

Exploring the SNOMED CT hierarchy to find the appropriate concept by (1) finding a similar term, then (2) exploring its surrounding concepts

When there is no sufficiently precise single code, using a more general concept should be avoided as it is preferable to avoid any information loss.

Inference

As stated above, inference is already included in SCT with stated and inferred concept definitions [33]. Using clinical knowledge and common sense, inference is also possible by the annotator when certain details are inferred from the context with a high level of confidence. This allows the use of a single code which appears less precise but is complete. When representing the concept “fracture of the tibial tuberosity”, there are multiple options available (Fig. 6). The pre-coordinated expressions available have additional information on fracture morphology, so PC seems the best option at first. In clinical settings however, the distinction between open and closed fractures is generally only made when the former is true. Therefore, if a fracture is not explicitly described as open, it can be considered closed, and a single code chosen to represent it without losing any information. The opposite applies to wounds, which are considered open by default.

Fig. 6

Inferring information to avoid unnecessary post-coordination

Approved PC

When post-coordination becomes unavoidable, different styles means there are different ways to express similar meanings [34, 35]. While this is unavoidable, rules are necessary to maintain consistency as much as possible.

Multiple focus expressions

First use multiple focus expressions, which are usually limited to concepts from the same top-level hierarchy [36]. When representing the clinical concept “post-infectious reactionary bacterial arthritis”, two SCT concepts encompass almost all the required information: “12913305 |Post-bacterial arthropathy (disorder)|”, and “239783001 |Post-infective arthritis (disorder)|”. They are neither equivalent nor complete however, as information on inflammatory morphology and bacterial causality, respectively, is missing. PC is therefore required. Combining the two gives a fully defined term and allows representation with a high level of precision while avoiding complex PC (Fig. 7). When semantically equivalent representations exist, always choose the simplest one.

Fig. 7

Different but semantically equivalent ways of using post-coordination

Refinements

The next step is to use PC with refinements defined by SI, which becomes complex with the addition of attribute groups and nested refinements [37]. This must be done in compliance with SI’s rules, but will not be detailed specifically as sufficient guidelines exist from SI and others. Referring to the MRCM and Editorial Guide is generally sufficient for proficient refined PC [38, 39].

Extending PC

Despite SCT’s extensiveness [40, 41], challenges inevitably arise when no pre-coordinated expressions or approved post-coordination fit. In this case, extending SCT’s compositional grammar and editorial guidance is the only solution. Such changes modify the MRCM and must be added to the institution’s classifier to avoid classification issues, which can be a complex process. Different examples are shown in Table 1.

Table 1 Attribute extensions and use of unapproved attributes

Domain and range extensions

The first way is by using approved attributes in situations that resemble what they have been approved for. This can be done by extending an attribute’s domain, range, or both. Since these are approved attributes, maintaining coherency with current rules is mandatory, which means that definitions of attributes cannot be changed. For the attribute “255234002 |After (attribute)|”, “ < < 71388002 |Procedure (procedure)|” has been added to the domain, but the range and definition remain unchanged, only expanding the scope.

New attributes

As a last resort, unapproved attributes should be used sparingly, as they may disappear or change in future SCT versions. They are useful for refining hierarchies which have no approved attributes, such as “410607006 |Organism (organism)|”, and for representing scalar values such as sizes [42]. To ensure consistent use, a complete set of domain, range, cardinalities, and definition must be validated. These new attributes, if correctly classified, can then be submitted to the national SNOMED centre for further approval if necessary. As always, but especially for new attributes, all expressions are reviewed extensively during focus groups to ensure semantic equivalence with the source data and a uniform approach.

Discussion

As of November 2024, 97′930 data elements are represented with 41′345 distinct SCT expressions, including 18′175 distinct PC expressions. These numbers demonstrate two things: using SCT allows handling of redundancy efficiently, and post-coordination is inevitable to properly represent meaning. A snapshot of the representation results demonstrating Pareto’s Principle is given in Fig. 8. This work shows that large-scale manual encoding of categorical content is doable, and sustainable, even with a limited budget. Having a guide to follow leads to less errors and more consistent representation [43].

Fig. 8

Pareto principle in practice, on average 23% of data elements represent 86% of instances for the examples given

Comparison to existing guidelines

This work is based on guidelines from both SI [23], whose grammar rules and scope are maintained wherever possible, and existing guidelines by other groups [41, 44,45,46,47,48,49,50]. Both were reviewed thoroughly and applied, when possible, but a full review or comparative evaluation is beyond the scope of this article.

To our knowledge, only Hojen et al. published guidelines on the practical use of SCT [44] across entire EHRs, focusing mainly on chosen hierarchies and PC. We intend to add to this work by exploring other problem areas. Other guidelines focus on specific clinical settings or conditions, such as diabetes [45, 46], palliative care [47], or the patient problem list [48]. This clearly impacts the development of these guidelines as rules defined for a specific context do not need to apply elsewhere. Common rules exist between these publications (Table 2), but no single one is included in all, highlighting the different methods applied.

Table 2 A comparative view of existing guidelines

Most authors agree on the importance of consistent and precise representation. Interestingly, authors mentioning PC often agree that current SI rules are too restrictive, and apply varying methods to counter that, using unapproved attributes [47] or combinations [44, 48]. Which hierarchies to select is the most recurring theme considering its importance to semantic accuracy, whether approached in detail [44] or broadly [45,46,47]. Clinical context is discussed in detail in only one other work [47], and is otherwise only mentioned in reference to the situation with explicit context hierarchy [45, 46]. Other related works focus on resolving specific issues, such as choosing between two hierarchies [49] or inter-coder agreement [34, 35, 50]. However, these often rather describe a method for selecting what to represent. Others mention similar principles such as context, exploration, or minimizing codes, but are not focused solely on SCT or discuss annotation of narrative text [32, 50, 51]. Others yet create local extensions with new attribute relationships to represent their needs [41].

In comparison to most of the guidelines, which are tailor-made for a specific clinical setting or disease, we have opted for general guidelines which can be applied to most settings. The iterative creation process used along with the heterogenous data elements encountered means that many possible scenarios have been encountered. This, coupled with the step-by-step approach, give us hope that these guidelines can be reproduced in different settings without too much difficulty.

Limitations

This document is not exhaustive, and some aspects, such as handling of inactive terms, are not addressed as a solution for this issue has not been implemented. A possibility would be to regularly run a check against the latest version to identify outdated codes, and apply established methods [47, 48] using historical relationships to find replacements. Likewise, existing guidelines which are sufficient, such as choosing hierarchies, are not repeated as focus is on expanding or developing rules.

This guide has only been applied within the author’s environment, meaning it might not be immediately applicable in other settings. This is the subject of future work described in Sect. " Future work".

One significant limitation is that, despite repeated evaluation of application of the guidelines, no formal quantitative evaluation was performed, for various reasons. First, the guide evolved organically with the work done by the team and was initially only intended for internal use. Secondly, as there are, by design, different ways of expressing things in SCT, the goal of the guide is not to have exact matching of outcomes, but rather to ensure that semantic accuracy of representation is maintained. Therefore, two different expressions can both be correct, and this would not appear in a formal inter-annotator agreement.

The use of unapproved attributes also limits interoperability due to non-compliance with the MRCM. Steps are taken to limit this, such as checks for logical equivalence with precoordinated concepts and ensuring correct classification [52].

Rules can sometimes contradict each other, as priorities for representation can vary between reproducibility and expressivity, or between what is best for machines and what is best for humans [53]. Therefore following this guide step-by-step will not always be possible, and steps may need to be skipped at times.

This work focuses exclusively on the use of SCT for semantic representation and does not approach topics such as standards used to structure, format, and exchange data. This is not an evaluation of the structure, strengths, or weaknesses of SCT, nor is it a comparative work between standards. The subjects of multi-terminology representation, semantic graphs, automatic annotation tasks, and use-case specific models are out of scope of this work.

Future work

Some important topics which are being worked on include negation and uncertainty, dealt with using new attributes. However, this has been only partly resolved, and is subject to change. These vast topics are the focus of ongoing work.

Incorporating these guidelines for manual representation to the work done on automatic or semi-automatic annotation using natural language processing (NLP) by other members of our team is also being explored but is still in preliminary stages.

As PC support is not trivial and SCT is not the only standard used in the DWH, a system to handle PC and other standards has been created using graph database technology. We believe graph databases to have huge potential for bridging between data and semantics, to facilitate querying of heterogenous data and exploring semantic connections which were not otherwise apparent. It also allows for the possibility of adding further representations with data models or other terminologies. The result, a new semantic graph which can represent data in various formats such as OMOP, FHIR, and i2b2, is the focus of a subsequent article.

Finally, talks are ongoing with other institutions to implement this strategy in different environments, which would help in demonstrating its generalizability.

Conclusion

When using SCT to represent data elements, a structured method is necessary. While existing guidelines are adequate at first, over time they become insufficient to represent a large proportion of terms adequately. Frequently encountered issues are analysed during focus groups, and solutions reached by consensus. Through trial-and-error, rules are established for general use of SCT. By adhering to a method for representation, semantic accuracy can be maintained, and use of time and resources optimised. This scalable and adaptable guide can be applied to various settings, leading to improved semantic interoperability for secondary usage of clinical data.

Appendices

Appendix

Quick guide for representation

Semantic accuracy

There are multiple ways to say the same thing in SNOMED CT (SCT), and different encoders will inevitably use different concepts to represent the same data element. However, the meaning can and must be maintained, and opting for semantic equivalence rather than exact matching allows a concept to be represented in more than one way while retaining its meaning.

Structural context

The information surrounding the data in a form, or where it is located within the database can be useful information to determine its meaning.

Clinical acquisition context

The intent of the healthcare professional that used the term in question is difficult to determine exactly, but the representation they had of that element must be deduced from the context.

Exploration

Exploring hierarchies by searching the parents of similar terms, as well as the children of neighboring branches, can help locate the most appropriate concept.

Inference

Some implied information can be added if it does not modify the semantic accuracy of the concept.

Multi focus expressions

Post-coordination should be done as simply as possible, first with simple associative post-coordination, combining concepts from the same hierarchy.

Refinements

Following SCT’s guides for using attribute relationships to further refine precoordinated concepts.

Domain and range extensions

Expanding on SCT’s MRCM by extending domain and ranges for attributes already approved by SI.

New attributes

Adding complete MRCM rules for previously unapproved attributes allows refinement of previously inaccessible hierarchies or concepts, greatly expanding the scope of representation.

Example of implementation