A regulatory method and system supporting dynamic hot update and efficient matching of rules

Abstract

This invention discloses a regulatory method and system supporting dynamic hot updates and efficient matching of rules, relating to the field of medical information. The method includes: constructing a rule runtime network; upon receiving a rule update instruction, executing a hot update step: parsing the rule update instruction and generating or modifying the corresponding target rule logic execution package; in an atomic transaction, updating the routing status of all dynamic routes related to the target rule logic execution package to active, and updating the status of the target rule logic execution package to active. Upon receiving a pending event, executing an efficient matching step: extracting feature keys; querying a hash inverted index table to obtain a first rule candidate set; performing logical operations on all first rule candidate sets to obtain a second rule candidate set; routing the pending event in parallel to each rule logic execution package in the second rule candidate set; and performing final matching verification. This achieves millisecond-level continuous operation of regulatory services and an order-of-magnitude increase in system throughput.

Description

Technical Field

[0001] This invention relates to the field of medical information technology, specifically to a regulatory method and system that supports dynamic hot updating and efficient matching of rules, and more particularly to a core engine architecture and its working method that can update business rules without loss and dynamically during continuous engine operation and achieve sub-millisecond matching of massive streaming data. Background Technology

[0002] With the deepening of medical informatization and the continuous reform of national medical insurance payment, intelligent medical supervision has become a rigid requirement in the industry. The industry supervision model has shifted from traditional manual sampling and post-event review to an intelligent supervision paradigm based on full data, encompassing "prevention before the event, control during the event, and traceability after the event." The intelligent supervision rule base dynamically released and mandated by national and local medical insurance bureaus is increasingly large and frequently updated. This poses two core challenges to the underlying rule engine: first, it must have the real-time processing capability for tens of millions of data streams per day; second, it must have the agile ability to respond to frequent policy changes and rule iterations, while maintaining 24 / 7 online supervision services.

[0003] Existing rule matching technologies, represented by the Rete algorithm, have become the de facto standard for rule engines due to their efficient handling of multi-rule and multi-object matching by constructing a shared condition network. However, the classic Rete algorithm and its variants suffer from two deep-seated bottlenecks when dealing with internet-based, high-concurrency medical monitoring scenarios:

[0004] On the one hand, in traditional Rete implementations, the rule network is built and stored in memory once during system initialization. Any addition, deletion, or modification of a rule must go through a complete process from stopping the service, recompiling the entire network of rules, to restarting and loading, which directly leads to business interruption. Some systems attempt to achieve hot deployment of rules through the KieContainer dynamic loading mechanism of rule engines such as Drools. For example, Chinese patent application CN120565011A discloses a dynamic rule engine loading method that dynamically generates DRL files through KieFileSystem and loads them into the rule engine, supporting incremental compilation. However, this dynamic loading still involves node replacement within the traditional rule network, which essentially modifies the network structure itself. Rules and condition nodes are directly coupled through pointers. Although the update process does not require restarting the service, there are still brief performance fluctuations, and the consistency of the system state observed by the business thread at the moment of update cannot be guaranteed. More importantly, this local replacement mechanism may still lead to fragmentation of the network structure when dealing with complex rule dependencies, resulting in a decline in system performance after long-term operation.

[0005] On the other hand, medical regulatory rules primarily target highly structured coded data such as diagnostic codes, drug codes, and treatment item codes. The classic Rete algorithm employs a network-wide broadcast matching strategy that iterates through all fact objects conditionally. This indiscriminate matching pattern generates a large number of invalid condition judgments and intermediate memory states. When handling tens of millions of medical transactions daily, this leads to soaring system latency and enormous CPU resource consumption, making it difficult to meet the stringent requirements of real-time interception scenarios (such as compliance verification at the moment of prescription issuance).

[0006] To overcome the above problems, the industry has made a number of attempts:

[0007] Chinese patent application CN120977514A discloses a reservation and resource scheduling system based on cognitive intelligence and a self-evolving rule engine. It includes rule hot loading and incremental update modules. Through an incremental update algorithm, it only transmits and replaces affected decision nodes in the rule network or relevant subgraphs in the knowledge graph, minimizing performance fluctuations and service interruption times during system updates. While this solution recognizes the inefficiency of traditional rule network updates, its improvement approach is limited to partial replacements within the existing network architecture, failing to fundamentally change the coupling relationship between rules and condition nodes. Furthermore, this solution focuses on performance fluctuations during the update process but does not address ensuring state consistency during the update or provide a security mechanism for rule decommissioning.

[0008] Chinese patent application CN117271541A discloses a data routing method for database clusters, introducing the concept of a "central dynamic routing table." This routing table is dynamically updated based on the database cluster status and is used to determine the target database cluster corresponding to a monitoring data query request. This solution solves the dynamic routing problem in database query scenarios, but it belongs to the data access layer technology and differs fundamentally from the logical routing within a rule engine. This solution does not involve core elements of a rule engine such as rule condition units, rule execution packages, and rule matching, nor does it provide the atomic transaction protocol and consistency guarantee mechanism required for hot rule updates.

[0009] In summary, while current intelligent monitoring systems widely integrate rule engines, their core technologies are mostly based on traditional open-source engines like Drools that haven't undergone deep modification. These solutions focus on describing business functions such as real-time monitoring and rule configurability, but their underlying engine architecture doesn't address or resolve the fundamental contradiction between static compilation and matching efficiency. In practical applications, compromises are often made by setting up periodic maintenance windows, reducing rule complexity, or sacrificing some real-time performance, failing to simultaneously meet the triple requirements of flexibility, efficiency, and continuity.

[0010] Therefore, there is an urgent need for a brand-new rules engine architecture that can achieve dynamic and incremental hot updates of rules without stopping or restarting the service. At the same time, it can deeply optimize the matching path for medical data characteristics and reduce the processing latency of a single event to the sub-millisecond level while ensuring state consistency, so as to support the efficient and stable operation of the next generation of intelligent medical supervision business. Summary of the Invention

[0011] This invention aims to solve the technical problem that existing rule engines, due to their fixed network structure, cannot simultaneously achieve dynamic hot updates and efficient matching of rules without interrupting business operations.

[0012] In a first aspect, to address the aforementioned technical problems, this invention provides a regulatory method that supports dynamic hot updating and efficient matching of rules, comprising:

[0013] A rule runtime network is constructed; the rule runtime network includes multiple shared condition calculation units, multiple rule logic execution packages, and a central dynamic routing table.

[0014] When a rule update instruction is received, the following hot update steps are performed:

[0015] Parse the rule update instruction to generate or modify the corresponding target rule logic execution package;

[0016] An atomic transaction is initiated to the central dynamic routing table. In the atomic transaction, the routing status of all dynamic routes related to the target rule logic execution package is updated to be on, and the status of the target rule logic execution package is updated to be active. After the atomic transaction is committed, the new rule or the modified rule takes effect immediately.

[0017] When a pending event is received, the following efficient matching steps are performed:

[0018] Extract the feature keys from the event to be processed;

[0019] For each feature key, locate the relevant shared condition calculation unit, query its built-in hash inverted index table, and obtain the first rule candidate set corresponding to the feature key;

[0020] Perform logical operations on all first rule candidate sets to obtain second rule candidate sets;

[0021] According to the central dynamic routing table, the events to be processed are routed in parallel to each rule logic execution package in the second rule candidate set;

[0022] Within the rule logic execution package, the encapsulated rule logic graph is executed to perform final matching verification on the event to be processed, and the corresponding action executor is triggered when the matching is successful.

[0023] Furthermore:

[0024] Each of the shared condition calculation units encapsulates an atomic condition judgment logic and has a built-in hash inverted index table. The hash inverted index table uses the possible values ​​that the atomic condition judgment logic is interested in as keys and the set of rule identifiers as values.

[0025] Each rule logic execution package encapsulates a complete regulatory rule's logic diagram and its corresponding action executor;

[0026] The central dynamic routing table maintains multiple dynamic routes from the shared condition calculation unit to the rule logic execution packet, and each route has a routing state that identifies whether the route is currently valid.

[0027] Furthermore, the atomic transaction is implemented using an atomic version switching protocol; the atomic version switching protocol includes:

[0028] In the transaction context, a new version snapshot containing the newly added routing record is created based on the currently effective routing snapshot, and the status of the target rule logic execution package is updated to active.

[0029] When a transaction is committed, an atomic operation is performed to atomically switch the global current route snapshot reference from pointing to the old version snapshot to pointing to the new version snapshot, so that the activation status of the newly added routing record and the target rule logic execution package takes effect on all concurrent business threads at the same time.

[0030] Furthermore, the hot update step also includes:

[0031] After the atomic transaction is committed, the hash inverted index table in the shared condition calculation unit associated with the target rule logic execution package is updated asynchronously.

[0032] Furthermore, the shared condition calculation unit includes a single-field hash inverted index unit for a single field and a composite condition calculation unit for a combination of multiple fields; wherein, the index key of the composite condition calculation unit is an ordered combination of multiple field values, and its value is a set of rule identifiers that directly depend on the specific combination.

[0033] Further, the step of performing logical operations on all the first rule candidate sets to obtain the second rule candidate set specifically includes:

[0034] When the rule of the event to be processed involves multiple atomic conditions connected by a logical AND, the intersection operation is performed on the first rule candidate set obtained from multiple single-field hash inverted index units to obtain the second rule candidate set;

[0035] or,

[0036] When the feature key of the event to be processed matches the index key of the composite condition calculation unit, the query result is directly used as the second rule candidate set.

[0037] Furthermore, the step of routing the events to be processed in parallel to each rule logic execution package in the second rule candidate set specifically includes:

[0038] Maintain a thread pool or coroutine scheduler;

[0039] Generate an independent execution task for each candidate rule logic execution package in the second rule candidate set;

[0040] The execution task is submitted to the thread pool or coroutine scheduler to process multiple candidate rule logic execution packages in parallel.

[0041] Furthermore, the efficient matching step also includes:

[0042] Before the matching process, a cache key is generated based on the hash value of the feature key of the event to be processed and the version number of the current central dynamic routing table, and the matching result cache is queried.

[0043] If the cache is hit, the corresponding matching result is directly retrieved and executed, skipping the subsequent matching process;

[0044] If the cache is not hit, the subsequent matching steps are executed, and the matching result is stored in the matching result cache.

[0045] Furthermore, when the version number of the central dynamic routing table increases due to rule updates, the matching result cache is automatically invalidated.

[0046] Furthermore, it also includes a rule-based smoothing offline step:

[0047] In response to the rule offline instruction, an atomic transaction is initiated to change the routing status of all routes pointing to the target rule logic execution packet in the central dynamic routing table to disconnect;

[0048] Update the status of the target rule logic execution package to a pending retirement status;

[0049] Monitor the number of active sessions within the target rule logic execution package. When the number of active sessions is zero, reclaim the resources occupied by the target rule logic execution package.

[0050] Furthermore, the rule logic execution package in the pending retirement state refuses to accept any new fact objects, but continues to provide full computation services for in-transit matching sessions that have entered its internal logic graph until all sessions end.

[0051] A second aspect of the present invention provides an intelligent monitoring system that supports dynamic hot updating and efficient matching of rules, comprising:

[0052] The rule definition and management layer is configured to provide a rule definition interface to receive and manage regulatory rules.

[0053] The incremental compilation and hot deployment layer is configured to parse approved rules, generate corresponding rule logic execution packages, and generate route change instructions.

[0054] The dynamic rule network runtime layer includes a fact preprocessing and distribution layer, a shared condition calculation and indexing layer, and a central routing and rule enforcement layer, wherein:

[0055] The fact preprocessing and distribution layer is configured to receive raw medical events and convert them into standard fact objects, extracting feature keys;

[0056] The shared condition calculation and indexing layer includes multiple shared condition calculation units, which are configured to receive the feature key and output a first rule candidate set by querying their built-in hash inverted index table;

[0057] The central routing and rule execution layer includes a central dynamic routing table and multiple rule logic execution packages. It is configured to route the standard fact object to the candidate rule logic execution package determined by the first rule candidate set according to the central dynamic routing table, and perform final matching verification.

[0058] The action execution and audit feedback layer is configured to execute actions generated after a successful match and record the entire matching process and results.

[0059] Furthermore, the incremental compilation and hot deployment layer includes a differential analysis engine for identifying the differences between the new rules and the existing rules, and generating the rule logic execution package and the route change instruction only for the differences.

[0060] Furthermore, the shared condition calculation unit in the shared condition calculation and index layer also includes a condition judgment logic module, which is used to perform precise judgment of the atomic condition when performing final matching verification within the rule logic execution package.

[0061] Furthermore, each record in the central dynamic routing table includes at least:

[0062] The source address points to a specific shared conditional computation unit;

[0063] The target address points to a specific rule logic execution package;

[0064] As a boolean flag for routing status.

[0065] Optional:

[0066] The system is applied to scenarios such as internet-based medical consultation supervision, medical insurance settlement supervision, or prescription review.

[0067] The original medical event includes at least one of the following: prescription issuance event and settlement application event;

[0068] The feature key includes at least one of drug code, diagnosis code, and treatment item code.

[0069] Compared with the prior art, the embodiments of the present invention have the following beneficial effects:

[0070] This invention decouples the rule logic execution package from the shared condition calculation unit by introducing a central dynamic routing table. This simplifies hot rule updates from traditional network reconstruction to atomic state switching of routing table records, enabling rules to take effect losslessly and instantly during continuous engine operation, thus completely eliminating the risk of business interruption. Simultaneously, by embedding a hash inverted index within the shared condition calculation unit, a two-stage matching pipeline of index pre-screening and precise route execution is constructed. Before matching, in-memory hash queries drastically reduce the range of rules to be processed from all rules to a very small number of candidate rules, thereby focusing computational resources on effective matching. This fundamentally solves the problem of ineffective computation and performance bottlenecks caused by the broadcast traversal of the traditional Rete algorithm.

[0071] This invention balances the flexibility of dynamic rule updates with the high performance of real-time processing of massive amounts of data, achieving millisecond-level continuous operation of regulatory services and an order-of-magnitude increase in system throughput. Attached Figure Description

[0072] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0073] Figure 1 This is a diagram illustrating the overall architecture of the regulatory engine disclosed in this invention.

[0074] Figure 2 This is a schematic diagram of the rule hot update process disclosed in this invention;

[0075] Figure 3 This is a schematic diagram of the efficient matching process disclosed in this invention;

[0076] Figure 4 This is a schematic diagram of the matching process in the traditional solution. Detailed Implementation

[0077] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0078] This invention aims to provide a regulatory method and system that supports dynamic hot updating and efficient matching of rules. The system adopts a layered and modular design, with each layer working together to complete a closed loop from rule definition to result output.

[0079] The first aspect of this invention provides a detailed description of a regulatory system that supports dynamic hot updating and efficient matching of rules.

[0080] Please see Figure 1 The system mainly includes a rule definition and management layer, an incremental compilation and hot deployment layer, a dynamic rule network runtime layer, and an action execution and audit feedback layer; specifically:

[0081] The rule definition and management layer provides a visual interface for regulators. Regulators can use this interface to define new regulatory rules based on a structured format using a specific JSON template, conduct simulation tests on the rules, submit them for review, and manage the entire lifecycle status of the rules, including draft, pending review, activated, and deactivated. The rule definition and management layer then distributes approved rule definitions to the next level for processing.

[0082] The incremental compilation and hot deployment layer is the core hub for dynamic updates. It receives approved new rule definitions and parses them into an intermediate representation. Then, its internal differential analysis engine identifies the differences between the new rule and the rule set currently running online. Based on this difference analysis, the incremental compilation and hot deployment layer generates independently loadable rule execution modules (rule logic execution packages) only for the differing parts, and simultaneously generates the corresponding network routing change instruction set. This on-demand compilation method avoids the huge overhead of full compilation.

[0083] The dynamic rule network runtime layer is the core engine of the system, consisting of three core sublayers: a fact preprocessing and distribution layer, a shared condition calculation and indexing layer, and a central routing and rule execution layer; among which:

[0084] The fact preprocessing and distribution layer is responsible for receiving raw medical events from the message queue, such as "prescription issuance" and "settlement application" events. This layer transforms this raw data into standardized fact objects that are unified within the system. During the transformation process, this layer extracts a set of feature keys for fast retrieval; for example, it extracts feature keys such as "drug code: D001" and "diagnosis code: B002" from a prescription event.

[0085] The shared condition computation and indexing layer consists of a series of atomic condition computation units. Each computation unit is responsible for performing a specific type of atomic condition judgment, such as "determining whether the 'drug code' field value of the input fact object is equal to the preset value 'A001'". Crucially, each atomic condition computation unit internally contains a hash inverted index table. This index table is an in-memory hash key-value pair mapping. Its "keys" are all possible specific values ​​that the computation unit is interested in; for example, for the drug code condition, the keys might be "A001", "A002", etc. Its "values" are a set of rule identifiers, recording all rule IDs that reference this condition in their rule logic and are currently active. When a fact object flows through this unit, the system first obtains a preliminary set of rule candidates by querying this hash inverted index table, rather than immediately performing a precise condition judgment.

[0086] The central routing and rule execution layer is controlled by a central dynamic routing table. This table records the current valid mappings from all shared condition calculation units to rule logic execution packages. Based on this routing table and the rule candidate set pre-filtered by the shared condition calculation and indexing layer, the system precisely routes fact objects to one or more corresponding rule logic execution packages, which then complete the final logical combination judgment and action triggering.

[0087] The action execution and audit feedback layer is responsible for executing the specific actions generated after rule matching, such as issuing real-time alerts to the doctor's workstation, intercepting current violations, and recording violations in the log database. Simultaneously, this layer integrates the entire matching process, matching results, and event-related contextual information to generate tamper-proof audit traceability records to meet the compliance requirements of medical supervision.

[0088] In this scheme, the built-in hash inverted index of the shared condition computation unit is a modification of the Alpha network in the traditional Rete algorithm. Each unit is constructed as an independent object in memory, containing two core elements:

[0089] Firstly, the conditional judgment logic encapsulates a basic, stateless Boolean judgment function. For example, a function that determines whether the value of the drug code field of the input fact object is equal to the preset specific value "A001" inside the unit.

[0090] Secondly, the hash inverted index table is a key data structure in this invention for improving matching efficiency. This table is an in-memory hash key-value pair mapping. In a specific embodiment, for the calculation unit responsible for determining the drug code field, its hash inverted index table may contain the following mappings:

[0091] Key “A001”: Maps to the rule ID set {R1, R5, R9}

[0092] Key “A002”: Maps to the rule ID set {R2, R9}

[0093] Key “A003”: Maps to the rule ID set {R7}

[0094] This mapping suggests that any factual event with a drug code of "A001" may be related to rules R1, R5, and R9, which requires further verification.

[0095] In a specific application scenario, for complex conditions such as "drug A and diagnosis B" which consist of multiple atomic conditions connected by a logical "AND", this invention provides two indexing processing modes to achieve performance optimization:

[0096] The first type is the composite key index mode. The system supports creating dedicated composite condition calculation units. The index key of this unit is an ordered combination of multiple field values, such as ('A001', 'B001') represented as a tuple, whose value is a set of rule IDs that directly depend on this specific combination. This mode is suitable for frequently occurring fixed combination conditions, enabling a single index query to directly reach the target rule, resulting in the highest matching efficiency.

[0097] The second approach is the multi-index result intersection calculation mode. When processing events, the system queries the hash inverted indexes of the drug coding unit and the diagnostic coding unit respectively, obtaining two candidate sets of rule IDs. Then, it performs an efficient intersection operation on these sets in memory. The result is the candidate set of rules that simultaneously satisfy both atomic conditions. This mode eliminates the need to pre-build indexes for all possible combinations, saving memory and flexibly supporting rules with arbitrary field combinations.

[0098] The system can intelligently select or combine the above modes based on the complexity, popularity, and business characteristics of the rules to achieve the optimal balance between resource utilization and matching performance.

[0099] In this scheme, the central dynamic routing table is the control center of the entire dynamic rule network and the core of enabling hot-swappable rules. It is a global data structure maintained in memory, essentially a mapping table. Each record in the table represents a valid data flow path and contains at least the following three core fields:

[0100] Source address: An exit identifier that points to a specific shared conditional computing unit.

[0101] Target address: An entry identifier that points to a specific rule logic execution package.

[0102] Routing status: A boolean flag indicating whether this path is currently open or closed.

[0103] The central dynamic routing table simplifies the process of connecting rules to the network from modifying complex pointer links to simply inserting or updating a record with a routing status into this table.

[0104] In this scheme, the rule logic execution package is an independent execution container corresponding to a single complete rule, thus decoupling the rule logic from the physical network. Each rule logic execution package contains the following four elements:

[0105] Rule identity and status: Stores a globally unique rule ID, a semantic version number, and lifecycle status identifiers such as "ready", "activated", "pending retirement", and "historical".

[0106] Internal logic graph of a rule: A memory structure that describes the logical relationships between multiple conditions within the rule, usually represented as a directed acyclic graph. It defines the complete internal flow from receiving a precondition signal to triggering the final action.

[0107] Private action executor: Encapsulates all the specific operations that need to be performed when the rule is fully matched, such as formatting an alarm message, calling an external medical insurance verification interface, or writing a violation record to the database.

[0108] Runtime context: Used to temporarily store intermediate calculation results and states during a matching session, such as recording whether a sub-condition has been met.

[0109] In a second aspect, the present invention provides a detailed description of a regulatory method that supports dynamic hot updating and efficient matching of rules.

[0110] This method mainly includes the following steps:

[0111] Step S100: Construct the rule runtime network; the rule runtime network includes multiple shared condition calculation units, multiple rule logic execution packages, and a central dynamic routing table.

[0112] Step S200: When a rule update instruction is received, perform the following hot update steps:

[0113] Parse the rule update instructions and generate or modify the corresponding target rule logic execution package.

[0114] Initiate an atomic transaction to the central dynamic routing table. In the atomic transaction, update the routing status of all dynamic routes related to the target rule logic execution package to be on, and update the status of the target rule logic execution package to be active. After the atomic transaction is committed, the new or modified rule takes effect immediately.

[0115] Step S300: When a pending event is received, perform the following efficient matching steps:

[0116] Extract the feature keys from the event to be processed.

[0117] For each feature key, locate the relevant shared condition calculation unit, query its built-in hash inverted index table, and obtain the first rule candidate set corresponding to the feature key.

[0118] Perform logical operations on all candidate sets of the first rule to obtain candidate sets of the second rule.

[0119] Based on the central dynamic routing table, the events to be processed are routed in parallel to each rule logic execution package in the second rule candidate set.

[0120] Inside the rule logic execution package, the encapsulated rule logic graph is executed to perform final matching verification of the events to be processed, and the corresponding action executor is triggered when the matching is successful.

[0121] Please see Figure 2 Taking the addition of a new regulatory rule R as an example, this article details the complete process of dynamic hot-launch of a rule.

[0122] Step 201: Compilation and Preparation.

[0123] The incremental compilation layer parses the newly added rule R, generates the corresponding rule logic execution package RLP-R, and sets its initial state to "ready". However, at this time, the execution package is not connected to the running network. At the same time, the compiler analyzes that rule R depends on two atomic conditions: C1 (drug code equals X) and C2 (diagnosis code equals Y).

[0124] Step S202: Atomic route injection and state switching.

[0125] The system initiates an atomic transaction to the central dynamic routing table. Within this transaction, the following actions are executed in an indivisible order:

[0126] First, insert two new records into the central dynamic routing table:

[0127] Record A: The source address is set to the calculation unit responsible for condition C1, the destination address is set to "RLP-R", and the routing status is set to "connected".

[0128] Record B: The source address is set to the calculation unit responsible for condition C2, the destination address is set to "RLP-R", and the routing status is set to "connected".

[0129] Secondly, the internal state of the rule logic execution package RLP-R is updated from "ready" to "activated".

[0130] This atomic transaction ensures consistency through a memory transaction protocol based on atomic version switching. Specifically, the protocol divides the update process into two logical phases: the first phase is isolation preparation, where a protected update thread creates a new version snapshot containing the newly added "connected" route records based on the currently effective route snapshot, and simultaneously updates the target rule logic execution packet RLP-R's state to "active." The second phase is atomic publishing, where, at the instant the transaction is committed, an indivisible atomic operation is performed, switching the global current route snapshot reference from pointing to the old version snapshot to pointing to the newly prepared version snapshot. The moment this atomic switch is completed is the moment the transaction is successfully committed and the new state takes effect. For all concurrent business matching threads, before the switch, they always see the old snapshot without the new routes, and RLP-R is still considered "inactive"; after the switch, they immediately see the complete new snapshot containing all the new routes, and the RLP-R's state is now "active." This design fundamentally eliminates the possibility of business threads observing intermediate states, because the visibility of the route snapshot and the executable state of the rule packet are synchronously activated through the same atomic operation. The central dynamic routing table is updated the moment the submission is completed. Afterward, any medical event data flowing through condition C1 or C2 computing units will be automatically routed to RLP-R for processing via the newly created "connection" route.

[0131] Step S203: Asynchronous index construction.

[0132] After successful route injection, a low-priority background thread is triggered to update the hash inverted index table in the relevant shared condition calculation unit. For example, in the unit responsible for condition C1, the ID of rule R is added to the set of rule IDs with key "X". The brief delay in this step does not affect the correctness of data routing, as the correctness of the routing is guaranteed by the central routing table; the index is only used for performance optimization.

[0133] Please see Figure 3 Taking a medical event containing "drug code equals X, diagnosis code equals Y" as an example, this paper details the complete process of efficient matching.

[0134] Step S301, fact standardization and feature extraction.

[0135] The data access layer converts raw events into standard fact objects and extracts key feature pairs, such as [(drug code, X), (diagnosis code, Y)].

[0136] Step S302, Level 1: Index pre-filtering.

[0137] The matching scheduler does not broadcast across the entire network, but instead performs the following operations for each feature pair:

[0138] Taking (drug code, X) as an example, the system locates all shared computational units responsible for determining drug code conditions. Then, it directly reads the hash inverted index tables within these units, querying the key "X". Assuming the query result is that the index of unit U1 points to the rule set {R, A} associated with value X, and the index of unit U2 points to the rule set {B} associated with value X, the system initially infers that the current event can only be related to rules R and A. By taking the intersection of the index query results for all feature pairs (for example, if the query result for another feature pair (diagnosis code, Y) is the rule set {R, C}, then the intersection operation yields the rule set {R}), the system can reduce the range of rules requiring deep processing from tens of thousands to just a few or even a single rule within microseconds, obtaining a second set of candidate rules.

[0139] Step S303, Level 2: Precise routing and concurrent execution.

[0140] The system pushes fact objects in parallel to all target rule execution packages (e.g., RLP-R) selected in the previous step, based on a central dynamic routing table. The system maintains a lightweight thread pool or coroutine scheduler to implement parallel triggering and resource management. For matching a single fact object, the system generates an independent execution task for each candidate rule execution package in the second rule candidate set. These tasks are submitted to the thread pool and executed in parallel, isolated from each other, sharing a read-only copy of the same fact object. The system uses task queues and load balancing mechanisms to ensure that parallel tasks do not excessively consume system resources, achieving a balance between high overall throughput and low latency for individual events.

[0141] Within each rule execution package (such as RLP-R), the system executes its encapsulated complete rule logic graph to perform final verification of the conditions. Due to the precise pre-screening at the first level, this verification step has an extremely high pass rate, effectively avoiding invalid calculations.

[0142] Step S304: Output and aggregation of results.

[0143] After all parallel rule packages have been processed, the system aggregates the action results generated by each rule package, such as alarms, interception commands, and logs. The action executor performs the final operation based on the aggregation result. For example, if multiple rules trigger alarms, they are merged into a single comprehensive alarm and sent to the supervisor. The audit module also records a complete audit log containing the matching trajectories of all candidate rules.

[0144] Step S305: Optimize the matching result caching.

[0145] This step is optional. For identical or highly similar facts that recur repeatedly within a short period, the system provides an optional high-performance caching layer to further improve throughput. The cache key is composed of the hash value of the key feature key of the fact object and the version number of the current central dynamic routing table, ensuring that the cache is only hit when the fact features and rule environment remain unchanged. The cache content stores the final matching result corresponding to this feature combination, such as the list of triggered rule IDs and actions. When a rule goes online or offline and a dynamic update causes the routing table version number to increment, or when a significant change in the fact feature pattern is detected, the relevant cache segments will be automatically and batch invalidated. This mechanism ensures strong consistency between cached results and dynamic rules, enjoying caching performance without affecting matching accuracy.

[0146] The further proposed solution also includes step S400 and the rule-based smoothing offline step:

[0147] Step S401: Atomized route cut-off.

[0148] The system initiates an atomic transaction that modifies the routing status field of all records in the central dynamic routing table with destination addresses of RLP-R to "disconnected". After the transaction is committed, any new incoming data flows are immediately blocked and will no longer be routed into RLP-R.

[0149] Step S402: Status flags and in-transit requests are cleared.

[0150] After an atomic route is disconnected, the system immediately updates the RLP-R state from "Active" to "Pending Retirement." This state is a critical control signal. For the central routing table and the matching scheduler, the "Pending Retirement" state is a clear indication of unroutable behavior. The system ensures that no new fact objects will be assigned or routed to rule packets in this state, thus fundamentally preventing the inflow of new requests. Simultaneously, RLP-R maintains the operation of its internal logic execution engine. For in-transit matching sessions that entered RLP-R before the state switch and are being executed within its internal logic graph, RLP-R will continue to provide normal computation services until each session naturally reaches its final state, such as triggering an action or determining a mismatch. This is crucial for achieving business continuity and result integrity, ensuring that no processing requests are forcibly interrupted, leading to data inconsistency or lost actions. A separate lifecycle monitoring thread continuously scans all rule packets in the "Pending Retirement" state, checking an active session counter within RLP-R (which increments at the start of a session and decrements at the end) to determine if it is "empty."

[0151] Step S403, Resource reclamation and index cleanup.

[0152] The monitoring thread will only trigger the subsequent resource reclamation process to safely release all memory resources occupied by RLP-R when the active session counter of a certain rule package remains at zero, indicating that all in-transit requests have been processed. Subsequently, a background task is triggered asynchronously to delete the ID of rule R from the hash inverted index of the relevant shared condition calculation unit, completing the entire offline process.

[0153] The following example, using a local medical insurance bureau's implementation of an intelligent monitoring system to prevent off-label drug use, illustrates the working process of this invention:

[0154] First, the National Healthcare Security Administration issued new regulations requiring the monitoring of the practice of "using drug M for non-indication D". Supervisors configure this new rule and submit it for review by selecting fields and setting conditions (drug code equals M, diagnosis code not equals D) on a visualization platform.

[0155] Next, the incremental compiler completes rule parsing within seconds, generating the corresponding rule logic execution package RLP-M. Subsequently, the system executes an atomic route injection transaction: creating a routing path from the two shared condition calculation units "drug code equals M" and "diagnosis code not equals D" to RLP-M in the central routing table, and atomically switching the state of RLP-M to "active". Thus, the provincial medical insurance settlement system, without any awareness or business interruption, acquires real-time monitoring capabilities for this new rule within 100 milliseconds.

[0156] When a doctor in a hospital attempts to prescribe medication M for a patient whose diagnosis code is not D, the settlement event is sent to the engine via a message queue. At the shared condition calculation and indexing layer, the event's feature key "medication code = M" matches the hash inverted index of the corresponding calculation unit, instantly generating a candidate set containing rule M; simultaneously, the feature key "diagnosis code ≠ D" also matches its index. Through logical operations on these two candidate sets, the system locks the range of rules to be processed into RLP-M within microseconds. Subsequently, through the central routing table, the event is precisely routed to RLP-M. Within RLP-M, after complete rule logic graph verification, the behavior is confirmed to be illegal, triggering a real-time interception action and simultaneously sending violation warnings to both the hospital and regulatory authorities. The entire processing time is less than 10 milliseconds.

[0157] Furthermore, after running for a period of time, the Medical Insurance Bureau discovered that the rules needed to add a restriction condition of "patients being over 65 years old." The administrator modified the rules online. The system completed the hot update using a process of "atomically deploying a new RLP-Mv2 packet containing the new condition - disconnecting the old packet's RLP-M route through a routing state switch - asynchronously reclaiming its resources after all in-transit sessions in the old packet's RLP-M are cleared." Throughout the entire optimization process, online monitoring services were never interrupted, and all historical work orders being processed in RLP-M remained unaffected, ensuring a smooth transition of services.

[0158] Figure 3 This invention demonstrates a two-stage pipeline architecture employing index pre-filtering and precise routing execution. Figure 4 The traditional scheme employs a broadcast-style traversal matching mechanism. As can be seen in the comparison, the traditional scheme consumes computational resources evenly across all rules and conditions, while the present invention uses a hash inverted index for pre-selection, focusing valuable computational resources only on the very few rules that are truly likely to match. This shift reduces the computational complexity of the matching process from being related to the total number of rules to being related to the number of candidate rules, achieving an order-of-magnitude improvement in matching efficiency. Simultaneously, the introduction of a central dynamic routing table simplifies rule hot-swapping from network reconstruction to route configuration, fundamentally solving the inherent problem of traditional schemes requiring downtime for updates.

[0159] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A regulatory method supporting dynamic hot updating and efficient matching of rules, characterized in that, include: A rule runtime network is constructed; the rule runtime network includes multiple shared condition calculation units, multiple rule logic execution packages, and a central dynamic routing table. When a rule update instruction is received, the following hot update steps are performed: Parse the rule update instruction to generate or modify the corresponding target rule logic execution package; An atomic transaction is initiated to the central dynamic routing table. In the atomic transaction, the routing status of all dynamic routes related to the target rule logic execution package is updated to be on, and the status of the target rule logic execution package is updated to be active. After the atomic transaction is committed, the new rule or the modified rule takes effect immediately. When a pending event is received, the following efficient matching steps are performed: Extract the feature keys from the event to be processed; For each feature key, locate the relevant shared condition calculation unit, query its built-in hash inverted index table, and obtain the first rule candidate set corresponding to the feature key; Perform logical operations on all first rule candidate sets to obtain second rule candidate sets; According to the central dynamic routing table, the events to be processed are routed in parallel to each rule logic execution package in the second rule candidate set; Within the rule logic execution package, the encapsulated rule logic graph is executed to perform final matching verification on the event to be processed, and the corresponding action executor is triggered when the matching is successful.

2. The regulatory method supporting dynamic hot updating and efficient matching of rules according to claim 1, characterized in that: Each of the shared condition calculation units encapsulates an atomic condition judgment logic and has a built-in hash inverted index table. The hash inverted index table uses the possible values ​​that the atomic condition judgment logic is interested in as keys and the set of rule identifiers as values. Each rule logic execution package encapsulates a complete regulatory rule's logic diagram and its corresponding action executor; The central dynamic routing table maintains multiple dynamic routes from the shared condition calculation unit to the rule logic execution packet, and each route has a routing state that identifies whether the route is currently valid.

3. The regulatory method supporting dynamic hot updating and efficient matching of rules according to claim 1, characterized in that, The atomic transactions are implemented using an atomic version switching protocol; The atomic version switching protocol includes: In the transaction context, a new version snapshot containing the newly added routing record is created based on the currently effective routing snapshot, and the status of the target rule logic execution package is updated to active. When a transaction is committed, an atomic operation is performed to atomically switch the global current route snapshot reference from pointing to the old version snapshot to pointing to the new version snapshot, so that the activation status of the newly added routing record and the target rule logic execution package takes effect on all concurrent business threads at the same time.

4. The regulatory method supporting dynamic hot updating and efficient matching of rules according to claim 1, characterized in that, The hot update step also includes: After the atomic transaction is committed, the hash inverted index table in the shared condition calculation unit associated with the target rule logic execution package is updated asynchronously.

5. The regulatory method supporting dynamic hot updating and efficient matching of rules according to claim 1, characterized in that, The shared condition calculation unit includes a single-field hash inverted index unit for a single field and a composite condition calculation unit for a combination of multiple fields; wherein, the index key of the composite condition calculation unit is an ordered combination of multiple field values, and its value is a set of rule identifiers that directly depend on the specific combination.

6. The regulatory method supporting dynamic hot updating and efficient matching of rules according to claim 5, characterized in that, The step of performing logical operations on all the first rule candidate sets to obtain the second rule candidate set specifically includes: When the rule of the event to be processed involves multiple atomic conditions connected by a logical AND, the intersection operation is performed on the first rule candidate set obtained from multiple single-field hash inverted index units to obtain the second rule candidate set; or, When the feature key of the event to be processed matches the index key of the composite condition calculation unit, the query result is directly used as the second rule candidate set.

7. The regulatory method supporting dynamic hot updating and efficient matching of rules according to claim 1, characterized in that, The step of routing the events to be processed in parallel to each rule logic execution package in the second rule candidate set specifically includes: Maintain a thread pool or coroutine scheduler; Generate an independent execution task for each candidate rule logic execution package in the second rule candidate set; The execution task is submitted to the thread pool or coroutine scheduler to process multiple candidate rule logic execution packages in parallel.

8. The regulatory method supporting dynamic hot updating and efficient matching of rules according to claim 1, characterized in that, The efficient matching step also includes: Before matching, a cache key is generated based on the hash value of the feature key of the event to be processed and the version number of the current central dynamic routing table, and the matching result cache is queried. If the cache is hit, the corresponding matching result is directly retrieved and executed, skipping the subsequent matching process; If the cache is not hit, the subsequent matching steps are executed, and the matching result is stored in the matching result cache.

9. The regulatory method supporting dynamic hot updating and efficient matching of rules according to claim 8, characterized in that, When the version number of the central dynamic routing table increases due to rule updates, the cached matching results are automatically invalidated.

10. The regulatory method supporting dynamic hot updating and efficient matching of rules according to claim 1, characterized in that, It also includes the rule-based smoothing offline step: In response to the rule offline instruction, an atomic transaction is initiated to change the routing status of all routes pointing to the target rule logic execution packet in the central dynamic routing table to disconnect; Update the status of the target rule logic execution package to a pending retirement status; Monitor the number of active sessions within the target rule logic execution package. When the number of active sessions is zero, reclaim the resources occupied by the target rule logic execution package.

11. The regulatory method supporting dynamic hot updating and efficient matching of rules according to claim 10, characterized in that, The rule logic execution package in the pending retirement state refuses to accept any new fact objects, but continues to provide full computation services for in-transit matching sessions that have entered its internal logic graph until all sessions end.

12. An intelligent monitoring system supporting dynamic hot updating and efficient matching of rules, characterized in that, include: The rule definition and management layer is configured to provide a rule definition interface to receive and manage regulatory rules. The incremental compilation and hot deployment layer is configured to parse approved rules, generate corresponding rule logic execution packages, and generate route change instructions. The dynamic rule network runtime layer includes a fact preprocessing and distribution layer, a shared condition calculation and indexing layer, and a central routing and rule enforcement layer, wherein: The fact preprocessing and distribution layer is configured to receive raw medical events and convert them into standard fact objects, extracting feature keys; The shared condition calculation and indexing layer includes multiple shared condition calculation units, which are configured to receive the feature key and output a first rule candidate set by querying their built-in hash inverted index table; The central routing and rule execution layer includes a central dynamic routing table and multiple rule logic execution packages. It is configured to route the standard fact object to the candidate rule logic execution package determined by the first rule candidate set according to the central dynamic routing table, and perform final matching verification. The action execution and audit feedback layer is configured to execute actions generated after a successful match and record the entire matching process and results.

13. The intelligent monitoring system supporting dynamic hot updating and efficient matching of rules according to claim 12, characterized in that, The incremental compilation and hot deployment layer includes a differential analysis engine, which is used to identify the differences between the new rules and the existing rules, and generate the rule logic execution package and the route change instruction only for the differences.

14. The intelligent monitoring system supporting dynamic hot updating and efficient matching of rules according to claim 12, characterized in that, The shared condition calculation unit in the shared condition calculation and index layer also includes a condition judgment logic module, which is used to perform precise judgment of atomic conditions when performing final matching verification within the rule logic execution package.

15. The intelligent monitoring system supporting dynamic hot updating and efficient matching of rules according to claim 12, characterized in that, Each record in the central dynamic routing table includes at least: The source address points to a specific shared conditional computation unit; The target address points to a specific rule logic execution package; As a boolean flag for routing status.

16. The intelligent monitoring system supporting dynamic hot updating and efficient matching of rules according to any one of claims 12-15, characterized in that: The system is applied to scenarios such as internet-based medical consultation supervision, medical insurance settlement supervision, or prescription review. The original medical event includes at least one of the following: prescription issuance event and settlement application event; The feature key includes at least one of drug code, diagnosis code, and treatment item code.

Images