DVP rule generation method and device, equipment, medium and program product

Abstract

The invention relates to a DVP rule generation method and device, equipment, a medium and a program product. The method comprises the following steps: receiving a DVP rule written based on a target rule structure, wherein the target rule structure comprises predefined parts; identifying a part of the received DVP rule, and performing form error correction on the part based on a keyword corresponding to the part; performing logical judgment on the DVP rule through a pre-trained large model to obtain a logical judgment result; and under the condition that the logic judgment result is passed, generating the DVP rule. By adopting the method, the generation efficiency and accuracy of the DVP rule can be improved.

Description

Technical Field

[0001] The present application relates to the field of artificial intelligence technology, and in particular to a DVP rule generation method, apparatus, device, medium, and program product. Background Art

[0002] In the process of clinical trials and medical data management, the Data Validation Plan (DVP) is used to ensure the integrity, accuracy and consistency of data. Especially in large-scale clinical trials, DVP is a key step in ensuring data quality.

[0003] In traditional technologies, the DVP writing process usually relies on natural language documents and manually defined rules.

[0004] However, the current DVP rules are usually written manually by medical business personnel, which can easily lead to errors when faced with complex logic and other situations. Summary of the Invention

[0005] Based on this, it is necessary to provide a DVP rule generation method, apparatus, device, medium and program product that can improve the generation efficiency and accuracy of DVP rules in order to address the above technical problems.

[0006] In a first aspect, the present application provides a DVP rule generation method, the method comprising:

[0007] receiving a DVP rule written based on a target rule structure, the target rule structure including predefined parts;

[0008] identifying a portion of the received DVP rule and performing formal error correction on the portion based on a keyword corresponding to the portion;

[0009] Performing logical judgment on the DVP rules through a pre-trained large model to obtain a logical judgment result;

[0010] When the result of the logic judgment is pass, the DVP rule is generated.

[0011] In one embodiment, receiving a DVP rule written based on a target rule structure includes:

[0012] receiving current data input based on a target rule structure;

[0013] Determining a portion corresponding to the current data based on the target rule structure, and matching the current data with a keyword corresponding to the portion;

[0014] The current data is completed based on the matching result to obtain a DVP rule.

[0015] In one embodiment, the portion includes: a field portion, a condition portion, and a logic portion, wherein the field portion is used to represent the field to be verified, the condition portion is used to represent the verification logic of the field to be verified, and the verification logic includes value range verification, format verification, and logic verification; the logic portion is used to represent the logical operator in the logic verification; and the method further includes:

[0016] receiving an extension instruction for a keyword, wherein the keyword includes an operation keyword, a logic keyword, a condition keyword, a comparison keyword, and a system keyword, and different parts correspond to different types of the keyword;

[0017] determining the type of the keyword based on the keyword expansion instruction;

[0018] Perform fuzzy matching on the keyword corresponding to the extended instruction and the existing keywords of the keyword type;

[0019] If the match fails, the keyword corresponding to the extended instruction is associated with the type of the keyword and stored.

[0020] In one embodiment, the DVP rule is logically judged by using a pre-trained large model to obtain a logical judgment result, including:

[0021] Logically splitting the DVP rule using a pre-trained large model to obtain a plurality of first logical units;

[0022] performing a self-logical check based on the fields and conditions corresponding to each of the first logical units, performing a comprehensive logical check based on the logical relationships between the first logical units, and checking the complexity of the DVP rule, wherein the complexity of the DVP rule is based on the number of the first logical units;

[0023] When at least one of the self-logic check of each of the first logic units to be processed, the inter-first logic unit check, and the complexity of the DVP rule fails, obtaining the part that failed the check, generating an optimization suggestion based on the part that failed the check, and outputting the optimization suggestion.

[0024] In one embodiment, after generating the DVP rule, the following steps are included:

[0025] receiving a code generation instruction, wherein the code generation instruction carries a code type;

[0026] Get pre-set rules and conversion programs between code types;

[0027] The DVP rules are converted into target codes based on the conversion program.

[0028] In one embodiment, the method further comprises:

[0029] Obtain each target code, and determine a test case generation thread corresponding to each target code, wherein each test case generation thread is a parallel thread;

[0030] In the test case generation thread, the test scenarios corresponding to the DVP rules are determined by using the pre-trained large model, and the test case value ranges corresponding to the test scenarios are generated;

[0031] In the test case generation thread, a large model obtained through pre-training generates a test case based on the test case value range and the DVP rule;

[0032] The target code is verified based on the test case.

[0033] In a second aspect, the present application further provides a DVP rule generation device, the device comprising:

[0034] A receiving module, configured to receive a DVP rule written based on a target rule structure, wherein the target rule structure includes predefined parts;

[0035] a formal error correction module, configured to identify a portion of the received DVP rule and perform formal error correction on the portion based on a keyword corresponding to the portion;

[0036] A logic error correction module, configured to perform logic judgment on the DVP rules using a pre-trained large model to obtain a logic judgment result;

[0037] A rule generating module is used to generate the DVP rule when the logic judgment result is passed.

[0038] In a third aspect, the present application further provides a computer device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the above method when executing the computer program.

[0039] In a fourth aspect, the present application also provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the above method when executed by a processor.

[0040] In a fifth aspect, the present application also provides a computer program product, comprising a computer program, which implements the steps of the above method when executed by a processor.

[0041] The above-mentioned DVP rule generation method, apparatus, device, medium, and program product receive a DVP rule written based on a target rule structure, wherein the target rule structure includes predefined parts; identify parts of the received DVP rule, perform formal error correction on the parts based on keywords corresponding to the parts, perform logical judgment on the DVP rule using a pre-trained large model, and obtain a logical judgment result; if the logical judgment result is a pass, the DVP rule is generated. In this way, during the DVP rule generation process, not only formal correction but also logical correction is performed on the DVP rule, thereby ensuring the accuracy of the DVP rule. The automatic logical correction also improves the efficiency of DVP rule generation. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments of the present application or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying any creative work.

[0043] Figure 1 A diagram illustrating an application environment of a DVP rule generation method according to an embodiment;

[0044] Figure 2 Schematic diagram of a flow chart of a DVP rule generation method in one embodiment;

[0045] Figure 3 is a structural block diagram of a DVP rule generating device in one embodiment;

[0046] Figure 4 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0047] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0048] The DVP rule generation method provided in the embodiment of the present application can be applied to Figure 1 In the application environment shown, the terminal 102 communicates with the server 104 via a network. The data storage system can store data that the server 104 needs to process. The data storage system can be integrated on the server 104 or placed on the cloud or other network servers.

[0049] The user can input the DVP rules into the terminal 102 , and the terminal 102 can upload the DVP rules to the server 104 in real time for processing, or process them locally. The processing includes correcting formal and logical errors in the DVP rules; optionally, it can also include generating test cases, etc.

[0050] Specifically, the system identifies parts of the received DVP rules and corrects formal errors based on the keywords corresponding to the parts. A pre-trained large model is used to perform logical judgment on the DVP rules to obtain a logical judgment result. If the logical judgment result is a pass, the DVP rules are generated. In this way, during the DVP rule generation process, not only the formal correction of the DVP rules is performed, but also the logical correction is performed, ensuring the accuracy of the DVP rules. The automatic logical correction also improves the efficiency of DVP rule generation.

[0051] The terminal 102 may be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices may include smart speakers, smart TVs, smart air conditioners, smart car devices, projectors, and the like. Portable wearable devices may include smart watches, smart bracelets, head-mounted devices, and the like. Head-mounted devices may include virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, and the like. The server 104 may be an independent physical server, a server cluster or distributed system consisting of multiple physical servers, or a cloud server providing cloud computing services.

[0052] In an exemplary embodiment, Figure 2 As shown, a DVP rule generation method is provided, which is applied to Figure 1 The terminal or server in the example is used to illustrate, including the following steps 202 to 208. Among them:

[0053] S202: Receive a DVP rule written based on a target rule structure, where the target rule structure includes predefined parts.

[0054] The target rule structure is predefined and consists of various components, including field definitions, condition definitions, and logical operations. Field definitions define fields to be validated, such as patient age and admission date. Condition definitions define field validation criteria, supporting numeric ranges, format checks, and logical relationships. Logical operations support both simple and complex logical operators, such as "AND," "OR," and "NOT."

[0055] For ease of understanding, two DVP rules are given:

[0056] Example 1: Simple patient age verification

[0057] dsl: Verify that the patient's age is between 0 and 120.

[0058] Example 2: Verifying the logical relationship between admission date and discharge date

[0059] Dsl: Verify that the admission date is before the discharge date.

[0060] The above target rule structure maintains consistency across all validation rules through standardized syntax, avoiding ambiguity caused by natural language descriptions. Regardless of the complexity of the rules, users can define them through the unified target rule structure of DSL. The following complex logic can also be defined through the above target rule structure.

[0061] Example: Composite validation of patient age and admission date

[0062] dsl: Verify that the patient's age is between 0 and 120 and the admission date is before the current date.

[0063] Among them, the conditional definitions in this application can include multiple conditional expressions and support the following validation logic: Numerical range validation: Check whether the value of the field is within the specified range. Example: Verify that the weight is between 30 and 100 kilograms. Format validation: Check whether the data conforms to a specific format, such as date, time, text, etc. Example: Verify that the birthday format is YYYY-MM-DD. Logical validation: Supports compound conditions and logical operations, such as AND, OR, NOT, etc. Example: Verify that the blood pressure is between 120 / 80 and 180 / 120 or the blood pressure is not filled in.

[0064] The target rule structure can also support complex logic and nested conditions. Users can define rules that combine cross-fields and multiple conditions to meet complex business logic requirements.

[0065] Example: Cross-Validation with Conditional Nesting

[0066] Dsl: Verify that if gender is "female", then pregnancy status should be "pregnant" or "not pregnant".

[0067] The target rule structure also supports extensible design. The DSL language is designed with the possibility of future expansion in mind, allowing for the definition of new validation rules or operators based on demand. Through its modular syntax, the DSL can flexibly adapt to new validation requirements.

[0068] Example: Introducing new validation logic

[0069] Dsl: Verify that the drug dose is within the safe dose range calculated based on body weight.

[0070] The target rule structure also supports cross-field validation: supporting cross-validation across multiple fields, for example: verifying that the admission date is earlier than the discharge date. Dynamic rule generation: dynamically generating validation rules based on the data context, for example: verifying that the patient's age is less than the current year minus the birth year. Conditional nesting and combination: supporting multi-level logical nesting and conditional combination, for example: verifying that if the patient is an adult, their blood pressure is within a reasonable range.

[0071] The target rule structure described above fully considers the usability of users with non-technical backgrounds. Through a concise imperative description method, users can define complex validation rules without having to master programming knowledge.

[0072] The DVP rules can be received while being input, and during the input process, the part of the DVP rules that has been input can be corrected for formal errors and logically judged as described below.

[0073] S204: Identify the portion of the received DVP rule, and perform formal error correction on the portion based on the keyword corresponding to the portion.

[0074] In this embodiment, when the user is inputting, the system will also provide intelligent prompts and automatic completion to help the user quickly generate compliant DSL rules.

[0075] Keywords are the fundamental elements that make up the target rule structure and instruct the system how to interpret and execute user-entered rules. Keywords define the actions, conditions, and logical relationships within DVP rules through a clear target rule structure, facilitating the parsing and execution of DVP rules. To ensure concise and easy-to-use rule descriptions, keyword design adheres to the principles of intuitiveness, universality, and consistency.

[0076] Rule writing example:

[0077] dsl:

[0078] Verify that the patient's age is between 0 and 120. Check that the admission date is earlier than the current date. If the gender is "Female," check that the pregnancy status is "Pregnant" or "Not Pregnant."

[0079] In this example, the action keywords "validate", "check", and "if / then" help the system clearly define the operation to be performed; the condition keywords "between" and "earlier than" define the logical conditions of the validation rule.

[0080] In the DSL design of this application, keywords are the core component of the DSL language. They help users define data validation rules through intuitive grammatical structures. The design principles of keywords are ease of use, flexibility, and consistency, ensuring that business personnel with non-technical backgrounds can easily write complex validation rules. At the same time, the keyword design of DSL has good scalability. Users can add new operation and condition keywords as needed to meet a wider range of business needs.

[0081] In this embodiment, for ease of understanding, keywords are classified to facilitate fuzzy matching in the process of formal error correction. In one optional embodiment, keywords include operation keywords, logic keywords, condition keywords, comparison keywords and system keywords.

[0082] The operation keyword is used to indicate a specific validation operation, specifically to describe the specific validation operation performed on a field. Common operation keywords include:

[0083] Validation: This is the core keyword of the DSL and is used to define the field to be validated and its conditions. Example: Validate that the patient’s age is between 0 and 120.

[0084] Check: Similar to Verify, but often used for lighter-weight checking scenarios. Example: Checking that the admission date is earlier than the discharge date.

[0085] If / Then: This is used for conditional branching, similar to the "if-then" statement in programming languages. Example: If the gender is "female", then check if the pregnancy status is "pregnant".

[0086] Logical keywords are used to describe the logical relationship between conditions. Specifically, they are used to combine multiple conditions or validation rules and support complex logical expressions. Common logical keywords include:

[0087] AND: Indicates that all conditions must be met at the same time (logical "AND"). Example: Verify that the patient's age is between 0 and 120 and that the admission date is earlier than the discharge date.

[0088] Or: Indicates that any one of the conditions must be met (logical "OR"). Example: Verify that blood pressure is within the normal range or that blood pressure is not entered.

[0089] Not: Used to negate a condition. Example: Verify that the medication is not expired.

[0090] Conditional keywords: used to set the conditions and ranges for data validation. Specifically, they are used to specify the conditions or ranges that a field should meet. Common conditional keywords include:

[0091] Between: Used to define a range of values or time periods. Example: Verify that the weight is between 30 and 100 kg.

[0092] Is: Used to check the specific value of a field. Example: Check if the gender is "Male".

[0093] Before / After: Used to compare dates or times. Example: Verify that the admission date is before the discharge date.

[0094] Comparison keywords: used to define how field values are compared, specifically how fields are compared with conditions. Common comparison keywords include:

[0095] Less Than: Used to define a comparison where a number or date is less than a certain value. Example: Verify that the patient's age is less than the current year minus their birth year.

[0096] Greater than: This is used to define a comparison where a number or date is greater than a certain value. Example: Verify that a temperature greater than 38 degrees Celsius indicates a fever.

[0097] System keywords: used to introduce system variables or dynamic data (such as the current date, age, etc.). Specifically, they introduce some dynamic values or system parameters to implement validation logic based on real-time data. Common system keywords include:

[0098] Current Date: Used to import the current system date. Example: Verify that the admission date is earlier than the current date.

[0099] Year of Birth: Used to calculate age or time-related fields. Example: Verify that the patient's age is less than the current year minus the year of birth.

[0100] In the present application, during the process of inputting DVP rules, a portion of the currently input DVP rule can be determined, and then a mapping relationship between the portion and the keyword type is obtained. The current input data is fuzzy matched with the keyword corresponding to the keyword type to determine whether the input information corresponding to the portion has a formal error. If so, the input information is corrected based on the keyword corresponding to the fuzzy match.

[0101] Part of the mapping relationship with the keyword type can be preset. Specifically, the field definition part includes system keywords, the condition definition includes operation keywords, condition keywords and comparison keywords, and the logical operation includes logic keywords.

[0102] One point that needs to be explained is that fuzzy matching is performed on natural language recognition according to a pre-trained large model to improve the accuracy of the match. This application uses a pre-trained large model to fuzzily match the current data input with the keyword corresponding to the keyword type. That is to say, if the current data input is information such as dialect, it can also be converted into a standardized expression after fuzzy matching to ensure uniformity. For convenience, the mapping relationship between each input current data and the standard keyword can also be stored. In this way, when performing the conversion, only the large model needs to learn these mapping relationships, that is, the standard keyword corresponding to the input current data can be obtained. For example, the standard keyword corresponding to age and age is age. Therefore, after the user enters words such as age and age, it can be converted into the standard keyword age to facilitate subsequent parsing.

[0103] In addition, in order to improve the efficiency of matching, the mapping relationship between some corresponding keyword types and the mapping relationship between keyword types and specific standard keywords are pre-set. In this way, the keyword type can be determined based on part of the current input data, and then the specific standard keyword can be obtained before matching. This can reduce the amount of data involved in matching and greatly improve the system's efficiency in correcting formal errors.

[0104] In the above embodiment, when a user enters an incorrect or incomplete field or condition, the system automatically suggests possible correct fields or conditions through a dynamic fuzzy matching mechanism. For example, when entering "admission date is earlier than the current date," if there are grammatical errors or spelling issues, the system can provide correction suggestions. During the parsing process, the system can detect logical or grammatical errors in the input and immediately provide correction suggestions. This ensures that users can quickly correct errors and obtain optimal rule definitions when writing DSL rules.

[0105] S206: Perform logical judgment on the DVP rules using the pre-trained large model to obtain a logical judgment result.

[0106] Logical judgment is performed using a pre-trained large model, providing feedback during user input. For example, if a rule's logic is found to be unreasonable, the system will automatically prompt and suggest modifications. Alternatively, logical judgment can be performed through intelligent analysis, with the system providing optimization suggestions for the entered rule. For example, if the user enters lengthy logic or repetitive conditions, the system will suggest simplifying the rule. This makes the rules more efficient and concise.

[0107] For example, real-time feedback example:

[0108] dsl: User input: Verify that patient age is less than birth year. System feedback: Error - patient age should be greater than birth year. Please check the rules.

[0109] The specific workflow is as follows: The user enters a DSL rule. The system parses it and immediately checks its logical correctness. It provides feedback and suggests that the user modify or optimize the rule. The user adjusts the rule based on the feedback.

[0110] Because the DVP rules in this application use the target rule structure described above, they support complex logic: DSL can support multi-field cross-validation, multiple condition combinations, and nested logic. For example, the system supports logical combination validation of multiple fields, such as "If the patient is female and over 18 years old, check whether she is pregnant."

[0111] The DVP rules in this application also support nested conditions and recursive validation: The DSL language allows nested conditions, implementing recursive validation through an "if...then..." structure. This enables the system to handle more complex validation logic, such as relying on the validation result of a previous field before proceeding to the next step. Example: DSL: If gender is "female" and age is greater than 18, then check pregnancy status as "pregnant" or "not pregnant."

[0112] Therefore, in the process of performing logical verification of DVP rules in this application, the system needs to combine complex logic and conditional nesting and recursion to perform logical verification to improve accuracy.

[0113] S208: If the logical judgment result is passed, generate a DVP rule.

[0114] Wherein, when the input DVP rules have no form errors and no logic errors and the logic is optimized, the DVP rules are generated.

[0115] Generating DVP rules specifically involves generating accurate DVP rules to facilitate the generation and verification of subsequent test cases for the DVP rules.

[0116] The DVP rule generation method receives a DVP rule written based on a target rule structure, the target rule structure including predefined parts; identifies parts of the received DVP rule, corrects formal errors in the parts based on keywords corresponding to the parts, and performs logical judgment on the DVP rule using a pre-trained large model to obtain a logical judgment result; and generates a DVP rule if the logical judgment result is a pass. In this way, during the DVP rule generation process, not only formal corrections are performed on the DVP rule, but also logical corrections are performed, thereby ensuring the accuracy of the DVP rule. The automatic logical correction also improves the efficiency of DVP rule generation.

[0117] In one optional embodiment, receiving a DVP rule written based on a target rule structure includes: receiving current data input based on the target rule structure; determining a portion corresponding to the current data based on the target rule structure, matching the current data with a keyword corresponding to the portion; and completing the current data based on the matching result to obtain the DVP rule.

[0118] Specifically, the mapping relationship between the part and the keyword type can be preset. Specifically, the field definition part includes system keywords, the condition definition includes operation keywords, condition keywords and comparison keywords, and the logical operation includes logic keywords.

[0119] In the present application, during the DVP rule input process, a portion of the currently input DVP rule can be determined, and then a mapping relationship between the portion and the keyword type is obtained. The current input data is fuzzy matched with the keyword corresponding to the keyword type through a pre-trained large model to determine whether the input information corresponding to the portion has a formal error. If so, the input information is corrected based on the keyword corresponding to the fuzzy match.

[0120] The formal errors in this application include missing keywords, non-standard keywords, etc. After the above processing, each keyword in the DVP rule is converted into a standard keyword to ensure the accuracy of the input DVP rule.

[0121] In one of the optional embodiments, the part includes: a field part, a condition part and a logic part, the field part is used to characterize the field to be verified, the condition part is used to characterize the verification logic of the field to be verified, and the verification logic includes numerical range verification, format verification and logic verification; the logic part is used to characterize the logical operators in the logic verification; the method also includes: receiving an extension instruction for a keyword, the keywords include operation keywords, logical keywords, condition keywords, comparison keywords and system keywords, and different parts correspond to different types of keywords; determining the type of the keyword based on the keyword extension instruction; fuzzy matching the keyword corresponding to the extension instruction with the existing keyword of the keyword type; if the match fails, the keyword corresponding to the extension instruction is associated with the keyword type and stored.

[0122] The various types of keywords in this application are extensible. For example, more customized system keywords or domain-specific operation keywords can be introduced based on business needs. With this flexibility, DSL can meet more complex business scenarios in the future.

[0123] In some optional embodiments, business scenarios can be acquired in advance, keywords corresponding to the business scenarios can be determined, and then the keywords can be stored according to keyword types. In this way, when a DVP rule input by a user is subsequently received, the business scenario selected by the user can be determined first, and then keywords of various types can be filtered based on the business scenario. Subsequently, further filtering can be performed based on the mapping relationship between the keyword type and part of the DVP rule, the keyword type, etc., thereby improving processing efficiency.

[0124] Specifically, for example, the extended keyword is safe dose range: In specific drug dose verification, the system can introduce custom keywords such as "safe dose range":

[0125] dsl: Verify that the drug dosage is within the safe dosage range.

[0126] In the above embodiment, corresponding keywords can be expanded based on business needs, thereby improving the accuracy of DVP rule input.

[0127] In one optional embodiment, a logical judgment is performed on the DVP rule using a pre-trained large model to obtain a logical judgment result, including: logically splitting the DVP rule using the pre-trained large model to obtain a plurality of first logical units; performing self-logical verification based on the fields and conditions corresponding to each first logical unit, performing comprehensive logical verification based on the logical relationships between the first logical units, and verifying the complexity of the DVP rule, wherein the complexity of the DVP rule is obtained based on the number of first logical units; if at least one of the self-logical verification of each first logical unit to be processed, the verification between the first logical units to be processed, and the complexity of the DVP rule fails, obtaining the portion that failed the verification, generating optimization suggestions based on the portion that failed the verification, and outputting the optimization suggestions.

[0128] It should be noted that the verification of logic rules includes verifying whether there are errors in the logic rules themselves and optimizing the expression of the logic rules, so that the written DVP rules are more concise and accurate.

[0129] In this embodiment, the logic rule verification process is first described:

[0130] DVP rules are pre-written by users and include target fields, condition fields, logic rules, and return result requirements. To avoid formatting and logic errors when manually entering these DVP rules and to optimize the stability and accuracy of rule input, this application provides a templated input parsing method, allowing users to only provide the necessary information, reducing human error.

[0131] Specifically, the template format includes target fields, conditional fields, logical rules, and return result requirements. The target field refers to the main field that needs to be verified, such as "Visit Date." The conditional field is the conditional field that is compared with the target field, such as "Surgery Date." The logical rule defines the logical relationship between the target field and the conditional field, such as "less than 50 days" or "greater than 74 days." Return result requirements: the expected verification result, such as "Verification Passed" or "Verification Failed."

[0132] The logical splitting model parses the DVP rules to generate independent first logical units. A first logical unit is the smallest logical unit, a unit that can be independently verified. For example, it may only include a single conditional result branch, where a conditional result branch can be considered a branch of a logical rule tree constructed based on each logical rule. The smallest logical unit can include the logical relationship between the target field and the corresponding condition, the logical relationship between the target field and the condition field, and so on, without specific limitations here. Corresponding logical operations are satisfied between each logical unit.

[0133] Specifically, the logical splitting model automatically decomposes complex multi-conditional rules and processes each independent logic. Specifically, the logical splitting model splits DVP rules based on the logical operators and conditions within the DVP rules to obtain individual first logic units. This conditional logic decomposition technology of the logical splitting model can decompose complex logical conditions into independently verifiable units, reducing the complexity of manual configuration and improving the accuracy of the verification process.

[0134] In one of the optional embodiments, the DVP rules are parsed by a pre-trained large model to obtain independent first logical units, including: parsing the DVP rules by a pre-trained logical splitting large model to obtain structured rule data; logically splitting the logical rules in the structured rule data by a pre-trained logical splitting large model to obtain several independent logical units.

[0135] The DVP rule is first parsed. This is because the end user fills out a template, so the received DVP rule is actually in template form. To ensure proper subsequent processing, the DVP rule is parsed into structured data. The parsing logic can be template-dependent, i.e., parsing is performed based on the position of each field in the template to obtain the corresponding structured data. In other embodiments, parsing of the template-based DVP rule can be performed by logically splitting a large model. Natural language processing techniques from the large model are used to parse the template-based DVP rule, automatically identifying the target field, condition field, and logical rule, and converting it into structured data for subsequent processing. The parsed structured DVP rule can be:

[0136] {

[0137] "Target Field":"Visit Date",

[0138] "Conditional Field": "Surgery Date",

[0139] "Logical rule": "<50 or >74",

[0140] "Return result requirement": "Verification passed"

[0141] }

[0142] The logical rules in the structured rule data are logically split by using the pre-trained logical splitting model to obtain several independent logical units. The splitting can be based on the logical operator symbols in the logical rules. For example, the logical operator type in the logical rule is first determined, and the splitting order of the logical rule is determined based on the priority of each logical operator type. Then, the logical rule is split based on the split data to ensure that each logical unit obtained by the split meets the requirements.

[0143] Each independent logic unit can be processed automatically without interfering with each other, thus facilitating the generation and verification of test cases corresponding to subsequent DVP rules.

[0144] Still using the above example, it can be divided into two logical units, including:

[0145] {

[0146] "Target Field":"Visit Date",

[0147] "Conditional Field": "Surgery Date",

[0148] "Logical rules":"<50",

[0149] "Verification result": "Passed"

[0150] }

[0151] {

[0152] "Target Field":"Visit Date",

[0153] "Conditional Field": "Surgery Date",

[0154] "Logical rules":">70",

[0155] "Verification result": "Passed"

[0156] }

[0157] In one optional embodiment, the DVP rules are parsed by a pre-trained large model to obtain independent logical units, including: identifying logical operators and conditions of logical rules in the DVP rules by a pre-trained logical splitting large model; performing initial splitting of the DVP rules based on the logical operators to obtain several initial logical units; and splitting the corresponding initial logical units based on the conditions to obtain several logical units.

[0158] The logic splitting model parses the DVP rules to obtain independent logic units, which can be obtained by splitting the logic operators and conditions in the logic rules of the DVP rules.

[0159] The DVP rules are initially split based on logical operators to obtain several initial logical units. For example, the logical operator type in the logical rule is first determined, and the splitting order of the logical rule is determined based on the priority of each logical operator type. Then, the logical rule is split based on the split data to ensure that each logical unit obtained by the split meets the requirements. Subsequently, the corresponding initial logical unit is split based on the conditions to obtain several logical units.

[0160] In the above embodiment, the logic splitting large model automatically decomposes complex multi-condition rules and processes each independent logic, which can ensure the accuracy of the DVP rules.

[0161] The verification of each independent logic unit may include separate verification of each independent logic unit and comprehensive verification to ensure that the logic of the DVP rule to be processed is correct, so that the test case can be generated normally.

[0162] In one optional embodiment, the method further includes: performing self-logic verification and inter-logic verification on the plurality of logic units using a large logic verification model; determining that the independent logic unit verification is successful if both the self-logic verification and the inter-logic verification of each logic unit pass; and if at least one of the self-logic verification and the inter-logic verification of each logic unit to be processed fail, outputting the failed logic unit to be processed and receiving a correction instruction for a DVP rule, until both the self-logic verification and the inter-logic verification of each logic unit to be processed pass, determining that the independent logic unit verification is successful.

[0163] The logic verification in this application is a verification of the logic of the DVP rules. Since the DVP rules in this application include complex logic, to ensure accuracy, the rules are first verified. This verification includes the logical verification of the logical unit to be processed, such as the current time must be greater than the birth time. Therefore, the verification rules can be based on the rules that each target field and condition field must meet. Inter-logical unit verification is the rules that need to be met between the target field and the condition field, such as the discharge date must be later than the admission date.

[0164] If the logic check corresponding to the DVP rule fails, the pending logic unit that failed the logic check is output, so that the corresponding pending logic unit can be modified to perform the logic check again until the logic check of the DVP rule succeeds. Then, the generation of subsequent test cases for the DVP rule can continue.

[0165] The logic verification can be achieved by logically splitting a large model, which is used to learn the rules that each target field and condition field must follow, so that the large model can identify problematic DVP rules.

[0166] For the expression of optimization logic rules:

[0167] In this embodiment, the relationship between the first logical units obtained by splitting is used to determine whether the form of the DVP rule can be optimized. If so, optimization is performed. For example, whether there are logical rules that can be merged. If so, optimization is performed.

[0168] In one optional embodiment, after generating the DVP rule, the method includes: receiving a code generation instruction, the code generation instruction carrying a code type; obtaining a conversion program between a preset rule and a code type; and converting the DVP rule into a target code based on the conversion program.

[0169] The DSL language used in this application to write DVP rules is universal and can be parsed into multiple programming languages to adapt to different development environments. This design ensures that DSL rules can not only be used as a descriptive language for verification logic but can also be directly used in actual development implementation.

[0170] The structured descriptions in the DSL language can be parsed into programming languages such as Python, Java, and C#, supporting multiple development platforms. For example, the system can parse DSL rules into Python scripts for data processing and automated verification.

[0171] For this purpose, the present application stores a conversion program between rules and code types. Different code types correspond to different conversion programs. Therefore, the DVP rules can be converted into target codes based on the conversion program without manual intervention.

[0172] For example, the system can automatically generate code that conforms to the syntax of the target programming language based on the logic of the DSL rules, without the need for users to write code manually.

[0173] Example: DSL:DSL rule: Verify that the patient's age is between 0 and 120.

[0174] Parsed into Python code:

[0175] if 0<=patient_age<=120:

[0176] pass

[0177] else:

[0178] raise ValueError("The patient's age is not within a reasonable range")

[0179] In the above embodiment, the DVP rules can be automatically converted into target programming language codes, thereby obtaining codes for use in an actual development environment, facilitating subsequent verification of the DVP rules.

[0180] In this application, the entire process from rule writing to actual development and implementation is automated, which greatly improves the efficiency of rule definition, optimization and verification.

[0181] Automation from input to parsing: After the user enters the DSL rules, intelligent parsing, feedback, and error correction are automatically performed. Once the rules are determined, the system automatically generates executable code without manual intervention.

[0182] Automated development: DSL rules are directly converted into the code required for actual development through the parsing module, enabling rapid deployment from rule design to application. For example, user-defined DSL rules in the system can be automatically converted into application code for real-world clinical data verification.

[0183] This application also involves a powerful validation engine that is responsible for executing user-defined DSL rules and validating actual clinical data to ensure data integrity and consistency.

[0184] Rule Execution: The validation engine automatically validates input clinical data based on DSL rules. For example, the system automatically checks whether each piece of data complies with the validation logic defined in the DSL.

[0185] Concurrency and Performance Optimization: The verification engine supports concurrent execution, maintaining efficient verification performance when processing large amounts of clinical data. Through parallel computing and optimized algorithms, the system can rapidly process large amounts of data and generate verification reports. Concurrency means that individual DVP rules are processed independently of each other.

[0186] In one optional embodiment, the method further includes: obtaining each target code and determining a test case generation thread corresponding to each target code, wherein each test case generation thread is a parallel thread; in the test case generation thread, determining a test scenario corresponding to a DVP rule through a pre-trained large model, and generating a test case value range corresponding to each test scenario; in the test case generation thread, generating a test case based on the test case value range and the DVP rule through the pre-trained large model; and verifying the target code based on the test case.

[0187] DVP rules often require simultaneous verification of multiple complex conditions. Traditional sequential processing methods are inefficient when faced with large-scale condition verification, especially when the verification tasks are complex and numerous, as sequential execution can lead to system bottlenecks. To improve verification efficiency, this application uses parallelization technology to simultaneously generate and verify multiple test cases.

[0188] Specifically, the server can connect to multiple terminals, and each terminal can upload multiple DVP rules to be processed each time. Therefore, the server generates a corresponding test case generation thread for each DVP rule. Each test case generation thread can run in parallel to improve the test case generation efficiency.

[0189] Optionally, the server may include a cache queue for caching the pending DVP rules uploaded by each terminal. The server may also include a test case generation thread pool, which includes a scheduling thread. The scheduling thread can detect whether there are pending DVP rules in the cache queue. If so, the scheduling thread obtains the corresponding test case generation thread from the test case generation thread pool and assigns the pending DVP rules to the test case generation thread, so that the pending DVP rules can be processed in parallel and the pending DVP rules do not interfere with each other.

[0190] The test scenario corresponds to each pending DVP rule. Each pending DVP rule may include at least two test scenarios, namely, an abnormal test scenario and a normal test scenario. Optionally, the pending DVP rule may further include a boundary test scenario.

[0191] In one of the optional embodiments, a test case generation macro model obtained through pre-training is used to obtain test scenarios corresponding to the DVP rules to be processed, and a test case value range corresponding to each test scenario is generated, including: the test case generation macro model obtained through pre-training determines the test scenarios based on the DVP rules to be processed, and the test scenarios include normal value scenarios, abnormal value scenarios, and boundary value scenarios; the test case generation macro model obtained through pre-training is combined with the DVP rules to be processed to obtain test case value ranges corresponding to the normal value scenarios, abnormal value scenarios, and boundary value scenarios, respectively.

[0192] The normal value scenario includes the values of the conditions corresponding to each logical rule when the verification result is passed, and the abnormal value scenario includes the complement of the values of the conditions corresponding to each logical rule when the verification result is passed; the boundary value scenario is the values involved in the conditions corresponding to each logical rule.

[0193] For example, if "Logical Rule": ">70" and "Logical Rule": "<50", the value range of the test cases corresponding to the boundary value scenario should meet the requirements of 50 and 70; the value range of the test cases corresponding to the normal value scenario should meet the requirements of >70 and <50; and the value range of the test cases corresponding to the abnormal value scenario should meet the requirements of >50 and <70.

[0194] The pre-trained test case generation model can automatically generate the value range of test cases for multiple scenarios based on the prompt word optimization algorithm, covering all possible logical combinations.

[0195] Optionally, when each to-be-processed DVP rule corresponds to multiple test scenarios, a test case is independently generated for each scenario to ensure comprehensiveness of verification.

[0196] Specifically, the pre-trained test case generation model generates test cases based on the test case value range and the target field and condition field of the DVP rule to be processed. For example, based on the test case value range that the difference between the target field and the condition field must satisfy, the values of each target field and the condition field are generated to obtain the test case.

[0197] After determining the test case value range and the target field and condition field of the DVP rule to be processed, you can obtain the test cases corresponding to each test scenario. The specific example is as follows: [

[0199] {"Target field":"2022-12-01","Condition field":"2022-10-01","Verification result":"Passed"},

[0200] {"Target field":"2022-12-01","Condition field":"2022-07-01","Verification result":"Passed"},

[0201] {"Target Field":"2022-12-01","Condition Field":"2022-09-30","Verification Result":"Failed"} ]

[0203] In one of the optional embodiments, in the test case generation thread, a test case generation large model obtained through pre-training generates test cases corresponding to each test scenario based on the value range of each test case and the DVP rules to be processed, including: generating an initial test case through the test case generation large model obtained through pre-training based on the value range of the test case and the DVP rules to be processed; calling a verification program to verify the initial test case to obtain a test result of the initial test case; on the premise that the test result of the initial test case is failed, adjusting the initial test case, and continuing to execute the step of calling the verification program to verify the initial test case to obtain the test result of the initial test case, until the test results of each initial test case are all passed, and the initial test case with a test result of passed is used as the test case.

[0204] The test cases in this application are generated based on a pre-trained test case generation model. The model generates initial test cases based on the value ranges of each test case and the DVP rules to be processed. An automated verification process is then used to verify the correctness of the generated initial test cases. If the initial test cases are correct, they are used as target test cases for validating the DVP rules to be processed. If the initial test cases are incorrect, the initial test cases are automatically adjusted based on the cause of the output error, and new test cases are generated. Automated verification continues until all generated test cases are correct.

[0205] The method of judging whether the test case is correct is to compare the output result of the test case with the verification result in the test case. If the two are the same, the initial test case is correct, otherwise the initial test case is incorrect.

[0206] In addition, the large model generates initial test cases based on the value range of each test case, which can cover the test cases corresponding to each test scenario and all possible logical combinations to ensure comprehensiveness.

[0207] In the above-mentioned embodiment, the large-scale model's multi-scenario prompt word generation algorithm automatically generates test cases covering all scenarios, ensuring that every condition is verified and avoiding the omission of scenarios in traditional manual generation. The automated feedback adjustment mechanism ensures that the generation and verification process of each test case is dynamically optimized, enabling real-time adjustments and re-verification of failed cases, thereby improving test case accuracy.

[0208] In one of the optional embodiments, the method also includes: on the premise that the test result of the initial test case is failed, obtaining the reason why the initial test case failed the test; adjusting the prompt word generation logic of the test case generation model based on the reason; adjusting the initial test case, including: adjusting the initial test case based on the test case model with the adjusted prompt word generation logic.

[0209] In this embodiment, under the premise that the test result of the initial test case is failed, the prompt words of the large model are corrected based on the initial test case to improve the accuracy of subsequent test cases generated by the large model.

[0210] The large model can obtain the reason why the initial test case failed the test, and identify whether it is a logical error or a parameter setting error. The large model can then automatically adjust the prompt word generation logic based on the feedback analysis results to ensure that the regenerated test case meets the requirements. Subsequently, new test cases are generated based on the prompt word optimization results and automatically enter the verification process until all initial test cases pass the verification.

[0211] For example, reasons why an initial test case might fail could include:

[0212] {

[0213] "Target Field":"2022-12-01",

[0214] "Condition field":"2022-11-10",

[0215] "Verification result": "Failed",

[0216] "Reason": "The visit date is later than the surgery date, which is inconsistent with the logic behind DVP"

[0217] }

[0218] The large model's intelligent feedback mechanism automatically adjusts prompt word generation logic based on the cause of verification failure, ensuring that newly generated test cases meet requirements and reducing the complexity of manual adjustments. The combination of automated feedback and the regeneration process enables rapid iterative verification, ultimately generating accurate test cases and improving overall verification efficiency and accuracy.

[0219] In some optional embodiments, the prompt word generation logic of the large model is not adjusted every time the test result of the initial test case is failed. Instead, the adjustment is triggered only when the number of failed initial test cases exceeds a preset value, or when the update time of the large model arrives, so as to reduce the waste of resources caused by the update of the large model.

[0220] In one of the optional embodiments, the method further includes: obtaining the number of test cases corresponding to each test scenario; when the number of test cases is less than the number threshold corresponding to the test scenario, continuing to generate test cases corresponding to each test scenario based on the value range of each test case and the DVP rules to be processed using the pre-trained test case generation model, until the number of test cases for each test scenario is greater than or equal to the number threshold corresponding to the test scenario.

[0221] In order to improve the accuracy of the test of each test scenario in this application, it is necessary to ensure that the number of test cases corresponding to each test scenario is greater than or equal to the quantity threshold.

[0222] One point that needs to be explained is that the quantity threshold here can be determined based on the test scenario, and the quantity thresholds of test cases in different test scenarios can be the same or different, and no specific limitation is made here.

[0223] In this application, after a test case is generated once, the number of test cases corresponding to each scenario at this time is counted. If it is less than the threshold number of the corresponding test scenario, the big model is called to regenerate new test cases. It should be noted that the test cases generated this time only need to generate test cases for the corresponding test scenarios. Therefore, the requirement input to the big model is to generate test cases for the corresponding test scenarios, without generating test cases for all test scenarios. In addition, the generated number can also be input into the big model so that the big model can generate the corresponding number of test cases.

[0224] In the above embodiment, by combining the large model and the verification program, correct test cases with the required number can be automatically generated, which improves efficiency and ensures the integrity of the test cases.

[0225] In one optional embodiment, the method further includes: determining a complexity corresponding to each DVP rule to be processed, where the complexity is obtained based on the number of independent logical units of the DVP rule to be processed; and allocating thread resources to a test case generation thread corresponding to each DVP rule to be processed based on the complexity.

[0226] In this application, for each pending DVP rule, parallel test case generation threads are used to process the rules, which can improve efficiency. In addition, since the complexity of each pending DVP rule is different, if all threads have the same resources, it will lead to low efficiency. Therefore, thread resources are dynamically allocated based on the complexity of the pending DVP rule, ensuring that the system can still run efficiently under high load conditions and avoiding resource bottlenecks during the verification process.

[0227] The complexity of the DVP rules to be processed can be obtained based on the number of logic units. That is, the more the number of logic units is, the higher the complexity of the DVP rules to be processed is, and thus more thread resources are allocated.

[0228] In some optional embodiments, the server further summarizes the results of each pending DVP rule and generates a corresponding report. For example, the report may be:

[0229] {

[0230] "Rule":"Visit date - surgery date <50 or >74",

[0231] "Result":"Partially passed",

[0232] "Details":[

[0233] {"Target field":"2022-12-01","Condition field":"2022-11-15","Verification result":"Failed"},

[0234] {"Target field":"2022-12-01","Condition field":"2022-10-01","Verification result":"Passed"} ]

[0236] }

[0237] In the above embodiment, by parallelizing the generation and verification process, a large number of DVP rules can be processed in a short period of time, greatly improving verification efficiency. This is particularly suitable for complex multi-condition rule verification. A load balancing algorithm is used to optimize resource allocation, ensuring efficient system operation under high loads, avoiding the resource waste and delays common in traditional sequential verification processes.

[0238] Among them, it is also necessary to explain that in order to distinguish the functions in the above text, each large model is given a separate name. In some optional embodiments, each large model can be a separate large model. In some other optional embodiments, each large model can be integrated into one large model. No specific limitation is made here.

[0239] It should be understood that, although the steps in the flowcharts of the above embodiments are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the flowcharts of the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily performed at the same time, but can be performed at different times. The execution order of these steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0240] Based on the same inventive concept, embodiments of the present application also provide a DVP rule generation device for implementing the aforementioned DVP rule generation method. The solution provided by this device is similar to the solution described in the aforementioned method. Therefore, the specific limitations of one or more DVP rule generation device embodiments provided below can be found in the above-described limitations of the DVP rule generation method and will not be further elaborated here.

[0241] In an exemplary embodiment, Figure 3 As shown, a DVP rule generation device is provided, comprising: a receiving module 301, a formal error correction module 302, a logical error correction module 303 and a rule generation module 304, wherein:

[0242] A receiving module 301 is configured to receive a DVP rule written based on a target rule structure, wherein the target rule structure includes predefined parts;

[0243] a formal error correction module 302 for identifying a portion of the received DVP rule and performing formal error correction on the portion based on a keyword corresponding to the portion;

[0244] The logic error correction module 303 is used to perform logic judgment on the DVP rules using a pre-trained large model to obtain a logic judgment result;

[0245] The rule generation module 304 is configured to generate a DVP rule when the logic judgment result is a pass.

[0246] In one optional embodiment, the receiving module 301 is specifically configured to receive current data input based on a target rule structure; determine a portion corresponding to the current data based on the target rule structure, and match the current data with a keyword corresponding to the portion; and complete the current data based on the matching result to obtain a DVP rule.

[0247] In one of the optional embodiments, the part includes: a field part, a condition part and a logic part, the field part is used to characterize the field to be verified, the condition part is used to characterize the verification logic of the field to be verified, and the verification logic includes numerical range verification, format verification and logic verification; the logic part is used to characterize the logical operators in the logic verification; the above-mentioned device also includes: an extension module, used to receive extension instructions for keywords, keywords include operation keywords, logical keywords, condition keywords, comparison keywords and system keywords, and different parts correspond to different types of keywords; determine the type of keyword based on the keyword extension instruction; fuzzy match the keyword corresponding to the extension instruction with the existing keyword of the keyword type; if the match fails, the keyword corresponding to the extension instruction is associated with the keyword type and stored.

[0248] In one optional embodiment, the logic error correction module 303 is specifically configured to logically split the DVP rule using a pre-trained large model to obtain a plurality of first logic units; perform self-logical verification based on the fields and conditions corresponding to each first logic unit, perform comprehensive logic verification based on the logical relationships between the first logic units, and verify the complexity of the DVP rule, where the complexity of the DVP rule is based on the number of first logic units; and if at least one of the self-logical verification of each first logic unit to be processed, the verification between the first logic units to be processed, and the complexity of the DVP rule fails, obtain the portion that failed the verification, generate optimization suggestions based on the portion that failed the verification, and output the optimization suggestions.

[0249] In one optional embodiment, the apparatus further includes: a code conversion module configured to receive a code generation instruction, the code generation instruction carrying a code type; obtain a conversion program between a preset rule and a code type; and convert the DVP rule into a target code based on the conversion program.

[0250] In one optional embodiment, the above-mentioned device also includes: a test verification module, which is used to obtain each target code and determine a test case generation thread corresponding to each target code, and each test case generation thread is a parallel thread; in the test case generation thread, the test scenario corresponding to the DVP rule is determined by a pre-trained large model, and a test case value range corresponding to each test scenario is generated; in the test case generation thread, the pre-trained large model is used to generate a test case based on the test case value range and the DVP rule; and the target code is verified based on the test case.

[0251] Each module in the aforementioned DVP rule generation device may be implemented in whole or in part through software, hardware, or a combination thereof. Each module may be embedded in or independent of a processor within a computer device in the form of hardware, or may be stored in a computer device memory in the form of software, so that the processor can call and execute the corresponding operations of each module.

[0252] In an exemplary embodiment, a computer device is provided. The computer device may be a terminal, and its internal structure diagram may be as shown in FIG. Figure 4 As shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit and an input device. The processor, the memory and the input / output interface are connected via a system bus, and the communication interface, the display unit and the input device are connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner can be achieved through WIFI, a mobile cellular network, near field communication (NFC) or other technologies. When the computer program is executed by the processor, a DVP rule generation method is implemented. The display unit of the computer device is used to form a visually visible image, which can be a display screen, a projection device or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device casing, or an external keyboard, touchpad or mouse.

[0253] Those skilled in the art will understand that Figure 4 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0254] In one embodiment, a computer device is further provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0255] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0256] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0257] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0258] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile memory and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a programmable logic unit (PLC), a data processing logic unit based on quantum computing, an artificial intelligence (AI) processor, and the like.

[0259] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0260] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A DVP rule generation method, characterized in that: The method comprises: receiving a DVP rule written based on a target rule structure, the target rule structure including predefined parts; identifying a portion of the received DVP rule and performing formal error correction on the portion based on a keyword corresponding to the portion; Performing logical judgment on the DVP rules through a pre-trained large model to obtain a logical judgment result; When the result of the logic judgment is pass, the DVP rule is generated.

2. The method according to claim 1, characterized in that The receiving of the DVP rule written based on the target rule structure includes: receiving current data input based on a target rule structure; Determining a portion corresponding to the current data based on the target rule structure, and matching the current data with a keyword corresponding to the portion; The current data is completed based on the matching result to obtain a DVP rule.

3. The method according to claim 1 or 2, characterized in that The part includes: a field part, a condition part, and a logic part. The field part is used to represent the field to be verified. The condition part is used to represent the verification logic of the field to be verified. The verification logic includes value range verification, format verification, and logic verification. The logic part is used to represent the logical operator in the logic verification. The method further includes: receiving an extension instruction for a keyword, wherein the keyword includes an operation keyword, a logic keyword, a condition keyword, a comparison keyword, and a system keyword, and different parts correspond to different types of the keyword; determining the type of the keyword based on the keyword expansion instruction; Perform fuzzy matching on the keyword corresponding to the extended instruction and the existing keywords of the keyword type; If the match fails, the keyword corresponding to the extended instruction is associated with the type of the keyword and stored.

4. The method according to claim 1, wherein The DVP rule is logically judged by the pre-trained large model to obtain a logical judgment result, including: Logically splitting the DVP rule using a pre-trained large model to obtain a plurality of first logical units; performing a self-logical check based on the fields and conditions corresponding to each of the first logical units, performing a comprehensive logical check based on the logical relationships between the first logical units, and checking the complexity of the DVP rule, wherein the complexity of the DVP rule is based on the number of the first logical units; When at least one of the self-logic check of each of the first logic units to be processed, the inter-first logic unit check, and the complexity of the DVP rule fails, obtaining the part that failed the check, generating an optimization suggestion based on the part that failed the check, and outputting the optimization suggestion.

5. The method according to claim 1 or 2, characterized in that After the DVP rule is generated, the method includes: receiving a code generation instruction, wherein the code generation instruction carries a code type; Get pre-set rules and conversion programs between code types; The DVP rules are converted into target codes based on the conversion program.

6. The method according to claim 5, characterized in that The method further comprises: Obtain each target code, and determine a test case generation thread corresponding to each target code, wherein each test case generation thread is a parallel thread; In the test case generation thread, the test scenarios corresponding to the DVP rules are determined by using the pre-trained large model, and the test case value ranges corresponding to the test scenarios are generated; In the test case generation thread, a large model obtained through pre-training generates a test case based on the test case value range and the DVP rule; The target code is verified based on the test case.

7. A DVP rule generation device, characterized in that: The device comprises: A receiving module, configured to receive a DVP rule written based on a target rule structure, wherein the target rule structure includes predefined parts; a formal error correction module, configured to identify a portion of the received DVP rule and perform formal error correction on the portion based on a keyword corresponding to the portion; A logic error correction module, configured to perform logic judgment on the DVP rules using a pre-trained large model to obtain a logic judgment result; A rule generating module is used to generate the DVP rule when the logic judgment result is passed.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images