Intelligent monitoring and early warning system for medical adverse events

Abstract

The invention discloses an intelligent monitoring and early warning system for medical adverse events, and relates to the technical field of medical treatment, and the system comprises an ETL module which is used for extracting medical text data from a hospital clinical information system; the medical adverse event prediction module is used for predicting the medical text data and obtaining the medical adverse event category and grade corresponding to the medical text data; the medical adverse event prediction module comprises a medical adverse event model obtained through training; the medical adverse event model is obtained by training a medical model according to historical medical adverse event samples, and the medical adverse event model can output corresponding medical adverse event types and levels according to input medical text data; according to the medical adverse event reporting method and device, the medical adverse event reporting efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of medical technology, and in particular to an intelligent monitoring and early warning system for adverse medical events. Background Technology

[0002] Adverse medical events (including adverse medical quality events and adverse medical safety events) refer to unexpected medical-related events that occur during the medical process and may cause harm to patients. They have three main characteristics: unexpectedness (discrepancies with expected treatment outcomes), harm (causing physical or psychological damage to patients), and preventability (avoidable through system or process improvements). Therefore, establishing a reporting system for adverse medical events has dual value: on the one hand, it enables experience sharing and system improvement through proactive reporting; on the other hand, it provides a basis for continuous improvement of medical quality through data analysis.

[0003] Currently, the traditional adverse medical event reporting systems widely used in Chinese medical institutions mainly rely on the proactive reporting mechanism of clinical medical staff. However, due to the heavy workload and limited time resources on the front lines of clinical practice, as well as some medical staff's unfamiliarity with or concerns about the reporting process, the system suffers from problems such as low reporting rates and untimely information reporting in actual operation. Summary of the Invention

[0004] The purpose of this application is to provide an intelligent monitoring and early warning system for adverse medical events, which can improve the efficiency of reporting adverse medical events.

[0005] To achieve the above objectives, this application provides the following solution: This application provides an intelligent monitoring and early warning system for adverse medical events, the system comprising: The system comprises an ETL module, a hospital clinical information system, a medical adverse event prediction module, and a display module. The medical adverse event prediction module includes a trained medical adverse event model. The medical adverse event model is trained on a medical model based on historical medical adverse event samples. The medical adverse event model can output the corresponding medical adverse event category and level based on the input medical text data. The ETL module is used to extract medical text data from the hospital's clinical information system. The adverse medical event prediction module is used to predict adverse medical events from medical text data and obtain the corresponding adverse medical event categories and levels. The display module is used to output prompt information, which includes: medical text data, and the corresponding adverse medical event category and level.

[0006] According to the specific embodiments provided in this application, the following technical effects are disclosed: This application provides an intelligent monitoring and early warning system for adverse medical events. This system automatically extracts medical text data from the clinical information system via an ETL module, replacing manual collection and processing, eliminating cumbersome processes, and reducing manpower and time costs. Based on a trained adverse medical event model, it can quickly analyze the extracted data, outputting the category and level of adverse medical events, avoiding the inefficiency of manual judgment. Simultaneously, the display module can directly output prompts containing complete information, simplifying the reporting process for medical staff, eliminating the need for manual form filling and processing, avoiding reporting delays due to information lag, and significantly improving reporting efficiency and timeliness. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 This is a flowchart illustrating a method for training a medical adverse event model according to an exemplary embodiment; Figure 2 This is a schematic diagram illustrating a portion of the data content in a database according to an exemplary embodiment; Figure 3 This is a schematic diagram of the structure of a medical adverse event reporting system according to an exemplary embodiment; Figure 4 This is a schematic diagram of the push interface of a medical adverse event reporting system according to an exemplary embodiment; Figure 5 This is a schematic diagram of the reporting interface of a medical adverse event reporting system according to an exemplary embodiment; Figure 6 This is a schematic diagram of a DingTalk push notification interface for medical adverse event warning, according to an exemplary embodiment. Figure 7 This is a flowchart illustrating a medical adverse event early warning system according to an exemplary embodiment. Detailed Implementation

[0009] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0010] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0011] Figure 1 This is a flowchart illustrating a method for training a medical adverse event model according to an exemplary embodiment, such as... Figure 1 As shown, the method includes the following steps S101-S102: In step S101, a sample of historical adverse medical events is obtained; the sample of historical adverse medical events includes: a description of the adverse medical event, the true level of the adverse medical event, and the true category of the adverse medical event.

[0012] Specifically, the data covers all adverse medical events that have occurred in all hospital campuses (including inpatient departments, outpatient departments, emergency departments, operating rooms, and medical technology departments) over the past 20 years, encompassing 8 major categories and 36 subcategories, including medication errors, falls, surgical complications, medical equipment / instrument incidents, nursing-related incidents, nosocomial infections, communication problems, and medical treatment incidents.

[0013] Each data entry must include seven key fields: adverse event reporting time, adverse event occurrence time, hospital / department where it occurred, adverse event type (8 major categories and 36 subcategories, graded), adverse event process (including key diagnostic and treatment milestones and interventions), adverse event level (grades A to E), and adverse event consequences (grades I to IV). This ensures the clinical traceability and analytical value of the data. Figure 2 As shown.

[0014] Alternatively, a combination of rule-based matching (based on event time, department, and core keywords) and semantic similarity algorithms (cosine similarity threshold ≥ 0.9) can be used to eliminate duplicate reported data. For missing data in key fields such as "event consequences not labeled" and "processing results missing," supplementation can be achieved by retrospectively analyzing electronic medical records, nursing records, and departmental adverse event ledgers to ensure a core field completeness rate of ≥ 99%. A unified time format (YYYY-MM-DD) can also be used. HH:MM:SS), hospital / department naming conventions, event classification and grading coding (using the group's internal standardized coding system, such as "medical equipment / materials event - instrument / consumable quality / compliance" coded as "03-02", "C-level adverse event" coded as "03"), to ensure that the data format is uniform and calculable; multiple senior medical safety management experts can also form a review group, using the "dual independent annotation + cross-verification" model, to review the event classification, consequence grading, and level determination results; for annotation discrepancies (such as expert A judging the same event as "surgical complication" and expert B judging it as "medical treatment event"), a collective assessment is conducted in conjunction with the event process, clinical guidelines, and group classification standards to correct annotation errors and ensure annotation consistency with a Kappa value ≥ 0.85; finally, invalid data without actual clinical significance (such as test reports and misreported events) are eliminated; colloquial expressions and redundant information (such as redundant descriptions of basic patient information unrelated to the core of the event) in the event process are standardized and refined, retaining the key logical chain of "diagnosis and treatment behavior - event triggering - consequence generation - handling measures" to form a structured event description text.

[0015] Based on the high-quality data after governance, a multi-dimensional training sample set is constructed to adapt to the fine-tuning of large models, meeting the core task requirements of adverse event classification, grading, and attribution analysis.

[0016] In step S102, the medical model is trained based on historical adverse medical event samples to obtain an adverse medical event model. The adverse medical event model can output the corresponding adverse medical event category and level based on the input medical text data.

[0017] The medical model is obtained by training the original large language model using a medical knowledge base, which includes: medical professional knowledge, nursing and health education knowledge, and clinical pathways and policy documents.

[0018] Large Language Models (LLM), as a cutting-edge technological breakthrough, embodies core innovations in three aspects: a self-supervised pre-training paradigm based on massive amounts of unlabeled data, the scale effect of model parameters exceeding hundreds of billions, and the emergence of capabilities such as the Chain of Thought (CoT). In the medical field, LLM demonstrates enormous application potential: clinical decision support systems enhanced by medical knowledge graphs can improve diagnostic accuracy; medical image analysis systems based on multimodal learning can achieve automatic lesion identification; intelligent medical record generation and structuring systems can significantly reduce the burden of clinical documentation; and breakthroughs have been made in molecular property prediction and generation in the field of drug discovery. These applications are reshaping the level of intelligence in healthcare services.

[0019] While general-purpose large language models demonstrate superior performance in natural language understanding and generation tasks, their application in specific professional domains still faces significant limitations. First, the broad distribution but insufficient depth of training corpora leads to biases in understanding specialized terminology within vertical domains (such as medicine, law, and finance), making it difficult to accurately capture domain-specific semantic relationships and logical structures. Second, the lack of systematic encoding of domain-specific knowledge systems in general-purpose models makes them prone to "illusion" phenomena in scenarios involving complex reasoning, such as clinical decision support and legal interpretation. Third, the parameter scale and computational resource requirements of general-purpose models hinder efficient deployment in specialized scenarios. These limitations highlight the necessity of developing large-scale models for vertical domains: domain-enhanced pre-training (such as targeted learning from medical literature and clinical guidelines), optimized embedding of specialized terminology, and domain-specific fine-tuning strategies (such as instruction fine-tuning based on medical question-and-answer pairs) can significantly improve the accuracy and reliability of models in specialized scenarios. Taking the medical field as an example, specialized large-scale models can more accurately understand professional knowledge such as ICD coding systems and drug interactions, and show significant advantages in key applications such as electronic medical record structuring and assisted diagnosis. This domain adaptability is the key to the clinical application of medical artificial intelligence.

[0020] In one embodiment, training the original large language model includes the following steps A1-A2: A1. Create a medical knowledge base.

[0021] In creating the medical knowledge base, medical experts and artificial intelligence experts collaborated closely to ensure that the resulting knowledge base was both authoritative and reliable, as well as easy for machine computation. Firstly, it was based on specialized medical vertical models as the foundation of the system, relying on medical knowledge bases, such as the Qizhen Medical Knowledge Base. Currently, this knowledge base has successfully achieved structured processing of knowledge about common and major diseases, aggregating massive authoritative medical resources (including millions of documents, guidelines, and expert consensus), constructing a vast knowledge graph containing millions of entities and tens of millions of relationships, and completing in-depth data import across more than 10 major clinical disciplines.

[0022] Building a medical knowledge base is a systematic project that requires deep collaboration between medical experts and artificial intelligence experts to ensure that the constructed knowledge base is both authoritative and reliable, as well as easy for machine computation. The entire construction path is divided into five key stages: Phase One: Integration and Screening of Multi-Source Heterogeneous Data. This is the fundamental prerequisite for knowledge base construction. The core objective is to screen high-quality, standardized original materials from massive amounts of scattered data. Medical experts act as "quality gatekeepers," responsible for reviewing various data sources one by one, including medical textbooks, clinical guidelines, expert consensus, policy documents, and even 3D medical models. They rigorously verify the authority and accuracy of the content, for example, removing the 2010 version of the hypertension diagnosis and treatment guidelines, which has been replaced by the 2022 updated version, and discarding controversial research conclusions published in non-core journals. AI experts focused on technology implementation, designing standardized data collection architectures to unify and organize heterogeneous data from different formats and sources. For example, they converted PDF documents like the "Guidelines for the Prevention and Treatment of Type 2 Diabetes in China," Excel spreadsheets listing commonly used hospital medications, database-stored reference values ​​for routine blood tests, and image-formatted 3D cardiac anatomy models with annotations into editable and parsable structured text formats. They also assigned standardized fields to similar data, such as "generic drug name," "indications," and "dosage and administration," to avoid formatting issues. Furthermore, they collaborated with medical experts to build a data quality evaluation system, specifying indicators such as "core guideline coverage ≥ 95%," "data field missing rate ≤ 3%," and "format standardization rate 100%." ​​This ensured the integrity and format consistency of data sources from the outset, clearing obstacles for subsequent knowledge processing.

[0023] Phase Two: Medical Expert Screening and Quality Control. The core of this phase is to refine and purify the initially integrated data to enhance its clinical applicability. This phase employs a multi-level review and professional division of labor model. Medical experts, combining their clinical experience and evidence-based medicine principles, conduct in-depth screening of the data. For example, cardiology experts accurately extract core diagnostic and treatment information such as interventional treatment indications and postoperative anticoagulation protocols for coronary heart disease from the integrated cardiovascular disease data, while eliminating basic experimental data with weak relevance to clinical practice and repetitive content. To improve screening efficiency, AI experts develop targeted intelligent auxiliary screening tools. These tools perform initial filtering through keyword matching and topic classification, such as automatically categorizing "diabetes"-related data into "diagnosis," "treatment," and "complications," reducing the workload of manual sentence-by-sentence screening. Simultaneously, a dynamic expert feedback loop mechanism is established. If medical experts discover that the tool mistakenly classifies "gestational diabetes" as ordinary diabetes, they will mark the problem and provide optimization suggestions, guiding the AI ​​tool to iterate its classification rules and continuously improve the screening criteria.

[0024] The third stage: Intelligent algorithm processing and knowledge extraction. This is the core link where medical engineering experts collaborate most closely, aiming to transform unstructured text into machine-recognizable and associative knowledge fragments. Medical experts first need to build a knowledge framework, clarify medical concept ontology, and define core entities such as diseases, symptoms, drugs, and surgeries, as well as their relationships. For example, the core symptoms of "myocardial infarction" are "chest pain," "profuse sweating," and "difficulty breathing," and the indications for the corresponding treatment drug "aspirin" include "acute myocardial infarction." Afterward, medical experts also need to review the results extracted by the AI ​​algorithm, such as judging whether the algorithm's extraction of "penicillin's indications include viral colds" is biased, and promptly correcting such errors that do not conform to medical logic to ensure that the professionalism of the knowledge is not overlooked. AI experts are responsible for the technical implementation, developing specialized NLP models adapted to medical scenarios, making specific optimizations for abbreviations and synonyms such as "heart attack," designing scientific knowledge representation mechanisms, such as using triples (myocardial infarction, core symptoms, chest pain) to store relationships, optimizing the extraction accuracy and processing efficiency of algorithms, and finally working with medical experts to establish computational representation standards for medical knowledge, laying the foundation for subsequent knowledge transformation.

[0025] Phase Four: Computable Medical Knowledge Generation. The core is to transform knowledge from "textual form" to "practical form," balancing clinical applicability and machine computability. First, the knowledge extracted in the previous phase is transformed into a structured presentation. For example, a diagnostic tree is constructed for pneumonia, starting with symptoms like "fever and cough," branching to "elevated / normal / decreased white blood cell count in blood tests," and then corresponding to diagnostic directions like "bacterial pneumonia / viral pneumonia / mycoplasma pneumonia" and subsequent treatment pathways. This makes the knowledge logic clearer, facilitating quick access for clinicians and precise machine retrieval. Simultaneously, internationally recognized medical coding standards such as ICD-10 and SNOMED CT are adopted. For instance, "community-acquired pneumonia" corresponds to ICD-10 code J18.9, and "cefixime" corresponds to SNOMED CT code 76403001, ensuring the knowledge base is compatible across hospitals and systems. In this stage, medical experts focus on the clinical applicability and safety of the knowledge, reviewing whether the "alternative plan for patients allergic to cephalosporins" in the pneumonia treatment pathway is reasonable, and avoiding errors that may cause allergy risks; AI experts focus on optimizing the machine readability and computational efficiency of the knowledge, converting the pneumonia diagnosis tree into machine-executable "IF-THEN" rules, optimizing the graph database storage structure, so that the machine can complete the path matching from symptoms to diagnosis within 1 second, ensuring that the needs of both are met and do not conflict with each other.

[0026] Phase Five: Medical Expert Certification and Release. This is the final checkpoint before the knowledge base is implemented, with the core objective of ensuring its security, reliability, and iterability. Medical experts will conduct comprehensive authoritative certification, practicality verification, and security assessments. For example, experts from multiple disciplines, including respiratory medicine, cardiology, and endocrinology, will jointly review the diagnosis and treatment knowledge for common diseases in the knowledge base. Simultaneously, they will test the knowledge base in simulated clinical scenarios, inputting a case of "65-year-old male with a 5-year history of diabetes and a 3-day history of fever and cough," to verify the compliance of the recommended diagnostic procedures and medication regimens, confirming that they will not be misleading and meet clinical safety requirements. AI experts will complete system integration testing, connecting to hospital HIS and EMR systems, testing the interface compatibility between the knowledge base and electronic medical records, such as optimizing knowledge retrieval response speed to ensure doctors can instantly access medication usage and dosage information when writing medical records, while also investigating data leakage risks and ensuring stable system operation. Finally, both parties jointly developed a knowledge base usage guide, clarifying the scope of application and operational standards. They also established a long-term update mechanism, agreeing that the corresponding content of the knowledge base would be iterated within one month after the National Health Commission releases new guidelines for the clinical application of antimicrobial drugs, ensuring the timeliness and vitality of the knowledge base and providing a solid guarantee for subsequent application scenarios.

[0027] Once the knowledge base is built, it can be used to train the original large language model, giving it a professional medical knowledge background to better complete various tasks in the vertical field.

[0028] The completed knowledge base comprises three parts: medical professional knowledge, nursing and health education, and clinical pathways and policy documents. The medical professional knowledge section includes knowledge from basic medicine, clinical medicine, and pharmacy, covering 130,000 drug-related items and drug instructions, over 10,000 disease-related items, over 20,000 guideline documents, over 4,000 surgical procedures, over 2,000 laboratory tests, over 2,000 assessment forms, and millions of doctor-patient Q&A data points. The nursing and health education section includes nursing professional knowledge, health education content, and medication guidance. The clinical pathways and policy documents section contains clinical medical pathways and over 150 policy documents from national medical management departments.

[0029] A2. A medical model is obtained by training the original large language model based on the medical knowledge base.

[0030] The original large language model here incorporates knowledge distillation and Chain of Thought (COT) techniques. The core training objective is to enable the lightweight model to learn the reasoning logic and professional expressions of authoritative medical knowledge, while maintaining model deployment efficiency.

[0031] The following example, "Indications for Aspirin," will be used to explain the specific process of knowledge distillation and COT technology.

[0032] Using COT technology, the original large language model is able to solve the problem step by step.

[0033] The output (soft label) of the teacher model is: [Reasoning Path] Aspirin is a nonsteroidal anti-inflammatory drug (NSAID) with antipyretic and analgesic effects. It can also inhibit platelet aggregation and prevent thrombosis. Furthermore, it has applications in anti-inflammatory and antirheumatic purposes.

[0034] [Conclusion (Soft Labeling)] Aspirin is used for antipyretic analgesia, anti-inflammatory and antirheumatic purposes, and antiplatelet aggregation.

[0035] The output (hard labels) of the student model is: [Reasoning Path] Aspirin can relieve pain and reduce fever, and it also has anti-inflammatory properties.

[0036] [Conclusion (Hard Label)] Aspirin is used to relieve fever, pain, and inflammation.

[0037] Training is conducted to address the differences between the outputs of the teacher and student models. The goal of training is to make the student model as close as possible to the teacher model, including soft and hard label alignment, inference path alignment, and feature alignment.

[0038] For soft and hard label alignment, the KL divergence of the softmax confidence values ​​of the soft and hard labels is calculated and used as the loss function to measure the difference between the soft and hard labels. Its expression is: ; ; ; Where TeacherLogits is the dictionary confidence vector output by the teacher model, StudentLogits is the dictionary confidence vector output by the student model, and KL() is the formula for calculating KL divergence.

[0039] Inference path alignment refers to aligning the attention of the models. The calculation involves the attention matrices output by the teacher and student models, measured by mean squared error. Its expression is: ; Where MSE() is the square of the difference between the two matrices, TeacherAttention is the attention matrix output by the teacher model, and StudentAttention is the attention matrix output by the student model.

[0040] Feature alignment refers to aligning the feature values ​​of the hidden layers between the teacher and student models. The difference between them is also measured using MSE(), and its calculation expression is as follows: ; Where TeacherHidden[6] represents the feature value matrix of the 6th hidden layer in the teacher model, and StudentHidden[6] represents the feature value matrix of the 6th hidden layer in the student model. The aligned hidden layers can be selected by the user and are hyperparameters that need to be set according to the actual situation during training.

[0041] Finally, considering all the alignment conditions mentioned above, the total loss function is: ; in, It is the cross-entropy between the labels generated by the student model and the real labels.

[0042] After being trained with a medical knowledge base, the medical model has acquired a certain level of general medical knowledge background.

[0043] To improve performance in the adverse events vertical, we will further refine the system using an adverse events knowledge base.

[0044] In one embodiment, training the medical model based on historical adverse medical event samples to obtain an adverse medical event model includes the following sub-steps S1021-S1025: S1021. The sample adverse medical events are described and encoded to obtain the word vectors corresponding to the sample adverse medical events.

[0045] Assuming the adverse medical event in the sample is described as "the utility of ibuprofen", the text must first be encoded. This process is accomplished by querying an encoding vocabulary. In the vocabulary, each word corresponds to a number. By querying the vocabulary, the question "the utility of ibuprofen" may be divided into three words: "ibuprofen", "of", and "utility", thus forming a three-dimensional word vector e=[36, 11, 79].

[0046] S1022. Input the word vectors into the feature calculation layer of the medical model to extract features from the word vectors through the self-attention mechanism, thereby obtaining the feature vectors representing adverse medical events of the sample.

[0047] In one embodiment, the feature vector of sample adverse medical events is obtained using the following formula: ; in, These are three learnable mapping matrices. It is a key vector The length of d is given by Attention, which is a feature vector of length d, where d is a hyperparameter of the medical model, and e represents a word vector.

[0048] During training, a LoRA module is added to the feature calculation layer. The LoRA module is used to add a low-rank decomposition matrix to the original weights of the feature calculation layer. During training, only the LoRA module is trained.

[0049] To avoid redundant calculations in full parameter fine-tuning, the LoRA technique is employed. For the original weight matrix... Introducing low-rank decomposition matrix and The update rules are as follows: ; During training, only A and B are optimized, while the original weights W are frozen. This method reduces the number of parameters to r(d+k), significantly reducing GPU memory usage.

[0050] S1023. Input the feature vector into the classification fully connected layer of the medical model, and output the predicted probability of the sample adverse medical event belonging to each adverse medical event category.

[0051] In one embodiment, the feature vector is input into the classification fully connected layer of the medical model to obtain a categorical logistic regression vector, which is composed of the initial category prediction probabilities of the sample medical adverse event belonging to each medical adverse event category; the softmax function is applied to the categorical logistic regression vector to obtain the category prediction probabilities of the sample medical adverse event belonging to each medical adverse event category.

[0052] , Let c represent the predicted probability of the c-th initial category in the logistic regression vector of the categorical adverse events of the i-th sample.

[0053] S1024. Input the feature vector into the hierarchical fully connected layer of the medical model, and output the level prediction probability of the sample medical adverse event belonging to each medical adverse event level.

[0054] In one embodiment, the feature vector is input into the hierarchical fully connected layer of the medical model to obtain the hierarchical logistic regression vector, which is composed of the initial level prediction probability of the sample medical adverse event belonging to each medical adverse event level; the softmax function is applied to the hierarchical logistic regression vector to obtain the level prediction probability of the sample medical adverse event belonging to each medical adverse event level. , This represents the predicted probability of the m-th initial level in the logistic regression vector of the level of the medical adverse event of the i-th sample.

[0055] Remove the original language modeling head from the medical model and replace it with a fully connected layer that matches the number of classification categories. Let the number of categories be C, and the hidden layer dimension be d, then the parameters of the new classification layer are... , bias is The forward propagation formula is: ; The calculated logits are the final logistic regression vector, and the length of the vector is the total number of categories. In this task, the classification task follows a classification system that divides adverse events into 8 major categories and 36 subcategories, so the length of the logits vector is 36.

[0056] S1025. The medical model is trained based on the predicted probability of category, the predicted probability of level, and the true level and true category of the sample medical adverse events to obtain the medical adverse event model.

[0057] In one embodiment, the loss function for training the medical model based on the predicted probability of the category and the true category of the sample adverse medical events is: ; Where N represents the number of samples, and C represents the total number of medical adverse event categories. Let represent the predicted category probability that the i-th adverse medical event belongs to the c-th adverse medical event category. Let represent the true probability that the true category of the i-th sample adverse medical event belongs to the c-th adverse medical event category. When the true category of the i-th sample adverse medical event is the c-th adverse medical event category... =1, otherwise =0; In one embodiment, the loss function for training the medical model based on the predicted probability of the level and the true level of the sample adverse medical events is: ; Where N represents the sample size, and M represents the total number of adverse medical event grades. This represents the predicted level of the medical adverse event in the i-th sample, which belongs to the m-th medical adverse event category. Let represent the true probability that the true level of the i-th sample adverse medical event belongs to the m-th adverse medical event level. When the true level of the i-th sample adverse medical event belongs to the m-th adverse medical event level... =1, otherwise =0.

[0058] At this point, the adverse event model has been trained and is ready for use. The model will be used to process clinically generated medical data, such as electronic medical records, laboratory reports, and nursing pathways, to identify potential adverse event risks.

[0059] This disclosure provides a training method for a medical adverse event model. The method includes: acquiring a historical sample set containing event description text, actual adverse event levels, and actual adverse event categories; training a preset model using the historical sample set to obtain a trained medical adverse event model. The model is configured to automatically output the corresponding adverse event category and adverse event level based on input medical text data. In the application phase, the trained medical adverse event model receives automatically extracted medical text data and outputs the adverse event category and level corresponding to the medical text, thereby significantly improving the efficiency of medical adverse event reporting, replacing the traditional manual judgment process based on standards, and reducing reporting delays and omissions caused by clinicians' unfamiliarity with the judgment standards or their busy schedules.

[0060] In one embodiment, the above training process is completed by the training module of the medical adverse event reporting system.

[0061] Figure 3 This is a schematic diagram illustrating the structure of a medical adverse event reporting system according to an exemplary embodiment, such as... Figure 3 As shown, the system includes: The system comprises an ETL module, a hospital clinical information system, a medical adverse event prediction module, and a display module, wherein the medical adverse event prediction module includes a medical adverse event model trained by the method described in any of the above embodiments. The ETL module is used to extract medical text data from the hospital's clinical information system. The adverse medical event prediction module is used to predict adverse medical events from medical text data and obtain the corresponding adverse medical event categories and levels. The display module is used to output prompt information, which includes: medical text data, and the corresponding adverse medical event category and level.

[0062] For example, the ETL module can extract medical text data from the hospital's clinical information system according to a preset cycle.

[0063] In one embodiment, the system further includes a detection module, which is used to detect medical text data whose predicted adverse medical event categories and levels meet preset requirements; and to send the medical text data to a display module so that the medical text data included in the prompt information output by the display module meets the preset requirements.

[0064] For example, the output of a medical adverse event model includes: Original medical text data (such as medical records, doctor's orders, laboratory reports, nursing records, etc.); The model predicts the categories of adverse medical events (such as medication errors, infusion reactions, falls, bed falls, hospital-acquired infections, etc.). The model predicts the event level (e.g., Level I / Special (Major), Level II (Serious), Level III (Moderate), Level IV (Minor), etc., with specific level classification based on hospital / industry standards).

[0065] Preset requirements are the system's pre-configured screening rules / thresholds, which can be flexibly set according to hospital management needs and clinical scenarios. They primarily include two categories: Level threshold requirements: Only retain events that reach or exceed the preset level (e.g., only push level II and above serious adverse events, filter level IV minor events, and reduce medical staff interference). Category matching requirements: Only retain the preset event categories of interest (such as focusing on monitoring medication errors and surgical complications, and temporarily excluding non-critical categories); The detection module compares the "event category + level" output by the model with the "preset requirements" one by one, and the judgment results are divided into two categories: If the preset requirements are met, proceed to the next step of the push notification process; If the preset requirements are not met: filter directly (can be saved to the system log for model iteration / post-event review, but not pushed to the clinical information system).

[0066] The detection module sends the filtered medical text data to the display module.

[0067] Data content: The push notification is not a simple "warning conclusion," but rather medical text data containing complete information, including: Patient basic information (anonymized / desensitized to meet medical data security requirements); Original medical documents (such as abnormal medical orders, abnormal test results, and key descriptions in nursing records); The event categories and levels predicted by the model; The screening criteria for the detection module (e.g., "meeting the preset requirements for Level II or above serious events").

[0068] The medical adverse event reporting system disclosed herein is a closed-loop system designed based on the entire process of "data acquisition - intelligent analysis - result output." Its core consists of three main components: an ETL module, a hospital clinical information system, and a medical adverse event model. These three components work together to automatically identify adverse events from clinical data, accurately determine their category and severity, and output early warning prompts to clinical settings, thus completely changing the traditional passive management model that relies on manual reporting.

[0069] Extract-Transform-Load (ETL) is a core technology in data warehouse construction. This system uses a customized ETL process to transform clinical data from its "raw state" to its "analyzable state".

[0070] The hospital's clinical information system includes: electronic medical record (EMR), laboratory information management system (LIS), medical image archiving and communication system (PACS), and nursing information system (NIS).

[0071] In this disclosure, each scheduled task only extracts data that has changed (added, modified, or deleted) since the last extraction operation, significantly reducing the amount of data processed. This is key to building an efficient and sustainable ETL process. Incremental extraction relies on change data capture technology, which depends on elements such as timestamps, triggers, and logs. After each extraction, the data needs to be transformed. This stage is the core of the ETL process, responsible for cleaning and processing the extracted raw data, transforming it into data that meets the quality and format requirements of the target data warehouse. Its most important function is data cleaning, ensuring that only "compliant" data can enter the target system. Operations during the transformation process include data cleaning, format standardization, and data integration. The transformed data will be loaded into a medical adverse event model for processing.

[0072] Specific workflow: Step 1: Data Extraction. Based on an incremental extraction mechanism, this step extracts only newly added, modified, or deleted medical text data (such as new nursing records and updated test reports) from various subsystems of the hospital's clinical information system (EMR, LIS, PACS, etc.) since the last extraction, rather than extracting the entire dataset. This significantly reduces data processing volume and system overhead. Extracted data types include unstructured text (such as progress notes in electronic medical records and event descriptions in nursing documentation) and semi-structured data (such as indicator names and results in test reports), ensuring data coverage of the core scenarios required for adverse event identification.

[0073] The second step, data transformation, is the core of the ETL module. It focuses on resolving issues such as inconsistent formats, redundant information, and varying quality of the original data. Specifically, it includes: Data cleaning: Remove invalid data (such as test records and duplicate data entries) and correct erroneous data (such as incorrect time format and incorrect spelling of department names); Format standardization: unify the format of heterogeneous data exported from different systems, such as unifying the time format to "YYYY-MM-DD HH:MM:SS", unifying the department naming convention (e.g., correcting "Gastrointestinal Material" to "Gastroenterology Department"), and converting unstructured text into a string format that the model can recognize; Data integration: Merging related data from different systems (such as linking the electronic medical record text of the same patient with medication records to form complete diagnosis and treatment scenario data) to ensure the relevance and integrity of the data.

[0074] Step 3: Data Loading. The converted standardized medical text data is loaded into the input layer of the adverse event model as needed, providing "clean, uniform, and usable" data input for the model's predictive analysis, ensuring that the model can efficiently identify adverse event characteristics in the data.

[0075] Core functions of the medical adverse event model: Adverse event feature extraction: Through the self-attention mechanism built into the model (Attention calculation logic as described in the claim), key features of adverse events are extracted from medical text data, including event triggering behavior (such as "cloth clamp breakage", "patient falls", "unplanned readmission"), event impact range (such as "not affecting patients", "patient develops infection symptoms"), etc. Category and grade prediction: Based on the extracted features, combined with the 8 major categories and 36 subcategories of adverse events learned by the model training (such as medical equipment / instrument events, surgery / operation related events, nursing events, etc.), and the consequence grading standards from Grade A (potential events) to Grade E (serious adverse events), the adverse event category and grade corresponding to the input data are accurately determined. Prediction results output: The determined "adverse event category + level" is correlated with the original medical text data to form a complete analysis result, and feedback is provided.

[0076] Specifically, the system workflow is as follows: 1. Data collection phase: The hospital's clinical information system generates and stores various medical data (such as electronic medical records and nursing records) during the patient's diagnosis and treatment process in real time. 2. Data preprocessing stage: The ETL module starts incremental extraction at a preset period (e.g., every 15 minutes) to extract newly added medical text data from the hospital's clinical information system. After cleaning, standardization, and integration, the data is loaded into the medical adverse event model. 3. Intelligent Analysis Stage: The medical adverse event model predicts the input standardized data, automatically identifies whether there are adverse events in the data, and outputs the corresponding event category (such as "medical equipment / instrument event - device / consumable quality / compliance") and level (such as "level C adverse event"). 4. Early Warning Output Stage: The output module receives the analysis results fed back by the model and generates a prompt message containing "original medical text data + adverse event category + level". This message is pushed to relevant personnel (such as department directors and quality control specialists) through system pop-ups, DingTalk push, etc., to remind them to handle the situation in a timely manner. 5. Follow-up coordination: Relevant personnel should review the notification information and conduct the review according to the procedure (as shown in the attached document). Figure 2 The review page shown), handling and rectification, and the handling results can feed back into the model for continuous optimization (such as using the reasons for invalidating cases for model iteration), forming a closed-loop management of "monitoring-early warning-handling-optimization".

[0077] In one embodiment, it also includes: The display module is used to receive reporting instructions triggered by the user and report medical text data, as well as the corresponding adverse medical event categories and levels, according to the reporting instructions.

[0078] After the display module outputs a prompt message, the user can choose whether to report the adverse medical events detected by the system.

[0079] Figure 4 This is a schematic diagram of the display interface of a medical adverse event reporting system according to an exemplary embodiment, such as... Figure 4 As shown, the platform scans clinical medical data to identify potential adverse events. All discovered adverse events will be compiled on this page for review by auditors. In the review menu, auditors simply need to select "Approve" or "Cancel" to complete the review. If "Cancel" is selected, a reason for cancellation must be entered for subsequent large-scale model optimization. After selecting "Approve," selecting "Submit and Proceed to Reporting Page" will automatically redirect the system to... Figure 5 The reporting page shown ( Figure 5 The large model in this disclosure refers to the adverse medical event model. This completes the subsequent reporting process. Figure 5 On the reporting interface, in the "Event Process" dialog box, enter a description of the adverse event's occurrence. Then click "AI Generate Event Classification and Consequences" to obtain the AI-generated adverse event classification and consequences. A pop-up window will display the AI ​​event classification results. Reviewers can select the event classification and consequences, and then click "Report" to submit the report to the Quality Improvement Office. To ensure the accuracy of the AI ​​model, the platform will push the most likely judgments and append a statement of credibility to each result for reference.

[0080] In one embodiment, such as Figure 6 As shown, this is a DingTalk notification for adverse medical event alerts. After the system detects an adverse medical event, it will push the relevant information to the responsible personnel via DingTalk for review.

[0081] This disclosure addresses the problems of traditional medical quality (safety) adverse event reporting systems, such as passive reliance on manual clinical reporting, poor reporting rates, and inadequate timeliness. It proposes a novel solution integrating proactive monitoring technology and intelligent data management, focusing on solving two core issues: First, it constructs a specialized database for the medical safety field and performs domain adaptation and fine-tuning on a large-scale pre-trained language model. Through systematic collection, cleaning, and annotation of historical and real-time adverse event data, a high-quality, multimodal training sample set is formed to support the model's accurate extraction, classification, and attribution analysis of risk events in medical texts. This provides a reliable data foundation and algorithmic support for intelligent early warning, causal analysis, and prevention and control strategy generation for adverse events. Second, it achieves automated, real-time proactive monitoring of potential adverse events during the medical process. It continuously scans and intelligently identifies heterogeneous medical data such as electronic medical records, nursing documents, and laboratory reports, effectively reducing reliance on manual reporting by clinical medical staff and improving the sensitivity and timeliness of adverse event detection.

[0082] This disclosure ultimately forms an intelligent system that integrates monitoring, early warning, and decision support. Clinically validated, it can shorten the response time for adverse event identification by 60% and achieve an early warning accuracy rate of over 85%, significantly improving the scientific nature and forward-looking nature of medical quality management.

[0083] The final closed-loop management system will achieve fully automated management of the entire process, from data collection, risk identification, tiered early warning, to treatment feedback. It will also continuously optimize the early warning algorithm through reinforcement learning, providing intelligent support for clinical decision-making. The overall flowchart of this disclosed solution is shown below. Figure 7 As shown: Step 1: Medical knowledge injection training (constructing QiZhenGPT-Base).

[0084] Medical experts have added annotations: The content of the "Qizhen Medical Knowledge Base + Medical Standard Dataset" has been manually reviewed and annotated to ensure the clinical professionalism of the knowledge. Medical knowledge training data: Knowledge and data annotated by experts are organized into training corpora that can be read by the model; Medical knowledge injection training: Based on Qwen (Tongyi Qianwen), knowledge injection is performed using the above training corpus (combining knowledge distillation and thought chain technology) to obtain QiZhenGPT-Base (a lightweight model with basic medical knowledge).

[0085] Step Two: Data distillation for medical applications: screening suitable data from adverse events, ATPS, and teaching assistants; Medical Education Scenario Reasoning Data (COT): Extract medical education data and organize it into a "problem-reasoning-conclusion" thinking chain (COT) format, and inject clinical reasoning logic; Enhanced medical reasoning ability (ds-r1 ability distillation): Using DeepSeek (ds-r1) as the teacher model, its medical reasoning ability is transferred to QiZhenGPT-Base to obtain QiZhenGPT.

[0086] Step 3: Train QiZhenGPT using the adverse event knowledge base.

[0087] Step four: Obtain the adverse event agent.

[0088] Step 5: Implement on the monitoring and early warning platform ETL data is extracted from the clinical ODS database to extract medical text data. The medical text data is then input into the adverse event agent to detect whether there are any adverse medical events in the medical text data, as well as the corresponding adverse event categories and grades. Finally, the extracted adverse medical events are output through the monitoring and early warning platform.

[0089] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0090] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A medical adverse event intelligent monitoring and early warning system, characterized in that, The system includes: The system comprises an ETL module, a hospital clinical information system, a medical adverse event prediction module, and a display module. The medical adverse event prediction module includes a trained medical adverse event model. The medical adverse event model is trained on a medical model based on historical medical adverse event samples. The medical adverse event model can output the corresponding medical adverse event category and level based on the input medical text data. The ETL module is used to extract medical text data from the hospital's clinical information system. The adverse medical event prediction module is used to predict adverse medical events from medical text data and obtain the corresponding adverse medical event categories and levels. The display module is used to output prompt information, which includes: medical text data, and the corresponding adverse medical event category and level.

2. The system according to claim 1, characterized in that, Also includes: The display module is also used to receive reporting instructions triggered by the user, and to report medical text data, as well as the corresponding adverse medical event categories and levels, according to the reporting instructions.

3. The system according to claim 1, characterized in that, Also includes: Detection module; The detection module is used to detect medical text data whose predicted adverse medical event categories and levels meet preset requirements, and sends the medical text data that meets the preset requirements, along with the corresponding adverse medical event categories and levels, to the display module. The display module is used to output prompt information, which includes: preset medical text data, and the category and level of the medical adverse event corresponding to the medical text data.

4. The system according to claim 1, characterized in that, Also includes: Training module; The training module is used to acquire historical adverse medical event samples; The historical adverse medical event sample includes: a description of the sample adverse medical event, the true level of the sample adverse medical event, and the true category of the sample adverse medical event; The medical adverse event model is obtained by training the medical model based on historical adverse medical event samples.

5. The system according to claim 4, characterized in that, In the aspect of training a medical model based on historical adverse medical event samples to obtain an adverse medical event model, the training module is specifically used for: The sample adverse medical events are described and encoded to obtain the word vectors corresponding to the sample adverse medical events. Word vectors are input into the feature calculation layer of the medical model to extract features from the word vectors through a self-attention mechanism, thereby obtaining feature vectors that represent adverse medical events in the sample. The feature vector is input into the classification fully connected layer of the medical model, and the output is the predicted probability of the sample medical adverse event belonging to each medical adverse event category. The feature vector is input into the hierarchical fully connected layer of the medical model, and the output is the level prediction probability of the sample medical adverse event belonging to each level of medical adverse event. The medical model is trained based on the predicted probability of category, the predicted probability of level, and the true level and true category of the sample medical adverse events to obtain the medical adverse event model.

6. The system according to claim 5, characterized in that, The loss function used when training the medical model based on the predicted probability of categories and the true categories of sample adverse medical events is: ； Where N represents the number of samples, and C represents the total number of medical adverse event categories. Let represent the predicted category probability that the i-th adverse medical event belongs to the c-th adverse medical event category. Let represent the true probability that the true category of the i-th sample adverse medical event belongs to the c-th adverse medical event category. When the true category of the i-th sample adverse medical event is the c-th adverse medical event category... =1, otherwise =0; The loss function used to train the medical model based on the predicted probability of the level and the true level of the sample adverse medical events is: ； Where N represents the sample size, and M represents the total number of adverse medical event grades. This represents the predicted level of the medical adverse event in the i-th sample, which belongs to the m-th medical adverse event category. Let represent the true probability that the true level of the i-th sample adverse medical event belongs to the m-th adverse medical event level. When the true level of the i-th sample adverse medical event belongs to the m-th adverse medical event level... =1, otherwise =0.

7. The system according to claim 6, characterized in that, In the aspect of inputting feature vectors into the classification fully connected layer of the medical model to predict the class probability of the output sample medical adverse events belonging to each medical adverse event category, the training module is specifically used for: The feature vector is input into the classification fully connected layer of the medical model to obtain the category logistic regression vector, which is composed of the initial category prediction probability of the sample medical adverse event belonging to each medical adverse event category; Applying the softmax function to the logistic regression vector of the categories yields the predicted probability of the sample medical adverse events belonging to each category of medical adverse events; in, , Let c represent the predicted probability of the c-th initial category in the logistic regression vector of the categorical adverse events of the i-th sample.

8. The system according to claim 7, characterized in that, In the aspect of inputting feature vectors into the hierarchical fully connected layer of the medical model to predict the probability of the output sample medical adverse events belonging to each level of medical adverse event, the training module is specifically used for: The feature vector is input into the hierarchical fully connected layer of the medical model to obtain the hierarchical logistic regression vector, which is composed of the initial level prediction probability of the sample medical adverse event belonging to each medical adverse event level. Applying the softmax function to the logistic regression vector of the grades, the predicted probability of the sample adverse medical event belonging to each adverse medical event grade is obtained; in, , This represents the predicted probability of the m-th initial level in the logistic regression vector of the level of the medical adverse event of the i-th sample.

9. The system according to claim 8, characterized in that, The medical model is obtained by training the original large language model using a medical knowledge base, which includes: medical professional knowledge, nursing and health education knowledge, and clinical pathways and policy documents.

10. The system according to claim 9, characterized in that, In the aspect of inputting word vectors into the feature calculation layer of the medical model to extract features from the word vectors through a self-attention mechanism to obtain feature vectors representing adverse medical events in the samples, the training module is specifically used for: The feature vector of adverse medical events in the sample is obtained using the following formula: ； in, These are three learnable mapping matrices. It is a key vector The length of d is given by Attention, which is a feature vector of length d, where d is a hyperparameter of the medical model, and e represents a word vector.

Images