A medical data governance rule configuration method and device

Abstract

The application discloses a medical data governance rule configuration method and device, relates to the field of medical data governance, and comprises the following steps: establishing a standardized data element set containing a business meaning identifier, presetting a standardized data element set containing a national health information standard data element identifier, forming a standardized data element level rule mapping library, establishing a dynamic ternary binding relationship, forming a ternary binding model of a physical field, a business data element and a check rule, constructing a scene-based rule inheritance tree, implementing differentiated rule rewriting, and generating a runtime rule set. The device comprises a data element management module, a ternary mapping engine, a scene tree manager, a differentiated configuration editor and a rule compiling module. The application can improve the configuration efficiency in medical data governance through metadata mediation, realize unified modification, and complete the rapid autonomous update of a database.

Description

Technical Field

[0001] This invention belongs to the field of medical data governance technology, specifically relating to a method and apparatus for configuring medical data governance rules. Background Technology

[0002] With the increasing depth of medical big data applications, medical institutions face data governance needs characterized by multiple sources, multiple standards, and multiple scenarios. Although existing data quality management tools have basic rule configuration functions, the following technical bottlenecks and business pain points still exist in the actual implementation of large-scale medical projects: 1. Traditional data governance tools typically bind validation rules directly to the physical database table structure (schema). For example, configuring "ID card format validation" on the ID_NO field of the "Outpatient Registration Table". In healthcare systems, core business data is highly redundant. For instance, the data element "patient ID number" may be scattered across dozens of business tables in the HIS (Hospital Information System), and even synchronized to corresponding tables in the CDR (Clinical Data Center) and ODR (Operations Data Center). When it is necessary to adjust the ID card validation rules (e.g., to be compatible with the new version of the foreigner's residence permit), operations and maintenance personnel must manually identify all physical tables containing this field and modify the configuration one by one. This point-to-point hard-coding mode is not only extremely labor-intensive, but also prone to inconsistencies in data standards between systems due to missed modifications, making it impossible to achieve agile governance where a change in one place takes effect globally. 2. Existing technologies are mostly based on static data model inheritance (e.g., cardiology patients inherit general patient attributes), lacking the ability to inherit and differentiate management for regulatory / business scenarios. The common practice is to copy the entire rule base separately for each new scenario (e.g., reporting to the National Health Commission or provincial medical insurance bureaus). This leads to redundant construction of general rules: 90% of basic rules (e.g., gender dictionary codes must conform to national standards) are the same in all scenarios, but under the current model, they are physically copied multiple times, resulting in wasted resources. Different scenarios often have logically conflicting requirements for the same field. For example, the "admission diagnosis code" field requires accuracy to two decimal places in clinical quality control scenarios; however, in medical insurance settlement scenarios, it may only require accuracy to the broad category. Existing technologies struggle to elegantly handle such threshold rewriting requirements with different names while reusing the same set of rule codes. 3. Rule base construction is often top-down, with the IT department configuring it all at once. Healthcare operations change rapidly, and frontline departments or specific research projects often generate highly valuable private rule data (e.g., specific logic checks for rare diseases). Existing systems lack a mechanism to elevate these high-value rules scattered across peripheral scenarios into hospital-wide universal rules. This prevents valuable governance experience from being transformed into organizational-level data assets, leaving the rule base stagnant and unable to evolve with business development.

[0003] In summary, existing technologies cannot achieve global synchronization and application of changes made in one place using a single set of rule codes, nor can they synchronize these scattered changes to the data rule base. This prevents the rapid configuration of data rules, and therefore, improvements are necessary. Summary of the Invention

[0004] To address the shortcomings of the aforementioned existing technologies, this invention provides a method and apparatus for configuring medical data governance rules, which can improve the configuration efficiency in medical data governance through metadata mediation, achieve unified changes, and complete rapid autonomous updates of the database.

[0005] In order to achieve the objective of this invention, the following solution is proposed: A method for configuring medical data governance rules includes the following steps: S1. Construct a standardized data element set containing business meaning identifiers, and pre-set a standardized data element set containing national health information standard data element identifiers. Each data element in the standardized data element set is pre-bound with atomic verification rules that conform to national standards, forming a standardized data element-level rule mapping library. S2. Establish dynamic ternary binding relationship: Map fields in the physical data model to business data elements, and automatically attach atomic verification rules to fields in the physical data model based on this mapping relationship, forming a ternary binding model of "physical field-business data element-verification rule"; S3. Construct a scenario-based rule inheritance tree: Create a root scenario node and multiple child scenario nodes to construct a scenario tree with a parent-child hierarchical relationship. Child scenario nodes automatically inherit the rule set associated with the parent scenario node through logical reference pointers. S4. Implement differentiated rule rewriting: In the sub-scene node, create a differentiated configuration mask for specific rules inherited from the parent scene. The differentiated configuration mask includes modification of rule thresholds, adjustment of rule execution strength, and masking of rules. S5. Generate runtime rule set: In response to the configuration request for the target scenario, traverse the scenario tree, aggregate parent rules based on logical reference pointers, and overlay the differentiated configuration mask of the current scenario to parse and generate the final execution rule set for the target scenario.

[0006] Furthermore, the ternary binding relationship in S2 has change propagation characteristics. When the atomic verification rules associated with a business data element change, the ternary binding model automatically retrieves all physical fields mapped to that business data element and updates the verification logic of all affected physical fields in real time.

[0007] Furthermore, the rewriting of the differentiation rules into common rules in S4 includes the following steps: S41. Private rule definition: Allows defining private extended rules in the sub-scenes of leaf nodes that are only visible to the current scene; S42, Rule Promotion: Receives a promotion instruction for a private extended rule, removes the private extended rule from the leaf node, and migrates and registers it to the root scene node or the parent scene node. S43, Global Effect: Once a rule is promoted, the private extended rule is automatically inherited by other sibling sub-scenes through logical reference pointers and becomes a public rule.

[0008] Furthermore, the differential configuration mask in S4 includes: Parameter rewrite mask: Keep the rule verification algorithm unchanged, but load threshold parameters different from those in the parent scene in the sub-scene; Intensity adjustment mask: Degrades a "blocking" error defined in the parent scene to a "hint" warning in the child scene, or vice versa; Logical masking: Marks a specific rule ID as invalid in a sub-scene, causing the rule to be skipped in the current sub-scene and its descendant scenes.

[0009] Furthermore, S5 generates runtime rule sets using an "overlay compilation" algorithm, which includes the following steps: S51, Loading Request: The user initiates a data governance task for the "Pediatric Outpatient Clinic" scenario; S52, Path Backtracking: Traverse the scene tree upwards from the "Pediatrics Clinic" node until the root node; S53, Rule Aggregation.

[0010] Furthermore, S53 includes the following steps: S531. Initialize the final rule configuration set; S532, Load Root: Put all rules of the root scenario into the final rule configuration set; S533, Overlay Parent: Traverse the "Outpatient Parent Scenario". If there are new rules, add them to the final rule configuration set; if there is a mask, update the parameters of the corresponding rule in the final rule configuration set. S534, Overlay: Traverse the “Pediatric Outpatient Clinic Sub-Scenario” and apply its defined mask; S535, Generate Snapshot: Output the final set of rule configurations to the validation engine for execution.

[0011] Furthermore, the execution rule set that is finally generated in the target scenario in S5 adopts the following priority strategy: if there is a differentiated configuration mask for a certain rule ID in the target scenario, the logic defined by the mask is executed first; if there is no mask, the process is to backtrack up the scenario tree to find the definition of the rule ID in the nearest parent scenario; if no differentiated definition is found after backtracking to the root scenario, the default atomic verification rule bound to the data element layer is executed.

[0012] A medical data governance rule configuration device, comprising: The data element management module is used to construct a standardized data element set containing business meaning identifiers. It pre-sets a standardized data element set containing national health information standard data element identifiers. Each data element in the standardized data element set is pre-bound with atomic verification rules that conform to national standards, forming a standardized data element-level rule mapping library. The ternary mapping engine is used to map fields in the physical data model to business data elements. Based on this mapping relationship, atomic verification rules are automatically and dynamically attached to the fields of the physical data model, forming a ternary binding model of "physical field - business data element - verification rule". Scene Tree Manager is used to build a scene-based rule inheritance tree: it creates a root scene node and multiple child scene nodes, constructs a scene tree with a parent-child hierarchical relationship, and the child scene nodes automatically inherit the rule set associated with the parent scene node through logical reference pointers; The differential configuration editor is used to implement differential rule rewriting: In the child scene node, a differential configuration mask is created for specific rules inherited from the parent scene. The differential configuration mask includes modification of rule thresholds, adjustment of rule execution strength, and masking of rules. The rule compilation module is used to respond to configuration requests for a target scenario, traverse the scenario tree, aggregate parent rules based on logical reference pointers, overlay the differential configuration mask of the current scenario, and parse to generate the final set of execution rules for the target scenario.

[0013] The beneficial effects of this invention are as follows: Under the premise of the same code, by establishing a dynamic ternary binding relationship and forming a data rule inheritance tree, when a modification occurs in one place, unified changes are made to all parts of the database. Then, by re-evaluating the differentiated rules, in response to configuration requests for the target scenario, the scenario tree is traversed to complete agile changes that take effect globally, thereby improving the configuration efficiency in medical data governance and enabling rapid and autonomous updates to the database. Attached Figure Description

[0014] Figure 1This is a flowchart illustrating the medical data governance rule configuration method according to an embodiment of this application.

[0015] Figure 2 This is a flowchart illustrating the implementation of differentiated rule rewriting in the embodiments of this application.

[0016] Figure 3 A flowchart for generating runtime rule sets for embodiments of this application.

[0017] Figure 4 This is a flowchart illustrating rule aggregation for embodiments of this application.

[0018] Figure 5 This is a structural block diagram of a medical data governance rule configuration device according to an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the implementation methods of the present invention will be described in detail below with reference to the accompanying drawings. However, the embodiments described in this invention are only some embodiments of the present invention, and not all embodiments.

[0020] One aspect of this application provides a method for configuring medical data governance rules, such as... Figures 1-4 As shown, the steps include: S1. Construct a standardized data element set containing business meaning identifiers, and pre-set a standardized data element set containing national health information standard data element identifiers. Each data element in the standardized data element set is pre-bound with atomic verification rules that conform to national standards, forming a standardized data element-level rule mapping library. S2. Establish dynamic ternary binding relationship: Map fields in the physical data model to business data elements. Based on this mapping relationship, dynamically attach atomic verification rules to fields in the physical data model to form a ternary binding model of "physical field - business data element - verification rule". S3. Construct a scenario-based rule inheritance tree: Create a root scenario node and multiple child scenario nodes to construct a scenario tree with a parent-child hierarchical relationship. Child scenario nodes automatically inherit the rule set associated with the parent scenario node through logical reference pointers. S4. Implement Differentiated Rule Rewriting: In the sub-scene node, for specific rules inherited from the parent scene, create a differentiated configuration mask. The differentiated configuration mask is not a traditional network IP mask, but a runtime rule overlay or configuration rewriting object applied in the object inheritance architecture. The differentiated configuration mask includes modification of rule thresholds, adjustment of rule execution strength, and rule masking, thereby achieving local polymorphism of the sub-scene verification logic without modifying the original rules of the parent scene. Furthermore, the differentiated configuration mask is not a physical tampering with the original rule code, but an independently stored incremental configuration description file. At runtime, the final execution logic is dynamically generated through the overlay operation of "basic rules + mask layer". S5. Generate runtime rule set: In response to the configuration request for the target scenario, traverse the scenario tree, aggregate parent rules based on logical reference pointers, and overlay the differentiated configuration mask of the current scenario to parse and generate the final execution rule set for the target scenario.

[0021] Specifically, the ternary binding relationship in S2 has change propagation characteristics. When the atomic verification rules associated with a business data element change, the ternary binding model automatically retrieves all physical fields mapped to the business data element and updates the verification logic of all affected physical fields in real time, without needing to modify the configuration for each physical field individually.

[0022] Specifically, such as Figure 2 As shown, S4 rewrites the differentiation rules into common rules, including the following steps: S41. Private rule definition: Allows defining private extended rules in the sub-scenes of leaf nodes that are only visible to the current scene; S42, Rule Promotion: Receives a promotion instruction for a private extended rule, removes the rule from the leaf node, and migrates and registers it to the root scene node or the parent scene node. S43, Global Effect: Once a rule is promoted, it is automatically inherited by other sibling sub-scenes through logical reference pointers and becomes a public rule.

[0023] Specifically, for differentiated configuration masks, in order to enable parameter rewriting, strength adjustment, and logic masking, a standard mask object model can be defined, using JSON as an example: json { "rule_yanma_bm": "MASK_001_PED", / / Unique identifier for the rule mask "rule_scenario_id": "SCN_PEDIATRICS", / / Bound sub-scenario: Pediatrics scenario "target_rule_id": "RULE_BP_01", / / Target rule ID: Blood pressure normal value validation "mask_type": "OVERRIDE", / / Mask type: OVERRIDE (overriding) / DISABLE (disabling) / SEVERITY (downgrading) "payload": { / / Payload data: specific modifications "operator": "BETWEEN", "params": { "min": 60, / / [Modification] Reduce the adult's 90 to 60 "max": 100 / / [Modification] Reduce the adult value from 140 to 100 }, "error_level": "WARNING" / / [Modification] Change the blocking level error message to a warning level error message. }, "priority": 10, / / Priority: handling conflicts in multiple inheritance "create_time": "2025-02-10" } Logical explanation: Non-destructive: The creation of the above mask will not affect the original definition (90-140) of RULE_BP_01 in the parent scene (such as "General Scene for the Entire Hospital").

[0024] Precise rule selection is possible: The rule to be modified can be precisely anchored by target_rule_id, and rules not matched by the mask can be directly inherited through the mask.

[0025] Specifically, the differential configuration mask in S4 includes: Parameter rewrite mask: Keep the rule verification algorithm unchanged, but load threshold parameters different from those in the parent scene in the sub-scene; Example: Scenario: Age verification rules; Parent scenario logic: Age >= 18 (adult department); Sub-scenario (Pediatrics) requirement: Age < 18; Processing logic: The system reads that there is a mask for this rule in the pediatric scenario, and directly extracts the params in the payload to replace the parameter context of the original rule; Technical advantages: No need to write two separate rule codes (check_adult_age and check_child_age), the same set of code logic check_age(min, max) can be reused, only the injected parameters are different at runtime.

[0026] Intensity adjustment mask: Downgrades "blocking" errors defined in the parent scene to "hint" warnings in the child scene, or vice versa, upgrades "hint" errors defined in the parent scene to "blocking" warnings in the child scene; Example: Scenario: "Medical record cover page integrity" rule; Parent scenario logic: Missing item causes "archiving failure"; Sub-scenario (Emergency Rescue) Requirements: Rescue is the priority; missing items will only trigger a "pop-up reminder," and saving the information first is allowed. Processing logic: The error_level field is modified by the mask, but the verification algorithm still executes. After an error is detected, the system decides whether to intercept the operation or only log it based on the level defined by the mask.

[0027] Logical masking: Marks a specific rule ID as invalid in a sub-scene, causing the rule to be skipped and executed in the current sub-scene and its descendant scenes; Example: Scenario: "ID card is required" rule; Parent scenario logic: ID_Card is NOT NULL; Sub-scenario (Neonatal Department) requirement: Newborns do not have ID cards and no verification is required; Processing logic: When the mask type is marked as DISABLE, the rule engine detects this mask while traversing the execution list and directly skips the execution of the rule. This is equivalent to dynamically commenting out this code at runtime.

[0028] Technical advantages: It avoids the need to write extremely complex general rule logic for a specific scenario in the traditional model (such as if (dept != 'newborn') then check...).

[0029] Specifically, such as Figure 3 As shown, S5 generates runtime rule sets using an "overlay compilation" algorithm, which includes the following steps: S51, Loading Request: The user initiates a data governance task for the "Pediatric Clinic" scenario; S52, Path Backtracking: The system traverses the scene tree upwards from the "Pediatric Clinic" node until the root node, obtaining the path: [Root Scene] -> [Clinic Parent Scene] -> [Pediatric Clinic Sub Scene]; S53, Rule Aggregation.

[0030] Specifically, such as Figure 4 As shown, S53 includes the following steps: S531. Initialize the final rule configuration set: Final_Rule_Map = {}; S532, Load Root: Put all rules of the root scenario into the final rule configuration set, i.e., Map; S533, Overlay Parent: Traverse the "Outpatient Parent Scenario". If there are new rules, add them to the final rule configuration set; if there is a mask, update the parameters of the corresponding rule in the final rule configuration set. S534, Overlay: Traverse the “Pediatric Outpatient Clinic Sub-Scenario” and apply its defined mask (such as blocking a rule or modifying a threshold). S535, Generate Snapshot: Output the final Final_Rule_Map to the verification engine for execution.

[0031] Specifically, the execution rule set that is finally effective in the target scenario is parsed and generated in S5, and the following priority strategy is adopted: if there is a differentiated configuration mask for a certain rule ID in the target scenario, the logic defined by the mask is executed first; if there is no mask, the scene tree is traced back up to find the definition of the rule ID in the nearest parent scene; if the differentiated definition is not found after tracing back to the root scene, the default atomic verification rule bound to the data element layer is executed.

[0032] Another aspect of this application provides a medical data governance rule configuration device, such as... Figure 5 As shown, it includes: a data element management module, a ternary mapping engine, a scene tree manager, a differential configuration editor, and a rule compilation module.

[0033] The data element management module is used to construct a standardized data element set containing business meaning identifiers, maintain the business data element definitions and their association with atomic verification rules, and pre-set a standardized data element set containing national health information standard data element identifiers. Each data element in the standardized data element set is pre-bound with atomic verification rules that conform to national standards, forming a standardized data element-level rule mapping library.

[0034] The ternary mapping engine stores and parses mapping tables from physical fields to business data elements, and is responsible for the automatic propagation of rule changes. It maps fields in the physical data model to business data elements. Based on this mapping relationship, the system automatically and dynamically attaches atomic validation rules to the fields of the physical data model, forming a ternary binding model of "physical field - business data element - validation rule". Specifically, the ternary mapping engine includes an intelligent recommendation unit. When configuring a new physical data model, it analyzes the name, data type, and sample data characteristics of the physical fields to automatically calculate their similarity to existing business data elements and recommends the most matching ternary binding relationship.

[0035] The Scene Tree Manager is used to build a visual scene topology, maintain the inheritance reference relationship between parent and child scenes, and build a scene-based rule inheritance tree: create a root scene node and multiple child scene nodes, build a scene tree with a parent-child hierarchical relationship, and the child scene nodes automatically inherit the rule set associated with the parent scene node through logical reference pointers.

[0036] The differential configuration editor provides a user interface to generate parameter rewriting, intensity adjustment, or masking masks for specific rules in sub-scenes, implementing differential rule rewriting: In a sub-scene node, a differential configuration mask is created for a specific rule inherited from the parent scene. This mask includes modifications to rule thresholds, adjustments to rule execution intensity, and rule masking. Specifically, the differential configuration editor includes a conflict detection unit. When a sub-scene attempts to rewrite a rigid rule marked as "forced inheritance and unmodifiable" by the parent scene, the conflict detection unit issues an intercept signal and prohibits the configuration operation.

[0037] The rule compilation module is used to calculate and output an independent rule configuration file for each scenario when the configuration takes effect, based on the scenario tree path, ternary binding relationship and differential mask, to generate a runtime rule set: In response to the configuration request for the target scenario, the system traverses the scenario tree, aggregates parent rules based on logical reference pointers, and overlays the differential configuration mask of the current scenario, and parses to generate the final execution rule set for the target scenario.

[0038] The above are merely preferred embodiments of the present invention and are not intended to be the only or limiting of the present invention. Those skilled in the art should understand that various changes or equivalent substitutions made to the present invention without departing from its scope are all within the protection scope of the present invention.

Claims

1. A method for configuring medical data governance rules, characterized in that, Including the following steps: S1. Construct a standardized data element set containing business meaning identifiers, and pre-set a standardized data element set containing national health information standard data element identifiers. Each data element in the standardized data element set is pre-bound with atomic verification rules that conform to national standards, forming a standardized data element-level rule mapping library. S2. Establish dynamic ternary binding relationship: Map fields in the physical data model to business data elements, and dynamically attach atomic verification rules to fields in the physical data model based on this mapping relationship to form a ternary binding model of "physical field-business data element-verification rule"; S3. Construct a scenario-based rule inheritance tree: Create a root scenario node and multiple child scenario nodes to construct a scenario tree with a parent-child hierarchical relationship. Child scenario nodes automatically inherit the rule set associated with the parent scenario node through logical reference pointers. S4. Implement differentiated rule rewriting: In the sub-scene node, create a differentiated configuration mask for specific rules inherited from the parent scene. The differentiated configuration mask includes modification of rule thresholds, adjustment of rule execution strength, and masking of rules. S5. Generate runtime rule set: In response to the configuration request for the target scenario, traverse the scenario tree, aggregate parent rules based on logical reference pointers, and overlay the differentiated configuration mask of the current scenario to parse and generate the final execution rule set for the target scenario.

2. The method for configuring medical data governance rules according to claim 1, characterized in that, The ternary binding relationship in S2 has change propagation characteristics. When the atomic verification rules associated with a business data element change, the ternary binding model automatically retrieves all physical fields mapped to that business data element and updates the verification logic of all affected physical fields in real time.

3. The method for configuring medical data governance rules according to claim 1, characterized in that, The steps involved in rewriting the differentiation rules into common rules in S4 are as follows: S41. Private rule definition: Allows defining private extended rules in the sub-scenes of leaf nodes that are only visible to the current scene; S42, Rule Promotion: Receive the promotion instruction for the private extended rule, remove the private extended rule from the leaf node, and migrate and register it to the root scene node or the parent scene node. S43, Global Effect: Once a rule is promoted, it is automatically inherited by other sibling sub-scenes through logical reference pointers and becomes a public rule.

4. The method for configuring medical data governance rules according to claim 1, characterized in that, The differential configuration mask in S4 includes: Parameter rewrite mask: Keep the rule verification algorithm unchanged, but load threshold parameters different from those in the parent scene in the sub-scene; Intensity adjustment mask: Degrades a "blocking" error defined in the parent scene to a "hint" warning in the child scene, or vice versa; Logical masking: Marks a specific rule ID as invalid in a sub-scene, causing the rule to be skipped in the current sub-scene and its descendant scenes.

5. The method for configuring medical data governance rules according to claim 1, characterized in that, S5 generates runtime rule sets using an "overlay compilation" algorithm, which includes the following steps: S51, Loading Request: The user initiates a data governance task for the "Pediatric Outpatient Clinic" scenario; S52, Path Backtracking: Traverse the scene tree upwards from the "Pediatrics Clinic" node until the root node; S53, Rule Aggregation.

6. The method for configuring medical data governance rules according to claim 5, characterized in that, S53 includes the following steps: S531. Initialize the final rule configuration set; S532, Load Root: Put all rules of the root scenario into the final rule configuration set; S533, Overlay Parent: Traverse the "Outpatient Parent Scenario". If there are new rules, add them to the final rule configuration set; if there is a mask, update the parameters of the corresponding rule in the final rule configuration set. S534, Overlay: Traverse the "Pediatric Outpatient Clinic" sub-scene and apply its defined mask; S535, Generate Snapshot: Output the final set of rule configurations to the validation engine for execution.

7. The method for configuring medical data governance rules according to claim 1, characterized in that, In S5, the execution rule set that is finally generated for the target scenario adopts the following priority strategy: if the target scenario has a differentiated configuration mask for a certain rule ID, the logic defined by the mask is executed first; if there is no mask, the scenario tree is traced back up to find the definition of the rule ID in the nearest parent scenario; if the differentiated definition is not found after tracing back to the root scenario, the default atomic verification rule bound to the data element layer is executed.

8. A medical data governance rule configuration device, characterized in that, include: The data element management module is used to construct a standardized data element set containing business meaning identifiers. It pre-sets a standardized data element set containing national health information standard data element identifiers. Each data element in the standardized data element set is pre-bound with atomic verification rules that conform to national standards, forming a standardized data element-level rule mapping library. The ternary mapping engine is used to map fields in the physical data model to business data elements. Based on this mapping relationship, atomic verification rules are automatically and dynamically attached to the fields of the physical data model, forming a ternary binding model of "physical field - business data element - verification rule". Scene Tree Manager is used to build a scene-based rule inheritance tree: it creates a root scene node and multiple child scene nodes, constructs a scene tree with a parent-child hierarchical relationship, and the child scene nodes automatically inherit the rule set associated with the parent scene node through logical reference pointers; The differential configuration editor is used to implement differential rule rewriting: In the child scene node, a differential configuration mask is created for specific rules inherited from the parent scene. The differential configuration mask includes modification of rule thresholds, adjustment of rule execution strength, and masking of rules. The rule compilation module is used to respond to configuration requests for a target scenario, traverse the scenario tree, aggregate parent rules based on logical reference pointers, overlay the differential configuration mask of the current scenario, and parse to generate the final set of execution rules for the target scenario.

Images