A method and system for retrieving thyroid surgery cases

Abstract

This application provides a method and system for retrieving thyroid surgery cases, relating to the field of medical information technology. It receives a composite query request containing both macroscopic imaging feature query conditions and microscopic pathological feature query conditions. Before query execution, it sends exploration requests to different data storage areas to obtain the number of case identifiers that satisfy each query condition. Subsequently, these numbers are compared to determine the filtering capability of each query condition, classifying those with fewer case identifiers as having stronger filtering capabilities. Based on this filtering capability assessment, the system can intelligently determine the query execution order of each query condition in the composite query request, prioritizing the execution of query conditions with stronger filtering capabilities. Finally, according to the determined query execution order, queries are sequentially executed in the corresponding data storage areas to obtain case identifiers, and the corresponding case data is obtained based on these identifiers.

Description

Technical Field

[0001] This application relates to the field of medical information technology, and more specifically, to a method and system for retrieving thyroid surgery cases. Background Technology

[0002] In modern medical practice, particularly in the diagnosis and surgical planning of thyroid diseases, physicians increasingly rely on advanced cloud-based systems to retrieve and reference massive amounts of historical case data. These systems aim to provide valuable decision support by rapidly matching similar cases. However, with the continuous advancement of medical technology, especially the emergence of new types of data such as high-resolution pathological images, traditional case retrieval methods are facing unprecedented challenges. How to efficiently integrate and utilize this data from different sources and at different levels of detail, and ensure the rapid provision of accurate references when clinically urgent, has become a pressing technical challenge.

[0003] For example, in a cloud-assisted thyroid surgery case retrieval system, when a doctor's workstation issues a complex query requiring matching of both macroscopic imaging features and microscopic pathological features, the query logic needs to dynamically and multi-stage filter and match a large case database containing features from different sources. Traditional standalone cloud servers or simple task distribution models cannot, within a clinically acceptable timeframe (e.g., 30 seconds), return the comprehensively sorted results. In such cases, a significant performance bottleneck emerges when handling complex queries, failing to meet doctors' urgent need for real-time, accurate case retrieval.

[0004] Specifically, when such a composite query request is received, the backend query execution module encounters a fundamental architectural obstacle. This is mainly because "macroscopic imaging features" and "microscopic pathological features" are physically separated and stored in independent databases optimized for their respective data types. For example, macroscopic imaging features might be stored in a traditional relational database for structured querying and indexing; while microscopic pathological features, especially high-dimensional pathological image features, might be stored in a specialized vector database to support efficient similarity searches. Due to this physical isolation and the difference in data models, there is a lack of a unified index or view capable of efficiently performing joint queries on data from these two different sources. Therefore, an extremely inefficient "application-layer joint" query approach is forced: it first filters all cases that meet the macroscopic imaging feature query criteria in the database storing macroscopic imaging features, which may return a huge list containing hundreds or thousands of case identifiers. Subsequently, the application must take this huge list of identifiers and query the second database storing microscopic pathological features one by one to match the microscopic pathological features for each case. This step-by-step, application-layer coordinated query pattern results in significant internal network communication overhead because data needs to be frequently transferred between different database servers and application servers. Furthermore, each query to the second database involves additional disk read / write operations, and as the returned case list grows, the accumulated input / output pressure increases exponentially, severely impacting query response time. Summary of the Invention

[0005] This application provides a method and system for retrieving thyroid surgery cases, aiming to solve the problem in the prior art that, when processing complex queries containing macroscopic imaging features and microscopic pathological features, the separation of data storage and the lack of a unified index lead to low query efficiency, excessively long response time, and an inability to meet the clinical needs for real-time and accurate case retrieval.

[0006] On the one hand, this application provides a method for retrieving thyroid surgery cases, including:

[0007] Receive composite query requests that include macroscopic imaging feature query conditions and microscopic pathological feature query conditions;

[0008] Send a first query request to the first data storage area and obtain the number of case identifiers that meet the macroscopic imaging feature query conditions based on the first query request; send a second query request to the second data storage area and obtain the number of case identifiers that meet the microscopic pathological feature query conditions based on the second query request.

[0009] The number of case identifiers returned by the first data storage area and the second data storage area is compared to determine the filtering ability of the query conditions. Query conditions with a smaller number of case identifiers are judged to be query conditions with strong filtering ability.

[0010] Based on the filtering capabilities, the query execution order of each query condition in the composite query request is determined, wherein query conditions with stronger filtering capabilities are executed first.

[0011] According to the query execution order, queries are executed sequentially in the corresponding data storage areas to obtain case identifiers; based on the case identifiers, the corresponding case data is obtained.

[0012] Optionally, the steps of sending a first query request to a first data storage area and obtaining the number of case identifiers that meet the macroscopic imaging feature query conditions based on the first query request, and sending a second query request to a second data storage area and obtaining the number of case identifiers that meet the microscopic pathological feature query conditions based on the second query request, include:

[0013] When sending a first query request to the first data storage area and a second query request to the second data storage area, a response time threshold is set for each query request;

[0014] Waiting for probe results from the first data storage area and the second data storage area;

[0015] When the response time of any query request exceeds its response time threshold, the query request is resent to the unresponsive data storage area, and at the same time, a query request is sent to the backup path of that data storage area.

[0016] The system receives exploration results from the first data storage area and the second data storage area, compares the timestamps of the received exploration results, and obtains the number of the latest and valid case identifiers.

[0017] Optionally, the first data storage area is a relational database storing macroscopic imaging features, and the second data storage area is a vector database storing microscopic pathological features; the first query request is a query instruction sent to the relational database storing macroscopic imaging features to obtain the number of cases that meet the macroscopic imaging feature query conditions, and the second query request is an estimation instruction sent to the vector database storing microscopic pathological features to obtain the number of cases that meet the microscopic pathological features.

[0018] Optionally, the step of resending the query request to the unresponsive data storage area and simultaneously sending a query request to the backup path of the data storage area when the response time of any query request exceeds its response time threshold; receiving the exploration results from the first data storage area and the second data storage area, and comparing the timestamps of the received exploration results to obtain the number of the latest and valid case identifiers includes:

[0019] Resend the corresponding query request to the unresponsive data storage area, and simultaneously send a third query request to the backup path of that data storage area;

[0020] Receive the exploration results, append a timestamp to the exploration results, and record the source path of the exploration results;

[0021] Compare the timestamps of the exploration results and select the exploration result with the latest timestamp;

[0022] The evaluation results are obtained by assessing the real-time or consistency level of the data source path of the latest timestamp investigation results, and based on the evaluation results, the number of latest and valid case identifiers is determined.

[0023] Optionally, the step of obtaining the evaluation result for the data real-time performance or consistency level of the source path of the latest exploration result with the evaluation timestamp includes:

[0024] Obtain the real-time operating metrics of the underlying data storage service corresponding to the source path;

[0025] Based on the real-time operating metrics, calculate the availability score and data freshness score of the source path;

[0026] Based on the availability score and the data freshness score, the data real-time or consistency level of the source path is determined.

[0027] Optionally, the step of determining the data real-time or consistency level of the source path based on the availability score and the data freshness score includes:

[0028] Analyze the type information of each query request, where the type information indicates the real-time or consistency requirements of the corresponding query request;

[0029] Based on the type of query request, the weights of the availability score and the data freshness score are adjusted to obtain the target weight;

[0030] Based on the target weight, the availability score and the data freshness score are weighted and combined to obtain the comprehensive data quality score of the source path;

[0031] The comprehensive data quality score is compared with a preset level threshold to determine the data real-time or consistency level of the source path.

[0032] Optionally, the step of adjusting the weights of the availability score and the data freshness score based on the type information of the query request to obtain the target weight includes:

[0033] Obtain the type information of the query request, which includes the diagnostic stage information, disease staging information, and the feature dimensions of interest for thyroid surgery cases;

[0034] Based on the diagnostic stage information, the disease staging information, and the feature dimensions, a corresponding weight combination is selected from a preset weight configuration set;

[0035] When the type information of the query request does not completely match the preset weight combination, the weights of the availability score and the data freshness score are dynamically calculated based on the priority of each dimension in the type information of the query request to obtain the target weight.

[0036] Optionally, the step of dynamically calculating the weights of the usability score and the data freshness score based on the priority of each dimension in the query request type information when the query request type information does not completely match the preset weight combination, and obtaining the target weight, includes:

[0037] Identify the diagnostic stage information, the disease staging information, and the feature dimensions, and increase the weight of the data freshness score based on the dimensions with higher requirements for data real-time performance.

[0038] Identify the dimensions with higher data consistency requirements among the diagnostic stage information, disease staging information, and feature dimensions, and increase the weight of the usability score based on the dimensions with higher data consistency requirements.

[0039] When there is a priority conflict among the diagnostic stage information, the disease staging information, and the feature dimensions, the final weight adjustment direction is determined according to the preset clinical priority rules to obtain the target weight.

[0040] Optionally, the step of dynamically calculating the weights of the usability score and the data freshness score based on the priority of each dimension in the query request type information when the query request type information does not completely match the preset weight combination, and obtaining the target weight, includes:

[0041] Identify the diagnostic stage information, the disease staging information, and the feature dimensions, and increase the weight of the data freshness score based on the dimensions with higher requirements for data real-time performance.

[0042] Identify the dimensions with higher data consistency requirements among the diagnostic stage information, disease staging information, and feature dimensions, and increase the weight of the usability score based on the dimensions with higher data consistency requirements.

[0043] Obtain clinical urgency information for current thyroid surgery cases, whereby the clinical urgency information indicates the severity of the case;

[0044] Obtain current system resource load information, which indicates the operating status of the data storage area;

[0045] Based on the clinical urgency information and the system resource load information, the weight bias between real-time performance and consistency in the preset clinical priority rules is dynamically adjusted to determine the final weight adjustment direction and obtain the target weight.

[0046] On the other hand, this application provides a thyroid surgery case retrieval system, which includes:

[0047] The receiving module is used to receive composite query requests that include macroscopic image feature query conditions and microscopic pathological feature query conditions.

[0048] The statistical information acquisition module is used to send a first query request to the first data storage area and obtain the number of case identifiers that meet the macroscopic imaging feature query conditions based on the first query request, and to send a second query request to the second data storage area and obtain the number of case identifiers that meet the microscopic pathological feature query conditions based on the second query request.

[0049] The filtering capability determination module is used to compare the number of case identifiers returned by the first data storage area and the second data storage area to determine the filtering capability of the query conditions. Query conditions with a smaller number of case identifiers are determined to be query conditions with strong filtering capabilities.

[0050] The query execution order determination module is used to determine the query execution order of each query condition in the composite query request based on the filtering capability, wherein the query condition with stronger filtering capability is executed first.

[0051] The data integration and return module is used to sequentially perform queries in the corresponding first data storage area according to the query execution order to obtain case identifiers; and obtain the corresponding case data based on the case identifiers.

[0052] This technical solution innovatively receives a composite query request containing both macroscopic imaging feature query conditions and microscopic pathological feature query conditions. Before query execution, it sends exploration requests to different data storage areas to obtain the number of case identifiers that satisfy each query condition. Subsequently, these numbers are compared to determine the filtering capability of each query condition, classifying those with fewer case identifiers as having stronger filtering capabilities. Based on this filtering capability assessment, the execution order of the query conditions in the composite query request can be intelligently determined, prioritizing the execution of query conditions with stronger filtering capabilities. Finally, according to the determined query execution order, queries are sequentially executed in the corresponding data storage areas to obtain case identifiers, and the corresponding case data is obtained based on these identifiers.

[0053] Through the above technical solution, this application effectively solves the problems of low efficiency, high network communication overhead, and high disk I / O pressure in the prior art when processing composite queries, caused by the physical storage separation of macroscopic imaging features and microscopic pathological features, differences in data models, and the lack of a unified index. This application, by pre-evaluating the filtering capability of query conditions and prioritizing queries with strong filtering capabilities, can significantly reduce the amount of data in subsequent queries, avoid the invalid processing of large intermediate result sets in traditional methods, thereby greatly reducing internal network communication and disk read / write operations, and effectively shortening query response time. Attached Figure Description

[0054] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 The diagram above illustrates a flowchart of a thyroid surgery case retrieval method in an embodiment.

[0056] Figure 2 The diagram illustrates a module configuration block diagram of a thyroid surgery case retrieval system according to an embodiment.

[0057] Figure labels: 100, Thyroid surgery case retrieval system; 10, Receiving module; 20, Statistical information acquisition module; 30, Screening capability determination module; 40, Query execution order determination module; 50, Data integration and return module. Detailed Implementation

[0058] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0059] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0060] In modern medical practice, especially in the diagnosis and surgical planning of thyroid diseases, doctors are increasingly relying on advanced cloud computing-assisted systems to retrieve and reference massive amounts of historical cases. However, traditional case retrieval methods, when dealing with complex queries that include both macroscopic imaging features and microscopic pathological features, often employ an inefficient "application-layer federated" query approach due to the separation of data storage and differences in data models. This results in significant network communication overhead and disk read / write operations, severely impacting query response time and failing to meet doctors' urgent need for real-time, accurate case retrieval.

[0061] like Figure 1 The diagram illustrates an exemplary method for retrieving thyroid surgery cases. This application proposes a method for retrieving thyroid surgery cases, comprising:

[0062] S10, receive a composite query request that includes macroscopic image feature query conditions and microscopic pathological feature query conditions.

[0063] Macroscopic imaging features refer to macroscopic characteristics extracted from medical images (such as ultrasound, CT, MRI, etc.) that can intuitively reflect the overall shape, size, location, boundary, and internal echo / density of lesions. These features are usually structured, making them easy to store and query in relational databases. For example, the diameter, morphological regularity, and calcification of thyroid nodules are all macroscopic imaging features.

[0064] Microscopic pathological features refer to the characteristic information extracted from pathological sections (such as HE-stained sections) that reflects changes in the microscopic structure of cells and tissues. These features are usually high-dimensional and unstructured, such as cell nucleus size, mitotic phase, cell arrangement, and interstitial infiltration patterns. They are often extracted into vector representations using image processing and deep learning techniques and stored in vector databases to support similarity searches.

[0065] S20, a first query request is sent to the first data storage area, and the number of case identifiers that meet the macroscopic imaging feature query conditions is obtained based on the first query request; and a second query request is sent to the second data storage area, and the number of case identifiers that meet the microscopic pathological feature query conditions is obtained based on the second query request.

[0066] The first and second data storage areas refer to independent databases storing macroscopic imaging features and microscopic pathological features, respectively. They may employ different database technologies, such as relational databases and vector databases, to suit the characteristics of their respective data and query requirements.

[0067] The case identifier is a unique code that identifies a thyroid surgery case. It allows you to retrieve complete data about the case, including imaging, pathology, and clinical information.

[0068] S30, compare the number of case identifiers returned by the first data storage area and the second data storage area to determine the filtering ability of the query conditions, wherein the query conditions with a smaller number of case identifiers are determined to be query conditions with strong filtering ability.

[0069] S40, based on the filtering capability, determine the query execution order of each query condition in the composite query request, wherein query conditions with strong filtering capabilities are executed first.

[0070] S50, according to the query execution order, queries are sequentially executed in the corresponding data storage areas to obtain case identifiers; based on the case identifiers, the corresponding case data is obtained.

[0071] This application effectively addresses the performance bottlenecks caused by data storage separation and inefficient query patterns in traditional methods by optimizing the execution strategy of compound queries. By pre-evaluating the filtering capabilities of each query condition and prioritizing the execution of queries with strong filtering capabilities, the amount of data and network transmission overhead for subsequent queries are significantly reduced, thereby greatly improving the efficiency and response speed of thyroid surgery case retrieval and providing doctors with more timely and accurate decision support.

[0072] First, the system receives a composite query request that includes both macroscopic imaging feature search criteria and microscopic pathological feature search criteria. This request can be entered by the doctor through the user interface; for example, the doctor can enter in the search system, "Find all cases of thyroid nodules that appear as hypoechoic on ultrasound with indistinct borders and whose pathology reports show papillary carcinoma characteristics."

[0073] Subsequently, to evaluate the filtering capability of each query condition, a first query request is sent to the first data storage area, and based on this first query request, the number of case identifiers that meet the macroscopic imaging feature query conditions is obtained. Simultaneously, a second query request is sent to the second data storage area, and based on this second query request, the number of case identifiers that meet the microscopic pathological feature query conditions is obtained. For example, for a macroscopic imaging feature query, an SQL query can be sent to a relational database storing macroscopic imaging features to count the number of cases that meet the conditions; for a microscopic pathological feature query, an estimation query can be sent to a vector database storing microscopic pathological features to obtain the number of cases that meet the similarity conditions. These queries are lightweight and designed to quickly obtain the preliminary number of results for each query condition, rather than obtaining complete case data.

[0074] Next, the number of case identifiers returned by the first and second data storage areas is compared to determine the filtering capability of the query conditions. Query conditions with fewer case identifiers are considered to have stronger filtering capabilities. For example, if a macroscopic imaging feature query returns 1000 case identifiers, while a microscopic pathological feature query returns 50, then the microscopic pathological feature query is considered to have stronger filtering capabilities.

[0075] Based on the defined filtering capabilities, the execution order of each query condition in a composite query request is determined, with query conditions possessing stronger filtering capabilities being executed first. For example, in the above example, microscopic pathological feature queries will be executed before macroscopic imaging feature queries. The purpose of this strategy is to narrow down the result set as much as possible in the early stages of the query process, thereby reducing the amount of data processing and network transmission overhead in subsequent queries.

[0076] Finally, according to the determined query execution order, queries are executed sequentially in the corresponding data storage areas to obtain case identifiers. For example, if the microscopic pathological feature query is executed first, a detailed query request is first sent to the second data storage area to obtain a list of case identifiers that meet the microscopic pathological feature query conditions. Then, using this smaller list of case identifiers, a query request is sent to the first data storage area to further filter out case identifiers that also meet the macroscopic imaging feature query conditions. Based on the finally obtained case identifiers, the corresponding case data is obtained and returned to the user.

[0077] The thyroid surgery case retrieval method described in this application works by intelligently optimizing the query order, effectively avoiding the performance bottleneck of the traditional "application-layer joint" query mode. Traditional methods typically first perform a macro-feature query to obtain a large preliminary result set, and then submit this result set to a micro-feature database for secondary filtering. This approach leads to a large amount of intermediate data transmission and repeated queries, especially when the macro-feature query result set is large, resulting in a sharp performance drop.

[0078] This application pre-assesses the filtering capabilities of macroscopic imaging feature query conditions and microscopic pathological feature query conditions before actual query execution. Specifically, lightweight query requests are sent to the first and second data storage areas respectively to quickly obtain the number of case identifiers that can be filtered out by each. By comparing these two numbers, it can intelligently determine which query condition has stronger filtering capabilities, that is, which condition can more quickly narrow down the initial large case database to a smaller range.

[0079] Once a query with strong filtering capabilities is identified, the query corresponding to that condition is executed first. For example, if a microscopic pathological feature query can narrow down the number of cases from millions to dozens, while a macroscopic imaging feature query can only narrow it down to thousands, then the microscopic pathological feature query will be executed first. Thus, after the first stage of querying, a significantly reduced list of case identifiers is obtained. This significantly reduced list is then used as input to execute the second query. This "coarse screening first, then fine screening" strategy greatly reduces the amount of data processing and network transmission required for subsequent queries.

[0080] Therefore, this application achieves intelligent optimization of complex queries for thyroid surgery cases by combining query execution order with the filtering capabilities of query conditions. This optimization not only reduces unnecessary data transmission and database operations, but more importantly, it significantly shortens query response time, enabling doctors to quickly obtain the accurate case data they need in clinical practice, thereby improving the efficiency and accuracy of diagnosis and surgical planning.

[0081] The thyroid surgery case retrieval method of this application demonstrates significant performance advantages and innovation compared with existing technologies when processing composite queries that include both macroscopic imaging features and microscopic pathological features.

[0082] The core innovation of this application lies in the introduction of mechanisms for "evaluating the filtering capability of query conditions" and "dynamically optimizing the query execution order." Upon receiving a composite query request, this application does not blindly execute the query according to a preset order. Instead, it first sends lightweight exploration requests to the first and second data storage areas to quickly obtain the number of case identifiers that can be filtered out by each. By comparing these numbers, it can intelligently determine which query condition has a stronger filtering capability, that is, which condition can more quickly narrow down the initial large case database to a smaller range.

[0083] This pre-evaluation mechanism allows this application to dynamically adjust the query execution order, prioritizing queries with strong filtering capabilities. For example, if a microscopic pathological feature query can reduce the number of cases from millions to dozens, while a macroscopic imaging feature query can only reduce it to thousands, then this application will prioritize the microscopic pathological feature query. Thus, after the first stage of querying, a significantly reduced list of case identifiers is obtained. Subsequently, this significantly reduced list is used as input to execute the second query condition.

[0084] Through this intelligent optimization of query order, this application achieves the following significant advantages:

[0085] First, it significantly reduces the amount of intermediate data transmission. By prioritizing queries with strong filtering capabilities, the amount of data that subsequent queries need to process is significantly reduced, thereby lowering network communication overhead.

[0086] Secondly, it significantly reduced the I / O pressure on the database. By shrinking the intermediate result set, the number of queries and the amount of data in the second database were also reduced, effectively alleviating the disk I / O bottleneck.

[0087] Finally, it significantly improves query response speed. This overall improvement in query efficiency allows doctors to obtain accurate case data within a clinically acceptable timeframe, meeting the needs of real-time decision-making.

[0088] In summary, this application effectively solves the performance challenges faced by existing technologies in handling composite queries of multi-source heterogeneous data by introducing query condition filtering capability assessment and dynamic query execution order optimization. It provides a more efficient and intelligent solution for the rapid and accurate retrieval of thyroid surgery cases, and has significant technological advancements and practical value.

[0089] In some embodiments, the steps of sending a first query request to a first data storage area and obtaining the number of case identifiers that meet the macroscopic imaging feature query conditions based on the first query request, and sending a second query request to a second data storage area and obtaining the number of case identifiers that meet the microscopic pathological feature query conditions based on the second query request, include:

[0090] When sending a first query request to the first data storage area and a second query request to the second data storage area, a response time threshold is set for each query request;

[0091] Waiting for probe results from the first data storage area and the second data storage area;

[0092] When the response time of any query request exceeds its response time threshold, the query request is resent to the unresponsive data storage area, and at the same time, a query request is sent to the backup path of that data storage area.

[0093] The system receives exploration results from the first data storage area and the second data storage area, compares the timestamps of the received exploration results, and obtains the number of the latest and valid case identifiers.

[0094] Specifically, the response time threshold refers to a maximum acceptable waiting time preset for each query request sent to the first and second data storage areas. This threshold can be dynamically or statically configured based on the expected performance of the data storage areas, network conditions, and the requirements for data real-time performance. It is used to avoid being blocked due to indefinitely waiting for a response from a data source, thereby ensuring the timeliness of the query process.

[0095] After sending a query request, the system enters a listening state, awaiting probe results from the first and second data storage regions. This stage is crucial for obtaining preliminary statistical information. If the response time of any query request exceeds its response time threshold, the query request is resent to the unresponsive data storage region, and simultaneously, a query request is sent to the backup path of that data storage region. Resending the query request aims to attempt to establish or restore a connection with the original data storage region to obtain its response. Sending the query request to the backup path of that data storage region provides a redundant or alternative data acquisition path when the primary path is unavailable or slow to respond. The backup path can be a read-only copy of the data storage region, a caching service, or other auxiliary storage with the same or similar data content, used to improve the success rate of data acquisition and fault tolerance. Probe results from the first and second data storage regions are received, and the received probe results are timestamped to obtain the number of the latest and valid case identifiers. Specifically, when probe results are received from the primary path and / or the backup path, each result is accompanied by a timestamp indicating the time it was generated or acquired. By comparing these timestamps, the freshest data can be identified and selected, ensuring that subsequent screening assessments are based on the most up-to-date and accurate number of case identifiers. This effectively avoids decision-making biases caused by outdated data.

[0096] The technical solution of this application effectively solves the response delay and data unreliability problems that may be encountered when obtaining the number of case identifiers in the basic solution mentioned above by introducing a response time threshold, a resend mechanism, and a backup path query. Specifically, setting a response time threshold enables timely detection and handling of data sources with abnormal responses, avoiding unnecessary long waiting times. When a timeout is detected, a request is simultaneously resent to the original data storage area and to its backup path, forming a dual guarantee mechanism. Resending the request gives the original data source another chance to respond, while the introduction of the backup path provides a redundant channel for data acquisition, greatly improving the success rate of data acquisition. In addition, timestamp comparison of the received exploration results ensures that, under the multi-path or retry mechanism, the freshest and most effective number of case identifiers can always be selected and used, thereby guaranteeing the accuracy of subsequent query condition filtering capabilities and optimizing the execution efficiency and result quality of the entire composite query.

[0097] Through the above technical solution, this application significantly improves the robustness and reliability of the thyroid surgery case retrieval method in the initial data statistics stage. This technical solution effectively addresses response delays or temporary failures in the data storage area, ensuring a stable acquisition of case identifiers through intelligent retry and alternative path query mechanisms. Simultaneously, timestamp comparison guarantees the real-time nature and validity of the acquired data, avoiding retrieval bias caused by outdated data. Therefore, the efficiency and accuracy of the entire retrieval process are significantly improved, providing users with a more stable, reliable, and efficient case retrieval service, especially when facing complex or high-concurrency query scenarios, where its advantages are even more pronounced.

[0098] In one specific implementation, assume a user submits a composite query request containing both macroscopic image feature query conditions and microscopic pathological feature query conditions. First, a first query request is sent to a first data storage area storing macroscopic image features (e.g., a relational database), and a second query request is sent to a second data storage area storing microscopic pathological features (e.g., a vector database) to obtain the number of case identifiers that meet the respective conditions. To ensure timely acquisition of these numbers, a 500-millisecond response time threshold is set for each query request. If the first data storage area fails to return its exploration results within 500 milliseconds, the first query request is immediately resent to that first data storage area, and simultaneously a third query request is sent to its preset backup path (e.g., a read-only copy database or a caching service). When exploration results are received from the first data storage area (which may be a response to the original request or a response to the resent request) and its backup path, each result is accompanied by a timestamp. These timestamps are compared. For example, if the original request returned result A (timestamp T1) at 600 milliseconds, and the backup path returned result B (timestamp T2) at 550 milliseconds, with T2 being later than T1, then result B is selected as the latest and most valid number of case identifiers. In this way, even if a data storage area experiences a brief response delay or failure, the backup mechanism can quickly obtain the latest and most accurate statistical data, ensuring that subsequent screening capability assessments and query executions are based on reliable information.

[0099] In some embodiments, the first data storage area is a relational database storing macroscopic imaging features, and the second data storage area is a vector database storing microscopic pathological features; the first query request is a query instruction sent to the relational database storing macroscopic imaging features to obtain the number of cases that meet the query conditions for macroscopic imaging features, and the second query request is an estimation instruction sent to the vector database storing microscopic pathological features to obtain the number of cases that meet the microscopic pathological features.

[0100] The first data storage area is specifically configured as a relational database, primarily used to store macroscopic image features. Macroscopic image features typically include structured or semi-structured data, such as descriptive text in image reports, image examination types, lesion size, and location. This data can be effectively organized into a table structure within the relational database and can be precisely queried using query languages ​​such as SQL.

[0101] Furthermore, the second data storage area is specifically configured as a vector database, primarily used to store microscopic pathological features. Microscopic pathological features, such as deep learning feature vectors of pathological slide images and gene expression data, are typically represented as high-dimensional vectors. Vector databases excel at processing this type of high-dimensional vector data and can quickly retrieve similar pathological features through vector similarity search (e.g., nearest neighbor search or approximate nearest neighbor search).

[0102] Therefore, the first query request is defined as a query instruction sent to a relational database storing macroscopic imaging features. This query instruction aims to accurately retrieve the number of cases that meet specific macroscopic imaging feature query conditions; for example, querying all cases of "thyroid nodules with a diameter greater than 2 cm".

[0103] Meanwhile, the second query request is defined as an estimation instruction sent to a vector database storing microscopic pathological features. Since similarity searches in vector databases typically involve complex calculations, and accurate counting can be time-consuming when processing massive amounts of data, using an estimation instruction can quickly obtain an approximate number of cases that meet the microscopic pathological feature query conditions, thus ensuring query efficiency while providing a basis for subsequent screening capability assessment.

[0104] The technical solution of this application achieves efficient management and retrieval of different data types by storing macroscopic imaging features in a relational database for precise querying and storing microscopic pathological features in a vector database for estimation querying. The structured nature of the relational database enables precise and reliable condition matching and statistical analysis of macroscopic imaging features, ensuring the accuracy of the query results. Meanwhile, the vector database efficiently processes high-dimensional microscopic pathological feature data, quickly providing the quantity information of similar cases through estimation commands, which is particularly important for the pre-screening stage requiring rapid response. This divide-and-conquer strategy fully leverages the advantages of different databases, optimizing overall query performance and resource utilization efficiency.

[0105] Through the above technical solutions, this application can select the most suitable data storage and query methods according to the characteristics of different types of medical data, thereby significantly improving the efficiency and accuracy of thyroid surgery case retrieval. Specifically, the use of a relational database ensures the accuracy and reliability of macroscopic image feature queries, while the combination of a vector database and estimation commands guarantees the rapid response capability of microscopic pathological feature queries. Especially when processing large-scale, high-dimensional pathological data, it can effectively avoid performance bottlenecks caused by precise calculations, providing a timely and effective basis for subsequent query execution order optimization, thereby improving user experience and usability.

[0106] In some embodiments, the step of resending the query request to the unresponsive data storage area and simultaneously sending the query request to the backup path of the data storage area when the response time of any query request exceeds its response time threshold; receiving the exploration results from the first data storage area and the second data storage area, and comparing the timestamps of the received exploration results to obtain the number of the latest and valid case identifiers includes:

[0107] Resend the corresponding query request to the unresponsive data storage area, and simultaneously send a third query request to the backup path of that data storage area;

[0108] Receive the exploration results, append a timestamp to the exploration results, and record the source path of the exploration results;

[0109] Compare the timestamps of the exploration results and select the exploration result with the latest timestamp;

[0110] The evaluation results are obtained by assessing the real-time or consistency level of the data source path of the latest timestamp investigation results, and based on the evaluation results, the number of latest and valid case identifiers is determined.

[0111] Specifically, when a query request, such as one targeting the primary data storage area, fails to return results within a preset response time threshold, the same query request is immediately resent to that primary data storage area to attempt to obtain a response again. Simultaneously, to improve the success rate and efficiency of data retrieval, a third query request is sent to a backup path of that primary data storage area. This third query request has the same purpose as the original query request: to obtain the number of case identifiers that meet the same query conditions from the backup data source. The backup path typically refers to an auxiliary storage system that has the same or similar data copies as the primary data storage area, providing redundancy and failover capabilities.

[0112] Upon receiving probe results from both the primary path (resent query requests) and the backup path (third query requests), each received probe result is appended with a timestamp. This timestamp records the precise time the probe result was received, used to subsequently determine the data's "freshness." Simultaneously, the source path of each probe result is also recorded, indicating whether the result was retrieved from the primary data storage area or its backup path. This source path information is crucial for subsequent evaluation of data reliability and quality.

[0113] Subsequently, the timestamps of all received probe results are compared. Typically, the probe result with the most recent timestamp is initially selected because it represents the "freshest" data at the current point in time. However, relying solely on timestamps may not be sufficient to guarantee the validity of the data.

[0114] Therefore, this application further evaluates the data real-time performance or consistency level of the source path of the most up-to-date timestamped exploration results. Data real-time performance refers to the timeliness with which data reflects changes in the real world, while data consistency refers to the degree to which data remains synchronized and conflict-free among different replicas in a distributed system. This evaluation aims to comprehensively consider the inherent characteristics and current operating status of the data source. For example, some alternative paths may be slightly inferior to the primary path in terms of data real-time performance, but perform better in terms of data consistency. By evaluating the data real-time performance or consistency level of the source path, the quality of the selected exploration results can be more comprehensively judged. Ultimately, based on this evaluation result, the number of truly up-to-date and valid case identifiers can be determined, ensuring that subsequent screening and retrieval processes are based on high-quality data.

[0115] This application's technical solution effectively addresses the problem that timestamps alone are insufficient to comprehensively determine data validity in distributed or heterogeneous data storage environments by introducing an assessment of the real-time performance or consistency level of the data source path for the exploration results. When the primary data storage area experiences response delays or failures, redundancy in data acquisition is ensured by simultaneously resending requests to the primary path and sending a third query request to the backup path. Subsequently, all received exploration results are timestamped and their source paths are recorded, providing a foundation for subsequent data selection. Crucially, after initially selecting the results with the latest timestamps, the real-time performance or consistency level of their source paths is further evaluated. This evaluation mechanism allows for a broader consideration beyond simple time "freshness," taking into account the inherent quality attributes of the data source. For example, even if a result's timestamp is slightly older, if its source path demonstrates excellent data consistency and the query has higher consistency requirements, that result may be considered more "valid." Therefore, this technical solution ensures that in complex data environments, the number of case identifiers that best meet business needs and data quality requirements is always selected and used.

[0116] Through the above technical solution, this application can significantly improve the accuracy and reliability of obtaining the number of case identifiers during the retrieval of thyroid surgery cases. Especially in scenarios where the data storage area is unstable or the data distribution is heterogeneous, this technical solution not only ensures the success rate of data acquisition through multi-path querying and retry mechanisms, but more importantly, it achieves intelligent selection of search results by combining timestamp comparison with the real-time or consistency level assessment of the source path. This avoids the introduction of low-quality or inconsistent data that may be introduced by simply selecting the latest timestamp, thereby ensuring the accuracy of subsequent query filtering and improving the overall robustness and data quality of the retrieval.

[0117] As a specific implementation method, a concrete example is given below. Suppose that in a thyroid surgery case retrieval, a user submits a composite query request containing both macroscopic imaging feature query conditions and microscopic pathological feature query conditions. First, a first query request is sent to the first data storage area (a relational database storing macroscopic imaging features), and a second query request is sent to the second data storage area (a vector database storing microscopic pathological features) to obtain the number of case identifiers that meet their respective conditions.

[0118] For example, if a first query request to the first data storage area fails to return a result within a preset response time threshold, the first query request will be immediately resent to the first data storage area. At the same time, to ensure timely data retrieval, a third query request will also be sent to an alternative path of the first data storage area (e.g., a read-only replica database that is asynchronously synchronized with the master relational database).

[0119] At a subsequent time point, a probe result A, timestamp T1, might be received from the primary data storage area via the primary path; simultaneously, a probe result B, timestamp T2, might be received from the backup path via the backup path. Assume T1 is later than T2, meaning probe result A has the latest timestamp.

[0120] At this point, the data real-time performance or consistency level of the source path (primary path) of probe result A will be further evaluated. For example, if the master relational database is currently under high load, its data synchronization may experience slight delays, resulting in a slightly lower data real-time performance score; while the backup path, although its timestamp is slightly older, may exhibit higher stability in terms of data consistency as a read-only replica. These factors will be comprehensively considered based on a pre-defined evaluation model.

[0121] Specifically, if the current query has extremely high requirements for data real-time performance (e.g., for emergency diagnosis), even if the real-time score of the source path of search result A is slightly lower, it may still be prioritized because its timestamp is the most recent. Conversely, if the query has higher requirements for data consistency (e.g., for scientific research statistics, requiring highly accurate data), even if the timestamp of search result B is slightly older, if its source path consistency level is higher, search result B may be selected after comprehensive evaluation and determined as the most recent and valid number of case identifiers. In this way, this application can intelligently select the most suitable search result based on actual needs and data source characteristics, thereby ensuring the accuracy and effectiveness of the retrieval results.

[0122] In some embodiments, the step of obtaining an evaluation result for the data real-time or consistency level of the source path of the latest exploration result includes:

[0123] Obtain the real-time operating metrics of the underlying data storage service corresponding to the source path;

[0124] Based on the real-time operating metrics, calculate the availability score and data freshness score of the source path;

[0125] Based on the availability score and the data freshness score, the data real-time or consistency level of the source path is determined.

[0126] Real-time operational metrics refer to various parameters related to the operational status of data storage services, collected proactively or passively. These metrics may include, but are not limited to: response latency (the time required for a data request to be sent and a response received), throughput (the amount of data processed or the number of requests processed per unit time), error rate (the proportion of failed requests), number of connections, CPU utilization, memory utilization, disk I / O, network bandwidth usage, data synchronization latency (for replicated or distributed systems, the data synchronization lag time between master and slave nodes), and data version number. These metrics comprehensively reflect the current performance, stability, and data update status of the data storage service.

[0127] Based on the real-time operational metrics, the availability score and data freshness score of the source path are calculated. The availability score measures the degree to which the data storage service is accessible and operable within a specific time period, and is typically related to the stability and reliability of the service. For example, a lower error rate and stable response latency usually result in a higher availability score. The data freshness score assesses the update frequency and timeliness of data within the storage service; for example, lower data synchronization latency and higher update frequency usually result in a higher data freshness score. These scores can be derived through a weighted calculation or comprehensive evaluation using a preset algorithm or model, combined with various real-time operational metrics. For example, different metric thresholds can be set, and when a metric exceeds a threshold, the score is deducted accordingly.

[0128] Based on the availability score and the data freshness score, the real-time or consistency level of the source path is determined. This step maps the quantified availability score and data freshness score to preset data quality levels. For example, multiple levels such as "high real-time and high consistency," "medium real-time and medium consistency," and "low real-time and low consistency" can be defined. By comparing the calculated availability score and data freshness score with the thresholds corresponding to these levels, the real-time or consistency level of the data provided by the current source path can be determined. For example, when both the availability score and the data freshness score are higher than a certain high threshold, it can be determined as the "high real-time and high consistency" level.

[0129] The technical solution of this application introduces real-time operational metrics of the underlying data storage service and calculates availability and data freshness scores based on these metrics, thereby providing a more objective and quantitative assessment of the real-time performance or consistency level of the data source path of the investigation results. This method avoids errors that may arise from relying solely on experience or simple timestamp comparisons, enabling a more accurate understanding of the actual quality of the data. By comprehensively considering service availability and data timeliness, the optimal data source can be selected more intelligently, ensuring that the number of acquired case identifiers is not only the most up-to-date in timestamps but also truly valid data that meets the query requirements.

[0130] The above technical solutions significantly improve the accuracy and reliability of data validity assessment during thyroid surgery case retrieval. By deeply analyzing the real-time operational metrics of the underlying data storage service and converting them into quantifiable availability and data freshness scores, the data quality of different sources can be more accurately evaluated. This enables more informed decision-making when faced with response timeouts or unstable data sources, prioritizing those sources that not only respond promptly but also possess high data quality and meet real-time or consistency requirements. This ensures that the final retrieved case data is the most up-to-date, accurate, and reliable, greatly enhancing the practical value and clinical application effectiveness of the retrieval results.

[0131] In some optional embodiments, it is assumed that during the thyroid surgery case retrieval process, query requests are sent to a first data storage area (relational database) and a second data storage area (vector database). When the response from the first data storage area times out, the query request is resent to it, and simultaneously a third query request is sent to its backup path. Probe results from the primary and backup paths are received, and it is found that the timestamp of the probe results from the backup path is the most recent. To assess the data real-time performance or consistency level of the backup path, real-time operational metrics of the underlying data storage service corresponding to the backup path are first obtained. For example, the average query latency of the backup database might be 50ms, the error rate 0.1%, the data synchronization latency 10 seconds, and the data update frequency of 500 records per minute for the most recent hour. Based on these real-time operational metrics, an availability score and a data freshness score for the backup path are calculated. For example, according to a preset scoring model, a 50ms latency and a 0.1% error rate might correspond to an availability score of 95, while a 10-second synchronization latency and an update frequency of 500 records per minute might correspond to a data freshness score of 80. Finally, these scores are compared with preset level thresholds. For example, if the preset "high real-time performance" level requires an availability score higher than 90 and a data freshness score higher than 75, then this backup path will be designated as "high real-time performance and high consistency." Based on this evaluation result, it can be assured that the number of case identifiers provided by this backup path is up-to-date and valid, and can be used for subsequent case data acquisition.

[0132] In some embodiments, the step of determining the data real-time or consistency level of the source path based on the availability score and the data freshness score includes:

[0133] Analyze the type information of each query request, where the type information indicates the real-time or consistency requirements of the corresponding query request;

[0134] Based on the type of query request, the weights of the availability score and the data freshness score are adjusted to obtain the target weight;

[0135] Based on the target weight, the availability score and the data freshness score are weighted and combined to obtain the comprehensive data quality score of the source path;

[0136] The comprehensive data quality score is compared with a preset level threshold to determine the data real-time or consistency level of the source path.

[0137] Specifically, the type information of each query request refers to the metadata or contextual information contained in the query request submitted by the current user. This type information may include, but is not limited to, the purpose of the query (e.g., clinical diagnosis, scientific research analysis, teaching demonstration), the urgency of the disease, the focus on specific features (e.g., focusing only on macroscopic imaging features or simultaneously focusing on microscopic pathological features), and the user's explicit preference for data timeliness or accuracy. This information is used to clarify the specific requirements of the query regarding data real-time performance (i.e., the freshness of the data) and data consistency (i.e., the uniformity and accuracy of data across different copies or points in time).

[0138] Specifically, the weights of usability and data freshness scores are adjusted based on the query request type information to obtain target weights. This means that different importance coefficients are dynamically assigned to the usability and data freshness scores based on the query type information obtained from the above analysis. For example, for queries requiring high real-time performance, the weight of the data freshness score may be increased, while for queries requiring high consistency, the weight of the usability score may be increased. These weight adjustments aim to make the final data quality assessment more closely reflect the actual needs of the current query.

[0139] In practical applications, based on the target weights, the usability score and data freshness score are weighted and combined to obtain the comprehensive data quality score of the source path. This means applying the adjusted weights to their respective scores and calculating a single, comprehensive data quality indicator through weighted averaging or other weighting algorithms. This comprehensive data quality score can fully reflect the overall performance of the data source path in meeting specific query needs.

[0140] Furthermore, comparing the comprehensive data quality score with preset level thresholds to determine the real-time or consistency level of the source path refers to pre-setting a series of score intervals, each interval corresponding to a specific data quality level (e.g., high, medium, and low real-time / consistency levels). By comparing the calculated comprehensive data quality score with these thresholds, the specific level of real-time or consistency of the data provided by the current data source path can be quantitatively determined, thereby providing a basis for subsequent data selection and processing.

[0141] The technical solution of this application introduces query request type information and dynamically adjusts the weights of availability and data freshness scores accordingly. This makes data quality assessment no longer static, but adaptively adjustable based on specific business scenarios and query needs. This mechanism ensures that when obtaining the latest and most valid case identifiers, the selected "validity" is not only technically valid but also valid in terms of business requirements. By using a weighted combination to obtain a comprehensive data quality score, the actual value of the data source path can be measured more comprehensively and accurately, avoiding decision-making errors caused by biased single indicators. Therefore, it is possible to more intelligently select the data source that best meets the current query needs, thereby optimizing overall retrieval efficiency and result quality.

[0142] In some alternative embodiments, it is assumed that there are two typical query requests: one is an "urgent diagnosis query," which requires the rapid acquisition of the latest case data to assist clinical decision-making; the other is a "scientific research statistics query," which requires the acquisition of a large amount of historical case data for trend analysis and has high requirements for data consistency.

[0143] When an "urgent diagnostic query" is received, its type information is identified as having a high requirement for data real-time performance. At this point, based on preset rules or dynamic calculation, the weight of the data freshness score (e.g., 0.8) is set higher than the weight of the availability score (e.g., 0.2). Assuming a data source path has an availability score of 0.9 and a data freshness score of 0.7, its overall data quality score is (0.9 * 0.2) + (0.7 * 0.8) = 0.18 + 0.56 = 0.74.

[0144] When a "scientific research statistics query" is received, its type information is identified as having a high requirement for data consistency. At this point, the weights are adjusted, setting the weight of the usability score (e.g., 0.7) higher than the weight of the data freshness score (e.g., 0.3). For the same data source path, its overall data quality score is (0.9 * 0.7) + (0.7 * 0.3) = 0.63 + 0.21 = 0.84.

[0145] By comparing these two comprehensive data quality scores with preset level thresholds, a data quality level that prioritizes real-time performance can be determined for "urgent diagnostic queries," while a data quality level that prioritizes consistency can be determined for "scientific research and statistics queries." For example, for urgent diagnostic queries, even if the data freshness is slightly lower, it may still be given priority as long as it meets the minimum real-time requirements; while for scientific research and statistics queries, data sources with high consistency and completeness will be prioritized. This dynamic adjustment mechanism enables the intelligent selection of the optimal data source based on the actual needs of the query, thereby significantly improving the relevance and effectiveness of the search results.

[0146] In some embodiments, the step of adjusting the weights of the availability score and the data freshness score based on the type information of the query request to obtain the target weight includes:

[0147] Obtain the type information of the query request, which includes the diagnostic stage information, disease staging information, and the feature dimensions of interest for thyroid surgery cases;

[0148] Based on the diagnostic stage information, the disease staging information, and the feature dimensions, a corresponding weight combination is selected from a preset weight configuration set;

[0149] When the type information of the query request does not completely match the preset weight combination, the weights of the availability score and the data freshness score are dynamically calculated based on the priority of each dimension in the type information of the query request to obtain the target weight.

[0150] Specifically, query request type information refers to the set of key attributes used to describe a user's query intent and data requirements. This type information can be refined into multiple dimensions. For example, diagnostic stage information for thyroid surgery cases can indicate whether the query is for different stages such as initial diagnosis, preoperative assessment, postoperative follow-up, or recurrence monitoring; disease staging information can reflect the TNM staging of thyroid cancer (tumor size, lymph node metastasis, distant metastasis) or other staging standards, which is usually closely related to the timeliness and completeness requirements of the data; and the feature dimensions of interest, such as focusing on imaging features (e.g., nodule size, borders, calcification), pathological features (e.g., cellular atypia, mitotic figures), gene mutation information, or clinical symptoms. These dimensions together constitute a comprehensive description of the query request, enabling a more accurate understanding of the user's data quality requirements.

[0151] The preset weight configuration set consists of a series of predefined weight combinations of availability and data freshness scores for different types of query requests, based on common query scenarios and empirical rules. When a query request is received, the system first attempts to match the query request type information with these preset combinations. For example, a higher weight might be preset for real-time performance in queries during the emergency diagnosis phase, while a greater emphasis might be placed on data consistency and integrity for long-term follow-up queries.

[0152] In practical applications, when the type information of a query request does not perfectly match the preset weight combination, it means that the current query requirement may be unique or complex, and existing rules cannot be simply applied. In this case, this application proposes dynamically calculating the weights of the usability score and the data freshness score based on the priority of each dimension in the query request's type information. This means that instead of simply selecting a preset value, the weights of the usability score and the data freshness score are adjusted in real time according to the importance of each dimension in the query request (such as diagnostic stage, disease staging, and feature dimensions) or the sensitivity to data quality. For example, if the diagnostic stage information in the query request indicates an urgent diagnosis of a critical case, then even without a perfectly matching preset combination, the weight of the data freshness score will be prioritized to ensure the acquisition of the latest data. This dynamic calculation mechanism enables flexible adaptation to various complex query scenarios and avoids data quality assessment bias caused by a lack of precise matching.

[0153] The technical solution of this application effectively solves the problem of rigid weight adjustment in traditional methods when handling complex or non-standard queries by introducing detailed analysis of query request type information and combining a hybrid strategy of preset weight selection and dynamic weight calculation. Specifically, firstly, by obtaining detailed type information including diagnostic stage information, disease staging information, and the feature dimensions of interest, a deeper understanding of the query intent can be achieved. Secondly, it prioritizes selecting matching weight combinations from the preset weight configuration set, which ensures efficient processing of common query scenarios. More importantly, when the query request type information does not completely match the preset weight combination, it no longer simply uses the default or approximate weights, but dynamically calculates the weights of availability score and data freshness score according to the priority of each dimension in the query request. This dynamic adjustment mechanism allows for flexible allocation of weights according to the actual needs of the query, such as the emphasis on real-time performance or consistency, thereby ensuring that even when facing unique or complex query scenarios, a comprehensive data quality score that best reflects data quality requirements can be generated.

[0154] In some alternative embodiments, suppose a physician needs to query for "a patient with papillary thyroid carcinoma, five years post-surgery follow-up, with cervical lymph node metastasis, and needs to review their latest ultrasound images and pathology report for microcalcifications." The query request type information can be parsed as follows: diagnostic stage "post-surgery follow-up," disease stage "with lymph node metastasis," and the features of interest being "microcalcifications in ultrasound images" and "pathology report."

[0155] First, an attempt was made to find a perfectly matching combination in the preset weight configuration set. However, perhaps because the combination of "five-year follow-up postoperatively", "with lymph node metastasis" and "microcalcifications" is not common in the preset set, no perfectly matching weight combination was found.

[0156] At this point, a dynamic calculation mechanism will be activated. It analyzes the priority of each dimension in the query request. For example, for the dimension of "five-year follow-up post-surgery," the requirement for data freshness may be relatively low, while the requirements for data consistency and completeness are higher; however, "with cervical lymph node metastasis" and "microcalcifications" may mean that attention needs to be paid to the latest progress or subtle changes, thus requiring higher data freshness. The feature dimension of "microcalcifications" may be identified as having a high requirement for data real-time performance, as it may indicate disease recurrence or progression. At the same time, the accuracy and consistency of the "pathology report" are also crucial.

[0157] Based on the priority of these dimensions, the weights of the usability score and the data freshness score are dynamically adjusted. For example, the weight of the data freshness score might be appropriately increased to ensure access to the latest ultrasound images and pathology reports, while maintaining the weight of the usability score to ensure data integrity and accessibility. Through this dynamic adjustment, even without a pre-defined exact match, an optimal weight combination can be generated for a specific query, thereby more accurately assessing the quality of the data source and ultimately obtaining the case data that best meets the doctor's needs.

[0158] In some embodiments, the step of dynamically calculating the weights of the usability score and the data freshness score based on the priority of each dimension in the query request type information to obtain the target weight when the type information of the query request does not completely match the preset weight combination includes:

[0159] Identify the diagnostic stage information, the disease staging information, and the feature dimensions, and increase the weight of the data freshness score based on the dimensions with higher requirements for data real-time performance.

[0160] Identify the dimensions with higher data consistency requirements among the diagnostic stage information, disease staging information, and feature dimensions, and increase the weight of the usability score based on the dimensions with higher data consistency requirements.

[0161] When there is a priority conflict among the diagnostic stage information, the disease staging information, and the feature dimensions, the final weight adjustment direction is determined according to the preset clinical priority rules to obtain the target weight.

[0162] Specifically, the system analyzes information contained in the query request, such as the diagnostic stage (e.g., emergency diagnosis, preoperative assessment), disease stage (e.g., early stage, late stage), and key features (e.g., real-time imaging, dynamic physiological indicators). If this information indicates a high demand for data timeliness, such as in emergency situations, the weight of the data freshness score will be increased accordingly to ensure that the retrieved case data is up-to-date.

[0163] Specifically, identifying the diagnostic stage information, the disease staging information, and the dimensions with high data consistency requirements among the feature dimensions, and increasing the weight of the usability score based on these dimensions, can be understood as follows: when the query request type indicates strict requirements for data accuracy, completeness, and cross-source consistency (e.g., for pathological diagnosis, long-term follow-up, or research analysis), data reliability will be prioritized. In this case, the usability score will be weighted more to ensure that the acquired case data is not only usable but also highly consistent across different data sources.

[0164] Through the above technical solution, this application overcomes the limitation of dynamically calculating weights when facing complex query requests with multi-dimensional and multi-priority conflicts, making it difficult to accurately balance the requirements of data real-time performance and consistency. This application, by refining the weight adjustment mechanism, intelligently favors data freshness or consistency based on the specific requirements of information such as diagnostic stage, disease staging, and feature dimensions in the query request. This ensures that the retrieved case data meets both timeliness and accuracy and reliability requirements in different clinical scenarios. Especially in cases of priority conflicts, the introduction of pre-defined clinical priority rules provides a scientific and objective decision-making basis, significantly improving the accuracy and rationality of weight adjustment, thereby enhancing the overall efficiency of thyroid surgery case retrieval and the clinical practical value of the results.

[0165] In some embodiments, the step of dynamically calculating the weights of the usability score and the data freshness score based on the priority of each dimension in the query request type information to obtain the target weight when the type information of the query request does not completely match the preset weight combination includes:

[0166] Identify the diagnostic stage information, the disease staging information, and the feature dimensions, and increase the weight of the data freshness score based on the dimensions with higher requirements for data real-time performance.

[0167] Identify the dimensions with higher data consistency requirements among the diagnostic stage information, disease staging information, and feature dimensions, and increase the weight of the usability score based on the dimensions with higher data consistency requirements.

[0168] Obtain clinical urgency information for current thyroid surgery cases, whereby the clinical urgency information indicates the severity of the case;

[0169] Obtain current system resource load information, which indicates the operating status of the data storage area;

[0170] Based on the clinical urgency information and the system resource load information, the weight bias between real-time performance and consistency in the preset clinical priority rules is dynamically adjusted to determine the final weight adjustment direction and obtain the target weight.

[0171] Specifically, analyzing the clinical dimensions contained in the query request helps determine which dimensions have higher requirements for data timeliness or freshness. For example, in the diagnostic phase of "rapid intraoperative pathological diagnosis," the real-time requirements for imaging and pathological features are extremely high, as this directly affects surgical decisions. Based on the identified dimensions with high real-time requirements, the weight of the data freshness score will be increased accordingly to ensure priority access to the latest data. Similarly, identifying dimensions with high data consistency requirements means determining which dimensions have higher requirements for data accuracy, completeness, and reliability. For example, in disease staging for "postoperative follow-up" or "prognostic assessment," the completeness and consistency of historical data are highly required to ensure the accuracy of long-term trend analysis. Based on the identified dimensions with high consistency requirements, the weight of the availability score will be increased accordingly to ensure priority access to stable and consistent data.

[0172] Obtaining the clinical urgency information of current thyroid surgery cases can be understood as acquiring the clinical urgency or priority of cases related to the current query. This information can come from urgency markers in the electronic medical record system, urgency labels manually entered by doctors, or obtained through natural language processing (NLP) analysis of case descriptions.

[0173] Through the aforementioned technical solution, this application significantly improves the adaptability and robustness of the thyroid surgery case retrieval method in complex and dynamic environments. Specifically, by integrating clinical urgency information, it can more intelligently respond to query requests for high-priority or critical cases, ensuring that the most timely and relevant data is provided first at critical moments, thereby supporting doctors in making rapid and accurate diagnostic and treatment decisions. Simultaneously, this method avoids performance bottlenecks or data inconsistencies caused by blindly pursuing real-time performance under excessive pressure, effectively guaranteeing the stability and reliability of data retrieval. This dynamic, context-aware weight adjustment mechanism further optimizes the quality and efficiency of search results, thus providing more valuable data support for clinical practice.

[0174] On the other hand, such as Figure 2 As shown, an exemplary thyroid surgery case retrieval system is illustrated. This application further proposes a thyroid surgery case retrieval system 100, which includes:

[0175] The receiving module 10 is used to receive a composite query request containing macroscopic image feature query conditions and microscopic pathological feature query conditions.

[0176] The statistical information acquisition module 20 is used to send a first query request to the first data storage area and obtain the number of case identifiers that meet the macroscopic imaging feature query conditions based on the first query request, and to send a second query request to the second data storage area and obtain the number of case identifiers that meet the microscopic pathological feature query conditions based on the second query request.

[0177] The filtering capability determination module 30 is used to compare the number of case identifiers returned by the first data storage area and the second data storage area to determine the filtering capability of the query conditions. The query conditions with a smaller number of case identifiers are determined to be query conditions with strong filtering capabilities.

[0178] The query execution order determination module 40 is used to determine the query execution order of each query condition in the composite query request based on the filtering capability, wherein the query condition with stronger filtering capability is executed first.

[0179] The data integration and return module 50 is used to sequentially perform queries in the corresponding first data storage area according to the query execution order to obtain case identifiers; and obtain corresponding case data based on the case identifiers.

[0180] This application's thyroid surgery case retrieval system aims to address the performance bottlenecks caused by the separation of data storage and inefficient query patterns in traditional case retrieval methods when handling complex queries containing both macroscopic imaging features and microscopic pathological features. The system achieves intelligent processing and optimized execution of complex query requests through a modular design. Specifically, the receiving module uniformly receives complex query requests from users; the statistical information acquisition module explores the preliminary screening capabilities of different data storage areas in parallel; the screening capability determination module intelligently evaluates the screening efficiency of each query condition based on the exploration results; the query execution order determination module dynamically plans the optimal query execution path based on the evaluation results, prioritizing conditions with strong screening capabilities; finally, the data integration and return module executes the queries and integrates the results in the optimized order. Through this collaborative work, the system can significantly reduce unnecessary data transmission and processing overhead, thereby greatly improving the efficiency and response speed of thyroid surgery case retrieval, providing doctors with more timely and accurate decision support.

[0181] Therefore, the thyroid surgery case retrieval system of this application, through its ingenious modular design and intelligent query optimization strategy, achieves rapid and accurate retrieval of complex queries for thyroid surgery cases. This not only significantly improves the overall performance and response speed of the system, but also provides clinicians with a more efficient and reliable decision support tool, possessing significant technical value and application prospects.

[0182] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for retrieving thyroid surgery cases, characterized in that, include: Receive composite query requests that include macroscopic imaging feature query conditions and microscopic pathological feature query conditions; Send a first query request to the first data storage area and obtain the number of case identifiers that meet the macroscopic imaging feature query conditions based on the first query request; send a second query request to the second data storage area and obtain the number of case identifiers that meet the microscopic pathological feature query conditions based on the second query request. The number of case identifiers returned by the first data storage area and the second data storage area is compared to determine the filtering ability of the query conditions. Query conditions with a smaller number of case identifiers are judged to be query conditions with strong filtering ability. Based on the filtering capabilities, the query execution order of each query condition in the composite query request is determined, wherein query conditions with stronger filtering capabilities are executed first. According to the query execution order, queries are executed sequentially in the corresponding data storage areas to obtain case identifiers; based on the case identifiers, the corresponding case data is obtained.

2. The method for retrieving thyroid surgical cases according to claim 1, characterized in that, The steps of sending a first query request to a first data storage area and obtaining the number of case identifiers that meet the macroscopic imaging feature query conditions based on the first query request, and sending a second query request to a second data storage area and obtaining the number of case identifiers that meet the microscopic pathological feature query conditions based on the second query request, include: When sending a first query request to the first data storage area and a second query request to the second data storage area, a response time threshold is set for each query request; Waiting for probe results from the first data storage area and the second data storage area; When the response time of any query request exceeds its response time threshold, the query request is resent to the unresponsive data storage area, and at the same time, a query request is sent to the backup path of that data storage area. The system receives exploration results from the first data storage area and the second data storage area, compares the timestamps of the received exploration results, and obtains the number of the latest and valid case identifiers.

3. The method for retrieving thyroid surgical cases according to claim 2, characterized in that, The first data storage area is a relational database storing macroscopic imaging features, and the second data storage area is a vector database storing microscopic pathological features; the first query request is a query instruction sent to the relational database storing macroscopic imaging features to obtain the number of cases that meet the macroscopic imaging feature query conditions, and the second query request is an estimation instruction sent to the vector database storing microscopic pathological features to obtain the number of cases that meet the microscopic pathological features.

4. The method for retrieving thyroid surgical cases according to claim 3, characterized in that, When the response time of any query request exceeds its response time threshold, the query request is resent to the unresponsive data storage area, and at the same time, a query request is sent to the backup path of that data storage area. The steps of receiving exploration results from the first data storage area and the second data storage area, and comparing the timestamps of the received exploration results to obtain the number of the latest and valid case identifiers include: Resend the corresponding query request to the unresponsive data storage area, and simultaneously send a third query request to the backup path of that data storage area; Receive the exploration results, append a timestamp to the exploration results, and record the source path of the exploration results; Compare the timestamps of the exploration results and select the exploration result with the latest timestamp; The evaluation results are obtained by assessing the real-time or consistency level of the data source path of the latest timestamp investigation results, and based on the evaluation results, the number of latest and valid case identifiers is determined.

5. The method for retrieving thyroid surgical cases according to claim 4, characterized in that, The steps for obtaining the evaluation result for the data real-time or consistency level of the source path of the latest exploration result with the evaluation timestamp include: Obtain the real-time operating metrics of the underlying data storage service corresponding to the source path; Based on the real-time operating metrics, calculate the availability score and data freshness score of the source path; Based on the availability score and the data freshness score, the data real-time or consistency level of the source path is determined.

6. The method for retrieving thyroid surgical cases according to claim 5, characterized in that, The step of determining the data real-time or consistency level of the source path based on the availability score and the data freshness score includes: Analyze the type information of each query request, where the type information indicates the real-time or consistency requirements of the corresponding query request; Based on the type of query request, the weights of the availability score and the data freshness score are adjusted to obtain the target weight; Based on the target weight, the availability score and the data freshness score are weighted and combined to obtain the comprehensive data quality score of the source path; The comprehensive data quality score is compared with a preset level threshold to determine the data real-time or consistency level of the source path.

7. The method for retrieving thyroid surgical cases according to claim 6, characterized in that, The step of adjusting the weights of the availability score and the data freshness score based on the query request type information to obtain the target weight includes: Obtain the type information of the query request, which includes the diagnostic stage information, disease staging information, and the feature dimensions of interest for thyroid surgery cases; Based on the diagnostic stage information, the disease staging information, and the feature dimensions, a corresponding weight combination is selected from a preset weight configuration set; When the type information of the query request does not completely match the preset weight combination, the weights of the availability score and the data freshness score are dynamically calculated based on the priority of each dimension in the type information of the query request to obtain the target weight.

8. The method for retrieving thyroid surgical cases according to claim 7, characterized in that, When the type information of the query request does not completely match the preset weight combination, the step of dynamically calculating the weights of the usability score and the data freshness score based on the priority of each dimension in the type information of the query request to obtain the target weight includes: Identify the diagnostic stage information, the disease staging information, and the feature dimensions, and increase the weight of the data freshness score based on the dimensions with higher requirements for data real-time performance. Identify the dimensions with higher data consistency requirements among the diagnostic stage information, disease staging information, and feature dimensions, and increase the weight of the usability score based on the dimensions with higher data consistency requirements. When there is a priority conflict among the diagnostic stage information, the disease staging information, and the feature dimensions, the final weight adjustment direction is determined according to the preset clinical priority rules to obtain the target weight.

9. The method for retrieving thyroid surgical cases according to claim 7, characterized in that, When the type information of the query request does not completely match the preset weight combination, the step of dynamically calculating the weights of the usability score and the data freshness score based on the priority of each dimension in the type information of the query request to obtain the target weight includes: Identify the diagnostic stage information, the disease staging information, and the feature dimensions, and increase the weight of the data freshness score based on the dimensions with higher requirements for data real-time performance. Identify the dimensions with higher data consistency requirements among the diagnostic stage information, disease staging information, and feature dimensions, and increase the weight of the usability score based on the dimensions with higher data consistency requirements. Obtain clinical urgency information for current thyroid surgery cases, whereby the clinical urgency information indicates the severity of the case; Obtain current system resource load information, which indicates the operating status of the data storage area; Based on the clinical urgency information and the system resource load information, the weight bias between real-time performance and consistency in the preset clinical priority rules is dynamically adjusted to determine the final weight adjustment direction and obtain the target weight.

10. A thyroid surgery case retrieval system, characterized in that, The system includes: The receiving module is used to receive composite query requests that include macroscopic image feature query conditions and microscopic pathological feature query conditions. The statistical information acquisition module is used to send a first query request to the first data storage area and obtain the number of case identifiers that meet the macroscopic imaging feature query conditions based on the first query request, and to send a second query request to the second data storage area and obtain the number of case identifiers that meet the microscopic pathological feature query conditions based on the second query request. The filtering capability determination module is used to compare the number of case identifiers returned by the first data storage area and the second data storage area to determine the filtering capability of the query conditions. Query conditions with a smaller number of case identifiers are determined to be query conditions with strong filtering capabilities. The query execution order determination module is used to determine the query execution order of each query condition in the composite query request based on the filtering capability, wherein the query condition with stronger filtering capability is executed first. The data integration and return module is used to sequentially perform queries in the corresponding first data storage area according to the query execution order to obtain case identifiers; and obtain the corresponding case data based on the case identifiers.

Images