A medical AI task processing system based on offline preprocessing

Abstract

The application discloses a medical AI task processing system based on offline preprocessing, which comprises a task acquisition module, a task scheduling module and a task execution module; the task acquisition module acquires task configuration information and a task priority weight score containing a service identifier and dynamic parameters from an external medical business system through an interface gateway, generates a task identifier and stores the task identifier in association to a database, and synchronizes the task identifier and the weight score to a cache middleware, wherein the weight score is dynamically updated according to a medical scene type corresponding to the external medical business system; the task scheduling module sorts all offline tasks in descending order according to the weight in the cache to generate a task queue; the task execution module obtains tasks from the queue in sequence, calls a corresponding AI intelligent agent to perform analysis, stores a result and synchronizes the result to the cache; and efficient scheduling of medical AI tasks and optimal allocation of resources are realized.

Description

Technical Field

[0001] This invention relates to the field of medical task processing technology, and mainly to a medical AI task processing system based on offline preprocessing. Background Technology

[0002] The integration of AI technology into current medical business systems is increasingly prevalent, penetrating various core business areas. However, this integration also faces the dual challenge of real-time requirements and limited computing resources, including issues such as real-time bottlenecks, flawed caching mechanisms, and significant resource waste.

[0003] Real-time bottleneck: Traditional AI systems suffer from poor real-time interactive experience when handling complex inference tasks due to the computational time of large models (e.g., average latency of LLM inference > 15 seconds), which seriously affects diagnostic efficiency and system availability.

[0004] Caching mechanism defects: Conventional caching solutions (such as Redis) only support key-value matching and cannot adapt to the combined query requirements of multi-round sessions (ConversationID) and dynamic parameters (Inputs).

[0005] Significant resource waste: Offline and real-time tasks share computing resources, resulting in GPU utilization fluctuations exceeding 60% (peak 85% vs. valley 25%).

[0006] The combined effect of these three technical components leads to a significant performance bottleneck in traditional cloud-based inference solutions. In typical diagnostic and treatment scenarios, the complete AI inference process takes longer than the clinical operation error tolerance threshold. In real-time interactive scenarios, medical staff often have to wait more than 60 seconds to receive feedback, which seriously affects diagnostic and treatment efficiency and system availability. Summary of the Invention

[0007] To address the technical problems mentioned in the background section, this invention provides a medical AI task processing system based on offline preprocessing, comprising a task acquisition module, a task scheduling module, and a task execution module; wherein...

[0008] The task acquisition module is configured to collect task configuration information and task priority weight scores corresponding to offline tasks from external medical business systems using an interface gateway, based on task configuration information and task priority weight scores pre-stored in the database. It generates a task identifier, associates and stores the task identifier, task configuration information, and task priority weight scores in the database, and simultaneously synchronizes the task identifier and task priority weight scores to the caching middleware. The task priority weight scores are dynamically updated according to the medical scenario type corresponding to the external medical business system. The task configuration information includes a service identifier for identifying the AI ​​agent used and dynamic parameters for inputting the AI ​​agent.

[0009] The task scheduling module is configured to sort all offline tasks in the database in descending order based on the task priority weight scores in the caching middleware and generate a task queue.

[0010] The task execution module is configured to retrieve offline tasks sequentially from the task queue, call the corresponding AI agent to perform analysis based on the task configuration information of the corresponding offline task, store the execution results in the database, and simultaneously synchronize the execution results to the cache middleware.

[0011] By leveraging the collaborative work of the task acquisition module, task scheduling module, and task execution module, combined with caching middleware and AI agents, and through offline pre-analysis and result caching, a large number of computationally intensive AI tasks are separated from the real-time business path, enabling instant delivery of results. This improves the response speed of medical AI tasks from minutes to milliseconds, effectively resolving the core contradiction between high real-time requirements and limited computing resources in medical scenarios. Furthermore, a tiered task scheduling strategy based on cache optimization prioritizes urgent and high-value diagnostic tasks, ensuring that limited computing resources are always invested in the most needed medical scenarios and achieving dynamic matching between computing power consumption and task complexity. This avoids the high deployment costs and resource contention risks associated with real-time medical AI tasks.

[0012] Furthermore, the interface gateway is configured to collect medical diagnostic files from offline tasks from external medical business systems, extract and parse the characteristics of medical diagnostic files according to the medical diagnostic file protocol types pre-stored in the database, and obtain dynamic parameters from the task configuration information; among them, the medical diagnostic file protocol types include DICOM and HL7.

[0013] By configuring the protocol type (DICOM or HL7) through the above technical solutions, the interface gateway can directly process standardized data from external medical business systems such as PACS, HIS, and LIS, enabling the system to seamlessly integrate into the existing medical information ecosystem, automatically parse complex medical data formats (such as DICOM image files or HL7 messages), extract key features as dynamic parameters, greatly reduce the threshold for system deployment and integration, and support seamless expansion of cross-disease diagnosis and multimodal data analysis scenarios.

[0014] Furthermore, the database is configured to be sharded according to the external medical business system, and to store task identifiers, task configuration information and task priority weight scores in time-based table associations, and to create a block-range index BRIN for the task identifier field.

[0015] Through the above technical solutions, a combination of vertical sharding based on external medical business systems and horizontal sharding based on time is used, along with the creation of BRIN indexes for frequently accessed task identifier fields. This enables the system to efficiently support the storage and retrieval of large-scale medical tasks, effectively solving the problems of large data volume, rapid growth, and complex query patterns in medical scenarios.

[0016] Furthermore, the caching middleware is configured to store execution results based on a cache key, which is constructed by combining a service identifier, a hash value of dynamic parameters, and a session identifier. The session identifier is used to identify the current session during the analysis process performed by the corresponding AI agent.

[0017] By employing the above technical solution and using a cache key generated from a combination of service identifier, hash value of dynamic parameters, and session identifier, precise matching across three dimensions is achieved. This ensures the correctness of different query results within the same session while allowing the reuse of identical query results between different sessions. It maximizes cache utilization while guaranteeing the accuracy of medical diagnoses, increasing the reuse rate of similar tasks by 47%.

[0018] Furthermore, the task scheduling module is also configured to generate a computing resource utilization matrix to identify idle resource periods; to calculate the analysis computing cost of corresponding offline tasks; and to schedule corresponding offline tasks during idle periods based on the resource utilization matrix.

[0019] By using the above technical solutions, generating a resource utilization matrix and computing cost statistics, identifying idle resource periods, and scheduling low-priority tasks during these periods, the overall resource utilization rate is increased by 45%, significantly reducing the operating costs of medical AI applications.

[0020] Furthermore, the task execution module is also configured to trigger retries according to the retry strategy of the corresponding offline task after the AI ​​agent fails to perform analysis. The retry strategy includes retrying after waiting for a predetermined time if the reason for the failure of the corresponding offline task is a network error; generating an alarm and determining that the reason for the failure is model abnormality if the number of retries exceeds a preset threshold; and switching to a backup AI agent to perform the analysis of the corresponding offline task if the reason for the failure of the corresponding offline task is model abnormality.

[0021] Through the above technical solutions, the intelligent retry strategy integrated into the task execution module can automatically perform a limited number of retries when there are network anomalies or model failures, and seamlessly switch to a backup AI agent in the event of a severe failure. This mechanism ensures high availability for critical medical tasks (such as emergency diagnosis), avoids diagnostic delays caused by single points of failure, and provides a reliable guarantee for the continuous and stable operation of medical AI applications.

[0022] Furthermore, the execution results include the number of times the AI ​​agent hit the target.

[0023] Furthermore, the task execution module is also configured to dynamically update the pre-stored task priority weight scores in the database based on the number of hits by the AI ​​agent using a reinforcement learning algorithm.

[0024] Through the above technical solutions, the more frequently an AI agent hits a task type, the higher the value and reliability of its future analysis results. Therefore, by increasing the task priority weight score of such tasks, computing resources can be allocated preferentially, ensuring that high-value tasks are processed in a timely manner, while improving the overall system result reuse rate and saving computing power.

[0025] Furthermore, the caching middleware is configured to store task identifiers and task priority weight scores based on a SortSet collection, execution results based on a String collection, and the number of hits by the AI ​​agent based on a Hash collection.

[0026] The above technical solutions employ a combined storage architecture using SortSet, String, and Hash data structures, optimizing the efficiency of task scheduling, result retrieval, and metadata management. This architecture supports weight-based priority scheduling (SortSet), millisecond-level result retrieval (String), and efficient cached metadata management (Hash), improving the cache hit rate by 37% compared to general solutions. This results in a 98.2% cache effectiveness rate for emergency tasks and 82.5% for regular tasks.

[0027] Furthermore, the task execution module is also configured to calculate the SHAP value based on the medical features in the execution result of each successfully executed offline task. The SHAP values ​​of each successfully executed offline task are sorted in ascending order to obtain a ranking, and the median of all SHAP values ​​after ascending order is used as the benchmark value. When the SHAP value of any offline task is greater than the benchmark value, the task priority weight score stored in the task acquisition module is updated to the sum of the current task priority weight score and the ranking preset weight increase score; when the SHAP value of any offline task is less than the benchmark value, the task priority weight score stored in the task acquisition module is updated to the difference between the current task priority weight score and the ranking preset weight decrease score.

[0028] Through the above technical solutions, tasks with more critical, complex, or learning-value-enhancing analysis results (i.e., high SHAP values) are automatically prioritized, thereby ensuring that limited computing resources are invested in areas that can generate the greatest benefits, achieving the optimal match between computing resources and medical value, and improving the overall efficiency and clinical applicability of the system.

[0029] The technical advantages of this invention are as follows: It provides a medical AI task processing system based on offline preprocessing, including a task acquisition module, a task scheduling module, and a task execution module. The task acquisition module collects task configuration information, including service identifiers and dynamic parameters, and priority weights from external medical business systems through an interface gateway, generates task identifiers, and stores them in a database. Simultaneously, it synchronizes the identifiers and weights to a cache middleware. The weight scores are dynamically updated according to the medical scenario type corresponding to the external medical business system. The task scheduling module sorts all offline tasks in descending order according to the weights in the cache to generate a task queue. The task execution module sequentially retrieves tasks from the queue, calls the corresponding AI agent to perform analysis, stores the results in the database, and synchronizes them to the cache. By utilizing the collaborative work of the task acquisition module, task scheduling module, and task execution module, combined with the cache middleware and AI agents, the system systematically resolves the conflict between real-time requirements and computational resource limitations in medical scenarios. By employing offline pre-analysis and result caching mechanisms, the AI ​​response speed in real-time business scenarios is improved to the threshold of seamless business operation; a hierarchical task scheduling strategy is adopted to achieve dynamic matching between computing power consumption and task complexity; and a standardized task processing paradigm is constructed to support seamless expansion into scenarios such as cross-disease diagnosis and multimodal data analysis. Attached Figure Description

[0030] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and, together with the description, serve to explain the principles of the invention. Other embodiments and many anticipated advantages of the embodiments will be readily recognized as they become better understood through reference to the following detailed description. Elements in the drawings are not necessarily to scale. The same reference numerals refer to corresponding similar parts.

[0031] Figure 1 This is a schematic diagram of the structure of a medical AI task processing system based on offline preprocessing according to an embodiment of the present invention;

[0032] Figure 2 This is a schematic diagram of the medical AI task processing system architecture based on offline preprocessing according to an embodiment of the present invention;

[0033] Figure 3 This is a schematic diagram of the retry mechanism of the task execution module according to an embodiment of the present invention;

[0034] Figure 4 This is a flowchart of the cache middleware query process according to an embodiment of the present invention;

[0035] Figure 5 This is a system execution timing diagram according to an embodiment of the present invention;

[0036] Figure 6This is a schematic diagram of the process executed by the system according to an embodiment of the present invention in an offline quality control analysis scenario;

[0037] Figure 7 This is a schematic diagram of the process executed by the system according to an embodiment of the present invention in a lung nodule CT analysis scenario. Detailed Implementation

[0038] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0039] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0040] According to an embodiment of the present invention, a medical AI task processing system based on offline preprocessing is provided.

[0041] Figure 1 This is a schematic diagram of the structure of a medical AI task processing system based on offline preprocessing according to an embodiment of the present invention, as shown below. Figure 1 As shown, the system includes a task acquisition module, a task scheduling module, and a task execution module; among which,

[0042] The task acquisition module is configured to collect task configuration information and task priority weight scores corresponding to offline tasks from external medical business systems using an interface gateway, based on task configuration information and task priority weight scores pre-stored in the database. It generates task identifiers, associates and stores the task identifiers, task configuration information, and task priority weight scores in the database, and simultaneously synchronizes the task identifiers and task priority weight scores to the caching middleware. The task priority weight scores are dynamically updated according to the medical scenario type corresponding to the external medical business system. The task configuration information includes a service identifier for identifying the AI ​​agent used and dynamic parameters for inputting the AI ​​agent.

[0043] Specifically, the initial task priority weight score is defined by clinical experts based on business needs and is dynamically updated thereafter (for example, the task priority weight score for emergency CT is greater than that for routine physical examination tasks).

[0044] Figure 2 This is a schematic diagram of a medical AI task processing system architecture based on offline preprocessing according to an embodiment of the present invention; as shown below. Figure 2As shown, the interface gateway is configured to collect medical diagnostic files from offline tasks in external medical business systems. It extracts and parses the features of these files based on the pre-stored protocol types in the database, obtaining dynamic parameters from the task configuration information. The medical diagnostic file protocol types include DICOM and HL7. By configuring the protocol type (DICOM or HL7), the interface gateway can directly process standardized data from external medical business systems such as PACS, HIS, and LIS, enabling seamless integration into the existing medical information ecosystem. It automatically parses complex medical data formats (such as DICOM image files or HL7 messages), extracting key features as dynamic parameters, significantly lowering the barrier to system deployment and integration, and supporting seamless expansion across disease diagnosis and multimodal data analysis scenarios.

[0045] The interface gateway extracts the features of files in offline tasks based on the preset protocol types stored in the database, and parses the features of files in offline tasks, including using AI models for parsing.

[0046] The response data format from the interface gateway to the corresponding medical business system is as follows:

[0047] "{"taskId":"uuid32",

[0048] "serviceId": "service ID",

[0049] "inputs":"{"visitNo":"123456"}",

[0050] "content": "Voice and text content",

[0051] "query":""}";

[0052] in,

[0053] taskId represents the task identifier. The business side generates a 32-bit UUID, which is used to ensure that all offline application tasks are globally unique. The taskId uniquely identifies a task in the medical business system and the corresponding execution result on the AI ​​agent. Different tasks cannot be duplicated.

[0054] serviceId represents the service identifier. serviceId needs to be combined with dynamic parameters inputs for the AI ​​agent to execute offline normally.

[0055] inputs represent the dynamic parameters used to input the AI ​​agent, in JSON format. The content of the JSON format depends on the flow input parameter configuration of the agent on DIFY.

[0056] The "content" field represents a reserved area for text analysis of user conversations, such as speech-to-text conversion, as input for additional AI agents.

[0057] The `query` field represents the initial request dialogue content used to configure the AI ​​agent; its availability depends on whether it's configured on DIFY. Fields are reserved for text analysis of user dialogue content. It's important to note that DIFY is an open-source platform for building AI applications and configuring intelligent agents.

[0058] Specifically, the database is configured to construct the offline task dictionary table and the offline task record table;

[0059] The offline task dictionary table is configured to store preset task configuration information and task priority weight scores. The task configuration information includes at least the service identifier, medical diagnostic file protocol type, retry policy, acquisition policy, and the identifier of the external medical business system to which it belongs.

[0060] The data collection strategy is associated with task priority weights, the external medical business system to which the task belongs, the medical diagnostic file protocol type, and service identifiers. When the task collection module is triggered in real-time or periodically to collect data from various medical business systems, it calls the collection strategy in the offline task dictionary table. Based on the collection strategy, it uses the interface gateway to collect the task configuration information and task priority weights corresponding to the offline tasks from the external medical business systems. It also extracts and parses the characteristics of the files in the offline tasks based on the medical diagnostic file protocol types stored in the database, obtaining dynamic parameters from the task configuration information. The medical diagnostic file protocol types include DICOM and HL7. The offline task dictionary table is also configured to store task dictionary identifier and task dictionary name fields. Furthermore, when the external medical business systems are clustered, the collection strategy includes a random collection strategy or a round-robin collection strategy.

[0061] The offline task log table is configured to store task identifiers, task configuration information, and task priority weight scores;

[0062] The offline task record table is configured to be used for database sharding based on the external medical business system, and to store task identifiers, task configuration information, and task priority weight scores based on time-based table partitioning. A block-range index (BRIN) is created for the task identifier field. Through this technical solution, a combined sharding strategy of vertical database partitioning based on the external medical business system and horizontal table partitioning based on time, along with the creation of a BRIN index for the frequently accessed task identifier field, enables the system to efficiently support the storage and retrieval of large-scale medical tasks, effectively solving the problems of large data volume, rapid growth, and complex query patterns in medical scenarios.

[0063] Furthermore, the offline task record table is also configured to store task dictionary identifiers associated with offline tasks, fields reserved for user dialogue content text analysis, and fields for configuring the initial request dialogue content of the AI ​​agent.

[0064] Specifically, the task acquisition module is also configured to maintain offline tasks through the backend management interface, that is, to update the offline task dictionary table, including but not limited to modifying service identifiers, task priority weight scores, dynamic parameters, retry strategies, acquisition strategies, and the identifiers of the external medical business systems to which they belong.

[0065] like Figure 1 and Figure 2 As shown, the task scheduling module is configured to sort all offline tasks in the database in descending order based on the task priority weight scores in the caching middleware, and generate a task queue, i.e. Figure 2 The task queue shown sorts each offline task in descending order as Task 1, Task 2, Task 3, and Task 4, and so on; and allocates more computing resources according to the priority weight score of the corresponding task.

[0066] Specifically, the Redis caching middleware should be selected.

[0067] Specifically, the caching middleware is configured to store task identifiers and task priority weight scores in association based on a SortSet collection.

[0068] Specifically, the task scheduling module is built using the XXL-JOB framework.

[0069] like Figure 1 and Figure 2 As shown, the task execution module is configured to retrieve offline tasks sequentially from the task queue, call the corresponding AI agent to perform analysis based on the task configuration information of the corresponding offline task, store the execution results in the database, and simultaneously synchronize the execution results to the cache middleware.

[0070] Specifically, the task execution module is configured to calculate the SHAP value (feature contribution) based on the medical features in the execution results of each successfully executed offline task. The SHAP values ​​of each successfully executed offline task are sorted in ascending order to obtain a ranking, with the median of all SHAP values ​​in ascending order serving as the benchmark. When the SHAP value of any offline task is greater than the benchmark, the task priority weight score stored in the task acquisition module is updated to the sum of the current task priority weight score and the ranking preset weight increase score. When the SHAP value of any offline task is less than the benchmark, the task priority weight score stored in the task acquisition module is updated to the difference between the current task priority weight score and the ranking preset weight decrease score. The ranking preset weight increase score and ranking preset weight decrease score are predefined values. Through this technical solution, tasks with more critical, complex, or learning-value-rich analysis results (i.e., high SHAP values) are automatically prioritized, ensuring that limited computing resources are invested in areas that generate the greatest benefit, achieving optimal matching between computing resources and medical value, and improving the overall efficiency and clinical applicability of the system.

[0071] Specifically, the task priority weight score updates support both manual pre-configuration via the management interface and dynamic updates based on the number of hits by the AI ​​agent during continuous operation, using reinforcement learning algorithms. Task types with a higher number of hits by the AI ​​agent will have higher value and reliability in future analysis results. Therefore, by increasing the task priority weight score of such tasks, computing resources can be allocated preferentially, ensuring that high-value tasks are processed promptly, while simultaneously improving the overall system result reuse rate and saving computing power.

[0072] Specifically, the task scheduling module is also configured to generate a computing resource (GPU or CPU) utilization matrix to identify idle resource periods (e.g., GPU utilization is less than 30% in the early morning); calculate the analysis computing cost of corresponding offline tasks (e.g., the cost of a single inference of a certain model is $0.15); and schedule offline tasks with priority weight scores lower than other priority weight scores during idle periods based on the resource utilization matrix. As an example, by scheduling tasks during idle periods (e.g., performing AI model training in the early morning), resource utilization is improved by 45%; and the monthly GPU cost is reduced by $3,200 (actual test data from a top-tier hospital).

[0073] like Figure 3After tasks are queued, the task scheduling module allocates CPU clusters when CPU is sufficient and A100 nodes when GPU is sufficient. Using the allocated resources, the task execution module invokes the corresponding AI agent to perform analysis based on the task configuration information of the offline task. By generating a resource utilization matrix and computing cost statistics, idle resource periods are identified, and low-priority tasks are scheduled during these periods, improving overall resource utilization by 45% and significantly reducing the operating costs of medical AI applications.

[0074] like Figure 3 As shown, after the AI ​​agent successfully performs analysis, the execution results of the corresponding offline task are stored in the cache middleware and database. The task execution module is also configured to trigger retries according to the retry strategy of the corresponding offline task if the AI ​​agent fails to perform analysis. The retry strategy includes retrying after a predetermined time (e.g., 5 minutes) if the failure is due to a network error; generating an alarm and determining the failure as a model anomaly if the number of retries exceeds a preset threshold (e.g., 3 times); and switching to a backup AI agent to perform the analysis if the failure is indeed due to a model anomaly. The predetermined time and preset threshold are custom-defined values. Through the retry strategy, the task execution module can automatically perform a limited number of retries in case of network anomalies or model failures, and seamlessly switch to a backup AI agent in case of severe failures. This mechanism ensures high availability for critical medical tasks (such as emergency diagnosis), avoids diagnostic delays caused by single points of failure, and provides a reliable guarantee for the continuous and stable operation of medical AI applications.

[0075] Specifically, the caching middleware is also configured to store execution results based on a String collection;

[0076] The caching middleware is configured to store execution results based on a cache key. This cache key is constructed from a service identifier, the hash value of dynamic parameters (MD5.hash(inputs)), and a session identifier. The session identifier identifies the current session during the analysis process performed by the corresponding AI agent. By using a cache key generated from the service identifier, the hash value of dynamic parameters, and the session identifier, precise matching across three dimensions is achieved. This ensures the correctness of different query results within the same session while allowing the reuse of identical query results between different sessions. While maintaining the accuracy of medical diagnosis, it maximizes cache utilization, increasing the reuse rate of similar tasks by 47%.

[0077] Furthermore, the caching middleware is configured to store the AI ​​agent's hit count based on a hash set. The determination of the AI ​​agent's hit count includes checking the output format and identifying any unwanted content after the AI ​​agent outputs its results. A combined storage architecture using SortSet, String, and Hash data structures optimizes the efficiency of task scheduling, result retrieval, and metadata management. This architecture supports weighted priority scheduling (SortSet), millisecond-level result retrieval (String), and efficient cache metadata management (Hash), improving the cache hit rate by 37% compared to general solutions, achieving a caching effectiveness rate of 98.2% for emergency tasks and 82.5% for regular tasks.

[0078] Specifically, the database is also configured to construct an offline task result table, which stores the execution results, exception information, and status of the corresponding offline tasks. The offline task result table is also configured to store the task dictionary identifier, dynamic parameters, AI agent hit count, and session identifier of associated offline tasks; the AI ​​agent hit count and session identifier are synchronously obtained from the metadata storage set of the cache middleware.

[0079] Furthermore, such as Figure 4 As shown, when the client of the corresponding medical business system issues a query request for any task, Figure 4 When making a China-Singapore session request, the first parameter combination is based on the service identifier and dynamic parameters included in the query request, i.e. Figure 4 The `serviceId+inputs` parameter in the query request, or the second parameter combination consisting of the service identifier, dynamic parameters, and session identifier, is... Figure 4 The `serviceId+inputs+conversationId` parameter is used to query the cache middleware using either the first or second parameter combination. If the cache is hit, the AI ​​agent's hit count in the cache middleware is updated, and the cached result in the execution result storage set in the cache middleware is returned to the client of the corresponding medical business system. If the cache is not hit, `DIFY` is called in real time to request the AI ​​agent to process the data. After the AI ​​agent successfully performs the analysis, the execution result of the corresponding offline task is stored in the cache middleware, including storing the execution result and status of the corresponding offline task in the execution result storage set in the cache middleware, storing the AI ​​agent's hit count and creation time in the metadata storage set in the cache middleware, and returning the execution result to the client of the corresponding medical business system. If the AI ​​agent fails to perform the analysis, an error response is returned.

[0080] It's important to note that when handling a large number of offline tasks, the task scheduling module prioritizes tasks with high business weight (including enriching and dynamically increasing computing resources). This ensures that new AI session requests hit the cache as much as possible, rather than going through real-time processing. If the cache is not hit, it means that the business itself has a low priority and low frequency, and was not executed, or that the business is not suitable for preprocessing. In this case, if there is no cache hit, DIFY is called in real-time to request the AI ​​agent to handle it.

[0081] Furthermore, such as Figure 5 As shown, when a client of the corresponding medical business system issues a query request result: RadAI_001 for any task, it queries the cache middleware. If the cache is hit, the cached result Protocol Buffers in the execution result storage set of the cache middleware is returned to the client of the corresponding medical business system. If the cache is not hit, the original parameters (task identifier, task configuration information, and task priority weight score) are obtained from the offline task record table of the database. Based on the task scheduling module, XXL-job dynamic scheduling is triggered to generate a task queue. Based on the task execution module, offline tasks are obtained sequentially from the task queue. According to the task configuration information of the corresponding offline task, the corresponding AI agent is called to perform analysis. The execution result (String result) is synchronized to the cache middleware. The hit count of AI agent in the metadata storage set of the cache middleware is incremented. The task priority weight score stored in the task acquisition module is dynamically updated according to the hit count of AI agent. Alternatively, the SHAP value is calculated based on the medical features in the execution result. The successfully executed tasks are sorted in ascending order according to the SHAP value. All SHAP values ​​are then sorted in ascending order. The median value serves as a baseline, dynamically updating the task priority weight scores stored in the task acquisition module; or, based on the type of medical scenario, dynamically updating the task priority weight scores stored in the task acquisition module. The task execution module can automatically adjust task priority weights based on the type of medical scenario (e.g., emergency or routine) and the success rate of the AI ​​agent's execution. This intelligent design enables the system to adapt to changes in the medical environment, prioritizing urgent and high-value diagnostic tasks, ensuring that limited computing resources are always invested in the most needed medical scenarios.

[0082] Specifically, the system also includes an intelligent hit dashboard for medical decision support, including a real-time monitoring panel that displays cache hit rate, task response time distribution, and GPU / CPU utilization heatmap; medical indicator correlation: linking the number of hits by the AI ​​agent with diagnostic accuracy (e.g., the more hits a certain image analysis model has, the higher the diagnostic consistency rate); and anomaly warning: automatically marking inefficient tasks (e.g., tasks with an AI agent hit rate of <50% for 3 consecutive times).

[0083] Specifically, the task execution module is also configured to fine-tune the training of the AI ​​agent based on SHAP values. This module analyzes feature contribution and provides feedback on feature parameters, enabling the system to continuously learn from real-world use, constantly optimizing feature extraction and model performance. This creates a positive cycle of increasing intelligence with use, improving the accuracy of the AI ​​agent and reducing feature extraction time.

[0084] The data flow is as follows: offline task results → feature importance analysis → model fine-tuning training → new feature injection → caching strategy update. The caching strategy update involves the task execution module calculating SHAP values ​​based on the medical features in the execution results, sorting successfully executed tasks in ascending order according to the SHAP values, and dynamically updating the task priority weight scores stored in the task acquisition module using the median of all SHAP values ​​after ascending sorting as the benchmark. As an example, the accuracy of the disease screening model improved by 12% (tested at a top-tier hospital); feature extraction time was reduced by 30%.

[0085] As a practical implementation example of the system in this application, its offline quality control analysis scenario is as follows: Figure 6 As shown, the external medical business system includes the ONE-LINK quality control system and the ONE-LINK-EMR system. The ONE-LINK quality control system is used to provide quality control patient information, and the ONE-LINK-EMR system is used to provide patient medical record information. The integration platform / adapter undertakes the interaction conversion and gateway functions between the external business and the present invention, that is, it includes the interface gateway of the present system.

[0086] like Figure 6 As shown, in this example, the system implements the following steps:

[0087] A scheduled task is created to trigger the task acquisition module during a preset time period. The module uses the interface gateway of the integration platform / adapter to collect offline tasks from an external medical business system (ONE-LINK system) and transfers them to this system. At this point, the offline tasks are a list of patients awaiting quality control. Therefore, the task acquisition module obtains the service identifier used to identify the AI ​​quality control agent and the task priority weight score for the individual patient quality control task in the list of patients awaiting quality control. Simultaneously, the task acquisition module also uses the interface gateway of the integration platform / adapter to continue acquiring the individual patient's medical record information from the external medical business system (ONE-LINK-EMR system). Based on the protocol type, the module automatically parses the medical record information (DICOM file), extracts the medical record content that needs quality control, and sends it to this system. At this point, the medical record information becomes the dynamic parameters used to input the AI ​​agent in the task configuration information, and a task identifier is generated. The task identifier and task priority weight score are synchronized to the cache middleware.

[0088] The task scheduling module sorts all single-patient quality control tasks in the patient list in descending order according to the task priority weight score in the cache middleware, generates a task queue, and allocates NVIDIA A100 nodes to offline tasks with higher priority weight scores than other tasks.

[0089] The task execution module retrieves individual patient quality control tasks sequentially from the task queue. Based on the task configuration information of the corresponding individual patient quality control task, it calls the corresponding AI agent to perform analysis, generates quality control details of problems and generates scoring information, compresses the quality control analysis results composed of quality control details and scoring information, and stores them in the database and cache middleware. When quality control personnel review medical records, the cached results are returned directly (response time <20ms).

[0090] As a second practical implementation example of the system in this application, its lung nodule CT analysis scenario is as follows: Figure 7 As shown, the external medical business system includes the ONE-LINK-EMR system, which is used to provide patients' CT images. The integration platform / adapter undertakes the interaction conversion and gateway functions between external business and the present invention, that is, it includes the interface gateway of the present system.

[0091] like Figure 7 As shown, in this example, the system implements the following steps:

[0092] When a radiologist uploads several CT images to an external medical business system (ONE-LINK-EMR system), the task acquisition module is triggered. Utilizing the interface gateway of the integrated platform / adapter, the module acquires these CT images from the ONE-LINK-EMR system, obtaining the medical record information for each image. The module automatically parses the medical record information (DICOM file) according to the protocol type. The medical record information includes 13-dimensional features such as nodule volume and density. All medical record information is extracted and sent to the task acquisition module. The task acquisition module collects the task configuration information and task priority weight score corresponding to the CT image analysis task and generates a task identifier. The task configuration information includes a service identifier that identifies the AI ​​CT image analysis agent and the task priority weight score for each of the CT images. The task identifier and task priority weight score are synchronized to the cache middleware.

[0093] The task scheduling module sorts the CT image analysis tasks in descending order according to the task priority weight score in the cache middleware and generates a task queue (offline task queue). NVIDIA A100 nodes are allocated to offline tasks with higher priority weight scores than other offline tasks.

[0094] The task execution module retrieves CT image analysis tasks sequentially from the task queue, calls the corresponding AI CT image analysis agent to perform the analysis according to the task configuration information of the corresponding CT image analysis task, stores the execution results (AI CT image analysis results) in the database, and generates an analysis report containing a confidence score (0.92) and stores it in the offline task result table and cache middleware; when the same case is consulted twice, the cached results are returned directly (response time <20ms).

[0095] This invention provides a medical AI task processing system based on offline preprocessing. Utilizing the collaborative work of a task acquisition module, a task scheduling module, and a task execution module, combined with a caching middleware and an AI agent, it solves the contradiction between real-time performance and computing power in medical scenarios at a relatively low cost through three core capabilities: accelerated preprocessing, distributed computing power, and dynamic task scheduling. It not only improves performance but also provides a reusable offline analysis paradigm for the medical industry through multi-scenario adaptation and cost optimization; it achieves hierarchical scheduling, with a response time 90% faster than traditional solutions; the caching middleware uses parameter hashes to accelerate queries, and the offline task result table stores complete data, balancing speed and accuracy; through a three-element collaborative mechanism of database weight, cache priority, and dynamic scheduling, it breaks through the limitations of traditional single-dimensional scheduling, enabling dynamic synchronization of database weights to cache sorting; and its medical-specific caching strategy uses a combination of String (results) + Hash (metadata) + SortSet (priority) storage, improving cache hit rate by 37% compared to general solutions (actual test results show a caching effectiveness rate of 98.2% for emergency tasks and 82.5% for regular tasks).

[0096] The specific embodiments of the present invention have been described above, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0097] In the description of this invention, it should be understood that the terms "upper," "lower," "inner," "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The simple fact that certain measures are recited in mutually different dependent claims does not indicate that combinations of these measures cannot be used for improvement. Any reference signs in the claims should not be construed as limiting the scope.

Claims

1. A medical AI task processing system based on offline preprocessing, characterized in that, It includes a task acquisition module, a task scheduling module, and a task execution module; among which, The task acquisition module is configured to collect task configuration information and task priority weight scores corresponding to offline tasks from external medical business systems using an interface gateway, based on task configuration information and task priority weight scores pre-stored in the database. It then generates a task identifier, associates and stores the task identifier, task configuration information, and task priority weight scores in the database, and simultaneously synchronizes the task identifier and task priority weight scores to a caching middleware. The task priority weight scores are dynamically updated according to the medical scenario type corresponding to the external medical business system. The task configuration information includes a service identifier for identifying the AI ​​agent used and dynamic parameters for inputting the AI ​​agent. The task scheduling module is configured to sort all offline tasks in the database in descending order according to the task priority weight score in the cache middleware and generate a task queue; it is also configured to generate a computing resource utilization matrix to identify idle resource periods; calculate the analysis computing cost of the corresponding offline tasks, and schedule the corresponding offline tasks during idle periods based on the resource utilization matrix; The task execution module is configured to sequentially retrieve offline tasks from the task queue, call the corresponding AI agent to perform analysis according to the task configuration information of the corresponding offline task, store the execution results in the database, and simultaneously synchronize the execution results to the cache middleware.

2. The system according to claim 1, characterized in that, The interface gateway is configured to collect medical diagnostic files from offline tasks from external medical business systems, extract and parse the features of the medical diagnostic files according to the medical diagnostic file protocol types pre-stored in the database, and obtain the dynamic parameters in the task configuration information; wherein, the medical diagnostic file protocol types include DICOM and HL7.

3. The system according to claim 1, characterized in that, The database is configured to be sharded according to the external medical business system, and to store the task identifier, task configuration information and task priority weight score in a time-based sharded table, and to create a block range index BRIN for the task identifier field.

4. The system according to claim 1, characterized in that, The caching middleware is configured to store the execution results based on a cache key, which is constructed by combining the service identifier, the hash value of the dynamic parameter, and the session identifier. The session identifier is used to identify the current session during the analysis process performed by the corresponding AI agent.

5. The system according to claim 1, characterized in that, The task execution module is also configured to trigger a retry according to the retry strategy of the corresponding offline task after the AI ​​agent fails to perform the analysis. The retry strategy includes retrying after waiting for a predetermined time if the reason for the failure of the corresponding offline task is a network error; generating an alarm and determining that the reason for the failure is a model anomaly if the number of retries exceeds a preset threshold; and switching to a backup AI agent to perform the analysis of the corresponding offline task if the reason for the failure of the corresponding offline task is a model anomaly.

6. The system according to claim 1, characterized in that, The execution result includes the number of times the AI ​​agent hit the target.

7. The system according to claim 6, characterized in that, The task execution module is also configured to dynamically update the task priority weight score pre-stored in the database based on the number of hits by the AI ​​agent, using a reinforcement learning algorithm.

8. The system according to claim 6, characterized in that, The caching middleware is configured to store the task identifier and the task priority weight score based on a SortSet set, store the execution result based on a String set, and store the number of hits by the AI ​​agent based on a Hash set.

9. The system according to claim 1, characterized in that, The task execution module is further configured to calculate a SHAP value based on the medical features in the execution result of each successfully executed offline task. The SHAP value is the feature contribution of the medical features to the execution result. The SHAP values ​​of each successfully executed offline task are sorted in ascending order to obtain a ranking, and the median of all SHAP values ​​after ascending order is used as the benchmark value. When the SHAP value of any offline task is greater than the benchmark value, the task priority weight score stored in the task acquisition module is updated to the sum of the current task priority weight score and the ranking preset weight increase score. When the SHAP value of any offline task is less than the benchmark value, the task priority weight score stored in the task acquisition module is updated to the difference between the current task priority weight score and the ranking preset weight decrease score.

Images