Sage Journals: Discover world-class research

Abstract

Objective: Accessing reliable medical information online in Germany is often hindered by misinformation and low health literacy. Tala-med, an ad-free search engine, was developed to provide curated, expert-reviewed content with filters for trustworthiness, recency, user-friendliness, and comprehensibility. This study re-engineered the original system to overcome technical limitations while maintaining result consistency. Methods: A modular architecture was designed using Elasticsearch, a fastText-based synonym system, and a subZero-powered admin interface. The system was evaluated using 214 unique queries to compare performance and result similarity with the legacy version. Results: The new implementation improved query processing speed while preserving result consistency. Synonym handling was enhanced using fastText, and system maintainability increased via a centralized database and modular backend. The administrative interface simplified data updates and configuration tasks. Conclusion: The re-engineered tala-med search engine maintains the original system’s strengths while enabling greater scalability, flexibility, and future extensibility. The open-source platform offers a foundation for advancing domain-specific search systems and supports applications beyond the medical field.

Keywords

databases health literacy medical informatics applications natural language processing search engine

Introduction

The internet has become a vital resource for accessing medical information in Germany,¹ with a significant portion of the population relying on online sources for health-related knowledge. However, this trend also brings to light prevalent problems associated with medical information online, including inaccuracies, lack of internet literacy, and misinformation.^2–4 Moreover, the origin and motivation of available health information vary in quality and trustworthiness, with advertisements often mixed into crucial information on websites.

Approximately 70% of the German population actively engages in searching for health-related content online, and the trend is rising.⁵ However, users often lament the lack of clarity regarding the trustworthiness of existing websites. Despite this surge in internet usage for health inquiries, the quality of health information online varies widely,^6,7 leading users to perceive frequently visited and popular websites as reliable, regardless of actual content quality.^8–12 Moreover, reliance on digital platforms for health information poses a significant challenge due to the substantial influence of search engine results. Users tend to rely on the first few search results displayed on the search engine result page, often advertisements, perceiving them as more trustworthy despite potential variations in information quality.^8,11,13 Low health literacy and digital health literacy among the German population exacerbate these challenges.^14–16 With up to 45% of the German population exhibiting problematic or inadequate internet skills, many individuals face navigational needs, relying on support to efficiently search and evaluate health information online, which, coupled with the growing amount of digital health information, raises concerns about misinformation and health-related misconceptions.^17,18

In response to these challenges, the tala-med search engine was developed to offer users a safer alternative. It features a search index built from curated sources, verified by medical professionals, and free of advertisements.¹⁹ Based on the knowledge gained in a related project,²⁰ criteria to assess web domains according to these needs were developed. Each domain was evaluated by experts accordingly based on random samples, estimating its quality in the four categories trustworthiness, recency, user-friendliness and comprehensibility. The interface provided users with the option of filtering their search results by four quality indicators to ensure transparency and provide the user with more power over their search results.¹⁹ Specht et al.¹⁹ performed an evaluation of the tala-med search, reporting a positive reception of the new independent, non-commercial medical search engine among initial users highlighting its role in enhancing the accessibility of reliable and evidence-based medical information on the internet, underscoring the imperative need for high-quality search results and addressing users’ navigational needs to promote health literacy and empower individuals to make informed health decisions. Throughout both the study period and the ongoing operation of the tala-med search engine, certain technical constraints concerning flexibility were identified.

The search engine was originally developed using open source tools and systems while Elastic’s AppSearch platform provided the main search functionality. The user-facing website was built with React²¹ and material UI²² and hosted with nginx.²³ This website then used the API provided by AppSearch for querying the search index, including filtering by the quality indicators, and retrieving search query suggestions.

The key issue with the existing tala-med search engine was the dependence on AppSearch 7.16 as a monolithic and proprietary search backend preventing core customizations. Therefore, the goal of the present work was to replace this monolithic architecture with a more flexible and customizable software stack inspired by Scheible et al.,²⁴ steering towards a modular single-responsibility principle²⁵ using microservices and being database-centric. Our new implementation was designed to closely replicate the original functionality while improving performance in terms of query processing speed, as demonstrated through controlled evaluation.

This study is primarily a system development and evaluation project focused on addressing the technical limitations of the original system. It involves two major components: (1) System design and implementation, emphasizing modularity and maintainability by integrating advanced tools like Elasticsearch and subZero to enhance flexibility and extensibility; and (2) performance and similarity evaluation, which assessed the system through predefined query sets to ensure it produced results similar to the legacy system in terms of content and ranking, while also demonstrating improved query processing speed.

The study further demonstrates the extensibility of the new architecture through the integration of a fastText²⁶ model for synonym detection and the inclusion of an administrative interface to support day-to-day operations. While direct user evaluation was not conducted, the design and evaluation approximated real-world usage scenarios, providing a foundation for future user-based studies or A/B testing to validate and refine the system. The software components developed as part of this study are available under MIT.

Materials and methods

Architecture

In order to re-engineer the existing tala-med search engine, a new architecture was devised. The website was rebuilt and integrated with the new administrative interface powered by subZero,²⁷ featuring a refined filtering UI that enables users to customize their search more effectively. SubZero is a framework to create administrative tools by automatically generating a REST API with a web console from the database schema. At the core of the new architecture an API was built with ExpressJS²⁸ using Typescript²⁹ and running on Node.js.³⁰ This server was used to combine all components together, from integrating subZero for an authenticated admin interface to supply the frontend with configuration and search endpoints. To perform all those operations the API communicated with multiple secondary backend components, most importantly the Postgres database³¹ which in turn was connected to an Elasticsearch (ES) cluster to facilitate full-text search queries. The API was also connected to a fastText²⁶ server to extract synonyms from a query to improve the relevance of the results. The data flow and interaction between these components are illustrated in Figure 1. The diagram shows how user queries are processed, starting from the frontend user interface, through the backend API, to the database, Elasticsearch cluster, and synonym server, before the ranked results are returned to the frontend. All components were dockerized for simple deployment and maintenance. Subsequent sections detail these components from the database layer to the web-frontend.

Figure 1.

Block diagram of the tala-med search engine architecture. The user initiates a query from the frontend user interface, which sends the query to the backend API (ExpressJS). The API processes the query by interacting with the database (Postgres + ZomboDB), Elasticsearch cluster, and fastText synonym server to retrieve relevant data. The system then filters and ranks the results before delivering them back to the user via the frontend interface. The modular backend architecture ensures scalability, flexibility, and efficient query processing.

ZomboDB and elasticsearch

For complex full-text search in the new search engine, we retained Elasticsearch as the backend, consistent with the legacy AppSearch. Simultaneously, we consolidated all data into a single source to simplify maintenance and enable data-layer optimizations. Consequently, we decided to store all our data, including the website index, in a Postgres database. This database was connected with an ES cluster, through the native Postgres extension ZomboDB,³² which allows the seamless integration of ES queries into SQL queries. This approach has already demonstrated effectiveness in similar projects within the medical domain.²⁴ ZomboDB also facilitates field mapping and other ES functions allowing the use of advanced ES features. We used ZomboDB v3000.1.25 with Postgres 15 and ES in version 8.10.

Database layout

We opted for a central database containing the search index, aiming for a more adaptable and manageable structure compared to the legacy system. This move also enhanced the overall maintainability of our application. The database layout is shown in Figure 2. It was kept in Boyce-Codd normal form³³ and contains all application data alongside our index. The search index was stored in the documents table while the quality indicators were stored in relation to the domains table. These were separated into category and filter-value tables for additional flexibility, although the flexibility was restricted by the need to name the categories explicitly in the SQL script to build the required materialised views used during processing. The documents table was extended with a ZomboDB index to allow for ES queries to operate on this data as well as to configure custom field analyzers like stemming and autocomplete.

Figure 2.

Database schema; From left to right, main data, application configuration, views for import and domain-filter data for search and last the synonym table.

Backend API

As highlighted in the architecture diagram (see Figure 3), the key element used to merge all these different software systems was the API built using an ExpressJS server, handling four main aspects: the serving of the static website files, the search query API, the configuration retrieval endpoints and the endpoints for the admin interface powered by subZero.

Figure 3.

Search engine architecture.

The API server’s primary function was to search through the documents, facilitated by a unified API endpoint. This endpoint managed search queries, pagination, and filtering, and toggles between legacy and fastText synonym handling. It constructed the final SQL query, which replicated the search equation used in the legacy AppSearch system (see Multimedia Appendix 1 in Specht et al.¹⁹) by incorporating full-text search and domain quality indicator values. A full-text ES search was constructed based extracted ES queries generated by AppSearch in the legacy system. This ES query combined the user query with any synonyms using a logical OR and a down boost of 0.75. Additionally, it considered the content-field with a stemming filter at a slightly lower factor. This implementation reflected the behavior and field generation of AppSearch but omited irrelevant ones like ”prefix” while including the stemming field, which was utilized in phrase and fuzzy queries.³⁴ Following the ES search, results were matched with domains and their quality indicators. These informed filtering and contributed to the document score, finalizing document ordering. Pagination was implemented using SQL limit and offset functions. In addition to the search endpoint, the API offered endpoints for the frontend website to access static configuration through public endpoints. This included filter categories and dynamic UI fields like help texts. Moreover, the API offered an endpoint for auto-complete functionality in the search field, utilizing Elasticsearch’s suggester in completion mode on the title-field, chosen for its dense information and suitability for potential search queries. As part of the modernization, an admin interface was added using subZero. It offers authenticated endpoints, login functionality, and a web interface for CRUD operations to manage application data and the index.

Synonym implementations

Legacy synonyms

Firstly, the synonym-set approach of AppSearch was reverse-engineered and reimplemented in the new system. In the present implementation, it is based on a predetermined set of 500 synonym relations each containing up to 32 synonyms, so-called synonym-sets. These relations were rebuilt in the new system using a simple Postgres table and an ES index on top of that to efficiently search for matches based on an input string. In this implementation, the lookup was done by using an ORed query with all words of the search query and a limit of the result number on the number of words in the query. After finding all matching synonyms, they were added to a secondary query which was ORed into the main query at a down boost.

FastText synonyms

In addition to the rebuild of the legacy system, a new synonym system was implemented to showcase the new flexibility gained by using our new architecture. Instead of extracting synonyms based on predefined synonym-sets or relations, we decided on using a combination of POS tagging and a fastText²⁶ powered k-nearest-neighbour (kNN) search to extract relevant synonyms from the search queries. To facilitate integration of this with our backend API server, a FastAPI-powered REST server was constructed. Figure 4 shows the architecture of this server, which performed the necessary steps and provided configurable access to the optional POS-tagging and amount of generated synonyms (k). Two fastText models were trained unsupervised on the German medical Wikipedia category exported on 8.1.2024 alongside a truecaser based on the pypi package truecase³⁵ which was inspired by tRuEcasIng.³⁶ One model was trained with uncased data while the second one used the original cased data. Generally, Wikipedia has relatively good grammar³⁷ which suggests that the casing of the training data should be of good quality. During inference, the truecaser was used in tandem with the cased fastText model to improve the relevance of the kNN search. The cased fastText model was used as default for the kNN search, which searched synonyms for the nouns in the search query. The Part-of-Speech (POS) tagging system of stanza³⁸ was used to target the fastText-kNN search only to relevant words (see Figure 3).

Figure 4.

FastText server components and data flow between them, as queried by the main API. The data flow shows the generation of k synonyms which is parameter-configurable.

Search query processing

The search functionality builds upon the equation introduced in Multimedia Appendix 1 in Specht et al.,¹⁹ incorporating synonym handling by expanding the query Q into Q*, where:

Q^{*} = Q \cup Synonyms (Q)

Synonyms are generated using a fastText model or pre-defined synonym sets. The expanded query Q* is then utilized in the scoring function to compute the relevance of a document D*, ensuring compatibility with the original approach described by Specht et al. Here, D* refers to a document in the search index that is evaluated based on its fields and quality indicators. The function v (D*, f) denotes the value of a specific field f in the document D*. This allows the scoring function to evaluate documents by considering field-specific relevance, as well as additional quality constraints.

The scoring function is based on the Okapi BM25 formula:

\begin{aligned} score (D^{*}, Q^{*}) = & \sum_{i = 1}^{n} IDF (q_{i}) \cdot \frac{f (q_{i}, D^{*}) \cdot (k_{1} + 1)}{f (q_{i}, D^{*}) + k_{1} \cdot (1 - b + b \cdot \frac{len (D^{*})}{avgdl})} \end{aligned}

(1)

where f (q_i, D*) is the frequency of the term q_i in document D*, len (D*) is the length of the document (in words), and avgdl is the average document length in the collection. The parameters k₁ and b are typically set as k₁ ∈ [1.2, 2.0] and b = 0.75. The inverse document frequency IDF (q_i) is computed as:

IDF (q_{i}) = \log \frac{N - n_{i} + 0.5}{n_{i} + 0.5}

where N is the total number of documents in the collection, and n_i is the number of documents containing the term q_i.

To incorporate field-specific weights and quality constraints, the weighted scoring function is defined as:

\begin{aligned} {score}^{*} (D^{*}, Q^{*}) = & \sum_{f \in F} w (f) \cdot score (v (D^{*}, f), Q^{*}) + \sum_{c \in C} w (c) \cdot v (D^{*}, c) \end{aligned}

(2)

Here, F = {title, content, url} represents the set of text fields, and C = {recency, user-friendliness, comprehensibility, trustworthiness} represents the set of quality constraints. These quality constraints are computed based on sample URLs of the domains of the search index and can be used as filter (see Multimedia Appendixes 1 and 3 in Specht et al.¹⁹). Similar to Specht et al.,¹⁹ the weighting function w(x) is defined as:

\begin{aligned} w (x) = \{\begin{cases} 8.5, & if x = c o n t e n t, \\ 7.5, & if x = t i t l e, \\ 2.0, & if x = u r l, \\ 5.0, & if x \in C . \end{cases} \end{aligned}

(3)

This approach combines the probabilistic relevance framework of BM25 with field-specific and constraint-based weighting, tailored for medical information retrieval.

Evaluation

Performance

To measure the performance of our system we created two sets of example queries. The first set consisted of 98 unique (compound-) words created from Google’s top & rising searches in the topic of medicine (Dec. 2023), the top 25 search queries used in a previous study of the tala-med search engine (see Multimedia Appendix 5 in Specht et al.¹⁹) and a curated set of ChatGPT generated search queries. For the second set, the same list was used as a base and transformed into full-sentence queries. This was done manually and by generating and curating queries with ChatGPT in order to test the systems’ behavior on sentence queries. These two sets were then used to query the systems repeatedly. To ensure reproducibility of the ordering of the search requests, the evaluation runs were performed in a single thread on a separate machine. After an additional 10% warm-up phase, the results were gathered and averaged over 10 runs. Both sets were run independently in sequence on a virtual machine with four cores and 16 GB of RAM. Between different runs the machine was restarted to ensure a consistent clean state. The actual processing time was isolated from the transport time and this was used as the primary metric for the analysis. Since most users focus on the first results presented by a search engine,³⁹ the result size of the evaluation queries was limited to 60 (20 per page). For the used queries the median number of results found by both the legacy and new system was 60 (IRQ 60-60) with an overall mean of more than 50 in all cases. This guaranteed that all test queries produced matches and exercised the full retrieval and ranking pipeline, rather than hitting cases with few or no results.

Similarity

We evaluated the search result quality using identical runs as the performance evaluation, extracting and mapping the results to their respective URLs, which acted as unique identifiers for each website. In this evaluation, we lacked a gold standard for assessing the objective quality and ranking order of search results in our search engine. Thus, our analysis compares the legacy system with the new one, measuring the similarity of their results. Similarity was measured per query based on the overlap of results present in both the legacy and the new system. Additionally, the distance between the overlapping results was computed based on their ranking position in the results returned by each system. These two metrics formed the base of analysing how close the new system was to the legacy search engine.

Results

Performance

The comparative analysis in Figure 5 illustrates performance differences between the legacy and new systems across different query scenarios. The legacy system, shown in orange, exhibited substantial increases in query processing time when synonyms were enabled, impacting both single-word and phrase queries. Although the new system was generally faster than the legacy system, there was a slight exception observed with phrase queries lacking synonyms, where the new system was marginally slower by approximately 0.05 s, equivalent to 112% of the legacy system’s runtime. Additionally, the performance of the new system varied depending on the complexity of the synonym system used. For instance, the fastText synonym system demonstrated slower performance compared to the re-implemented legacy synonym-set system. Moreover, the introduction of the truecaser also resulted in a minor increase in processing time. Furthermore, aside from the baseline runs, the new system displayed slightly less consistent processing times compared to AppSearch, particularly noticeable in single-word queries where the new system exhibited a few more outliers. However, these discrepancies were minor when considering the overall performance gap between the systems.

Figure 5.

Performance benchmark results; Legacy system in orange boxes; ”Stemming” runs are runs with only the base features enabled (baseline); ”TC” = True casing enabled. The suffix ”W” indicates word-only queries and ”P” phrase queries.

Similarity

Table 1 shows the findings from the similarity analysis for word queries. It indicates that the baselines, without any synonym system enabled, exhibited high similarity, with a median overlap exceeding 90%. This suggests that the majority of results appeared in both systems’ result pages for the same search term, with an average distance of approximately 5. However, the standard deviation of the distance was nearly equal to the average distance, indicating significant differences in result ordering despite their similarity. Moreover, the rebuilt synonym-set system demonstrated similarity to the legacy AppSearch system. However, with the implementation of the fastText synonym system, differences became more pronounced, although nearly half of the results still overlapped. Additionally, notable differences were observed in the fastText models with and without casing information. While both exhibited similar performance when compared to the legacy system, significant discrepancies emerged when compared to each other, as evident in the rightmost column of Tables 1 and 2.

Table 1.

Similarity metrics of word queries, including fastText with true casing across a median of 60 results.

	Baseline	Synonyms	fastText truecasing	fastText	fastText (TC) vs. fastText
Overlap mean	78.78% (SD 30%)	71.55% (SD 32%)	46.33% (SD 27%)	50.00% (SD 30%)	61.98% (SD 29%)
Overlap median	91.67%	87.50%	48.33%	52.21%	68.33%
Avg. distance	5.3	6.34	13.68	12.95	11.62
Std distance	4.59	5.48	9.91	9.33	9.06
Avg med distance	4.1	4.96	11.87	11.31	9.67

Table 2.

Similarity metrics of phrase queries, including fastText with true casing across a median of 60 results.

	Baseline	Synonyms	fastText truecasing	fastText	fastText (TC) vs. fastText
Overlap mean	67.37% (SD 21%)	27.51% (SD 17%)	31.48% (SD 32%)	29.55% (SD 30%)	55.70% (SD 31%)
Overlap median	70.00%	5.00%	31.67%	25.83%	56.67%
Avg. distance	10.59	10.19	16.28	16.5	11.66
Std distance	9.15	6.21	11.97	12.35	9.31
Avg med distance	8.41	9.09	13.73	14	9.84

Table 2 presents the outcomes of the similarity analysis for phrase queries. In the baseline configuration, both the new and legacy systems remained closely aligned, although not as much as with single-word queries. However, the distance of overlapping results notably increased, averaging over 10. The introduction of synonym systems led to significant disparities in results, a trend that persisted with the fastText synonym systems. However, the fastText systems were closer to the legacy system compared to our synonym-set implementation. This deviation from the legacy system, though expected due to differing synonym handling in phrase queries by AppSearch, highlights a substantial difference in results. Similar to single-word queries, the fastText systems with and without true casing exhibited comparable performance when compared to the legacy system but displayed significant discrepancies when compared to each other.

Flexibility and final product

To evaluate the achieved flexibility of the new architecture, the integration of the fastText synonym system as well as the subZero admin interface, were built. Additionally, the index data was strictly separated from the quality indicators, which allowed easy updates to the data using the admin web page and only requires a quick rebuild of a materialised view also exposed through the admin console. Other parts of the application, like help texts, could be edited the same way and only required a website reload afterwards. Figure 6 shows the final seach UI and the admin dashboard.

Figure 6.

Screenshots of final search engine with filter UI and active filtering for “Verständlichkeit” (right picture) and subzero admin dashboard (left picture). The translations of the filter-categories can be seen in the left screenshot.

Discussion

Principal findings

The redesign and rebuild of the search engine aimed to enhance flexibility and control. This goal was realized by implementing a new architecture that supports the integration of additional features and tools. This architecture grants full control over data layout and optimizations, and facilitates the integration of any compatible service with the main backend server. For instance, domain evaluation could be directly integrated into the application, eliminating the need for separate third-party services. Leveraging plain Elasticsearch also enabled direct utilization of features not available through AppSearch, such as the Completion Suggester.⁴⁰

Our evaluation indicated a significant performance improvement with the new architecture. While some of this enhancement may be attributed to the newer ES version 8.10 utilized in the new system compared to ES 7.16 in the legacy AppSearch,⁴¹ most of the performance gain in ES 8 is related to scalability aspects. Despite using a single-node ES cluster for the new system, which should have minimized scalability effects, the new system consistently outperformed the legacy system, even with performance-intensive synonym systems. Additionally, our evaluations revealed that AppSearch seems not to consider synonyms in full-sentence queries, whereas our new system effectively integrates synonyms in all query types.

While the absolute speed improvements observed in our system may appear marginal, prior research has shown that even sub-second reductions in response time can meaningfully impact user satisfaction, perceived usability, and engagement.^42,43 More generally, Nah et al.⁴⁴ demonstrate that system response time is a key determinant of perceived usability and user experience in web-based applications. In the context of health information retrieval, where users often search under emotionally charged or time-sensitive conditions, responsiveness, in both the technical and informational sense, contributes not only to usability but also to trust and perceived system quality. Although Hesse et al.⁴⁵ do not investigate latency directly, they highlight a behavioral shift where users increasingly turn to the Internet as their first source for health information. Keselman et al.⁴⁶ further emphasize the importance of aligning health systems with user needs and competencies, underscoring the need for responsive, understandable, and trustworthy digital tools. This reinforces the imperative to deliver systems that are not only functionally reliable, but also competitively responsive.

Moreover, user expectations around performance are increasingly shaped by dominant platforms like Google and Bing. Arapakis et al.⁴³ demonstrate that even moderate response delays (under 1 s) in mobile web search can significantly increase user frustration, perceived sluggishness, and stress, even when delays are within traditionally acceptable bounds. Users today are not only sensitive to raw loading speed but are also more likely to interpret delays as indicators of poor system quality. In competitive search environments, where response time is part of the user experience baseline, a delay of even 500 ms can be enough to reduce engagement or trust.^42,47

Given that tala-med positions itself as a high-trust alternative to commercial search engines, speed is not merely a technical metric. It is a requirement for credibility. Delivering fast and fluid interactions is essential to earning and maintaining user trust. This underscores the need to deliver trustworthy systems that are also competitively responsive.

Adopting a database-centric architecture enabled the new system to be finely tailored to our specific needs. For instance, we utilized materialized views to precompute aspects of search queries, reducing the need for recomputations with each query and minimizing abstraction layers, thereby enhancing system performance. Furthermore, this approach facilitated integration with the custom subZero administration tool and in future will allow the integration of extensions to accommodate research tasks like survey management and evaluation. Our selection of independent, highly customizable systems has substantially reduced dependency on Elastic, enabling us to implement new features without waiting for AppSearch support.

Significant differences were observed between the legacy and new systems, particularly in the similarity of results with synonyms in full-sentence queries. However, our analysis still indicated that the new system closely aligns with the legacy search engine, especially considering the prevalence of single-word queries in tala-med.¹⁹ Additionally, the weighting between user input query and inferred synonyms (currently set at 0.75 boost) emerged as a relevant parameter for balancing synonym influence on ranking. Our analysis of the AppSearch-based system also revealed persistent challenges in synonym handling for search queries. In particular, the handling of compound words that refer to the same concept but appear as separate words during text processing have posed a challenge and could be explored further.

Our implementation of fastText-based synonym expansion builds on prior research demonstrating the effectiveness of word embeddings in biomedical information retrieval. Unlike rule-based synonym systems, fastText models include subword-level information, allowing them to generalize to inflected or compound biomedical terms, frequent challenges in health-related queries. Yeganova et al.⁴⁸ conducted a comparative evaluation of three popular word embedding models, word2vec,⁴⁹ GloVe,⁵⁰ and fastText,²⁶ to assess their ability to detect biomedical synonyms. While no single model outperformed the others across all scenarios, fastText demonstrated superior performance in identifying high-precision synonym pairs for different-stem terms, a scenario especially relevant for search applications like ours. As our system uses only the top-k ranked synonyms, this prioritization of precision over recall aligns well with our design objective: returning highly relevant suggestions rather than a large set of noisy expansions. In a complementary line of work, Agibetov et al.⁵¹ showed that fastText achieves competitive performance in biomedical sentence classification, with much faster training and greater scalability compared to deep learning models. These findings validate our design decision to integrate fastText for dynamic synonym expansion, a feature in which the legacy system lacked support.

To support this and future extensibility, we re-engineered the search engine using a modular, database-centric architecture. Modular software designs are increasingly valued in health information systems for their adaptability and long-term maintainability. As Bathelt et al.⁵² note, modularity enables independent evolution of system components, while Rasmussen et al.⁵³ highlight its role in solving interoperability and representation challenges in biomedical applications. Our architecture decouples the core services search, synonym processing, and administration. This makes it easier to integrate features such as ontology-based ranking or explainability modules. This approach not only modernizes tala-med but also contributes a replicable and extensible blueprint for future domain-specific search engines in healthcare.

Limitations

As there was no gold standard for ranking suitable to the tala-med search engine, our evaluation was limited to comparing the new system with the existing AppSearch. Hence, we couldn’t objectively measure the quality of our new search engine’s results. Additionally, differences were expected due to AppSearch being closed-source, lacking comprehensive documentation for complete replication.

The synonym solutions used, had their limitations and nuances. The rebuilt legacy system approximated which synonym sets to use based on the query’s word count, potentially differing from AppSearch’s approach. In contrast, the new system offers greater flexibility, with fewer constraints on synonym-set size and easy extension via its ES index. For instance, synonym-sets can now be used in phrase queries. The fastText and truecaser were not individually evaluated, leaving their potential limitations unknown. This aspect is evident in the similarity evaluation of the fastText model with and without truecasing. Further investigation could unveil valuable insights and clarify the impact of truecasing on the search.

The new architecture enhanced search engine flexibility but introduces higher development complexity. Previously reliant on a monolithic architecture centered around AppSearch and the UI, the current setup will necessitate separate maintenance and development of numerous components. However, the subZero admin interface and database-centric architecture streamlined system maintenance post-deployment.

Future works

First of all, the deployment of the new architecture in production is planned, which also requires integrations into existing extract, load and transform (ELT) processes and their adaption. Future work could focus on establishing a gold standard or objective method for evaluating search result quality. The newly added flexibility allows for the implementation of various methods to enhance the search engine. Inspired by TourBERT⁵⁴ the more sophisticated domain-specific machine learning model GerMedBERT⁵⁵ could be used to extract synonyms and leverage available domain knowledge. Similarly, ontologies and terminology systems could enhance the semantic relevance of search results by leveraging domain knowledge in medicine. For instance, instead of solely relying on an ML system to find synonyms, related terms could be identified through traversal of the SNOMED CT⁵⁶ terminology system. Additionally, the MeSH terminology system could annotate search index pages and refine search queries, akin to PubMed’s functionality. In addition, a user evaluation study similar to that of Specht et al.¹⁹ or an A/B testing approach, as described by Strecker et al.,⁵⁷ could provide valuable insights into the effectiveness, usability, and real-world impact of the newly implemented architecture. Such an evaluation would involve collecting user feedback, analyzing search behavior, and measuring both satisfaction with search results and overall user engagement. These types of evaluations represent an important next step to ensure that the system’s technical improvements translate into meaningful user benefit and real-world adoption.

Conclusions

In conclusion, we successfully replaced the monolithic AppSearch backend of the tala-med search engine with a more flexible and efficient software stack. This transition addressed previous limitations and improved system performance. Despite minor differences in search results compared to the legacy system, the new system is considered close enough to be a viable replacement. The new flexibility was demonstrated through the implementation of a fastText-powered synonym system, showcasing the system’s capabilities and setting a precedent for future extensions to the tala-med search engine. Furthermore, full-sentence queries now incorporate synonym usage, expanding search functionality. Future works can leverage the new search engine to integrate sophisticated enhancements, improving search relevance and exploring novel concepts in medical search engines. Additionally, extensions to facilitate research and analysis can now be directly incorporated into tala-med, eliminating the reliance on third-party services. This includes enabling domain evaluation by experts within the application. While promising, the study has several limitations. Due to the lack of a suitable gold standard for tala-med, evaluation was restricted to comparisons with the legacy system. Furthermore, the true impact of fastText-based synonym expansion and truecasing remains to be assessed in detail, and the increased complexity of the new modular system may require additional maintenance effort. Future work will focus on conducting user-centered evaluations (e.g., A/B testing), and exploring deeper integration of medical ontologies such as SNOMED CT and MeSH to further enhance relevance and interpretability. Finally, the modular and database-centric technology concept developed for tala-med, which we have released as open-source, can be adapted for a wide range of applications beyond medical information retrieval, providing a scalable and flexible framework for other domain-specific search engines and information systems.

Footnotes

Acknowledgements

The authors would like to thank Johann Frei for his feedback and proof reading of parts of the manuscript.

Author contributions

Conceptualization, Raphael Scheible-Schmitt; Data curation, Florian Albrecht and Raphael Scheible-Schmitt; Formal analysis, Florian Albrecht; Investigation, Florian Albrecht and Raphael Scheible-Schmitt; Methodology, Florian Albrecht, Ruslan Talpa and Raphael Scheible-Schmitt; Project administration, Raphael Scheible-Schmitt; Resources, Raphael Scheible-Schmitt; Software, Florian Albrecht, Ruslan Talpa and Raphael Scheible-Schmitt; Supervision, Raphael Scheible-Schmitt; Validation, Florian Albrecht; Visualization, Florian Albrecht; Writing – original draft, Florian Albrecht and Raphael Scheible-Schmitt; Writing – review & editing, Florian Albrecht, Ruslan Talpa and Raphael Scheible-Schmitt.

Funding

The authors disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by the German Ministry for Education and Research grant number (01ZZ2304A).

Declaration of conflicting interests

The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Data Availability Statement

The software components developed as part of this study are available under MIT and can be accessed via the following link: .

References

Baumann

Czerwinski

Rosset

, et al. How do people in Germany seek health information? Insights from the first wave of HINTS Germany. Bundesgesundheitsblatt - Gesundheitsforsch - Gesundheitsschutz 2020; 63(9): 1151–1160.

Wang

McKee

Torbica

, et al. Systematic literature review on the spread of health-related misinformation on social media. Soc Sci Med 2019; 240: 112552.

Daraz

Morrow

Ponce

, et al. Can patients trust online health information? A meta-narrative systematic review addressing the quality of health information on the internet. J Gen Intern Med 2019; 34(9): 1884–1891.

Rowe

Alexander

. Fighting nutrition and health misinformation: enlisting the public’s help. Nutr Today 2022; 57(1): 34–37.

Eurostat . Individuals using the internet for seeking health-related information. 2023. https://ec.europa.eu/eurostat/databrowser/product/view/isoc_ci_ac_i

Zhang

Sun

Xie

. Quality of health information for consumers on the web: a systematic review of indicators, criteria, tools, and evaluation results. J Assoc Inf Sci Technol 2015; 66(10): 2071–2084.

Eysenbach

Powell

Kuss

, et al. Empirical studies assessing the quality of health information for consumers on the world wide web: a systematic review. JAMA 2002; 287(20): 2691–2700.

Marstedt

. Das Internet: auch Ihr Ratgeber für Gesundheitsfragen? 2018. https://www.bertelsmann-stiftung.de/de/publikationen/publikation/did/das-internet-auch-ihr-ratgeber-fuer-gesundheitsfragen

Hambrock

. Die Suche nach Gesundheitsinformationen. 2018. https://www.bertelsmann-stiftung.de/de/publikationen/publikation/did/die-suche-nach-gesundheitsinformationen

10.

Baumann

Czerwinski

. Erst mal Doktor Google fragen? Nutzung neuer Medien zur Information und zum Austausch über Gesundheitsthemen. Gesundheitsmonitor 2015; 1: 57–79.

11.

Kammerer

Gerjets

. Effects of search interface and internet-specific epistemic beliefs on source evaluations during web search for medical information: an eye-tracking study. Behav Inf Technol 2012; 31(1): 83–97.

12.

Haas

Unkel

. Ranking versus reputation: perception and effects of search result credibility. Behav Inf Technol 2017; 36(12): 1285–1298.

13.

Cai

King

Dwyer

. Using the google™ search engine for health information: is there a problem? Case study: supplements for cancer. Curr Dev Nutr 2021; 5(2): nzab002.

14.

Schaeffer

Vogt

Berens

, et al. Gesundheitskompetenz der Bevölkerung in Deutschland: ergebnisbericht. Universität Bielefeld, Fakultät für Gesundheitswissenschaften; 2016.

15.

Schaeffer

Berens

Vogt

. Health literacy in the German population. Dtsch Arztebl Int 2017; 114(4): 53–60.

16.

Schaeffer

Berens

Vogt

, et al. Health literacy in Germany - findings of a representative Follow-up survey. Dtsch Arztebl Int 2021; 118(43): 723–728.

17.

Jordan

Hoebel

. Gesundheitskompetenz von Erwachsenen in Deutschland. Bundesgesundheitsblatt - Gesundheitsforsch - Gesundheitsschutz 2015; 58(9): 942–950.

18.

Lee

Hoti

Hughes

, et al. Consumer use of “Dr google”: a survey on health information-seeking behaviors and navigational needs. J Med Internet Res 2015; 17(12): e288.

19.

Specht

Scheible

Boeker

, et al. Evaluating the Acceptance and Usability of an Independent, Noncommercial Search Engine for Medical Information: Cross-Sectional Questionnaire Study and User Behavior Tracking Analysis. JMIR Human Factors. 2025; 12: e56941. doi:10.2196/56941.

20.

Wollmann

der Keylen

Tomandl

, et al. The information needs of internet users and their requirements for online health information—A scoping review of qualitative and quantitative studies. Patient Educ Counsel 2021; 104(8): 1904–1932.

21.

React. React [Internet]. [cited 2024 Feb 28]. Available from: https://react.dev

22.

Material UI . React components that implement Material Design [Internet]. [cited 2024 Feb 28]. Available from: https://mui.com/material-ui

23.

Nginx. Nginx [Internet]. [cited 2024 Feb 28]. Available from: https://nginx.org/en

24.

Scheible

Strecker

Yazijy

, et al. A multilingual browser platform for medical subject headings. In: Informatics and Technology in Clinical Care and Public Health. IOS Press, 2022, pp. 384–387.

25.

Martin

RC.

The single responsibility principle [Internet]. 2014 [cited 2025 Sep 17]. Available from: https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

26.

Joulin

Grave

Bojanowski

, et al. FastText.zip: Compressing text classification models. 2016. arXiv:1612.03651.

27.

subZero. subZero cloud [Internet]. [cited 2024 Feb 22]. Available from: https://subzero.cloud

28.

OpenJS Foundation . Express [Internet]. [cited 2024 Feb 22]. Available from: https://expressjs.com

29.

Microsoft. TypeScript: JavaScript with syntax for types [Internet]. [cited 2024 Mar 21]. Available from: https://www.typescriptlang.org

30.

OpenJSNode.js Foundation : Run JavaScript everywhere [Internet]. [cited 2024 Mar 21]. Available from: https://nodejs.org/en

31.

PostgreSQL Global Development Group . PostgreSQL [Internet]. [cited 2024 Feb 22]. Available from: https://www.postgresql.org

32.

ZomboDB

LLC.

ZomboDB [Internet]. [cited 2024 Feb 22]. Available from: https://www.zombodb.com

33.

Tsou

Fischer

. Decomposition of a relation scheme into boyce-codd normal form. SIGACT News 1982; 14(3): 23–29.

34.

Elastic . Elasticsearch engines text field conventions | App Search documentation [Internet]. [cited 2024 Mar 18]. Available from: https://www.elastic.co/guide/en/app-search/current/elasticsearch-engines-text-subfields-support-conventions.html

35.

FuryTruecase

A library to restore capitalization

for text [Internet]. [cited 2024 Mar 18]. Available from: https://github.com/daltonfury42/truecase

36.

Lita

Ittycheriah

Roukos

, et al. tRuEcasIng. In: Proceedings of the 41st Annual Meeting of the Association for Computational Linguistics. Association for Computational Linguistics, 2003, pp. 152–159.

37.

Hammwöhner

Fuchs

Kattenbeck

, et al. Qualität der Wikipedia - eine vergleichende Studie. In: Oßwald

Stempfhuber

Wolff

(eds). Open Innovation. UVK Verl. Ges, 2007, vol 46, pp. 77–90.

38.

Zhang

, et al. Stanza: a python natural language processing toolkit for many human languages. 2020. arXiv.

39.

Rakesh Kumar

Suri

Chauhan

. Search engines evaluation. DESIDOC Bull Inf Technol 2005; 25(2): 3–10.

40.

Elastic . Suggesters | Elasticsearch Guide [Internet]. [cited 2024 Mar 20]. Available from: https://www.elastic.co/guide/en/elasticsearch/reference/current/search-suggesters.html#completion-suggester

41.

Liappis

Braun

. Benchmark-driven optimizations — how we pushed scalability to the next level in Elasticsearch 8 [Internet]. Elastic Blog. 2023 [cited 2024 Mar 20]. Available from: https://www.elastic.co/de/blog/benchmark-driven-optimizations-scalability-elasticsearch-8

42.

Brutlag

. Speed matters for google web search. Google Research Blog, 2009. https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36971.pdf

43.

Arapakis

Park

Pielot

. Impact of response latency on user behaviour in Mobile web search. CoRR 2021. arxiv. https://arxiv.org/abs/2101.09086

44.

FFHN . A study on tolerable waiting time: how long are web users willing to wait? Behav Inf Technol 2004; 23(3): 153–163.

45.

Hesse

Nelson

Kreps

, et al. Trust and sources of health information: the impact of the internet and its implications for health care providers: findings from the first health information national trends survey. Arch Intern Med 2005 12; 165(22): 2618–2624.

46.

Keselman

Logan

Smith

, et al. Developing informatics tools and strategies for consumer-centered health communication. J Am Med Inf Assoc 2008 07; 15(4): 473–483.

47.

Xilogianni

Doukas

Drivas

, et al. Speed matters: what to prioritize in optimization for faster websites. Analytics 2022; 1(2): 175–192.

48.

Yeganova

Kim

Chen

, et al. Better synonyms for enriching biomedical search. J Am Med Inf Assoc 2020; 27(12): 1894–1902.

49.

Goldberg

Levy

. word2vec Explained: deriving Mikolov et al.’s negative-sampling word-embedding method. CoRR; 2014: abs/1402.3722.

50.

Pennington

Socher

Manning

. GloVe: global vectors for word representation. In: Moschitti

Pang

Daelemans

(eds). Proceedings of the 2014 Conference on Empirical Methods in Natural Language Processing (EMNLP). Association for Computational Linguistics, 2014, pp. 1532–1543. https://aclanthology.org/D14-1162/

51.

Agibetov

Blagec

, et al. Fast and scalable neural embedding models for biomedical sentence classification. BMC Bioinf 2018; 19(1): 541.

52.

Bathelt

Lorenz

Weidner

, et al. Application of modular architectures in the medical domain - a scoping review. J Med Syst 2025; 49(1): 27.

53.

Rasmussen

Kiefer

, et al. A modular architecture for electronic health record-driven phenotyping. AMIA Jt Summits Transl Sci Proc 2015; 2015: 147–151.

54.

Arefeva

Egger

. When BERT started traveling: tourBERT—A natural language processing model for the travel industry. Digit 2022; 2(4): 546–559.

55.

Bressem

Papaioannou

Grundmann

, et al. medBERT.de: a comprehensive German BERT model for the medical domain. Expert Syst Appl 2024; 237: 121598.

56.

Donnelly

. SNOMED-CT: the advanced terminology and coding system for eHealth. Stud Health Technol Inf 2006; 121: 279–290.

57.

Strecker

Boeker

Buechner

, et al. Usability evaluation of a modern multilingual MeSH browser. Stud Health Technol Inf 2022; 295: 37–40.

Enhancing medical information retrieval: Re-engineering the tala-med search engine for improved performance and flexibility

Abstract

Keywords

Introduction

Materials and methods

Architecture

ZomboDB and elasticsearch

Database layout

Backend API

Synonym implementations

Legacy synonyms

FastText synonyms

Search query processing

Evaluation

Performance

Similarity

Results

Performance

Similarity

Flexibility and final product

Discussion

Principal findings

Limitations

Future works

Conclusions

Footnotes

Acknowledgements

Author contributions

Funding

Declaration of conflicting interests

Data Availability Statement

References