Prescription pre-audit method based on linkage of double rule bases

Abstract

The application discloses a prescription pre-audit method based on double-rule library linkage and belongs to the technical field of medical information systems. In view of the problem that the medical insurance payment rules and the reasonable drug use rules are independent of each other in the existing prescription audit, leading to inflexible processing and lack of differentiated processing paths, the method establishes independent reasonable drug use rule library and medical insurance restriction rule library, acquires prescription drug information and its charging attribute, calls the two rule libraries for double verification if it is medical insurance payment, prompts conversion to self-payment if only the medical insurance payment rule library is not satisfied while the reasonable drug use rule library is satisfied, and automatically recommends alternative drugs or adjusts the usage and dosage if the reasonable drug use rule library is not satisfied. If it is self-payment, only the reasonable drug use rule library is called for single verification. The method is mainly used for the pre-audit of prescriptions in the HIS system of a hospital, and realizes differentiated audit and intelligent auxiliary decision according to the charging attribute.

Description

Technical Field

[0001] This invention relates to the field of medical information system technology. More specifically, this invention relates to a pre-prescription review method based on the linkage of two rule bases. Background Technology

[0002] With the continued deepening of DRG / DIP payment reform, medical insurance fund supervision is accelerating its transformation from "post-event accountability" to a closed-loop management model encompassing "pre-event warning—in-event control—post-event traceability." This shift in governance focus signifies that medical insurance supervision is moving from traditional "end-of-pipe governance" to "source governance," placing higher compliance requirements and more refined standards on pharmaceutical management in medical institutions. Medical institutions not only need to ensure the rationality of clinical drug use but also must consider the compliance of indications for medical insurance payment and the safety of fund utilization. Pharmaceutical services are facing a dual empowerment transformation from "clinically oriented" to "medical insurance collaborative."

[0003] However, most existing hospital HIS systems employ a single rule base for pre-prescription review, such as a rational drug use rule base built solely on drug instructions and evidence-based medicine, or an indication rule base built solely on medical insurance payment restrictions. While some systems integrate both rule bases, they use either a sequential or independent judgment method: first, the rational drug use rule base is called for verification, and only after passing this is the medical insurance restriction rule base called for secondary verification; or, after the two rule bases provide their respective judgment results, the system takes the intersection or union of these results for interception.

[0004] In real-world clinical settings, this review method has the following problems: First, for prescriptions intended for reimbursement under medical insurance, if the prescription meets all the conditions of the rational drug use rule base but not the limiting conditions of the medical insurance restriction rule base, the existing system usually directly blocks the prescription and requires the physician to modify it or abandon the prescription. However, in clinical practice, patients can choose to pay for the drug out-of-pocket, without being restricted by the indications covered by medical insurance. In this case, the physician needs to manually switch the drug's payment attribute from medical insurance reimbursement to out-of-pocket payment and resubmit it for review. This operation adds extra steps for physicians and is easily overlooked due to unfamiliarity with the process, causing a potentially reasonable medication plan to be blocked.

[0005] Second, when a prescription does not meet the applicable conditions of the rational drug use rule base, the existing system generally only provides a "not approved" or "rule violated" message and blocks the prescription. When faced with such blocking, physicians need to consult drug instructions, clinical guidelines, or pharmacists to find alternative drugs or feasible solutions for adjusting the dosage. This process is time-consuming and increases the cost of manual consultation.

[0006] Third, for prescriptions with a self-pay payment attribute, some existing systems still call the medical insurance restriction rule base for verification. Since self-pay prescriptions are not covered by medical insurance, the medical insurance restrictions have no binding force on them. The extra verification not only increases the system's computational burden, but also causes unnecessary interception and interferes with the normal diagnosis and treatment process. Summary of the Invention

[0007] One object of the present invention is to provide a prescription pre-approval method based on dual rule base linkage, so as to at least solve the above-mentioned problems.

[0008] To achieve the objectives and other advantages of this invention, a prescription pre-approval method based on dual rule base linkage is provided, applied to a hospital HIS system, executed by a prescription pre-approval server, and including the following steps: 1) Establish independent databases for rational drug use rules and medical insurance restriction rules; 2) Obtain information on prescription drugs and their charging attributes, including whether they are covered by medical insurance or out-of-pocket; 3) If the payment type is covered by medical insurance, both the rational drug use rule base and the medical insurance restriction rule base will be used for dual verification. The prescription will only be approved and released if it meets the applicable conditions of both rule bases simultaneously. If the dual verification fails, the reason for failure will be further determined: 3a) If the applicable conditions of the medical insurance restriction rule base are not met but the rational drug use rule base is met, a prompt with a self-pay settlement identifier is generated, and the confirmation operation event of the prompt is detected. When the confirmation operation event is detected, the drug's charging attribute is switched to self-pay and released after passing the single verification according to the rational drug use rule base. At the same time, the reason for the conversion is automatically recorded. 3b) If the applicable conditions of the rational drug use rule base are not met, then filter the drug information that meets the applicable conditions from the rational drug use rule base, generate recommendations for alternative drugs or suggestions for adjusting the usage and dosage, and detect the adoption operation event of the suggestion. When the adoption operation event is detected, the verification is retried. 4) If the charge attribute is self-paid, only the rational drug use rule base is called for single verification. If the verification fails, the recommendation and re-verification process in step 3b) is executed. 5) The verification results, prompts, and suggestions will be fed back to the prescription issuance interface in real time. Prescriptions that fail the verification will be intercepted and specific rules will be provided.

[0009] Preferably, the construction and iterative updates of the rational drug use rule base include: Initial construction steps: Using drug instructions, clinical practice guidelines, hospital prescription sets, and historical desensitized prescription data as data sources, a pre-trained sequence labeling model is called to automatically extract fields such as drug indications, contraindications, dosage and administration, and treatment course restrictions to generate a candidate list of structured rules; a review and correction instruction is received from the pharmacist's end, and the confirmed rules are entered into the rational drug use rule library according to the instruction; Iterative update steps: Daily, read the physician forced release trigger events and their frequency corresponding to each rule from the HIS system prescription review log, and read the corresponding drug-related adverse reaction rates from the hospital adverse event reporting system or follow-up platform; use statistical process control methods to detect whether there are abnormal fluctuations in rule effectiveness; when abnormal fluctuations are detected, automatically extract the prescription characteristics and physician modification behavior that triggered the rule, generate three types of candidate modification schemes: "rule tightening", "rule relaxation", and "adding exception conditions", and push them to the pharmacist end after sorting them by the scope of impact; receive confirmation or fine-tuning instructions for candidate modification schemes from the pharmacist end, replace the original rule with a hot update according to the instructions, and record the version change and the operation pharmacist's identification; for rules that have not been triggered for two consecutive months and have received low-priority marking instructions from the pharmacist end, they are automatically put into a dormant state. Low-priority marking instructions are manually initiated by pharmacists in the rule management interface for rules that have not been triggered for a long time and have been assessed as having low clinical necessity. When marking, the marking reason must be filled in.

[0010] Preferably, the statistical process control method is as follows: the HIS system obtains seasonal disease index from the hospital epidemiological monitoring system, baseline change data of drug usage from the drug procurement module, and policy change timestamps of relevant rules from the policy early warning interface, and extracts the above data as external covariates; an accumulated sum control chart with covariate correction is used to introduce the external covariates into the control chart offset calculation to eliminate performance fluctuations caused by non-rule inherent factors; only when the cumulative offset of rule performance after deducting the influence of external covariates exceeds a preset threshold is it judged as an abnormal fluctuation.

[0011] Preferably, after generating three types of candidate modification schemes, the HIS system uses a confidence upper bound algorithm to calculate a comprehensive score based on the historical adoption rate, expected prescription coverage, and risk coefficient of each candidate scheme. The scores are then sorted in descending order and pushed to the pharmacist's end. The HIS system records the pharmacist's selection results for the candidate schemes and the actual changes in the rule effectiveness after the schemes are implemented, which are used to update the prior parameters corresponding to each scheme in the confidence upper bound algorithm.

[0012] Preferably, the construction and iterative updates of the medical insurance restriction rule base include: Initial construction steps: Using national and local medical insurance drug payment policy documents, medical insurance drug catalogs, and payment restriction texts as data sources, a pre-trained sequence labeling model is invoked to automatically extract fields such as generic drug name, medical insurance code, restricted indications, restricted treatment course, restricted medical institution level, restricted payment cycle, and restricted combination drug use, generating a candidate list of structured rules; receiving confirmation instructions from the medical insurance management terminal, the confirmed rules are entered into the medical insurance restriction rule library according to the instructions, and mapped and bound to the hospital's HIS drug dictionary; Iterative update steps: Regularly acquire medical insurance policy change data, and use change recognition algorithms to automatically identify newly added, modified, or abolished rule entries; for changed entries, generate candidate update schemes, sort them by impact scope, and push them to the medical insurance management terminal; receive confirmation or adjustment instructions from the medical insurance management terminal, replace the original rules with hot updates according to the instructions, and record the effective time and operator identification; for abolished rules, the system automatically moves them to the historical archive area and stops calling them in the review process; at the same time, the system continuously collects the refusal events and reason classifications in the hospital's medical insurance refusal appeal module, and collects the number of consultations in the medical insurance consultation records, calculates the review trigger score by combining the rule fuzziness score, and when the score exceeds the dynamic threshold, automatically marks the rule as pending review and pushes an alert to the medical insurance management terminal.

[0013] Preferably, the change recognition algorithm specifically includes: the HIS system periodically obtains medical insurance policy documents from the medical insurance policy data interface, policy document import port, or policy release page, and uses an optical character recognition engine to convert unstructured policy documents into text; it calls a semantic similarity model based on contrastive learning to calculate the semantic similarity between the extracted candidate rules and each rule in the existing medical insurance restriction rule base; when the similarity exceeds a preset threshold, it is determined to be an existing rule and no change entry is generated; only when the similarity is below the threshold is it determined to be a newly added or substantially modified rule; for rules determined to be substantially modified, a differential positioning algorithm based on word vectors is used to mark the specific difference fields between the two versions and generate a highlighted comparison view. Preferably, the calculation method for the review trigger score includes: setting a statistical period, obtaining the number of medical insurance refusal events and medical insurance consultations generated for the rule to be reviewed within the statistical period, and calculating the refusal event frequency and consultation frequency respectively; constructing a fuzzy word dictionary, which at least contains fuzzy expressions such as "discretionary", "appropriate", "when necessary", "general", "usually", "can be considered", "suggested", and "not suitable"; extracting the limiting condition text of the rule to be reviewed, performing word segmentation on the limiting condition text, matching the word segmentation results with the fuzzy word dictionary, counting the number of successfully matched fuzzy words, and calculating the ratio of the number of fuzzy words to the total number of words in the limiting condition text as the rule fuzziness score; calculating the review trigger score, which is calculated as follows: review trigger score = first weight × refusal event frequency + second weight × consultation frequency + third weight × rule fuzziness score; wherein, the initial values ​​of the first weight, second weight, and third weight are preset fixed values ​​of the HIS system, and the HIS system continuously collects the actual review results after each review trigger, and dynamically adjusts the first weight, second weight, and third weight using an online gradient descent method.

[0014] Preferably, each rule in the rational drug use rule base and the medical insurance restriction rule base is configured with a creation timestamp and an effective timestamp; when performing dual verification in step 3), the HIS system obtains the prescription issuance time and only calls the latest version of the rule whose effective timestamp is no later than the prescription issuance time.

[0015] Preferably, it also includes establishing a patient-level medication accumulation ledger to store information on valid prescriptions for each patient that have not yet exceeded the course of treatment. During the double verification in step 3), the HIS system first retrieves the accumulated dosage and remaining medical insurance payment amount of the same drug or similar drugs from the medication accumulation ledger based on the patient's identifier. Then, it merges the current prescription application amount with the accumulated amount to determine whether it exceeds the cycle total limit in the medical insurance restriction rule base or the cumulative safe dosage limit in the rational drug use rule base. It only passes if all restriction conditions are still met after merging; otherwise, it intercepts and displays the historical dosage details and the remaining prescription amount.

[0016] Preferably, the dual verification also includes conflict arbitration rules: the verification results of the rational drug use rule base are pre-set to have a higher priority than the medical insurance restriction rule base; when the dual verification result in step 3) is that the rational drug use rule base fails while the medical insurance restriction rule base passes, the HIS system forcibly intercepts the prescription, does not generate a prompt with a self-pay settlement indicator, and displays the risk basis and clinical alternative suggestions in the rational drug use rule base to the physician; only when the rational drug use rule base passes will the pass, intercept, or self-pay settlement operation be performed based on the verification result of the medical insurance restriction rule base.

[0017] The present invention has at least the following beneficial effects: First, by establishing independent rational drug use rule bases and medical insurance restriction rule bases, and implementing differentiated review paths based on prescription fee attributes, the problem of mixed rule application and rigid processing in traditional review is solved. For prescriptions covered by medical insurance, dual verification ensures that both clinical rationality and medical insurance compliance are met simultaneously. For cases where only medical insurance rules are not met but rational drug use rules are met, an automatic prompt with a conversion to out-of-pocket settlement indicator is generated and the reason for the conversion is recorded, avoiding the predicament of directly blocking prescriptions that would prevent rational prescriptions from being issued. For cases where rational drug use rules are not met, clinical alternative drugs or dosage adjustment suggestions are automatically recommended, reducing the time physicians spend searching for information. Out-of-pocket prescriptions only call the rational drug use rule base, avoiding unnecessary verification interference. This solution achieves flexible and accurate pre-prescription review, improving the approval rate and clinical work efficiency.

[0018] Secondly, during the construction and iterative updates of the rational drug use rule base, a pre-trained model automatically extracts rule fields to generate a candidate list, reducing the manual cost of initial rule construction. In the iterative update phase, data such as mandatory release events and adverse reaction rates from the review logs are used, employing statistical process control methods to detect abnormal fluctuations in rule effectiveness, enabling timely identification of overly strict or lenient rules. Based on this, three types of candidate modification schemes are automatically generated and pushed to pharmacists in order of impact. After pharmacists confirm, the rules are replaced via hot updates, completing rule optimization without system downtime. Rules that have not been triggered for a long time and are marked as low priority by pharmacists are automatically put into a dormant state, reducing unnecessary rule matching calculations and maintaining the activity of the rule base and review efficiency.

[0019] Third, in statistical process control, relevant data is obtained from the hospital's epidemiological monitoring system, drug procurement module, and policy early warning interface. An accumulated sum control chart with covariate correction is used. Abnormal fluctuations are only judged when the cumulative offset of rule effectiveness after deducting the influence of external covariates exceeds the threshold. This solves the problem of performance fluctuations caused by non-rule-inherent factors such as seasonal epidemics, changes in drug usage baseline, and policy changes being misjudged as rule anomalies. This improves the accuracy of rule anomaly detection, avoids frequent triggering of unnecessary rule modification processes due to changes in the external environment, and makes rule iteration more robust and reliable.

[0020] Fourth, after generating candidate modification schemes, a confidence upper bound algorithm is used to calculate a comprehensive score for each scheme based on its historical adoption rate, expected prescription coverage, and risk coefficient. This score is then pushed to pharmacists in descending order, allowing them to prioritize modifications with higher overall benefits and reducing trial-and-error costs. The system further records pharmacists' selections and the actual changes in rule effectiveness after implementation, using this information to update the prior parameters of the confidence upper bound algorithm, thus achieving continuous optimization of the recommendation model. With increased usage, the recommendation results will become increasingly aligned with the hospital's clinical practice, improving the intelligence level of rule maintenance and pharmacists' work efficiency.

[0021] Fifth, during the construction and iterative updates of the medical insurance restriction rule base, the system automatically extracts limiting fields from policy documents and maps them to the HIS drug dictionary, ensuring accurate binding between rules and drugs. By regularly acquiring medical insurance policy change data and automatically identifying newly added, modified, or repealed entries, candidate update schemes are generated and pushed to the medical insurance management terminal for confirmation before hot updates, ensuring the synchronization of rules with the latest policies. Simultaneously, the system collects medical insurance refusal events and consultation records, and calculates review trigger scores based on rule ambiguity scoring. When the score exceeds a dynamic threshold, it automatically marks the system as pending review and sends an alert, proactively identifying potentially ambiguous or controversial rules. This shifts from passive response to proactive alerting, reducing the risk of refusal due to rule ambiguity.

[0022] Sixth, by periodically accessing the medical insurance bureau's policy release page and applying optical character recognition to convert unstructured documents, automated collection of policy texts was achieved. A semantic similarity model based on contrastive learning was used to compare candidate rules with existing rules one by one. Rules with similarity exceeding a threshold were considered existing rules, while those below the threshold were considered new additions or substantial modifications, effectively filtering out non-substantive changes such as format adjustments and text rearrangements. For rules with substantial modifications, a word vector-based differential positioning algorithm was used to annotate the specific difference fields between versions and generate a highlighted comparison view, enabling medical insurance administrators to intuitively understand the changes, significantly improving the accuracy and efficiency of rule updates, and reducing the workload of manual comparison.

[0023] Seventh, by comprehensively considering three dimensions—the frequency of chargeback events, the frequency of inquiries, and the ambiguity score of rules—and multiplying each dimension by a preset weight before weighted summation, a multi-dimensional review trigger score calculation model is constructed. The system continuously collects the actual review results after each review trigger and dynamically adjusts the three weights using an online gradient descent method. This allows the scoring model to adapt to the actual situation of different periods and different rules, avoiding missed or false alarms caused by fixed weights, improving the accuracy of rule identification, and enabling limited review resources to be concentrated on rules that truly have problems.

[0024] Eighth, by configuring a timestamp and an effective timestamp for each rule, the prescription issuance time is retrieved during dual verification. Only the latest version of the rule with an effective timestamp no later than the prescription issuance time is called. This resolves the potential version mismatch issue between historical prescriptions and new rules after rule updates, preventing prescriptions that have been issued but not yet settled from being incorrectly blocked or approved due to rule changes. Simultaneously, it supports the coexistence of rule versions with different effective times, allowing for flexible scheduling of rule releases, such as uniformly implementing them during off-peak hours without affecting normal daytime review processes. The preservation of version change records also provides a basis for subsequent auditing and backtracking.

[0025] Ninth, by establishing a patient-level medication accumulation ledger, the system stores valid prescription medication information for each patient that has been issued and has not yet exceeded the treatment course. During dual verification, the system retrieves the accumulated dosage and remaining medical insurance payment limit for the same or similar drugs based on the patient's identifier. It then combines the current prescription application with the accumulated dosage to determine whether it exceeds the cycle limit or the cumulative safe dosage limit. This effectively solves the problem of cumulative over-dosage across prescriptions and departments, such as situations where the same patient obtains the same type of drug from different departments, resulting in an excessive total dosage. The system only approves prescriptions if all restrictions are still met after merging; otherwise, it blocks the process and displays historical dosage details and the remaining available dosage, providing physicians with clear decision-making support and ensuring patient medication safety and the rationality of medical insurance payments.

[0026] Tenth, by setting conflict arbitration rules, the verification results of the rational drug use rule base are given higher priority than those of the medical insurance restriction rule base. When the dual verification results show that the rational drug use rule base fails while the medical insurance restriction rule base passes, the system forcibly intercepts the prescription, does not generate a prompt with a self-pay settlement indicator, and displays the risk basis and clinical alternative suggestions in the rational drug use rule base to the physician. This avoids sacrificing patient medication safety in pursuit of medical insurance payment. Only when the rational drug use rule base passes will the system execute the pass, intercept, or self-pay settlement operation based on the verification results of the medical insurance restriction rule base, making the review process more rigorous and secure.

[0027] Other advantages, objectives and features of the present invention will become apparent in part from the following description, and in part from those skilled in the art through study and practice of the invention. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating a prescription pre-approval method based on dual rule base linkage, according to an embodiment of the present invention. Detailed Implementation

[0029] The present invention will now be described in further detail with reference to the embodiments and accompanying drawings, so that those skilled in the art can implement it based on the description.

[0030] It should be understood that terms such as “having,” “comprising,” and “including” as used herein do not exclude the presence or addition of one or more other elements or combinations thereof.

[0031] like Figure 1 As shown, this invention provides a prescription pre-approval method based on dual rule base linkage, applied to a hospital HIS system. In one embodiment of this invention, the method includes the following steps: 1) Establish independent rule bases for rational drug use and medical insurance restrictions. The rational drug use rule base is built based on drug instructions and evidence-based medicine, and includes information on clinical alternatives. The medical insurance restriction rule base is built based on medical insurance payment restrictions. In implementation, each rule in the rational drug use rule base is assigned a unique identifier. Clinical alternative information is stored in structured fields, such as the generic name, dosage form, strength, and recommended dosage range of the alternative drug (e.g., 100mg to 200mg orally once or twice daily). Each rule in the medical insurance restriction rule base is assigned a corresponding medical insurance code, a limited ICD-10 code range for the restricted indication, a limited treatment duration (e.g., 7 days, 14 days, or 30 days), a limited medical institution level (e.g., tertiary, secondary), and a list of drugs restricted for combination therapy. Both rule bases are stored in relational database tables, and a mapping relationship is established between the generic name of the drug and the HIS drug dictionary. When constructing the rule base, at least 2,000 historical prescriptions from the past 6 months of this hospital were randomly selected as the test set. Stratified sampling was used to sample the prescriptions by department to verify the initial coverage and false positive rate of the rule base. Statistical analysis used the chi-square test to compare the changes in prescription interception rate before and after the application of the rule base, with a significance level set at 0.05.

[0032] 2) Obtain drug information and its billing attributes from prescriptions issued by physicians through the HIS system. Billing attributes include medical insurance payment and out-of-pocket payment. Drug information includes at least the generic name, dosage form, single dose, frequency of use, duration of treatment, and issuing department. Billing attributes are selected by physicians through a drop-down menu on the HIS prescription interface, with default values ​​preset according to the patient's insurance type (e.g., employee medical insurance defaults to medical insurance payment, out-of-pocket patients default to out-of-pocket payment). The system captures prescription save events in real time and reads the structured prescription data through interface calls. For medical insurance payment attributes, further obtain the patient's medical insurance type (e.g., urban employee, rural resident) and personal account balance information for reference during subsequent conversion judgments.

[0033] 3) If the billing attribute is covered by medical insurance, both the rational drug use rule base and the medical insurance restriction rule base are called for double verification. The prescription is only approved and released if it meets the applicable conditions of both rule bases. If the double verification fails, the reason for failure is further determined. In practice, the response time of the double verification is set to no more than 500ms. The system uses multi-threaded concurrent querying and sets a timeout threshold of 300ms for each rule base. 3a) If only the applicable conditions of the medical insurance restriction rule base are not met, but the rational drug use rule base is met, a prompt with a self-pay settlement identifier is generated and written back to the HIS prescription interface. The HIS system generates a "Convert to self-pay payment" prompt button on the prescription interface and detects the physician's click confirmation event on the button. After the confirmation operation is triggered, the system switches the billing attribute of the drug to self-pay and releases it after passing the single verification according to the rational drug use rule base. At the same time, the reason for conversion is automatically recorded (stored as a text field with a length not exceeding 200 characters). The reason for conversion includes the name of the unmet medical insurance restriction condition and the timestamp. 3b) If the applicable conditions of the rational drug use rule base are not met, drug information that meets the applicable conditions is selected from the rational drug use rule base, and suggestions for alternative drugs or adjustments to dosage are generated and written back to the HIS prescription interface. For example, drug A can be replaced with drug B, where drug B belongs to the same treatment category as drug A and has been approved by the hospital's pharmacy committee. For adjustments to dosage, such as changing the dose from 200mg to 100mg per dose, or changing from three times daily to twice daily, the suggested results are displayed in a list in the sidebar of the prescription interface. The system also detects the physician's adoption of any suggestion. After adoption, the verification is triggered again from step 2, with a maximum of three re-verification attempts. Each re-verification attempt can recommend a maximum of three alternative solutions. If the limit is exceeded, the system proceeds to the final interception process. In cases where neither rule base meets the requirements during the dual verification process, the recommendation process in step 3b) is executed directly, and the option to switch to self-payment is not provided.

[0034] 4) If the charge attribute is self-pay, only the rational drug use rule base is called for single-pass validation. If the validation fails, the recommendation and re-validation process in step 3b) is executed. The rule matching logic for single-pass validation is the same as the rational drug use part in double-pass validation, and the validation timeout threshold is set to 400ms. For self-pay prescriptions, the system does not query the medical insurance restriction rule base, nor does it record medical insurance-related conversion reasons. In the re-validation process, if the physician adopts the recommendation and the re-validation still fails, the maximum number of re-validations is still 3. Each re-validation recommends a maximum of 3 alternative solutions. If the limit is exceeded, the process will proceed to the final interception process. Each recommended alternative solution is arranged in descending order of priority. The priority is calculated based on the historical adoption frequency of the alternative solution in the past 30 days in this hospital. The specific calculation formula is: Priority Score = Historical Adoption Count of the Alternative Solution / Total Recommendation Count of the Alternative Solution × 100%. The higher the score, the higher the priority.

[0035] 5) All verification results, prompts, and suggestions will be fed back to the prescription issuance interface in real time, with a feedback delay of no more than 100ms. For prescriptions that ultimately fail verification, the system will intercept them and provide a specific rule description. The rule description text will list the violated rule number, rule name, and a fragment of the original rule text. Intercepted prescriptions will be automatically saved to the audit log table, and the log retention period will be no less than 180 days.

[0036] In this embodiment, the review path is differentiated based on the charging attribute. During the dual verification of medical insurance prescriptions, a self-pay channel is provided for prescriptions that only violate medical insurance rules but comply with rational drug use rules, avoiding direct interception that would prevent the issuance of rational prescriptions. When rational drug use rules are not met, alternative solutions are automatically recommended, reducing physicians' manual search time. Self-pay prescriptions are exempt from unnecessary medical insurance rule verification, reducing system load. Therefore, the overall efficiency of prescription review is improved, manual intervention is reduced, and a balance between clinical safety and medical insurance compliance is ensured. In another embodiment of the invention, the construction and iterative updating of the rational drug use rule base includes: The initial construction steps use drug instructions, clinical practice guidelines, hospital prescription sets, and historical anonymized prescription data as data sources. A pre-trained sequence labeling model is used to automatically extract fields such as drug indications, contraindications, dosage, and treatment duration restrictions, generating a candidate list of structured rules. Review and correction instructions from pharmacists are received, and the confirmed rules are entered into the rational drug use rule base according to these instructions. In specific implementation, anonymized prescription data from the hospital within the past 12 months is collected as the data source. At least 10,000 prescription records are randomly selected and stratified by department (internal medicine, surgery, pediatrics, etc., each accounting for an appropriate proportion) to supplement common clinical uses not covered by the instructions and guidelines. The pre-trained sequence labeling model uses a BERT-BiLSTM-CRF architecture and is pre-trained on a publicly available drug instruction dataset (containing approximately 5,000 annotated texts). It is then fine-tuned using 200 manually annotated drug instructions from the hospital, with a learning rate set to 2e during fine-tuning. -5The training process consists of three rounds. The model sets a confidence threshold of 0.85 for each text output field; fields below this threshold are excluded from the candidate list and manually reviewed by pharmacists. The structured rule candidate list is stored in JSON format, with each rule containing the drug's generic name, field type (e.g., indication), field content, and data source identifier (e.g., original paragraph number in the instruction manual). Pharmacists view the candidate list via a web interface, with 20 rules displayed per page. Pharmacists can select "Confirm," "Modify," or "Reject," and modification is supported by directly editing field content in the text edit box. Review and correction instructions are sent to the backend via HTTP requests. Confirmed rules are entered into the rational drug use rules table in the MySQL database, along with the entry timestamp and the pharmacist's ID. Before entry, the system automatically checks for existing rules with the same drug and field type; if found, it prompts for overwriting or merging.

[0037] The iterative update process involves daily reading of physician-mandated release trigger events and their frequency from the HIS system's prescription review logs for each rule, and retrieving the corresponding adverse reaction rates for the relevant drugs from the hospital's adverse event reporting system or follow-up platform. Specifically, a scheduled task starts at 2:00 AM daily, reading the review logs from 0:00 to 24:00 the previous day, filtering records marked "physician-mandated release," and summarizing the trigger counts by rule number. A mandatory release event is defined as the physician clicking the "mandatory release" button and filling in a reason after the system prompts for interception. The adverse reaction rate is retrieved from the adverse event reporting system and calculated as follows: on a weekly basis, the number of adverse reaction reports for a specific drug is divided by the total number of prescriptions for that drug during the same period to obtain the weekly adverse reaction rate (unit: cases / thousand prescriptions, expressed as a few per thousand). Simultaneously, adverse reaction data proactively reported by patients is obtained from the follow-up platform and included in the adverse reaction count. The data retrieval interface uses a RESTful API with a timeout of 30 seconds and 3 retries. After each daily read is completed, the number of forced releases, adverse reaction rate, corresponding rule number, and drug code are stored in the rule effectiveness monitoring table, and historical data for the most recent 180 days are retained.

[0038] Statistical process control (SPC) methods are used to detect abnormal fluctuations in rule effectiveness. When abnormal fluctuations are detected, the prescription characteristics that triggered the rule and the physician's modification behavior are automatically extracted, generating three candidate modification schemes: "rule tightening," "rule relaxation," and "adding exception conditions." These are then sorted by their impact scope and pushed to the pharmacist's end. The SPC method uses a cumulative sum control chart with covariate correction to monitor the mandatory release rate of each rule. Let n be the total number of prescriptions involving a certain rule reviewed daily, and d be the number of prescriptions forcibly released by physicians. Then the mandatory release rate for that day is d divided by n. The center line of the control chart is the historical average mandatory release rate, with the historical period being the previous 30 effective days (excluding days with zero prescriptions). The upper control limit is the center line plus three times the standard deviation, calculated based on the relationship between the average mandatory release rate and the daily prescription count. The lower control limit is the center line minus three times the standard deviation; if the result is negative, it is set to 0. The rules for identifying abnormal fluctuations are as follows: If the mandatory release rate falls outside the 2-standard-deviation range on the same side of the center line for 2 out of 3 consecutive valid days, or if the mandatory release rate falls outside the 1-standard-deviation range on the same side of the center line for 4 out of 5 consecutive valid days, or if the mandatory release rate falls on the same side of the center line for all 8 consecutive valid days. Upon detecting abnormal fluctuations, the system automatically extracts the prescription features that triggered the rule (including the distribution of the first three digits of the department and diagnostic ICD-10 code, patient age segments (0-6 years, 7-17 years, 18-59 years, 60 years and above), and physician title), as well as the physician's modification behavior (including whether the dosage was modified before mandatory release and whether alternative drug recommendations were selected). Based on the extracted features, the system uses a decision tree classifier (maximum depth set to 4) to generate three types of candidate modification schemes: if mandatory releases are concentrated in a specific diagnosis that is not covered by the rule, a "new exception condition" is generated; if mandatory releases are accompanied by a dose reduction and the adverse reaction rate does not increase, a "rule relaxation" is generated; if the adverse reaction rate increases after mandatory release, a "rule tightening" is generated. Candidate proposals are sorted by their scope of impact, which is defined as the percentage of historical prescriptions that the rule may cover (i.e., the percentage of the total number of prescriptions that triggered the rule in the past 30 days out of the total number of prescriptions in the hospital). After being sorted in descending order, they are pushed to the pharmacist's web interface. Each proposal is accompanied by a feature summary and the expected number of prescriptions affected after modification.

[0039] The system receives confirmation or fine-tuning instructions for candidate modification schemes from pharmacists. Based on these instructions, it replaces the original rules using a hot update method, recording the version change and the pharmacist's identifier. Rules that haven't been triggered for two consecutive months and have received a low-priority marking instruction from pharmacists are automatically put into a dormant state. Low-priority marking instructions are manually initiated by pharmacists in the rule management interface for rules that haven't been triggered for a long time and have low clinical necessity after assessment. A reason for marking must be provided. The hot update is implemented by writing the modified rule to an in-memory cache (e.g., Redis), with the key format being `rule` followed by the rule number and then an underscore `active`. The lifespan is set to permanent, and the rule version number in the database is updated (incrementing by 1 with each change). During the system review process, each rule call prioritizes reading the Redis cache. If the cache hits, it's used directly; otherwise, it's loaded from the database and written to the cache, thus replacing rules without restarting the service. Version change records are written to a log table, including the old version rule content, the new version rule content, the change time, the pharmacist's identifier, and the reason for the change (e.g., "relaxed threshold" or "added diagnostic exception"). For rules that have not been triggered by any prescriptions for two consecutive months (60 calendar days) (i.e., both forced release and normal interception counts are 0), the system generates a reminder during daily checks. If the pharmacist sends a low-priority marking command via the interface, the rule's status field is set to dormant. Dormant rules do not participate in daily review and matching but are retained in the database and can be woken up at any time via background commands. Dormant rules are reassessed every 30 days, and if the assessment deems them potentially needing to be reactivated, a notification is pushed to the pharmacist's end.

[0040] The construction and iterative update method in this implementation automatically extracts rule fields through a pre-trained model, combined with pharmacist review and correction, reducing the manual cost of initial rule construction. The iterative update stage utilizes mandatory release events and adverse reaction rate data, employing statistical process control methods to sensitively detect abnormal fluctuations in rule effectiveness, enabling timely identification of overly strict or lenient rules. Based on this, three categories of candidate modification schemes are automatically generated and sorted by their impact range. After pharmacist confirmation, these schemes are replaced via hot updates, completing rule optimization without system downtime. Rules that have not been triggered for a long time and are marked as low priority by pharmacists are automatically put into a dormant state, reducing unnecessary rule matching calculations in the system. Overall, the timeliness and activity of the rule base are maintained, improving the automation and intelligence level of rule maintenance, while version change records ensure the traceability of rule adjustments.

[0041] In another embodiment of the present invention, the statistical process control method specifically includes: The HIS system pre-obtains seasonal disease indices from the hospital's epidemiological surveillance system, baseline drug usage change data from the drug procurement module, and policy change timestamps for relevant rules from the policy early warning interface, extracting these data as external covariates. In practice, the seasonal disease index is defined as the proportion of outpatient visits for a specific disease (such as upper respiratory tract infection) in the current week to the annual average weekly outpatient visits. This index is calculated and stored daily by the hospital's epidemiological surveillance system, typically ranging from 0.5 to 2.0. At 3:00 AM daily, the system retrieves the disease index from the epidemiological surveillance system's statistical tables via a database link, with a timeout of 10 seconds. Baseline drug usage change data is obtained from the drug procurement module and is defined as the average weekly outbound volume of a drug over the past 4 weeks divided by the average weekly outbound volume over the past 52 weeks. A baseline ratio is calculated; a ratio below 0.7 or above 1.3 indicates a significant change in the usage baseline. The policy early warning interface is a web service provided by the Medical Insurance Bureau, which polls every 2 hours to obtain the timestamp of the policy document's release and the policy's effective date. The system compares the timestamp of the most recent policy change with the update time of the corresponding rule in the rule base. If the policy release time is later than the rule update time, the rule is marked as pending review. The three external covariates mentioned above are stored in daily units, with each rule corresponding to a set of covariate values ​​for that day. Missing values ​​are filled using forward imputation, and consecutive missing values ​​do not exceed 3 days.

[0042] A cumulative sum control chart with covariate correction is used to incorporate external covariates into the control chart offset calculation, eliminating performance fluctuations caused by inherent irregularities. The basic principle of the cumulative sum control chart originates from sequential analysis in statistical process control; this method adds a covariate correction term to this foundation. The specific process is as follows: A daily observation value is set as the mandatory release rate for a specific rule on a given day, calculated as the number of mandatory releases divided by the total number of prescriptions involving that rule. Without the influence of external covariates, the cumulative sum control chart monitors offset by accumulating the difference between the daily mandatory release rate and a reference value. This method introduces covariate correction, replacing the daily observation value with the corrected residual. First, a linear regression relationship is established, with the daily mandatory release rate as the dependent variable and the seasonal disease index, the baseline ratio of drug usage, and policy change indicators (1 for changes, 0 for none) as independent variables. A residual value is calculated, which is the actual mandatory release rate minus the mandatory release rate predicted by the aforementioned covariates. The regression coefficients are estimated using 30 days of historical data, updated daily, and estimated using the least squares method. The residuals are then used as corrected observations and input into the cumulative control chart. The mean of the residuals is 0, and their standard deviation is calculated from the historical residual series. The reference value is set to 0.5 times the standard deviation, and the decision interval is set to 4 times the standard deviation. The cumulative sum is calculated as follows: the residual value for each day is calculated. If the residual value is greater than the reference value, the cumulative sum is equal to the previous day's cumulative sum plus (residual value minus reference value); otherwise, the cumulative sum is the larger value between the previous day's cumulative sum minus (reference value minus residual value) and 0. The initial cumulative sum is 0.

[0043] The specific implementation of introducing external covariates into the control chart offset calculation is as follows: After the system completes the daily prescription review log statistics, it obtains historical data from the previous 30 days and calculates the daily residual value. Taking a certain rule as an example, assume that in the past 30 days, there were 10 days with a seasonal disease index higher than 1.2, 5 days with a drug usage baseline ratio lower than 0.7, and 2 days with policy changes. The system calculates the difference between the average mandatory release rate on these days and the average mandatory release rate on normal days, using it as the influence coefficient of the covariate. In the actual cumulative calculation, when a higher disease index occurs on a certain day, the regression model will subtract the influence of this factor from the mandatory release rate, resulting in a smaller residual value, thereby avoiding misjudging the increase in the normal release rate caused by the disease epidemic as a rule anomaly. The cumulative sum update process is as follows: The residual value is calculated daily, and then it is determined whether the residual value is greater than the reference value. If it is, the cumulative sum is equal to the previous day's cumulative sum plus (residual value minus reference value); otherwise, the cumulative sum is the larger value between the previous day's cumulative sum plus (residual value minus reference value) and 0. When the cumulative sum exceeds the decision interval, an abnormal fluctuation alarm is triggered. For example: assuming the standard deviation of the residual value is 0.04, the reference value is set to 0.02, and the decision interval is set to 0.16. If the residual values ​​are positive for several consecutive days and the cumulative sum exceeds 0.16, an anomaly is determined.

[0044] Abnormal fluctuations are identified only when the cumulative offset of the rule's effectiveness, after deducting the influence of external covariates, exceeds a preset threshold. The preset threshold is the decision interval, and its value is adjustable based on the rule's importance and risk level. For high-risk drugs (such as chemotherapy drugs and anticoagulants), the decision interval is set to 3 times the standard deviation of the residuals; for medium-risk drugs, it is set to 4 times the standard deviation of the residuals; and for low-risk drugs, it is set to 5 times the standard deviation of the residuals. The standard deviation of the residuals is recalculated every 7 days, using a moving range method to ensure stability. The specific judgment process is as follows: the cumulative sum is updated daily. When the cumulative sum exceeds the decision interval, the system records that the rule has experienced abnormal fluctuations and triggers the candidate modification scheme generation process. Simultaneously, to prevent continuous fluctuations, after triggering an alarm, the cumulative sum is reset to the larger value between the previous day's cumulative sum minus 0.5 times the decision interval and 0, avoiding repeated alarms within a short period. If the cumulative sum remains below the decision interval but shows an upward trend for 15 consecutive days (i.e., the cumulative sum increases daily and the cumulative sum on the last day is greater than 0.5 times the decision interval), the system also generates an early warning for pharmacists to pay attention to. To verify the effectiveness of this method, the 50 most frequently used drugs in our hospital were selected, and a comparative test was conducted using an uncorrected cumulative sum control chart and this method. The test period lasted for 90 days, with manual verification results as the gold standard. The number of false alarms and false negatives of the two methods were statistically analyzed. The results show that the accuracy of this method is significantly improved.

[0045] This implementation introduces seasonal disease indices, baseline drug usage changes, and policy change timestamps as external covariates. By employing a cumulative sum control chart with covariate correction, it effectively isolates rule performance fluctuations caused by non-inherent factors (such as high incidence of seasonal diseases, drug procurement fluctuations, and policy updates) from anomaly detection. Anomalies are only identified when the cumulative offset of rule performance after deducting the effects of these factors exceeds a threshold. This effectively reduces false alarms caused by changes in the external environment, making rule anomaly detection more accurate and reliable, avoiding unnecessary rule modification processes, and reducing the workload for pharmacists.

[0046] In another embodiment of the present invention, after generating three types of candidate modification schemes (rule tightening, rule relaxation, and adding exception conditions), the HIS system uses a confidence upper bound algorithm to calculate a comprehensive score based on the historical adoption rate, expected prescription coverage, and risk coefficient of each candidate scheme. The confidence upper bound algorithm originates from the classic algorithm in the multi-armed gambling machine problem, and this method uses it for the ranking and recommendation of candidate schemes. In specific implementation, for each candidate scheme, the system maintains three parameters: historical adoption rate (i.e., the number of times the scheme has been adopted by pharmacists in the past divided by the total number of times it has been pushed), expected prescription coverage (i.e., the number of prescriptions expected to be affected daily if the scheme is adopted, estimated based on the prescription characteristics that trigger the rule), and risk coefficient (the value ranges from 0 to 1, determined by the drug safety level; high-risk drugs such as anticoagulants are assigned a value above 0.8, and low-risk drugs are assigned a value below 0.3). The comprehensive score is calculated as follows: the base score is the historical adoption rate, plus an exploration reward item (this reward item is proportional to the square root of the ratio of the logarithm of the number of times the scheme has been pushed to the current total number of pushes, multiplied by a constant factor, which is set to 2). Then, multiply the sum of the above by the normalized value of the expected prescription coverage (i.e., the coverage of the proposed solution divided by the maximum coverage among all candidate solutions), and then multiply by the reciprocal of the risk coefficient (i.e., 1 minus the risk coefficient) to obtain the final comprehensive score. For example, if a proposed solution has a historical adoption rate of 0.6, has been pushed 5 times, has a current total number of pushes of 20, an expected prescription coverage of 80, and a risk coefficient of 0.3, then the calculated exploration reward item is approximately 0.8. The base score and the reward item are added together to get 1.4. Multiplying by the coverage normalization (assuming the maximum coverage is 100, then 80 / 100=0.8) gives 1.12. Multiplying by (1-0.3=0.7) gives 0.78.

[0047] After sorting the candidate proposals in descending order of their overall scores, the proposed modifications are pushed to the pharmacist's end. The system calculates the overall score of each candidate proposal daily, sorts them, and generates a push list. The push interface displays the proposals in list format, with each proposal including its type (e.g., rule relaxation), overall score, and a summary of key parameters (historical adoption rate, expected prescription volume impact, risk level). The pharmacist's end displays 5 proposals per page, which can be clicked to view detailed feature summaries. To prevent duplicate pushes, proposals rejected by pharmacists will not be pushed again for 7 days; for proposals not yet implemented by pharmacists, the score will be recalculated and pushed again after 3 days, with a maximum of 3 pushes.

[0048] The HIS system records pharmacists' selection of candidate treatment plans and the actual changes in rule effectiveness after plan implementation. This data is used to update the prior parameters corresponding to each plan in the confidence upper bound algorithm. When a pharmacist adopts a plan, the system increases the adoption count and the number of times it is pushed to the pharmacist by 1. When a pharmacist rejects a plan or fails to act within the cooling-off period, only the number of times it is pushed to the pharmacist is increased by 1. Simultaneously, within 30 days of plan implementation, the system continuously tracks changes in the mandatory release rate, interception rate, and adverse reaction rate corresponding to the rule, using these actual effectiveness changes to adjust the expected prescription coverage and risk coefficient of the plan. For example, if the actual prescription coverage deviates from the expected value by more than 20%, the expected value is adjusted to the average of the actual value and historical estimates; if a new adverse reaction report occurs after implementation, the risk coefficient increases by 0.1 (not exceeding 0.95), otherwise the risk coefficient decreases by 0.05 (not lower than 0.05). The updated parameters are used for subsequent comprehensive score calculations.

[0049] This implementation employs a confidence upper bound algorithm to comprehensively evaluate candidate solutions based on their historical adoption rate, expected prescription coverage, and risk coefficient. Solutions are then pushed in descending order of score, allowing pharmacists to prioritize modified solutions with high overall benefits and reducing trial-and-error costs. Simultaneously, the system records pharmacists' selections and changes in rule effectiveness after implementation, dynamically updating prior parameters in the algorithm accordingly. This ensures that recommendations better align with the hospital's clinical realities and pharmacists' preferences as usage increases, improving the intelligence and efficiency of rule maintenance and reducing the time pharmacists spend selecting solutions.

[0050] In another embodiment of the present invention, the construction and iterative updating of the medical insurance restriction rule base includes: The initial construction steps use national and local medical insurance drug payment policy documents, medical insurance drug catalogs, and payment restriction texts as data sources. A pre-trained sequence labeling model is invoked to automatically extract fields such as generic drug name, medical insurance code, limited indications, limited treatment course, limited medical institution level, limited payment cycle, and limited combination therapy, generating a candidate list of structured rules. Confirmation instructions are received from the medical insurance management end, and the confirmed rules are entered into the medical insurance restriction rule base according to the instructions, and mapped and bound to the hospital's HIS drug dictionary. In specific implementation, the data source collects policy documents from the most recent calendar year, prioritizing the annual drug catalogs and local supplementary catalogs published by the National Healthcare Security Administration. The pre-trained sequence labeling model adopts a similar BERT-BiLSTM-CRF architecture as described above, but is fine-tuned for medical insurance-specific fields. The fine-tuning dataset contains 300 manually labeled policy documents. The confidence threshold for the extracted fields is set to 0.8; fields below this threshold are not included in the candidate list. The candidate list of structured rules is displayed in tabular form on the medical insurance management interface, showing 15 rules per page. Medical insurance managers can select "Confirm," "Modify," or "Reject." Once confirmed, the rules are entered into the medical insurance payment rule table in the database. Simultaneously, the system automatically matches the generic drug names in the rules against drugs in the HIS drug dictionary. The matching method is exact matching of the generic name; if a match fails, fuzzy matching (similarity threshold 0.85) is used, and manual intervention is prompted. After the mapping and binding are completed, each rule generates a unique rule number and an effective timestamp.

[0051] The iterative update process periodically acquires data on changes in medical insurance policies and uses a change identification algorithm to automatically identify newly added, modified, or abolished rule entries. For changed entries, candidate update schemes are generated, sorted by impact scope, and pushed to the medical insurance management terminal. The system receives confirmation or adjustment instructions from the medical insurance management terminal, replaces the original rules using a hot update method based on the instructions, and records the effective time and operator identification. For abolished rules, the system automatically moves them to the historical archive area and stops their use in the review process. In practice, the system automatically accesses the RSS subscription or specified URL of the national and local medical insurance bureau policy release pages every 24 hours; if a new file is detected, the processing flow is triggered. The core of the change identification algorithm is to compare the rule text of the old and new versions, using a semantic similarity-based matching method for identification. For identified changed entries, the system generates three categories of candidate update schemes: "new rules," "modified rules (including comparison with the old version)," and "abolished rules." The impact scope is sorted based on the prescription frequency of the drugs involved in the rule in the past 30 days; rules with higher prescription frequency are ranked higher. After being pushed to the medical insurance management terminal, administrators can view the differences in highlighting before and after the change, and click to confirm or manually adjust the rule content. Upon confirmation, the original rule is replaced using a hot update method (updated via Redis cache), while simultaneously recording the operator's identifier and the effective time (accurate to the second). Deprecated rules have their status field set to archived and are copied to the historical archive table; they are no longer invoked in the review process.

[0052] The system continuously collects refusal events and their cause classifications from the hospital's medical insurance refusal appeal module, and collects the number of consultations from medical insurance consultation records. It calculates a review trigger score by combining this with the rule ambiguity score. When this score exceeds a dynamic threshold, the rule is automatically marked as pending review and an alert is pushed to the medical insurance management terminal. In practice, a refusal event is defined as a prescription record that is refused payment after medical insurance settlement due to non-compliance with payment conditions. The system reads refusal events daily from the medical insurance refusal appeal module interface, classifies them by rule number, and statistically analyzes the number of refusal events and their causes (e.g., "mismatched indications" or "exceeded treatment duration"). Medical insurance consultation records are defined as telephone or online consultations conducted by clinical departments or the medical insurance office regarding the payment conditions for a specific drug. The system collects the number of consultations from the medical insurance consultation system. The review trigger score is calculated as follows: the refusal event frequency (i.e., the number of refusal events corresponding to the rule within the statistical period divided by the total number of prescriptions for the drug involved in the rule) multiplied by a first weight, plus the consultation frequency (number of consultations divided by the total number of prescriptions) multiplied by a second weight, plus the rule ambiguity score multiplied by a third weight. The rule fuzziness score is obtained by segmenting the rule constraint text into words, matching it against a fuzzy word dictionary (containing words such as "discretionary," "appropriate," "when necessary," "general," "usually," "can be considered," "suggested," and "not suitable"), and calculating the ratio of fuzzy words to the total number of words. The initial values ​​of the three weights are set to 0.4, 0.3, and 0.3, respectively. The system dynamically adjusts these weights every 30 days using an online gradient descent method based on the accuracy of historical review results, with an adjustment step size of 0.01. The dynamic threshold is set as follows: the average score of all rule review triggers over the past 90 days is added to 1.5 times the standard deviation. When the score of a rule exceeds this threshold, the system automatically marks the rule as pending review and pushes an alert to the medical insurance management interface. The alert information includes the rule number, drug name, score details, and the trend of refusal of payment and consultation over the past 30 days.

[0053] The rule construction and iterative update method in this implementation automatically extracts policy document fields to generate a candidate rule list, which, combined with confirmation and input from the medical insurance management terminal, reduces the manual input for initial rule construction. It periodically acquires medical insurance policy change data and automatically identifies change items, generates candidate update schemes, pushes them for confirmation, and then performs hot updates, ensuring the rules are synchronized with the latest policies. Simultaneously, by collecting refusal payment events and consultation records and combining them with rule ambiguity scoring to calculate review trigger scores, it proactively issues warnings when the score exceeds a dynamic threshold. This allows for the timely identification of potentially ambiguous or controversial rules, reducing the risk of refusal payment due to rule ambiguity and decreasing the workload of manual inspections.

[0054] In another embodiment of the present invention, the change identification algorithm specifically includes: The HIS system periodically retrieves medical insurance policy documents from the medical insurance policy data interface, policy document import port, or policy release pages. It then uses an optical character recognition (OCR) engine to convert unstructured policy documents into text. Specifically, the system can start a scheduled task every 24 hours, with a default execution time of 1:00 AM. This task accesses the medical insurance policy data interface, policy document import port, or a list of policy release page URLs specified by the National Healthcare Security Administration and local healthcare security bureaus (configurable, up to 20 URLs can be added). Page parsing uses HTTP GET requests with a timeout of 30 seconds. If the download fails, it retryes three times, with a 5-minute interval between attempts. Downloaded policy documents are typically in PDF format. The system uses an OCR engine for text recognition, preprocessing the PDF image before recognition (300 DPI resolution, grayscale, binarization threshold set to 128). The recognized text is stored in TXT format, named "Policy Source-Release Time-Original Filename.txt". For already processed files, the system avoids duplicate processing by comparing file hash values ​​(MD5). The hash value database retains records from the last 180 days.

[0055] A contrastive learning-based semantic similarity model is invoked to calculate the semantic similarity between extracted candidate rules and each rule in the existing medical insurance restriction rule base. If the similarity exceeds a preset threshold, the rule is considered an existing rule, and no changes are made. The contrastive learning-based semantic similarity model employs the SimCSE or SBERT architecture and is fine-tuned on a medical insurance policy text corpus. The fine-tuning dataset contains 5000 manually annotated rule text pairs (similar or not). The model maps each rule text (including fields such as generic drug name, limited indications, and limited treatment duration) into a 768-dimensional semantic vector. Candidate rules are extracted from the OCR-converted text using regular expressions to match key fields (such as paragraphs containing keywords like "drug name," "payment scope," "limited," and "indications"). The system calculates the cosine similarity between each candidate rule vector and all rule vectors in the existing rule base, with the cosine similarity value ranging from 0 to 1. The preset threshold is set to 0.85. If the similarity between a candidate rule and an existing rule is greater than or equal to 0.85, it is determined to be an existing rule, and no change entry is generated. If all similarities are below 0.85, the next step of judgment is initiated. The threshold can be manually adjusted according to actual operation, with an adjustment step of 0.05, and the adjustment takes effect the next day.

[0056] Rules are classified as newly added or substantially modified only when the similarity is below a threshold. For candidate rules with a similarity below 0.85, the system further assesses their difference from the most similar rule in the rule base (i.e., the one with the highest similarity). If the similarity between the most similar rule and the candidate rule is between 0.6 and 0.85, it is classified as a substantially modified rule (i.e., a revision of an existing rule); if the similarity is below 0.6, it is classified as a newly added rule (i.e., there is no corresponding entry in the rule base). Rules classified as newly added or substantially modified are entered into the subsequent processing flow as change entries. The system also records the basis for the judgment (similarity value and the number of the most similar rule) for review by medical insurance management personnel.

[0057] For rules deemed substantially modified, a word vector-based differential localization algorithm is used to annotate the specific difference fields between the two versions and generate a highlighted comparison view. The specific process is as follows: The candidate rule text and the text of the most similar rule (i.e., the old version) are segmented separately. Jieba segmentation can be used, and a medical insurance-specific dictionary (containing 500 medical insurance terms) is loaded. Then, each word is converted into a pre-trained word vector (trained using Word2Vec on medical insurance policy text, with a vector dimension of 200). The differential localization algorithm uses dynamic programming to calculate the longest common subsequence of the two word sequences to find the positions of mismatched words. For mismatched words, the Euclidean distance between their word vectors is further calculated. If the distance is greater than 0.3, it is marked as "substantial difference"; otherwise, it is marked as "word usage difference." The final annotation results are displayed in a highlighted comparison view: content deleted in the old version is marked with a red strikethrough, and content added in the new version is marked with a green underline. The comparison view supports export in HTML format for viewing in a browser by the medical insurance management system. The system also extracts the difference fields (such as changing the treatment course from "7 days" to "14 days") into structured information, which facilitates the generation of candidate update plans in the future.

[0058] The change recognition algorithm in this implementation achieves automated collection of policy changes by periodically downloading policy documents and converting the text using OCR. A semantic similarity model based on contrastive learning accurately distinguishes between existing rules and newly added or modified rules, and a preset similarity threshold (0.85) effectively filters out non-substantive textual adjustments. For substantive modified rules, a word vector-based differential localization algorithm accurately marks the specific differences between versions and generates a highlighted comparison view, enabling medical insurance administrators to intuitively understand the changes, significantly improving the accuracy and efficiency of rule updates, and reducing the workload of manual comparison.

[0059] In another embodiment of the present invention, the calculation method for the review trigger score specifically includes: Set a statistical period to obtain the number of medical insurance reimbursement rejection events and medical insurance consultations generated for the rules to be reviewed within that period, and calculate the reimbursement event frequency and consultation frequency respectively. The statistical period can be set to 30 days, and the system will automatically calculate the data for the past 30 days daily. The number of medical insurance reimbursement rejection events is collected from the hospital's medical insurance reimbursement appeal module, limited to reimbursement types directly related to the medical insurance payment indication rules, such as inconsistency in indications, exceeding the treatment course limit, or inconsistency in the level of medical institutions. The reimbursement event frequency is calculated by dividing the number of reimbursement events by the total number of prescriptions for the drugs involved in the rule within the statistical period, and the result is expressed as a percentage (‰). If the total number of prescriptions is zero, the frequency is set to zero. The number of medical insurance consultations is collected from the medical insurance consultation system, including telephone consultations and online consultation work orders. The consultation frequency is also calculated by dividing the number of consultations by the total number of prescriptions, and expressed as a percentage (‰). The system performs data collection at 3:00 AM daily, and the interface timeout is set to 15 seconds.

[0060] A fuzzy word dictionary is constructed, containing at least the following vague expressions: "discretionary," "appropriate," "when necessary," "general," "usually," "can be considered," "suggested," and "not suitable," and can be expanded to include 20 common vague words (such as "handle with discretion," "depending on the situation," "about," "around," "long-term," "short-term," "reasonable," and "conventional"). The limiting condition text of the rule to be reviewed is extracted and segmented (using jieba segmentation with a medical insurance-specific dictionary). The segmentation results are precisely matched against the fuzzy word dictionary. The number of successfully matched fuzzy words is counted, and the ratio of the number of fuzzy words to the total number of words in the limiting condition text is calculated as the rule's fuzziness score. For example, if the limiting condition is "limited to patients with poor results from conventional treatment, usually with a treatment course not exceeding 7 days," and the words "conventional" and "usually" are matched, for a total of 10 words, the fuzziness score is 0.2. The fuzziness score ranges from 0 to 1; a higher score indicates a more vague rule expression.

[0061] The review trigger score is obtained by multiplying the frequency of non-payment events, consultation frequency, and rule ambiguity score by preset first, second, and third weights, respectively, and then summing them. The initial weights can be set to 0.4 for the first weight, 0.3 for the second weight, and 0.3 for the third weight. Since the frequency values ​​and ambiguity scores are of different magnitudes, the frequency of non-payment events and consultation frequencies are normalized before calculation by dividing them by the average of the frequencies corresponding to all rules within the statistical period (the average of the entire hospital over the previous 30 days), ensuring that the three values ​​are of similar magnitudes. For example: if the frequency of non-payment events for a certain rule is 5‰, the hospital average is 4‰, and the normalized value is 1.25; the consultation frequency is 3‰, the hospital average is 2‰, and the normalized value is 1.5; and the ambiguity score is 0.2; then the review trigger score = 1.25 × 0.4 + 1.5 × 0.3 + 0.2 × 0.3 = 0.5 + 0.45 + 0.06 = 1.01. A review warning is triggered when this score exceeds the dynamic threshold.

[0062] The initial values ​​of the first, second, and third weights are fixed values ​​preset by the HIS system (0.4, 0.3, 0.3). The system continuously collects the actual review results after each review trigger (i.e., whether the medical insurance management personnel confirm that the rule "has a problem" or "has no problem") and dynamically adjusts the three weights using an online gradient descent method.

[0063] After each review, the system calculates the error between the predicted score and the actual result (error caused by missed or false alarms), and then updates the weights with a learning rate of 0.01: the new weight equals the old weight minus the learning rate multiplied by the error multiplied by the corresponding feature value. The feature value is the normalized value of each dimension indicator. Specifically, for the refusal event frequency feature, its feature value = (current rule refusal frequency / hospital-wide average refusal frequency during the same period); for the consultation frequency feature, its feature value = (current rule consultation frequency / hospital-wide average consultation frequency during the same period); for the rule fuzziness scoring feature, its feature value = number of fuzzy words / total number of words in the limiting condition text (value range [0,1]). After the update, the weights are normalized (so that the sum of the three is 1 and non-negative). The system recalculates the dynamic threshold every 7 days (taking the average of all rule scores in the past 90 days plus 1.5 times the standard deviation), and uses the updated weights for the score calculation in the next cycle. Through continuous iteration, the weight combination is gradually optimized, making the review trigger score more accurately reflect the true risk of the rule.

[0064] In this implementation, the review trigger score is calculated by comprehensively considering three dimensions: the frequency of refusal events, the frequency of inquiries, and the ambiguity score of the rules. This quantifies the actual problems and inherent ambiguity of the rules. An online gradient descent method is used to dynamically adjust the three weights, enabling the scoring model to adaptively learn the actual patterns of refusal events and inquiries within the hospital. This avoids underreporting or false reporting caused by fixed weights, improves the accuracy of rule identification, and allows limited review resources to be focused on rules with genuine problems, reducing the review workload for medical insurance management personnel.

[0065] In another embodiment of the present invention, each rule in the rational drug use rule base and the medical insurance restriction rule base is configured with a creation timestamp and an effective timestamp. The creation timestamp records the moment the rule is first entered into the system, and the effective timestamp records the moment the rule is first used for prescription review. Both are in the format YYYY-MM-DD HH:MM:SS, accurate to the second. For initially entered rules, the effective timestamp is the same as the creation timestamp by default. When a rule is hot-updated, the system does not modify the original rule, but generates a new version record. The creation timestamp of the new rule is the current moment, and the effective timestamp is specified by the pharmacist or medical insurance administrator (usually set to the next full hour after the confirmation time, for example, if confirmed at 14:23, the effective time is set to 15:00:00). The effective timestamp of the old version rule remains unchanged, and its status is marked as "expired" for historical query.

[0066] During the double verification in step 3), the HIS system obtains the prescription issuance time. The prescription issuance time is the timestamp recorded by the system when the physician clicks "Save" or "Submit" in the HIS system, in the same format: YYYY-MM-DD HH:MM:SS, accurate to the second. This timestamp is automatically generated by the HIS server and cannot be manually modified. When the system triggers an audit, it reads this timestamp from the prescription data. If it is missing due to an anomaly, the current server time is used as a backup timestamp and recorded in the log.

[0067] The system only calls the latest version of the rule whose effective timestamp is no later than the prescription issuance time. The specific judgment logic is as follows: For each rule that needs to be verified, the system searches all version records of that rule, filters out versions whose effective timestamp is less than or equal to the prescription issuance time, and then selects the version with the largest effective timestamp as the rule to be called this time. For example, a rule has three versions: version A effective on 2025-01-01 08:00:00, version B effective on 2025-03-15 10:00:00, and version C effective on 2025-04-01 00:00:00. If the prescription issuance time is 2025-03-20 09:30:00, then versions A and B meet the condition, and version B is selected; if the prescription issuance time is 2025-04-02 12:00:00, then version C is selected. If the prescription is issued before the effective date of all versions, no version is available. The system logs the error and adopts a lenient rule (no blocking), while notifying the administrator to check the configuration.

[0068] In this implementation, by configuring creation and activation timestamps for each rule, the latest version of the rule, no later than the prescription issuance time, is dynamically called during dual verification. This ensures that the rule version used for prescription review is consistent with the policy or clinical requirements at the time of prescription issuance, avoiding erroneous blocking or approval of historical prescriptions that have been issued but not yet settled after rule updates. It also supports time-slot activation of rules, facilitating smooth rule switching during off-peak hours for hospitals, reducing the interference of rule changes on clinical diagnosis and treatment, and making the historical traceability and auditing of rules clearer.

[0069] In yet another embodiment of the invention, the method further includes: Establish a patient-level medication accumulation ledger to store valid prescriptions for each patient that have not yet exceeded their treatment course. Specifically, the medication accumulation ledger is stored in a database table containing the following fields: patient unique identifier (e.g., medical card number or ID card number), drug generic name, drug ATC classification code (used to identify similar drugs), cumulative dosage (in mg, ml, or tablets), remaining medical insurance payment limit (in yuan), prescription date, and expected treatment course end date. The ledger only records valid prescriptions that have not yet exceeded their treatment course, which is defined as the number of days of medication use specified in the rules (e.g., 7 days, 14 days, or 30 days). Records exceeding the treatment course end date are automatically invalidated and removed from the ledger (a cleanup task is performed daily at 4:00 AM). For cases where the same patient has multiple valid prescriptions for the same drug, the ledger merges the dosages and stores them as a cumulative value. The data source for this ledger is automatic system updates after each prescription approval, occurring after either step 3) or step 4).

[0070] In step 3) during dual verification, the HIS system first retrieves the cumulative usage and remaining medical insurance reimbursement limit for the same or similar drugs from the medication accumulation ledger based on the patient's identifier. The criteria for determining if a drug is the same are a complete match between the generic name and the hospital drug code. The criteria for determining if drugs are similar are that the first four digits of the ATC classification code are the same (representing the same pharmacological subclass), for example, nifedipine and amlodipine both belong to class C08C. During the retrieval, the system obtains the drug information in the current prescription, queries the ledger for records of the same or similar drugs for the patient, and if found, reads the cumulative usage and remaining medical insurance reimbursement limit. If a drug has both medical insurance reimbursement and out-of-pocket payment history, the ledger separately calculates the usage for the medical insurance reimbursement portion and the out-of-pocket portion, since the out-of-pocket portion does not occupy the medical insurance reimbursement limit. Then, the current prescription application quantity is combined with the cumulative quantity to determine whether it exceeds the periodic total limit in the medical insurance restriction rule base or the cumulative safe dosage limit in the rational drug use rule base. Cycle quantity limits include, for example, medical insurance rules stipulating that a certain drug cannot exceed 30 doses per quarter or 2000 yuan per month; cumulative safe dosage limits include, for example, rational drug use rules stipulating that the cumulative dosage of a certain drug cannot exceed 5 times the maximum daily dose (based on the drug's instructions). The judgment logic is: the current prescription application quantity plus the cumulative usage in the ledger; if it exceeds either the cycle quantity limit or the cumulative safe dosage limit, the condition is not met. For example, if a patient has cumulatively used 28 doses of a certain drug, the cycle quantity limit is 30 doses, and the current prescription application is for 3 doses, the combined quantity is 31 doses, exceeding the limit, and therefore the application is rejected. For restrictions on similar drugs, the system must also combine the usage of similar drugs in the calculation (e.g., the sum of the cumulative doses of two ACEI antihypertensive drugs). The application is only approved if all restrictions are still met after combining; otherwise, it is blocked, and the historical usage details and remaining available dosage are displayed.

[0071] The system provides real-time feedback on the prescription issuance interface: if approved, the prescription is issued normally, and the system updates the medication accumulation ledger after issuance (adding the current dosage to the cumulative amount and deducting the corresponding medical insurance payment). If rejected, the prescription is intercepted, and a pop-up window displays historical dosage details (e.g., "A certain drug, 28 doses used, details: 10 doses prescribed on 2025-05-01, 18 doses prescribed on 2025-05-10"), as well as the remaining prescription quantity (e.g., "2 doses remaining for this cycle"). Physicians can adjust the prescription accordingly (e.g., reduce the dosage or change the drug) and resubmit. The system also records the reason for the interception in the review log for subsequent traceability. This ledger mechanism supports cumulative quantity control across multiple departments and prescriptions, preventing patients from obtaining excessive dosages of the same drug from multiple departments.

[0072] In this implementation, by establishing a patient-level medication accumulation ledger, the cumulative dosage of current prescriptions and historical valid prescriptions is merged during dual verification to determine whether the total dosage limit or cumulative safe dosage limit has been exceeded. This effectively solves the problem of cumulative overdosing across prescriptions and departments. By displaying detailed historical dosages and remaining available dosages, physicians are provided with clear decision-making basis, avoiding over-prescribing due to information asymmetry, and ensuring patient medication safety and the rationality of medical insurance payments. Simultaneously, the ledger automatically clears records exceeding the treatment course, ensuring data accuracy and lightweight system operation.

[0073] In yet another embodiment of the present invention, the conflict arbitration rule in dual verification specifically includes: The validation results of the rational drug use rule base are pre-set to have a higher priority than the medical insurance restriction rule base. This priority setting is stored as a parameter in the system configuration file. This configuration is loaded when the system starts up, and the processing logic is determined based on this priority during each double validation. This priority setting cannot be modified by physicians in the prescription issuance interface; it can only be adjusted by the system administrator in the background configuration file. After adjustment, the audit service must be restarted for it to take effect.

[0074] When the dual verification result in step 3) is that the rational drug use rule base fails but the medical insurance restriction rule base passes, the HIS system forcibly intercepts the prescription and does not provide the "convert to out-of-pocket payment" option. The specific execution process is as follows: The system first calls the rational drug use rule base for verification. If it returns a failure (e.g., violation of contraindications, overdose, duplicate medication, etc.), it directly enters the interception process regardless of the medical insurance rule verification result. At this time, the system does not continue to display the "convert to out-of-pocket payment" prompt button (this button only appears when the rational drug use rule base passes but the medical insurance rule fails). Simultaneously, the system displays the risk basis (e.g., "This drug is contraindicated in patients allergic to this product, and the patient's allergy history record is positive") and clinical alternative suggestions (e.g., "It is recommended to switch to drug B or undergo desensitization treatment"). The risk basis is read from the rule description field stored in the rational drug use rule base, and the clinical alternative suggestions are read from the alternative scheme field corresponding to the rule. The content is displayed in a pop-up window with a light yellow background to distinguish it from regular prompts. The pop-up includes a "Close" button but not "Force Release" or "Convert to Out-of-Position Payment" buttons. Physicians can only close the pop-up and then modify the prescription or abandon the prescription. Only when the rational drug use rule base is approved will the system execute the approval, blocking, or conversion to out-of-pocket payment operation based on the verification result of the medical insurance restriction rule base. The specific logic is as follows: If the rational drug use verification passes, the medical insurance restriction rule base is called again. If the medical insurance verification also passes, the prescription is released; if the medical insurance verification fails, step 3a) is executed (generating a "Convert to Out-of-Position Payment" prompt, checking and confirming the event, switching the payment attribute and releasing, or blocking). If the rational drug use verification fails, the forced blocking described in the second feature above is executed directly, without further evaluation of the medical insurance verification result. This processing order ensures that clinical safety takes precedence over medical insurance compliance, avoiding the use of clinically risky drugs in pursuit of medical insurance payment.

[0075] The conflict arbitration rules set up in this implementation clearly stipulate that the rational drug use rule base has higher priority than the medical insurance restriction rule base. When a rational drug use rule fails while a medical insurance rule succeeds, the system forcibly blocks the prescription and does not provide an option to switch to out-of-pocket payment, preventing the risk of ignoring clinical safety due to the temptation of medical insurance payment. At the same time, it shows physicians the specific risk basis and clinical alternative suggestions, which helps physicians adjust prescriptions. Only after a rational drug use rule succeeds will subsequent operations be performed according to the medical insurance rule, making the review logic clear, secure and rigorous.

[0076] The number of devices and processing scale described herein are for simplification of the invention. Applications, modifications, and variations of the prescription pre-approval method based on dual rule base linkage of this invention will be readily apparent to those skilled in the art.

[0077] Although embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, other modifications can be easily made. Therefore, without departing from the general concept defined by the claims and their equivalents, the present invention is not limited to the specific details and illustrations shown and described herein.

Claims

1. A prescription pre-approval method based on dual rule base linkage, applied to a hospital HIS system, executed by a prescription pre-approval server, characterized in that... Includes the following steps: 1) Establish independent databases for rational drug use rules and medical insurance restriction rules; 2) Obtain information on prescription drugs and their charging attributes, including whether they are covered by medical insurance or out-of-pocket; 3) If the payment type is covered by medical insurance, both the rational drug use rule base and the medical insurance restriction rule base will be used for dual verification. The prescription will only be approved and released if it meets the applicable conditions of both rule bases simultaneously. If the dual verification fails, the reason for failure will be further determined: 3a) If the applicable conditions of the medical insurance restriction rule base are not met but the rational drug use rule base is met, a prompt with a self-pay settlement identifier is generated and the confirmation operation event of the prompt is detected. When the confirmation operation event is detected, the drug's charging attribute is switched to self-pay and released after passing the single verification according to the rational drug use rule base. At the same time, the reason for the conversion is automatically recorded. 3b) If the applicable conditions of the rational drug use rule base are not met, then filter from the rational drug use rule base. For drug information that meets the applicable conditions, generate recommendations for alternative drugs or suggestions for adjusting the usage and dosage, and detect the adoption of the suggestions. When an adoption event is detected, the verification is retried. 4) If the charge attribute is self-paid, only the rational drug use rule base is called for single verification. If the verification fails, the recommendation and re-verification process in step 3b) is executed. 5) The verification results, prompts, and suggestions will be fed back to the prescription issuance interface in real time. Prescriptions that fail the verification will be intercepted and specific rules will be provided.

2. The prescription pre-approval method based on dual rule base linkage as described in claim 1, characterized in that, The construction and iterative updates of the rational drug use rule base include: Initial construction steps: Using drug instructions, clinical practice guidelines, hospital prescription sets, and historical desensitized prescription data as data sources, a pre-trained sequence labeling model is called to automatically extract fields such as drug indications, contraindications, dosage and administration, and treatment course restrictions to generate a candidate list of structured rules; a review and correction instruction is received from the pharmacist's end, and the confirmed rules are entered into the rational drug use rule library according to the instruction; Iterative update steps: Daily, read the physician forced release trigger events and their frequency corresponding to each rule from the prescription review log of the HIS system, and read the corresponding adverse reaction rate related to the drug from the hospital adverse event reporting system or follow-up platform; use statistical process control methods to detect whether there are abnormal fluctuations in rule effectiveness; when abnormal fluctuations are detected, automatically extract the prescription characteristics and physician modification behavior that triggered the rule, generate three types of candidate modification schemes: "rule tightening", "rule relaxation", and "adding exception conditions", and push them to the pharmacist end after sorting them by the scope of impact; receive confirmation or fine-tuning instructions for candidate modification schemes from the pharmacist end, replace the original rule with a hot update according to the instructions, and record the version change and the operation pharmacist's identification; for rules that have not been triggered for two consecutive months and have received low-priority marking instructions from the pharmacist end, they are automatically put into a dormant state. Low-priority marking instructions are initiated manually by pharmacists in the rule management interface for rules that have not been triggered for a long time and have been assessed as having low clinical necessity. When marking, the marking reason must be filled in.

3. The prescription pre-approval method based on dual rule base linkage as described in claim 2, characterized in that, The statistical process control method is as follows: the HIS system obtains seasonal disease index from the hospital epidemiological surveillance system, obtains baseline change data of drug usage from the drug procurement module, and obtains policy change timestamps of relevant rules from the policy early warning interface, and extracts the above data as external covariates; An accumulated summation control chart with covariate correction is used to incorporate external covariates into the control chart offset calculation to eliminate performance fluctuations caused by irregular inherent factors; abnormal fluctuations are only judged when the cumulative offset of the regular performance after deducting the influence of external covariates exceeds a preset threshold.

4. The prescription pre-approval method based on dual rule base linkage as described in claim 2, characterized in that, After generating three types of candidate modification schemes, the HIS system uses a confidence upper bound algorithm to calculate a comprehensive score based on the historical adoption rate, expected prescription coverage, and risk coefficient of each candidate scheme. The scores are then sorted in descending order and pushed to the pharmacist's end. The HIS system records the pharmacist's selection results for the candidate schemes and the actual changes in the rule effectiveness after the schemes are implemented, which are used to update the prior parameters corresponding to each scheme in the confidence upper bound algorithm.

5. The prescription pre-approval method based on dual rule base linkage as described in claim 1, characterized in that, The construction and iterative updates of the medical insurance restriction rule base include: Initial construction steps: Using national and local medical insurance drug payment policy documents, medical insurance drug catalogs, and payment restriction texts as data sources, a pre-trained sequence labeling model is invoked to automatically extract fields such as generic drug name, medical insurance code, restricted indications, restricted treatment course, restricted medical institution level, restricted payment cycle, and restricted combination drug use, generating a candidate list of structured rules; receiving confirmation instructions from the medical insurance management terminal, the confirmed rules are entered into the medical insurance restriction rule library according to the instructions, and mapped and bound to the hospital's HIS drug dictionary; Iterative update steps: Regularly acquire medical insurance policy change data, and use change recognition algorithms to automatically identify newly added, modified, or abolished rule entries; for changed entries, generate candidate update schemes, sort them by impact scope, and push them to the medical insurance management terminal; receive confirmation or adjustment instructions from the medical insurance management terminal, replace the original rules with hot updates according to the instructions, and record the effective time and operator identification; for abolished rules, the system automatically moves them to the historical archive area and stops calling them in the review process; at the same time, the system continuously collects the refusal events and reason classifications in the hospital's medical insurance refusal appeal module, and collects the number of consultations in the medical insurance consultation records, calculates the review trigger score by combining the rule fuzziness score, and when the score exceeds the dynamic threshold, automatically marks the rule as pending review and pushes an alert to the medical insurance management terminal.

6. The prescription pre-approval method based on dual rule base linkage as described in claim 5, characterized in that, The change recognition algorithm specifically includes: the HIS system periodically obtains medical insurance policy documents from the medical insurance policy data interface, policy document import port, or policy release page, and uses an optical character recognition engine to convert unstructured policy documents into text; it calls a semantic similarity model based on contrastive learning to calculate the semantic similarity between the extracted candidate rules and each rule in the existing medical insurance restriction rule base; when the similarity exceeds a preset threshold, it is determined to be an existing rule and no change entry is generated; only when the similarity is lower than the threshold is it determined to be a newly added or substantially modified rule; for rules determined to be substantially modified, a differential positioning algorithm based on word vectors is used to mark the specific difference fields between the two versions and generate a highlighted comparison view.

7. The prescription pre-approval method based on dual rule base linkage as described in claim 5, characterized in that, The calculation method for the review trigger score includes: setting a statistical period, obtaining the number of medical insurance refusal events and medical insurance consultations generated for the rule to be reviewed within the statistical period, and calculating the refusal event frequency and consultation frequency respectively; constructing a fuzzy word dictionary, which must contain at least the fuzzy expression words "discretionary", "appropriate", "when necessary", "general", "usually", "can be considered", "suggested", and "not suitable"; extracting the limiting condition text of the rule to be reviewed, performing word segmentation on the limiting condition text, matching the word segmentation results with the fuzzy word dictionary, counting the number of successfully matched fuzzy words, and calculating the ratio of the number of fuzzy words to the total number of words in the limiting condition text as the rule fuzziness score; calculating the review trigger score, which is calculated as follows: Review trigger score = first weight × refusal event frequency + second weight × consultation frequency + third weight × rule fuzziness score; wherein, the initial values ​​of the first weight, second weight, and third weight are preset fixed values ​​of the HIS system, and the HIS system continuously collects the actual review results after each review trigger, and dynamically adjusts the first weight, second weight, and third weight using an online gradient descent method.

8. The prescription pre-approval method based on dual rule base linkage as described in claim 1, characterized in that, Each rule in the rational drug use rule base and the medical insurance restriction rule base is configured with a creation timestamp and an effective timestamp; during the double verification in step 3), the HIS system obtains the prescription issuance time and only calls the latest version of the rule whose effective timestamp is no later than the prescription issuance time.

9. The prescription pre-approval method based on dual rule base linkage as described in claim 1, characterized in that, It also includes establishing a patient-level medication accumulation ledger to store information on valid prescriptions for each patient that have not yet exceeded the course of treatment. During the double verification in step 3), the HIS system first retrieves the accumulated dosage and remaining medical insurance payment amount of the same drug or similar drugs from the medication accumulation ledger based on the patient's identifier. Then, it merges the current prescription application amount with the accumulated amount to determine whether it exceeds the cycle total limit in the medical insurance restriction rule base or the cumulative safe dosage limit in the rational drug use rule base. It only passes if all restriction conditions are still met after merging; otherwise, it intercepts and displays the historical dosage details and the remaining prescription amount.

10. The prescription pre-approval method based on dual rule base linkage as described in claim 1, characterized in that, The dual verification also includes conflict arbitration rules: the verification results of the rational drug use rule base are pre-set to have higher priority than the medical insurance restriction rule base; when the dual verification result in step 3) is that the rational drug use rule base fails while the medical insurance restriction rule base passes, the HIS system forcibly intercepts the prescription, does not generate a prompt with a self-pay settlement indicator, and shows the physician the risk basis and clinical alternative suggestions in the rational drug use rule base; only when the rational drug use rule base passes will the pass, intercept, or self-pay settlement operation be performed based on the verification result of the medical insurance restriction rule base.

Images