Next Article in Journal
LFDC: Low-Energy Federated Deep Reinforcement Learning for Caching Mechanism in Cloud–Edge Collaborative
Next Article in Special Issue
An Automated English Essay Scoring Engine Based on Neutrosophic Ontology for Electronic Education Systems
Previous Article in Journal
Instability Induced by Random Background Noise in a Delay Model of Landslide Dynamics
 
 
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

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

1
IT Center for Clinical Research, University of Luebeck, 23562 Luebeck, Germany
2
Institute of Medical Informatics, University of Luebeck, 23562 Luebeck, Germany
*
Authors to whom correspondence should be addressed.
These authors contributed equally to this work.
Appl. Sci. 2023, 13(10), 6114; https://doi.org/10.3390/app13106114
Submission received: 20 April 2023 / Revised: 13 May 2023 / Accepted: 15 May 2023 / Published: 16 May 2023
(This article belongs to the Special Issue Advances in Ontology and Semantic Web)

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, 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.

Author Contributions

Conceptualization, C.D. and J.I.; methodology, C.D., T.O. and J.W.; software, T.O.; validation, C.D. and J.W.; writing—original draft preparation, C.D.; writing—review and editing, T.O., J.W. and J.I.; visualization, C.D. and T.O.; supervision, J.I. and C.D.; project administration, J.I. All authors have read and agreed to the published version of the manuscript.

Funding

This research was funded by the German Federal Ministry of Education and Research (BMBF) as part of the Medical Informatics Initiative Germany, grant numbers 01ZZ1802Z and 01ZZ2312A.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

No new data were created or analyzed in this study. Data sharing is not applicable to this article.

Acknowledgments

The authors would like to thank SNOMED International for their support by answering questions about the intricacies of postcoordination and the Concept Model.

Conflicts of Interest

The authors declare no conflict of interest.

Abbreviations

The following abbreviations are used in this manuscript:
CSIROCommonwealth Scientific and Industrial Research Organisation
ECLExpression Constraint Language
FHIRFast Healthcare Interoperability Resources
HL7Health Level 7
HTTPHypertext Transfer Protocol
JSONJavaScript Object Notation
MIOMedical Information Object
MRCMMachine Readable Concept Model
NASHIPNational Association of Statutory Health Insurance Physicians
NLPNatural Language Processing
PCEPostcoordinated expression
RGRole group
TSTerminology server
UIUser interface
WASPWeb Application supporting SNOMED CT Postcoordination

Appendix A

Table A1. Usability survey results in detail and per participant.
Table A1. Usability survey results in detail and per participant.
ItemAnswer OptionsP1P2P3
Background knowledge
How much do you know about SNOMED CT?Nothing–Very much554
How much do you know about SNOMED CT Postcoordination?Nothing–Very much544
Overall impression
WASP has a consistent, clearly recognizable look and design.Strongly disagree–Strongly agree454
Functionality of buttons and controls is identifiable based on their label and design.Strongly disagree–Strongly agree544
The individual pages are organized clearly.Strongly disagree–Strongly agree544
Where tooltips or information fields are given, these provided useful assistance.Strongly disagree–Strongly agree555
The user is informed of incorrect entries.Strongly disagree—Strongly agree452
PCE creation based on MRCM
How effective was the selection of the individual attributes?Very ineffective–Very effective554
How easy was it to choose an attribute value of an attribute?Very hard–Very easy344
How easy was it overall to create a PCE based on the Concept Model?Very hard–Very easy444
Could you create the PCE like you wanted?Not at all–Yes, completely555
If not: Which problems have occurred?1
PCE creation based on Template
How easy was it to choose an appropriate Template?Very hard–Very easy435
How easy was it overall to create a PCE based on a Template?Very hard–Very easy454
Could you create the PCE like you wanted?Not at all–Yes, completely555
If not: Which problems have occurred?2
Template generation
How effective was the selection of the individual attributes?Very ineffective–Very effective554
How easy was it to choose or adjust the value range of an attribute?Very hard–Very easy444
How helpful were the default value ranges and default cardinalities?Not helpful at all–Very helpful45
How intuitive was the generation of a Term Template?Very counterintuitive–Very intuitive444
How easy was it overall to create a Template?Very hard–Very easy453
Could you create the Template like you wanted?Not at all–Yes, completely55
If not: Which problems have occurred?3
Additional comments
Do you have any further comments?4
1 “Selecting concepts from the ranges of the attributes needs a bit more work. A typeahead of three is sometimes not enough. A solution would possible be pre-expansion of the VS on the backend side, and then applying filtering using fuzzy search in either the frontend or (likely better) the backend”. 2 “c.f. above re. MRCM-based attribute value selection”. 3 “Range: reordering of rows, or allowing the deletion of all rows. Term template: it might be good if you could include an example term that is generated from the template, e.g., by expanding each range and selecting a random concept from that for each attribute”. 4 “Feature request: import and export templates and PCEs generated using WASP. Bug: follow 302 redirects when selecting a server. Bug: Settings are not modal. Enhancement: use Angular routing to generate meaningful URLs and use TitleService to set the app title as well for each Component”.

References

  1. Benson, T.; Grieve, G. Principles of Health Interoperability: FHIR, HL7 and SNOMED CT, 4th ed.; Springer Nature: Cham, Switzerland, 2021; ISBN 978-3-030-56882-5. [Google Scholar]
  2. Cimino, J.J. Desiderata for controlled medical vocabularies in the twenty-first century. Methods Inf. Med. 1998, 37, 394–403. [Google Scholar] [CrossRef] [PubMed]
  3. Chang, E.; Mostafa, J. The use of SNOMED CT, 2013–2020: A literature review. J. Am. Med. Inform. Assoc. 2021, 28, 2017–2026. [Google Scholar] [CrossRef] [PubMed]
  4. Hüsers, J.; Przysucha, M.; Nolte, L.; Paul, A.; Matysek, P.; John, S.; Hübner, U. Expressiveness of SNOMED CT for wound Care–Mapping a Standardised item Set for Leg Ulcers to SNOMED CT. JMIR Med. Inform. 2020, 9, e31980. [Google Scholar]
  5. Wang, A.Y.; Sable, J.H.; Spackman, K.A. The SNOMED clinical terms development process: Refinement and analysis of content. In Proceedings of the AMIA Symposium; American Medical Informatics Association: Bethesda, ML, USA, 2002; pp. 845–849. [Google Scholar]
  6. Karlsson, D.; Nyström, M.; Cornet, R. Does SNOMED CT post-coordination scale? In e-Health—For Continuity of Care; IOS Press: Amsterdam, The Netherlands, 2014; pp. 1048–1052. [Google Scholar]
  7. SNOMED International. SNOMED CT Starter Guide, Version 1; International Health Terminology Standard Development Organisation: London, UK, 2023; pp. 26–32. Available online: https://confluence.ihtsdotools.org/display/DOCSTART/SNOMED+CT+Starter+Guide?preview=/28742871/180920238/doc_StarterGuide_Current-en-US_INT_20230421.pdf (accessed on 4 May 2023).
  8. Gaudet-Blavignac, C.; Foufi, V.; Bjelogrlic, M.; Lovis, C. Use of the Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) for processing free text in health care: Systematic scoping review. J. Med. Internet Res. 2021, 23, e24594. [Google Scholar] [CrossRef] [PubMed]
  9. Rinaldi, E.; Saas, J.; Thun, S. Use of LOINC and SNOMED CT with FHIR for microbiology data. Stud. Health Technol. Inform. 2021, 278, 156–162. [Google Scholar] [PubMed]
  10. Semler, S.C.; Wissing, F.; Heyder, R. German medical informatics initiative. Methods Inf. Med. 2018, 57, e50–e56. [Google Scholar] [CrossRef] [PubMed]
  11. KBV-BASIS-PROFILE. Available online: https://mio.kbv.de/display/BASE1X0/KBV-Basis-Profile (accessed on 12 April 2023).
  12. Rossander, A.; Lindsköld, L.; Ranerup, A.; Karlsson, D. A State-of-the Art Review of SNOMED CT Terminology Binding and Recommendations for Practice and Research. Methods Inf. Med. 2021, 60, e76–e88. [Google Scholar] [CrossRef] [PubMed]
  13. Green, J.M.; Wilcke, J.R.; Abbott, J.; Rees, L.P. Development and evaluation of methods for structured recording of heart murmur findings using SNOMED-CT® post-coordination. J. Am. Med. Inform. Assoc. 2006, 13, 321–333. [Google Scholar] [CrossRef] [PubMed]
  14. Dhombres, F.; Winnenburg, R.; Case, J.T.; Bodenreider, O. Extending the coverage of phenotypes in SNOMED CT through post-coordination. Stud. Health Technol. Inform. 2015, 216, 795–799. [Google Scholar] [PubMed]
  15. Ohlsen, T.; Kruse, V.; Krupar, R.; Banach, A.; Ingenerf, J.; Drenkhahn, C. Mapping of ICD-O Tuples to OncoTree Codes Using SNOMED CT Post-Coordination. In Challenges of Trustable AI and Added-Value on Health: Proceedings of MIE 2022, Nice, France, 27–30 May 2022; IOS Press: Amsterdam, The Netherlands, 2022; pp. 307–311. [Google Scholar]
  16. Wua, C.; Xie, Z.; Todd, J.; Johnson, B.; Kuoa, G.M.; Jeffrey, R. Development of web-based snomed-ct post-coordinated code searching tool. In MEDINFO 2004, Proceedings of the 11th World Congress on Medical Informatics, San Francisco, CA, USA, 7–11 September 2004; IOS Press: Amsterdam, The Netherlands, 2004; p. 1912. [Google Scholar]
  17. Github: Postcoordination Tooling Terminologiecentrum. Available online: https://github.com/hielkema/postco (accessed on 12 April 2023).
  18. Github: Postcoordination Demonstrator. Available online: https://github.com/ihtsdo/iid-postcoordination (accessed on 12 April 2023).
  19. Miñarro-Giménez, J.A.; Martínez-Costa, C.; López-García, P.; Schulz, S. Building SNOMED CT Post-Coordinated Expressions from Annotation Groups. Stud. Health Technol. Inform. 2017, 235, 446–450. [Google Scholar] [PubMed]
  20. Kate, R.J. Automatic full conversion of clinical terms into SNOMED CT concepts. J. Biomed. Inform. 2020, 111, 103585. [Google Scholar] [CrossRef] [PubMed]
  21. Castell-Díaz, J.; Miñarro-Giménez, J.A.; Martínez-Costa, C. Supporting SNOMED CT postcoordination with knowledge graph embeddings. J. Biomed. Inform. 2023, 139, 104297. [Google Scholar] [CrossRef] [PubMed]
  22. Vogl, K.; Ingenerf, J.; Kramer, J.; Chantraine, C.; Drenkhahn, C. LUMA: A Mapping Assistant for Standardizing the Units of LOINC-Coded Laboratory Tests. Appl. Sci. 2022, 12, 5848. [Google Scholar] [CrossRef]
  23. Steel, J. How and When to Use FHIR Terminology Service APIs. In Proceedings of the HL7 FHIR DevDays 2019, Redmond, WA, USA, 10–12 June 2019; Available online: https://www.devdays.com/wp-content/uploads/2021/12/Jim-Steel-FHIR-Terminology-Service-APIs-DevDays-2019-Redmond.pdf (accessed on 18 April 2023).
  24. SNOMED International. SNOMED CT Compositional Grammar Specification and Guide, Version 2.4; International Health Terminology Standard Development Organisation: London, UK, 2020; Available online: https://confluence.ihtsdotools.org/display/DOCSCG?preview=/33496020/115880553/doc_CompositionalGrammar_v2.4-en-US_INT_20201116.pdf (accessed on 20 April 2023).
  25. SNOMED International. SNOMED CT Editorial Guide; International Health Terminology Standard Development Organisation: London, UK, 2023; Available online: https://confluence.ihtsdotools.org/display/DOCEG/PDFs+for+Download (accessed on 20 April 2023).
  26. SNOMED International. SNOMED CT Machine Readable Concept Model Specification, Version 1.0; International Health Terminology Standard Development Organisation: London, UK, 2017; Available online: https://confluence.ihtsdotools.org/display/DOCMRCM?preview=/42403745/47681102/doc_MachineReadableConceptModelSpecification_v1.0_Current-en-US_INT_20170817.pdf (accessed on 20 April 2023).
  27. SNOMED International. SNOMED CT Expression Constraint Language Specification and Guide, Version 2.1; International Health Terminology Standard Development Organisation: London, UK, 2022; Available online: https://confluence.ihtsdotools.org/display/DOCECL/Expression+Constraint+Language+-+Specification+and+Guide?preview=/33493263/154245524/doc_ExpressionConstraintLanguage_v2.1-en-US_INT_20220824.pdf (accessed on 20 April 2023).
  28. Github: SNOMED CT Authoring Templates. Available online: https://github.com/IHTSDO/snomed-templates (accessed on 17 April 2023).
  29. Confluence: Template Specification. Available online: https://confluence.ihtsdotools.org/display/SCTEMPLATES/Template+specification (accessed on 17 April 2023).
  30. Bender, D.; Sartipi, K. HL7 FHIR: An Agile and RESTful approach to healthcare information exchange. In CBMS 2013, Proceedings of the 26th IEEE International Symposium on Computer-Based Medical Systems, Porto, Portugal, 20–22 June 2013; IEEE: New York, NY, USA; pp. 326–331.
  31. Ayaz, M.; Pasha, M.F.; Alzahrani, M.Y.; Budiarto, R.; Stiawan, D. The Fast Health Interoperability Resources (FHIR) standard: Systematic literature review of implementations, applications, challenges and opportunities. JMIR Med. Inform. 2021, 9, e21929. [Google Scholar]
  32. Terminology Module. Available online: https://www.hl7.org/fhir/terminology-module.html (accessed on 12 April 2023).
  33. Metke-Jimenez, A.; Steel, J.; Hansen, D.; Lawley, M. Ontoserver: A syndicated terminology server. J. Biomed. Semant. 2018, 9, 24. [Google Scholar] [CrossRef] [PubMed]
  34. Confluence: Features of Known Servers. Available online: https://confluence.ihtsdotools.org/display/FHIR/Features+of+Known+Servers (accessed on 12 April 2023).
  35. Ontoserver-SNOMED CT Post-Coordination Support. Available online: https://ontoserver.csiro.au/docs/6/postcoordination.html (accessed on 12 April 2023).
  36. Simplifier: Kassenärztliche Bundesvereinigung (KBV)/Projects. Available online: https://simplifier.net/organization/kassenrztlichebundesvereinigungkbv/~projects (accessed on 12 April 2023).
  37. SNOMED International SNOMED CT Browser. Available online: https://browser.ihtsdotools.org/ (accessed on 12 April 2023).
  38. SNOMED International. SNOMED CT Diagramming Guideline; International Health Terminology Standard Development Organisation: London, UK, 2021; Available online: https://confluence.ihtsdotools.org/display/DOCDIAG?preview=/29951081/137237893/doc_DiagrammingGuideline_Current-en-US_INT_20211027.pdf (accessed on 20 April 2023).
  39. Ontoserver: Australian Test Endpoint. Available online: https://r4.ontoserver.csiro.au/fhir (accessed on 12 April 2023).
  40. Bodenreider, O.; Cornet, R.; Vreeman, D. Recent Developments in Clinical Terminologies—SNOMED CT, LOINC, and RxNorm. Yearb. Med. Inform. 2018, 27, 129–139. [Google Scholar] [CrossRef] [PubMed]
  41. Aronson, A.R. Effective mapping of biomedical text to the UMLS Metathesaurus: The MetaMap program. In Proceedings of the AMIA Symposium; American Medical Informatics Association: Bethesda, ML, USA, 2001; pp. 17–21. [Google Scholar]
  42. Peterson, K.J.; Liu, H. Automating the transformation of free-text clinical problems into SNOMED CT expressions. AMIA Summits Transl. Sci. Proc. 2020, 2020, 497–506. [Google Scholar] [PubMed]
Figure 1. An overview of the architecture conceptualized for the envisioned application, including a mockup of the user interface.
Figure 1. An overview of the architecture conceptualized for the envisioned application, including a mockup of the user interface.
Applsci 13 06114 g001
Figure 2. To formulate a correct postcoordinated expression, SNOMED CT’s Compositional Grammar and Concept Model needs to be applied: (a) The panel above shows an exemplary PCE for “Biopsy of distal left femur using computed tomography guidance” using 71388002 |Procedure| as Focus concept. Different components of the expression are colored according to the explanation of the Compositional Grammar in the main text. (b) The panel below pictures schematically the Concept Model constraints for domain and range of the Attribute 260686004 |Method|. “<<” indicates that a subset is defined including the respective concept and all of its descendants. 129314006 |Biopsy - action| is a subconcept of 129264002 |Action|; thus, the Attribute relationship of the expression above is valid.
Figure 2. To formulate a correct postcoordinated expression, SNOMED CT’s Compositional Grammar and Concept Model needs to be applied: (a) The panel above shows an exemplary PCE for “Biopsy of distal left femur using computed tomography guidance” using 71388002 |Procedure| as Focus concept. Different components of the expression are colored according to the explanation of the Compositional Grammar in the main text. (b) The panel below pictures schematically the Concept Model constraints for domain and range of the Attribute 260686004 |Method|. “<<” indicates that a subset is defined including the respective concept and all of its descendants. 129314006 |Biopsy - action| is a subconcept of 129264002 |Action|; thus, the Attribute relationship of the expression above is valid.
Applsci 13 06114 g002
Figure 3. Excerpt of a SNOMED CT Expression Template with static and variable components, as well as cardinalities.
Figure 3. Excerpt of a SNOMED CT Expression Template with static and variable components, as well as cardinalities.
Applsci 13 06114 g003
Figure 4. WASP offers three main functions, which are stated on the left. The user interaction process is accordingly depicted on the right, with internal queries to the terminology server added.
Figure 4. WASP offers three main functions, which are stated on the left. The user interaction process is accordingly depicted on the right, with internal queries to the terminology server added.
Applsci 13 06114 g004
Figure 5. A screenshot of the user interface showing the PCE creation process based on the Concept Model. Here, the SNOMED CT concept “Procedure (procedure)” was chosen as the expression’s focus concept. Two Role groups were created (see “1.1 RG” and “1.2 RG”). In the first Role group, visible in the screenshot, the Attributes “Method” and “Procedure site” with corresponding Attribute values are added. Together with the second Role group, the PCE as displayed in Figure 2 results.
Figure 5. A screenshot of the user interface showing the PCE creation process based on the Concept Model. Here, the SNOMED CT concept “Procedure (procedure)” was chosen as the expression’s focus concept. Two Role groups were created (see “1.1 RG” and “1.2 RG”). In the first Role group, visible in the screenshot, the Attributes “Method” and “Procedure site” with corresponding Attribute values are added. Together with the second Role group, the PCE as displayed in Figure 2 results.
Applsci 13 06114 g005
Figure 6. A screenshot of the user interface showing the PCE creation process using Expression Templates. In this example, the SNOMED-CT-defined Template “Imaging guided biopsy (procedure)” was chosen, which builds upon the Focus concept “Procedure” and two mandatory Role groups (targeting either imaging or biopsy details). In the first Role group, the attributes “Method” and “Has intent” are mandatory, with the latter having a fixed value of “Guidance intent”. Additionally, concept values were chosen as in Figure 5 to create the same PCE.
Figure 6. A screenshot of the user interface showing the PCE creation process using Expression Templates. In this example, the SNOMED-CT-defined Template “Imaging guided biopsy (procedure)” was chosen, which builds upon the Focus concept “Procedure” and two mandatory Role groups (targeting either imaging or biopsy details). In the first Role group, the attributes “Method” and “Has intent” are mandatory, with the latter having a fixed value of “Guidance intent”. Additionally, concept values were chosen as in Figure 5 to create the same PCE.
Applsci 13 06114 g006
Figure 7. A screenshot of the user interface showing the Template creation process. Here, the Template presented in Section 2.3 is recreated with the same Attributes, Attribute value ranges, cardinalities and Role groups. Only for the “Procedure site”, a more specific value range is chosen, limiting possible Attribute values to the subhierarchy of “Bone structures”.
Figure 7. A screenshot of the user interface showing the Template creation process. Here, the Template presented in Section 2.3 is recreated with the same Attributes, Attribute value ranges, cardinalities and Role groups. Only for the “Procedure site”, a more specific value range is chosen, limiting possible Attribute values to the subhierarchy of “Bone structures”.
Applsci 13 06114 g007
Figure 8. Results of the usability survey.
Figure 8. Results of the usability survey.
Applsci 13 06114 g008
Table 1. FHIR resources and operations needed within this project.
Table 1. FHIR resources and operations needed within this project.
Resource TypeOperationExplanation
CodeSystem$lookupLookup information for a specific SNOMED CT concept.
$subsumesQuery the hierarchical relationship between two codes to determine a concept’s domain.
$validate-codeCheck a given PCE for syntactic and semantic correctness.
ValueSet$expandQuery the subset of possible concepts via ECL.
CodeSystem supplement Save and load created PCEs.
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Drenkhahn, C.; Ohlsen, T.; Wiedekopf, J.; Ingenerf, J. WASP—A Web Application to Support Syntactically and Semantically Correct SNOMED CT Postcoordination. Appl. Sci. 2023, 13, 6114. https://doi.org/10.3390/app13106114

AMA Style

Drenkhahn C, Ohlsen T, Wiedekopf J, Ingenerf J. WASP—A Web Application to Support Syntactically and Semantically Correct SNOMED CT Postcoordination. Applied Sciences. 2023; 13(10):6114. https://doi.org/10.3390/app13106114

Chicago/Turabian Style

Drenkhahn, Cora, Tessa Ohlsen, Joshua Wiedekopf, and Josef Ingenerf. 2023. "WASP—A Web Application to Support Syntactically and Semantically Correct SNOMED CT Postcoordination" Applied Sciences 13, no. 10: 6114. https://doi.org/10.3390/app13106114

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop