WASP—A Web Application to Support Syntactically and Semantically Correct SNOMED CT Postcoordination

Abstract

Expressive clinical terminologies are of utmost importance for achieving a semantically interoperable data exchange and reuse in healthcare. SNOMED CT, widely respected as the most comprehensive terminology in medicine, provides formal concept definitions based on description logic which not only allows for advanced querying of SNOMED-CT-coded data but also for flexibly augmenting its 350,000 concepts by allowing a controlled combination of these. This ability for postcoordination largely increases the expressivity of the terminology but correlates with an intrinsic complexity. Complicated by the current lack of tooling support, postcoordination is widely either ignored or applied in an error-prone way. To help facilitate the adoption of postcoordination, we implemented a web application that guides users through the creation of postcoordinated expressions (PCEs) while ensuring adherence to syntactic and semantic constraints. Our approach was largely facilitated by making use of the extensive SNOMED CT specifications as well as advanced HL7 FHIR Terminology Services. Qualitative evaluations confirmed the usability of the developed application and the correctness of the PCEs created with it.

1. Introduction

Semantic interoperability is the fundamental prerequisite to allow a meaningful exchange and secondary use of electronic health data. Because of the idiosyncratic nature of human language, using clinical terminologies is indispensable to standardize individual expressions into a universally machine-interpretable interlingua [1]. While a multitude of controlled vocabularies are readily available, the potential benefits for data analytics and reuse are strongly intertwined with a terminology’s expressivity and adaptability [2].

SNOMED CT is widely recognized as the most comprehensive and expressive interlingua in medicine [3], due to its large scope of currently about 350,000 concepts and its use of formal description logic entailing machine-interpretable concept definitions. Despite this immense coverage of contents, SNOMED CT’s hundred of thousands of predefined, “precoordinated” concepts are no match for the expressiveness of natural language [4]. However, adding any conceivable unit of meaning as a separate concept would lead to a combinatorial explosion, rendering the terminology cluttered and unusable. Putting its ontological foundation to work, SNOMED CT allows for an alternative solution via postcoordination [5,6].

Postcoordination refers to the controlled combination of existing SNOMED CT concepts to form a new unit of meaning. Therefore, two or more concept identifiers are combined in a well-defined way to build a postcoordinated expression (PCE) [7]. To ensure the machine readability of the created PCE, SNOMED CT employs its Compositional Grammar as the syntax specification and its Concept Model to sanction reasonable combinations of concepts. Adhering to these constraints is necessary to generate correct PCEs but correlates with the challenges inherent in powerful yet complex instruments. Due to a current lack of adequate tooling support, responsibility is passed on to the user, requiring intricate expertise of the aforementioned specifications. Thus, uptake of postcoordination is often hesitant [8] and error-prone.

Mirroring the international trend, the same issue is becoming apparent in Germany’s recent adoption of SNOMED CT. After joining SNOMED International in 2021, SNOMED CT concepts have been eagerly introduced in various national initiatives and standardization endeavors [9]. Postcoordination, on the other hand, is either avoided altogether, as in the case of the Medical Informatics Initiative (MII) [10], or used as a last resort, such as in the Medical Information Objects (MIOs) [11] of the National Association of Statutory Health Insurance Physicians (NASHIP, in German: Kassenärztliche Bundesvereinigung, KBV) [12]. Qualitative evaluation of the postcoordinated expressions employed in the latter revealed several inaccuracies, thus showing the necessity for software supporting the creation process.

To help overcome these barriers and facilitate the international adoption of postcoordination, we aimed to develop an integrated web application guiding the user through the creation process of postcoordinated expressions while ensuring syntactic and semantic correctness.

Related Work

While a growing number of publications demonstrates the usefulness of SNOMED CT postcoordination [13,14,15], a review of previous work carried out in the context of PCE-supporting tooling yielded only sparse results. SNOMED International, the organization responsible for SNOMED CT, reportedly applies various dedicated software tools during authoring tasks. These include guidance for authoring concept definitions, which would likely be feasible to employ for creating postcoordinated expressions as well. Alas, these tools are not available to the public. Other projects found are either outdated [16] or incomplete [17]. Recently, SNOMED International has begun to develop a publicly available application with a seemingly similar objective, but it has not yet been finalized and is thus difficult to assess [18].

Moreover, a number of publications have explored other approaches of supporting SNOMED CT postcoordination, largely employing machine learning but yielding only mixed results [19,20]. A very recent article by Castell-Diaz et al. depicts a promising approach to automatically generating PCEs by using knowledge graph embeddings. However, this approach has significant limitations when dealing with more complicated postcoordinated expressions [21].

2. Materials and Methods

Building on the authors’ knowledge gained in previous projects [15,22], the overall architecture of the envisioned application was conceptualized as shown in Figure 1, and the required materials and components were identified.

SNOMED CT can be described as a highly formalized semantic standard, so that its extensive specifications could be employed within the application to guarantee compliance. To be syntactically and semantically correct, a postcoordinated expression (PCE) must adhere to the rules imposed by the Compositional Grammar and the Concept Model, respectively. Expression Templates offer an additional mechanism to further constrain the Concept Model for a particular use case, which was identified as a useful feature of the planned application.

Furthermore, using a dedicated terminology server was envisioned to avoid dealing with the complexities of SNOMED CT within the proposed application. Here, the HL7 FHIR Terminology Services offer a standardized interaction mechanism [23].

2.1. Compositional Grammar

The SNOMED CT Compositional Grammar specification [24] defines the syntax of SNOMED CT expressions, used both for the formal definition of precoordinated concepts as well as for PCEs. The overall structure is shown in Figure 2.

The basis for each PCE is the Focus concept (green), which can then be refined (purple) by adding Attribute relationships (orange). Each relationship consists of the Attribute itself (blue) and an Attribute value (red), both being SNOMED CT concepts as well. By surrounding them with curly braces, Attribute relationships can be grouped into Role groups (light blue) to imply a composite meaning.

The Compositional Grammar is formally defined in Augmented Backus–Naur Form and is needed within the project to develop a suitable user interface to transform the user’s input into the correct syntax and to parse an existing PCE for further editing.

2.2. Concept Model

The SNOMED CT Concept Model defines which combinations of Concepts and Attributes are allowed for concept definitions and PCEs. Therefore, the domain and range for each of the current 125 Attributes in SNOMED CT are specified.

The domain refers to the subset of possible source concepts for an Attribute relationship (the Focus concept in Figure 2) and covers one of the 19 Top-level hierarchies of SNOMED CT in its entirety, or a large subhierarchy within. Similarly, the Attribute’s range sanctions a subset of Attribute values as the relationship’s target concept. Here, the subset can consist of a few enumerated concepts up to complete Top-level hierarchies. Additionally, the Concept Model specifies how often an Attribute can occur for the given domain (cardinality) and if the usage of one or more Role groups is allowed [7].

A human-readable version of the Concept Model can be found within the domain-specific sections of SNOMED CT’s Editorial Guide [25]. For software processing, on the other hand, the Machine Readable Concept Model (MRCM) is provided [26]. It is distributed via four dedicated Reference Sets (RefSet) within the RF2 files of each SNOMED CT release. For our purpose, we extracted the MRCM Domain Reference Set from the International Edition of 2022-09-30. This RefSet contains the Concept Model rules sorted by domain in the form of Expression Templates (see Section 2.3).

2.3. Expression Templates

Based on the previously explained specifications, SNOMED CT offers so-called Expression Templates to further constrain the range of appropriate concept definitions or PCEs for use in a particular context. Formally, Expression Templates are structured like postcoordinated expressions but with one or more concepts replaced by variables and with added cardinalities.

The syntax of Expression Templates is based on the previously explained Compositional Grammar—mainly, a Focus concept that is refined by one or more Attribute relationships. As shown in Figure 3, the Focus concept and the Attributes themselves are the static components of the Template. Attribute values, on the other hand, form the variable part. Here, a subset of SNOMED CT concepts is offered to choose from when applying the Template for PCE creation. These subset constraints are formulated in SNOMED CT’s Expression Constraint Language (ECL) [27]. As in the Concept Model, cardinalities can be added to constrain how often a particular Attribute relationship may be used within a Role group and to limit each Role group’s repeatability.

Expression Templates offer the opportunity to tailor the broader Concept Model rules to one’s specific use case, reducing both ambiguity and optionality. Thus, we decided to also offer support for using Templates during PCE creation in the envisioned application, as well as a mechanism to generate additional Templates. SNOMED CT currently provides about 80 predefined Expression Templates via their Github and Confluence pages [28,29]. To acquire a machine-processable version, all currently available Templates were downloaded from Github in JSON format, and the relevant information (element “logicalTemplate”) was extracted.

All of the available Expression Templates were checked for compliance with the MRCM. Any inconsistencies found were communicated to SNOMED International, leading to revision or correction of the affected Templates.

2.4. FHIR Terminology Services

The HL7 standard Fast Healthcare Interoperability Resources (FHIR) [30] is currently gaining traction in interoperable data modeling on the national and international level [31]. Apart from the majority of FHIR resources typically used to capture patient-centered information, FHIR also defines a range of Terminology Services in its Terminology Module [32]. These consist mainly of the resources CodeSystem (for representing clinical terminologies and classifications), ValueSet (to state a subset of codes taken from one or more CodeSystems) and ConceptMap (for stating the relation between codes of different origin), as well as a number of operations to query the former resources in a standardized fashion. The FHIR resources and operations relevant for this project are listed in

Table 1. FHIR resources and operations needed within this project.

Resource Type	Operation	Explanation
CodeSystem	$lookup	Lookup information for a specific SNOMED CT concept.
	$subsumes	Query the hierarchical relationship between two codes to determine a concept’s domain.
	$validate-code	Check a given PCE for syntactic and semantic correctness.
ValueSet	$expand	Query the subset of possible concepts via ECL.
CodeSystem supplement		Save and load created PCEs.

, including a brief explanation of their usage.

Consequently, a terminology server based on the FHIR standard is required, which further supports the use of SNOMED CT’s Expression Constraint Language as well as postcoordination. CSIRO’s Ontoserver [33] was chosen as the only candidate fulfilling the latter requirement in particular [34].

Here, postcoordination support includes syntactic and semantic validation, as well as display string generation for existing PCEs and subsumption testing for pre- and postcoordinated expressions. Saving a PCE for later usage or inclusion in value sets requires its addition to SNOMED CT via a CodeSystem supplement [35].

A local instance of Ontoserver running version 6.12.1 with enabled support for PCEs and providing several recent versions of the International Edition of SNOMED CT was available during development and for testing purposes.

2.5. Data for Evaluation

As mentioned earlier, the German NASHIP (the KBV)—or more specifically, the related organization mio42 GmbH—is defining so-called Medical Information Objects (MIOs) to establish a standardized representation of specific healthcare documents. Therefore, FHIR is employed for syntactic standardization enriched with (inter)national terminologies for semantics, preferably SNOMED CT.

In a few instances, mio42 resorted to postcoordinated expressions to complete their value sets of otherwise precoordinated SNOMED CT concepts throughout various MIOs. For a later evaluation of our web application, we collected all value sets specified in the MIO projects available on the Simplifier platform [36] and extracted any postcoordinated expressions. The resulting 41 PCEs were first validated for adherence to the SNOMED CT Compositional Grammar and Concept Model via Ontoserver. Any violations found were analyzed manually and reported to mio42 if necessary. Mio42 verified the proposed corrections and assured their subsequent implementation into the affected MIOs.

3. Results

Based on the aforementioned components and considerations, we developed a web application called WASP (Web Application supporting SNOMED CT Postcoordination). Subsequently, WASP was evaluated using two different approaches.

3.1. Web Application

WASP was developed as a backend, implemented in Java using the Spring Boot framework, and as a frontend, using Angular and TypeScript. The two components are deployed together using the Gradle build tool and communicate over HTTP requests with each other. The code repository is available at https://gitlab.com/tessa00/wasp-supporting-snomed-ct-postcoordination (accessed on 20 April 2023). WASP offers three related main functions, which are summarized in Figure 4 and explained in detail in the following subsections. Firstly, the application offers an interface to create a postcoordinated expression based on the general constraints of SNOMED CT’s Compositional Grammar and Concept Model. Secondly, a PCE can be created according to an Expression Template to enforce further use-case-specific constraints. Thirdly, a new Expression Template can be created interactively if no appropriate Template is available for usage within the second function.

Throughout all three functions, the same paradigms are applied to both simplify the user’s task as well as prevent any erroneous input. Based on the respectively applicable constraints, the user interface is generated dynamically, which then resembles an automatically prefilled form. Like this, required elements are already present, and only relevant items are shown. For the remaining variable data fields, an autocomplete function provides appropriate SNOMED CT concepts according to the user’s input and the respectively applicable subset. Furthermore, several features for user guidance were added: Additional information on several elements, e.g., explaining an Attribute’s meaning, is provided within the user interface, including references to the SNOMED browser [37] or relevant SNOMED CT documents. To notify the user of any mandatory elements not yet filled out, error messages and highlighting are employed. Created PCEs are displayed according to the SNOMED CT Diagramming Guideline [38], providing a concise summary of the yielded input.

While the application was developed in conjunction with a local instance of Ontoserver, the user can choose to connect WASP to a different terminology server (TS) fulfilling the requirements stated in Section 2.4, such as the public Ontoserver hosted by the developers in Australia [39]. Based on the availability on the TS, different versions and editions of SNOMED CT can be chosen as well.

3.1.1. Creating PCEs Based on the MRCM

For the first task, the user starts with choosing an appropriate Focus concept for their intended postcoordinated expression. Based on this input, WASP deduces the Focus concept’s domain by subsumption testing and determines the corresponding MRCM Domain Template, which states all Attributes and Attribute value ranges applicable in this particular domain. Furthermore, the Attribute relationships present in the Focus concept’s definition are incorporated into the given MRCM Domain Template as well. This is necessary because a PCE can only refine the existing relationships of its Focus concepts, i.e., the valid Attribute range consists of the subhierarchy of the former Attribute value concept. Apart from this, the PCE can qualify the Focus concept by adding additional Attribute relationships.

According to these constraints—MRCM Domain Template and Focus concept definition—the user interface is generated, as shown in Figure 5. It is rendered as a form already containing the Attributes and Attribute values of the Focus concept, as well as the Attributes mandatory in the MRCM. For qualifying, the user can then add further Attribute relationships by selecting an Attribute from the list of permitted Attribute concepts and by choosing the corresponding Attribute value. For refining, only the Attribute value of an existing relationship is changed. As described in Section 2, Role groups can lend an additional structure to PCE refinements. To differentiate the different groups of Attribute relationships as well as those that remain ungrouped, multiple tabs are used within the form.

When the user has finished editing their custom elements, clicking the button “Create PCE” will initiate WASP to serialize the form’s content into a string representation complying with the Compositional Grammar. A summary of the created expression and a schematic diagram are shown. “Save PCE” will finally add the PCE to a CodeSystem supplement available on the terminology server.

3.1.2. Creating PCEs Based on Expression Templates

As pictured in Figure 4, the second function follows a similar course of action as the first. Contrastingly, the user starts here by choosing an Expression Template as blueprint for their PCE. The selection is facilitated by an internal repository containing the Expression Templates predefined by SNOMED International and those generated by users of the application. A filtering mechanism by category (i.e., by the Focus concept’s semantic tag) can be used to limit the number of choices.

Based on the chosen Template, the user interface is rendered. Compared with the MRCM constraints, Templates are generally far more restrictive, and thus, the resulting UI is fashioned in a different way, leaving less optionality. Figure 6 shows an exemplary form which contains a specific slot for each Attribute relationship specified within the Template. Using Role groups is enabled according to the Template’s constraints as well.

The further process is equivalent to the previous description.

3.1.3. Generating New Expression Templates

The third main function is largely similar to the first, although an Expression Template is created instead of a PCE. However, like before, a Focus concept is chosen by the user, which serves as the basis for generating the user interface as a prefilled form.

As shown in Figure 7, allowed Attributes are selected here as well, but instead of determining a concrete Attribute value, the value range—specified by MRCM or Focus concept—can be further constrained within the given limits. In this context, cardinalities for Attribute relationships and Role groups can also be set.

When the user has finished editing the form, a second step follows which allows to specify a name for the created Template as well as a so-called Term Template. The latter facilitates the automatic generation of a display term for any expression created using the corresponding Template. To achieve this, fixed and dynamic parts are employed which, respectively, correspond to the fixed values or variables of the Template, e.g., “Fracture of [bone structure] (disorder)”. To support the user while formulating the Term Template, variables depending on the previously chosen Attribute relationships are provided.

Afterwards, the created Template is displayed for review and can be saved within the application’s Template repository.

3.2. Evaluation

To evaluate the developed application, we tested both the PCE creation as well as the Template generation process in the context of already existing postcoordinated expressions. By doing so, we intended to verify that our proposed approach is capable of creating correct Templates and PCEs while preventing the creation of incorrect expressions. Furthermore, we conducted a usability study to gain insight into the users’ perspective. In this evaluation step, we primarily wanted to investigate if the implemented application adequately simplifies PCE creation. Therefore, special attention was laid on the comprehensibility, functionality and usability ratings of the study participants.

3.2.1. Existing PCEs

A sample set of real-life postcoordinated expressions was determined, as described in Section 2.5. Automatically checking these 41 PCEs for Concept Model adherence resulted in 34 cases of a response containing errors. The subsequent manual analysis revealed 6 PCEs with actual Concept Model violations, 26 PCEs with minor syntax issues caused by reasonable restrictions of the Ontoserver and 2 PCEs that were falsely identified as incorrect due to an error in SNOMED CT’s Concept Model. The latter two sets were considered acceptable, finally resulting in 35 correct and 6 incorrect PCEs.

For the correct PCEs, a two-step process was developed to verify that WASP enables guided replication of them. In the first step, the usage context of the respective PCE is identified, so that a Template—appropriate for the general use case—can be generated within WASP. This Template is then applied as the basis for the second step, in which the original PCE is recreated using the “Create PCE based on Template” function. This process was conducted with 10 randomly chosen PCEs. For all of these, both the Template and PCE could be created without issues. The original and the replicated PCE were compared pairwise and evaluated as equivalent.

To further test WASP’s capability to prevent erroneous input, an attempt was made to recreate all 6 incorrect PCEs directly using the “Create PCE based on Concept Model” function. Hereby, two different kinds of violations occurred that correctly prevented the formulation of the respective PCE: Unauthorized Attribute used and maximum cardinality exceeded. In the first case, the PCE contains an Attribute that is not sanctioned for the Focus concept’s domain. Here, WASP prevents the entry by only showing the allowed Attributes in a list to choose from. In the second case, the PCE contains the same Attribute more times than allowed. Similar to before, WASP no longer offers an Attribute if the maximum cardinality is reached. Thus, none of the incorrect PCEs could be created within the user interface.

3.2.2. Usability Survey

For the usability survey, a tailored questionnaire was put together by the authors. It contains 24 items collecting the participant’s overall impression of the application and their opinion about specific aspects of its three main functions, as well as a self-assessment of their own SNOMED CT knowledge. For 20 items, an ordinal scale with five options ranging from worst (“1”) to best (“5”) is employed; the remaining four items are open-ended questions. None of the items are mandatory and no answer options are preselected. The complete questionnaire including answer options is available in the Appendix A.

The survey was conducted with three local participants, all being fairly knowledgeable about SNOMED CT postcoordination but new to WASP. Each participant received the questionnaire beforehand, as well as a short introduction to WASP’s functionality. Then, the application could be explored freely and without time constraints. Afterwards, the participants completed the questionnaire anonymously.

The results were collated and aggregated as visualized in Figure 8. Both functionality as well as usability were largely considered favorable, as 78% of items (14 of 18) received only positive values (“4” or “5”). For the remaining four questions, there was one neutral answer (“3”) in three cases and one negative answer (“2”) in a single case. The former depicts occasional difficulties in all of WASP’s three main functions, while the latter expresses a participant’s wish for more information on incorrect entries. Consistent with this, information fields and tooltips were rated as very useful throughout. As for the application’s principal goal, all participants confirmed that they were completely able to create PCEs and Templates according to their needs.

Only one participant added free-text comments (see Appendix A), which include several small suggestions for optimization. Among other aspects, two bugs were reported, and an improvement for the Attribute range selection was described. Additional features were requested as well, including the reordering or deleting of Attribute relationships during Template generation, an automated example display term for the Term Template and an import/export function for PCEs and Templates.

4. Discussion

According to the identified need for better tooling in terms of SNOMED CT postcoordination, we successfully developed the versatile application WASP, which not only supports the creation of postcoordinated expressions (PCEs) in its rudimental form but also employs SNOMED CT Expression Templates for additional functionality. This includes both the creation of user-defined templates as well as their usage for PCE creation in turn. During the development process, great emphasis was laid on user guidance by providing necessary and comprehensible functionality and preventing erroneous input.

The chosen approach benefits greatly from SNOMED CT’s extensive formalisms. Existing specifications of the Compositional Grammar, Concept Model and Expression Templates were largely machine-processable and easily integratable, so that the application’s compliance with the current definitions is ensured. The deep integration of these specifications into the application’s architecture is pivotal for fulfilling the central goal of guaranteeing the syntactic and semantic correctness of user-created PCEs. While the successful achievement of this aim is a logical conclusion of WASP’s design, it was also proven empirically using existing real-life examples. For the PCEs defined within the German MIOs, correct expressions could be successfully replicated in WASP using a roundtrip validation based on Template generation and subsequent PCE creation. The replication of PCEs previously identified as incorrect was effectively prohibited.

A small usability study supports these claims as well and indicates good user acceptance. Guidance through information fields within the application was received well, but further explanations, e.g., by providing a user manual, would still be beneficial to improve accessibility and to resolve any uncertainties. This huge need for information once again demonstrates the complexity of the PCE creation process and emphasizes our demand for better tooling.

Furthermore, the complexity inherent in the whole topic of SNOMED CT postcoordination was omnipresent throughout the project. We encountered inaccuracies not only in existing user-created PCEs but also in the official specifications of the MRCM and several Expression Templates by SNOMED International. These were conjointly resolved, leaving a stable and quality-assured ground truth for PCE validation. On the other hand, these issues not being found earlier is indicative of the lacking usage of postcoordination in general. WASP can only contribute to a wider adoption by facilitating PCE creation; the integration of PCEs in electronic health records and their subsequent (re)use entails the need for further specialized software.

In this context, the recent proliferation of HL7 FHIR works as a driving factor. FHIR resources build the syntactic fundament in which SNOMED CT is often prioritized for semantic standardization of individual data elements, creating a strong synergy between the two standards. This development is further fueled by FHIR’s Terminology Module, which offers a standardized interface to query SNOMED CT content [40]. Putting this principle to work via a sophisticated terminology server facilitated a straightforward implementation of WASP and greatly reduced the amount of work required.

There are several opportunities for future development in the context of WASP. The conducted usability study already yielded valuable input for improvement, which is progressively implemented. Yet, a larger user evaluation is required to gain broader feedback from users with different backgrounds, particularly domain experts in charge of designing PCEs. To facilitate such a survey, and primarily to broaden access, the web application is currently being made available to the public. Apart from minor functionality and stability improvements, larger adaptations of the PCE creation process available in WASP would also be imaginable. Harnessing NLP (natural language processing)-powered approaches such as Metamap [41], for example, could allow for automated proposals of appropriate PCEs based on user-provided free-text phrases [42] and thus further streamline the PCE creation process.