Medical prescription auditing and medication safety management and control method and device, equipment and storage medium

Abstract

The invention discloses a medical prescription auditing and medication safety management and control method, device and equipment and a storage medium, and relates to the technical field of medical informatization and health big data, the method comprises the following steps: obtaining drug information, patient allergy history and multi-dimensional health data in a target prescription, and constructing a prescription data set; in combination with a medicine knowledge base and a taboo database, intelligent verification is carried out on the medication rationality of the prescription by utilizing a Duros rule engine and a graph neural network model, and a verification result and verification detail data are output; if the verification result is unreasonable, marking the prescription as a risk prescription, generating a medication risk assessment report and a prescription modification suggestion based on verification detail data, and pushing the report and the suggestion to a corresponding doctor terminal; and if the verification result is reasonable, generating personalized medication guidance through prescription-patient feature matching, and sending the personalized medication guidance to the doctor terminal, the patient terminal and the pharmacy terminal. According to the application, intelligent prescription checking and medication safety guarantee can be realized through risk assessment and personalized adaptation.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of medical informatization and health big data, in particular to a medical prescription auditing and medication safety control method, device, equipment and storage medium. BACKGROUND

[0002] Under the background of the increasing complexity of the current medical system and the continuous growth of the types of drugs, rational drug use and patient safety have become the core concern of medical institutions. At the same time, the high incidence of chronic diseases, the coexistence of multiple diseases and the universalization of combined drug use have significantly increased the complexity of prescriptions, and the traditional manual auditing mode has been difficult to meet the efficient, accurate and full-coverage medication safety needs.

[0003] At present, most medical institutions use a hybrid mode of "manual + information system assistance" for prescription auditing, and some large hospitals have deployed an electronic prescription pre-audit system to achieve preliminary screening through built-in drug compatibility contraindication library, dose threshold rules, and allergy history comparison logic. Primary medical institutions rely more on pharmacists' experience for post-comment or sampling audit. In addition, some regions have tried to build regional prescription auditing centers to provide unified prescription auditing services for member units of the medical community and improve the level of rational drug use at the grassroots level.

[0004] However, the existing approach still has obvious limitations: first, there is a lack of quantitative evaluation mechanism for medication risk, which cannot distinguish between high, medium and low risk prescriptions and implement graded intervention; second, the data island problem between systems is prominent, and it is difficult to effectively integrate key information such as patient's history of medication, inspection results, etc., affecting the comprehensiveness of the audit; third, the professional competence of grassroots pharmacists is uneven, and they rely too much on system prompts and lack of clinical judgment support, which may instead cause "alarm fatigue" or blind release. Therefore, how to achieve intelligent prescription auditing and medication safety protection through risk assessment and individualized adaptation has become a problem to be solved. SUMMARY

[0005] The present application aims to provide a medical prescription auditing and medication safety control method, device, equipment and storage medium, which aims to solve the technical problem of how to achieve intelligent prescription auditing and medication safety protection through risk assessment and individualized adaptation.

[0006] To achieve the above-mentioned purpose, the present application provides a medical prescription auditing and medication safety control method, which comprises: obtaining drug information, patient allergy history and multi-dimensional health data in a target prescription to obtain a prescription data set; based on the prescription data set, the drug knowledge base and the contraindication database, the medication rationality of the target prescription is verified by a DURUS rule engine and a graph neural network model to obtain verification results and verification details data; when the check result is unreasonable, marking the target prescription as a risky prescription, generating a medication risk assessment report and a prescription modification suggestion according to the check detail data, and sending the medication risk assessment report and the prescription modification suggestion to a doctor terminal corresponding to the target prescription; when the check result is reasonable, performing prescription-patient feature matching according to the prescription data set and the check detail data, generating individualized medication guidance, and sending the individualized medication guidance to the doctor terminal, the patient terminal, and the pharmacy terminal.

[0007] In an embodiment, the step of checking the medication rationality of the target prescription based on the prescription data set, the drug knowledge base, and the contraindication database by the DURUS rule engine and the graph neural network model to obtain a check result and check detail data comprises: According to the department type corresponding to the target prescription, a matched scenario-based rule subset is called from the drug knowledge base; The prescription data set, the scenario-based rule subset, and the allergic contraindication data in the contraindication database are input into the DURUS rule engine to check medication timing conflicts and physiological state contraindications to obtain a preliminary screening result; According to the preliminary screening result and the patient's historical prescription records, a patient medication similarity matrix is constructed; The patient medication similarity matrix is associated and checked by the graph neural network model to obtain a risk difference coefficient; According to the preliminary screening result and the risk difference coefficient, medication-examination item linkage checking is performed to obtain a check result and check detail data containing medication risk points and risk confidence.

[0008] In an embodiment, the step of inputting the prescription data set, the scenario-based rule subset, and the allergic contraindication data in the contraindication database into the DURUS rule engine to check medication timing conflicts and physiological state contraindications to obtain a preliminary screening result comprises: The taking time, taking frequency, patient physiological state information, and drug information in the prescription data set are parsed; Based on the taking time and the taking frequency, the timing conflict judgment rules in the scenario-based rule subset are called by the DURUS rule engine to compare whether the taking time intervals of each drug combination in the drug information meet the preset time length requirement to obtain a timing conflict check result; Based on the patient physiological state information and the allergic contraindication data in the contraindication database, the physiological contraindication rules in the scenario-based rule subset are called by the DURUS rule engine to check the matching of the patient physiological state and the drug contraindication components to obtain a physiological contraindication check result; The timing conflict check result and the physiological contraindication check result are respectively classified and labeled; According to the time sequence conflict checking result and the physiological contraindication checking result after classification marking, conflict specific drugs, conflict types and contraindication basis are marked, and a preliminary screening result is generated.

[0009] In an embodiment, the graph neural network model comprises an input layer, a graph convolution module, an attention mechanism module and an output layer. The step of performing correlation verification on the patient-drug similarity matrix by the graph neural network model to obtain a risk difference coefficient comprises: The patient-drug association features in the patient-drug similarity matrix are initialized and coded by the input layer to obtain an initial feature vector; The initial feature vector is aggregated by the graph convolution module to obtain a node feature vector; The node feature vector is weighted and distributed by the attention mechanism module to obtain a weighted feature vector; The weighted feature vector is calculated by the full connection network of the output layer to obtain a risk deviation degree, and a risk difference coefficient is obtained.

[0010] In an embodiment, the step of performing drug-examination item linkage verification according to the preliminary screening result and the risk difference coefficient to obtain a verification result and verification detail data containing drug risk points and risk confidence comprises: Obtain the drug pre-requisite inspection item requirements corresponding to the drugs in the target prescription from the drug knowledge base; According to the drug pre-requisite inspection item requirements, the patient examination item results in the prescription data set and the conflict identification in the preliminary screening result, it is judged whether there is an inspection item missing or abnormal, and an inspection item matching result is obtained; The risk difference coefficient and the inspection item matching result are weighted and calculated to obtain a comprehensive risk confidence; According to the conflict identification, the inspection item matching result and the comprehensive risk confidence, verification detail data containing drug risk points and risk confidence are generated; When the comprehensive risk confidence is greater than or equal to a preset confidence threshold, the verification result is obtained as unreasonable; When the comprehensive risk confidence is less than the preset confidence threshold, the verification result is obtained as reasonable.

[0011] In an embodiment, when the verification result is unreasonable, the target prescription is marked as a risk prescription, and a drug risk assessment report and a prescription modification suggestion are generated according to the verification detail data, and the drug risk assessment report and the prescription modification suggestion are sent to the doctor terminal corresponding to the target prescription. when the check result is unreasonable, marking the target prescription as a risk prescription; matching the risk confidence in the check detail data with a preset risk level division threshold to mark a corresponding risk level for the risk prescription; generating a drug substitution scheme based on the drug knowledge base, the multi-dimensional health data, and the medication risk point in the check detail data; filling the basic information of the risk prescription, the medication risk point, the risk level, and the drug substitution scheme into a preset report template to obtain a medication risk assessment report; sending the medication risk assessment report and the prescription modification suggestion to the doctor terminal corresponding to the target prescription.

[0012] In an embodiment, when the check result is reasonable, the step of performing prescription-patient feature matching according to the prescription data set and the check detail data, generating personalized medication guidance, and sending the personalized medication guidance to the doctor terminal, the patient terminal, and the pharmacy terminal comprises: when the check result is reasonable, extracting the patient's basic diseases, work and rest habits, and drug taking requirements from the prescription data set; matching the drug taking requirements with the work and rest habits, and matching the patient's basic diseases with the medication risk point in the check detail data to obtain a feature matching result; generating personalized medication guidance including specific taking time, dietary restrictions, and adverse reaction handling plans according to the feature matching result; sending the personalized medication guidance to the doctor terminal, the patient terminal, and the pharmacy terminal.

[0013] In addition, to achieve the above-mentioned purpose, the present application also proposes a medical prescription auditing and medication safety control device, which comprises: a data acquisition module for obtaining drug information, patient allergy history, and multi-dimensional health data in a target prescription to obtain a prescription data set; a prescription check module for checking the medication rationality of the target prescription based on the prescription data set, a drug knowledge base, and a contraindication database through a DURUS rule engine and a graph neural network model to obtain a check result and check detail data; a prescription modification module for marking the target prescription as a risk prescription when the check result is unreasonable, and generating a medication risk assessment report and a prescription modification suggestion according to the check detail data, and sending the medication risk assessment report and the prescription modification suggestion to the doctor terminal corresponding to the target prescription; The medication guidance module is configured to perform prescription-patient feature matching based on the prescription data set and the verification detail data when the verification result is reasonable, generate personalized medication guidance, and send the personalized medication guidance to the doctor terminal, the patient terminal, and the pharmacy terminal.

[0014] In addition, to achieve the above-mentioned purpose, the present application also provides a medical prescription auditing and medication safety control device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the medical prescription auditing and medication safety control method as described above.

[0015] In addition, to achieve the above-mentioned purpose, the present application also provides a storage medium, which is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the medical prescription auditing and medication safety control method as described above.

[0016] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the medical prescription auditing and medication safety control method as described above.

[0017] The one or more technical solutions provided by the present application have at least the following technical effects: First, the drug information, patient allergy history, and multi-dimensional health data in the target prescription are acquired, and are integrated to form a structured prescription data set, which provides a comprehensive patient-prescription context for subsequent accurate auditing and effectively avoids misjudgment caused by missing information. Then, based on the prescription data set, in combination with the drug knowledge base and the contraindication database, the explicit violation items are efficiently logically matched by using the DURUS rule engine, and the implicit risks in the scenes of multi-drug combination and complex comorbidity are identified by using the graph neural network model. The verification result and detailed verification detail data are output by fusing the two, which significantly improves the coverage and accuracy of the medication rationality judgment. When the verification result is unreasonable, the system marks the target prescription as a risk prescription, and automatically generates a medication risk assessment report and a prescription modification suggestion containing risk explanation and specific optimization path based on the verification detail data, and pushes them to the corresponding doctor terminal, so as to facilitate the doctor to quickly understand the problem and adjust the prescription, and improve the intervention efficiency. When the verification result is reasonable, the system further performs prescription-patient feature matching, generates personalized medication guidance containing specific taking time, dietary taboo, and adverse reaction coping measures, and synchronously sends the personalized medication guidance to the doctor terminal, the patient terminal, and the pharmacy terminal, so as to ensure that the three parties cooperatively execute the medication plan on the basis of consistent information, and enhance the compliance and safety. The present application can realize prescription intelligent auditing and medication safety guarantee through risk assessment and personalized adaptation. BRIEF DESCRIPTION OF DRAWINGS

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0020] Figure 1 This is a flowchart illustrating an embodiment of the medical prescription review and medication safety management method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the medical prescription review and medication safety management method of this application. Figure 3 This is a schematic diagram of the module structure of the medical prescription review and medication safety management device according to an embodiment of this application; Figure 4 This is a schematic diagram of the hardware operating environment involved in the medical prescription review and medication safety management method in the embodiments of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] It should be noted that the executing entity of this application embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device capable of realizing the above functions, such as a prescription review and medication safety management system. The following description uses a prescription review and medication safety management system as an example to illustrate this embodiment and the subsequent embodiments.

[0025] Based on this, the embodiments of this application provide a method for medical prescription review and medication safety management, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the medical prescription review and medication safety management method of this application.

[0026] In this embodiment, the medical prescription review and medication safety management method includes steps S10 to S40: Step S10: Obtain drug information, patient allergy history, and multidimensional health data from the target prescription to obtain the prescription dataset.

[0027] It should be noted that a target prescription refers to a medication regimen prescribed by a clinician for a specific patient, intended for the treatment, prevention, or diagnosis of a disease, including core information such as the selected medication and its administration method. Drug information refers to the specific attributes of each medication in the target prescription, including the drug name, single dose, daily dosing frequency, route of administration, and course of treatment, used to clarify the standard of medication use. Patient allergy history refers to records of past hypersensitivity reactions to specific drugs, excipients, or related compounds, covering information such as the allergen name, reaction type, and severity, and is a key basis for assessing medication safety. Multidimensional health data refers to a comprehensive set of clinical indicators reflecting the patient's overall health status, including age, weight, underlying diseases (such as hypertension, diabetes, etc.), liver and kidney function indicators, and other physiological or pathological parameters closely related to drug metabolism and safety. The prescription dataset refers to a unified data set formed by structurally integrating the drug information, patient allergy history, and multidimensional health data from the target prescription, used to support subsequent intelligent review and risk assessment analysis.

[0028] Understandably, the prescription review and medication safety management system first obtains the complete content of the target prescription from the Hospital Information System (HIS) or electronic prescription platform, extracting drug information such as drug name, single dose, frequency of administration, route of administration, and course of treatment for each medication. Second, the system uses the patient's unique identifier (such as ID card number or medical record number) to link to the Electronic Health Record (EHR) in real time, retrieving the patient's allergy history and multidimensional health data including age, underlying disease diagnosis codes, and liver and kidney function test results. Finally, the system standardizes, aligns, and logically validates the above three parts of information according to a preset data model, merging them to generate a patient-centric prescription dataset containing complete clinical context for subsequent risk assessment and intelligent review. This is done to ensure that the review process is not only based on the prescription itself but also fully considers the individual characteristics of the patient, improving the accuracy and clinical applicability of medication safety judgments.

[0029] Step S20: Based on the prescription dataset, drug knowledge base, and contraindication database, the rationality of medication use in the target prescription is verified using the Duluth rule engine and graph neural network model to obtain verification results and verification details.

[0030] It should be noted that the drug knowledge base refers to a structured collection of drug information built into the system, containing authoritative data on the pharmacological classification, indications, usual dosage ranges, metabolic pathways, adverse reactions, and known interactions with other drugs for various types of drugs, used to support judgments on the rationality of drug use. The contraindication database refers to a data resource specifically collecting information on drug contraindications, covering absolute contraindications (such as specific allergies, contraindications in cases of severe hepatic or renal insufficiency) and relative contraindications (such as pregnancy stage, cautionary cues for specific disease states), providing a basis for identifying allergic contraindications and drug risks in special populations. The Drools rule engine is an open-source Business Rule Management System (BRMS) based on Java, capable of transforming clinical drug use guidelines, consensus, and expert experience into executable "if-then" logical rules, and efficiently matching and reasoning on prescription datasets at runtime to quickly screen for clear violations such as overdosing, duplicate medication, and drug incompatibilities. Graph Neural Network (GNN) is a deep learning architecture that models entities such as drugs, diseases, and patient characteristics as nodes in a graph, and relationships such as drug interactions, comorbidities, and metabolic pathways as edges. It utilizes message passing mechanisms to learn higher-order semantic relationships, thereby identifying complex, implicit, or non-linear medication risks that rule engines struggle to cover, such as the potential cumulative toxicity effects of multiple drug combinations. The verification result refers to the system's comprehensive judgment on the overall rationality of the target prescription, typically expressed as "pass," "warning," or "block," indicating the existence of unacceptable medication risks. Verification details data refers to the structured explanatory information generated based on the verification result, including the specific risk type triggered (e.g., drug interactions, dosage exceeding limits, allergic contraindications), the names of the drugs involved, the violated rule number or risk level, and recommended interventions, used to support pharmacist review and clinical decision-making.

[0031] Understandably, firstly, the prescription review and medication safety management system uses the existing prescription dataset as input, while simultaneously loading the latest drug knowledge base and contraindication database from local or cloud sources to ensure that the rules and medical evidence used are valid. Secondly, the system feeds the drug information, patient allergy history, and multidimensional health data from the prescription dataset into the Duluth rule engine, which then uses approximately 500 to 1000 pre-defined structured clinical rules (such as "If the patient's glomerular filtration rate is less than 30 mL / min / 1.73 m...)" to determine the appropriate rule. 2The system performs matching and reasoning on each item (e.g., disabling a certain drug if it violates a specific rule) to identify violations of explicit medication guidelines. Simultaneously, it constructs a heterogeneous graph from the prescription's elements, including drugs, patient diseases, and physiological indicators. Nodes include drugs, diseases, and laboratory indicators, while edges represent known interactions or clinical associations. This graph is then input into a trained graph neural network model, which calculates the potential risk score of each drug combination within the current patient context through multi-layered message passing to capture complex interactions that rules cannot cover. Finally, the system performs weighted fusion and priority ranking of the hard violations output by the Duluth rule engine and the soft risks output by the graph neural network model, generating a comprehensive verification result and simultaneously outputting structured verification details, including the specific type of each risk, the drugs involved, the triggering logic or basis, the risk level, and the recommended handling method. This approach balances the interpretability of the rules with the generalization ability of the model, ensuring review efficiency while improving the accuracy of risk identification in individualized and complex medication scenarios.

[0032] Step S30: When the verification result is unreasonable, the target prescription is marked as a risk prescription, and a medication risk assessment report and prescription modification suggestions are generated based on the verification details data. The medication risk assessment report and prescription modification suggestions are then sent to the doctor's terminal corresponding to the target prescription.

[0033] It should be noted that a risk prescription refers to a target prescription identified as having inappropriate medication issues (such as drug interactions, dosage exceeding limits, allergies, contraindications, etc.) during the verification process. The system labels these prescriptions as "risk" to distinguish them from reasonable prescriptions, facilitating subsequent focused intervention and tracking. A medication risk assessment report is a structured document automatically generated based on verification details, detailing the specific medication issues in the risk prescription, including the risk type, involved drugs, relevant patient health indicators, risk mechanism, potential clinical consequences, and evidence sources, clearly communicating the basis for the risk to the physician. Prescription modification suggestions refer to actionable adjustment plans proposed by the system based on the medication risk assessment report, combined with the drug knowledge base and clinical guidelines, for each inappropriate issue. These may include replacing medications with alternatives, adjusting dosages, changing dosing frequency, or adding monitoring items, aiming to help physicians quickly optimize prescriptions. The physician terminal refers to the clinical workstation device or application used by the physician issuing the target prescription. This is typically a computer terminal on the hospital intranet, a mobile ward round tablet, or a physician interface integrated into the electronic medical record system. It is used to receive the medication risk assessment report and prescription modification suggestions pushed by the system and supports online viewing, confirmation, or modification of prescriptions.

[0034] As an example, the steps of marking the target prescription as a risk prescription when the verification result is unreasonable, generating a medication risk assessment report and prescription modification suggestions based on the verification details data, and sending the medication risk assessment report and prescription modification suggestions to the doctor's terminal corresponding to the target prescription include: marking the target prescription as a risk prescription when the verification result is unreasonable; matching the risk confidence level in the verification details data with a preset risk level classification threshold to mark the risk prescription with the corresponding risk level; generating a drug alternative based on the drug knowledge base, the multidimensional health data, and the medication risk points in the verification details data; filling the basic information of the risk prescription, the medication risk points, the risk level, and the drug alternative into a preset report template to obtain a medication risk assessment report; using the drug alternative as a prescription modification suggestion, and sending the medication risk assessment report and prescription modification suggestions to the doctor's terminal corresponding to the target prescription.

[0035] Risk confidence level refers to the quantified value of the system's credibility in judging a certain medication risk during the verification process. It is usually derived from the rule matching strength of the Duluth rule engine or the probability score output by the graph neural network model, and is used to reflect the likelihood of the risk existing. Preset risk level classification thresholds refer to the numerical boundaries pre-set by the system to map risk confidence levels to specific risk levels. For example, a confidence level of 0.0–0.3 is classified as low risk, 0.3–0.7 as medium risk, and 0.7–1.0 as high risk, to achieve graded risk management. Risk level refers to the classification label assigned to the risk prescription after matching the risk confidence level with the preset risk level classification threshold. It is usually divided into three levels: "low risk," "medium risk," and "high risk," used to guide subsequent intervention priorities and physician response strategies. Medication risk points refer to specific irrational medication issues clearly indicated in the verification details data, such as "the combined use of aspirin and warfarin increases the risk of bleeding" or "cephalosporin drugs may have cross-allergy potential in patients with a known history of penicillin allergy," etc. Each item corresponds to an explainable risk event. Drug substitution options refer to at least two clinically equivalent or safer alternative drugs recommended by the system from the drug knowledge base for each medication risk point, taking into account factors such as indication matching, patient liver and kidney function, underlying diseases, and allergy history. Basic information refers to the core identification and clinical information associated with the risk prescription, including patient name, medical record number, prescription date, original prescription drug list, prescribing physician's name and department, etc., to ensure accurate correspondence between the report and the prescription. Preset report templates refer to the system's built-in standardized structured document format, containing fixed fields such as risk level identification areas, a list of medication risk points, a drug substitution comparison table, and a summary of the patient's multidimensional health data, used to automatically fill in the content and generate a uniformly formatted, easy-to-read medication risk assessment report.

[0036] First, when the system determines that the verification result is unreasonable, it immediately updates the status field of the target prescription to "risk prescription" in the prescription management database and records the timestamp and review serial number for subsequent tracking and auditing. Second, the system extracts the risk confidence level corresponding to each medication risk point from the verification details data, compares it with the preset risk level classification threshold, and if there are multiple risk points, takes the level corresponding to the highest confidence level as the final risk level of the risk prescription and writes it into its metadata. Then, for each medication risk point, the system executes a drug alternative generation process: first, based on the pharmacological classification, indication code, and dosage form of the original drug, it filters out a list of candidate drugs with the same therapeutic purpose and no contraindications from the drug knowledge base, and then combines the patient's multidimensional health data (such as liver function ALT (Alanine Aminotransferase) value, glomerular filtration rate eGFR (estimated Glomerular Filtration) value, etc.) The system filters out unsuitable options by checking the glomerular filtration rate (GFR), allergy history, etc., and ultimately retains at least two safer, dose-adjustable alternatives that are covered by local medical insurance or hospital catalogs. Each alternative is then labeled with a recommendation reason (e.g., "no CYP450 enzyme interaction" or "suitable for patients with eGFR ≥ 20 mL / min"). Next, the system calls a preset report template—which is based on HTML or PDF. The structured document defined by the schema includes fixed blocks such as "Patient Basic Information Area," "Risk Level Identifier," "Drug Risk Point Details Table," and "Alternative Solution Comparison Matrix." It automatically fills in the corresponding positions according to field mapping rules with basic information of the risk prescription (including patient name, medical record number, prescribing department, and original prescription drug list), identified drug risk points, determined risk levels, and generated drug alternatives (including drug name, recommended dosage, and replacement basis), generating a standardized and complete drug risk assessment report. Finally, the system packages the above drug risk assessment report as a PDF attachment and provides drug alternatives as prescription modification suggestions via structured JSON or pop-up prompts. This is pushed in real-time to the doctor's terminal corresponding to the target prescription through the hospital integration platform's message middleware (such as HL7 or WebSocket channels), ensuring that doctors receive actionable intervention information immediately after prescribing. This approach aims to provide accurate, interpretable, and executable drug optimization support while ensuring clinical efficiency, reducing medical risks caused by irrational drug use.

[0037] Step S40: When the verification result is reasonable, perform prescription-patient feature matching based on the prescription dataset and the verification details data to generate personalized medication guidance, and send the personalized medication guidance to the doctor terminal, patient terminal and pharmacy terminal.

[0038] It should be noted that personalized medication guidance refers to the automatically generated targeted medication instructions based on drug information in the prescription dataset and individual patient characteristics (such as age, liver and kidney function, underlying diseases, allergy history, etc.), combined with medication regimens confirmed to be risk-free in the verification details data. This includes recommended administration times (such as before meals, before bedtime), foods or activities to avoid (contraindications), possible adverse reactions and coping strategies, and precautions for special populations, aiming to improve patient compliance and medication safety. The patient terminal refers to the smart device or application used by the patient, such as the hospital's official app, WeChat mini-program, self-service machine, or SMS platform, to receive and view personalized medication guidance information related to their prescription. The pharmacy terminal refers to the workstation or dispensing system interface used by pharmacists in hospital pharmacies or community pharmacies, used to verify the rationality of prescriptions before dispensing and simultaneously obtain personalized medication guidance content, so as to provide accurate medication instructions to patients or print medication labels at the time of dispensing.

[0039] As an example, the step of performing prescription-patient feature matching based on the prescription dataset and the verification details data to generate personalized medication guidance when the verification result is reasonable, and sending the personalized medication guidance to the doctor's terminal, patient's terminal, and pharmacy terminal includes: when the verification result is reasonable, extracting the patient's underlying diseases, daily routines, and medication requirements from the prescription dataset; matching the medication requirements with the daily routines, and matching the patient's underlying diseases with medication risk points in the verification details data to obtain feature matching results; generating personalized medication guidance containing specific administration times, dietary restrictions, and adverse reaction management plans based on the feature matching results; and sending the personalized medication guidance to the doctor's terminal, patient's terminal, and pharmacy terminal.

[0040] The patient's underlying diseases refer to diagnosed chronic diseases or long-term pathological states recorded in the patient's electronic health record, such as hypertension, type 2 diabetes, coronary heart disease, and chronic kidney disease. These are used to assess the safety and suitability of drug selection and medication regimens. Daily routines refer to the patient's regular behavioral patterns in daily life, including usual wake-up time, bedtime, meal times, and whether they work night shifts. This information is usually derived from patient-completed questionnaires or wearable device data and is used to optimize medication schedules to improve adherence. Medication usage requirements refer to the specific guidelines defined in the drug knowledge base regarding the timing of administration, food effects, and special precautions for each drug in clinical use, such as "take on an empty stomach," "take before bedtime," "avoid taking with dairy products," and "abstain from alcohol while taking the medication." Feature matching results refer to the structured adaptation conclusions output by the system after aligning the medication requirements with the patient's daily routines in terms of time and behavior (e.g., mapping "take after breakfast" to the patient's actual breakfast time of 07:30), and at the same time performing correlation analysis on the patient's underlying diseases and potential risk points that have been excluded but require attention in the verification details data (e.g., "although no contraindication has been triggered, the patient has cirrhosis and should be wary of slowed metabolism of a certain drug"). These results serve as the direct basis for generating personalized medication guidance.

[0041] First, when the verification result is reasonable, the prescription review and medication safety management system extracts three types of structured information from the prescription dataset: the patient's underlying disease, daily routine (e.g., "breakfast 07:30, lunch break 12:30–13:30, bedtime 22:00"), and the medication requirements for each drug (e.g., "atorvastatin: once daily, after dinner; avoid taking with grapefruit"). Second, the system performs two parallel matching paths: one path maps the time semantics in each medication requirement (e.g., "after dinner") to the patient's actual meal time in their daily routine (e.g., "dinner 18:30") according to rules, generating a specific medication time (e.g., "19:00") through a preset time offset logic (e.g., "after meal = meal time + 30 minutes"). The other path iterates through all medication risk points in the verification details data that have not triggered interception but are marked as "need attention" (e.g., "patient's eGFR is 45 mL / min / 1.73m). 2The system first identifies a drug that is primarily excreted through the kidneys. Then, it cross-validates this with the patient's underlying medical condition. If a correlation is found (e.g., chronic kidney disease and drugs excreted through the kidneys), a targeted warning is added to the guidance. Based on the matching results, the system uses a template-filling and natural language generation engine: for each drug, it sequentially combines "specific dosing time," "dietary or behavioral restrictions," "special reminders based on the patient's disease background," and "common adverse reaction management plans" (e.g., "If muscle pain occurs, immediately discontinue atorvastatin and test for creatine kinase"). Through sentence coherence optimization, it generates a clear, conversational, yet professional personalized medication guidance text for the patient. Finally, the system applies this personalized guidance. Medication instructions are broken down into three adapted versions based on roles: a complete version for doctors' terminals for informed consent and record-keeping; a simplified, easy-to-read version (with icons and highlighted key points) for patients' terminals for daily compliance; and a structured, itemized version (including a drug-time-contraindication checklist) for pharmacy terminals for verification and verbal explanation during dispensing. These versions are simultaneously pushed to the doctor's, patient's, and pharmacy terminals via the hospital's integrated platform's messaging service. This approach aims to further achieve patient-centered, refined medication management on top of prescription compliance. By providing guidance tailored to individual lifestyles and health conditions, it significantly improves medication adherence, reduces potential adverse events, and strengthens collaboration among doctors, pharmacies, and patients.

[0042] As an example, after the steps of performing prescription-patient feature matching based on the prescription dataset and the verification details data to generate personalized medication guidance when the verification result is reasonable, and sending the personalized medication guidance to the doctor's terminal, patient's terminal, and pharmacy terminal, the method further includes: receiving initial medication feedback data sent by the patient's terminal; sending the initial medication feedback data to the doctor's terminal so that the doctor's terminal can review and annotate the initial medication feedback data and provide target medication feedback data; performing conflict verification and difference analysis on the target medication feedback data based on the drug knowledge base and the contraindication database to obtain a feedback conflict analysis report; and sending the feedback conflict analysis report to the pharmacy terminal so that the pharmacy terminal can update the drug knowledge base and the contraindication database.

[0043] Initial medication feedback data refers to information proactively reported by patients through their terminals regarding their actual medication use after starting prescription medication. This includes whether medication was taken on time, whether any discomfort symptoms occurred, specific adverse reactions (such as nausea, rash, dizziness, etc.), and changes in patients' subjective feelings after taking the medication. Target medication feedback data refers to structured feedback information generated by physicians after receiving the initial medication feedback data and reviewing, annotating, and correcting it based on clinical judgment. This includes confirming the causal relationship between adverse reactions and the drug, ruling out non-drug factors, supplementing diagnostic opinions, or adjusting subsequent medication plans. This data serves as the authoritative version for system analysis. Feedback conflict analysis reports are analysis documents generated by the system based on the drug knowledge base and contraindication database, comparing the medication events described in the target medication feedback data with existing knowledge rules. The reports include whether there are novel adverse reactions not covered by the knowledge base, inconsistencies between the patient's actual contraindications and database records, potential conflicts between the drug use scenario and existing contraindications, and suggestions for updating knowledge entries or adjusting the level of evidence.

[0044] The system first receives initial medication feedback data uploaded from the patient's terminal. This data, in the form of a structured form or natural language text, includes the patient's actual medication usage and descriptions of adverse reactions. Then, the system forwards the complete initial medication feedback data in real time to the prescribing doctor's terminal. The doctor clinically reviews the content on the terminal interface, confirming the correlation between symptoms and medication, correcting vague descriptions, marking the causal relationship level, and submitting the confirmed target medication feedback data. Next, the system calls upon the adverse reaction spectrum and contraindication rules in the drug knowledge base, as well as the patient's contraindication records in the contraindication database, to target... Key events in medication feedback data (such as "prolonged QT (QT interval, ventricular repolarization time) after taking a certain drug") are compared item by item with existing knowledge entries to identify any unrecorded adverse reactions, omissions of contraindications, or deviations in individual patient contraindication information. This process generates a feedback conflict analysis report that includes conflict type, location of discrepancies, evidence strength assessment, and knowledge update suggestions. Finally, the system pushes this report to the pharmacy terminal for review by pharmacy administrators to revise or expand relevant entries in the drug knowledge base and contraindication database, achieving dynamic optimization of the knowledge system.

[0045] This embodiment provides a method for medical prescription review and medication safety management. First, it acquires drug information, patient allergy history, and multidimensional health data from the target prescription, integrating them to form a structured prescription dataset. This provides a comprehensive patient-prescription context for subsequent accurate review, effectively avoiding misjudgments due to missing information. Next, based on this prescription dataset, and combining a drug knowledge base and a contraindication database, it utilizes the Duluth rule engine to perform efficient logical matching on explicit violations. Simultaneously, it identifies hidden risks in scenarios such as multidrug use and complex comorbidities through a graph neural network model. The two are then fused to output the verification result and detailed verification data, significantly improving the coverage of medication rationality judgment. The system assesses both breadth and accuracy. When the verification result is deemed unreasonable, the system marks the target prescription as a risk prescription and automatically generates a medication risk assessment report and prescription modification suggestions, including risk descriptions and specific optimization paths, based on the verification details. This report is then pushed to the corresponding doctor's terminal, allowing doctors to quickly understand the problem and adjust the prescription, thus improving intervention efficiency. When the verification result is deemed reasonable, the system further performs prescription-patient characteristic matching, generating personalized medication guidance that includes specific dosing times, dietary restrictions, and adverse reaction management measures. This guidance is simultaneously sent to the doctor's terminal, patient's terminal, and pharmacy terminal, ensuring that all three parties collaboratively execute the medication plan based on consistent information, enhancing adherence and safety. This embodiment achieves intelligent prescription review and medication safety assurance through risk assessment and personalized adaptation.

[0046] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in Embodiment 1 above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating the second embodiment of the medical prescription review and medication safety management method of this application. Step S20 of the medical prescription review and medication safety management method includes steps S21 to S24: Step S21: Based on the department type corresponding to the target prescription, retrieve the matching subset of scenario-based rules from the drug knowledge base.

[0047] It should be noted that department type refers to the professional category of the clinical department to which the target prescription belongs, reflecting the differences in patient groups and treatment characteristics, such as pediatrics, oncology, geriatrics, obstetrics and gynecology, and critical care medicine. The scenario-based rule subset refers to a set of structured medication rules selected from the drug knowledge base by department type, applicable to specific clinical scenarios. This includes common departmental contraindications (such as "quinolones are contraindicated in newborns"), special dosage conversion formulas (such as "dosage calculated based on body surface area for children" or "dosage adjusted according to eGFR for the elderly"), and warnings about common drug interactions in the specialty, aiming to improve the accuracy and applicability of prescription review in a specialty setting.

[0048] Understandably, firstly, the system extracts the department type field corresponding to the target prescription from the prescription data. This field is automatically recorded by the hospital information system when prescribing. Then, the system uses the department type as an index key to search for the associated scenario-based rule subset identifier in the rule directory of the drug knowledge base, and loads all the structured rule entries contained in the subset.

[0049] Step S22: Input the prescription dataset, the scenario-based rule subset, and the allergy contraindication data in the contraindication database into the Duluth rule engine to verify medication timing conflicts and physiological state contraindications, and obtain the initial screening results.

[0050] It should be noted that allergy contraindication data refers to drug contraindication information recorded in the contraindication database related to the patient's known allergens. This includes specific sensitizing substances (such as penicillin and sulfonamides), a list of drugs with cross-allergy risks, and their corresponding contraindication levels. This data is used to determine whether the target prescription contains drugs that the patient should avoid. Medication timing conflicts refer to situations where the timing of multiple medications in a prescription violates the minimum interval required by pharmacological or clinical guidelines. For example, two medications that require "fasting" are taken within 30 minutes before the same meal, or medications that interfere with each other's absorption are not taken at the predetermined interval (e.g., at least 2 hours apart). Physiological contraindications refer to restrictions on the use of certain medications based on the patient's current specific physiological condition (such as pregnancy, lactation, severe hepatic or renal insufficiency, etc.). For example, "Pregnancy category X drugs are contraindicated in pregnant women" or "Central nervous system depressants that can be secreted into breast milk are contraindicated during lactation." The initial screening result refers to the preliminary violation judgment set output by the Dulus rule engine after integrating the prescription dataset, the scenario-based rule subset, and allergy contraindication data in the contraindication database, and performing rule matching on medication timing conflicts and physiological state contraindications. It includes structured information such as the triggered rule number, the involved drugs, the conflict type, and whether it was blocked, which serves as the input basis for subsequent deep verification.

[0051] As an example, the step of inputting the prescription dataset, the scenario-based rule subset, and allergy contraindication data from the contraindication database into the Duluth rule engine to verify medication timing conflicts and physiological state contraindications to obtain preliminary screening results includes: parsing the administration time, administration frequency, patient physiological state information, and drug information in the prescription dataset; based on the administration time and administration frequency, calling the timing conflict judgment rules in the scenario-based rule subset through the Duluth rule engine to compare whether the administration time interval of each drug combination in the drug information meets the preset duration requirement, and obtaining the timing conflict verification result; based on the patient physiological state information and the allergy contraindication data in the contraindication database, calling the physiological contraindication rules in the scenario-based rule subset through the Duluth rule engine to check the matching between the patient's physiological state and the drug contraindication components, and obtaining the physiological contraindication verification result; classifying and labeling the timing conflict verification result and the physiological contraindication verification result respectively; and labeling the specific conflicting drug, conflict type, and contraindication basis according to the classified and labeled timing conflict verification result and physiological contraindication verification result to generate preliminary screening results.

[0052] Patient physiological status information refers to key clinical indicators reflecting the patient's current physical condition, centrally recorded in the prescription dataset. These include age, gender, pregnancy status and specific pregnancy stage (e.g., early or mid-pregnancy), breastfeeding status, liver function, and kidney function (e.g., eGFR or creatinine clearance). This information is used to determine the patient's tolerance and contraindications to specific drugs. Drug information refers to the structured attributes of each drug in the prescription dataset, including the drug's generic name, dosage form, single dose, route of administration, frequency of administration, and clearly indicated administration time (e.g., "after breakfast" or "before bedtime"). This serves as the basic input for timing and contraindication checks. Timing conflict determination rules refer to logical rules defined in the scenario-based rule subset used to determine whether multiple drugs interfere with each other in the time dimension. Examples include "probiotics and antibiotics should be taken at least 2 hours apart" and "proton pump inhibitors should be taken 30 minutes before other oral medications," to ensure that drug efficacy is not weakened or adverse interactions occur. Drug combinations refer to two or more drugs prescribed simultaneously for use within the same treatment cycle. The system pairs these drugs and checks each one individually for timing or pharmacological conflicts. Preset duration requirements refer to the minimum interval between drug administrations, set based on pharmaceutical evidence, such as "antibiotics and probiotics 2 hours apart" or "iron supplements and thyroid hormones 4 hours apart." These values ​​are fixed as rule parameters by the drug knowledge base or specialist guidelines. The timing conflict verification result refers to the judgment output by the Duluth rule engine after comparing the administration time of each drug pair with the preset duration requirements, indicating whether there is a violation of the timing rules. Allergy contraindication data refers to the drug contraindication records related to known allergens of the patient stored in the contraindication database, including the name of the sensitizing substance, a list of cross-reactive drugs, and their contraindication strength (e.g., "absolutely contraindicated" or "use with caution"). Physiological contraindication rules refer to medication restriction rules set for specific physiological states in the scenario-based rule subset, such as "ACEIs (Angiotensin-Converting Enzyme Inhibitors) are contraindicated during pregnancy" or "eGFR < 30 mL / min / 1.73m 2"Metformin is contraindicated during certain times," etc., is used for automatic screening of inappropriate medication situations. Contraindicated drug ingredients refer to active ingredients or excipients in a drug that are prohibited from use under specific physiological conditions, such as "drugs containing estrogen are contraindicated in breast cancer patients" or "oral solutions containing alcohol excipients are contraindicated during pregnancy." Physiological contraindication verification results refer to the judgment output generated by the Duluth rule engine after matching the patient's physiological state information with the contraindicated drug ingredients, indicating whether there is a medication contraindication due to physiological state. Specific conflicting drugs refer to the names or combinations of drugs identified as having temporal conflicts or physiological contraindications during the verification process, such as "Amoxicillin and Bifidobacterium Quadruple Live Bacteria Tablets." Conflict type refers to the specific category of the violation, divided into "temporal conflict" or "physiological state contraindication," used to distinguish the source of risk. Contraindication basis refers to the specific rule content or medical evidence source on which the contraindication judgment is triggered, such as "According to the 'Guidelines for Drug Use During Pregnancy,' thalidomide is contraindicated in pregnant women," used to provide traceable audit reasons.

[0053] First, the system parses each field from the prescription dataset to extract the administration time, frequency, patient physiological state information, and drug information for each medication. Second, the system pairs all medications together, calculates the actual dosing interval for each pair based on its administration time and frequency, and then loads the corresponding temporal conflict judgment rules from the scenario-based rule subset using the Duluth rule engine. Each rule is matched and judged to determine whether it violates the preset duration requirement, generating a structured temporal conflict verification result. Simultaneously, the system uses the patient's physiological state information and allergy contraindication data from the contraindication database as input, and calls the physiological contraindication rules from the scenario-based rule subset. The system checks each drug's ingredients to see if they trigger contraindications, outputting a physiological contraindication verification result for each drug. Then, it categorizes these two types of verification results: if any drug combination or single drug violates the rules, it's marked as "conflict exists"; otherwise, it's marked as "no conflict." Finally, the system iterates through all entries marked "conflict exists," extracting and writing the specific conflicting drug, conflict type, and contraindication basis (e.g., "Rule ID: TIM-004, requires an interval ≥ 2 hours" or "Patient eGFR = 28, below the metformin usage threshold of 30"). These fields are then assembled into a complete initial screening result according to a preset format. This is done to quickly screen out prescriptions that clearly violate clinical medication guidelines at an early stage, providing a high-quality, clearly structured input foundation for the subsequent complex risk analysis of the graph neural network model, thereby improving overall review efficiency and accuracy.

[0054] As an example, the construction steps of the Durus rule engine are as follows: Based on the drug's temporal conflict determination rules, physiological contraindication rules, and dosage restriction rules, structured rule clauses are formed; the structured rule clauses are converted into the Durus rule language format to construct a rule base that associates the drug knowledge base and the contraindication database; based on the rule base, the engine's rule executor, working memory, and inference engine are configured, and rule matching priorities are set to obtain the Durus rule engine.

[0055] Dosage restriction rules refer to the maximum / minimum dose thresholds and frequency restrictions for drugs set for specific populations (such as children, the elderly, and those with hepatic or renal insufficiency) or specific disease states. Examples include "adult acetaminophen single dose not exceeding 1g, total daily dose not exceeding 4g" or "eGFR < 30 mL / min / 1.73m 2 "Vancomycin dosage needs to be reduced by 50%." Structured rule clauses refer to logical units that standardize the above-mentioned medication timing rules, physiological contraindication rules, and dosage restriction rules according to a unified data model. Each clause includes a precondition (if), a judgment object, a threshold or constraint relationship, a conclusion (then), and a rule identifier, facilitating program parsing and execution. The Drools Rule Language (DRL) is a Java-based declarative rule writing syntax supported by the Drools rule engine. It uses a "when-then" structure to describe business logic and can be directly parsed by the Drools compiler and loaded into the rule engine for execution. The rule base is a collection of all structured rule clauses converted to DRL format. It is dynamically associated with the drug knowledge base and the contraindication database through a data source interface, ensuring that the drug name, contraindicated ingredients, dosage parameters, etc., in the rules can reference the latest authoritative data in real time. The rule executor is the core component in the Drools engine responsible for loading the rule base, managing the rule lifecycle, and triggering rule matching and execution, controlling the start and end of the entire inference process. The working memory refers to the runtime space that temporarily stores input facts during rule execution. Drug information and patient physiological state information from the prescription dataset are inserted into the working memory as fact objects for rule matching. The inference engine refers to the logic processing module within the Drools engine that implements rule matching, conflict resolution, and action execution. It uses the Rete algorithm (network matching algorithm) to efficiently identify rules that meet the conditions and schedule their execution according to priority. Rule matching priority refers to the strategy by which the system determines the execution order when multiple rules are triggered simultaneously, based on a preset priority order. Here, physiological contraindication rules have the highest priority (executed first), followed by timing conflict rules, and finally dosage restriction rules, to ensure that high-risk contraindication issues are intercepted first.

[0056] First, based on clinical guidelines, drug instructions, and specialist consensus, the system transforms the timing conflict judgment rules, physiological contraindication rules, and dosage restriction rules into structured rule clauses with clear preconditions, judgment logic, and conclusion actions. Each clause includes a rule ID, applicable department, trigger condition expression, violation level, and associated drug code. Second, the developers compile these structured rule clauses into rule files in the Drools rule language format according to the syntax requirements of the Drools engine. The "when" part uses MVEL expressions to reference fact objects in working memory (such as drug administration time, patient eGFR value), and the "then" part calls predefined actions (such as marking conflicts, recording evidence). Furthermore, real-time query logic for the drug knowledge base (obtaining drug metabolic pathways and dosage forms) and the contraindication database (querying allergen cross-reaction lists) is embedded in the rules through JPA (JavaPersistence API) or REST (Representational State Transfer) interfaces, thereby constructing a rule base that dynamically relates to external knowledge sources. Finally, based on this rule base, the system runs on Drools... The KieContainer initializes the rule executor, configures its working memory to receive fact objects injected from the prescription dataset, enables the Rete algorithm-based inference engine, and explicitly annotates the salience value (priority value, e.g., physiological contraindication rules set to 1000, timing conflict rules set to 500, and dosage restriction rules set to 100) in the metadata of each DRL rule. This ensures that when multiple rules are matched simultaneously, the engine executes them in the priority order of "physiological contraindication rules > timing conflict rules > dosage restriction rules." This is done to ensure that high-risk, irreversible contraindications (such as teratogenic effects of medication in pregnant women) are identified and blocked first, preventing low-priority rules from interfering with critical safety judgments, thereby improving the clinical reliability and risk control capabilities of the review process.

[0057] Step S23: Construct a patient medication similarity matrix based on the initial screening results and the patient's historical prescription records.

[0058] It should be noted that the patient's historical prescription record refers to the collection of prescription data previously issued and executed by the patient in the medical institution's information system. This includes complete prescription information for the last preset number of prescriptions (5 times), such as drug name, dosage, course of treatment, prescription date, and corresponding adverse reaction history (if reported). This information reflects the patient's long-term medication pattern and drug tolerance. The patient medication similarity matrix is ​​a structured numerical matrix constructed based on the initial screening results and the patient's historical prescription record. Rows represent drugs or medication characteristics in the current prescription, and columns represent corresponding items in historical prescriptions. Matrix elements are generated by calculating the similarity (e.g., cosine similarity) between the two in dimensions such as drug category, dosage level, medication sequence, and adverse reaction correlation. This matrix quantifies the consistency or deviation between the current prescription and the patient's past medication behavior, providing contextual basis for subsequent risk identification.

[0059] Understandably, the system first retrieves the patient's five most recent prescription records from the electronic health record. Second, it compares each medication in the current prescription with each of the five historical prescriptions, considering factors such as whether the medication's ATC (Anatomical Therapeutic Chemical Classification System) classification is the same, whether the dosage difference is within 20%, whether the administration time (e.g., morning or evening) is consistent, and whether there have been adverse reactions due to similar medications. Then, for each comparison result, a comprehensive similarity score is calculated according to preset weights (e.g., 1.0 point for identical ATC, 0.9 points for dosage difference ≤20%, 1.0 point for consistent administration time, and 1.0 point for no similar adverse reactions; the weighted average is then normalized to the 0–1 range). Finally, using the medication in the current prescription as rows and the five historical prescription records as columns, all similarity scores are filled into the corresponding positions to form a patient medication similarity matrix. This is done to help identify abnormal or high-risk prescriptions by quantifying the consistency between current medication use and the patient's past patterns, thereby improving the individualized accuracy of subsequent intelligent verification.

[0060] Step S24: The patient medication similarity matrix is ​​correlated and verified using a graph neural network model to obtain the risk difference coefficient.

[0061] It should be noted that the risk difference coefficient is a quantitative indicator output by the graph neural network model after verifying the correlation of the patient medication similarity matrix. It is used to characterize the degree of deviation between the current prescription and the patient's previous medication pattern in terms of safety. The coefficient comprehensively considers factors such as the rationality of drug replacement, the potential risks of introducing new drugs, and the possibility of recurrence of adverse reaction history. The higher the value, the more significant the potential medication risks or inconsistencies of the current prescription compared to historical medication.

[0062] As an example, the graph neural network model includes an input layer, a graph convolution module, an attention mechanism module, and an output layer. The step of performing association verification on the patient-drug similarity matrix using the graph neural network model to obtain a risk difference coefficient includes: initializing and encoding the patient-drug association features in the patient-drug similarity matrix through the input layer to obtain an initial feature vector; aggregating neighborhood information of the initial feature vector through the graph convolution module to obtain a node feature vector; assigning weights to the node feature vector through the attention mechanism module to obtain a weighted feature vector; and calculating the risk deviation of the weighted feature vector through the fully connected network of the output layer to obtain the risk difference coefficient.

[0063] The input layer is the module in the graph neural network model responsible for receiving and preprocessing the raw input data. It transforms the structured information in the patient-drug similarity matrix into a numerical representation that can be processed by subsequent networks. The graph convolution module is the core component in the model that performs graph convolution operations. By aggregating the feature information of each node (such as a drug or patient) and its neighboring nodes, it achieves the propagation and fusion of local structural information, thereby capturing high-order associations between drugs or between patients and drugs. The attention mechanism module is a weight learning submodule introduced into the graph neural network. It can dynamically allocate attention weights to different aggregation paths based on the importance of the relationships between nodes, highlighting association features that contribute more to risk assessment. The output layer is the last processing unit in the graph neural network model, typically composed of a fully connected network. It maps the high-dimensional features after graph convolution and attention weighting to the final prediction or evaluation metric. Patient-drug association features refer to the multidimensional attributes extracted from the patient-drug similarity matrix that describe the historical usage relationship and similarity between patients and various drugs, including the matching scores of current prescription drugs and historical drugs in dimensions such as ATC category, dosage, and adverse reaction history. The initial feature vector refers to the low-dimensional dense vector generated by the input layer after embedding and encoding the patient-drug association features (e.g., through linear transformation or lookup tables), serving as the initial representation of each node in the graph neural network. The node feature vector refers to the new feature representation containing contextual semantics obtained by the graph convolutional module after one or more rounds of neighborhood information aggregation, updated for each node (representing the drug or patient's medication status). The weighted feature vector refers to the enhanced feature representation output by the attention mechanism module after calculating attention weights based on the importance of each node's features and performing weighted summation or weighted concatenation of the node feature vectors. A fully connected network refers to a neural network structure in the output layer consisting of one or more linear transformation layers (including activation functions), used to compress and map the weighted feature vectors into a single scalar output.

[0064] First, the system concatenates the similarity scores (including ATC category matching, dosage difference, medication time consistency, and adverse reaction history association) of each current prescription drug in the patient medication similarity matrix with five historical prescriptions into a 4-dimensional patient-drug association feature vector. This vector is then linearly mapped to a 64-dimensional initial feature vector using the embedding matrix of the input layer, serving as the initial representation of each drug node in the graph. Second, on the constructed graph structure with drugs as nodes and historical associations with similarity greater than 0.5 as edges, the system performs two layers of graph convolution operations using the graph convolution module. Each layer aggregates the features of first-order neighboring nodes and transforms them through a learnable weight matrix, thereby generating a node feature vector that integrates the local medication pattern context. Then, the attention mechanism module calculates attention coefficients for the neighborhood features of each node (e.g., through a learnable query-key dot product), assigning higher weights to highly relevant historical medication paths and summing them to obtain a more discriminative weighted feature vector. Finally, this weighted feature vector is fed into the fully connected network of the output layer (containing a two-layer MLP of 64→32→1). The perceptron (multilayer perceptron) uses ReLU activation and sigmoid output to calculate a risk difference coefficient between 0 and 1. This is done so that the model can not only identify surface rule violations, but also learn "normal" patterns from individual patient medication trajectories and detect latent anomalies accordingly. When the current prescription deviates significantly from the patient's historical safe medication behavior, an alert can be issued through a high risk difference coefficient, even if no explicit rule is triggered, thereby improving the personalization and foresight of intelligent review.

[0065] As an example, the training steps of the graph neural network model include: acquiring historical prescription data, historical patient health data, and historical medication feedback data to obtain a sample dataset; dividing the sample dataset into a training set and a test set according to a preset ratio; extracting prescription entities, patient entities, feedback entities, and the attributes of each entity from the training set, and constructing a prescription-patient-feedback association graph based on the prescription-patient issuing object relationship, the corresponding feedback relationship between prescription and feedback, and the feedback subject relationship between patient and feedback; converting the training set into graph training data based on the prescription-patient-feedback association graph; training the graph neural network model using the graph training data, a preset learning rate, a preset number of iterations, and a cross-entropy loss function to obtain a reference model; validating the performance of the reference model using the test set and calculating the risk prediction accuracy of the reference model; when the risk prediction accuracy is less than a preset accuracy threshold, returning to the step of training the graph neural network model using the graph training data, a preset learning rate, a preset number of iterations, and a cross-entropy loss function to obtain the reference model; when the risk prediction accuracy is greater than or equal to the preset accuracy threshold, using the reference model as the trained graph neural network model.

[0066] Historical prescription data refers to past patient prescription records stored in the medical institution's information system, including structured information such as drug name, dosage, usage, frequency, prescription time, and prescribing physician. Historical patient health data refers to the patient's clinical background information corresponding to the above prescriptions, including age, gender, underlying diseases (such as hypertension, diabetes), allergy history, and multidimensional health parameters such as liver and kidney function indicators (such as eGFR, ALT). Historical medication feedback data refers to information reported by patients or medical staff regarding drug use outcomes after medication, including adverse reaction types (such as rash, elevated liver enzymes), medication effects (such as symptom relief, ineffectiveness), and the time of occurrence. The sample dataset refers to a structured training sample set formed by aligning and integrating the above three types of historical data according to the patient-prescription-feedback triplet. Each sample corresponds to a complete medication event and its outcome. The preset ratio refers to a manually set ratio used to divide the dataset, such as 8:2 or 7:3, representing the proportion of samples in the training set and the test set. The training set refers to a subset extracted from the sample dataset according to the preset ratio for model parameter learning. The test set refers to a subset of the sample dataset that was not used in training and is used to independently evaluate the model's generalization performance. A prescription entity is a node representing a single prescription in the graph construction, with core attributes including prescription ID, drug list, and dosage regimen. A patient entity is a node representing a patient, containing attributes such as patient ID, underlying diseases, allergy history, and physiological state. A feedback entity is a node representing a medication feedback, containing attributes such as feedback ID, adverse reaction type, medication effect level, and reporting time. The attributes of each entity are the specific field values ​​associated with the prescription, patient, and feedback entities, used to describe entity features and as initial feature inputs for graph nodes. The prescription-patient issuing object relationship refers to the semantic relationship where a prescription is received and executed by a patient, connected to the prescription and patient entities by directed edges in the graph. The prescription-feedback corresponding feedback relationship refers to the association generated by a specific prescription for a particular feedback, connected to the prescription and feedback entities by directed edges in the graph. The patient-feedback feedback subject relationship refers to the relationship where feedback is provided or experienced by a specific patient, connected to the patient and feedback entities by directed edges in the graph. The prescription-patient-feedback association graph refers to a heterogeneous graph structure built based on the three types of entities and their three relationships mentioned above, which fully depicts the clinical closed loop of "who (patient) used what (prescription) and what result (feedback)." Graph training data refers to transforming each sample in the training set into a subgraph instance (including nodes, edges, and node attributes) in the graph, for end-to-end training of the graph neural network model. The preset learning rate refers to the step size parameter of gradient descent during model optimization (e.g., 0.001), controlling the parameter update speed. The preset number of iterations refers to the maximum number of rounds to traverse the entire training set during training (e.g., 100 rounds), used to limit the training time.The cross-entropy loss function is an objective function used to measure the difference between the model's predicted risk labels (e.g., "high risk / low risk") and the true labels, guiding model parameter optimization. The reference model is a snapshot of the graph neural network model parameters obtained after a complete training cycle, used for subsequent validation. Risk prediction accuracy refers to the proportion of samples on the test set where the reference model correctly predicts medication risks (e.g., whether serious adverse reactions occur). The preset accuracy threshold is a pre-set target for model performance (e.g., 90%), used to determine whether to terminate training and adopt the current model.

[0067] First, the system batch exports structured historical prescription data, historical patient health data, and historical medication feedback data from the hospital's HIS, electronic health records, and patient follow-up system. It aligns these three tables using patient ID and prescription timestamps to generate sample records, each containing a complete closed loop of "one prescription – one patient – ​​one feedback," forming a sample dataset. Second, the sample dataset is randomly divided according to a preset ratio to ensure no overlap between the training and test sets. Then, for each sample in the training set, three nodes are created: a prescription entity identified by the prescription ID, a patient entity identified by the patient ID, and a feedback entity identified by the feedback ID. Three directed edges are established—from the patient entity to the prescription entity (representing the "prescription object"), from the prescription entity to the patient entity, and from the patient entity to the patient entity. The system points from the patient entity to the feedback entity (representing "corresponding feedback"), and from the patient entity to the feedback entity (representing "feedback subject"). Finally, it merges and removes duplicate nodes and edges from all samples to construct a global prescription-patient-feedback association graph. Next, it extracts the local subgraph (containing the sample's three entity nodes and their connecting edges) corresponding to each sample in the training set, converts the node attributes into floating-point feature vectors, and binarizes the severity of adverse reactions in the feedback (e.g., whether hospitalization is required) into risk labels (1 = high risk, 0 = low risk), forming a batch of labeled graph instances, i.e., graph training data. Subsequently, these graph instances are input into a graph neural network model, using a preset learning rate and the Adam optimizer, and iterated in small batches within a preset number of iterations. The model is trained using a method with a size of 32. In each round, the cross-entropy loss function between the model's output risk probability and the true label is calculated, and the model parameters are updated via backpropagation. After each complete training iteration, the current parameters are saved as a reference model. Each sample in the test set is then converted into a subgraph and input into the reference model to obtain the predicted risk probability. A threshold of 0.5 is used to convert this probability into a binary classification result. The proportion of samples whose predicted results match the true label is counted, which is the risk prediction accuracy. If this accuracy is lower than a preset accuracy threshold, the learning rate is adjusted or the number of iterations is increased, and the training process is restarted. If the risk prediction accuracy is greater than or equal to the preset accuracy threshold, training stops, and the current reference model is used as the final graph neural network model. This approach ensures that the model not only learns general drug risk patterns but also captures the complex correlation between individualized medication trajectories and feedback, thereby more accurately identifying potentially high-risk prescriptions in actual review processes.

[0068] Step S25: Perform medication-inspection item linkage verification based on the initial screening results and the risk difference coefficient to obtain verification results and verification details data including medication risk points and risk confidence levels.

[0069] As an example, the step of performing medication-examination item linkage verification based on the initial screening results and the risk difference coefficient to obtain verification results and verification details data including medication risk points and risk confidence levels includes: obtaining the required pre-medication mandatory examination items corresponding to the drugs in the target prescription from the drug knowledge base; determining whether there are missing or abnormal examination items based on the required pre-medication mandatory examination items, the patient examination results in the prescription dataset, and the conflict identifiers in the initial screening results, and obtaining examination item matching results; performing a weighted calculation of the risk difference coefficient and the examination item matching results to obtain a comprehensive risk confidence level; generating verification details data including medication risk points and risk confidence levels based on the conflict identifiers, the examination item matching results, and the comprehensive risk confidence level; when the comprehensive risk confidence level is greater than or equal to a preset confidence threshold, the verification result is unreasonable; when the comprehensive risk confidence level is less than the preset confidence threshold, the verification result is reasonable.

[0070] The mandatory pre-medication testing requirements refer to the explicit stipulations in the drug knowledge base regarding the laboratory or clinical tests that must be completed before the use of a specific drug. These requirements include the test name (e.g., "complete blood count," "liver function ALT / AST"), the effective time window (e.g., "within 72 hours before medication"), and the result safety threshold (e.g., "white blood cell count ≥ 3.0 × 10⁻⁶"). 9 / L”, used to ensure medication safety. Patient examination results refer to the actual test data of the most recent relevant examination of the patient associated with the prescription dataset, including the name of the examination item, test time, specific value and unit, sourced from the hospital LIS (Laboratory Information System) or electronic health record system. Conflict identifier refers to the binary flag in the initial screening results that marks whether each drug has a medication conflict (1 for conflict, 0 for no conflict), used to indicate that the drug has triggered the preliminary risk judgment of the rule engine. Examination item matching result refers to the judgment result generated by the system after comparing the required pre-medication mandatory examination items with the patient examination item results: if the required examination is missing, exceeds the effective time window, or the value exceeds the safety threshold, it is recorded as 1 (abnormal / missing); if the examination is complete, timely and valid, and the result is normal, it is recorded as 0 (abnormal / missing). (Normal). The overall risk confidence score is the final risk score calculated by weighting the risk difference coefficient (reflecting the degree of deviation between the prescription and the patient's historical medication pattern) and the matching results of the inspection items (reflecting the completeness of key safety checks) according to a preset weight (60%:40%). The value ranges from 0 to 1 and is used to uniformly quantify the overall medication risk level. The preset confidence threshold is a critical value (50% in this embodiment) pre-set by the system to determine whether a prescription is reasonable. When the overall risk confidence score is greater than or equal to this value, the verification result is determined to be unreasonable; if it is lower than this value, it is determined to be reasonable.

[0071] First, the system iterates through each drug in the target prescription, precisely querying its corresponding mandatory pre-medication testing requirements from the drug knowledge base, including the test item name, the maximum allowed testing interval, and the clinically acceptable numerical range. Second, for each mandatory testing requirement, the system searches for the most recently matching test record in the patient test results of the prescription dataset. If no match is found, the testing time exceeds the allowed interval, or the test value is below / above the safety threshold, the test item matching result for that drug is set to 1; otherwise, it is set to 0. This, combined with whether the drug has been marked with a conflict flag in the initial screening results, forms a complete risk context. Then, the system calculates the comprehensive risk confidence score for each drug individually: the global risk difference coefficient is calculated... Multiply by 0.6, and add the drug's check item matching result multiplied by 0.4 to obtain the drug's overall risk confidence score. Next, the system generates verification details data—for each drug with an overall risk confidence score greater than 0, a structured record is created, with fields including "Drug Risk Point" (composed of drug name + missing / abnormal check item, such as "Cisplatin: no eGFR result provided within 48 hours before administration"), "Risk Confidence Score" (i.e., the drug's overall risk confidence score value), "Conflict Identifier," and "Check Item Matching Result." All records are summarized into a list by drug. Finally, the highest overall risk confidence score among all drugs is taken as the prescription-level judgment criterion. If this value is greater than or equal to a preset confidence threshold, the output verification result is deemed unreasonable; otherwise, it is deemed reasonable. This is done to integrate explicit conflicts from the rule engine, implicit deviations from the graphical model, and missing key safety checks into a unified risk score, avoiding missed judgments due to relying on only a single dimension, and especially ensuring that high-risk drugs (such as chemotherapy drugs and nephrotoxic drugs) are effectively intercepted when necessary monitoring is lacking.

[0072] This embodiment first retrieves a matching subset of scenario-based rules from the drug knowledge base based on the department type corresponding to the target prescription, ensuring that subsequent verification aligns with specialty medication guidelines and improving the clinical relevance of the review. Then, the prescription dataset, the scenario-based rule subset, and allergy / contraindication data from the contraindication database are input into the Duluth rule engine to verify medication timing conflicts and physiological state contraindications, obtaining structured initial screening results for efficient identification of clear violations. Next, a patient medication similarity matrix is ​​constructed based on the initial screening results and the patient's historical prescription records to quantify the consistency between the current prescription and the patient's past medication patterns. A graph neural network model is then used to perform correlation verification on this matrix, outputting a risk difference coefficient to capture individualized latent risks. Finally, combining the initial screening results and the risk difference coefficient, a medication-inspection item linkage verification is performed, generating verification details data containing specific medication risk points and risk confidence levels, and outputting the final verification result to ensure that high-risk drugs are effectively blocked when necessary inspection support is lacking. The entire process achieves more accurate and personalized prescription rationality judgment through multi-level, multi-source information fusion.

[0073] This application also provides a medical prescription review and medication safety control device; please refer to [reference needed]. Figure 3 The medical prescription review and medication safety control device includes: Data acquisition module 10 is used to acquire drug information, patient allergy history and multidimensional health data in the target prescription to obtain prescription dataset; The prescription verification module 20 is used to verify the rationality of medication use of the target prescription based on the prescription dataset, drug knowledge base and contraindication database, through the Duluth rule engine and graph neural network model, and obtain verification results and verification details data. The prescription modification module 30 is used to mark the target prescription as a risk prescription when the verification result is unreasonable, and to generate a medication risk assessment report and prescription modification suggestions based on the verification details data, and send the medication risk assessment report and prescription modification suggestions to the doctor terminal corresponding to the target prescription; The medication guidance module 40 is used to perform prescription-patient feature matching based on the prescription dataset and the verification details data when the verification result is reasonable, generate personalized medication guidance, and send the personalized medication guidance to the doctor terminal, patient terminal, and pharmacy terminal.

[0074] The medical prescription review and medication safety management device provided in this application, employing the medical prescription review and medication safety management method described in the above embodiments, can solve the technical problem of how to achieve intelligent prescription review and medication safety assurance through risk assessment and personalized adaptation. Compared with the prior art, the beneficial effects of the medical prescription review and medication safety management device provided in this application are the same as those of the medical prescription review and medication safety management method provided in the above embodiments, and other technical features in the medical prescription review and medication safety management device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0075] This application provides a medical prescription review and medication safety management device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the medical prescription review and medication safety management method in the above embodiment 1.

[0076] The following is for reference. Figure 4This document illustrates a structural diagram of a medical prescription review and medication safety management device suitable for implementing embodiments of this application. The medical prescription review and medication safety management device in this application embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 4 The medical prescription review and medication safety management equipment shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0077] like Figure 4 As shown, the medical prescription review and medication safety management device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to programs stored in ROM (Read Only Memory) 1002 or programs loaded from storage device 1003 into RAM (Random Access Memory) 1004. RAM 1004 also stores various programs and data required for the operation of the medical prescription review and medication safety management device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via bus 1005. Input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, LCDs (Liquid Crystal Displays), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the medical prescription review and medication safety management equipment to exchange data wirelessly or via wired communication with other devices. Although the figure shows medical prescription review and medication safety management equipment with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0078] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0079] The medical prescription review and medication safety management device provided in this application, employing the medical prescription review and medication safety management method described in the above embodiments, can solve the technical problem of how to achieve intelligent prescription review and medication safety assurance through risk assessment and personalized adaptation. Compared with the prior art, the beneficial effects of the medical prescription review and medication safety management device provided in this application are the same as those of the medical prescription review and medication safety management method provided in the above embodiments, and other technical features in this medical prescription review and medication safety management device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0080] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0081] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0082] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the medical prescription review and medication safety management method in the above embodiments.

[0083] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, RAM (Random Access Memory), ROM (Read Only Memory), EPROM (Erasable Programmable Read Only Memory or Flash Memory), optical fibers, CD-ROM (CD-Read Only Memory), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0084] The aforementioned computer-readable storage medium may be included in the medical prescription review and medication safety management equipment; or it may exist independently and not be assembled into the medical prescription review and medication safety management equipment.

[0085] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the medical prescription review and medication safety management device, the device performs the following actions: acquires drug information, patient allergy history, and multidimensional health data from the target prescription to obtain a prescription dataset; based on the prescription dataset, drug knowledge base, and contraindication database, it verifies the rationality of medication use in the target prescription using a Duluth rule engine and a graph neural network model to obtain verification results and verification details; when the verification result is unreasonable, it marks the target prescription as a risk prescription and generates a medication risk assessment report and prescription modification suggestions based on the verification details, sending the medication risk assessment report and prescription modification suggestions to the doctor's terminal corresponding to the target prescription; when the verification result is reasonable, it performs prescription-patient feature matching based on the prescription dataset and verification details to generate personalized medication guidance, sending the personalized medication guidance to the doctor's terminal, patient's terminal, and pharmacy terminal.

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

[0087] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0088] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0089] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described medical prescription review and medication safety management methods. This solves the technical problem of how to achieve intelligent prescription review and medication safety assurance through risk assessment and personalized adaptation. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the medical prescription review and medication safety management methods provided in the above embodiments, and will not be repeated here.

[0090] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the medical prescription review and medication safety management method described above.

[0091] The computer program product provided in this application can solve the technical problem of how to achieve intelligent prescription review and medication safety assurance through risk assessment and personalized adaptation. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the medical prescription review and medication safety management methods provided in the above embodiments, and will not be repeated here.

[0092] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for medical prescription review and medication safety management, characterized in that, The method includes: Obtain drug information, patient allergy history, and multidimensional health data from the target prescription to obtain a prescription dataset; Based on the prescription dataset, drug knowledge base, and contraindication database, the rationality of medication use in the target prescription is verified using the Dulus rule engine and graph neural network model to obtain verification results and verification details. When the verification result is unreasonable, the target prescription is marked as a risk prescription, and a medication risk assessment report and prescription modification suggestions are generated based on the verification details data. The medication risk assessment report and prescription modification suggestions are then sent to the doctor's terminal corresponding to the target prescription. When the verification result is reasonable, prescription-patient feature matching is performed based on the prescription dataset and the verification details data to generate personalized medication guidance, and the personalized medication guidance is sent to the doctor's terminal, the patient's terminal and the pharmacy terminal.

2. The method as described in claim 1, characterized in that, The step of verifying the rationality of medication use in the target prescription using the Duluth rule engine and graph neural network model based on the prescription dataset, drug knowledge base, and contraindication database, and obtaining verification results and verification details data, includes: Based on the department type corresponding to the target prescription, a matching subset of scenario-based rules is retrieved from the drug knowledge base; The prescription dataset, the scenario-based rule subset, and allergy contraindication data from the contraindication database are input into the Dulus rule engine to verify medication timing conflicts and physiological state contraindications, and to obtain preliminary screening results. A patient medication similarity matrix is ​​constructed based on the initial screening results and the patient's historical prescription records; The risk difference coefficient is obtained by performing correlation verification on the patient medication similarity matrix using a graph neural network model. Based on the initial screening results and the risk difference coefficient, a joint verification of medication and examination items is performed to obtain the verification results and verification details data including medication risk points and risk confidence levels.

3. The method as described in claim 2, characterized in that, The step of inputting the prescription dataset, the scenario-based rule subset, and allergy contraindication data from the contraindication database into the Duluth rule engine to verify medication timing conflicts and physiological state contraindications, and obtaining preliminary screening results, includes: The prescription dataset is analyzed to extract information on administration time, administration frequency, patient physiological status, and medication. Based on the administration time and the administration frequency, the timing conflict determination rules in the scenario-based rule subset are called through the Dulus rule engine to compare whether the administration time interval of each drug combination in the drug information meets the preset duration requirement, and the timing conflict verification result is obtained. Based on the patient's physiological state information and the allergy contraindication data in the contraindication database, the physiological contraindication rules in the scenario-based rule subset are called through the Dulus rule engine to check the matching between the patient's physiological state and the drug's contraindicated components, and the physiological contraindication verification result is obtained. The timing conflict verification results and the physiological contraindication verification results are classified and labeled respectively; Based on the temporal conflict verification results and the physiological contraindication verification results after classification and labeling, the specific drugs involved in the conflict, the conflict type, and the basis for contraindication are marked, and the initial screening results are generated.

4. The method as described in claim 2, characterized in that, The graph neural network model includes an input layer, a graph convolution module, an attention mechanism module, and an output layer; The step of performing correlation verification on the patient medication similarity matrix using a graph neural network model to obtain the risk difference coefficient includes: The input layer initializes and encodes the patient-drug association features in the patient medication similarity matrix to obtain an initial feature vector; The initial feature vector is aggregated using the graph convolution module to obtain the node feature vector; The attention mechanism module assigns weights to the node feature vectors to obtain a weighted feature vector. The risk deviation coefficient is obtained by calculating the risk deviation of the weighted feature vector through the fully connected network of the output layer.

5. The method as described in claim 2, characterized in that, The step of performing medication-examination item linkage verification based on the initial screening results and the risk difference coefficient to obtain verification results and verification details data including medication risk points and risk confidence levels includes: Obtain the required pre-medication testing items for the drugs in the target prescription from the drug knowledge base; Based on the requirements of the mandatory pre-medication tests, the patient test results in the prescription dataset, and the conflict markers in the initial screening results, it is determined whether there are missing or abnormal test items, and the test item matching results are obtained. The risk difference coefficient is weighted and calculated with the matching results of the inspection items to obtain the comprehensive risk confidence level. Based on the conflict identifier, the matching result of the inspection item, and the comprehensive risk confidence level, generate verification details data containing medication risk points and risk confidence levels; When the overall risk confidence level is greater than or equal to the preset confidence threshold, the verification result is deemed unreasonable. When the overall risk confidence level is less than the preset confidence threshold, the verification result is considered reasonable.

6. The method as described in claim 1, characterized in that, The steps of marking the target prescription as a risk prescription when the verification result is unreasonable, generating a medication risk assessment report and prescription modification suggestions based on the verification details data, and sending the medication risk assessment report and prescription modification suggestions to the doctor's terminal corresponding to the target prescription include: When the verification result is unreasonable, the target prescription will be marked as a risk prescription; The risk confidence level in the verification details data is matched with a preset risk level classification threshold to determine the risk level corresponding to the risk prescription label. Based on the drug knowledge base, the multidimensional health data, and the medication risk points in the verification details data, a drug alternative solution is generated; Fill in the basic information of the risk prescription, the medication risk points, the risk level, and the drug alternatives into the preset report template to obtain a medication risk assessment report; The proposed alternative medication is used as a prescription modification suggestion, and the medication risk assessment report and the prescription modification suggestion are sent to the doctor's terminal corresponding to the target prescription.

7. The method according to any one of claims 1 to 6, characterized in that, The step of performing prescription-patient feature matching based on the prescription dataset and the verification details data when the verification result is reasonable, generating personalized medication guidance, and sending the personalized medication guidance to the doctor's terminal, the patient's terminal, and the pharmacy terminal includes: When the verification result is reasonable, the patient's underlying diseases, daily routines, and medication requirements are extracted from the prescription dataset. The medication requirements are matched with the patient's daily routine, and the patient's underlying diseases are matched with the medication risk points in the verification details data to obtain feature matching results; Based on the feature matching results, a personalized medication guide is generated, which includes specific administration time, dietary restrictions, and adverse reaction management plans. The personalized medication guidance is sent to the doctor's terminal, the patient's terminal, and the pharmacy terminal.

8. A medical prescription review and medication safety control device, characterized in that, The device includes: The data acquisition module is used to obtain drug information, patient allergy history and multidimensional health data from the target prescription to obtain the prescription dataset; The prescription verification module is used to verify the rationality of medication use in the target prescription based on the prescription dataset, drug knowledge base, and contraindication database, using the Duluth rule engine and graph neural network model, and to obtain verification results and verification details. The prescription modification module is used to mark the target prescription as a risk prescription when the verification result is unreasonable, and to generate a medication risk assessment report and prescription modification suggestions based on the verification details data, and send the medication risk assessment report and prescription modification suggestions to the doctor's terminal corresponding to the target prescription; The medication guidance module is used to perform prescription-patient feature matching based on the prescription dataset and the verification details data when the verification result is reasonable, generate personalized medication guidance, and send the personalized medication guidance to the doctor terminal, patient terminal, and pharmacy terminal.

9. A medical prescription review and medication safety management device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the medical prescription review and medication safety management method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the medical prescription review and medication safety management method as described in any one of claims 1 to 7.

Images