An AI large model-based inpatient hospital infection case identification method and system

Abstract

The application provides an inpatient hospital infection case identification method and system based on an AI large model, comprising: constructing a screening standard knowledge base based on infection sites, clinical diagnosis, etiological diagnosis and supplementary notes; collecting desensitization diagnosis and treatment data of inpatients, splicing with prompt words to form input text; calling a large model interface to process the input text of the inpatients, and the large model performs reasoning according to the screening standard knowledge base; analyzing the structured data returned by the large model to obtain infection early warning information; wherein the infection early warning information comprises: whether to be infected, infection site, risk level, key evidence and reference standard. The application can provide an inpatient hospital infection case identification method capable of improving the accuracy and scientificity of hospital infection screening, analyzing complex medical screening logic and providing key evidence with clinical interpretability.

Description

Technical Field

[0001] This application relates to the field of medical information and artificial intelligence application technology, and in particular to a method and system for identifying hospital-acquired infection cases in hospitalized patients based on a large AI model, and a method for monitoring the risk of hospital-acquired infections in hospitalized patients. Background Technology

[0002] Hospital infection control is a core component of medical quality control, and its accuracy and timeliness directly affect patient safety and the efficiency of medical resource utilization. With the widespread adoption of electronic medical records and the rapid growth of medical data, the demand for efficient, accurate, and traceable screening for hospital infections is increasing.

[0003] Traditional hospital infection screening mainly relies on dedicated personnel manually reviewing medical records or computer-aided screening systems based on fixed rules. However, existing methods have the following drawbacks because they heavily depend on human experience or rules:

[0004] On the one hand, existing technologies rely on fixed and rigid rule expressions, making it difficult to cope with complex clinical diagnostic scenarios. These methods typically screen medical record data based on simple logical combinations, such as combining "abnormal C-reactive protein" with keywords like "abnormal body temperature," or combining detected bacterial results with keywords like "fever for 3 consecutive days," lacking the ability to comprehensively analyze and semantically understand multi-dimensional medical evidence. For example, regarding infection site screening, the etiological diagnostic criteria for lower respiratory tract infections in the *Hospital Infection Diagnostic Criteria (Trial)* are: the number of pathogens isolated via bronchoalveolar lavage (BAL). Pathogens can be isolated from lower respiratory tract secretions collected via protected specimen brush (PSB) or protected bronchoalveolar lavage (PBAL). For patients with pre-existing chronic obstructive pulmonary disease (including bronchiectasis), the pathogen count must be... For judgments based on such complex conditions, existing screening systems suffer from poor flexibility, high maintenance costs, and risks such as low screening sensitivity and unclear results.

[0005] On the other hand, due to the lack of effective screening for complex logic in existing technologies, the screening logic between patient treatment data, diagnostic criteria, and hospital infection control cannot be fully expressed. For example, a patient in a certain hospital meets the criteria of continuous fever, infection keywords in the course of the illness, use of therapeutic antibiotics, and detection of Enterobacter cloacae in clean specimens. However, these three screening indicators (two days of continuous fever, positive symptoms or signs (infection) in the course of the illness, and use of therapeutic antibiotics) do not serve as the basis for assisting hospital infection control specialists in diagnosing that the patient has a deep surgical site infection. Therefore, existing technologies cannot provide users with more accurate and valuable auxiliary decision-making and prevention and control suggestions.

[0006] On the other hand, while existing technology-supported weighted screening methods integrate multi-indicator information to some extent, the setting of risk factors and weight ratios heavily relies on the personal experience of experts. Taking a certain hospital's pleural cavity infection screening program as an example, its assignment of fixed weights and setting thresholds for specific specimen detection results or symptoms such as bacteria, abnormal white blood cells, and abnormal body temperature relies entirely on the medical institution's own experience and data, lacking scientific rigor.

[0007] Therefore, in this context, the technical problem to be solved is how to provide a method for identifying hospital-acquired infections that can improve the accuracy and scientific rigor of hospital infection screening, analyze the complex logic of medical screening, and provide key evidence with clinical interpretability. Summary of the Invention

[0008] In view of the above-mentioned problems of the prior art, this application provides a method and system for identifying hospital-acquired infection cases in hospitalized patients based on an AI large model, and a method for monitoring the risk of hospital-acquired infection in hospitalized patients, so as to improve the accuracy and scientific nature of hospital infection screening, analyze complex medical screening logic, and provide key evidence with clinical interpretability.

[0009] To achieve the above objectives, the first aspect of this application provides a method for identifying hospital-acquired infection cases in hospitalized patients based on a large AI model, comprising:

[0010] Construct a knowledge base of screening criteria based on infection site, clinical diagnosis, etiological diagnosis, and supplementary explanations;

[0011] Collect desensitized medical data from hospitalized patients, concatenate it with prompt words, and form the input text;

[0012] The large model interface is called to process the input text of hospitalized patients, and the large model performs inference based on the screening standard knowledge base.

[0013] The structured data returned by the large model is analyzed to obtain infection early warning information; the infection early warning information includes: whether infected, infection site, risk level, key evidence, and cited standards.

[0014] In summary, by injecting screening criteria into a large model in the form of a knowledge base, and leveraging the model's semantic understanding to extract the screening logic from complex screening criteria, the accuracy and scientific rigor of screening are improved. Furthermore, through cue word engineering, the large model processes the diagnostic and treatment data of hospitalized patients to obtain structured infection warning information. This infection warning information can be further enhanced in terms of interpretability of screening results through key evidence and cited standards.

[0015] As one possible implementation of the first aspect, the process of calling the large model interface to process the input text of hospitalized patients includes: calling at least two large model interfaces through a multi-threaded program; the large models process the input text of different hospitalized patients respectively.

[0016] As shown above, by using a multi-threaded program to process the input text of hospitalized patients in parallel, the data processing efficiency can be improved, meeting the real-time monitoring needs of a large number of hospitalized patients.

[0017] As one possible implementation of the first aspect, the step of calling at least two large model interfaces through a multi-threaded program includes: the multi-threaded program starting a container, the container being injected with an instance of at least one implementation class; wherein each implementation class encapsulates a calling logic for a large model; the multi-threaded program obtaining an instance of the implementation class from the container and calling the large model interface.

[0018] As described above, by dynamically managing instances of implementation classes (or clients) of different large models through containers, rapid configuration of different models can be achieved.

[0019] As one possible implementation of the first aspect, the prompt words include instructions for constraining the output format and decision logic of the large model; wherein the instructions are at least used to limit the output of the infected site to use a predefined standardized dictionary.

[0020] As described above, by constraining the output through prompt word engineering, the standardization and reliability of the large model's output results are improved, forcing it to make more semantically comprehensible inferences by connecting with the contextual information of the standardized dictionary.

[0021] As one possible implementation of the first aspect, the input text is obtained by concatenating a prompt word template, which includes the instruction and reserves placeholders for the desensitized diagnostic data.

[0022] As shown above, the structured assembly of instructions and data is achieved through predefined prompt word templates, which not only ensures the integrity and consistency of key constraint instructions, but also ensures that patient data can be dynamically and accurately filled into the specified positions, thereby improving the standardization and processing reliability of large model input information.

[0023] The second aspect of this application provides a method for monitoring the risk of hospital-acquired infections in hospitalized patients, comprising: in response to a user's monitoring needs for a target hospitalized patient, acquiring desensitized medical data of the target hospitalized patient;

[0024] By applying any of the methods described in the first aspect for identifying hospital-acquired infections in hospitalized patients based on large AI models, infection early warning information can be obtained;

[0025] The infection warning information is presented through a visual interface for users to query.

[0026] The third aspect of this application provides a system for identifying hospital-acquired infection cases in hospitalized patients based on an AI large model, including: a knowledge base injection module for constructing a screening standard knowledge base based on infection site, clinical diagnosis, etiological diagnosis and supplementary explanation;

[0027] The data acquisition module is used to collect desensitized medical data of hospitalized patients and concatenate it with prompt words to form input text;

[0028] The data processing module calls the large model interface to process the input text of hospitalized patients, and the large model performs inference based on the screening standard knowledge base.

[0029] The output module is used to parse the structured data returned by the large model to obtain infection warning information; wherein, the infection warning information includes: whether infected, infection site, risk level, key evidence, and cited standards.

[0030] A fourth aspect of this application provides a computing device, including: a processor and a memory having program instructions stored thereon, the program instructions, when executed by the processor, causing the processor to perform the method for identifying hospital-acquired infection cases of hospitalized patients based on an AI large model as described in any of the first aspects.

[0031] The fifth aspect of this application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a computer, cause the computer to perform the method for identifying hospital-acquired infection cases of hospitalized patients based on an AI large model as described in any of the first aspects.

[0032] The sixth aspect of this application provides a computer program product including program instructions that, when executed by a computer, cause the computer to perform the method for identifying hospital-acquired infection cases of hospitalized patients based on an AI large model as described in any of the first aspects. Attached Figure Description

[0033] Figure 1 This is a flowchart of the method for identifying hospital-acquired infection cases in hospitalized patients based on an AI large model, provided in the first embodiment of this application;

[0034] Figure 2 This is a flowchart of the method for identifying hospital-acquired infection cases in hospitalized patients based on an AI large model, provided in the second embodiment of this application;

[0035] Figure 3 This is a schematic diagram of the hospital infection identification system for inpatients based on an AI large model provided in an embodiment of this application;

[0036] Figure 4 This is a schematic structural diagram of a computing device provided in an embodiment of this application.

[0037] It should be understood that the dimensions and shapes of the blocks in the above structural diagrams are for reference only and should not constitute an exclusive interpretation of the embodiments of the present invention. The relative positions and inclusion relationships between the blocks presented in the structural diagrams are only schematic representations of the structural relationships between the blocks, and are not intended to limit the physical connection methods of the embodiments of the present invention. Detailed Implementation

[0038] The technical solutions provided in this application will be further described below with reference to the accompanying drawings and embodiments. It should be understood that the system architecture and business scenarios provided in the embodiments of this application are mainly for illustrating possible implementations of the technical solutions of this application and should not be construed as the sole limitation on the technical solutions of this application. Those skilled in the art will recognize that the technical solutions provided in this application are equally applicable to similar technical problems as system architectures evolve and new business scenarios emerge.

[0039] It should be understood that the AI-based large-scale model-based identification scheme for hospitalized patients with hospital-acquired infections provided in this application includes a method for identifying hospital-acquired infections in hospitalized patients based on an AI-based large-scale model, a method for monitoring the risk of hospital-acquired infections in hospitalized patients, a system, a computing device, a computer-readable storage medium, and a computer program product. Since these technical solutions solve problems based on the same or similar principles, some repetitive details may not be repeated in the following description of specific embodiments. However, it should be considered that these specific embodiments have mutual references and can be combined with each other.

[0040] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. In case of any inconsistency, the meaning set forth in this specification or derived from the content described herein shall prevail. Furthermore, the terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application. To accurately describe the technical content of this application and to accurately understand the invention, the following explanations or definitions of the terms used in this specification are provided before describing specific embodiments:

[0041] 1) Sensitivity / Recall: In this invention, it refers to the proportion of actual infected people among the positive patients screened by the large model.

[0042] 2) Specificity: In this invention, it refers to the proportion of the actual uninfected number of patients who tested negative in the large model screening.

[0043] 3) Factory Pattern: The factory pattern is a commonly used design pattern. Its core idea is to separate the object creation process from the usage process. A special "factory" class is used to be responsible for creating instances of other classes, thereby simplifying the object creation logic and improving the flexibility and maintainability of the code.

[0044] 4) Injection (Large Model): This refers to providing the screening standard knowledge base to the large model in some form, enabling it to base its analysis and judgment on the content of the knowledge base. This can be achieved, but is not limited to: using the knowledge base as context for prompts, dynamically providing it through retrieval enhancement generation techniques, or fine-tuning the model to learn the knowledge base.

[0045] 5) Spring Framework: An open-source Java platform application framework whose core features include a dependency injection container and aspect-oriented programming, used to simplify enterprise application development.

[0046] 6) IoC Container: Inversion of Control (IoC) container is a core module of the Spring framework. This container is responsible for instantiating, configuring, and assembling objects (called Beans) in the application, and managing dependencies between objects through dependency injection. Its implementation mechanism involves reading external configuration metadata (XML configuration or annotations) to automatically complete object creation and establish dependencies.

[0047] The hospital infection identification scheme for inpatients based on an AI-powered large-scale model provided in this application injects a screening standard knowledge base based on infection site, clinical diagnosis, etiological diagnosis, and supplementary descriptions into a large model. Through prompt word engineering, the large model processes desensitized medical data from inpatients to obtain infection early warning information. This approach provides a method for identifying hospital infection cases that can improve the accuracy and scientific rigor of hospital infection screening, enabling the analysis of complex medical screening logic and providing key evidence with clinical interpretability. This application can be applied to hospital infection monitoring, hospital infection management quality control, and clinical decision support in various medical institutions. The embodiments of this application are described in detail below with reference to the accompanying drawings.

[0048] The first embodiment of this application provides a method for identifying hospital-acquired infection cases in hospitalized patients based on a large AI model. The following will combine... Figure 1 The implementation of each step of the method is described in detail, including steps S10-S40.

[0049] S10: Construct a knowledge base of screening standards based on infection site, clinical diagnosis, etiological diagnosis, and supplementary explanations.

[0050] In some embodiments, clinical screening standards, clearly defined etiological screening result values, and supplementary explanatory values ​​for diagnosing different sites of infection are collected from standards such as the hospital infection screening standards issued by the National Health Commission. In some embodiments, the screening standards may also be collected based on hospital clinical data or local standards, group standards, etc.

[0051] In some embodiments, the screening criteria are converted into structured data in formats such as JSON, XML, or YAML according to four dimensions: infection site, clinical diagnosis, etiological diagnosis, and supplementary explanation.

[0052] In some embodiments, the screening criteria are also constructed based on multi-dimensional and multi-source clinical information such as imaging features, drug use, and susceptibility factors. This information is converted into different structured data depending on the data format; for example, imaging features are converted into structured data using formats such as DICOM (Digital Imaging and Communication Format for Medicine); susceptibility factors are converted into structured data using formats such as JSON, XML, or YAML.

[0053] In some embodiments, the screening criteria library is converted into vectors and stored in a vector database. Specifically, at least one of a general text embedding model, a medical domain-specific embedding model, a multimodal fusion embedding model, or a finely tuned and optimized embedding model can be used to convert the text-based screening criteria into a high-dimensional vector representation through semantic encoding.

[0054] S20: Collect desensitized medical data of hospitalized patients and concatenate it with prompt words to form input text.

[0055] In some embodiments, the medical data of hospitalized patients may include basic patient information (gender, age, number of hospitalizations, etc.), patient transfer information, diagnostic records, and data related to the antibiotics used. The diagnostic records include the diagnostic content, laboratory test results (imaging features, various indicators, etiological evidence), etc.

[0056] In some embodiments, the medical data of hospitalized patients is desensitized through methods such as identifier replacement, generalized fuzzing, and masking sensitive information.

[0057] In some embodiments, the diagnostic data is preprocessed, for example, by performing logical validation on missing key fields (such as body temperature and white blood cell count) and performing simple filling (such as filling with previous valid values) or marking according to clinical rules.

[0058] In some embodiments, the prompts may be in Markdown format, dividing the input text into independent modules to avoid the omission of critical information such as infection dates and illustrative evidence that can occur with free text, thus facilitating later maintenance. The prompts include instructions for constraining the output format and decision logic of the large model; wherein, the instructions at least limit the output of the infection site to use a predefined standardized dictionary. The instructions may also include: ignoring historical context, prohibiting illusions (such as "For uncertain infection sites, please return 'uncertain' instead of guessing a result"), etc.

[0059] In some embodiments, the constraints on the prompt words may also include: the content includes how to return if the patient has multiple infection sites, restricting the answer to the infection site to be in accordance with the relevant content given in the given infection site dictionary, refusing to give irrelevant infection sites outside the dictionary, not returning judgment evidence that is obviously inconsistent with the patient's situation and data, ensuring that the screening logic is strict and accurate, and removing subjective descriptions from the evidence entries.

[0060] In some embodiments, the prompts also include processing of patient medical data, such as removing unnecessary fields (e.g., ICD codes), not outputting empty content, and merging identical content. This reduces the length of patient medical data and avoids redundant or useless data affecting the model's output results or quality.

[0061] In some embodiments, the prompt also includes constraints on multi-source data, such as requiring a clear description of lesion characteristics for the determination of imaging evidence (e.g., CT showing pulmonary consolidation with cavitation), and requiring abnormal thresholds for laboratory indicators (e.g., PCT). 0.5 ng / ml).

[0062] In some embodiments, the prompt words may further include the following instructions: the role of the large model, such as an infection control expert with Certified Infection Control Physician (CIC) qualifications; and a description of the returned data format, such as mandatory JSON.

[0063] In some embodiments, the prompt words have multiple versions. For example, they may include prompt words for a large model that is injected into the screening standard knowledge base and prompt words for a large model that is not injected into the screening standard knowledge base. Users can decide whether to use a large model of the knowledge base or a sub-screening standard knowledge base based on the hospital's situation and adopt different versions of prompt words.

[0064] In some embodiments, the desensitized diagnostic data and prompt words are concatenated into the input text using at least one of the following methods: concatenating the desensitized diagnostic data and prompt words using a predefined separator; or filling the desensitized diagnostic data and prompt words into a pre-set prompt word template.

[0065] S30: Call the large model interface to process the input text of hospitalized patients. The large model performs inference based on the screening standard knowledge base.

[0066] In some embodiments, the step of calling the large model interface to process the input text of hospitalized patients includes: calling at least two large model interfaces through a multi-threaded program; the large models respectively process the input text of different hospitalized patients. That is, the input text of hospitalized patients is processed in parallel through a multi-threaded program. The multi-threaded program can be written in languages ​​such as Java or Python and can have a graphical human-computer interaction interface.

[0067] In some embodiments, the step of calling at least two large model interfaces via a multi-threaded program includes: the multi-threaded program starting a container, the container being injected with instances of at least one implementation class; wherein each implementation class encapsulates a large model calling logic; the multi-threaded program obtains an instance of the implementation class from the container and calls the large model interface. For example, a Java program uses the strategy pattern and the factory pattern to manage instances of different large model clients (implementation classes).

[0068] In some embodiments, the multithreaded program uses a task scheduling strategy for invocation. For example, the multithreaded program may use a dynamic task queue. The main thread is responsible for packaging the input text to be processed into tasks and putting them into the queue. Multiple worker threads retrieve tasks from the queue and call the large model through the implementation class / client instance in the container. When a large model interface call fails or times out, the thread may mark the task as failed and put it back into the queue, or automatically switch to another available standby instance for processing.

[0069] In some embodiments, the large model performs inference based on the screening criteria knowledge base in at least one of the following ways: directly injecting the screening criteria knowledge base as a context prompt, that is, directly inputting the screening criteria as part of the system prompts into the large model, and having the large model acquire and follow the screening criteria in the context of the current dialogue for analysis; dynamically injecting the screening criteria knowledge base through retrieval enhancement (RAG), that is, converting the screening criteria knowledge base into vectors and storing them in a vector database, and when processing patient data, first retrieving the most relevant diagnostic criteria fragments from the vector database based on the input text, and then inputting the retrieved fragments and patient data together as prompts into the large model; and internally injecting the screening criteria knowledge base through model fine-tuning, that is, using the diagnostic criteria knowledge base as a training set to perform supervised fine-tuning or parameter efficiency fine-tuning on the basic large model, so that the diagnostic criteria are internalized and absorbed by the model, becoming part of its own knowledge system.

[0070] In some embodiments, the screening criteria knowledge base can also adopt a hybrid injection approach, where the most stable screening criteria are injected internally through model fine-tuning, while for frequently updated detailed criteria such as those at the hospital and local levels, dynamic injection is generated using retrieval enhancement.

[0071] In some embodiments, a suitable number and types of large models can be invoked to screen hospitalized patients based on factors such as department, ward, disease, and hospital structure.

[0072] In some embodiments, the screening standard knowledge base is categorized to obtain sub-diagnostic screening knowledge bases; the sub-screening standard knowledge bases are then injected into different large models; the input text is adjusted according to the different large models. For example, the screening standard knowledge base can be divided according to disease category, related departments, etc.

[0073] In some embodiments, the large model may employ general-purpose large language models such as Qwen, DeepSeek, GPT, and Claude, or it may employ a pre-trained language model specifically designed for the medical field.

[0074] In some embodiments, the final screening results of the system (including manually confirmed true positive and false positive cases) are recorded to form a feedback dataset. This dataset is used periodically to retrain the fine-tuned large model or to optimize the retrieval strategy during the RAG retrieval phase, thereby achieving continuous self-improvement of the system's recognition performance.

[0075] In some embodiments, the large model is not injected with the screening criteria and is directly used for subsequent analysis and processing.

[0076] S40: Analyze the structured data returned by the large model to obtain infection early warning information; wherein, the infection early warning information includes: whether infected, infection site, risk level, key evidence, and cited standards.

[0077] In some embodiments, the returned infection warning information is structured data in formats such as JSON, XML, and YAML; for example, whether or not an infection is present and infection details can be used as two nodes / primary keys, wherein infection details include sub-nodes / sub-keys such as infection site, risk level, key evidence, and cited criteria; wherein there can be multiple key evidence and cited criteria.

[0078] In some embodiments, the large model parses the structured data and presents the processed content to the user using natural language, tables, charts, etc. Non-standardized data is considered invalid.

[0079] In some embodiments, users may combine the above information to manually screen hospitalized patients for infection risks; or the infection warning information may be further processed and provided to users, for example, by calculating infection risk probability scores, trends, epidemiological correlation indices, etc., and users may manage the hospital based on the calculated and processed data.

[0080] In some embodiments, the large model also outputs its own sensitivity / recall and specificity as a basis for screening accuracy. For example, a confidence field is generated, and low-confidence warning information can be clearly marked for user reference.

[0081] The second embodiment of this application provides a method for identifying hospital-acquired infection cases in hospitalized patients based on a large AI model. The following will refer to... Figure 2 The flowchart shown illustrates that the method provided in this second embodiment includes the following steps S200-S230.

[0082] S200: Construct a knowledge base of screening standards based on infection site, clinical diagnosis, etiological diagnosis, and supplementary explanations.

[0083] Based on infection-related judgment documents issued by the state, such as the "Diagnostic Criteria for Hospital Infections (Trial)" issued by the Ministry of Health in 2001, a knowledge base of relevant screening standards was compiled, clearly listing the hospital infection sites requiring standardized judgment (such as the respiratory system, urinary system, surgical sites, etc.). For each infection site, the clinical symptoms, signs, and imaging manifestations required for diagnosis were refined. Positive thresholds for etiological evidence such as microbial culture and molecular detection were clarified. Detailed judgment rules and methods for excluding interfering factors were supplemented. The diagnostic criteria for different infection sites were compiled according to the format of infection site, clinical diagnosis, etiological diagnosis, and supplementary explanation, as shown in the following example:

[0084]

[0085] The above information is organized into structured data, as shown in the following quadruple:

[0086] [Site of infection A | Clinical diagnosis B | Etiological diagnosis C | Supplementary explanation D]

[0087] Each of the above quadruples is stored as a screening criterion in a screening criterion knowledge base (JSON array) as a JSON object. Each element in the quadruple corresponds to four key-value pairs in the JSON object, using natural language text fragments that conform to medical standards.

[0088] The aforementioned screening standard knowledge base is vectorized. For example, the text content of the four key-value pairs of the JSON object is concatenated, input into a pre-trained model based on the Transformer architecture to generate a text vector representation, and stored in a vector database. Each vector is indexed and associated with the corresponding complete screening standard text and its structured fields.

[0089] S210: Collect desensitized medical data of hospitalized patients and generate input text using prompt word templates.

[0090] The hospital medical record system collects inpatient medical data, including: basic patient information (gender, age, number of hospitalizations, etc.), patient transfer information, diagnostic records, and data related to antibiotics used. The diagnostic records include the diagnosis details and laboratory test results (various indicators, etiological evidence).

[0091] Sensitive information such as patient names and contact information in the above medical data is replaced and desensitized using identifiers, and then converted into query vectors. Similarity is searched in the vector database to find the K screening criteria that are most relevant to the corresponding patient's clinical manifestations, and these criteria are sorted by confidence level as enhanced prompts.

[0092] Desensitized diagnostic data and enhanced prompts are constructed using prompt word templates. The prompt word templates include necessary instructions such as setting large model roles, ignoring historical context, prohibiting hallucinations, and using only standard infection site dictionaries, as shown in the markdown template below:

[0093]

[0094] Here, `has_infection` indicates whether the model is infected, and `infection_details` provides details of the infection, including: site of infection, risk level, date of infection, key evidence, and reference standard. The risk level is categorized as "high," "medium," and "low." The reference standard is determined and returned by injecting knowledge from the large model's knowledge base. Multiple key evidence and reference standards are allowed.

[0095] S220: Call the large model interface to process the input text of hospitalized patients. The large model performs inference based on the screening standard knowledge base.

[0096] The system calls a Java program within the hospital infection control system. The Java program creates multiple threads to call the large model interface, employing the strategy and factory patterns. The Spring framework's IoC container dynamically manages instances of different large model clients.

[0097] Specifically, the Spring IoC container loads the implementation classes of all large model clients according to the configuration file, and injects the large model client instances in the configuration file into the corresponding service components through the dependency injection mechanism.

[0098] Define a unified API for calling large model services, and provide a specific implementation class for each supported large model service. Each implementation class encapsulates the API call details for a specific model. The call details are defined through an external configuration file.

[0099] In actual processing, the Java program creates multiple threads, each independently processing the input text of one patient. Through the injected large model client instance, it uses a unified large model service call interface to invoke the specific large model service for processing, and stores the results in a specified data structure. The system can dynamically switch between different large model clients based on configuration.

[0100] S230: Analyze the structured data returned by the large model to obtain infection warning information. Users can judge whether there is a risk of hospital-acquired infection in hospitalized patients by viewing the infection warning information.

[0101] The structured data obtained in step S220 is parsed to obtain infection warning information including whether the person is infected, the site of infection, the risk level, key evidence, and cited standards. This information is then displayed in a table format on the human-computer interaction interface in response to the query requests of the front-end page.

[0102] Users can use the above information to determine whether there is a risk of hospital-acquired infection among hospitalized patients.

[0103] This application provides a method for identifying hospital-acquired infection cases in hospitalized patients based on a large AI model, including:

[0104] In response to users' monitoring needs for target hospitalized patients, obtain de-identified medical data of target hospitalized patients;

[0105] The method for identifying hospital-acquired infections in hospitalized patients based on an AI large model, as described in the first embodiment of this application, is used to obtain infection early warning information;

[0106] The infection warning information is presented through a visual interface for users to query.

[0107] This application provides a system for identifying hospital-acquired infections in hospitalized patients based on an AI large-scale model. This device can be used to implement the AI ​​large-scale model-based method for identifying hospital-acquired infections in hospitalized patients described in the above embodiments. Figure 3 As shown, the device for identifying hospital-acquired infections in hospitalized patients based on an AI-powered large-scale model includes:

[0108] The knowledge base injection module is used to construct a screening standard knowledge base based on infection site, clinical diagnosis, etiological diagnosis and supplementary explanation; specifically, the knowledge base injection module can be used to implement step S10 in the first embodiment and its optional embodiments.

[0109] The data acquisition module is used to collect desensitized medical data of hospitalized patients and concatenate it with prompt words to form input text; specifically, the data acquisition module can be used to implement step S20 in the first embodiment and its optional embodiments.

[0110] The data processing module is used to call the large model interface to process the input text of hospitalized patients. The large model performs inference based on the screening standard knowledge base. Specifically, the data processing module can be used to implement step S30 in the first embodiment and its optional embodiments.

[0111] The output module is used to parse the structured data returned by the large model to obtain infection early warning information; wherein, the infection early warning information includes: whether infected, infection site, risk level, key evidence, and cited standards. Specifically, this output module can be used to implement step S40 in the first embodiment and its optional embodiments.

[0112] Figure 4 This is a schematic structural diagram of a computing device 900 provided in an embodiment of this application. This computing device can execute various optional embodiments of the methods described above. The computing device can be a terminal, or a chip or chip system within the terminal. Figure 4 As shown, the computing device 900 includes: a processor 910, a memory 920, and a communication interface 930.

[0113] It should be understood that Figure 4 The communication interface 930 in the computing device 900 shown can be used to communicate with other devices, and may specifically include one or more transceiver circuits or interface circuits.

[0114] The processor 910 can be connected to the memory 920. The memory 920 can be used to store the program code and data. Therefore, the memory 920 can be a storage unit inside the processor 910, an external storage unit independent of the processor 910, or a component that includes both the storage unit inside the processor 910 and the external storage unit independent of the processor 910.

[0115] Optionally, the computing device 900 may also include a bus. The memory 920 and communication interface 930 can be connected to the processor 910 via the bus. The bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 The symbol is represented by a line without an arrow, but this does not mean that there is only one bus or one type of bus.

[0116] It should be understood that in the embodiments of this application, the processor 910 may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. Alternatively, the processor 910 may employ one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0117] The memory 920 may include read-only memory and random access memory, and provides instructions and data to the processor 910. A portion of the processor 910 may also include non-volatile random access memory. For example, the processor 910 may also store device type information.

[0118] When the computing device 900 is running, the processor 910 executes computer execution instructions stored in the memory 920 to perform any of the operational steps of the above method and any of the optional embodiments thereof.

[0119] It should be understood that the computing device 900 according to the embodiments of this application can correspond to the corresponding subject in executing the methods according to the various embodiments of this application, and the above and other operations and / or functions of each module in the computing device 900 are respectively for implementing the corresponding processes of the methods of this embodiment. For the sake of brevity, they will not be described in detail here.

[0120] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0121] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0122] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0123] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0124] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0125] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0126] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is used to perform the above-described method, which includes at least one of the schemes described in the above embodiments.

[0127] The computer storage medium in this application embodiment can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0128] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0129] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0130] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0131] Furthermore, the terms "first, second, third, etc." or similar terms such as module A, module B, and module C used in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of objects. It is understood that, where permissible, a specific order or sequence may be interchanged so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0132] In the above description, the labels of the steps involved, such as S110, S120, etc., do not mean that the steps will necessarily be executed. The order of the steps can be interchanged or executed simultaneously if permitted.

[0133] The term "comprising" as used in the specification and claims should not be construed as limiting itself to what follows; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the mentioned feature, integral, step, or component, but does not exclude the presence or addition of one or more other features, integrals, steps, or components, or groups thereof. Thus, the statement "device comprising means A and B" should not be limited to a device consisting solely of components A and B.

[0134] The terms "an embodiment" or "an embodiment" as used in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in at least one embodiment of this application. Therefore, the terms "in one embodiment" or "in an embodiment" appearing throughout this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. Furthermore, in one or more embodiments, the particular features, structures, or characteristics can be combined in any suitable manner, as will be apparent to those skilled in the art from this disclosure.

[0135] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, all of which fall within the scope of protection of this application.

Claims

1. A method for identifying hospital-acquired infections in hospitalized patients based on a large AI model, characterized in that, Includes the following steps: Construct a knowledge base of screening criteria based on infection site, clinical diagnosis, etiological diagnosis, and supplementary explanations; Collect desensitized medical data from hospitalized patients, concatenate it with prompt words, and form the input text; The large model interface is called to process the input text of hospitalized patients, and the large model performs inference based on the screening standard knowledge base. The structured data returned by the large model is analyzed to obtain infection early warning information; the infection early warning information includes: whether infected, infection site, risk level, key evidence, and cited standards.

2. The method according to claim 1, characterized in that, The process of calling the large model interface to process the input text of hospitalized patients includes: Call at least two large model interfaces through a multi-threaded program; The large model processes the input text from different hospitalized patients.

3. The method according to claim 2, characterized in that, The process of calling at least two large model interfaces through a multi-threaded program includes: The multi-threaded program starts a container, which is injected with an instance of at least one implementation class; wherein each implementation class encapsulates the calling logic of a large model; The multithreaded program obtains an instance of the implementation class from the container and calls the large model interface.

4. The method according to claim 1, characterized in that, The prompts include instructions for constraining the output format and decision logic of the large model; wherein, the instructions are at least used to limit the output of the infected site to use a predefined standardized dictionary.

5. The method according to claim 4, characterized in that, The input text is obtained by concatenating prompt word templates, which include the instructions and reserve placeholders for the desensitized diagnostic data.

6. A method for monitoring the risk of hospitalized patients with hospital-acquired infections, characterized in that, include: In response to users' monitoring needs for target hospitalized patients, obtain de-identified medical data of target hospitalized patients; The method for identifying hospital-acquired infections in hospitalized patients based on an AI large model, as described in any one of claims 1-5, is used to obtain infection early warning information; The infection warning information is presented through a visual interface for users to query.

7. A system for identifying hospital-acquired infections in hospitalized patients based on a large AI model, characterized in that, include: The knowledge base injection module is used to build a screening standard knowledge base based on infection site, clinical diagnosis, etiological diagnosis and supplementary explanation; The data acquisition module is used to collect desensitized medical data of hospitalized patients and concatenate it with prompt words to form input text; The data processing module is used to call the large model interface to process the input text of hospitalized patients. The large model processes the input text based on the screening criteria knowledge base. Reasoning; The output module is used to parse the structured data returned by the large model to obtain infection warning information; wherein, the infection warning information includes: whether infected, infection site, risk level, key evidence, and cited standards.

8. A computing device, characterized in that, include: processor, and A memory having stored program instructions thereon, which, when executed by the processor, cause the processor to perform the method for identifying hospital-acquired infection cases of hospitalized patients based on an AI large model as described in any one of claims 1 to 5.

9. A computer-readable storage medium, characterized in that, It stores program instructions, which, when executed by a computer, cause the computer to perform the method for identifying hospital-acquired infection cases of hospitalized patients based on an AI large model as described in any one of claims 1 to 5.

10. A computer program product, characterized in that, It includes program instructions that, when executed by a computer, cause the computer to perform the method for identifying hospital-acquired infection cases of hospitalized patients based on an AI large model as described in any one of claims 1 to 5.

Images