Medical AI task processing system based on offline preprocessing

Abstract

The invention discloses a medical AI task processing system based on offline preprocessing. The medical AI task processing system comprises a task acquisition module, a task scheduling module and a task execution module, the task acquisition module acquires task configuration information containing a service identifier and a dynamic parameter and a task priority weight score from an external medical service system through an interface gateway, generates a task identifier, associatively stores the task identifier to a database, and synchronizes the task identifier and the weight score to cache middleware, the weight score is dynamically updated according to a medical scene type corresponding to the external medical service system; the task scheduling module sorts all the offline tasks in a descending order according to the weights in the cache to generate a task queue; the task execution module obtains tasks from the queue in sequence, calls corresponding AI agents to execute analysis, stores results in a library and synchronizes the results to a cache; and efficient scheduling of medical AI tasks and optimal allocation of resources are realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of medical task processing, and mainly relates to a medical AI task processing system based on offline preprocessing. BACKGROUND

[0002] At present, more and more medical business systems integrate AI technology, which continuously penetrates into various core business fields, but at the same time, there are dual contradictions of real-time demand and resource limitation. Including real-time bottleneck, cache mechanism defect and serious resource waste problems; Real-time bottleneck: when processing complex reasoning tasks, the traditional AI system has poor real-time interaction experience due to the time-consuming calculation of large models (such as LLM reasoning average delay > 15 seconds), which seriously affects the diagnosis and treatment efficiency and system usability Cache mechanism defect: the conventional cache scheme (such as Redis) only supports key value matching, and cannot adapt to the composite query demand of multi-round conversation (ConversationID) and dynamic parameters (Inputs).

[0003] Serious resource waste: offline tasks and real-time tasks share computing resources, resulting in GPU utilization fluctuation exceeding 60% (peak value 85% vs. valley value 25%).

[0004] The superimposed effect of these three technical requirements leads to the significant performance bottleneck of the traditional cloud reasoning scheme, that is, in the typical diagnosis and treatment scene, the complete AI reasoning process takes more than the clinical operation fault tolerance threshold, and the medical staff often needs to wait for more than 60 seconds to obtain feedback in the real-time interaction scene, which seriously affects the diagnosis and treatment efficiency and system usability. SUMMARY

[0005] In order to solve the technical problems mentioned in the background art, the present application provides 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; wherein, The task acquisition module is configured to acquire the task configuration information and the task priority weight score corresponding to the offline task from the external medical business system based on the task configuration information and the task priority weight score pre-stored in the database by using the interface gateway, generate a task identifier, and store the task identifier, the task configuration information and the task priority weight score in the database in association, and synchronize the task identifier and the task priority weight score to the cache middleware; wherein, the task priority weight score is dynamically updated according to the medical scene type corresponding to the external medical business system, and the task configuration information includes a service identifier for identifying the AI agent used and a dynamic parameter 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 scores in the cache middleware, and generate a task queue; The task execution module is configured to sequentially obtain 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 result to the database, and synchronize the execution result to the cache middleware.

[0006] Through the above technical solutions, the task acquisition module, the task scheduling module and the task execution module work together, combined with the cache middleware and the AI agent, through offline pre-analysis and result caching, a large number of computationally intensive AI tasks are separated from the real-time business path, the response speed of medical AI tasks is improved from minutes to milliseconds, effectively resolving the core contradiction between high real-time demand and limited computing resources in the medical scene; and a hierarchical task scheduling strategy based on cache optimization is adopted, which prioritizes urgent and high-value diagnostic tasks, ensures that limited computing resources are always invested in the most needed medical scenarios, and realizes dynamic matching of computing resource consumption and task complexity; avoiding the high deployment cost and resource contention risk of real-time medical AI tasks.

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

[0008] Through the above technical solutions, the protocol type (DICOM or HL7) is configured, the interface gateway can directly process standardized data from PACS, HIS and LIS external medical business systems, so that the system can seamlessly access 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 reducing the threshold of system deployment and integration, and supporting seamless expansion of cross-disease diagnosis and multi-modal data analysis scenarios.

[0009] Further, the database is configured to store task identifiers, task configuration information and task priority weight scores according to time sub-table association, and to establish a block range index BRIN for the field of the task identifier.

[0010] By the above technical solution, the combination of vertical database division according to external medical business system and horizontal table division according to time, and the establishment of BRIN index for high-frequency access task identification field, make the system can efficiently support large-scale medical task storage and retrieval, effectively solve the problem of large data, fast growth and complex query mode in medical scene.

[0011] Further, the cache middleware is configured to store the execution result based on a cache key, the cache key is constructed by a combination of a service identifier, a hash value of a dynamic parameter and a session identifier, and the session identifier is used to identify the current session in the process of executing analysis by the corresponding AI agent.

[0012] Through the above technical solution, the cache key generated by the combination of the service identifier, the hash value of the dynamic parameter and the session identifier realizes three-dimensional accurate matching. It not only guarantees the correctness of different query results in the same session, but also allows the reuse of the same query results between different sessions. It maximizes the cache utilization rate and improves the similar task reuse rate by 47%, while ensuring the accuracy of medical diagnosis.

[0013] Further, the task scheduling module is further configured to generate a resource utilization rate matrix to identify resource idle periods; and to calculate the analysis computing power cost of the corresponding offline task, and to schedule the corresponding offline task in the idle period based on the resource utilization rate matrix.

[0014] Through the above technical solution, by generating the resource utilization rate matrix and the computing power cost statistics, identifying the resource idle period and scheduling low-priority tasks in these periods, the overall resource utilization rate is improved by 45%, significantly reducing the operation cost of medical AI application.

[0015] Further, the task execution module is further configured to trigger a retry according to a retry strategy of the corresponding offline task after the AI agent fails to execute the analysis, the retry strategy including retrying after waiting for a predetermined time if the reason for the failure of the corresponding offline task execution is network error, and generating an alarm and determining that the reason for the failure of the execution is model abnormality if the number of retries exceeds a preset threshold; if the reason for the failure of the corresponding offline task execution is model abnormality, switching to the standby AI agent to execute the analysis of the corresponding offline task.

[0016] Through the above technical solution, the intelligent retry strategy integrated by the task execution module can automatically retry a limited number of times when the network is abnormal or the model fails, and seamlessly switch to the standby AI agent when there is a serious failure. This mechanism ensures the high availability of critical medical tasks (such as emergency diagnosis), avoids diagnosis delays caused by single-point failures, and provides reliable protection for the continuous and stable operation of medical AI applications.

[0017] Further, the execution result includes the number of hits of the AI agent. Further, the execution result includes the number of hits of the AI agent.

[0018] Further, the task execution module is further configured to dynamically update the task priority weight score pre-stored in the database according to the number of hits of the AI agent based on a reinforcement learning algorithm.

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

[0020] Further, the cache middleware is configured to store the task identifier and the task priority weight score based on a SortSet collection, store the execution result based on a String collection, and store the number of hits of the AI agent based on a Hash collection.

[0021] Through the above technical solution, the combination of SortSet, String and Hash three data structures is used to store the architecture, which optimizes the efficiency of task scheduling, result reading and metadata management. The architecture supports priority scheduling based on weight (SortSet), millisecond-level result retrieval (String) and efficient cache metadata management (Hash), which improves the cache hit rate by 37% compared with the general solution, and makes the cache efficiency of emergency tasks 98.2% and the cache efficiency of regular tasks 82.5%.

[0022] Further, the task execution module is further configured to calculate the SHAP value of the medical feature in the execution result corresponding to each successfully executed offline task, sort the SHAP values of each successfully executed offline task in ascending order to obtain a ranking, and take the median value of all SHAP values after ascending arrangement as a reference value. When the SHAP value corresponding to any offline task is greater than the reference value, the task priority weight score stored in the task collection module is updated to the sum of the current task priority weight score and a preset weight increase score of the ranking. When the SHAP value corresponding to any offline task is less than the reference value, the task priority weight score stored in the task collection module is updated to the difference between the current task priority weight score and a preset weight reduction score of the ranking.

[0023] Through the above technical solution, the tasks with more critical, more complex or more learning value (i.e. high SHAP value) analysis results are automatically processed preferentially, so as to ensure that limited computing resources are invested in places where the greatest benefits can be achieved, to achieve optimal matching of computing resources and medical value, and to improve the overall efficiency and clinical practicability of the system.

[0024] The technical effect of the present application is to provide an offline preprocessing-based medical AI task processing system, which comprises a task acquisition module, a task scheduling module and a task execution module; the task acquisition module acquires task configuration information and priority weight containing service identification and dynamic parameters from an external medical business system through an interface gateway, generates a task identification and stores it in association in a database, and synchronizes the identification and weight to a cache middleware, wherein the weight score is dynamically updated according to the 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 turn, calls the corresponding AI agent to perform analysis, stores the result and synchronizes it to the cache; the collaborative work of the task acquisition module, the task scheduling module and the task execution module is utilized, combined with the cache middleware and the AI agent, to systematically resolve the contradictory contradiction between real-time demand and computing resource limitation in the medical scene. Through the offline pre-analysis and result caching mechanism, the AI response speed of the real-time business scene is improved to the business inapparent threshold; a hierarchical task scheduling strategy is adopted to realize dynamic matching of computing consumption and task complexity; a standardized task processing paradigm is constructed to support seamless expansion of scenes such as cross-disease diagnosis and multi-modal data analysis. BRIEF DESCRIPTION OF DRAWINGS

[0025] The accompanying drawings are included to provide a further understanding of 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 application. Other embodiments and many of the intended advantages of the present application will be readily appreciated as the same becomes better understood by reference to the following detailed description. The elements of the drawings are not necessarily to scale relative to each other. Like reference numerals designate corresponding similar parts.

[0026] Figure 1 Structure schematic diagram of the offline preprocessing-based medical AI task processing system according to the embodiment of the present application; Figure 2 Structure schematic diagram of the offline preprocessing-based medical AI task processing system according to the embodiment of the present application; Figure 3 Retry mechanism schematic diagram of the task execution module according to the embodiment of the present application; Figure 4 Cache middleware query flowchart according to the embodiment of the present application; Figure 5 System execution timing diagram according to the embodiment of the present application; Figure 6 Flowchart of the system in the offline quality control analysis scene according to the embodiment of the present application; Figure 7 Flowchart of the system in the pulmonary nodule CT analysis scene according to the embodiment of the present application. DETAILED DESCRIPTION

[0027] The application will be further described below in conjunction with the drawings and embodiments. It should be understood that the specific embodiments described herein are intended to be merely illustrative of the application and not limiting thereof. It should also be noted that, for the purpose of clarity, only the parts of the drawings that are pertinent to the application are shown.

[0028] It should be noted that the embodiments in the application and the features in the embodiments can be combined with each other without conflict. The application will be described in detail below with reference to the drawings and embodiments.

[0029] According to the embodiments of the application, a medical AI task processing system based on offline preprocessing is provided.

[0030] Figure 1 For the medical AI task processing system based on offline preprocessing according to the embodiments of the application, a structural schematic diagram is shown in Figure 1 The system includes a task acquisition module, a task scheduling module and a task execution module; wherein, The task acquisition module is configured to acquire, based on the task configuration information and the task priority weight score pre-stored in the database, the task configuration information and the task priority weight score corresponding to the offline task from the external medical business system by using the interface gateway, generate a task identifier, store the task identifier, the task configuration information and the task priority weight score in association to the database, and synchronize the task identifier and the task priority weight score to the cache middleware; wherein, the task priority weight score is dynamically updated according to the medical scene type corresponding to the external medical business system, and the task configuration information includes a service identifier for identifying the AI agent used and a dynamic parameter for inputting the AI agent.

[0031] Specifically, the initial task priority weight score is defined by a clinical expert according to business requirements, and is dynamically updated subsequently (for example, the task priority weight score of emergency CT is greater than that of routine physical examination task).

[0032] Figure 2 For the medical AI task processing system based on offline preprocessing according to the embodiments of the application, a structural schematic diagram is shown in Figure 2As shown, the interface gateway is configured to collect medical diagnosis files in offline tasks from external medical business systems, extract and parse the features of the medical diagnosis files in the offline tasks according to the medical diagnosis file protocol types pre-stored in the database, and obtain the dynamic parameters in the task configuration information; wherein the medical diagnosis 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 the system to seamlessly access existing medical information ecosystems, automatically parse complex medical data formats (such as DICOM image files or HL7 messages), extract key features as dynamic parameters, greatly reducing the threshold for system deployment and integration, and supporting seamless expansion of cross-diagnosis and multi-modal data analysis scenarios.

[0033] Among them, the interface gateway extracts the features of the file in the offline task according to the pre-set protocol type stored in the database, and parses the features of the file in the offline task, including using an AI model for parsing.

[0034] The response data format of the interface gateway from the corresponding medical business system is: "{“taskId”:“uuid32”, “serviceId”:“service id”, “inputs”:“{“visitNo”:“123456”}”, “content”:“voice text content”, “query”:“”}”; Among them, taskId represents task identification, which is a 32-bit UUID generated by the business side, i.e., to ensure that all access to offline application tasks are globally unique, taskId uniquely identifies the execution result of the medical business system on the AI agent, and different tasks cannot be repeated; serviceId represents service identification, and serviceId needs to be combined with dynamic parameter inputs to enable the AI agent to execute offline normally; inputs represent dynamic parameters for inputting the AI agent, in JSON format, and the content of the JSON format depends on the flow parameter configuration of the agent on DIFY; content represents a field reserved for user dialogue content text analysis, such as voice-to-text, as an additional input for the AI agent; The query represents a first request question content field for configuring an AI agent, and whether to enable depends on whether it is configured on the DIFY. The fields of the reserved user dialogue content text analysis and are reserved. It should be noted that the DIFY is an open source platform for building AI applications, which is used to configure the construction of an intelligent agent.

[0035] Specifically, the database is configured to construct an offline task dictionary table and an offline task record table. The offline task dictionary table is configured to store preset task configuration information and task priority weight scores, and the task configuration information at least includes a service identifier, a medical diagnosis file protocol type, a retry strategy, a collection strategy, and an identifier of a belonging external medical business system. The collection strategy, the task priority weight score, the belonging external medical business system, the medical diagnosis file protocol type, and the service identifier are associated. When the task collection module is triggered to collect calls to each medical business system in real time or at a fixed time, the collection strategy in the offline task dictionary table is called to collect the task configuration information and the task priority weight score corresponding to the offline task from the external medical business system by using the interface gateway according to the collection strategy, and the features of the file in the offline task are extracted and parsed according to the medical diagnosis file protocol type stored in the database to obtain the dynamic parameters in the task configuration information. The medical diagnosis file protocol type includes DICOM and HL7. The offline task dictionary table is also configured to store a task dictionary identifier and a task dictionary name field. Moreover, when the external medical business system is a cluster, the collection strategy includes a random collection strategy or a polling collection strategy.

[0036] The offline task record table is configured to store a task identifier, task configuration information, and a task priority weight score. The offline task record table is configured to store a task identifier, task configuration information, and a task priority weight score according to the external medical business system, store the task identifier, the task configuration information, and the task priority weight score according to the time, and establish a block range index BRIN for the task identifier field. Through the above technical solution, the combination of the vertical database division according to the external medical business system and the horizontal table division according to the time is used as a sharding strategy, and the BRIN index is established for the high-frequency access task identifier field, so that the system can efficiently support the storage and retrieval of large-scale medical tasks, and effectively solve the problems of large data volume, rapid growth, and complex query mode in the medical scene.

[0037] Moreover, the offline task record table is also configured to store a task dictionary identifier of an associated offline task, a field of reserved user dialogue content text analysis, and a first request question content field for configuring an AI agent.

[0038] Specifically, the task collection module is further configured to maintain the offline tasks, i.e., update the offline task dictionary table, through a background management interface, including but not limited to modifying the service identifier, the task priority weight score, the dynamic parameter, the retry strategy, the collection strategy, and the identifier of the external medical business system to which the task belongs. As shown in Figure 1 and Figure 2 , the task scheduling module is configured to sort all offline tasks in the database in descending order according to the task priority weight scores in the cache middleware, and generate a task queue, i.e., the task queue shown in Figure 2 , sort each offline task in descending order as task 1, task 2, task 3, and task 4, and so on, and allocate more computing resources according to the corresponding task priority weight scores. Specifically, the cache middleware specifically selects Redis cache middleware.

[0039] Specifically, the cache middleware is configured to store the task identifier and the task priority weight score based on the SortSet collection.

[0040] Specifically, the task scheduling module specifically selects the XXL-JOB framework.

[0041] As shown in Figure 1 and Figure 2 , the task execution module is configured to sequentially obtain offline tasks from the task queue, call the corresponding AI intelligent agent to perform analysis according to the task configuration information of the corresponding offline task, store the execution result to the database, and synchronize the execution result to the cache middleware.

[0042] Specifically, the task execution module is configured to calculate the SHAP value, i.e., the feature contribution degree, based on the medical feature in the execution result corresponding to each successfully executed offline task, sort the SHAP values of each successfully executed offline task in ascending order to obtain a ranking, and take the median value of all SHAP values after ascending arrangement as a reference value. When the SHAP value corresponding to any offline task is greater than the reference value, the task priority weight score stored in the task collection module is updated to the sum of the current task priority weight score and the ranking preset weight increase score. When the SHAP value corresponding to any offline task is less than the reference value, the task priority weight score stored in the task collection 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 the ranking preset weight decrease score are predefined values. Through the above technical solution, the tasks with more critical, more complex, or more learning value, i.e., the SHAP value, are automatically prioritized for analysis, so as to ensure that the limited computing resources are invested in the places that can produce the greatest benefits, realize the optimal matching of computing resources and medical value, and improve the overall efficiency and clinical practicability of the system.

[0043] Specifically, the updating of the task priority weight score supports both pre-manual configuration by the management interface and dynamic updating based on the reinforcement learning algorithm during continuous operation according to the hit times of the AI agent to dynamically update the task priority weight score pre-stored in the database. The more the hit times of the AI agent for a task type, the higher the value and reliability of the future analysis result of the task type. Therefore, by increasing the task priority weight score of such a task, the computing resources can be preferentially allocated to ensure that high-value tasks are processed in time, while the overall result reuse rate of the system is improved and the computing power is saved.

[0044] Specifically, the task scheduling module is further configured to generate a computing resource (GPU or CPU) utilization rate matrix to identify resource idle periods (such as a GPU utilization rate less than 30% at midnight); to count the analysis computing power cost of the corresponding offline task (such as a single inference cost of $0.15 for a certain model), and to schedule offline tasks with a task priority weight score less than other priority weight scores in the idle period based on the resource utilization rate matrix. As an example, by scheduling tasks during idle time (such as executing AI model training at midnight), the resource utilization rate is increased by 45%; the monthly GPU cost is reduced by $3,200 (actual data of a certain first-class hospital).

[0045] As Figure 3 After the tasks are queued, the CPU cluster is allocated when the CPU is sufficient, and the A100 node is allocated when the GPU is sufficient by the task scheduling module, and the corresponding AI agent is executed for analysis according to the task configuration information of the corresponding offline task by the task execution module through the allocated resources. By generating a resource utilization rate matrix and computing power cost statistics, idle resource periods are identified and low-priority tasks are scheduled in these periods, which increases the overall resource utilization rate by 45% and significantly reduces the operating cost of medical AI applications.

[0046] As Figure 3As shown, after the AI agent performs analysis successfully, the execution result of the corresponding offline task is stored in the cache middleware and the database. 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 analysis, the retry strategy including retrying after waiting for a predetermined time (such as 5 minutes) if the reason for the failure of the execution of the corresponding offline task is a network error, and generating an alarm and determining that the reason for the failure of the execution is a model abnormality if the number of retries exceeds a preset threshold (such as 3 times); if the reason for the failure of the execution of the corresponding offline task is a model abnormality, switching to a backup AI agent to perform analysis of the corresponding offline task. The predetermined time and the preset threshold are values set by the user. Through the retry strategy, the task execution module can automatically retry a limited number of times when there is a network anomaly or a model failure, and seamlessly switch to a backup AI agent when there is a serious failure. This mechanism ensures the high availability of critical medical tasks (such as emergency diagnosis) and avoids diagnostic delays caused by single-point failures, providing a reliable guarantee for the continuous and stable operation of medical AI applications.

[0047] Specifically, the cache middleware is also configured to store the execution result based on a String set; The cache middleware is configured to store the execution result based on a cache key, the cache key being composed of a service identifier, a hash value MD5.hash(inputs) of dynamic parameters, and a session identifier, the session identifier being used to identify the current session in the process of performing analysis by the corresponding AI agent. The cache key composed of the service identifier, the hash value of the dynamic parameters, and the session identifier achieves precise matching in three dimensions. It not only ensures the correctness of different query results within the same session, but also allows the reuse of exactly the same query results between different sessions, maximizing cache utilization while ensuring the accuracy of medical diagnosis, and increasing the reuse rate of similar tasks by 47%.

[0048] Moreover, the cache middleware is also configured to store the number of AI agent hits based on a Hash set, wherein the determination of the number of AI agent hits includes determining whether the format of the output result meets the requirements, whether there is any unexpected content, and other rules after the AI agent outputs the result. The combination of SortSet, String, and Hash three data structures optimizes the efficiency of task scheduling, result reading, and metadata management. This architecture supports priority scheduling based on weights (SortSet), millisecond-level result retrieval (String), and efficient cache metadata management (Hash), which improves the cache hit rate by 37% compared to general solutions, making the efficiency of emergency task cache 98.2% and the efficiency of regular task cache 82.5%.

[0049] Specifically, the database is also configured to construct an offline task result table, wherein the offline task result table is configured to store the execution result, abnormal information and state of the corresponding offline task. The offline task result table is also configured to store the task dictionary identifier, dynamic parameter, AI agent hit frequency and conversation identifier of the associated offline task; wherein the AI agent hit frequency and conversation identifier are synchronously obtained from the metadata storage set of the cache middleware.

[0050] Further, as shown in Figure 4 When the client of the corresponding medical business system issues a query request for any task, i.e. Figure 4 a new conversation request, based on the first parameter combination composed of the service identifier and dynamic parameter contained in the query request, i.e. Figure 4 serviceId+inputs in the above formula, or the second parameter combination composed of the service identifier, dynamic parameter and conversation identifier contained in the query request, i.e. Figure 4 serviceId+inputs+conversationId in the above formula, the query is performed in the cache middleware through the first parameter combination or the second parameter combination. If the cache hits, the AI agent hit frequency in the cache middleware is updated, and the cache 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 misses, the DIFY is called in real time to request the AI agent to process. After the AI agent performs analysis successfully, the execution result of the corresponding offline task is stored in the cache middleware, including storing the execution result and state of the corresponding offline task in the execution result storage set in the cache middleware, storing the hit frequency and creation time of the AI agent in the metadata storage set in the cache middleware 112, and returning the execution result to the client of the corresponding medical business system. If the AI agent performs analysis unsuccessfully, an error response is returned.

[0051] It should be noted that the task scheduling module is used to ensure that tasks with high business weight are preferentially executed (including enrichment and dynamic increase of computing resource) when a large number of offline task demands are processed, so as to ensure that the cache is hit as much as possible when the AI new conversation request is processed, and the real-time processing is not performed. If the cache is not hit, it means that the priority of the business itself is relatively low and the frequency is also relatively low, and the task is not executed or the business is not suitable for pre-processing. At this time, the cache is not hit, and the DIFY is called to request the AI agent to process in real time.

[0052] Further, as shown in Figure 5As shown, when the client corresponding to the medical business system issues a query request result: RadAI_001 for any task, the cache middleware is queried, and if the cache hits, the cached result Protocol Buffers in the execution result storage set in the cache middleware is returned to the client corresponding to the medical business system; if the cache does 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, the XXL-job dynamic scheduling generates a task queue, and based on the task execution module, the offline tasks are sequentially obtained from the task queue, the corresponding AI agent is called to execute analysis according to the task configuration information of the corresponding offline task, and the execution result (String result) is synchronized to the cache middleware. The hit count of the metadata storage set in the cache middleware is incremented, and the task priority weight score stored in the task collection module is dynamically updated according to the hit count of the AI agent; or the SHAP value is calculated based on the medical features in the execution result, the tasks that are successfully executed are sorted in ascending order according to the SHAP value, and the median value of all SHAP values arranged in ascending order is taken as a reference value, and the task priority weight score stored in the task collection module is dynamically updated; or the task priority weight score stored in the task collection module is dynamically updated according to the type of the medical scene. The task execution module can automatically adjust the task priority weight based on the type of the medical scene (such as emergency or routine) and the hit of the AI agent execution result. This intelligent design enables the system to adapt to changes in the medical environment, prioritize diagnosis tasks that are urgent and valuable, and ensure that limited computing resources are always invested in the most needed medical scenes.

[0053] Specifically, the system further includes an intelligent hit board for medical decision support, including a real-time monitoring panel: showing cache hit rate, task response time distribution, GPU / CPU utilization heat map; medical index association: associating AI agent hit count with diagnosis accuracy (such as the more times an image analysis model hits, the higher the consistent diagnosis rate); abnormal early warning: automatically marking inefficient tasks (such as tasks with AI agent hit rate < 50% for 3 consecutive times).

[0054] Specifically, the task execution module is further configured to fine-tune the training of the AI agent based on the SHAP value. The task execution module can analyze the feature contribution and feedback the feature parameters, so that the system can continuously learn from actual use, continuously optimize feature extraction and model performance, form a positive cycle of getting smarter, improve the accuracy of the AI agent, and reduce the time consumption of feature extraction.

[0055] The data flow is offline task result → feature importance analysis → model fine-tuning training → new feature injection → cache strategy update, that is, the task execution module calculates the SHAP value based on the medical features in the execution result, sorts the tasks that are successfully executed in ascending order according to the SHAP value, and dynamically updates the task priority weight score stored in the task collection module based on the median value of all SHAP values in ascending order. As an example, the accuracy of the disease screening model is improved by 12% (measured in a certain third-grade hospital); the feature extraction time is reduced by 30%.

[0056] As a practical implementation example of the system of the present application, the offline quality control analysis scene is as shown in Figure 6 The external medical business system includes a ONE-LINK quality control system and a ONE-LINK-EMR system, wherein the ONE-LINK quality control system is used to provide quality control patient information, and the ONE-LINK-EMR system is used to provide medical record information of the patient. The integrated platform / adapter undertakes the interactive conversion and gateway function between the external business and the present application, that is, it contains the interface gateway of the present system. As shown in Figure 6 In this example, the present system implements the following steps: A timing task is created to trigger the task collection module at a preset time period, and the interface gateway of the integrated platform / adapter is used to collect offline tasks from the external medical business system (ONE-LINK system) to the present system. At this time, the offline task is a list of patients to be controlled, so the task collection module obtains the service identifier for identifying the AI quality control intelligent agent and the task priority weight score of the single patient quality control task in the list of patients to be controlled. At the same time, the task collection module also uses the interface gateway of the integrated platform / adapter to continue to obtain the medical record information of the single patient from the external medical business system (ONE-LINK-EMR system), automatically parses the medical record information (DICOM file) according to the protocol type, extracts the medical record content that needs to be controlled for the patient, and sends it to the present system. At this time, the medical record information is the dynamic parameter for inputting the AI intelligent agent in the task configuration information, and a task identifier is generated. The task identifier and the task priority weight score are synchronized to the cache middleware; The task scheduling module sorts all single patient quality control tasks in the list of patients to be controlled in descending order according to the task priority weight score in the cache middleware, and generates a task queue. The NVIDIA A100 node is allocated to the offline task with a higher task priority weight score than others in priority; The task execution module sequentially obtains single-patient quality control tasks from the task queue, calls corresponding AI agents to perform analysis according to the task configuration information of the corresponding single-patient quality control task, generates quality control details with problems and score information, and stores the quality control analysis results formed by the quality control details and the score information in the database and the cache middleware after compression; when the quality control personnel reviews the medical record, the cache result is directly returned (response time <20 ms).

[0057] As a second practical implementation example of the system of the present application, a lung nodule CT analysis scene is as shown in Figure 7 The external medical business system includes a ONE-LINK-EMR system, wherein the ONE-LINK-EMR system is used to provide CT images of patients, and the integration platform / adapter undertakes the interactive conversion and gateway function of the external business and the present application, that is, contains the interface gateway of the system; As shown in Figure 7 In this example, the following steps are implemented by the system: When a radiologist uploads a plurality of CT images on an external medical business system (ONE-LINK-EMR system), a task acquisition module is triggered, the interface gateway of the integration platform / adapter is used to collect a plurality of CT images from the external medical business system (ONE-LINK-EMR system), the medical record information of each of the plurality of CT images is obtained, the medical record information (DICOM file) is automatically parsed 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 acquires task configuration information and task priority weight scores corresponding to the CT image analysis task, and generates a task identifier; wherein the task configuration information includes a service identifier identifying an AI CT image analysis agent and a task priority weight score for each of the plurality of CT images, and the task identifier and the task priority weight score are synchronized to the cache middleware; The task scheduling module sorts the CT image analysis tasks in descending order according to the task priority weight scores in the cache middleware, and generates a task queue (offline task queue), and allocates NVIDI A100 nodes to the offline tasks with higher task priority weight scores in priority; The task execution module sequentially obtains CT image analysis tasks from the task queue, calls corresponding AI CT image analysis agents to perform analysis according to the task configuration information of the corresponding CT image analysis task, stores the execution result (AI CT image analysis result) to the database, and generates an analysis report containing a confidence score (0.92) and stores it in the offline task result table and the cache middleware; when the same case is inquired again, the cache result is directly returned (response time <20 ms).

[0058] The application provides a medical AI task processing system based on offline preprocessing, which utilizes the cooperative work of a task acquisition module, a task scheduling module and a task execution module, combines a cache middleware and an AI intelligent agent, and solves the contradiction between real-time performance and computing power in a medical scene through three core capabilities of preprocessing acceleration, computing power allocation and task dynamic scheduling at a small cost. Not only the performance is improved, but also the reusable offline analysis paradigm is provided for the medical industry through multi-scene adaptation and cost optimization; hierarchical scheduling is realized, which is 90% faster than the traditional scheme; the cache middleware stores parameter hash to accelerate query, and the offline task result table stores complete data, which balances speed and accuracy; through the ternary cooperative mechanism of database weight, cache priority and dynamic scheduling, the limitations of traditional single-dimensional scheduling are broken through, and the database weight is dynamically synchronized to the cache sorting; the cache strategy special for the medical scene: the combination of String (result) + Hash (metadata) + SortSet (priority) storage, which improves the cache hit rate by 37% (emergency task cache efficiency 98.2%, regular task 82.5%) compared with the general scheme.

[0059] The specific embodiments of the application are described above, but the protection scope of the application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical range disclosed by the application, which should be covered within the protection scope of the application. Therefore, the protection scope of the application should be subject to the protection scope of the claims.

[0060] In the description of the application, it should be understood that the terms "upper", "lower", "inner", "outer" and the like indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the application and simplifying the description, and do not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, therefore cannot be understood as a limitation on the application. The word 'including' does not exclude the existence of elements or steps not listed in the claims. The word 'one' or 'a' in front of an element does not exclude the existence of multiple such elements. The simple fact that certain measures are recorded in mutually different dependent claims does not mean that the combination of these measures cannot be used for improvement. Any reference symbol in the claims should not be interpreted 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. 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 scheduling module 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.

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

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

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

9. The system according to claim 7, 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.

10. The system according to claim 1, characterized in that, The task execution module is further configured to calculate the SHAP value based on the medical features in the execution result of each successfully executed offline task, sort the SHAP values ​​of each successfully executed offline task in ascending order to obtain a ranking, and use the median of all SHAP values ​​after ascending order as the benchmark value. When the SHAP value corresponding to 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 corresponding to 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