Generation system and generation method of medical advice of medicine

Abstract

The invention provides a medicine advice generation system and a medicine advice generation method, the system determines the scene type of the current doctor advice recommendation scene, responds to the scene type to recommend the emergency doctor advice, and according to the diagnosis identification result, the image detection data, the physiological index detection data and the call recording data of the target patient, the medical advice is recommended to the emergency doctor advice. Determining recommended drug advices according to the scene type, recommending the chronic disease advices in response to the scene type, determining the recommended drug advices according to the diagnosis and identification result of the target patient and the basic information of the patient in combination with a pre-constructed graph database, and further determining diagnosis and treatment actions according to the diagnosis and identification result and the basic information of the patient. The diagnosis and treatment actions and the evidence labels are used as auxiliary judgment information and are sent to a doctor end together with the recommended medicine advice, so that doctor advice recommendation is realized, the problems of low doctor seeing efficiency of patients, heavy workload of doctors and the like can be solved, human decision errors are reduced, and the doctor experience is improved. And the accuracy and rationality of drug recommendation are ensured.

Description

Technical Field

[0001] This application relates to the field of diagnostic assistance technology, and particularly to a drug order generation system and a drug order generation method. Background Art

[0002] In recent years, with the rapid development of artificial intelligence technology, intelligent tools have been gradually introduced in the medical field to improve the diagnosis and treatment efficiency and accuracy.

[0003] However, current medical information systems mostly focus on single scenarios, such as consultation robots, resulting in the following problems: the patient visit process is cumbersome, and the workload of doctors is too heavy, especially in time-consuming links such as order formulation, leading to low overall efficiency. In particular, the treatment time of critically ill patients may be delayed. Summary of the Invention

[0004] In view of the above defects or deficiencies in the prior art, this application aims to provide a drug order generation system and a drug order generation method to solve problems such as low patient visit efficiency and heavy doctor workload in the prior art, improve the quality of medical services, reduce human errors and optimize resource allocation.

[0005] An embodiment of this application provides a drug order generation system, which includes a scenario determination module, an emergency treatment module, a chronic disease treatment module, an auxiliary information determination module, and an order push module, where:

[0006] The scenario determination module is used to determine the scenario type of the current order recommendation scenario;

[0007] The emergency treatment module is used to respond to the emergency order recommendation of the scenario type, and determine the recommended drug order of the target patient according to the diagnosis result, imaging detection data, physiological index detection data, and call recording data of the target patient;

[0008] The chronic disease treatment module is used to respond to the chronic disease order recommendation of the scenario type, and determine the recommended drug order of the target patient according to the diagnosis result, basic patient information, and a pre-constructed graph database, where the graph database describes the conflict relationship and combination relationship between drugs;

[0009] The auxiliary information determination module is used to determine the treatment action according to the diagnosis result and the basic patient information, and determine the evidence label corresponding to the drug in the recommended drug order, and use the treatment action and the evidence label as auxiliary judgment information;

[0010] The order push module is used to send the recommended drug order and the auxiliary judgment information to the doctor side.

[0011] Optionally, the emergency treatment module includes a disease recommendation unit, a symptom recommendation unit, and an order recommendation unit, where:

[0012] A disease recommendation unit, which is used to determine the disease recommended medication information of the target patient according to the diagnosis result, imaging detection data, and physiological index detection data;

[0013] A symptom recommendation unit, which is used to determine the symptom recommended medication information of the target patient according to the call recording data and physiological index detection data;

[0014] A medical order recommendation unit, which is used to determine the recommended drug medical order of the target patient based on the disease recommended medication information and the symptom recommended medication information.

[0015] Optionally, the disease recommendation unit is specifically used for:

[0016] Determine the disease sub-classification of the target patient according to the diagnosis result and imaging detection data;

[0017] Determine each recommended drug according to the disease sub-classification, and determine the priority corresponding to each recommended drug based on the physiological index detection data, so as to obtain the disease recommended medication information.

[0018] Optionally, the symptom recommendation unit is specifically used for:

[0019] Input the call recording data into a pre-trained symptom extraction model to obtain key symptom description information, where the symptom extraction model is a compressed lightweight model;

[0020] Judge whether the physiological index detection data is consistent with the key symptom description information. If so, determine the symptom recommended medication information based on the key symptom description information.

[0021] Optionally, the chronic disease processing module includes an initial medical order generation unit, a risk index determination unit, and a medical order generation unit, where:

[0022] The initial medical order generation unit is used to generate the initial drug medical order of the target patient according to the diagnosis result and the conflict relationship and combination relationship between drugs in the graph database;

[0023] The risk index determination unit is used to input the initial drug medical order and the patient's basic information into a pre-trained risk prediction model to obtain the patient usage risk index corresponding to the initial drug medical order;

[0024] The medical order generation unit is used to adjust the drugs in the initial drug medical order according to the patient usage risk index, and adjust the dosage corresponding to the drugs in the initial drug medical order according to the patient's basic information, so as to obtain the recommended drug medical order.

[0025] Optionally, the system further includes a graph construction module, and the graph construction module is specifically used for:

[0026] Obtain the usage instruction documents of each drug and the drug combination records in real historical medical records;

[0027] For each usage instruction document, extract the conflicting drugs and co-administered drugs associated with the corresponding drug from the usage instruction document;

[0028] Construct a graph database based on the conflicting drugs and co-administered drugs associated with each drug;

[0029] Determine the actual co-administered drugs of each drug based on the drug combination records, and update the graph database according to the actual co-administered drugs of each drug.

[0030] Optionally, the system further includes a nutritional assistance medical order module, and the nutritional assistance medical order module is specifically used for:

[0031] Determine the inventory status of each nutritional drug;

[0032] Determine the nutritional assistance medical order for the target patient according to the diagnosis result and the inventory status;

[0033] Based on the physiological index detection data and the upper and lower limits corresponding to each preset physiological index, determine the risk physiological index among the preset physiological indexes, and determine the prohibited nutritional components corresponding to the risk physiological index;

[0034] If the nutritional assistance medical order contains prohibited nutritional components, update the nutritional assistance medical order based on the diagnosis result, the inventory status, and the prohibited nutritional components.

[0035] Optionally, the system further includes a medical order feedback module, and the medical order feedback module is used for:

[0036] In response to receiving the medical order veto signal feedback from the doctor side, obtain the veto reason text corresponding to the recommended drug medical order;

[0037] Determine the recommended drug medical order as a negative sample, and determine the problem type of the recommended drug medical order according to the veto reason text;

[0038] Write the recommended drug medical order into the database corresponding to the problem type, where the database is used for reinforcement learning of the model related to the problem type.

[0039] Optionally, the system further includes a dynamic optimization module, and the dynamic optimization module is used for:

[0040] In response to receiving the medical order usage signal feedback from the doctor side, associate and store the recommended drug medical order with the patient's basic information, and determine the dynamic medical order optimization conditions corresponding to the target patient according to the recommended drug medical order and the patient's basic information;

[0041] In response to detecting the real-time physiological data of a target patient, determine whether the target patient meets the dynamic medical order optimization condition based on the real-time physiological data. If so, adjust the recommended drug medical order based on the real-time physiological data.

[0042] An embodiment of the present application further provides a method for generating a drug medical order, including:

[0043] Determine the scene type of the current medical order recommendation scene;

[0044] In response to the scene type being an emergency medical order recommendation, determine the recommended drug medical order of the target patient according to the diagnosis result, imaging detection data, physiological index detection data, and call recording data of the target patient;

[0045] In response to the scene type being a chronic disease medical order recommendation, determine the recommended drug medical order of the target patient according to the diagnosis result, patient basic information, and a pre-constructed graph database, where the graph database describes the conflict relationship and combination relationship between drugs;

[0046] Determine the diagnosis and treatment actions according to the diagnosis result and patient basic information, and determine the evidence labels corresponding to the drugs in the recommended drug medical order. Use the diagnosis and treatment actions and evidence labels as auxiliary judgment information;

[0047] Send the recommended drug medical order and the auxiliary judgment information to the doctor terminal.

[0048] An embodiment of the present application further provides an electronic device, which includes:

[0049] A processor and a memory;

[0050] The processor is used to execute the steps of the method for generating a drug medical order provided in any embodiment of the present application by calling the program or instruction stored in the memory.

[0051] An embodiment of the present application further provides a computer-readable storage medium, which stores a program or instruction, and the program or instruction enables a computer to execute the steps of the method for generating a drug medical order provided in any embodiment of the present application.

[0052] In summary, the present application proposes a drug order generation system. The system determines the scenario type of the current order recommendation scenario. In response to the scenario type being an emergency order recommendation, based on the diagnosis result, imaging test data, physiological index test data, and call recording data of the target patient, it determines the recommended drug order for the target patient. In response to the scenario type being a chronic disease order recommendation, based on the diagnosis result of the target patient and the patient's basic information, combined with a pre-constructed graph database describing the conflict and combination relationships between drugs, it determines the recommended drug order for the target patient. Furthermore, based on the diagnosis result and the patient's basic information, it determines the treatment actions, and determines the evidence tags corresponding to the drugs in the recommended drug order. It sends the treatment actions and evidence tags as auxiliary judgment information, together with the recommended drug order, to the doctor's terminal to achieve order recommendation, which can quickly assist doctors in making treatment decisions, improve the efficiency of treatment decisions, and in scenarios with a large number of patients waiting for treatment, it can solve problems such as low patient treatment efficiency and heavy doctor workload, improve the quality of medical services, reduce human decision-making errors, optimize resource allocation. Moreover, the system sends the treatment actions and evidence tags as auxiliary judgment information to the doctor, which can help the doctor quickly judge whether the recommended drug order is reasonable and further ensure the correctness of the recommended drug order. In addition, the system divides the scenarios into emergency order recommendation and chronic disease order recommendation, and adopts corresponding order determination strategies for different scenarios, which can combine the order recommendation requirements in different scenarios to achieve accurate order recommendation and further ensure the reasonableness of the recommended drug order. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the following will briefly introduce the drawings required for use in the description of the specific embodiments or the prior art. Obviously, the following drawings are some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0054] Figure 1 It is a schematic structural diagram of a drug order generation system provided by an embodiment of the present application;

[0055] Figure 2 It is a flowchart of a drug order generation method provided by an embodiment of the present application;

[0056] Figure 3 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0057] The present application will be further described in detail below with reference to the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the related invention, rather than limiting the invention. Additionally, it should be noted that for ease of description, only the parts related to the invention are shown in the drawings.

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

[0059] As mentioned in the background art, in view of the problems in the prior art, the embodiments of the present application provide a drug order generation system, and this system is applicable to the drug order generation method provided by the embodiments of the present application.

[0060] Embodiment 1:

[0061] Figure 1 is a schematic structural diagram of a drug order generation system provided by the embodiments of the present application. As Figure 1 shown, the drug order generation system provided by the embodiments of the present application includes a scenario determination module 110, an emergency treatment module 120, a chronic disease treatment module 130, an auxiliary information determination module 140, and an order push module 150, where:

[0062] The scenario determination module 110 is used to determine the scenario type of the current order recommendation scenario;

[0063] The emergency treatment module 120 is used to, in response to the scenario type being an emergency order recommendation, determine the recommended drug order for the target patient according to the diagnosis result, imaging detection data, physiological index detection data, and call recording data of the target patient;

[0064] The chronic disease treatment module 130 is used to, in response to the scenario type being a chronic disease order recommendation, determine the recommended drug order for the target patient according to the diagnosis result, patient basic information, and a pre-constructed graph database, where the graph database describes the conflict relationship and combination relationship between drugs;

[0065] The auxiliary information determination module 140 is used to determine the treatment action according to the diagnosis result and patient basic information, and determine the evidence label corresponding to the drug in the recommended drug order, and use the treatment action and the evidence label as auxiliary judgment information;

[0066] The order push module 150 is used to send the recommended drug order and the auxiliary judgment information to the doctor side.

[0067] Among them, the current order recommendation scenario may refer to the diagnosis and treatment scenario of the target patient with an order recommendation requirement; the scenario type may be an emergency order recommendation or a chronic disease order recommendation.

[0068] Exemplarily, the scenario type can be determined according to the diagnosis results of the target patient, where the diagnosis results include the disease name and the corresponding judgment criteria. For example, the disease names in each emergency medical order recommendation scenario and the disease names in each chronic disease medical order recommendation scenario can be pre-entered, and the disease name in the diagnosis results of the target patient is compared with the entered disease names to determine the scenario type of the current medical order recommendation scenario.

[0069] Among them, the imaging detection data can be the relevant data of the medical imaging examination of the target patient, such as low-field nuclear magnetic resonance (0.23T), Doppler ultrasound, computed tomography, etc. The physiological index detection data can be the relevant data of the physiological metabolism index examination of the target patient, such as blood glucose value, prothrombin time, etc. The call recording data can be the recording data of the call related to the target patient stored in the emergency center.

[0070] Considering that it is necessary to quickly implement drug order recommendations in the emergency medical order recommendation scenario, a specific transmission protocol and technology can be adopted to achieve rapid data transmission to improve the patient diagnosis and treatment efficiency. For example, a streaming data processing pipeline can be built based on Apache Flink and integrated with 5G emergency vehicle Internet of Things devices. Among them, the 5G emergency vehicle Internet of Things devices include but are not limited to life feature sensors, in-vehicle cameras, examination equipment, etc. Through this streaming data processing pipeline, the diagnosis results, imaging detection data, physiological index detection data, and call recording data can be quickly obtained, improving the data transmission efficiency and ensuring that the data latency is in milliseconds.

[0071] Specifically, for the emergency medical order recommendation scenario, the emergency processing module 120 can generate recommended drug orders through the diagnosis results, imaging detection data, physiological index detection data, and call recording data. For example, the diagnosis results, imaging detection data, physiological index detection data, and call recording data are input into a pre-trained emergency medical order recommendation model to obtain the recommended drug orders.

[0072] In a specific implementation manner, the emergency processing module 120 includes a disease recommendation unit, a symptom recommendation unit, and an order recommendation unit, where:

[0073] The disease recommendation unit is used to determine the disease recommended drug information of the target patient according to the diagnosis results, imaging detection data, and physiological index detection data;

[0074] The symptom recommendation unit is used to determine the symptom recommended drug information of the target patient according to the call recording data and the physiological index detection data;

[0075] The order recommendation unit is used to determine the recommended drug order of the target patient based on the disease recommended drug information and the symptom recommended drug information.

[0076] Among them, the disease recommendation unit can recommend medications based on the diseases of the target patient to obtain disease-recommended medication information. Exemplarily, the disease type of the target patient can be determined through the diagnosis result, imaging detection data, and physiological index detection data, and then the disease-recommended medication information for the target patient can be determined based on the disease type.

[0077] In one example, the disease recommendation unit is specifically configured to:

[0078] Determine the disease subcategory of the target patient according to the diagnosis result and imaging detection data; determine each recommended drug according to the disease subcategory, and determine the priority corresponding to each recommended drug based on the physiological index detection data to obtain the disease-recommended medication information.

[0079] Specifically, the disease recommendation unit can first subdivide the disease name in the diagnosis result according to the imaging detection data to obtain the disease subcategory. Exemplarily, the imaging detection data and the diagnosis result can be input into a pre-trained image recognition model together. The image recognition model can use the diagnosis result as prior knowledge, and then subdivide the disease condition according to the imaging detection data to obtain the disease subcategory.

[0080] For example, low-field nuclear magnetic resonance can be used to further identify the type of stroke and distinguish whether it is hemorrhagic or ischemic.

[0081] After obtaining the disease subcategory, further, the disease recommendation unit can determine the drugs that can be used for this disease subcategory according to the disease subcategory as the recommended drugs. Exemplarily, the historical used drugs of different disease subcategories can be extracted from the historical medical record data in advance, and the historical used drugs of each disease subcategory can be stored, and then the recommended drugs can be determined from the stored historical used drugs of each disease subcategory.

[0082] For example, for ischemic stroke, the recommended drug can be a thrombolytic drug, and for hemorrhagic stroke, the recommended drug can be a hemostatic drug.

[0083] After determining each recommended drug according to the disease subcategory, considering that different drugs have different effects on physiological indexes, and the effects of drugs under different physiological indexes are also different. Therefore, in order to further ensure the reliability of diagnosis and treatment, the disease recommendation unit can also determine the priority corresponding to each recommended drug through the physiological index detection data of the target patient. This priority can be in the form of a weight factor, and thus the disease-recommended medication information is obtained. Among them, the disease-recommended medication information includes the priority corresponding to each recommended drug and the corresponding dose.

[0084] Exemplarily, the disease recommendation unit can pre-calibrate the physiological index conditions corresponding to each drug. After determining each recommended drug, it can respectively determine whether the physiological index detection data meets the physiological index conditions corresponding to each recommended drug. For the recommended drugs that meet the corresponding physiological index conditions, the corresponding priority can be increased, and for the recommended drugs that do not meet the corresponding physiological index conditions, the corresponding priority can be decreased.

[0085] Through the above example, in the scenario of emergency medical order recommendation, considering the requirement for accuracy in emergency medication, a dynamic priority algorithm can be adopted. The disease recommendation unit calculates each recommended drug that conforms to the disease classification of the target patient through the diagnosis result and imaging detection data, and dynamically adjusts the priority of each recommended drug in combination with physiological indexes to achieve precise drug recommendation. By combining the disease sub-classification with physiological indexes, it can ensure that the generated disease-recommended medication information can precisely meet the patient's needs and avoid delaying the treatment opportunity due to incorrect medication. Moreover, through this system, the drug matching time can be significantly reduced, thereby greatly improving the timeliness of emergency medication.

[0086] In addition to recommending medications based on the diseases of the target patient, the symptom recommendation unit can also recommend medications according to the symptoms of the target patient to obtain symptom-recommended medication information. Exemplarily, the symptom recommendation unit can determine the symptoms of the target patient through call recording data and physiological index detection data, and thus determine the symptom-recommended medication information of the target patient based on the symptoms.

[0087] In one example, the symptom recommendation unit is specifically used for:

[0088] Input the call recording data into a pre-trained symptom extraction model to obtain key symptom description information, where the symptom extraction model is a compressed lightweight model; determine whether the physiological index detection data matches the key symptom description information. If so, determine the symptom-recommended medication information based on the key symptom description information.

[0089] Among them, the symptom extraction model can be a natural language processing model trained based on core symptom knowledge, which can be used to extract information related to symptom descriptions. To ensure the operation efficiency of the model and enable the model to stably run on edge devices (such as in-vehicle terminals on ambulances), in addition to training the model with core symptom knowledge, model compression technology can also be used to compress the symptom extraction model so that the size of the model is compressed within a preset size (such as 50MB).

[0090] Specifically, the symptom recommendation unit can input the call recording data into a pre-trained symptom extraction model. The symptom extraction model can convert the call recording data into a call recording text and extract key symptom descriptions from it, such as "chest pain radiating to the left arm", to obtain key symptom description information.

[0091] Further, the symptom recommendation unit can cross-validate the key symptom description information based on the physiological index detection data. For example, it can determine the suspected symptoms corresponding to the physiological index detection data, and determine the similarity between the suspected symptoms and the key symptom description information. If the similarity between the two is greater than the preset similarity threshold, it can be determined that the physiological index detection data is consistent with the key symptom description information, that is, the key symptom description information passes the verification. Furthermore, the symptom recommendation medication information can be generated based on the key symptom description information to achieve medication recommendation based on symptoms. Among them, the symptom recommendation medication information can include the drug and the corresponding dosage.

[0092] Through the above example, the symptom recommendation unit can fuse the call recording data and the physiological index detection data to achieve multi-modal medication decision-making. The symptom recommendation unit cross-verifies the key symptom description in the call recording through the physiological index detection data, which can ensure the accuracy and reliability of the medication recommendation based on symptoms.

[0093] After obtaining the disease recommendation medication information and the symptom recommendation medication information, further, the medical order recommendation unit can fuse the two to obtain the recommended drug medical order for the target patient. Exemplarily, the medical order recommendation unit can update the priority of the recommended drugs in the disease recommendation medication information according to the drugs in the symptom recommendation medication information. For example, if the recommended drug exists in the symptom recommendation medication information, the priority of the recommended drug can be increased; if the recommended drug does not exist in the symptom recommendation medication information, the priority of the recommended drug can be decreased. Furthermore, the recommended medication with the highest priority and the corresponding dosage can be used as the recommended drug medical order for the target patient.

[0094] The above disease recommendation unit and symptom recommendation unit analyze from the perspectives of disease and symptoms respectively to make medication recommendations according to the disease and symptoms. Furthermore, the medical order recommendation unit fuses the two results to obtain the final recommended drug medical order. Compared with making medication recommendations only according to the disease or symptoms, it can further improve the accuracy of drug recommendation. Moreover, this system can greatly improve the drug recommendation efficiency, thereby ensuring the timeliness of emergency medication.

[0095] Among them, the graph database describes the conflict relationship and combination relationship between drugs. The graph database can be constructed in the form of a knowledge graph, modeling drugs as nodes, and defining the conflict relationship and combination relationship between nodes through edges.

[0096] In one example, the system provided by the embodiment of the present application further includes a graph construction module, and the graph construction module is specifically used to perform the following steps:

[0097] Step 11: Obtain the usage instruction documents of each drug and the drug combination records in the real historical medical records;

[0098] Step 12: For each instruction document, extract the conflicting drugs and co-administered drugs associated with the corresponding drug from the instruction document.

[0099] Step 13: Construct a graph database based on the conflicting drugs and co-administered drugs associated with each drug.

[0100] Step 14: Determine the actual co-administered drugs for each drug based on the drug co-administration records, and update the graph database according to the actual co-administered drugs of each drug.

[0101] Among them, the instruction document of a drug can describe the usage taboos of the drug, the conflicting drugs that interact with the drug, and the co-administered drugs that have synergistic effects, reduce side effects, delay drug resistance, or treat multiple co-existing diseases with the drug. The real historical medical records can describe the drug usage situation of real diagnosed patients, including drug co-administration records.

[0102] Specifically, in Step 11, for the instruction document of a drug, the graph construction module can search through the browser engine. For real historical medical records, the Crontab technology can be used to refresh and obtain the real historical medical records of the hospital system at regular intervals.

[0103] For example, the graph construction module sends an HTTP request to the outpatient module of the hospital system through the requests library to obtain real medical record data. This process covers API authentication authorization and request parameter configuration. The docked hospital system interface uses the API Key authentication mechanism. Therefore, the request script can complete authorization by passing the API key in the URL. The parameter configuration mainly includes the interface service code (code) and the time range for obtaining medical records. After obtaining the real medical record data, considering that the patient data obtained through interface calls may be chaotic and contain some data that is ineffective for diagnosis and treatment, during the drug recommendation process, key attention is paid to data such as the patient's chief complaint, current medical history, past medical history, and medication records, which are of great reference significance for system diagnosis and treatment. Therefore, the real medical record data can be structured to form real historical medical records for subsequent diagnosis and treatment use.

[0104] Furthermore, in Step 12, for the instruction document of a drug, the graph construction module can extract the conflicting drugs and co-administered drugs associated with the corresponding drug from the instruction document. For example, the graph construction module can input the instruction document into a pre-trained associated drug detection model. The associated drug detection model can perform text analysis on the instruction document, locate each drug noun in the document and the label in front of the drug noun, and then determine the conflicting drugs and co-administered drugs.

[0105] Further, in step 13, the graph construction module can construct each node and establish the relationships between the nodes based on the conflicting drugs and co-administered drugs associated with each drug, thereby forming a graph database.

[0106] Considering that there may be co-administered drugs omitted in the drug instruction documents, in step 14, the graph construction module can further extract the actual co-administered drugs of each drug from the drug co-administration records. For example, the drug co-administration records are input into the associated drug detection model, and then the actual co-administered drugs of each drug can be supplemented into the graph database in the form of nodes and edges to update the graph database.

[0107] Through the above steps 11 - 14, the graph construction module can describe the conflict relationships and co-administration relationships between various drugs based on the drug instruction documents of each drug and real historical medical records, forming a graph database, which is convenient for subsequent drug recommendations to consider the conflict relationships and co-administration relationships between drugs, and recommend a safer and more reliable medication plan for the target patient. Moreover, the system integrates the drug instruction documents and the actual medication situations, which can make the formed graph database more comprehensive, avoid missing the co-administration relationships between drugs, and further improve the accuracy of drug recommendations.

[0108] In the embodiments of the present application, considering that the medication plans for chronic diseases are usually relatively complex and may involve multiple drugs, and there are differences in the medication plans among different types of patients with the same disease, such as the elderly, lactating women, children, etc., different drugs may be required for the same disease.

[0109] Therefore, for the chronic disease medical order recommendation scenario, the chronic disease processing module 130 can determine the recommended drug medical order for the target patient based on the diagnosis results of the target patient, the patient's basic information, and the pre-constructed graph database, so as to avoid drugs with conflict relationships in the recommended drug medical order and avoid the recommended drug medical order not conforming to the actual situation of the patient.

[0110] In a specific implementation manner, the chronic disease processing module 130 includes an initial medical order generation unit, a risk index determination unit, and a medical order generation unit, where:

[0111] The initial medical order generation unit is used to generate the initial drug medical order for the target patient according to the diagnosis results and the conflict relationships and co-administration relationships between the drugs in the graph database;

[0112] The risk index determination unit is used to input the initial drug medical order and the patient's basic information into a pre-trained risk prediction model to obtain the patient's usage risk index corresponding to the initial drug medical order;

[0113] The medical order generation unit is used to adjust the drugs in the initial drug medical order according to the patient's usage risk index, and adjust the dosage corresponding to the drugs in the initial drug medical order according to the patient's basic information, so as to obtain the recommended drug medical order.

[0114] Among them, the initial medical order generation unit can first determine the initial drug medical order that can be applied to the disease name in the diagnosis result and whose included drugs have no conflict relationship by combining the conflict relationship and combination relationship described in the graph database. The initial drug medical order can include the combined drugs for the disease name.

[0115] Furthermore, considering that some drugs may not be applicable to specific patients or there are risks for specific patients to use. For example, non-steroidal anti-inflammatory drugs are not applicable to lactating women. Therefore, in order to further ensure the safety of drug recommendation, the risk index determination unit can input the initial drug medical order and the patient's basic information into a pre-trained risk prediction model. The risk prediction model can judge the risk of the initial drug medical order being used by the target patient according to the patient's basic information, and obtain the corresponding patient usage risk index. The patient usage risk index can reflect the action risk after the patient uses the initial drug medical order. Among them, the patient's basic information can include the patient's age, gender, basic medical history, and patient attributes (such as whether the patient is pregnant, etc.).

[0116] Furthermore, after the medical order generation unit obtains the patient usage risk index, if the patient usage risk index is greater than the preset index threshold, it can update the initial drug medical order. For example, replace the drugs in the initial drug medical order with drugs of the same effect. After updating the initial drug medical order, the initial drug medical order and the patient's basic information can be input into the risk prediction model again to re-predict the patient usage risk index, and repeat this process until the patient usage risk index corresponding to the initial drug medical order is less than the preset index threshold.

[0117] It should be noted that when the patient usage risk index is greater than the preset index threshold, the medical order generation unit can also issue a graded alarm. The greater the difference between the patient usage risk index and the preset index threshold, the higher the alarm level. Alarm methods corresponding to the alarm level can be adopted, such as pop-up windows, SMS notifications, or system blocking, etc.

[0118] In addition, in addition to adjusting the drugs in the initial drug medical order according to the patient's basic information, considering that the dosage of the same drug used by different types of patients may vary, the medical order generation unit can also adjust the dosage corresponding to the drugs in the initial drug medical order according to the patient's basic information. For example, the Monte Carlo algorithm can be embedded to optimize the dosage corresponding to the drugs in the initial drug medical order. Combining the patient's basic information and physiological index detection data, the dosage error can be controlled within ±2.5 mg to ensure the safety and effectiveness of the patient's medication.

[0119] The above-mentioned initial medical order generation unit can first combine the graph database and the diagnosis result to generate an initial drug medical order without conflict relationships. Then, the risk index determination unit detects the risk indicators of the initial drug medical order based on the patient's basic information. The medical order generation unit adjusts the drugs therein according to the risk indicators and adjusts the drug doses therein according to the patient's basic information, which can ensure that the generated recommended drug medical order better meets the patient's needs, and there are no conflicts among multiple drugs, and the safety of drug recommendation is ensured.

[0120] It should be noted that the emergency treatment module 120 and the chronic disease treatment module 130 are two parallel modules, and specifically trigger the two models to execute the generation of the corresponding recommended drug medical order according to the scene type. Refer to Figure 1 Among them, the scene determination module 110 is connected to both the emergency treatment module 120 and the chronic disease treatment module 130 at the same time. Moreover, both the emergency treatment module 120 and the chronic disease treatment module 130 are connected to the auxiliary information determination module 140, and the auxiliary information determination module 140 is connected to the medical order recommendation module 150.

[0121] Considering that in the chronic disease medical order recommendation scenario, in addition to drug medical orders, patients may also need nutritional assistance medical orders. Therefore, for the chronic disease medical order recommendation scenario, the above-mentioned system can also generate the nutritional assistance medical order of the target patient while generating the recommended drug medical order.

[0122] In some embodiments, the system provided by the embodiments of the present application further includes a nutritional assistance medical order module, and the nutritional assistance medical order module is specifically used to perform the following steps:

[0123] Step 21: Determine the inventory status of each nutritional drug;

[0124] Step 22: Determine the nutritional assistance medical order of the target patient according to the diagnosis result and the inventory status;

[0125] Step 23: Based on the physiological index detection data and the upper and lower limits corresponding to each preset physiological index, determine the risk physiological index among the preset physiological indexes, and determine the prohibited nutritional components corresponding to the risk physiological index;

[0126] Step 24: If the nutritional assistance medical order contains prohibited nutritional components, update the nutritional assistance medical order based on the diagnosis result, the inventory status, and the prohibited nutritional components.

[0127] Among them, in step 21, the nutritional assistance medical order module can dock with the hospital system through the HL7 FHIR standard to obtain the inventory status of each nutritional drug in real time. For example, the remaining amount information of branched-chain amino acid preparations.

[0128] Further, in step 22, the nutritional assistance medical advice module can determine applicable nutritional drugs according to the disease names in the diagnosis results. For example, for special populations such as patients with hepatic encephalopathy, nutritional drugs with a low-protein formula will be preferentially allocated, which can be specifically determined by pre-set rules. Then, according to the inventory status of each nutritional drug, among the applicable nutritional drugs, the nutritional drugs with the inventory surplus exceeding the pre-set surplus threshold are preferentially used as the recommended nutritional drugs to generate the nutritional assistance medical advice for the target patient. Among them, the nutritional assistance medical advice includes the recommended nutritional drugs and the corresponding dosages.

[0129] When generating the nutritional assistance medical advice, the nutritional assistance medical advice module can also generate a hash value corresponding to the nutritional assistance medical advice and store the hash value in the consortium blockchain. In this way, cross-hospital traceability can be achieved within 30 seconds, which is convenient for auditing and querying the decision-making process. Similarly, the recommended drug medical advice can also generate and store the hash value in this way.

[0130] Further, in step 23, the nutritional assistance medical advice module can judge whether the values of each pre-set physiological index exceed the upper and lower limits in the physiological index detection data of the target patient according to the upper and lower limits corresponding to each pre-set physiological index, and determine the pre-set physiological index that exceeds the upper and lower limits as the risk physiological index, indicating that the target patient has a risk in this pre-set physiological index. Then, the prohibited nutritional components corresponding to this risk physiological index can be queried to lock the components that will have a negative impact on the target patient.

[0131] Exemplarily, if blood ammonia > 60 μmol / L and INR (International Normalized Ratio of prothrombin time) > 1.8, then blood ammonia and INR can be determined as risk physiological indexes, and the corresponding prohibited nutritional component is high protein.

[0132] Further, in step 24, the nutritional assistance medical advice module can judge whether the nutritional assistance medical advice contains prohibited nutritional components. If it contains, the prohibited nutritional components can be directly removed from the nutritional assistance medical advice, or, according to the diagnosis results and the inventory status of each nutritional drug, a new nutritional assistance medical advice that does not contain prohibited nutritional components can be generated.

[0133] Through the above steps 21 - 24, the nutritional assistance medical advice module can first generate a nutritional assistance medical advice based on the inventory status of nutritional drugs and the diagnosis results to ensure the rational use of resources, and then monitor the risks of this medical advice through the physiological index detection data, avoiding recommending risky nutritional formulas for the target patient, ensuring the safety and effectiveness of the recommended nutritional assistance drugs, realizing personalized nutritional diagnosis and treatment recommendations, further improving the patient diagnosis and treatment efficiency, reducing the workload of doctors, and enhancing the patient's medical experience.

[0134] In an embodiment of the present application, to help doctors better understand the recommended drug orders, the auxiliary information determination module 140 may generate auxiliary judgment information corresponding to the recommended drug orders, and the auxiliary judgment information includes diagnosis and treatment actions and evidence tags.

[0135] Among them, the diagnosis and treatment actions can describe the diagnosis and treatment plans for diseases, such as medication information, examination information, etc. Specifically, the auxiliary information determination module 140 may pre-construct various action judgment rules presented in the form of logical expressions. The rules may include judgment conditions for diseases and patient basic information (and may also include judgment conditions for physiological indicators), and the rules also include corresponding actions to be executed after passing the judgment (such as medication information, examination information, etc.).

[0136] Specifically, the auxiliary information determination module 140 may input the diagnosis result and patient basic information into each action judgment rule, so that the action judgment rule judges the diagnosis result and patient basic information to obtain the corresponding diagnosis and treatment actions.

[0137] Exemplarily, the action judgment rule may be: "If the patient is diagnosed with sepsis and the time elapsed since the diagnosis time does not exceed [specified time], then perform the actions of blood culture and antibiotic use". Among them, the condition part of the action judgment rule may include multiple factors, such as the patient's basic information (age, gender, etc.), physiological indicators (body temperature, blood pressure, etc.), and examination data (blood routine, etc.).

[0138] In an embodiment of the present application, the action judgment rule can be implemented using a suitable programming language and rule engine, such as Drools, etc. Drools provides powerful rule definition and execution capabilities, and can encode the defined rules in the syntax supported by the rule engine so that it can run in a computer system. For example, using the rule file format of Drools, the sepsis rule in the above example is written as:

[0139] rule "Sepsis Bundle Treatment"

[0140] when

[0141] $patient: Patient(diagnosis == "Sepsis", timeSinceDiagnosis < [specified time])

[0142] then

[0143] / / Code logic for performing blood culture and antibiotic use actions

[0144] performBloodCulture();

[0145] administerAntibiotics();

[0146] end

[0147] In addition to determining the diagnosis and treatment actions, the auxiliary information determination module 140 can also generate evidence tags corresponding to the drugs in the recommended drug order. Among them, the evidence tags can include the names of relevant clinical studies, research results, and evidence grades (for example, grade A is high-quality evidence, grade B is medium-quality evidence, grade C is low-quality evidence, etc., which can be determined according to the types of source documents).

[0148] For example, for a certain antibiotic used to treat sepsis, the evidence tag can be: "According to [specific research name], this antibiotic has shown significant efficacy in treating sepsis patients, and the evidence grade is A".

[0149] Specifically, the auxiliary information determination module 140 can pre-associate the evidence tags with the drugs to ensure that the relevant evidence information can be displayed simultaneously when recommending drugs. For example, in the database of the system, an evidence tag field is added to each drug record, and the corresponding evidence tag content is stored in this field. When generating a recommended drug order, the corresponding evidence tags can be extracted from the database.

[0150] After obtaining the diagnosis and treatment actions and evidence tags, the auxiliary information determination module 140 can use them as auxiliary judgment information to be presented to the doctor together with the recommended drug order.

[0151] Specifically, the order push module 150 can send the recommended drug order and the auxiliary judgment information to the doctor side to help the doctor better understand the recommendation basis and rationality of the recommended drug order. The doctor can confirm the recommended drug order or modify the recommended drug order through the doctor side.

[0152] Considering that there may be a large deviation in the recommended drug order, the doctor can directly veto the recommended drug order in such cases, and such recommended drug orders can also be used for model feedback learning.

[0153] In a specific implementation manner, the system provided by the embodiment of the present application further includes an order feedback module, and this order feedback module is used to perform the following steps:

[0154] Step 31: After sending the recommended drug order and the auxiliary judgment information to the doctor side, in response to receiving the order veto signal fed back by the doctor side, obtain the veto reason text corresponding to the recommended drug order;

[0155] Step 32: Determine the recommended drug order as a negative sample, and determine the problem type of the recommended drug order according to the rejection reason text;

[0156] Step 33: Write the recommended drug order into the database corresponding to the problem type, where the database is used for reinforcement learning of models related to the problem type.

[0157] Among them, in Step 31, the doctor can reject the recommended drug order through the doctor's terminal and fill in or select the rejection reason. The order feedback module can obtain the rejection reason text filled in by the doctor in the doctor's terminal in response to the order rejection signal feedback by the doctor's terminal.

[0158] Further, in Step 32, the order feedback module can determine the rejected recommended drug order as a negative sample and determine the problem type according to the rejection reason text, that is, the type of problem that occurs in the recommendation, such as the symptom does not match the drug, the drug has risks, the dosage is incorrect, etc.

[0159] Further, in Step 33, the order feedback module can write the recommended drug order into the database corresponding to the problem type to facilitate subsequent reinforcement learning of models related to the problem type. And it can also obtain the corrected order feedback by the doctor's terminal and store the corrected order in the database together.

[0160] Exemplarily, negative samples with symptoms not matching the drug can be used for strengthening the training of image recognition models, symptom extraction models, etc., and negative samples with drug risks can be used for strengthening the training of risk prediction models.

[0161] Through the above implementation manner, the order feedback module can be stored in the database as a negative sample when the doctor rejects the recommended drug order, which is used for reinforcement feedback learning of the model, further ensuring the accuracy of subsequent drug recommendations.

[0162] Considering that the patient's condition may change during the diagnosis and treatment process, therefore, in order to adapt to the patient's condition in real time and ensure the diagnosis and treatment effect of the patient, the recommended drug order can also be dynamically adjusted during the patient's diagnosis and treatment process, so that the recommended drug order can always meet the patient's diagnosis and treatment needs.

[0163] In some implementation manners, the system provided by the embodiment of the present application further includes a dynamic optimization module, and this dynamic optimization module is used to perform the following steps:

[0164] Step 41: After sending the recommended drug order and the auxiliary judgment information to the doctor's terminal, in response to receiving the order use signal feedback by the doctor's terminal, associate and store the recommended drug order with the patient's basic information, and determine the dynamic order optimization condition corresponding to the target patient according to the recommended drug order and the patient's basic information;

[0165] Step 42: In response to detecting the real-time physiological data of the target patient, determine whether the target patient meets the dynamic doctor's order optimization conditions based on the real-time physiological data; if so, adjust the recommended drug doctor's order based on the real-time physiological data.

[0166] Among them, in step 41, after the recommended drug order is generated and displayed to the doctor side, the doctor side can confirm it to indicate that the target patient will subsequently use the recommended drug order. The dynamic optimization module responds to the order usage signal fed back by the doctor side and can store the recommended drug order in association with the patient's basic information.

[0167] In addition, in order to achieve dynamic optimization of recommended drug orders during diagnosis and treatment, the dynamic optimization module can also determine dynamic order optimization conditions based on the recommended drug orders and the patient's basic information. The dynamic order optimization conditions can be understood as the conditions that need to be met for dynamic optimization of recommended drug orders.

[0168] For example, the physiological index conditions that need to be optimized for the medical order can be determined based on the effect description of the drug corresponding to the recommended medical order and the basic information of the patient, and the physiological index conditions can be used as dynamic medical order optimization conditions.

[0169] For example, in diabetes management, the insulin dosage can be dynamically adjusted according to blood sugar fluctuations. If the therapeutic effect is not achieved (such as 72-hour blood sugar target rate <70%), the dosage recalculation or drug replacement needs to be automatically triggered. Therefore, the 72-hour blood sugar target rate <70% can be used as a dynamic medical order optimization condition.

[0170] Furthermore, in step 42, the dynamic optimization module can determine whether the target patient meets the dynamic medical order optimization conditions based on the detected real-time physiological data of the target patient. If so, the adjustment amount is determined based on the real-time physiological data, and the dosage of the drug in the recommended drug order is corrected based on the adjustment amount.

[0171] Through the above steps 41 and 42, the dynamic optimization module can determine the dynamic order optimization conditions through the recommended drug orders and the patient's basic information, and then determine whether the conditions are met based on the real-time physiological data, so as to dynamically optimize the recommended drug orders. Compared with the static recommendation mode, it can combine multimodal data to make decisions, achieve accurate dosage adaptation, and further ensure the effect of drug recommendation.

[0172] The drug order generation system provided by the embodiments of the present application determines the scene type of the current order recommendation scene. In response to the scene type being an emergency order recommendation, based on the diagnosis result, imaging detection data, physiological index detection data, and call recording data of the target patient, it determines the recommended drug order for the target patient. In response to the scene type being a chronic disease order recommendation, based on the diagnosis result of the target patient and the patient's basic information, combined with the pre-constructed graph database describing the conflict relationship and combination relationship between drugs, it determines the recommended drug order for the target patient. Furthermore, it determines the treatment actions based on the diagnosis result and the patient's basic information, and determines the evidence labels corresponding to the drugs in the recommended drug order. The treatment actions and evidence labels are used as auxiliary judgment information and sent to the doctor's terminal together with the recommended drug order to achieve order recommendation, which can quickly assist doctors in making treatment decisions, improve the efficiency of treatment decisions, and solve problems such as low patient treatment efficiency and heavy doctor workload in scenarios with a large number of patients waiting for treatment, improve the quality of medical services, reduce human decision-making errors, and optimize resource allocation. Moreover, the system pushes the treatment actions and evidence labels together as auxiliary judgment information to the doctor, which can help the doctor quickly judge whether the recommended drug order is reasonable and further ensure the correctness of the recommended drug order. In addition, the system divides the scene into emergency order recommendation and chronic disease order recommendation, and adopts corresponding order determination strategies for different scenes, which can combine the order recommendation requirements in different scenes to achieve accurate order recommendation and further ensure the reasonableness of the recommended drug order.

[0173] On the basis of the above embodiments, optionally, the drug order generation system further includes an interrogation module, which is implemented through an interrogation intelligent agent. The front end interrogates the patient in the form of a digital human + voice, and the user can directly talk to the digital human. At the same time, the front end also designs touch buttons and input boxes. In addition to having a voice conversation with the digital human, the user can also choose to interact through touch buttons and text input, improving the convenience of interaction in the interrogation session. The entire intelligent interrogation session takes the large model and the interrogation intelligent agent as the core, and also involves a voice model and a text-to-video model. The voice model is responsible for converting the user's voice input into text, and the system then inputs the text into the interrogation intelligent agent. When the intelligent agent finishes answering, the answer result is converted into a corresponding digital human video, and the digital human is presented at the front end to talk to the user. The digital human image here supports customization, and a specified image can be selected.

[0174] Based on the above embodiments, optionally, the drug order generation system further includes a physical examination module. The front end of the physical examination module designs a patient physical examination form, and each examination item contains multiple sub-items. Patients can complete the physical examination through touch operations. When the patient finishes the physical examination and clicks the submission button, the doctor's end will receive a message. After the doctor corrects the physical examination data submitted by the patient and clicks the confirmation button, the form data will be transmitted to the back end. After the back end adjusts the structure of the data, it will be stored in the SQLite database for subsequent calls. When the doctor clicks the confirmation button, a parameter containing the operation code will be transmitted to the back end, indicating that the data required for the diagnosis has been prepared. After receiving this parameter, the back end will add the diagnosis task to the queue. The queue uses RabbitMQ technology. After the large model finishes processing the current task, it will take the task from the queue for processing. This can ensure that the processing process will not be blocked. During the execution of the diagnosis, the next step can be carried out synchronously without waiting for the diagnosis result. When the diagnosis result is generated, it will be automatically pushed to the front end for the doctor to view and correct, and on this basis, the diagnosis result confirmed by the doctor will be generated.

[0175] Based on the above embodiments, optionally, the drug order generation system further includes a patient data acquisition module, which uses Crontab technology to regularly refresh and obtain the internal data of the hospital system, and stores the formatted data in the database of the corresponding patient. It mainly includes two steps: one is patient data acquisition: an HTTP request is sent to the hospital outpatient information management system through the requests library to obtain medical record data. This process covers API authentication authorization and request parameter configuration. The interface of the hospital information management system docked by the system adopts the API Key authentication mechanism, so the request script completes the authorization by passing the API key in the URL. Parameter configuration mainly includes the interface service code (code) and the time range for obtaining medical records. The second is patient data preprocessing: The patient data obtained through interface calls is chaotic and contains some data that is invalid for system diagnosis and treatment. It is necessary to perform preprocessing on the basis of obtaining the data, focusing on data such as the patient's chief complaint, current medical history, and past medical history, which are of great significance for system diagnosis and treatment. After reasonable structuring of these data, they are stored in the local SQLite database for subsequent diagnosis and treatment.

[0176] Based on the above embodiments, optionally, the drug order generation system further includes a diagnosis module, which involves the link of large model processing and can be managed in a queued manner using RabbitMQ. After the front end transmits the diagnosis-related operation parameters and patient information, the system automatically adds the information corresponding to the patient to the queue until the task is executed.

[0177] Based on the above embodiments, optionally, the drug order generation system further includes a diagnosis and treatment plan module. The implementation principle of this module is roughly similar to that of the recommended order, but there are two differences: one is that the diagnosis and treatment plan will call a large model specifically for diagnosis and treatment plans, and the other is that the input data is slightly different. In addition to the data used in the recommended order, the diagnosis and treatment plan model also requires the recommended order result as part of the input. In other words, on the basis of the recommended order input data, the recommended drug order (the recommended drug order revised by the doctor) is added.

[0178] Based on the above embodiments, optionally, the drug order generation system further includes a discharge medical document module. When the patient meets the discharge conditions, this module can automatically trigger the discharge medical document task. The large model automatically generates the inpatient diagnosis and treatment process, discharge diagnosis, discharge condition, symptoms and signs, etc. based on the daily diagnosis and treatment plan and other existing patient information, and finally generates a discharge summary and pushes it to the doctor's end. The doctor revises and fills it into the patient's discharge information on this basis.

[0179] Based on the above embodiments, optionally, the drug order generation system further includes a message queue management engine, such as RabbitMQ. The producer sends messages to the exchange, and the exchange distributes the messages to the corresponding queue according to predefined routing rules (such as Direct, Fanout, Topic, etc.). The consumer retrieves and processes the messages from the queue. Its core mechanisms include message persistence, load balancing, transaction confirmation, and high availability support, ensuring reliable and efficient message delivery in a distributed system. At the same time, application decoupling and asynchronous processing are achieved through flexible routing strategies. The front end of this system passes patient information and operation codes to the back end according to specific nodes. The back end submits the processed messages to the message queue after processing and executes the tasks in the message queue through pre-designed callback functions, thereby realizing parallelism in different links, improving processing efficiency, avoiding process jams, and the user does not need to wait for the back-end large model processing result on the current interface. When the result is generated, it will be automatically pushed to the front end.

[0180] The drug order generation system provided by the embodiments of this application has the following technical effects:

[0181] (1) It can realize the full-process AI-assisted diagnosis and treatment from the patient's admission consultation to the generation of discharge medical documents through an integrated system, connect all processes in the patient's diagnosis and treatment process, solve the problem that the current AI applications can only be applied separately in several fields and cannot be linked, break the barriers between different item data of patients, reduce the cost of manual intervention by medical staff, and reduce the probability of problems such as missed diagnosis and misdiagnosis by medical staff;

[0182] (2) It can interact with the existing hospital systems. Through the data acquisition engine, patient data can be obtained from the hospital systems. By embedding the front-end page into the hospital systems, doctors can supplement and correct the electronic medical records of patients according to the AI recommendations, realizing the two-way data flow between this system and the hospital systems.

[0183] (3) A dual-track process of first admission registration and daily admission record is designed. The two processes have different focuses. The first admission registration emphasizes more comprehensive medical history taking and physical examination, while the daily admission record emphasizes targeted medical history taking and physical examination of patients based on the first admission information. Patients can choose different processes according to their current situation.

[0184] The above drug order generation system can solve the following problems in the prior art: 1. Process fragmentation and data silos: In the traditional diagnosis and treatment process, patient data collection, medical history taking, physical examination, diagnosis, treatment, and discharge links are independent of each other, and data transfer relies on manual operations, resulting in information lag, duplicate entry, and low cross-departmental collaboration efficiency. Especially for critically ill patients, the treatment opportunity may be delayed; 2. Fragmented intelligent applications: The prior art mostly focuses on single scenarios (such as medical history-taking robots), lacking an integrated solution covering the whole process. Although large model technologies are applied in some scenarios, their potential has not been fully released. For example, an end-to-end closed-loop from diagnosis to drug order recommendation, treatment plan generation to discharge documents has not been achieved; 3. Insufficient diagnosis and treatment standardization: Different hospitals are limited by the differences in doctors' experience, and the standardization of diagnosis and treatment plans varies greatly, prone to missed diagnosis, misdiagnosis, or over-medical treatment problems. Existing systems are difficult to dynamically combine guidelines and patient individual data to provide accurate decision-making support; 4. Uneven distribution of medical resources: High-quality medical resources are concentrated in large hospitals, the patient visit process is cumbersome, and doctors' workload is too heavy, especially in time-consuming links such as medical record writing and drug order formulation. There is an urgent need for intelligent tools to release human resources. The above drug order generation system realizes the full-cycle automation and precision from patient admission to discharge by constructing a closed-loop system with real-time data synchronization and multi-link linkage, thereby improving the quality of medical services, reducing human errors, and optimizing resource allocation.

[0185] Embodiment 2:

[0186] For the same purpose, the embodiment of the present application also proposes a method for generating drug orders. The steps in the method for generating drug orders provided by the embodiment of the present application can be executed by the above drug order generation system, and the execution steps and beneficial effects are not elaborated here. Figure 2 It is a flowchart of a method for generating drug orders provided by the embodiment of the present application.

[0187] See Figure 2 , the method for generating drug orders specifically includes:

[0188] S210. Determine the scenario type of the current doctor's order recommendation scenario.

[0189] S220. In response to the scenario type being emergency doctor's order recommendation, determine the recommended drug doctor's order for the target patient based on the diagnosis result, imaging test data, physiological index test data, and call recording data of the target patient.

[0190] In a specific implementation manner, determining the recommended drug doctor's order for the target patient based on the diagnosis result, imaging test data, physiological index test data, and call recording data of the target patient includes:

[0191] Determine the disease recommended drug information for the target patient according to the diagnosis result, imaging test data, and physiological index test data;

[0192] Determine the symptom recommended drug information for the target patient according to the call recording data and physiological index test data;

[0193] Based on the disease recommended drug information and symptom recommended drug information, determine the recommended drug doctor's order for the target patient.

[0194] In an example, determining the disease recommended drug information for the target patient according to the diagnosis result, imaging test data, and physiological index test data includes:

[0195] Determine the disease sub-classification of the target patient according to the diagnosis result and imaging test data; determine each recommended drug according to the disease sub-classification, and determine the priority corresponding to each recommended drug based on the physiological index test data to obtain the disease recommended drug information.

[0196] In an example, determining the symptom recommended drug information for the target patient according to the call recording data and physiological index test data includes:

[0197] Input the call recording data into a pre-trained symptom extraction model to obtain key symptom description information, where the symptom extraction model is a compressed lightweight model; determine whether the physiological index test data is consistent with the key symptom description information, and if so, determine the symptom recommended drug information based on the key symptom description information.

[0198] S230. In response to the scenario type being chronic disease doctor's order recommendation, determine the recommended drug doctor's order for the target patient according to the diagnosis result, patient basic information, and a pre-constructed graph database.

[0199] In some implementation manners, the construction of the graph database includes:

[0200] Obtain the usage instruction documents of each drug and the drug combination records in real historical medical records;

[0201] For each instruction manual, extract the conflicting drugs and co-administered drugs associated with the corresponding drug from the instruction manual;

[0202] Construct a graph database based on the conflicting drugs and co-administered drugs associated with each drug;

[0203] Determine the actual co-administered drugs of each drug based on the drug co-administration records, and update the graph database according to the actual co-administered drugs of each drug.

[0204] In a specific implementation manner, according to the diagnosis results of the target patient, the patient's basic information, and the pre-constructed graph database, determine the recommended drug orders for the target patient, including:

[0205] Generate the initial drug orders for the target patient according to the diagnosis results and the conflict relationship and co-administration relationship between drugs in the graph database;

[0206] Input the initial drug orders and the patient's basic information into a pre-trained risk prediction model to obtain the patient usage risk index corresponding to the initial drug orders;

[0207] Adjust the drugs in the initial drug orders according to the patient usage risk index, and adjust the doses corresponding to the drugs in the initial drug orders according to the patient's basic information to obtain the recommended drug orders.

[0208] In some implementation manners, when determining the recommended drug orders for the target patient according to the diagnosis results of the target patient, the patient's basic information, and the pre-constructed graph database, it also includes:

[0209] Determine the inventory status of each nutritional drug;

[0210] Determine the nutritional assistance orders for the target patient according to the diagnosis results and the inventory status;

[0211] Based on the physiological index detection data and the upper and lower limits corresponding to each preset physiological index, determine the risk physiological indexes among the preset physiological indexes, and determine the prohibited nutritional components corresponding to the risk physiological indexes;

[0212] If the nutritional assistance orders contain prohibited nutritional components, update the nutritional assistance orders based on the diagnosis results, the inventory status, and the prohibited nutritional components.

[0213] S240. Determine the treatment actions according to the diagnosis results and the patient's basic information, and determine the evidence labels corresponding to the drugs in the recommended drug orders, and use the treatment actions and the evidence labels as auxiliary judgment information.

[0214] S250. Send the recommended drug orders and the auxiliary judgment information to the doctor terminal.

[0215] In a specific implementation, after sending the recommended drug medical order and the auxiliary judgment information to the doctor's terminal, it further includes:

[0216] In response to receiving the medical order veto signal feedback from the doctor's terminal, obtain the veto reason text corresponding to the recommended drug medical order;

[0217] Determine the recommended drug medical order as a negative sample, and determine the problem type of the recommended drug medical order according to the veto reason text;

[0218] Write the recommended drug medical order into the database corresponding to the problem type, where the database is used for reinforcement learning of the model related to the problem type.

[0219] In some implementations, after sending the recommended drug medical order and the auxiliary judgment information to the doctor's terminal, it further includes:

[0220] In response to receiving the medical order usage signal feedback from the doctor's terminal, associate and store the recommended drug medical order with the patient's basic information, and determine the dynamic medical order optimization conditions corresponding to the target patient according to the recommended drug medical order and the patient's basic information;

[0221] In response to detecting the real-time physiological data of the target patient, judge whether the target patient meets the dynamic medical order optimization conditions based on the real-time physiological data. If so, adjust the recommended drug medical order based on the real-time physiological data.

[0222] The method for generating a drug medical order provided by an embodiment of the present application determines the scene type of the current medical order recommendation scene. In response to the scene type being an emergency medical order recommendation, based on the diagnosis result, imaging detection data, physiological index detection data, and call recording data of the target patient, the recommended drug medical order for the target patient is determined. In response to the scene type being a chronic disease medical order recommendation, based on the diagnosis result of the target patient and the patient's basic information, combined with a pre-constructed graph database describing the conflict relationship and combination relationship between drugs, the recommended drug medical order for the target patient is determined. Furthermore, the diagnosis action is determined based on the diagnosis result and the patient's basic information, and the evidence label corresponding to the drug in the recommended drug medical order is determined. The diagnosis action and the evidence label are used as auxiliary judgment information and sent to the doctor terminal together with the recommended drug medical order to achieve medical order recommendation. It can quickly assist doctors in making medical decisions, improve the efficiency of medical decision-making, and in scenarios with a large number of patients waiting for treatment, it can solve problems such as low patient treatment efficiency and heavy doctor workload, improve the quality of medical services, reduce human decision-making errors, and optimize resource allocation. Moreover, this method sends the diagnosis action and the evidence label together as auxiliary judgment information to the doctor, which can help the doctor quickly judge whether the recommended drug medical order is reasonable and further ensure the correctness of the recommended drug medical order. In addition, this method divides the scene into emergency medical order recommendation and chronic disease medical order recommendation, and adopts corresponding medical order determination strategies for different scenes, which can combine the medical order recommendation requirements in different scenes to achieve accurate medical order recommendation and further ensure the reasonableness of the recommended drug medical order.

[0223] Figure 3 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. As Figure 3 shown, the electronic device 400 includes one or more processors 401 and a memory 402.

[0224] The processor 401 can be a central processing unit (CPU) or other forms of processing units with data processing capabilities and / or instruction execution capabilities, and can control other components in the electronic device 400 to perform desired functions.

[0225] The memory 402 may include one or more computer program products, and the computer program products may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory, etc. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage media, and the processor 401 may run the program instructions to implement the method for generating a drug order according to any embodiment of the present application described above and / or other desired functions. Various contents such as initial external parameters, thresholds, etc. may also be stored in the computer-readable storage media.

[0226] In one example, the electronic device 400 may further include: an input device 403 and an output device 404, and these components are interconnected through a bus system and / or other forms of connection mechanisms (not shown). The input device 403 may include, for example, a keyboard, a mouse, etc. The output device 404 may output various information to the outside, including warning prompt information, braking force, etc. The output device 404 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0227] Of course, for simplicity, Figure 3 only some of the components related to the present application in the electronic device 400 are shown, and components such as buses, input / output interfaces, etc. are omitted. In addition, according to specific application scenarios, the electronic device 400 may further include any other appropriate components.

[0228] In addition to the above methods and devices, an embodiment of the present application may also be a computer program product, which includes computer program instructions that, when run by a processor, cause the processor to execute the steps of the method for generating a drug order provided in any embodiment of the present application.

[0229] The computer program product may be written in any combination of one or more programming languages to write program code for performing the operations of the embodiments of the present application. The programming languages include object-oriented programming languages, such as Java, C++, etc., and also include conventional procedural programming languages, such as the "C" language or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's device, executed as an independent software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0230] In addition, an embodiment of the present application may also be a computer-readable storage medium storing computer program instructions, which, when run by a processor, cause the processor to execute the steps of the method for generating a drug order provided in any embodiment of the present application.

[0231] The computer-readable storage medium may adopt any combination of one or more readable media. The readable media may be a readable signal medium or a readable storage medium. The readable storage medium may, for example, include but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0232] It should be noted that the terms used in the present application are only for describing specific embodiments and do not limit the scope of the present application. As shown in the specification and claims of the present application, unless the context clearly indicates otherwise, words such as "a", "an", "one", and / or "the" are not specifically singular and may also include the plural. The term "comprising", "including", or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, or device including a series of elements not only includes those elements but also other elements not explicitly listed, or also includes elements inherent to such a process, method, or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, or device including the said element.

[0233] It should also be noted that the orientation or positional relationship indicated by terms such as "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc. is based on the orientation or positional relationship shown in the drawings, and is only for the convenience of describing the present application and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and thus cannot be construed as a limitation to the present application. Unless otherwise clearly specified and limited, terms such as "installed", "connected", "coupled", etc. should be understood in a broad sense. For example, it may be a fixed connection, a detachable connection, or an integral connection; it may be a mechanical connection or an electrical connection; it may be directly connected or indirectly connected through an intermediate medium, and it may be the internal communication of two elements. For those of ordinary skill in the art, the specific meanings of the above terms in the present application can be understood in specific cases.

[0234] In this text, specific examples are used to elaborate on the principles and implementation manners of this application. The description of the above embodiments is only used to help understand the method and its core idea of this application. The above is only the preferred implementation manner of this application. It should be noted that due to the limitation of literal expression and objectively infinite specific structures, for those of ordinary skill in the art, without departing from the principles of this application, several improvements, refinements or changes can be made, or the above technical features can be combined in an appropriate manner; these improvements, refinements, changes or combinations, or directly applying the inventive concept and technical solution to other occasions without improvement, shall all be regarded as the protection scope of this application.

Claims

1. A system for generating medication prescriptions, characterized in that: The system includes a scenario determination module, an emergency treatment module, a chronic disease treatment module, an auxiliary information determination module, and a medical advice push module, wherein: A scenario determination module is used to determine the scenario type of the current doctor's order recommendation scenario; An emergency treatment module, for determining a recommended medication order for the target patient based on the target patient's diagnosis result, imaging test data, physiological index test data, and call recording data in response to the scenario type being an emergency medical order recommendation; a chronic disease processing module, for determining, in response to the scenario type being a chronic disease doctor's order recommendation, a recommended drug order for the target patient based on the target patient's identification result, the patient's basic information, and a pre-built graph database, wherein the graph database describes conflict relationships and combined use relationships between drugs; An auxiliary information determination module, used to determine the diagnosis and treatment action according to the diagnosis result and the patient's basic information, and determine the evidence label corresponding to the drug in the recommended drug order, and use the diagnosis and treatment action and the evidence label as auxiliary judgment information; The medical advice push module is used to send the recommended drug advice and the auxiliary judgment information to the doctor.

2. The system for generating medication prescriptions according to claim 1, characterized in that: The emergency treatment module includes a disease recommendation unit, a symptom recommendation unit and a doctor's advice recommendation unit, wherein: The disease recommendation unit is used to determine the disease recommended medication information of the target patient according to the diagnosis result, the image detection data and the physiological index detection data; The symptom recommendation unit is used to determine the symptom recommended medication information of the target patient based on the call recording data and the physiological index detection data; The medical advice recommendation unit is used to determine the recommended drug advice for the target patient based on the disease recommended medication information and the symptom recommended medication information.

3. The system for generating medication prescriptions according to claim 2, characterized in that: The disease recommendation unit is specifically used for: Determining the disease subclassification of the target patient according to the diagnosis result and the imaging detection data; The recommended drugs are determined according to the disease subclassification, and the priority level corresponding to each recommended drug is determined based on the physiological indicator detection data to obtain the disease recommended drug information.

4. The system for generating medication prescriptions according to claim 2, characterized in that: The symptom recommendation unit is specifically used for: Inputting the call recording data into a pre-trained symptom extraction model to obtain key symptom description information, wherein the symptom extraction model is a compressed lightweight model; Determine whether the physiological indicator detection data is consistent with the key symptom description information, and if so, determine the symptom recommended medication information based on the key symptom description information.

5. The system for generating medication prescriptions according to claim 1, characterized in that: The chronic disease processing module includes an initial medical order generation unit, a risk index determination unit and a medical order generation unit, wherein: The initial medical order generating unit is used to generate the initial medical order for the target patient according to the identification result and the conflict relationship and the combination relationship between the drugs in the graph database; A risk index determination unit, used to input the initial medication order and the patient basic information into a pre-trained risk prediction model to obtain a patient use risk index corresponding to the initial medication order; The medical order generating unit is used to adjust the drugs in the initial medical order according to the patient's use risk index, and adjust the dosage corresponding to the drugs in the initial medical order according to the patient's basic information to obtain the recommended medical order.

6. The system for generating medication prescriptions according to claim 1, characterized in that: The system further includes a graph construction module, wherein the graph construction module is specifically configured to: Obtain the instructions for use of each drug and the drug combination records in the real historical medical records; For each of the instruction documents, extracting conflicting drugs and combined drugs associated with the corresponding drug from the instruction document; Build a graph database based on the conflicting drugs and combined drugs associated with each drug; The actual combined drugs of each drug are determined based on the drug combination records, and the graph database is updated according to the actual combined drugs of each drug.

7. The system for generating medication prescriptions according to claim 1, characterized in that: The system further includes a nutrition assistance doctor's advice module, which is specifically used for: Determine the inventory status of each nutritional medicine; Determining the nutrition assistance prescription for the target patient according to the diagnosis result and the inventory status; Based on the physiological indicator detection data and the upper and lower limits corresponding to each preset physiological indicator, determining a risk physiological indicator among each preset physiological indicator, and determining a prohibited nutrient component corresponding to the risk physiological indicator; If the nutritional assistance prescription contains the prohibited nutrients, the nutritional assistance prescription is updated based on the diagnosis result, the inventory status and the prohibited nutrients.

8. The system for generating medication prescriptions according to claim 1, characterized in that: The system further comprises a doctor's advice feedback module, wherein the doctor's advice feedback module is used to: In response to receiving a doctor's order rejection signal fed back by the doctor, obtaining a rejection reason text corresponding to the recommended drug order; Determine the recommended medication order as a negative sample, and determine the problem type of the recommended medication order based on the rejection reason text; The recommended medication prescription is written into a database corresponding to the problem type, wherein the database is used to perform reinforcement learning on a model related to the problem type.

9. The system for generating medication prescriptions according to claim 1, characterized in that: The system further includes a dynamic optimization module, wherein the dynamic optimization module is used to: In response to receiving the medical order use signal fed back by the doctor, the recommended drug medical order is associated with the patient basic information and stored, and the dynamic medical order optimization condition corresponding to the target patient is determined according to the recommended drug medical order and the patient basic information; In response to detecting the real-time physiological data of the target patient, it is determined whether the target patient meets the dynamic medical order optimization condition based on the real-time physiological data, and if so, the recommended drug medical order is adjusted based on the real-time physiological data.

10. A method for generating a drug prescription, characterized in that: include: Determine the scenario type of the current doctor's order recommendation scenario; In response to the scenario type being an emergency medical advice recommendation, determining a recommended medication advice for the target patient based on the target patient's diagnostic results, imaging test data, physiological index test data, and call recording data; In response to the scenario type being chronic disease medical advice recommendation, a recommended drug advice for the target patient is determined according to the target patient's diagnosis result, basic patient information, and a pre-built graph database, wherein the graph database describes conflict relationships and combined use relationships between drugs; Determine the diagnosis and treatment action according to the diagnosis result and the basic information of the patient, and determine the evidence label corresponding to the drug in the recommended drug order, and use the diagnosis and treatment action and the evidence label as auxiliary judgment information; The recommended drug prescription and the auxiliary judgment information are sent to the doctor.

Images