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

Expressive clinical terminologies are of utmost importance for achieving an 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. 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 through the creation of Postcoordinated expressions (PCEs) while ensuring the 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 PCEs created with it.

Keywords:

Subject: Computer Science and Mathematics - Computer Science

1. Introduction

Semantic interoperability is the fundamental prerequisite to allow a meaningful exchange as well as the 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 is 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 thousands of predefined, "precoordinated" concepts are no match for the expressiveness of natural language [4]. But, 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. To ensure machine-readability of the created Postcoordinated expression (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 [7] 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 [8]. Postcoordination on the other hand, is either avoided altogether as in the case of the Medical Informatics Initiative (MII) [9] or used as a last resort like in the Medical Information Objects (MIOs) [10] of the National Association of Statutory Health Insurance Physicians (NASHIP, in German: Kassenärztliche Bundesvereinigung, KBV) [11]. 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.

A review of previous work done in this area 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 [12] or incomplete [13]. Recently, SNOMED International has begun to develop a publicly available application with a seemingly similar objective [14].

2. Materials and Methods

Building on the authors’ knowledge gained in previous projects [15,16], the overall architecture of the envisioned application was conceptualized as shown in Figure 1 and 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 own application. Here, the HL7 FHIR Terminology Services offer a standardized interaction mechanism [17].

2.1. Compositional Grammar

The SNOMED CT Compositional Grammar specification [18] 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, domain and range for each of the currently 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 sub-hierarchy 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.

A human-readable version of the Concept Model can be found within the domain-specific sections of SNOMED CT’s Editorial Guide [19]. For software processing on the other hand, the Machine Readable Concept Model (MRCM) is provided [20]. 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). 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 [22,23]. To acquire a machine-processable version, all currently available Templates were downloaded from Github in JSON format and relevant information (element "logicalTemplate") 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) [24] is currently gaining traction in interoperable data modeling on the national and international level [25]. 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 [26]. 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. 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 furthermore supports the use of SNOMED CT’s Expression Constraint Language as well as postcoordination. CSIRO’s Ontoserver [27] was chosen as the only candidate fulfilling the latter requirement in particular [28].

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 [29].

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 specific the related organisation 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 [30] 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 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 will be 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 pre-filled form. Like this, required elements are already present and only relevant items are shown. For the remaining variable data fields, an auto-complete 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, are provided within the user interface including references to the SNOMED browser [31] 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 [32], 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, like the public Ontoserver hosted by the developers in Australia [33]. 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. 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 with 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 5 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. But like before, a Focus concept is chosen by the user which serves as the basis for generating the user interface as a pre-filled form.

As shown in Figure 6, 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. Furthermore, we conducted a usability study to gain insight into the users’ perspective.

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 for 34 cases in 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 the guided replication of these. In the first step, the usage context of the respective PCE is identified so that a Template—appropriate for the general use case—could 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 Template and PCE could be created without issues. The original and the replicated PCE were compared pair-wise and evaluated as equivalent.

To furthermore test WASP’s capability to prevent erroneous input, all 6 incorrect PCEs were tried to recreate 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, their opinion about specific aspects of its three main functions as well as a self-assessment of the 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 into 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 7. 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. Amongst 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 creation of Postcoordinated expression (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, a great emphasis was laid upon 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 a 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. Not only did we encounter inaccuracies 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; 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 [34]. 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 like Metamap [35] for example could allow for automated proposals of appropriate PCEs based on user-provided free-text phrases [36] 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

CSIRO	Commonwealth Scientific and Industrial Research Organisation
ECL	Expression Constraint Language
FHIR	Fast Healthcare Interoperability Resources
HL7	Health Level 7
HTTP	Hypertext Transfer Protocol
JSON	JavaScript Object Notation
MIO	Medical Information Object
MRCM	Machine Readable Concept Model
NASHIP	National Association of Statutory Health Insurance Physicians
NLP	Natural Language Processing
PCE	Postcoordinated expression
RG	Role group
TS	Terminology server
UI	User interface
WASP	Web Application supporting SNOMED CT Postcoordination

Appendix A

Table A1. Usability survey results in detail and per participant.

Item	Answer options	P1	P2	P3
Background knowledge
How much do you know about SNOMED CT?	Nothing — Very much	5	5	4
How much do you know about SNOMED CT Postcoordination?	Nothing — Very much	5	4	4
Overall impression
WASP has a consistent, clearly recognizable look and design.	Strongly disagree — Strongly agree	4	5	4
Functionality of buttons and controls is identifiable based on their label and design.	Strongly disagree — Strongly agree	5	4	4
The individual pages are organized clearly.	Strongly disagree — Strongly agree	5	4	4
Where tooltips or information fields are given, these provided useful assistance.	Strongly disagree — Strongly agree	5	5	5
The user is informed of incorrect entries.	Strongly disagree — Strongly agree	4	5	2
PCE creation based on MRCM
How effective was the selection of the individual attributes?	Very ineffective — Very effective	5	5	4
How easy was it to choose an attribute value of an attribute?	Very hard — Very easy	3	4	4
How easy was it overall to create a PCE based on the Concept Model?	Very hard — Very easy	4	4	4
Could you create the PCE like you wanted?	Not at all — Yes, completely	5	5	5
If not: Which problems have occurred?	–	...¹	–	–
PCE creation based on Template
How easy was it to choose an appropriate Template?	Very hard — Very easy	4	3	5
How easy was it overall to create a PCE based on a Template?	Very hard — Very easy	4	5	4
Could you create the PCE like you wanted?	Not at all — Yes, completely	5	5	5
If not: Which problems have occurred?	–	...²	–	–
Template generation
How effective was the selection of the individual attributes?	Very ineffective — Very effective	5	5	4
How easy was it to choose or adjust the value range of an attribute?	Very hard — Very easy	4	4	4
How helpful were the default value ranges and default cardinalities?	Not helpful at all — Very helpful	4	5	–
How intuitive was the generation of a Term Template?	Very counterintuitive — Very intuitive	4	4	4
How easy was it overall to create a Template?	Very hard — Very easy	4	5	3
Could you create the Template like you wanted?	Not at all — Yes, completely	5	5	–
If not: Which problems have occurred?	–	...³	–	–
Additional comments
Do you have any further comments?	–	...⁴	–	–

¹ "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." ² "c.f. above re. MRCM-based attribute value selection" ³ "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." ⁴ "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

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.
Cimino, J. J. Desiderata for controlled medical vocabularies in the twenty-first century. Methods of information in medicine 1998, 37(04/05), 394–403. [CrossRef]
Chang, E.; Mostafa, J. The use of SNOMED CT, 2013-2020: a literature review. Journal of the American Medical Informatics Association 2021, 28(9), 2017–2026. [Google Scholar] [CrossRef] [PubMed]
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 Medical Informatics 2020, 9, e31980:1–e31980:11. [Google Scholar] [CrossRef]
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. 2002, 845–849.
Karlsson, D.; Nyström, M.; Cornet, R. Does SNOMED CT post-coordination scale? e-Health–For Continuity of Care. IOS Press. 2014, 1048–1052.
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. Journal of medical Internet research 2021, 23, e24594:1–e24594:18. [Google Scholar] [CrossRef]
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]
Semler, S.C.; Wissing, F.; Heyder, R. German medical informatics initiative. Methods Inf. Med. 2018, 57, e50–e56. [Google Scholar] [CrossRef] [PubMed]
KBV-BASIS-PROFILE. Available online: https://mio.kbv.de/display/BASE1X0/KBV-Basis-Profile (accessed on 12 April 2023).
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 of Information in Medicine 2021, 60, e76–e88. [Google Scholar] [CrossRef] [PubMed]
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, USA, 7–11 September 2004; 1912.
Github: Postcoordination tooling Terminologiecentrum. Available online: https://github.com/hielkema/postco (accessed on 12 April 2023).
Github: Postcoordination Demonstrator. Available online: https://github.com/ihtsdo/iid-postcoordination (accessed on 12 April 2023).
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; 307–311.
Vogl, K.; Ingenerf, J.; Kramer, J.; Chantraine, C.; Drenkhahn, C. LUMA: A Mapping Assistant for Standardizing the Units of LOINC-Coded Laboratory Tests. Applied Sciences 2022, 12, 5848:1–5848:22. [Google Scholar] [CrossRef]
Steel, J. How and when to use FHIR Terminology Service APIs. Presented at the HL7 FHIR DevDays 2019, Redmond, 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).
SNOMED International. SNOMED CT Compositional Grammar Specification and Guide, Version 2.4. International Health Terminology Standard Development Organisation, 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).
SNOMED International. SNOMED CT Editorial Guide. International Health Terminology Standard Development Organisation, 2023. Available online: https://confluence.ihtsdotools.org/display/DOCEG/PDFs+for+Download (accessed on 20 April 2023).
SNOMED International. SNOMED CT Machine Readable Concept Model Specification, Version 1.0. International Health Terminology Standard Development Organisation, 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).
SNOMED International. SNOMED CT Expression Constraint Language Specification and Guide, Version 2.1. International Health Terminology Standard Development Organisation, 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).
Github: SNOMED CT Authoring Templates. Available online: https://github.com/IHTSDO/snomed-templates (accessed on 17 April 2023).
Confluence: Template specification. Available online: https://confluence.ihtsdotools.org/display/SCTEMPLATES/Template+specification (accessed on 17 April 2023).
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; 326–331.
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 medical informatics 2021, 9, e21929:1–e21929:21. [Google Scholar] [CrossRef]
Terminology Module. Available online: https://www.hl7.org/fhir/terminology-module.html (accessed on 12 April 2023).
Metke-Jimenez, A.; Steel, J.; Hansen, D.; Lawley, M. Ontoserver: A syndicated terminology server. J. Biomed. Semant. 2018, 9, 1–10. [Google Scholar] [CrossRef] [PubMed]
Confluence: Features of Known Servers. Available online: https://confluence.ihtsdotools.org/display/FHIR/Features+of+Known+Servers (accessed on 12 April 2023).
Ontoserver - SNOMED CT Post-Coordination support. Available online: https://ontoserver.csiro.au/docs/6/postcoordination.html (accessed on 12 April 2023).
Simplifier: Kassenärztliche Bundesvereinigung (KBV)/Projects. Available online: https://simplifier.net/organization/kassenrztlichebundesvereinigungkbv/~projects (accessed on 12 April 2023).
SNOMED International SNOMED CT Browser. Available online: https://browser.ihtsdotools.org/ (accessed on 12 April 2023).
SNOMED International. SNOMED CT Diagramming Guideline. International Health Terminology Standard Development Organisation, 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).
Ontoserver: Australian test endpoint. Available online: https://r4.ontoserver.csiro.au/fhir (accessed on 12 April 2023).
Bodenreider, O.; Cornet, R.; Vreeman, D. Recent Developments in Clinical Terminologies—SNOMED CT, LOINC, and RxNorm. Yearb. Med. Informatics 2018, 27, 129–139. [Google Scholar] [CrossRef] [PubMed]
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, 2001; 17–21.
Peterson, K. J.; Liu, H. Automating the transformation of free-text clinical problems into SNOMED CT expressions. AMIA Summits on Translational Science Proceedings 2020, 497–506. [Google Scholar]

Figure 1. An overview of the architecture conceptualized for the envisioned application including a mockup of the user interface.

Figure 2. To formulate a correct Postcoordinated expression SNOMED CT’s Compositional Grammar and Concept Model need 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 sub-concept of 129264002 |Action|, thus, the Attribute relationship of the expression above is valid.

Figure 3. Excerpt of a SNOMED CT Expression Template with static and variable components as well as cardinalities.

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 5. A screenshot of the user interface showing the PCE creation process using Expression Templates.

Figure 6. A screenshot of the user interface showing the Template creation process.

Figure 7. Results of the usability survey.

Table 1. FHIR resources and operations needed within the 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.

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.

© 2023 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

Copyright: This open access article is published under a Creative Commons CC BY 4.0 license, which permit the free download, distribution, and reuse, provided that the author and preprint are cited in any reuse.

MDPI Initiatives

Important Links

Choose an area of interest and we will send you notifications of new preprints at your preferred frequency.

Disclaimer