Clinical test data table collaborative auditing method and system based on file state driving
By generating a topology diagram of tabular data units and using a constraint propagation analysis model to handle the diffusion of influence, the problem of low efficiency in the traditional clinical trial data table review was solved, realizing automated collaborative review and improving review efficiency and accuracy.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- JIEHELIX (SHANGHAI) MEDICAL TECH CO LTD
- Filing Date
- 2026-04-21
- Publication Date
- 2026-05-19
AI Technical Summary
Traditional clinical trial data form review methods are inefficient, prone to omissions, and lack in-depth analysis of data relationships. This forces reviewers to spend a lot of time re-examining data relationships, affecting review efficiency and accuracy.
The file-state-driven approach generates a topology diagram of tabular data cells, clarifies the correspondence and constraints between data fields, uses a constraint propagation analysis model to handle the diffusion of influence, and generates file-state-driven instructions to trigger collaborative review operations.
It has enabled automated coordination of the review process, improved review efficiency, ensured the comprehensiveness and accuracy of the review, and enhanced the quality and reliability of clinical trial data review.
Smart Images

Figure CN122067684A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of clinical trial data processing technology, and more specifically, to a collaborative review method and system for clinical trial data tables based on file status. Background Technology
[0002] In the field of clinical trials, collaborative review of data tables is a crucial step in ensuring data accuracy and completeness. Traditional methods of reviewing clinical trial data tables often rely on manual, row-by-row checking, which is not only inefficient but also prone to oversights.
[0003] As clinical trials expand in scale and data volume increases, the limitations of manual review become increasingly apparent. Furthermore, most existing review systems only offer basic data viewing and tagging functions, lacking in-depth analysis of the relationships between data points. During the review process, when a data field is modified or an issue is discovered, it's difficult to quickly and accurately identify related data fields. This forces reviewers to spend significant time re-examining data relationships, impacting review efficiency and accuracy. In addition, the lack of effective coordination mechanisms among different reviewers easily leads to duplicate reviews or omissions. Summary of the Invention
[0004] In view of this, the purpose of this application is to provide a collaborative review method and system for clinical trial data tables based on document status.
[0005] According to a first aspect of this application, a collaborative review method for clinical trial data tables based on document status is provided, the method comprising: The initial file set corresponding to the form file, the initial file set containing the form file unit to be reviewed with a unique file identifier and a set of metadata description information associated with the form file unit to be reviewed; The data unit structure of the table file unit to be reviewed is parsed based on the metadata description information set to generate a table data unit topology graph consisting of multiple data unit nodes. The data unit nodes form a one-to-one correspondence with the data fields in the table file unit to be reviewed. The data unit nodes are connected by data dependency edges, which represent the constraint relationship between data fields. In response to an audit operation performed by a collaborative audit entity on a target data unit node in the table data unit topology graph, an audit operation event is generated that includes the node identifier of the target data unit node and the audit operation type. The audit operation event is input into a preset constraint propagation analysis model. The constraint propagation analysis model performs influence range diffusion processing on the target data unit node according to the data dependency edge to obtain the set of associated data unit nodes affected by the audit operation event. Based on each associated data unit node in the set of associated data unit nodes, a corresponding file status driving instruction is generated, and the file status driving instruction is sent to the collaborative review terminal to trigger the collaborative review operation on the data field corresponding to the associated data unit node.
[0006] According to a second aspect of this application, a file-state-driven collaborative review system for clinical trial data tables is provided. The file-state-driven collaborative review system for clinical trial data tables includes a machine-readable storage medium and a processor. The machine-readable storage medium stores machine-executable instructions. When the processor executes the machine-executable instructions, the file-state-driven collaborative review system for clinical trial data tables implements the aforementioned file-state-driven collaborative review method for clinical trial data tables.
[0007] Based on any of the above aspects, the technical effect of this application is as follows: By acquiring the set of metadata descriptions and unique file identifiers for the tables to be reviewed, each data table file can be located. The data units are then structurally analyzed to generate a topology diagram, clarifying the one-to-one correspondence and constraints between data fields. This presents the data structure in an intuitive graphical format. Review operation events are generated in response to review operations, and a constraint propagation analysis model is used to diffuse the impact based on data dependency edges. This allows for the rapid and accurate identification of the set of related data unit nodes affected by the review operation, avoiding the tedious and error-prone process of manually sorting out data relationships. Based on the related data unit nodes, file status-driven instructions are generated and collaborative review operations are triggered, achieving automated coordination of the review process, improving review efficiency, ensuring the comprehensiveness and accuracy of the review, and effectively enhancing the quality and reliability of clinical trial data review. Attached Figure Description
[0008] Figure 1 A flowchart illustrating the collaborative review method for clinical trial data tables based on file status driven by embodiments of this application is shown. Figure 2 This illustration shows a schematic diagram of the component structure of a file-state-driven collaborative review system for clinical trial data tables, provided in an embodiment of this application, for implementing the above-described file-state-driven collaborative review method for clinical trial data tables. Detailed Implementation
[0009] Figure 1This paper illustrates a flowchart of a collaborative review method and system for clinical trial data tables based on file status driven by embodiments of this application. Detailed steps include: Step S110: Obtain the initial file set corresponding to the clinical trial data table file, wherein the initial file set includes the table file unit to be reviewed with a unique file identifier and a set of metadata description information associated with the table file unit to be reviewed.
[0010] This embodiment uses a Phase III clinical trial evaluating the efficacy of a novel drug as an example. The data generated by this trial is organized into multiple structured electronic case report forms. An operation is performed to obtain the initial file set corresponding to the clinical trial data form files. This initial file set contains a form file unit to be reviewed and a set of metadata description information associated with the form file unit to be reviewed. The form file unit to be reviewed is a structured file containing complete clinical trial data, such as an electronic case report form file recording the baseline information of the subjects.
[0011] Assign a globally unique file identifier, such as "FILE_CRF_BASELINE_001," to the form file unit to be reviewed. This identifier uniquely identifies the file throughout the system's entire lifecycle. The metadata description information set is descriptive data accompanying the form file unit to be reviewed, used to define its structure and rules. This metadata description information set exists as an independent structured file, containing table structure definition information and a set of table constraint rules. The table structure definition information defines the name, data type, field length, and field position of each data field in the form file unit to be reviewed. The set of table constraint rules defines the calculation relationships, logical validation rules, and value range constraints between data fields. For example, the metadata description information set defines the "Subject ID" field as text, the "Age" field as integer, and the "Systolic Blood Pressure" and "Diastolic Blood Pressure" fields as floating-point numbers. It also defines the calculation rule that the "Body Mass Index" field equals the "Weight" field divided by the square of the "Height" field, and the value range constraint that the "Age" field must be between 18 and 80 years old. After obtaining the initial file set, the initial file set is stored in the file storage service, and a file index record is created in the database. This file index record is associated with the unique file identifier "FILE_CRF_BASELINE_001" and the storage path of the metadata description information set.
[0012] Step S120: Perform data unit structure parsing processing on the table file unit to be reviewed according to the metadata description information set, and generate a table data unit topology graph composed of multiple data unit nodes. The data unit nodes form a one-to-one correspondence with the data fields in the table file unit to be reviewed. The data unit nodes are connected by data dependency edges, and the data dependency edges represent the constraint relationship between data fields.
[0013] After obtaining the initial set of files, the data unit structure parsing process is performed on the table file units to be reviewed based on the metadata description information set to generate a table data unit topology diagram.
[0014] Step S121: Parse the table structure definition information in the metadata description information set, and extract the data field name set and data field type set from the table structure definition information. Each data field name in the data field name set corresponds to a data field in the table file unit to be reviewed, and each data field type in the data field type set forms a one-to-one correspondence with the data field name in the data field name set.
[0015] The metadata parser is invoked to read the set of metadata description information associated with the form file unit to be reviewed. This metadata parser locates the table structure definition information section within the metadata description information set, traverses this section, and extracts the names and corresponding data types of all data fields. From the table structure definition information, a set of data field names is extracted, containing "Subject ID," "Age," "Gender," "Height," "Weight," "Systolic Blood Pressure," "Diastolic Blood Pressure," and "Body Mass Index." Simultaneously, the corresponding set of data field types is extracted, containing "String," "Integer," "String," "Floating-point Number," "Floating-point Number," "Floating-point Number," "Floating-point Number," and "Floating-point Number." This metadata parser ensures a strict one-to-one correspondence between the data field names in the data field name set and the data field types in the data field type set.
[0016] Step S122: Based on the data field names in the data field name set and the data field types in the data field type set, generate a corresponding data unit node for each data field name. The data unit node includes a node identifier, a node name attribute, a node type attribute, and a node value range attribute. The node name attribute takes the value of the corresponding data field name, the node type attribute takes the value of the corresponding data field type, and the node value range attribute extracts the corresponding data field value range definition from the metadata description information set.
[0017] Based on the data field names and data field types extracted in step S121, a corresponding data unit node is generated for each data field. A data unit node is generated for the "Age" field, and a unique node identifier "NODE_AGE_001" is assigned to it. The node name attribute of this data unit node is set to "Age," and the node type attribute is set to "Integer." Simultaneously, the metadata description information set is queried again to extract the value range definition associated with the "Age" field. This value range is defined as a minimum value of 18 and a maximum value of 80, and this value range definition is stored as the node value domain attribute of this data unit node. A data unit node is generated for the "Body Mass Index" field, and a node identifier "NODE_BMI_001" is assigned to it. The node name attribute is set to "Body Mass Index," and the node type attribute is set to "Floating Point Number." Since the value range of the "Body Mass Index" field is determined by the calculation rules, its node value domain attribute is empty and will be determined later by constraint rules. All generated data unit nodes are temporarily stored in the node buffer.
[0018] Step S123: Parse the set of table constraint rules in the set of metadata description information, and extract constraint condition expressions from the set of table constraint rules. The constraint condition expressions define the calculation relationship or logical association relationship between two or more data fields. The constraint condition expressions include left operand identifiers, right operand identifiers and operator type identifiers.
[0019] The parser continues parsing the table constraint rule set within the metadata description information set. This set of table constraint rules describes the dependencies between data fields using a predefined rule language. The parser iterates through each rule in this set, extracting its core elements. For the rule that calculates "Body Mass Index" (BMI), the constraint expression can be represented as: "BMI" equals "Weight" divided by the product of "Height" and "Height". The parser extracts the left operand identifier "BMI", the right operand identifiers "Weight" and "Height", and the operator type identifiers "Division" and "Multiplication". For the logical validation rule "If 'Gender' equals 'Female' and 'Hemoglobin' is less than 110, then trigger a warning", the parser extracts the left operand identifiers "Gender" and "Hemoglobin", the right operand identifiers are the constant values "Female" and "110", and the operator type identifiers are "Equal to", "Less than", and "Logical AND".
[0020] Step S124: Perform dependency analysis on the data unit nodes according to the constraint expressions, determine the dependency direction between the data unit nodes associated with each constraint expression, and generate data dependency edges connecting the associated data unit nodes. The data dependency edges include a dependency type attribute and a constraint expression reference identifier. The dependency type attribute represents the dependency direction feature of the constraint expression, and the constraint expression reference identifier points to the constraint expression that generated the data dependency edge.
[0021] Based on the constraint expressions extracted in step S123, dependency analysis is performed. For the calculation expression of "Body Mass Index" (BMI), the data unit nodes corresponding to the operands in the expression are identified as "Weight," "Height," and "BMI." According to the semantics of the expression, the dependency direction is determined: changes in the values of the "Weight" and "Height" data unit nodes will affect the value of the "BMI" data unit node; therefore, the dependency direction is from the "Weight" and "Height" data unit nodes to the "BMI" data unit node. A data dependency edge is generated for each pair of dependencies. A data dependency edge is generated from the "Weight" data unit node to the "BMI" data unit node. This data dependency edge contains a dependency type attribute, whose value is set to "Computational Dependency," indicating that the data dependency edge is generated by a computational expression. Simultaneously, this data dependency edge also contains a constraint expression reference identifier, which points to the original constraint expression that generated this data dependency edge, such as "RULE_BMI_CALC_001," for subsequent traceability and verification. Similarly, another data dependency edge is generated, pointing from the "height" data unit node to the "body mass index" data unit node.
[0022] Step S125: Combine all generated data unit nodes and all data dependency edges into a table data unit topology graph, assign a topology graph identifier to the table data unit topology graph, establish an association mapping relationship between the topology graph identifier and the unique file identifier of the table file unit to be reviewed, and then store it in the topology graph storage space.
[0023] After generating all data unit nodes and data dependency edges, these nodes and edges are combined into a complete graph structure, namely the tabular data unit topology graph. A unique topology graph identifier, such as "TOPO_CRF_BASELINE_001," is assigned to this topology graph topology graph. Subsequently, an association mapping is established in the database between this topology graph identifier and the unique file identifier "FILE_CRF_BASELINE_001" of the table file unit to be reviewed. Finally, the entire tabular data unit topology graph is serialized into a graph data file and stored in the topology graph storage space for rapid loading and use later.
[0024] Step S126: Perform in-degree calculation on each data unit node in the table data unit topology graph to obtain the in-degree value of each data unit node. The in-degree value represents the total number of data dependency edges pointing to the data unit node. Store the in-degree value of each data unit node as a node attribute in the data unit node. Also, perform out-degree calculation on each data unit node in the table data unit topology graph to obtain the out-degree value of each data unit node. The out-degree value represents the total number of data dependency edges pointing from the data unit node to other data unit nodes. Store the out-degree value of each data unit node as a node attribute in the data unit node.
[0025] To analyze the topological importance of data unit nodes in the tabular data unit topology graph, in-degree and out-degree calculations are performed on each data unit node. All data dependency edges are traversed. For each data unit node, the number of data dependency edges with that node as the target node is counted to obtain the in-degree value. For the "Body Index" data unit node, since there are two data dependency edges pointing to it from both the "Weight" and "Height" data unit nodes, its in-degree value is 2. This in-degree value is stored as the "In-degree Value" attribute in the "Body Index" data unit node. Simultaneously, the number of data dependency edges with that node as the source node is counted to obtain the out-degree value. The "Weight" data unit node has one data dependency edge pointing to it, with an out-degree value of 1. This out-degree value is stored as the "Out-degree Value" attribute in the "Weight" data unit node.
[0026] Step S127: Perform hierarchical division processing on all data unit nodes in the table data unit topology graph according to the in-degree and out-degree values of each data unit node. Mark the data unit nodes with an in-degree value of 0 as the root node layer, mark the data unit nodes with an out-degree value of 0 as the leaf node layer, and mark the data unit nodes with both in-degree and out-degree values as intermediate node layers according to the path length from the root node layer to the leaf node layer.
[0027] Based on the calculated in-degree and out-degree values, the data unit nodes are hierarchically divided. Data unit nodes with an in-degree of 0, such as the "Subject ID," "Age," and "Gender" data unit nodes, are identified. These data unit nodes have no other data unit nodes that depend on them, and are therefore marked as the root node layer. Data unit nodes with an out-degree of 0, such as the "Body Mass Index" data unit node, are identified. This data unit node has no data dependency edges pointing to other data unit nodes, and is therefore marked as the leaf node layer. For data unit nodes with both in-degree and out-degree values not equal to 0, such as the "Weight" and "Height" data unit nodes, the longest path length from any data unit node marked as the root node layer to this data unit node is calculated, and the data unit node is marked as the corresponding intermediate node layer based on this longest path length.
[0028] Step S128: Perform weight assignment processing on each data dependency edge in the topology graph of the table data unit. The weight assignment processing determines the propagation weight value of the data dependency edge according to the operator type identifier of the constraint condition expression corresponding to the data dependency edge. The propagation weight value is positively correlated with the constraint strength parameter corresponding to the operator type identifier.
[0029] Assign a propagation weight value to each data dependency edge to quantify the strength of the dependency. Obtain the constraint expression associated with each data dependency edge and analyze its operator type identifier. For data dependency edges generated by the "equal to" operator, the constraint strength parameter is the highest, so the propagation weight value is set to a high predefined value, such as 10. For data dependency edges generated by the "greater than" or "less than" operators, the constraint strength parameter is next, and the propagation weight value is set to 5. For data dependency edges generated by the "logical AND" or "logical OR" operators, the constraint strength parameter is lower, and the propagation weight value is set to 2. For data dependency edges generated by other non-deterministic relations, the propagation weight value is set to 1. Store the calculated propagation weight values as attributes in the corresponding data dependency edges.
[0030] Step S129: Structure and store the node identifiers of all data unit nodes, the edge identifiers of all data dependent edges, the in-degree and out-degree values of each data unit node, the hierarchical labeling information of each data unit node, and the propagation weight value of each data dependent edge in the table data unit topology graph to generate a table data unit topology graph description file, and associate the table data unit topology graph description file with the unique file identifier.
[0031] After all calculations and labeling are completed, the structured information of the entire tabular data unit topology graph is persistently stored. The node identifiers, in-degree values, out-degree values, and level label information of all data unit nodes, as well as the edge identifiers and propagation weights of all data-dependent edges, are collected and organized into a binary file, namely the tabular data unit topology graph description file, according to a predefined format. This tabular data unit topology graph description file is stored in the topology graph storage space, and the storage path of this description file is associated with the unique file identifier "FILE_CRF_BASELINE_001" of the table file unit to be reviewed in the database's file index record, so that the topology graph of the table data unit can be quickly loaded during subsequent review processes.
[0032] Step S130: In response to the audit operation performed by the collaborative audit entity on the target data unit node in the table data unit topology graph, an audit operation event containing the node identifier of the target data unit node and the audit operation type is generated.
[0033] After the tabular data cell topology diagram is generated, it begins responding to review operations from collaborative review entities. These entities can be clinical data administrators or medical monitors with specific review permissions, and they interact with the system through a collaborative review terminal.
[0034] Step S131: Receive an audit operation request sent by the collaborative audit terminal. The audit operation request includes the node identifier of the target data unit node, the operation execution entity identifier, the operation timestamp, and the operation type identifier. The operation type identifier is generated by the collaborative audit terminal based on the operation behavior of the collaborative audit entity on the user interface.
[0035] When a collaborative audit entity performs an operation on a data unit on the collaborative audit terminal, the terminal generates an audit operation request. This request is a structured message containing the target data unit node's node identifier "NODE_AGE_001", the operation execution entity identifier, the operation timestamp, and the operation type identifier. The operation execution entity identifier is the user identity identifier of the collaborative audit entity, such as "USER_DR_ZHANG". The operation timestamp is the server's current time. The operation type identifier is mapped by the collaborative audit terminal based on the collaborative audit entity's user interface operation behavior, such as "DATA_MODIFY". This audit operation request is received through an application programming interface (API).
[0036] Step S132: Extract the node name attribute, node type attribute, and node value domain attribute of the target data unit node from the table data unit topology graph according to the node identifier of the target data unit node, and determine the current value state of the data field corresponding to the target data unit node according to the node value domain attribute. The current value state includes an assigned value state and an unassigned value state.
[0037] Upon receiving an audit request, the system locates the target data unit node from the loaded table data unit topology graph based on the node identifier "NODE_AGE_001" in the request. It then extracts the node name attribute "age," the node type attribute "integer," and the node value range attribute "minimum 18, maximum 80" for this target data unit node. Next, it queries the actual data records of the table file unit to be audited to find the current value of the corresponding data field for this target data unit node. If the current value of the "age" field is empty, its current value status is determined to be "unassigned." If the current value of the "age" field is "35," its current value status is determined to be "assigned."
[0038] Step S133: Match the operation type identifier with a preset audit operation type mapping table to obtain the audit operation type corresponding to the operation type identifier. The audit operation type includes data field content confirmation operation, data field content modification operation, data field content questioning operation, and data field content rejection operation.
[0039] The operation type identifier "DATA_MODIFY" in the audit operation request is matched against a pre-defined audit operation type mapping table. This mapping table defines the conversion relationship from operation type identifiers to internal audit operation types. For example, "DATA_MODIFY" is mapped to "Data field content modification operation", "DATA_CONFIRM" is mapped to "Data field content confirmation operation", "DATA_QUERY" is mapped to "Data field content challenge operation", and "DATA_REJECT" is mapped to "Data field content rejection operation". After matching, the audit operation type is determined to be "Data field content modification operation".
[0040] Step S134: Obtain the audit permission level information corresponding to the collaborative audit entity from the entity permission database according to the operation execution entity identifier. The audit permission level information includes a list of all audit operation types authorized to be executed by the collaborative audit entity.
[0041] Based on the operation execution entity identifier "USER_DR_ZHANG" in the audit operation request, query the entity permission database for the audit permission level information of the collaborative audit entity corresponding to this operation execution entity identifier. This audit permission level information is a data structure that contains a list of all audit operation types authorized to be executed by this collaborative audit entity. For example, the list of audit operation types contained in the audit permission level information is ["Data field content confirmation operation", "Data field content modification operation"].
[0042] Step S135: Perform permission matching calculations between the list of all audit operation types in the audit permission level information and the audit operation type to generate a permission matching result. The permission matching result is used to indicate whether the collaborative audit entity has the permission to execute the audit operation type.
[0043] The list of all audit operation types in the audit permission level information obtained in step S134 is compared with the audit operation types determined in step S133 to perform permission matching calculations. The entire list of audit operation types is traversed, checking if any element exists that matches the current audit operation type. The current audit operation type is "Data Field Content Modification Operation," and the list of audit operation types contains "Data Field Content Modification Operation," therefore the match is successful. A permission matching result is generated, indicating that the collaborative audit entity has the permission to perform the "Data Field Content Modification Operation."
[0044] Step S136: When the permission matching result indicates that the collaborative audit entity has the permission to perform the audit operation type on the target data unit node, an audit operation event is generated based on the node identifier of the target data unit node, the audit operation type, the operation execution entity identifier, and the operation timestamp, and an event sequence number is assigned to the audit operation event and stored in the audit operation event queue.
[0045] The permission matching result generated in step S135 indicates that the collaborative audit entity has the permission to perform a "data field content modification operation". An audit operation event is generated based on the target data unit node's node identifier "NODE_AGE_001", the audit operation type "data field content modification operation", the operation execution entity identifier "USER_DR_ZHANG", and the operation timestamp. A globally unique event sequence number, such as "EVT_0001", is assigned to this audit operation event. The generated audit operation event is stored in an audit operation event queue, which is used to sequentially process subsequent impact-spreading operations.
[0046] Step S137: When the permission matching result indicates that the collaborative audit entity does not have the permission to perform the audit operation type on the target data unit node, a permission denial response message is generated and the permission denial response message is returned to the collaborative audit terminal that sent the audit operation request.
[0047] In this embodiment, this step is not executed because the permission matching is successful. If the permission matching result of step S135 indicates that the collaborative audit entity does not have the permission to perform the "data field content modification operation", a permission denial response message is generated. The permission denial response message contains a denial reason code and is returned to the collaborative audit terminal that sent the audit operation request to indicate that the collaborative audit entity's operation has been rejected.
[0048] Step S138: After storing the audit operation event in the audit operation event queue, extract the event sequence number of the audit operation event from the audit operation event queue, establish an association between the event sequence number and the node identifier of the target data unit node, and store it in the operation history storage space. Determine the expected state of the data field corresponding to the target data unit node after the audit operation according to the audit operation type. The expected state and the audit operation type have a preset mapping relationship.
[0049] After storing the audit operation event in the audit operation event queue, the event sequence number "EVT_0001" is extracted from the queue. This event sequence number "EVT_0001" is then associated with the node identifier "NODE_AGE_001" of the target data unit node, and this association is stored in the operation history storage space for subsequent traceability. Based on the audit operation type "Data Field Content Modification Operation," the expected state of the data field corresponding to the target data unit node after the audit operation is determined. This expected state has a preset mapping relationship with the audit operation type; for example, the expected state for "Data Field Content Modification Operation" is "Modified and Awaiting Confirmation," and the expected state for "Data Field Content Confirmation Operation" is "Confirmed."
[0050] Step S139: Combine the node identifier of the target data unit node, the audit operation type, and the expected state into an audit operation event completion notification, and send the audit operation event completion notification to the collaborative audit terminal that subscribes to the status change of the target data unit node.
[0051] The node identifier "NODE_AGE_001" of the target data unit node, the audit operation type "Data Field Content Modification Operation", and the expected status "Modified and Awaiting Confirmation" are combined into an audit operation completion notification. This audit operation completion notification is sent to all collaborative audit terminals that have subscribed to the status changes of the target data unit node, so that the collaborative audit terminals can update the status display on the user interface in real time.
[0052] Step S140: Input the audit operation event into a preset constraint propagation analysis model, and use the constraint propagation analysis model to perform influence range diffusion processing on the target data unit node according to the data dependency edge to obtain the set of associated data unit nodes affected by the audit operation event.
[0053] After generating an audit operation event, the audit operation event is input into a preset constraint propagation analysis model to perform influence range diffusion processing in order to determine other data unit nodes affected by the audit operation event.
[0054] Step S141: Input the audit operation event into the event parsing module of the constraint propagation analysis model, and extract the node identifier and audit operation type of the target data unit node from the audit operation event through the event parsing module.
[0055] The audit operation event is input into the event parsing module of the constraint propagation analysis model. This event parsing module extracts the node identifier "NODE_AGE_001" of the target data unit node and the audit operation type "data field content modification operation" from the input audit operation event.
[0056] Step S142: Locate the corresponding target data unit node from the table data unit topology graph according to the node identifier of the target data unit node, and obtain all data dependency edges directly connected to the target data unit node as a first-level dependency edge set. Traverse each data dependency edge in the first-level dependency edge set, extract the corresponding constraint condition expression from the table constraint rule set according to the constraint expression reference identifier of the data dependency edge, and determine the adjacent data unit node associated with the data dependency edge according to the constraint condition expression.
[0057] Based on the extracted node identifier "NODE_AGE_001" of the target data unit node, locate the target data unit node from the table data unit topology graph. Obtain all data dependency edges directly connected to the target data unit node, as the first-level dependency edge set. Traverse each data dependency edge in the first-level dependency edge set. For each data dependency edge, extract the corresponding constraint condition expression from the table constraint rule set based on the constraint expression reference identifier of the data dependency edge. Then, determine the adjacent data unit nodes associated with the data dependency edge based on the constraint condition expression. For example, if there is a data dependency edge pointing from "NODE_AGE_001" to "NODE_AGE_GROUP_001", and its constraint condition expression is "age grouping" equals the group divided according to the "age" value, then the adjacent data unit node is the "age grouping" data unit node.
[0058] Step S143: Add the adjacent data unit node as a first-level influencing node to the candidate set of influencing nodes, and record the dependency path information between the first-level influencing node and the target data unit node. The dependency path information includes the node identifier of the first-level influencing node and the propagation weight value of the data dependency edge.
[0059] The adjacent data unit nodes determined in step S142 are added to the candidate set of influence nodes as first-level influence nodes. Simultaneously, the dependency path information between these first-level influence nodes and the target data unit node is recorded. This dependency path information includes the node identifier of the first-level influence node and the propagation weight value of the data dependency edge connecting the target data unit node and the first-level influence node.
[0060] Step S144: Take each of the candidate influential nodes in the set of influential nodes as the current diffusion node, perform recursive diffusion processing on each current diffusion node, obtain all data dependency edges directly connected to each current diffusion node as the set of secondary dependency edges, select data dependency edges from the set of secondary dependency edges whose dependency direction is from the current diffusion node to the adjacent node as the set of forward propagation dependency edges, and determine the corresponding secondary influential node according to each forward propagation dependency edge in the set of forward propagation dependency edges.
[0061] Each influencing node in the candidate set is designated as the current diffusion node, and recursive diffusion processing is performed on each current diffusion node. For each current diffusion node, all data dependency edges directly connected to it are obtained, forming a set of secondary dependency edges. From this set of secondary dependency edges, data dependency edges whose dependency direction is from the current diffusion node to its adjacent node are selected, and these data dependency edges are formed into a set of forward propagation dependency edges. Then, based on each forward propagation dependency edge in this set, the corresponding secondary influencing node is determined.
[0062] Step S145: Add the secondary impact node to the impact node candidate set, and update the dependency path information between the secondary impact node and the target data unit node. The dependency path information includes the aggregated result of the propagation weight values of all data dependency edges traversed from the target data unit node to the secondary impact node.
[0063] The secondary impact node determined in step S144 is added to the impact node candidate set. Simultaneously, the dependency path information between this secondary impact node and the target data unit node is updated. This dependency path information includes the aggregated result of the propagation weight values of all data dependency edges traversed from the target data unit node to the secondary impact node. This aggregation result is obtained by summing the propagation weight values of all data dependency edges along the path.
[0064] Step S146: Deduplicate all influencing nodes in the candidate set of influencing nodes to obtain a deduplicated candidate set of influencing nodes. Sort the influencing nodes in the candidate set of influencing nodes according to the cumulative propagation weight value of each influencing node in the dependency path information. Generate a sorted list of influencing nodes in descending order of the aggregated propagation weight value. Extract the influencing nodes in the sorted list whose aggregated propagation weight value is greater than a preset propagation threshold to generate a set of associated data unit nodes affected by the audit operation event.
[0065] After completing the recursive diffusion process, all influencing nodes in the candidate set are deduplicated to ensure that each influencing node appears only once, resulting in a deduplicated candidate set. Based on the accumulated propagation weight value of each influencing node in the dependency path information, the influencing nodes in the deduplicated candidate set are sorted, generating a sorted list of influencing nodes according to the aggregated propagation weight value from largest to smallest. A preset propagation threshold is set, and the sorted list of influencing nodes is traversed. Influencing nodes whose aggregated propagation weight value is greater than the preset propagation threshold are extracted, and these extracted influencing nodes form a set of associated data unit nodes affected by the audit operation event.
[0066] Step S150: Generate a corresponding file status driving instruction based on each associated data unit node in the associated data unit node set, and send the file status driving instruction to the collaborative audit terminal to trigger the collaborative audit operation on the data field corresponding to the associated data unit node.
[0067] After obtaining the set of associated data unit nodes, a corresponding file status driving instruction is generated based on each associated data unit node in the set, and the file status driving instruction is sent to the collaborative review terminal.
[0068] Step S151: Extract the node identifier of each associated data unit node from the set of associated data unit nodes, and obtain the node name attribute and node type attribute of each associated data unit node from the table data unit topology diagram based on the node identifier of each associated data unit node.
[0069] Extract the node identifier of each associated data unit node from the set of associated data unit nodes. For each associated data unit node's node identifier, obtain the corresponding node name attribute and node type attribute from the tabular data unit topology diagram. For example, for an associated data unit node with the node identifier "NODE_AGE_GROUP_001", its node name attribute is "age grouping" and its node type attribute is "string".
[0070] Step S152: Determine the review priority parameter of the data field corresponding to each associated data unit node based on the node type attribute of each associated data unit node. The review priority parameter is positively correlated with the criticality of the data field corresponding to the node type attribute in the clinical trial data table.
[0071] Based on the node type attribute of each associated data unit node, the review priority parameter for the corresponding data field is determined. This review priority parameter is positively correlated with the criticality of the data field corresponding to the node type attribute in the clinical trial data table. For example, if the node type attribute is "critical variable," the review priority parameter is set to a higher value, such as 100; if the node type attribute is "derived variable," the review priority parameter is set to a lower value, such as 50.
[0072] Step S153: Based on the node identifier of each associated data unit node, query the most recent audit operation record corresponding to each associated data unit node from the operation history storage space. The most recent audit operation record includes the operation execution entity identifier and operation timestamp of the most recent audit operation.
[0073] Based on the node identifier of each associated data unit node, query the most recent audit operation record corresponding to that associated data unit node from the operation history storage space. This most recent audit operation record contains the operation execution entity identifier and operation timestamp of the most recent audit operation. For example, for the node identifier "NODE_AGE_GROUP_001", the query finds that the operation execution entity identifier of its most recent audit operation is "USER_DR_LI", and the operation timestamp is "2023-10-27 10:00:00".
[0074] Step S154: Calculate the time interval parameter of each associated data unit node based on the operation timestamp in the most recent audit operation record and the current timestamp, and determine the timeliness weight value of each associated data unit node based on the time interval parameter. The timeliness weight value is negatively correlated with the time interval parameter.
[0075] Based on the operation timestamp in the most recent audit operation record and the current timestamp, a time interval parameter is calculated for each associated data unit node. This time interval parameter is the difference between the current timestamp and the operation timestamp. Then, a timeliness weight value is determined for each associated data unit node based on this time interval parameter. This timeliness weight value is negatively correlated with the time interval parameter. For example, the formula for calculating the timeliness weight value is defined as: the timeliness weight value equals the preset baseline weight value divided by the ratio of the time interval parameter to the time unit conversion constant. The larger the time interval parameter, the smaller the timeliness weight value.
[0076] Step S155: Based on the review priority parameter and timeliness weight value of each associated data unit node, calculate the review urgency score of each associated data unit node through predefined scoring rules, and sort all associated data unit nodes in the associated data unit node set in descending order according to the review urgency score to generate an associated data unit node processing sequence. Traverse each associated data unit node in the associated data unit node processing sequence, and generate a corresponding file status driving instruction according to the node identifier and node name attribute of each associated data unit node. The file status driving instruction includes the node identifier, node name attribute and review operation type suggestion information of the target associated data unit node.
[0077] Based on the review priority parameter and timeliness weight value of each associated data unit node, a review urgency score is calculated for each associated data unit node using a predefined scoring rule. This predefined scoring rule can be a weighted sum of the review priority parameter and the timeliness weight value. According to the calculated review urgency score, all associated data unit nodes in the associated data unit node set are sorted in descending order to generate a processing sequence. The higher the score, the earlier the node appears in the sequence. Each associated data unit node in the processing sequence is traversed, and a corresponding file status-driven instruction is generated based on its node identifier and node name attribute. This file status-driven instruction contains the node identifier, node name attribute, and review operation type suggestion information for the target associated data unit node. The review operation type suggestion information can be determined based on the node type attribute and historical review records. For example, for the "Age Grouping" node, it is suggested to perform a "Data Field Content Confirmation Operation".
[0078] Step S156: The generated file status driving instructions are sent to the collaborative review terminal in the order of the processing sequence of the associated data unit nodes. The file status driving instructions are used to instruct the collaborative review terminal to highlight the data fields corresponding to the target associated data unit node on the user interface.
[0079] The generated file status-driven instructions are sent sequentially to the collaborative review terminal according to the processing sequence of the associated data unit nodes. These file status-driven instructions instruct the collaborative review terminal to highlight the data fields corresponding to the target associated data unit node on the user interface, for example, by using highlighted borders or flashing icons, to guide the collaborative review entity to prioritize the review of these affected fields.
[0080] Step S157: After sending the file status driving instruction to the collaborative review terminal, receive the instruction reception confirmation message returned by the collaborative review terminal. The instruction reception confirmation message includes the instruction identifier and reception timestamp of the received file status driving instruction.
[0081] After sending the file status-driven instruction to the collaborative review terminal, the system receives an instruction reception confirmation message from the terminal. This confirmation message contains the instruction identifier and reception timestamp of the received file status-driven instruction, confirming that the collaborative review terminal has successfully received the instruction.
[0082] Step S158: Match the corresponding file status driving instruction from the sent file status driving instructions according to the instruction identifier in the instruction reception confirmation message, mark the successfully matched file status driving instruction as confirmed and store it in the instruction sending record storage space, calculate the time difference between the sending timestamp of the file status driving instruction and the receiving timestamp in the instruction reception confirmation message to obtain the instruction transmission delay parameter, and store the instruction transmission delay parameter as the status indicator of the collaborative review terminal in the terminal status monitoring database.
[0083] Based on the instruction identifier in the instruction reception confirmation message, the corresponding file status driving instruction is matched from the sent file status driving instructions. The successfully matched file status driving instruction is marked as confirmed and stored in the instruction sending record storage space for subsequent auditing. The time difference between the sending timestamp of the file status driving instruction and the receiving timestamp in the instruction reception confirmation message is calculated to obtain the instruction transmission delay parameter. This instruction transmission delay parameter is used as a status indicator of the collaborative audit terminal and stored in the terminal status monitoring database for monitoring the network health status of the collaborative audit terminal.
[0084] Step S161: Extract an unprocessed influence node from the candidate set of influence nodes as the current diffusion node, and assign a diffusion depth identifier to the current diffusion node. The initial value of the diffusion depth identifier is determined based on the number of data dependency edges contained in the dependency path between the current diffusion node and the target data unit node.
[0085] This step is a concrete implementation of step S144, which involves "taking each influence node in the candidate influence node set as the current diffusion node and performing recursive diffusion processing on each current diffusion node." One unprocessed influence node is extracted from the candidate influence node set and designated as the current diffusion node. A diffusion depth identifier is assigned to this current diffusion node, and the initial value of this identifier is determined based on the number of data dependency edges contained in the dependency path between the current diffusion node and the target data unit node. For example, if the dependency path contains two data dependency edges, the initial value of the diffusion depth identifier is 2.
[0086] Step S162: Based on the node identifier of the current diffusion node, obtain all data dependency edges directly connected to the current diffusion node from the table data unit topology graph, generate a full set of associated dependency edges related to the current diffusion node, filter out data dependency edges whose dependency direction is from the current diffusion node to other data unit nodes as a forward propagation dependency edge candidate set from the full set of associated dependency edges, and filter out data dependency edges whose dependency direction is from other data unit nodes to the current diffusion node as a backward propagation dependency edge candidate set.
[0087] Based on the node identifier of the current diffusion node, all data dependency edges directly connected to the current diffusion node are obtained from the tabular data unit topology graph, generating a full set of dependency edges associated with the current diffusion node. From this full set of dependency edges, data dependency edges whose dependency direction is from the current diffusion node to other data unit nodes are selected, and these data dependency edges are used as the candidate set of forward propagation dependency edges. Simultaneously, data dependency edges whose dependency direction is from other data unit nodes to the current diffusion node are selected, and these data dependency edges are used as the candidate set of backward propagation dependency edges.
[0088] Step S163: Add each forward propagation dependency edge in the candidate set of forward propagation dependency edges to the set of secondary dependency edges, and add each backward propagation dependency edge in the candidate set of backward propagation dependency edges to the set of secondary dependency edges. Traverse each secondary dependency edge in the set of secondary dependency edges, extract the corresponding secondary constraint condition expression from the set of table constraint rules according to the constraint expression reference identifier of each secondary dependency edge, and determine the adjacent nodes connected to the current diffusion node through the secondary dependency edge according to the secondary constraint condition expression. Take the determined adjacent nodes as secondary influence nodes, and generate a diffusion path record for each secondary influence node. The diffusion path record contains the edge identifier sequence of all data dependency edges traversed from the target data unit node to the secondary influence node and the propagation weight value of each data dependency edge.
[0089] Each forward propagation dependency edge in the candidate set of forward propagation dependencies is added to the secondary dependency edge set, and each backward propagation dependency edge in the candidate set of backward propagation dependencies is added to the secondary dependency edge set. Then, each secondary dependency edge in this set is traversed. For each secondary dependency edge, the corresponding secondary constraint condition expression is extracted from the table constraint rule set based on the constraint expression reference identifier of that secondary dependency edge. Based on the secondary constraint condition expression, the adjacent nodes connected to the current diffusion node through that secondary dependency edge are determined. These determined adjacent nodes are designated as secondary influence nodes. A diffusion path record is generated for each secondary influence node, containing a sequence of edge identifiers for all data dependency edges traversed from the target data unit node to the secondary influence node and the propagation weight value of each data dependency edge.
[0090] Step S164: Check whether the secondary impact node already exists in the impact node candidate set. If the secondary impact node does not exist in the impact node candidate set, add the secondary impact node to the impact node candidate set. If the secondary impact node already exists in the impact node candidate set, compare the aggregation result of the propagation weight value in the existing diffusion path record of the secondary impact node with the aggregation result of the propagation weight value in the newly generated diffusion path record.
[0091] Check whether the secondary impact node determined in step S163 already exists in the impact node candidate set. If the secondary impact node does not exist in the impact node candidate set, add the secondary impact node to the impact node candidate set. If the secondary impact node already exists in the impact node candidate set, compare the aggregated result of the propagation weight values in the existing diffusion path record of the secondary impact node with the aggregated result of the propagation weight values in the newly generated diffusion path record. This aggregation result is obtained by summing the propagation weight values of all data dependency edges on the path.
[0092] Step S165: When the aggregated result of the propagation weight value in the newly generated diffusion path record is greater than the aggregated result of the propagation weight value in the existing diffusion path record, the existing diffusion path record of the secondary affected node is replaced by the newly generated diffusion path record. After processing all secondary dependent edges of the current diffusion node, the current diffusion node is marked as processed, and the next unprocessed affected node is extracted from the candidate set of affected nodes as the new current diffusion node for iterative processing until there are no unprocessed affected nodes in the candidate set of affected nodes.
[0093] When the aggregated propagation weight values in the newly generated propagation path record are greater than the aggregated propagation weight values in the existing propagation path record, the existing propagation path record of the secondary affected node is replaced with the newly generated propagation path record. After processing all secondary dependent edges of the current propagation node, the current propagation node is marked as processed. Then, the next unprocessed affected node is extracted from the candidate set of affected nodes as the new current propagation node, and steps S161 to S165 are repeated until there are no unprocessed affected nodes in the candidate set of affected nodes.
[0094] Step S171: Extract the currently pending associated data unit node from the associated data unit node processing sequence, and obtain the node identifier and node name attribute of the current associated data unit node.
[0095] This step is a specific implementation of "traversing each associated data unit node in the associated data unit node processing sequence" in step S155. It extracts the currently pending associated data unit node from the associated data unit node processing sequence and obtains the node identifier and node name attribute of that current associated data unit node.
[0096] Step S172: Obtain the node type attribute and node value domain attribute of the current associated data unit node from the table data unit topology graph according to the node identifier of the current associated data unit node, and determine the table area identifier to which the data field corresponding to the current associated data unit node belongs according to the node type attribute.
[0097] Based on the node identifier of the current associated data unit node, the node type attribute and node value range attribute of the current associated data unit node are obtained from the table data unit topology graph. Then, based on the node type attribute, the table region identifier to which the data field corresponding to the current associated data unit node belongs is determined. For example, if the node type attribute is "demographic characteristics", then its table region identifier is "SECTION_DEMOGRAPHICS".
[0098] Step S173: Based on the node identifier of the current associated data unit node, query the historical audit operation statistics information corresponding to the current associated data unit node from the operation history storage space. The historical audit operation statistics information includes the number of times each type of audit operation was performed on the current associated data unit node and the most recent operation timestamp.
[0099] Based on the node identifier of the currently associated data unit node, query the historical audit operation statistics corresponding to that node from the operation history storage space. These statistics include the number of times each type of audit operation was performed on the currently associated data unit node and the most recent operation timestamp. For example, for the node identifier "NODE_AGE_GROUP_001", its historical audit operation statistics might include: "Data field content challenge operation" was performed 2 times, with the most recent operation timestamp being "2023-10-26 15:30:00"; "Data field content confirmation operation" was performed 1 time, with the most recent operation timestamp being "2023-10-25 09:15:00".
[0100] Step S174: Based on the number of operations for each type of audit operation in the historical audit operation statistics, calculate the audit dispute level parameter of the current associated data unit node using predefined statistical rules. The audit dispute level parameter is used to characterize the degree of difference in the distribution of the number of operations for different types of audit operations.
[0101] Based on the number of operations for each type of review operation in historical review operation statistics, a review dispute level parameter for the current associated data unit node is calculated using predefined statistical rules. This review dispute level parameter characterizes the degree of difference in the distribution of operation counts for different types of review operations. For example, the variance or information entropy of the number of operations for each type can be calculated as the review dispute level parameter. The more dispersed the distribution of operation counts, the higher the dispute level parameter.
[0102] Step S175: Combine the node identifier, node name attribute, table area identifier, and audit dispute level parameter of the current associated data unit node into the instruction payload data of the file status driving instruction.
[0103] The node identifier, node name attribute, table area identifier, and review dispute level parameter of the currently associated data unit node are combined to form the instruction payload data of the file status-driven instruction. This instruction payload data contains all the context information required by the collaborative review terminal.
[0104] Step S176: Determine the sending priority parameter of the file status driving instruction based on the sorting position of the current associated data unit node in the associated data unit node processing sequence. The sending priority parameter is positively correlated with the sorting position, and the earlier the sorting position, the higher the sending priority parameter.
[0105] The sending priority parameter of the file status-driven instruction is determined based on the current sorting position of the associated data unit node in the associated data unit node processing sequence. This sending priority parameter is positively correlated with the sorting position; the earlier the sorting position, i.e., the higher the urgency score of the review, the higher the sending priority parameter.
[0106] Step S177: Encapsulate the instruction payload data and the transmission priority parameter into a file status driving instruction, and assign a unique instruction identifier and generation timestamp to the file status driving instruction. Insert the encapsulated file status driving instruction into the corresponding priority position of the instruction transmission queue according to the transmission priority parameter. The instruction transmission queue organizes and stores the file status driving instructions to be sent in descending order of the transmission priority parameter.
[0107] The instruction payload data generated in step S175 and the transmission priority parameters determined in step S176 are encapsulated into a complete file status driving instruction. A unique instruction identifier and generation timestamp are assigned to this file status driving instruction. Then, the encapsulated file status driving instruction is inserted into the corresponding priority position of the instruction transmission queue according to its transmission priority parameters. This instruction transmission queue is a priority queue, organizing and storing the file status driving instructions to be transmitted in descending order of transmission priority parameters.
[0108] Step S178: Extract the file status driving instruction with the highest sending priority parameter from the head of the instruction sending queue as the current sending instruction, and send the current sending instruction to the collaborative review terminal. After the current sending instruction is sent, remove the current sending instruction from the instruction sending queue, and record the instruction identifier and the actual sending timestamp of the current sending instruction.
[0109] Extract the file status-driven instruction with the highest priority parameter from the head of the instruction sending queue as the current sending instruction. Send this current sending instruction to the collaborative review terminal. After the current sending instruction is sent, remove it from the instruction sending queue and record its instruction identifier and actual sending timestamp for subsequent instruction status tracking.
[0110] Step S181: Obtain the node identifier of each associated data unit node in the associated data unit node set, and obtain the hierarchical label information of each associated data unit node from the table data unit topology diagram according to the node identifier of each associated data unit node. Based on the hierarchical label information of each associated data unit node, group the associated data unit nodes in the associated data unit node set according to their respective hierarchical levels to generate a hierarchical grouped set of associated data unit nodes.
[0111] After generating the set of associated data unit nodes affected by the audit operation event in step S146, further analysis and processing are performed. The node identifier of each associated data unit node in this set is obtained. Based on the node identifier of each associated data unit node, the hierarchical labeling information of each associated data unit node is obtained from the tabular data unit topology diagram. Based on this hierarchical labeling information, the associated data unit nodes in the set are grouped according to their respective hierarchical levels (root node level, intermediate node level, leaf node level), generating a hierarchically divided set of associated data unit node groups.
[0112] Step S182: Extract the related data unit nodes with the root node layer as the root node influence group from the hierarchically divided related data unit node group set as the root node influence group, and extract the related data unit nodes with the leaf node layer as the leaf node influence group. Obtain the out-degree value of the related data unit node of each root node influence group from the table data unit topology graph according to the node identifier of each related data unit node in the root node influence group, and use the out-degree value as the branch influence range parameter of each related data unit node in the root node influence group. Use the in-degree value of the related data unit node as the convergence influence degree parameter of the related data unit node in each leaf node influence group, and determine the convergence influence degree parameter of each related data unit node according to the in-degree value of the related data unit node.
[0113] From the hierarchically grouped set of related data unit nodes, extract the related data unit nodes with hierarchical labeling information at the root node level, as the root node influence group. Extract the related data unit nodes with hierarchical labeling information at the leaf node level, as the leaf node influence group. For each related data unit node in the root node influence group, obtain its out-degree value from the tabular data unit topology graph based on its node identifier, and use this out-degree value as the branch influence range parameter for that related data unit node. The larger the out-degree value, the more branches that the related data unit node in the root node influence group can influence. For each related data unit node in the leaf node influence group, obtain its in-degree value from the tabular data unit topology graph based on its node identifier, and use this in-degree value as the convergence influence parameter for that related data unit node. The larger the in-degree value, the more constraints converge to the related data unit node in the leaf node influence group.
[0114] Step S183: Mark the associated data unit nodes in the root node influence group whose branch influence range parameter is greater than the preset branch range threshold as key root node influence units, and mark the associated data unit nodes in the leaf node influence group whose convergence influence degree parameter is greater than the preset convergence degree threshold as key leaf node influence units.
[0115] Set a preset branch range threshold and a preset convergence threshold. Nodes in the root node influence group whose branch influence range parameter exceeds the preset branch range threshold are marked as key root node influence units. Nodes in the leaf node influence group whose convergence influence parameter exceeds the preset convergence threshold are marked as key leaf node influence units. These key influence units represent nodes that occupy a core or convergent position in the influence diffusion.
[0116] Step S184: Generate a list of key impact node identifiers based on the key root node impact unit and the key leaf node impact unit, and then store the list of key impact node identifiers in the key impact record storage space after establishing an association between the key impact node identifier list and the event sequence number of the audit operation event.
[0117] Collect the node identifiers of all critical root node and critical leaf node affected units marked in step S183 to generate a critical affected node identifier list. Establish a relationship between this critical affected node identifier list and the event sequence number "EVT_0001" of the audit operation event, and store this relationship in the critical affected record storage space for subsequent critical node tracking.
[0118] Step S185: Extract the data dependency edge information corresponding to each key impact node from the table data unit topology graph according to the key impact node identifier list, and generate a complete impact path description set from the target data unit node to each key impact node according to the data dependency edge information. Combine the complete impact path description set with the event sequence number of the audit operation event to form an impact analysis report, and send the impact analysis report to the collaborative audit terminal that initiated the audit operation event.
[0119] Based on the list of key impact node identifiers, extract the data dependency edge information corresponding to each key impact node from the tabular data unit topology graph. Using this data dependency edge information and previously recorded dependency path information, generate a complete set of impact path descriptions from the target data unit node "NODE_AGE_001" to each key impact node. This set of descriptions details all data dependency edges along the path. Combine this complete set of impact path descriptions with the event sequence number "EVT_0001" of the audit operation event to form an impact analysis report. Send this impact analysis report to the collaborative audit terminal where the collaborative audit entity that initiated the audit operation event is located to help the collaborative audit entity understand the comprehensive impact that its operation may have.
[0120] Step S191: Receive a collaborative audit completion message returned by the collaborative audit terminal for the file status-driven instruction. The collaborative audit completion message includes the node identifier of the associated data unit node that has completed the audit, the operation execution entity identifier that has completed the audit, and the operation completion timestamp.
[0121] After sending the file status-driven command to the collaborative audit terminal and triggering the collaborative audit operation, the subsequent status update operation is performed. The collaborative audit completion message returned by the collaborative audit terminal for the file status-driven command is received. This collaborative audit completion message includes the node identifier of the associated data unit node that has completed the audit, the identifier of the entity executing the completed audit operation, and the timestamp of the completed audit operation.
[0122] Step S192: Locate the corresponding data unit node that has completed the review from the table data unit topology graph according to the node identifier in the collaborative review completion message, and obtain the in-degree and out-degree values of the data unit node that has completed the review.
[0123] Based on the node identifier in the collaborative review completion message, locate the corresponding data unit node that has completed the review from the tabular data unit topology graph. Obtain the in-degree and out-degree values of the data unit node that has completed the review.
[0124] Step S193: When the in-degree value of the data unit node that has completed the review is 0, mark the data unit node that has completed the review as the root node reviewed, and associate the root node reviewed status with the operation execution entity identifier that has completed the review; when the out-degree value of the data unit node that has completed the review is 0, mark the data unit node that has completed the review as the leaf node reviewed, and associate the leaf node reviewed status with the operation execution entity identifier that has completed the review; when both the in-degree and out-degree values of the data unit node that has completed the review are not 0, mark the data unit node that has completed the review as the intermediate node reviewed, and associate the intermediate node reviewed status with the operation execution entity identifier that has completed the review.
[0125] Based on the in-degree and out-degree values of the data unit nodes that have completed the review, determine their topological role. If the in-degree value is 0, mark the reviewed data unit node as a root node with a reviewed status, and associate this root node's reviewed status with the operation execution entity identifier. If the out-degree value is 0, mark the reviewed data unit node as a leaf node with a reviewed status, and associate this leaf node's reviewed status with the operation execution entity identifier. If neither the in-degree nor the out-degree value is 0, mark the reviewed data unit node as an intermediate node with a reviewed status, and associate this intermediate node's reviewed status with the operation execution entity identifier.
[0126] Step S194: Based on the node identifier of the data unit node that has been reviewed, query the key impact record storage space to see if there is a list of key impact node identifiers containing the node identifier. If it exists, mark the event sequence number of the review operation event corresponding to the list of key impact node identifiers as responded.
[0127] Based on the node identifier of the data unit node that has completed the review, query the critical impact record storage space to see if a list of critical impact node identifiers containing that node identifier exists. If it exists, it means that the node is a critical impact node for a certain review operation event. Mark the event sequence number of the review operation event corresponding to the list of critical impact node identifiers as a responded status to track the processing status of critical impacts.
[0128] Step S195: Statistically analyze the distribution information of the reviewed status of all data unit nodes in the table data unit topology diagram to which the reviewed data unit node belongs, and generate a reviewed node coverage parameter and an unreviewed node identifier list; when the reviewed node coverage parameter exceeds a preset completion threshold, generate an unreviewed node reminder instruction based on the unreviewed node identifier list, and send the unreviewed node reminder instruction to the collaborative review terminal.
[0129] This process involves statistically analyzing the distribution of the reviewed status of all data unit nodes in the tabular data unit topology diagram to which the reviewed data unit nodes belong. The ratio of the number of reviewed nodes to the total number of nodes is calculated to generate a reviewed node coverage parameter. Simultaneously, the node identifiers of all data unit nodes whose status is not "reviewed" are listed, generating an unreviewed node identifier list. When the reviewed node coverage parameter exceeds a preset completion threshold, such as 90%, an unreviewed node reminder instruction is generated based on the unreviewed node identifier list and sent to the collaborative review terminal, reminding the collaborative review entity that a small number of nodes remain unreviewed.
[0130] Step S196: Combine the node identifier, audited status flag, operation execution entity identifier, and operation completion timestamp of the data unit node that has completed the audit into an audit progress synchronization message, and broadcast the audit progress synchronization message to all collaborative audit terminals participating in the collaborative audit.
[0131] The node identifier of the data unit node that has completed the review, the review status flag, the identifier of the operation execution entity that has completed the review, and the operation completion timestamp are combined into a review progress synchronization message. This review progress synchronization message is broadcast to all collaborative review terminals participating in the collaborative review, so that all collaborative review entities can understand the overall review progress in real time and maintain visibility. Figure 1 To.
[0132] For example, after step S140, the method further includes: step S210: obtaining the node value domain attribute of each associated data unit node from the table data unit topology diagram according to the node identifier of each associated data unit node in the associated data unit node set, and determining the value domain constraint type of each associated data unit node according to the node value domain attribute of each associated data unit node.
[0133] After generating the set of associated data unit nodes affected by the audit operation event in step S146, value range constraint analysis of the associated data unit nodes is performed. Based on the node identifier of each associated data unit node in the set, the node value range attribute of each associated data unit node is obtained from the tabular data unit topology diagram. Based on the node value range attribute, the value range constraint type of each associated data unit node is determined, such as "numerical range constraint", "enumerated value constraint", "length constraint", or "format constraint".
[0134] Step S220: Extract the constraint expressions associated with each associated data unit node from the table constraint rule set according to the value range constraint type of each associated data unit node, and use them as the node associated constraint expression set.
[0135] Based on the value domain constraint type of each associated data unit node, extract all constraint expressions associated with that associated data unit node from the set of table constraint rules, and use these constraint expressions as the set of node association constraint expressions for that associated data unit node.
[0136] Step S230: Parse each node association constraint expression in the set of node association constraint expressions, extract the operator type identifier and operand identifier in each node association constraint expression, generate a set of constraint expression parsing results, and determine the allowable value change range of each associated data unit node after being affected by the audit operation event based on the set of constraint expression parsing results. The allowable value change range is determined jointly based on the audit operation type in the audit operation event and the node value domain attribute of each associated data unit node.
[0137] For each associated data unit node, each constraint expression in the node association constraint expression set is parsed, extracting the operator type identifier and operand identifier from each constraint expression to generate a constraint expression parsing result set. Based on this constraint expression parsing result set, and in conjunction with the audit operation type in the audit operation event (e.g., "data field content modification operation") and the node value range attribute of each associated data unit node, the allowed value change range of each associated data unit node after being affected by the audit operation event is determined. For example, if the associated data unit node is "systolic blood pressure," its value range constraint is "90 to 180," and there is a logical relationship constraint with "diastolic blood pressure" that "diastolic blood pressure is less than systolic blood pressure," then when "systolic blood pressure" is modified, the allowed value change range of "diastolic blood pressure" will be dynamically adjusted to "less than the new systolic blood pressure value."
[0138] Step S240: Compare the allowed value variation range of each associated data unit node with the current value of the data field corresponding to each associated data unit node to generate a value compliance judgment result for each associated data unit node. When the value compliance judgment result indicates that the degree of matching between the allowed value variation range of the associated data unit node and the current value is lower than a preset matching threshold, mark the associated data unit node as a potential conflict node and generate a conflict node identifier list.
[0139] The allowed value range for each associated data unit node is compared with the current value of the corresponding data field. It is determined whether the current value falls within the allowed range; if it falls entirely within the range, the matching degree is 100%. If it partially falls within the range or completely falls outside the range, the matching degree is reduced. A preset matching threshold is set, for example, 80%. When the calculated matching degree is lower than this preset threshold, the associated data unit node is marked as a potential conflict node. All node identifiers marked as potential conflict nodes are collected to generate a conflict node identifier list.
[0140] Step S250: Extract the data dependency edge information corresponding to each conflict node from the table data unit topology graph according to the conflict node identifier list, and determine the conflict propagation path between each conflict node and the target data unit node according to the data dependency edge information.
[0141] Based on the generated list of conflict node identifiers, the data dependency edge information corresponding to each conflict node is extracted from the tabular data unit topology graph. Using this data dependency edge information, combined with the previously recorded dependency path information, the conflict propagation path between each conflict node and the target data unit node is determined; that is, the path from the target data unit node to the conflict node through a series of data dependency edges.
[0142] Step S260: Combine the list of conflict node identifiers and the conflict propagation path corresponding to each conflict node into conflict warning information, and send the conflict warning information to the collaborative audit terminal that executes the audit operation event. Receive the conflict handling decision returned by the collaborative audit terminal regarding the conflict warning information. The conflict handling decision includes one of the following: conflict ignore decision, conflict coverage decision, and conflict rollback decision.
[0143] The list of conflict node identifiers and the conflict propagation path corresponding to each conflict node are combined to form a conflict warning message. This conflict warning message is sent to the collaborative auditing terminal that performed the auditing operation to alert the collaborative auditing entity that its operation may cause data conflicts. The collaborative auditing terminal returns a conflict handling decision for the conflict warning message. This conflict handling decision can be a "conflict ignore decision" (meaning ignore the conflict and continue the operation), a "conflict overwrite decision" (meaning overwrite the existing value with the new value and enforce the operation), or a "conflict rollback decision" (meaning abandon the operation and roll back to the previous state).
[0144] Step S270: Update the status information of the corresponding associated data unit node in the associated data unit node set according to the conflict handling decision, and associate the updated status information with the event sequence number of the audit operation event.
[0145] Based on the received conflict handling decision, update the status information of the corresponding associated data unit node in the associated data unit node set. For example, if the decision is "conflict overwrite decision," the current value of the associated data unit node is forcibly updated to a value within the allowed range of value changes, and its status is marked as "forced update." If the decision is "conflict ignore decision," its current value is retained, but its status is marked as "conflict ignore." If the decision is "conflict rollback decision," the impact of this audit operation event is canceled. The updated status information is associated with the event sequence number "EVT_0001" of the audit operation event and stored for subsequent traceability.
[0146] For example, step S310: Obtain all historical audit operation events in the historical audit operation event queue. Each historical audit operation event contains the historical node identifier of the historical target data unit node, the historical audit operation type, the historical operation execution entity identifier, and the historical operation timestamp.
[0147] This embodiment also includes an additional method for mining review patterns. First, all historical review operation events in the historical review operation event queue are retrieved. Each historical review operation event contains a historical node identifier of the historical target data unit node, a historical review operation type, a historical operation execution entity identifier, and a historical operation timestamp.
[0148] Step S320: Extract the set of adjacent data dependency edges of each historical target data unit node at the time of occurrence of the historical audit operation event from the table data unit topology graph according to the historical node identifier of the historical target data unit node, and extract the corresponding historical constraint condition expression from the table constraint rule set according to the constraint expression reference identifier of each adjacent data dependency edge in the set of adjacent data dependency edges. Convert each historical constraint condition expression into a historical constraint directed graph structure. The historical constraint directed graph structure has data unit nodes as vertices and data dependency edges as directed edges, and retains the propagation weight value of each data dependency edge.
[0149] For each historical audit operation event, based on the historical node identifier of its historical target data unit node, the set of adjacent data dependency edges of that historical target data unit node at the time the historical audit operation event occurred is extracted from the tabular data unit topology graph. Based on the constraint expression reference identifier of each adjacent data dependency edge in this set, the corresponding historical constraint condition expression is extracted from the tabular constraint rule set. Each historical constraint condition expression is converted into a historical constraint directed graph structure. This historical constraint directed graph structure uses data unit nodes as vertices and data dependency edges as directed edges, retaining the propagation weight value of each data dependency edge.
[0150] Step S330: Locate the historical node identifier of the historical target data unit node corresponding to each historical audit operation event as the historical trigger source node in the historical constraint directed graph structure, and extract all historical reachable nodes that can be reached from the historical trigger source node along the data dependency edge direction to generate a historical impact diffusion subgraph corresponding to each historical audit operation event. The historical impact diffusion subgraph includes the historical trigger source node, all historical reachable nodes, and all data dependency edges connecting these nodes.
[0151] For each historical review operation event, the historical node identifier of its historical target data unit node is located as the historical trigger source node in its corresponding historical constrained directed graph structure. Then, a graph traversal algorithm is executed to extract all historically reachable nodes that can be reached from the historical trigger source node along the data dependency edge directions. The historical trigger source node, all historically reachable nodes, and all data dependency edges connecting these nodes are combined to generate the historical impact diffusion subgraph corresponding to the historical review operation event.
[0152] Step S340: Input the historical impact diffusion subgraph corresponding to each historical review operation event into the subgraph encoding layer of the review mode mining network. Through the subgraph encoding layer, perform node feature encoding processing on each data unit node in each historical impact diffusion subgraph to obtain a node feature encoding vector. The node feature encoding processing generates the node feature encoding vector according to the node type attribute and node value domain attribute of the data unit node.
[0153] Each historical impact diffusion subgraph corresponding to a historical review operation event is input into a pre-trained review pattern mining network. This network includes a subgraph encoding layer. This layer performs node feature encoding on each data unit node in each historical impact diffusion subgraph. Based on the node's type and value range attributes, this node feature encoding generates a fixed-dimensional node feature encoding vector by searching a pre-defined embedding matrix. For example, the node type attribute "integer" corresponds to one embedding vector, and the node value range attribute "minimum 18, maximum 80" corresponds to another. These two vectors are concatenated to form the node's feature encoding vector.
[0154] Step S350: The edge feature encoding vector is obtained by performing edge feature encoding on each data dependency edge in each historical impact diffusion subgraph through the subgraph encoding layer, and graph-level pooling is performed on the entire historical impact diffusion subgraph. The feature encoding vectors of all nodes and all edge feature encoding vectors in each historical impact diffusion subgraph are aggregated to generate the subgraph structure encoding vector corresponding to each historical review operation event. The edge feature encoding process generates the edge feature encoding vector according to the propagation weight value and dependency type attribute of the data dependency edge.
[0155] This subgraph encoding layer simultaneously performs edge feature encoding on each data dependency edge in each historical influence diffusion subgraph. This edge feature encoding process generates a fixed-dimensional edge feature encoding vector by looking up another pre-defined embedding matrix, based on the propagation weight value and dependency type attribute of the data dependency edge. Then, the subgraph encoding layer performs graph-level pooling on the entire historical influence diffusion subgraph, for example, average pooling of the feature encoding vectors of all nodes and summation pooling of the feature encoding vectors of all edges. Finally, the pooled node vectors and edge vectors are concatenated to generate a subgraph structure encoding vector representing the subgraph structure.
[0156] Step S360: Input the historical review operation type and subgraph structure encoding vector corresponding to each historical review operation event into the pattern generation layer of the review pattern mining network. The pattern generation layer performs latent space mapping processing on the subgraph structure encoding vector through a variational autoencoder to obtain the pattern distribution parameters of each historical review operation event in the latent space. The pattern distribution parameters include a mean vector and a variance vector.
[0157] The historical review operation type and subgraph structure encoding vector corresponding to each historical review operation event are input into the pattern generation layer of the review pattern mining network. This pattern generation layer contains a variational autoencoder. The variational autoencoder encodes the subgraph structure encoding vector and maps it to a low-dimensional latent space to obtain the pattern distribution parameters of each historical review operation event in the latent space. These pattern distribution parameters contain a mean vector and a variance vector.
[0158] Step S370: Perform cluster analysis on the historical review operation events according to the pattern distribution parameters of each historical review operation event in the latent space to obtain multiple review pattern cluster centers. Each review pattern cluster center corresponds to an influence diffusion subgraph structure type. Store the combination of each review pattern cluster center and the corresponding historical review operation type as a review pattern template.
[0159] Based on the pattern distribution parameters (mean vector) of each historical review operation event in the latent space, cluster analysis is performed on the above events, for example, using the K-Means algorithm. After cluster analysis, multiple review pattern cluster centers are obtained. Each review pattern cluster center corresponds to an influence diffusion subgraph structure type. For each cluster, the historical review operation types of all historical review operation events within that cluster are counted, and the review operation type with the highest frequency is selected as the associated review operation type of that cluster center. The combination of each review pattern cluster center and its associated review operation type is stored as a review pattern template.
[0160] Step S380: In response to a newly received audit operation event, extract the node identifier of the new target data unit node and the new audit operation type from the newly received audit operation event. Based on the node identifier of the new target data unit node, extract all new reachable nodes that can be reached along the data dependency edge direction with the new target data unit node as the trigger source node from the table data unit topology graph. Generate a new impact diffusion subgraph corresponding to the new audit operation event. Input the new impact diffusion subgraph into the subgraph encoding layer of the audit pattern mining network. Perform node feature encoding, edge feature encoding, and graph-level pooling processing on the new impact diffusion subgraph to generate a new subgraph structure encoding vector corresponding to the new impact diffusion subgraph. Perform similarity calculation processing between the new subgraph structure encoding vector and each audit pattern cluster center in the audit pattern template to obtain the target audit pattern cluster center with the highest matching degree with the new impact diffusion subgraph structure, and extract the target historical audit operation type corresponding to the target audit pattern cluster center.
[0161] When a new audit operation event is received, the node identifier of the new target data unit node and the new audit operation type are extracted from the new audit operation event. Based on the node identifier of the new target data unit node, all new reachable nodes that can be reached along the data dependency edge direction with the triggering source node are extracted from the tabular data unit topology graph, generating a new impact diffusion subgraph corresponding to the new audit operation event. This new impact diffusion subgraph is input into the subgraph encoding layer of the audit pattern mining network, and the same node feature encoding, edge feature encoding, and graph-level pooling processing as in steps S340 and S350 are performed to generate a new subgraph structure encoding vector corresponding to the new impact diffusion subgraph. The similarity (e.g., Euclidean distance or cosine similarity) between this new subgraph structure encoding vector and each audit pattern cluster center stored in step S370 is calculated. The target audit pattern cluster center with the highest similarity (i.e., the highest matching degree) is found, and the target historical audit operation type corresponding to this target audit pattern cluster center is extracted.
[0162] Step S390: Compare and analyze the target historical review operation type with the new review operation type. When the target historical review operation type is inconsistent with the new review operation type, generate a review operation deviation warning signal, and send the review operation deviation warning signal to the preset review supervision terminal after associating it with the new impact diffusion sub-graph.
[0163] The extracted historical audit operation types are compared and analyzed with the new audit operation types in new audit operation events. If they are inconsistent, it indicates that the current audit entity's operation mode deviates from the common operation mode under similar historical structures. In this case, an audit operation deviation warning signal is generated. After associating the audit operation deviation warning signal with the new impact diffusion subgraph, it is sent to a preset audit monitoring terminal (e.g., the project manager's terminal) to remind supervisors of possible abnormal operations or operation modes that require attention.
[0164] For example, step S410: obtain the event sequence number of the ongoing review operation event, and extract the corresponding key impact node identifier list and complete impact path description set from the key impact record storage space according to the event sequence number of the ongoing review operation event.
[0165] This embodiment also includes an additional method for optimizing audit task allocation. First, the event sequence number of an ongoing audit operation is obtained, for example, "EVT_0001". Based on the event sequence number "EVT_0001", a list of key impact node identifiers and a complete set of impact path descriptions associated with the event sequence number are extracted from the previously stored key impact record storage space. The list of key impact node identifiers contains node identifiers of root and leaf impact units marked as key during the impact diffusion process, starting from the target data unit node, such as "NODE_AGE_GROUP_001" and "NODE_BMI_001". The complete set of impact path descriptions records in detail the complete path from the target data unit node "NODE_AGE_001" to these key impact nodes, including the edge identifier sequence of all data dependency edges traversed on the path and the propagation weight value of each data dependency edge.
[0166] Step S420: Obtain the node type attribute and node value range attribute of each key impact node from the table data unit topology graph according to the node identifier of each key impact node in the key impact node identifier list, and determine the review complexity parameter of each key impact node according to the node type attribute and node value range attribute. The review complexity parameter is positively correlated with the in-degree value, out-degree value and the breadth of the value range of the node value range attribute of the key impact node.
[0167] For each critically influential node in the list of critically influential node identifiers, its node type attribute and node value range attribute are obtained from the topology graph of the tabular data unit based on its node identifier. Then, based on these attributes and combined with the node's in-degree and out-degree values in the topology graph, the review complexity parameter of the critically influential node is calculated. This review complexity parameter is positively correlated with the breadth of the in-degree, out-degree, and node value range attributes. For example, if a critically influential node has an in-degree of 3, an out-degree of 5, and its node value range attribute is a continuous interval with a wide range of values, the review complexity parameter calculated using a predefined weighted summation formula will be high; conversely, if both the in-degree and out-degree values are 0, and the node value range attribute is an enumeration type with two fixed values, the review complexity parameter will be low.
[0168] Step S430: Input each complete impact path description in the complete impact path description set into the routing graph construction module of the audit path planning network. The routing graph construction module constructs a weighted audit route directed graph from the target data unit node to each key impact node based on the edge identifier sequence and propagation weight value of the data dependency edge in each complete impact path description. The weight value of each directed edge in the weighted audit route directed graph is the propagation weight value of the corresponding data dependency edge.
[0169] Each complete influence path description extracted in step S410 is input into a pre-trained audit path planning network. This audit path planning network includes a routing graph construction module. This module parses each complete influence path description, extracting the edge identifier sequence of data dependency edges and the propagation weight value of each data dependency edge. Using this information, the routing graph construction module constructs a weighted audit routing directed graph from the target data unit node "NODE_AGE_001" to each key influence node. In this weighted audit routing directed graph, nodes represent data unit nodes, directed edges represent data dependencies, and the weight value of each directed edge is directly taken as the propagation weight value of the corresponding data dependency edge. This weighted audit routing directed graph clearly shows all the key nodes that need to be audited and their dependency paths.
[0170] Step S440: Input the weighted audit routing directed graph into the node state prediction module of the audit path planning network. The node state prediction module performs audit workload pre-calculation processing on each key impact node in the weighted audit routing directed graph through a graph attention network. The graph attention network calculates the expected audit time parameter of each key impact node based on the node type attribute, node value domain attribute, in-degree value, out-degree value, and propagation weight value of all incoming edges pointing to the key impact node. Input the weighted audit routing directed graph and the expected audit time parameter of each key impact node into the resource allocation module of the audit path planning network. The resource allocation module obtains the entity identifier list of currently idle collaborative audit entities and the historical audit efficiency parameter of each idle collaborative audit entity. The historical audit efficiency parameter includes the number of audits completed per unit time for each idle collaborative audit entity under different node type attributes.
[0171] The weighted audit routing directed graph constructed in step S430 is input into the node state prediction module of the audit path planning network. This node state prediction module contains a graph attention network. Taking the weighted audit routing directed graph as input, for each key impact node in the graph, the graph attention network aggregates the node's own features (node type attribute, node value range attribute, in-degree value, out-degree value) and the propagation weights of all incoming edges pointing to it. Through multiple layers of graph attention, it outputs the expected audit time parameter for each key impact node. This expected audit time parameter is a numerical value used to estimate the time required for a collaborative audit entity to complete the audit of that node. Then, the weighted audit routing directed graph and the calculated expected audit time parameter for each key impact node are input into the resource allocation module of the audit path planning network. Simultaneously, the resource allocation module retrieves the list of entity identifiers of currently idle collaborative audit entities from the entity state database, as well as the historical audit efficiency parameters for each idle collaborative audit entity. The historical review efficiency parameter is a multi-dimensional vector that records the average number of reviews that the collaborative review entity can complete per unit of time (e.g., per hour) for different node type attribute data fields over a period of time.
[0172] Step S450: The resource allocation module establishes an optimization objective function for the allocation of audit tasks based on the historical audit efficiency parameters of each idle collaborative audit entity and the expected audit time parameters of each key impact node. The optimization objective function for the allocation of audit tasks aims to minimize the variance of the expected audit time of all key impact nodes.
[0173] Based on the acquired information, the resource allocation module establishes an optimization objective function for task allocation. This objective function aims to minimize the variance of the estimated review time for all key impact nodes. Specifically, the module needs to determine how to assign each key impact node to an idle collaborative review entity. For any allocation scheme, the sum of the estimated review time parameters of all key impact nodes assigned to each collaborative review entity can be calculated as the entity's estimated total time. Then, the variance of the estimated total time for all entities with assigned tasks is calculated. The smaller the variance, the more balanced the task allocation and the higher the overall review efficiency. The optimization objective function aims to find the allocation scheme that minimizes this variance.
[0174] Step S460: Solve the objective function for optimizing the allocation of the audit task to obtain the optimal allocation mapping relationship between each key influence node and the idle state collaborative audit entity. In the optimal allocation mapping relationship, each key influence node is assigned to an idle state collaborative audit entity, and the key influence nodes assigned to the same idle state collaborative audit entity form a connected subgraph structure in the weighted audit routing directed graph.
[0175] The objective function for optimizing the allocation of review tasks is solved, for example using a combined optimization algorithm such as the Hungarian algorithm or a genetic algorithm. The solution process requires satisfying an additional constraint: all key impact nodes assigned to the same idle collaborative review entity must form a connected subgraph structure in the weighted review routing directed graph. In other words, all review tasks assigned to the same reviewer must be interconnected in the dependency graph. This helps reviewers understand the context and avoid information silos. After solving, the optimal allocation mapping relationship between each key impact node and the idle collaborative review entity is obtained.
[0176] Step S470: Generate a set of assigned tasks corresponding to each idle state collaborative audit entity according to the optimal allocation mapping relationship. Each set of assigned tasks includes the node identifier of the key impact node assigned to the idle state collaborative audit entity, the corresponding expected audit time parameter, and the audit execution order in the weighted audit routing directed graph. The audit execution order is determined according to the topological sorting result of the key impact node in the weighted audit routing directed graph.
[0177] Based on the optimal allocation mapping obtained in step S460, a corresponding allocation task set is generated for each idle collaborative audit entity. This allocation task set contains the node identifiers of all key impact nodes assigned to that entity, as well as the expected audit time parameters for each node. Furthermore, the set also contains the audit execution order of these key impact nodes. This audit execution order is obtained by topological sorting the weighted audit routing directed graph. Since the weighted audit routing directed graph is a directed acyclic graph, topological sorting ensures that during audit execution, a node is always processed before all nodes that depend on it, thus guaranteeing the correctness of dependencies. For example, for the "Body Mass Index" node, which depends on the "Weight" and "Height" nodes, topological sorting ensures that the audit order of the "Weight" and "Height" nodes precedes that of the "Body Mass Index" node.
[0178] Step S480: Encapsulate the set of assigned tasks corresponding to each idle collaborative audit entity into an audit task assignment instruction, and send the audit task assignment instruction to the collaborative audit terminal where the corresponding idle collaborative audit entity is located. After sending the audit task assignment instruction to the collaborative audit terminal, receive the audit progress update message returned by the collaborative audit terminal in real time. The audit progress update message includes the node identifier of the key impact node that has completed the audit and the actual audit time.
[0179] Each idle collaborative review entity's assigned task set is encapsulated into a single review task assignment instruction. This instruction is then sent to the collaborative review terminal where the idle entity resides. The collaborative review entity displays the assigned task list on its terminal and begins reviewing tasks in the specified order. During the review process, the collaborative review terminal returns real-time review progress updates. These updates include the node identifier of the critical impact node that has just completed its review, and the actual review time taken by the collaborative review entity to complete the review of that node.
[0180] Step S490: Update the historical review efficiency parameters of the corresponding idle collaborative review entity according to the actual review time parameters, and dynamically reallocate the unassigned key impact nodes according to the updated historical review efficiency parameters to generate a dynamically adjusted review task allocation instruction. The key impact nodes involved in the dynamically adjusted review task allocation instruction are key impact nodes in the weighted review routing directed graph that have not yet been marked as completed.
[0181] Whenever a review progress update message is received, the historical review efficiency parameter of the corresponding idle collaborative review entity is updated according to the actual review time parameter in the message. For example, if the entity originally completed 10 reviews per hour for "integer" type nodes, but it actually took 6 minutes to complete one node, its efficiency parameter is updated to 10 per hour. Then, it checks whether there are any key impact nodes in the weighted review routing graph that have not yet been marked as completed. If so, based on the latest historical review efficiency parameters of all collaborative review entities currently in an idle state (which may include entities that have completed tasks and entities that have not yet been assigned tasks), and the expected review time parameters of the remaining unassigned key impact nodes, steps S450 to S470 are re-executed for dynamic reallocation. This process generates a new, dynamically adjusted review task allocation instruction. The key impact nodes involved in this instruction are only those key impact nodes in the weighted review routing graph that have not yet been marked as completed. This dynamic reallocation process can be repeated until all key impact nodes are marked as completed, thereby achieving real-time optimization and scheduling of the entire review process.
[0182] Figure 2 This application illustrates a file-state-driven collaborative review system 100 for clinical trial data tables, comprising a processor 1001 and a memory 1003. The processor 1001 and memory 1003 are connected, for example, via a bus 1002. Optionally, the file-state-driven collaborative review system 100 may further include a transceiver 1004, which can be used for data interaction between this file-state-driven collaborative review system and other file-state-driven collaborative review systems for clinical trial data tables, such as sending and / or receiving data. It should be noted that in actual scheduling, the transceiver 1004 is not limited to one, and the structure of this file-state-driven collaborative review system 100 does not constitute a limitation on the embodiments of this application.
[0183] The memory 1003 is used to store program code for executing the embodiments of this application, and its execution is controlled by the processor 1001. The processor 1001 is used to execute the program code stored in the memory 1003 to implement the steps shown in the foregoing method embodiments.
[0184] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application, without departing from the technical concept of this application, also fall within the protection scope of the embodiments of this application.
Claims
1. A collaborative review method for clinical trial data tables based on file status, characterized in that, The method includes: Obtain an initial set of files corresponding to the clinical trial data tabular files. The initial set of files includes a tabular file unit to be reviewed with a unique file identifier and a set of metadata description information associated with the tabular file unit to be reviewed. The data unit structure of the table file unit to be reviewed is parsed based on the metadata description information set to generate a table data unit topology graph consisting of multiple data unit nodes. The data unit nodes form a one-to-one correspondence with the data fields in the table file unit to be reviewed. The data unit nodes are connected by data dependency edges, which represent the constraint relationship between data fields. In response to an audit operation performed by a collaborative audit entity on a target data unit node in the table data unit topology graph, an audit operation event is generated that includes the node identifier of the target data unit node and the audit operation type. The audit operation event is input into a preset constraint propagation analysis model. The constraint propagation analysis model performs influence range diffusion processing on the target data unit node according to the data dependency edge to obtain the set of associated data unit nodes affected by the audit operation event. Based on each associated data unit node in the set of associated data unit nodes, a corresponding file status driving instruction is generated, and the file status driving instruction is sent to the collaborative review terminal to trigger the collaborative review operation on the data field corresponding to the associated data unit node.
2. The collaborative review method for clinical trial data tables based on file state-driven approach according to claim 1, characterized in that, The step of parsing the data unit structure of the table file unit to be reviewed based on the metadata description information set to generate a table data unit topology diagram composed of multiple data unit nodes includes: Parse the table structure definition information in the metadata description information set, and extract the data field name set and data field type set from the table structure definition information. Each data field name in the data field name set corresponds to a data field in the table file unit to be reviewed, and each data field type in the data field type set forms a one-to-one correspondence with the data field name in the data field name set. Based on the data field names in the data field name set and the data field types in the data field type set, a corresponding data unit node is generated for each data field name. The data unit node includes a node identifier, a node name attribute, a node type attribute, and a node value range attribute. The node name attribute takes the value of the corresponding data field name, the node type attribute takes the value of the corresponding data field type, and the node value range attribute extracts the corresponding data field value range definition from the metadata description information set. Parse the set of table constraint rules in the set of metadata description information, and extract constraint condition expressions from the set of table constraint rules. The constraint condition expressions define the calculation relationship or logical association relationship between two or more data fields. The constraint condition expressions include left operand identifier, right operand identifier and operator type identifier. Based on the constraint expression, the data unit nodes are subjected to dependency analysis to determine the dependency direction between the data unit nodes associated with each constraint expression, and a data dependency edge connecting the associated data unit nodes is generated. The data dependency edge includes a dependency type attribute and a constraint expression reference identifier. The dependency type attribute represents the dependency direction feature of the constraint expression, and the constraint expression reference identifier points to the constraint expression that generated the data dependency edge. All generated data unit nodes and all data dependency edges are combined into a table data unit topology graph, and a topology graph identifier is assigned to the table data unit topology graph. After establishing an association mapping relationship between the topology graph identifier and the unique file identifier of the table file unit to be reviewed, the topology graph identifier is stored in the topology graph storage space. For each data unit node in the table data unit topology graph, perform in-degree calculation to obtain the in-degree value of each data unit node. The in-degree value represents the total number of data dependency edges pointing to that data unit node, and store the in-degree value of each data unit node as a node attribute in that data unit node. Also, for each data unit node in the table data unit topology graph, perform out-degree calculation to obtain the out-degree value of each data unit node. The out-degree value represents the total number of data dependency edges pointing from that data unit node to other data unit nodes, and store the out-degree value of each data unit node as a node attribute in that data unit node. Based on the in-degree and out-degree values of each data unit node, all data unit nodes in the table data unit topology graph are hierarchically divided. Data unit nodes with an in-degree value of 0 are marked as root nodes, data unit nodes with an out-degree value of 0 are marked as leaf nodes, and data unit nodes with both in-degree and out-degree values not equal to 0 are marked as intermediate nodes according to the path length from the root node layer to the leaf node layer. Each data dependency edge in the topology graph of the table data unit is weighted. The weighting process determines the propagation weight value of the data dependency edge based on the operator type identifier of the constraint condition expression corresponding to the data dependency edge. The propagation weight value is positively correlated with the constraint strength parameter corresponding to the operator type identifier. The node identifiers of all data unit nodes, the edge identifiers of all data dependent edges, the in-degree and out-degree values of each data unit node, the hierarchical labeling information of each data unit node, and the propagation weight values of each data dependent edge in the tabular data unit topology graph are structured and stored to generate a tabular data unit topology graph description file. The tabular data unit topology graph description file is then associated with and stored with the unique file identifier.
3. The collaborative review method for clinical trial data tables based on file state-driven approach according to claim 1, characterized in that, The response to the collaborative audit entity performing an audit operation on a target data unit node in the table data unit topology graph generates an audit operation event containing the node identifier of the target data unit node and the audit operation type, including: The system receives an audit operation request sent by the collaborative audit terminal. The audit operation request includes a node identifier of the target data unit node, an operation execution entity identifier, an operation timestamp, and an operation type identifier. The operation type identifier is generated by the collaborative audit terminal based on the operation behavior of the collaborative audit entity on the user interface. Based on the node identifier of the target data unit node, extract the node name attribute, node type attribute, and node value domain attribute of the target data unit node from the table data unit topology diagram, and determine the current value state of the data field corresponding to the target data unit node based on the node value domain attribute. The current value state includes an assigned value state and an unassigned value state. The operation type identifier is matched with a preset audit operation type mapping table to obtain the audit operation type corresponding to the operation type identifier. The audit operation type includes data field content confirmation operation, data field content modification operation, data field content questioning operation, and data field content rejection operation. Based on the operation execution entity identifier, the audit permission level information corresponding to the collaborative audit entity is obtained from the entity permission database. The audit permission level information includes a list of all audit operation types authorized to be executed by the collaborative audit entity. The list of all audit operation types in the audit permission level information is matched with the audit operation type to generate a permission matching result. The permission matching result is used to indicate whether the collaborative audit entity has the permission to execute the audit operation type. When the permission matching result indicates that the collaborative review entity has the permission to perform the review operation type on the target data unit node, a review operation event is generated based on the node identifier of the target data unit node, the review operation type, the operation execution entity identifier, and the operation timestamp. After assigning an event sequence number to the review operation event, it is stored in the review operation event queue. When the permission matching result indicates that the collaborative audit entity does not have the permission to perform the audit operation type on the target data unit node, a permission denial response message is generated and the permission denial response message is returned to the collaborative audit terminal that sent the audit operation request; After storing the audit operation event in the audit operation event queue, the event sequence number of the audit operation event is extracted from the audit operation event queue, and the event sequence number is associated with the node identifier of the target data unit node and then stored in the operation history storage space. The expected state of the data field corresponding to the target data unit node after the audit operation is determined according to the audit operation type. The expected state and the audit operation type have a preset mapping relationship. The node identifier of the target data unit node, the audit operation type, and the expected state are combined into an audit operation event completion notification, and the audit operation event completion notification is sent to the collaborative audit terminal that subscribes to the status changes of the target data unit node.
4. The collaborative review method for clinical trial data tables based on file state-driven approach according to claim 1, characterized in that, The step involves inputting the audit operation event into a preset constraint propagation analysis model. The model then performs influence range diffusion processing on the target data unit node based on the data dependency edges, resulting in a set of associated data unit nodes affected by the audit operation event, including: The audit operation event is input into the event parsing module of the constraint propagation analysis model, and the node identifier and audit operation type of the target data unit node are extracted from the audit operation event through the event parsing module; Based on the node identifier of the target data unit node, locate the corresponding target data unit node from the table data unit topology graph, and obtain all data dependency edges directly connected to the target data unit node as a first-level dependency edge set. Traverse each data dependency edge in the first-level dependency edge set, extract the corresponding constraint condition expression from the table constraint rule set according to the constraint expression reference identifier of the data dependency edge, and determine the adjacent data unit node associated with the data dependency edge according to the constraint condition expression. The adjacent data unit node is added to the candidate set of influence nodes as a first-level influence node, and the dependency path information between the first-level influence node and the target data unit node is recorded. The dependency path information includes the node identifier of the first-level influence node and the propagation weight value of the data dependency edge. Each of the candidate influential nodes in the set of influential nodes is taken as the current diffusion node. Recursive diffusion processing is performed on each current diffusion node to obtain all data dependency edges directly connected to each current diffusion node as a set of secondary dependency edges. Data dependency edges with the dependency direction from the set of secondary dependency edges are selected as a set of forward propagation dependency edges. The corresponding secondary influential node is determined according to each forward propagation dependency edge in the set of forward propagation dependency edges. The secondary impact node is added to the impact node candidate set, and the dependency path information between the secondary impact node and the target data unit node is updated. The dependency path information includes the aggregated result of the propagation weight values of all data dependency edges traversed from the target data unit node to the secondary impact node. All influencing nodes in the candidate set of influencing nodes are deduplicated to obtain a deduplicated candidate set of influencing nodes. The influencing nodes in the candidate set of influencing nodes are sorted according to the cumulative propagation weight value of each influencing node in the dependency path information. An influencing node sorting list is generated in descending order of the aggregated propagation weight value. Influencing nodes whose aggregated propagation weight value in the influencing node sorting list is greater than a preset propagation threshold are extracted to generate a set of associated data unit nodes affected by the audit operation event.
5. The collaborative review method for clinical trial data tables based on file state-driven approach according to claim 1, characterized in that, The step of generating a corresponding file status driving instruction based on each associated data unit node in the associated data unit node set, and sending the file status driving instruction to the collaborative review terminal to trigger a collaborative review operation on the data field corresponding to the associated data unit node, includes: Extract the node identifier of each associated data unit node from the set of associated data unit nodes, and obtain the node name attribute and node type attribute of each associated data unit node from the table data unit topology diagram based on the node identifier of each associated data unit node; The review priority parameter of the data field corresponding to each associated data unit node is determined based on the node type attribute of each associated data unit node. The review priority parameter is positively correlated with the criticality of the data field corresponding to the node type attribute in the clinical trial data table. Based on the node identifier of each associated data unit node, query the operation history storage space for the most recent audit operation record corresponding to each associated data unit node. The most recent audit operation record includes the operation execution entity identifier and operation timestamp of the most recent audit operation. The time interval parameter of each associated data unit node is calculated based on the operation timestamp in the most recent audit operation record and the current timestamp, and the timeliness weight value of each associated data unit node is determined based on the time interval parameter. The timeliness weight value is negatively correlated with the time interval parameter. Based on the review priority parameter and timeliness weight value of each associated data unit node, the review urgency score of each associated data unit node is calculated through predefined scoring rules. Then, all associated data unit nodes in the associated data unit node set are sorted in descending order according to the review urgency score to generate an associated data unit node processing sequence. Each associated data unit node in the associated data unit node processing sequence is traversed, and a corresponding file status driving instruction is generated according to the node identifier and node name attribute of each associated data unit node. The file status driving instruction includes the node identifier, node name attribute, and review operation type suggestion information of the target associated data unit node. The generated file status driving instructions are sent to the collaborative review terminal in the order of the processing sequence of the associated data unit nodes. The file status driving instructions are used to instruct the collaborative review terminal to highlight the data fields corresponding to the target associated data unit node on the user interface. After the file status driving instruction is sent to the collaborative review terminal, an instruction reception confirmation message is received from the collaborative review terminal. The instruction reception confirmation message includes the instruction identifier and reception timestamp of the received file status driving instruction. According to the instruction identifier in the instruction receipt confirmation message, the corresponding file status driving instruction is matched from the sent file status driving instructions. The successfully matched file status driving instruction is marked as confirmed and stored in the instruction sending record storage space. The time difference between the sending timestamp of the file status driving instruction and the receiving timestamp in the instruction receipt confirmation message is calculated to obtain the instruction transmission delay parameter. The instruction transmission delay parameter is stored as the status indicator of the collaborative review terminal in the terminal status monitoring database.
6. The collaborative review method for clinical trial data tables based on file state-driven approach according to claim 4, characterized in that, The step of taking each influencing node in the candidate set of influencing nodes as the current diffusion node, performing recursive diffusion processing on each current diffusion node, and obtaining all data dependency edges directly connected to each current diffusion node as a set of secondary dependency edges includes: Extract an unprocessed influence node from the candidate set of influence nodes as the current diffusion node, and assign a diffusion depth identifier to the current diffusion node. The initial value of the diffusion depth identifier is determined based on the number of data dependency edges contained in the dependency path between the current diffusion node and the target data unit node. Based on the node identifier of the current diffusion node, obtain all data dependency edges directly connected to the current diffusion node from the table data unit topology graph, generate a full set of associated dependency edges related to the current diffusion node, filter out data dependency edges whose dependency direction is from the current diffusion node to other data unit nodes as a forward propagation dependency edge candidate set from the full set of associated dependency edges, and filter out data dependency edges whose dependency direction is from other data unit nodes to the current diffusion node as a backward propagation dependency edge candidate set. Each forward propagation dependency edge in the candidate set of forward propagation dependency edges is added to the secondary dependency edge set, and each backward propagation dependency edge in the candidate set of backward propagation dependency edges is added to the secondary dependency edge set. Each secondary dependency edge in the secondary dependency edge set is traversed, and the corresponding secondary constraint condition expression is extracted from the table constraint rule set according to the constraint expression reference identifier of each secondary dependency edge. The adjacent nodes connected to the current diffusion node through the secondary dependency edge are determined according to the secondary constraint condition expression. The determined adjacent nodes are taken as secondary influence nodes, and a diffusion path record is generated for each secondary influence node. The diffusion path record contains the edge identifier sequence of all data dependency edges traversed from the target data unit node to the secondary influence node and the propagation weight value of each data dependency edge. Check whether the secondary impact node already exists in the impact node candidate set. If the secondary impact node does not exist in the impact node candidate set, add the secondary impact node to the impact node candidate set. If the secondary impact node already exists in the impact node candidate set, compare the aggregation result of the propagation weight value in the existing diffusion path record of the secondary impact node with the aggregation result of the propagation weight value in the newly generated diffusion path record. When the aggregated propagation weight value in the newly generated diffusion path record is greater than the aggregated propagation weight value in the existing diffusion path record, the existing diffusion path record of the secondary affected node is replaced by the newly generated diffusion path record. After processing all secondary dependent edges of the current diffusion node, the current diffusion node is marked as processed, and the next unprocessed affected node is extracted from the candidate set of affected nodes as the new current diffusion node for iterative processing until there are no unprocessed affected nodes in the candidate set of affected nodes.
7. The collaborative review method for clinical trial data tables based on file state-driven approach according to claim 5, characterized in that, The step of traversing each associated data unit node in the associated data unit node processing sequence and generating corresponding file status driving instructions based on the node identifier and node name attribute of each associated data unit node includes: Extract the currently pending associated data unit node from the associated data unit node processing sequence, and obtain the node identifier and node name attribute of the current associated data unit node; Based on the node identifier of the current associated data unit node, the node type attribute and node value domain attribute of the current associated data unit node are obtained from the table data unit topology graph, and the table area identifier to which the data field corresponding to the current associated data unit node belongs is determined based on the node type attribute. Based on the node identifier of the current associated data unit node, query the historical audit operation statistics corresponding to the current associated data unit node from the operation history storage space. The historical audit operation statistics include the number of times each type of audit operation was performed on the current associated data unit node and the most recent operation timestamp. Based on the number of operations for each type of audit operation in the historical audit operation statistics, the audit dispute level parameter of the current associated data unit node is calculated through predefined statistical rules. The audit dispute level parameter is used to characterize the degree of difference in the distribution of the number of operations for different types of audit operations. The node identifier, node name attribute, table area identifier, and review dispute level parameter of the current associated data unit node are combined into the instruction payload data of the file status driven instruction; The sending priority parameter of the file status driving instruction is determined based on the sorting position of the current associated data unit node in the associated data unit node processing sequence. The sending priority parameter is positively correlated with the sorting position, and the earlier the sorting position, the higher the sending priority parameter. The instruction payload data and the transmission priority parameters are encapsulated into a file status driving instruction, and a unique instruction identifier and generation timestamp are assigned to the file status driving instruction. The encapsulated file status driving instruction is inserted into the corresponding priority position of the instruction transmission queue according to the transmission priority parameters. The instruction transmission queue organizes and stores the file status driving instructions to be sent in descending order of the transmission priority parameters. Extract the file status driving instruction with the highest sending priority parameter from the head of the instruction sending queue as the current sending instruction, and send the current sending instruction to the collaborative review terminal. After the current sending instruction is sent, remove the current sending instruction from the instruction sending queue, and record the instruction identifier and the actual sending timestamp of the current sending instruction.
8. The collaborative review method for clinical trial data tables based on file state-driven approach according to claim 4, characterized in that, After extracting the nodes whose aggregated propagation weight values in the impact node sorting list are greater than a preset propagation threshold and generating a set of associated data unit nodes affected by the audit operation event, the method further includes: Obtain the node identifier of each associated data unit node in the associated data unit node set, and obtain the hierarchical label information of each associated data unit node from the table data unit topology diagram based on the node identifier of each associated data unit node. Based on the hierarchical label information of each associated data unit node, group the associated data unit nodes in the associated data unit node set according to their respective hierarchical levels to generate a hierarchical grouped set of associated data unit nodes. From the hierarchically divided set of associated data unit nodes, we extract the associated data unit nodes with the hierarchical label information as root node level as root node influence groups, and extract the associated data unit nodes with the hierarchical label information as leaf node level as leaf node influence groups. Based on the node identifier of each associated data unit node in the root node influence group, we obtain the out-degree value of each associated data unit node in the tabular data unit topology graph, and use the out-degree value as the branch influence range parameter of each associated data unit node in the root node influence group. We use the in-degree value of the associated data unit node as the convergence influence degree parameter of each associated data unit node in the leaf node influence group, and determine the convergence influence degree parameter of each associated data unit node based on the in-degree value of the associated data unit node. The associated data unit nodes in the root node influence group whose branch influence range parameter is greater than the preset branch range threshold are marked as key root node influence units, and the associated data unit nodes in the leaf node influence group whose convergence influence degree parameter is greater than the preset convergence degree threshold are marked as key leaf node influence units. A list of key impact nodes is generated based on the key root node impact unit and the key leaf node impact unit. The list of key impact nodes is then associated with the event sequence number of the audit operation event and stored in the key impact record storage space. Based on the list of key impact node identifiers, extract the data dependency edge information corresponding to each key impact node from the topology graph of the table data unit, and generate a complete set of impact path descriptions from the target data unit node to each key impact node based on the data dependency edge information. Combine the complete set of impact path descriptions with the event sequence number of the audit operation event to form an impact analysis report, and send the impact analysis report to the collaborative audit terminal that initiated the audit operation event.
9. The collaborative review method for clinical trial data tables based on file state-driven approach according to claim 1, characterized in that, After generating a corresponding file status driving instruction based on each associated data unit node in the associated data unit node set, and sending the file status driving instruction to the collaborative review terminal to trigger a collaborative review operation on the data field corresponding to the associated data unit node, the method further includes: The system receives a collaborative review completion message from the collaborative review terminal in response to the file status-driven instruction. The collaborative review completion message includes the node identifier of the associated data unit node that has been reviewed, the operation execution entity identifier that has completed the review, and the operation completion timestamp. Based on the node identifier in the collaborative review completion message, locate the corresponding data unit node that has completed the review from the table data unit topology graph, and obtain the in-degree and out-degree values of the data unit node that has completed the review. When the in-degree value of the data unit node that has completed the review is 0, the data unit node that has completed the review is marked as the root node reviewed, and the root node reviewed status is associated with the operation execution entity identifier that has completed the review; when the out-degree value of the data unit node that has completed the review is 0, the data unit node that has completed the review is marked as the leaf node reviewed, and the leaf node reviewed status is associated with the operation execution entity identifier that has completed the review; when both the in-degree and out-degree values of the data unit node that has completed the review are not 0, the data unit node that has completed the review is marked as the intermediate node reviewed, and the intermediate node reviewed status is associated with the operation execution entity identifier that has completed the review. Based on the node identifier of the data unit node that has been reviewed, query the key impact record storage space to see if there is a list of key impact node identifiers containing the node identifier. If there is, mark the event sequence number of the review operation event corresponding to the list of key impact node identifiers as a responded status. The system statistically analyzes the distribution information of the reviewed status of all data unit nodes in the table data unit topology diagram to which the reviewed data unit nodes belong, and generates a reviewed node coverage parameter and an unreviewed node identifier list. When the reviewed node coverage parameter exceeds a preset completion threshold, an unreviewed node reminder instruction is generated based on the unreviewed node identifier list, and the unreviewed node reminder instruction is sent to the collaborative review terminal. The node identifier, audited status flag, operation execution entity identifier, and operation completion timestamp of the data unit node that has completed the audit are combined into an audit progress synchronization message, and the audit progress synchronization message is broadcast to all collaborative audit terminals that participated in the collaborative audit.
10. A collaborative review system for clinical trial data tables based on file status, characterized in that, The method includes a processor and a computer-readable storage medium storing machine-executable instructions that, when executed by the processor, implement the file-state-driven collaborative review method for clinical trial data tables as described in any one of claims 1-9.