Single-pass and report distribution method, system and electronic equipment for medical data multi-scenario compliance verification and storage medium

Abstract

The application provides a single traversal and report distribution method, system, electronic equipment and storage medium for medical data multi-scene compliance verification, relates to medical informatization and underlying data processing technology, and the method comprises the following steps: analyzing each verification request to obtain an original verification rule set; generating a unique corresponding logical fingerprint through a hash algorithm, and generating a global execution rule set by de-duplication compilation; establishing a reverse mapping dictionary; based on the global execution rule set, calling an underlying database interface to perform single physical I / O scanning on a target medical data table, generating a bitmap state feature code, and forming an atomic verification log; asynchronous processing threads are parallel, and a scene mask for the own scene is generated; a bitwise AND operation is performed to generate an independent scene quality analysis report. The scheme can cut off the physical coupling between verification execution and business scenes at the computer underlying layer, maximize the reuse of logical computing power, and support the data processing of an unlimited number of upper-level supervision scenes through only a single database traversal.

Description

Technical Field

[0001] This application relates to the fields of medical informatics and underlying data processing technology, specifically to a single-pass traversal and report distribution method, system, electronic device and storage medium for multi-scenario compliance verification of medical data. Background Technology

[0002] With the ongoing advancement of the new healthcare reform and the rapid development of medical informatization, hospitals and regional medical institutions have accumulated massive amounts of medical and health big data. To fully leverage the value of this data and meet regulatory requirements at different levels, medical institutions' data centers often need to support a variety of complex business and regulatory scenarios. These include: hospital information interconnection standardization maturity assessments, hospital performance evaluations, reporting of medical insurance settlement lists, uploading data to municipal / provincial regional health platforms, and extracting clinical research data within hospitals. Different regulatory or application scenarios impose varying quality requirements and verification rules on the underlying medical data.

[0003] Existing medical data governance and quality verification solutions, such as conventional ETL tools or traditional data auditing systems, typically employ a scenario-based independent task flow architecture. This means that for each specific business scenario, the system administrator independently configures a set of verification rules, and during execution, initiates a complete data extraction, cleaning, transformation, and loading task for that scenario. When multiple target scenarios exist, the system will launch multiple parallel or serial data scanning tasks.

[0004] However, with the exponential growth of medical data and the increasing number of higher-level regulatory scenarios, existing technologies have exposed the following underlying computer technology deficiencies: First, during concurrent verification across multiple scenarios, despite significant overlap in rules across different scenarios—for example, multiple scenarios may require verification of "patient ID number format" or "discharge diagnosis not empty"—existing systems still mechanically perform full or incremental reads on the underlying physical tables, which contain billions of records, for each scenario. This multi-headed monitoring and multi-headed scanning model results in extremely high disk I / O pressure and CPU computational redundancy for the database server, which can easily lead to system crashes or delays in the response of core business systems. Second, the existing verification engine is tightly coupled with the final business report. This means that after executing the rules, it directly outputs a qualitative conclusion of "qualified / unqualified for this scenario," and the intermediate logical data generated during the verification process is destroyed. This design means that if data is deemed unqualified in a particular scenario, such as the lack of specific verification indicators required for scientific research, the entire data entry is often discarded, making it unusable in other scenarios with lower requirements, such as medical insurance scenarios that only require basic diagnosis. This results in a double waste of computing power and data assets. Even when existing systems attempt to save verification logs, they often use relational database records or string concatenation to store the reasons for failure. During high-concurrency reading across multiple scenarios, the cyclical comparison and parsing of these massive amounts of string logs again causes severe CPU and memory consumption and retrieval latency, making it impossible to achieve millisecond-level report distribution. Third, for the same field, different platforms often have different code standards or constraint parameters. For example, scenario A requires the gender code to be "1 / 2", while scenario B requires it to be "M / F". When traditional systems encounter such logical mutual exclusion, they can usually only solve the problem by creating multiple physical data copies or forcibly overriding priorities, which greatly increases storage costs and makes it impossible to perform multi-standard compliance verification in parallel on the same primary data copy. Summary of the Invention

[0005] To address the shortcomings of the aforementioned existing technologies, this application provides a method, system, electronic device, and storage medium for single-pass traversal and report distribution of medical data compliance verification across multiple scenarios. This method can sever the physical coupling between verification execution and business scenarios at the computer level, maximize the reuse of logical computing power, and support the processing of an unlimited number of upper-level regulatory scenarios through only a single database traversal.

[0006] To achieve the above objectives, the present invention employs the following techniques: Methods for single-pass traversal and report distribution of multi-scenario compliance verification of medical data, including: Receive concurrent verification requests from multiple medical supervision scenarios targeting the target medical data table, parse each verification request, and obtain the original verification rule set corresponding to each medical supervision scenario; Extract the verification fields, logical operators, and parameter thresholds of each verification rule in the original verification rule set, and generate a unique corresponding logical fingerprint using a hash algorithm; perform a union operation and deduplication on all original verification rule sets based on the logical fingerprints, compile to generate a global execution rule set; and establish a reverse mapping dictionary between the logical fingerprint and the identifier of the corresponding medical supervision scenario. Based on the global execution rule set, the underlying database interface is called to perform a single physical I / O scan on the target medical data table; a fixed bitmap index bit is assigned to each logical fingerprint in the global execution rule set; for each row of medical data scanned, a zero vector with a length equal to the total number of rules in the global execution rule set is initialized; if the row of medical data fails the rule verification corresponding to a certain logical fingerprint, the corresponding bitmap index bit in its zero vector is set to 1, a bitmap status feature code is generated, and a key-value pair is constructed using the unique primary key of the medical data as the key to generate an atomic verification log decoupled from the medical supervision scenario; The atomic verification log is written to the memory cache, and multiple asynchronous processing threads corresponding to the number of medical supervision scenarios are woken up. Each asynchronous processing thread sets the bitmap index bit corresponding to all logical fingerprints contained in its own scenario to 1 according to the reverse mapping dictionary, and generates a scenario mask for that scenario. Each asynchronous processing thread performs a bitwise AND operation between the bitmap status feature code and its own scenario mask. If the operation result is non-zero, the bitmap index bit that is 1 in the operation result is reverse parsed into the specific failure record, and an independent scenario quality analysis report is generated.

[0007] A single-pass traversal and report distribution system for multi-scenario compliance verification of medical data, including: The request parsing module is used to receive concurrent verification requests from multiple medical supervision scenarios targeting the target medical data table, parse each verification request, and obtain the original verification rule set corresponding to each medical supervision scenario. The fingerprint compilation module is used to extract the verification fields, logical operators, and parameter thresholds of each verification rule in the original verification rule set, generate a unique corresponding logical fingerprint through a hash algorithm, perform a union operation and deduplication on all original verification rule sets based on the logical fingerprint, compile and generate a global execution rule set, and establish a reverse mapping dictionary between the logical fingerprint and the identifier of the corresponding medical supervision scenario. The single-scan engine is used to perform a single physical I / O scan of the target medical data table by calling the underlying database interface based on the global execution rule set. It assigns a fixed bitmap index bit to each logical fingerprint in the global execution rule set. For each row of medical data scanned, it initializes a zero vector with a length equal to the total number of rules in the global execution rule set. If the row of medical data fails the rule verification corresponding to a certain logical fingerprint, it sets the corresponding bitmap index bit in its zero vector to 1, generates a bitmap status feature code, and constructs a key-value pair with the unique primary key of the medical data as the key to generate an atomic verification log decoupled from the medical supervision scenario. The asynchronous thread dispatch module is used to write atomic verification logs to the memory cache and wake up multiple asynchronous processing threads corresponding to the number of medical supervision scenarios. Each asynchronous processing thread sets the bitmap index bits corresponding to all logical fingerprints contained in its own scenario to 1 according to the reverse mapping dictionary, and generates a scenario mask for that scenario. Each asynchronous processing thread performs a bitwise AND operation between the bitmap state feature code and its own scenario mask. If the operation result is non-zero, the bitmap index bits that are 1 in the operation result are reverse parsed into specific failure records, and independent scenario quality analysis reports are generated respectively.

[0008] The beneficial effects of this invention are as follows: 1. Traditional technologies require M full table scans of N massive medical data sets to handle M regulatory scenarios; this invention generates a global execution rule set through compilation, enabling a single low-level physical scan to support an unlimited number of upper-level scenarios, thus exponentially reducing database I / O pressure. 2. This invention abandons the method of using Chinese strings or complex relational tables to record the intermediate verification results. Instead, it highly compresses the complex verification results into binary bitmap status feature codes. When the report is distributed asynchronously in the future, the CPU’s underlying logic gate circuits are used to perform the bitwise AND operation for filtering. Compared with the traditional SQL statement-based conditional retrieval or loop comparison, the method of this invention improves the decomposition speed of multi-scenario reports to the millisecond level. 3. The atomic verification log generated by this invention does not contain any scene identifiers, which allows the same underlying quality assessment data to be projected on demand in real time by various independent systems in the hospital (such as medical insurance, scientific research, and quality control) through a custom scene mask. This not only eliminates the problem of rule mutual exclusion, but also avoids the overall abandonment of data assets due to the failure of a single standard. Attached Figure Description

[0009] Figure 1 This is a flowchart illustrating the method steps of an embodiment of this application.

[0010] Figure 2 This is a flowchart of the preferred method for step two in an embodiment of this application.

[0011] Figure 3 These are examples of atomic verification logs, scene masks, and calculation results from embodiments of this application.

[0012] Figure 4 This is a method example for mutual exclusion of rules in the embodiments of this application.

[0013] Figure 5 This is a system structure diagram of an embodiment of this application. Detailed Implementation

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

[0015] One aspect of this application provides a method for single-pass traversal and report distribution of multi-scenario compliance verification of medical data, such as... Figure 1 As shown, it includes the following steps: Step 1: Receive concurrent verification requests from multiple medical supervision scenarios targeting the target medical data table, parse each verification request, and obtain the original verification rule set corresponding to each medical supervision scenario.

[0016] Step 2: Extract the verification field, logical operator, and parameter threshold of each verification rule in the original verification rule set, and generate a unique corresponding logical fingerprint using a hash algorithm; perform a union operation and deduplication on all original verification rule sets based on the logical fingerprint, compile to generate a global execution rule set; and establish a reverse mapping dictionary between the logical fingerprint and the identifier of the corresponding medical supervision scenario.

[0017] As a preferred option for step two, such as Figure 2 As shown, before extracting the validation fields, logical operators, and parameter thresholds of each validation rule in the original validation rule set, the abstract syntax tree (AST) parser is used to perform lexical and syntactic analysis on the original validation rules written in natural language or custom scripts, automatically converting unstructured business rules into structured machine-readable logical expressions.

[0018] Step 3: Based on the global execution rule set, call the underlying database interface to perform a single physical I / O scan on the target medical data table; assign a fixed bitmap index bit to each logical fingerprint in the global execution rule set; for each row of medical data scanned, initialize a zero vector with a length equal to the total number of rules in the global execution rule set; if the row of medical data fails the rule verification corresponding to a certain logical fingerprint, set the bitmap index bit in its zero vector corresponding to that logical fingerprint to 1, generate a bitmap status feature code representing the quality defect of the row of data, and construct key-value pairs using the unique primary key of the medical data as the key to generate an atomic verification log decoupled from the medical supervision scenario.

[0019] Step 4: Write the atomic verification log to the memory cache and wake up multiple asynchronous processing threads corresponding to the number of medical supervision scenarios; each asynchronous processing thread sets the bitmap index bit corresponding to all logical fingerprints contained in its own scenario to 1 according to the reverse mapping dictionary, and generates a scenario mask for that scenario.

[0020] Step 5: Each asynchronous processing thread performs a bitwise AND operation between the bitmap state feature code and its own scene mask. If the result is non-zero, the bitmap index bits that are 1 in the result are reversed and parsed into specific failure records, generating independent scene quality analysis reports respectively.

[0021] This example demonstrates the bitmap-based verification and rapid decomposition process for medical data: Suppose we receive concurrent requests for "Medical Insurance Settlement Scenario (Scenario A)" and "In-Hospital Scientific Research Scenario (Scenario B)". After deduplication using logical fingerprint hashing, a total of 5 unique, non-repeating rules are generated globally, and each is assigned a fixed bitmap index (0 to 4): Index 0: Patient name is not empty (fingerprint F0); Index 1: The ID number must be 18 digits (F1 fingerprint); Index 2: Gender must be filled in (F2 fingerprint); Index 3: Must include discharge diagnosis code (fingerprint F3); Index 4: Must include surgical procedure records (fingerprint F4); The underlying scanning engine reads a medical record for patient "Zhang San". Verification reveals that Zhang San's name, gender, and surgical record are complete (passing rules 0, 2, and 4); however, his ID card number is 15 digits and his discharge diagnosis is missing (failing rules 1 and 3). First, a zero vector of length 5 is initialized for Zhang San: 0 0 0 0 0. Then, the index positions corresponding to the rules that failed verification are set to 1, generating a unique bitmap status feature code for Zhang San: 0 1 0 1 0, as shown below. Figure 3 As shown. This signature is stored in memory with a very small byte footprint, which is the atomic check log.

[0022] Entering the asynchronous generation phase of multi-scenario reports: For scenario A (medical insurance settlement scenario): the business requirements only focus on basic identity information (rules 0, 1, 2), and not on clinical diagnosis and treatment. Asynchronous thread A automatically generates a unique scenario mask: 1 1 1 0 0, such as... Figure 3 As shown, thread A calls a CPU instruction to perform a bitwise AND operation on Zhang San's status feature code and scene mask: 0 1 0 1 0 (Zhang San's feature code) & 11 1 0 0 (Scene mask of scene A) = 0 1 0 0 0 (Result of the operation). Analysis: The result is non-zero, indicating that Zhang San is ineligible under the medical insurance scenario. By analyzing the position of 1 in the result (index 1), the reason for failure is determined by reverse mapping: "ID number must be 18 digits," and this is directly written into the medical insurance quality control report. (Note: Zhang San's diagnosis error due to missing rule 3 is perfectly filtered by the mask and does not affect the medical insurance judgment logic).

[0023] For Scenario B (in-hospital research scenario): the business requirement is to focus only on clinical diagnosis and treatment information (rules 3 and 4), and not on identity privacy. Asynchronous thread B generates a unique scenario mask: 0 0 0 1 1. Thread B performs a parallel bitwise AND operation: 0 1 0 10 (Zhang San's signature) & 0 0 0 1 1 (Scenario B's scenario mask) = 0 00 1 0 (result). Result analysis: the result is non-zero, indicating that Zhang San is also unqualified in the research scenario. Parsing the 1 at index 3, the reverse mapping reveals the reason for failure: "must include discharge diagnosis code," and this is written into the research cleaning report.

[0024] As can be seen from the above embodiments, this example avoids the complex loop judgments or lengthy string text retrieval in traditional methods by using binary bit operations, and achieves millisecond-level multi-view report projection under high concurrency.

[0025] In practical medical data governance, different higher-level regulatory platforms often have conflicting (i.e., mutually exclusive) standardization requirements for the same business field. This example, when compiling and generating a global execution rule set, also includes a mechanism for the physical coexistence and logical resolution of conflicting rules, combined with... Figure 4 The specific description is as follows: When step two is executed, if mutually exclusive verification rules for the same medical data field are identified in different medical supervision scenarios, all mutually exclusive verification rules are retained in the global execution rule set, and independent logical fingerprints are generated for each of them; when step three is executed, in a single physical I / O scan, the mutually exclusive verification rules are executed in parallel for the same medical data field, and all verification results are recorded in the atomic verification log; when step four is executed, each asynchronous processing thread reads the logical fingerprint state that strictly matches its own scenario only through its corresponding scenario identifier and reverse mapping dictionary, so as to achieve physical coexistence and logical isolation of the results of mutually exclusive rules. Figure 4 In the example shown, mutual exclusion rules F4 and F5 coexist in memory. Asynchronous thread 1 reads only F4, and asynchronous thread 2 reads only F5.

[0026] Specifically, the following example will explain in detail how this instance uses the combination of "reverse mapping dictionary" and "asynchronous thread" to perfectly achieve the physical coexistence and logical isolation of mutual exclusion rules without copying the underlying physical data.

[0027] Assume that both a "city-level platform (Scenario A)" and a "provincial-level platform (Scenario B)" are connected simultaneously. For the "gender" field in the medical data table: The original rule for scenario A requires that the gender code must be either "1 (male)" or "2 (female)". The original rule for scenario B requires that the gender code must be either "M (male)" or "F (female)".

[0028] Clearly, it's impossible for the same row of physical data to simultaneously satisfy both of the above conditions. Traditional ETL tools would encounter logical errors or require creating two copies of the data in this situation. However, in the steps of this example method, after the fingerprint compilation module identifies the conflict, it does not forcibly merge the rules, but treats them as two independent verification logics, generating independent logical fingerprints for each: Generate: Logical fingerprint F_city (verification logic: value in[1, 2]); Generate: Logical fingerprint F_province (verification logic: value in [M, F]).

[0029] To decouple the underlying verification engine from the upper-layer business logic, this example constructs a reverse mapping dictionary in memory. This dictionary functions similarly to a lost and found list, recording the attribution relationship between the underlying logic fingerprint and the upper-layer scenario. Dictionary record 1: Logical fingerprint F_city → belongs to scenario A; Dictionary record 2: Logical fingerprint F_province → belongs to scenario B; The underlying scanning engine reads a medical record of patient Li Si, whose gender field has a true value of "1". The underlying engine objectively executes all logical fingerprint verifications in parallel, without incorporating any scenario-based judgments. After verification of "Logical Fingerprint F_City": Passed, because the value is 1; Verification of "Logical Fingerprint F_Province" failed because 1 is neither M nor F.

[0030] Subsequently, the failed fingerprints are recorded in the atomic verification log. At this point, the log only objectively records "Li Si failed verification in F_ province", completely unaware of the existence of scenario A and scenario B.

[0031] Wake up multiple asynchronous processing threads to generate their own reports: For asynchronous thread A (representing scenario A, the city-level platform): After thread A starts, it first queries the reverse mapping dictionary and learns that it only has jurisdiction over the "logical fingerprint F_city". Then, thread A retrieves Li Si's data from the atomic verification log and finds that Li Si did not fail on "F_city" (ignoring failure records for F_province). Therefore, thread A determines that Li Si's data is fully qualified in scenario A.

[0032] For asynchronous thread B (representing scenario B, the provincial platform): After thread B starts, it also queries the reverse mapping dictionary and learns that it has jurisdiction over the "logical fingerprint F_province". Thread B searches the atomic verification log and accurately matches that Li Si has a failure record on "F_province". Therefore, thread B determines that Li Si's data is unqualified in scenario B and writes the error message into the scenario B's dedicated report.

[0033] This example utilizes a reverse mapping dictionary scheduling mechanism to ensure that each asynchronous processing thread accurately retrieves the error messages belonging to its jurisdiction from the underlying error log pool. This not only completely solves the technical challenge of system crashes caused by conflicting regulatory standards or logical mutual exclusion, but also enables the support of an unlimited number of even contradictory upper-level data compliance checks while maintaining a minimalist architecture with a single database and table containing the same physical data.

[0034] Another aspect of this application provides a single-pass traversal and report distribution system for multi-scenario compliance verification of medical data, such as... Figure 5 As shown, it includes a request parsing module, a fingerprint compilation module, a single scan engine, and an asynchronous thread dispatch module connected in sequence.

[0035] The request parsing module is used to receive concurrent verification requests for multiple medical supervision scenarios targeting the target medical data table, parse each verification request, and obtain the original verification rule set corresponding to each medical supervision scenario.

[0036] The fingerprint compilation module extracts the verification fields, logical operators, and parameter thresholds of each verification rule in the original verification rule set, and generates a unique corresponding logical fingerprint using a hash algorithm. Based on the logical fingerprint, it performs a union operation and deduplication on all original verification rule sets to compile a global execution rule set. It also establishes a reverse mapping dictionary between the logical fingerprint and the identifier of its respective medical regulatory scenario. Preferably, before extracting the verification fields, logical operators, and parameter thresholds of each verification rule in the original verification rule set, the fingerprint compilation module first uses an abstract syntax tree parser to perform lexical and syntactic analysis on the original verification rules written in natural language or custom scripts, automatically converting unstructured business rules into structured machine-readable logical expressions.

[0037] The single-scan engine is used to perform a single physical I / O scan of the target medical data table by calling the underlying database interface based on the global execution rule set. A fixed bitmap index bit is assigned to each logical fingerprint in the global execution rule set. For each row of medical data scanned, a zero vector with a length equal to the total number of rules in the global execution rule set is initialized. If the row of data fails the rule verification corresponding to a certain logical fingerprint, the bitmap index bit in its zero vector is set to 1, a bitmap status feature code representing the quality defect of the row of data is generated, and a key-value pair is constructed using the unique primary key of the medical data as the key to generate an atomic verification log decoupled from the medical supervision scenario.

[0038] The asynchronous thread dispatch module is used to write atomic verification logs to the memory cache and wake up multiple asynchronous processing threads corresponding to the number of medical supervision scenarios. Each asynchronous processing thread sets the bitmap index bits corresponding to all logical fingerprints contained in its own scenario to 1 according to the reverse mapping dictionary, and generates a scenario mask for that scenario. Each asynchronous processing thread performs a bitwise AND operation between the bitmap status feature code and its own scenario mask. If the operation result is non-zero, the bitmap index bits that are 1 in the operation result are reverse parsed into specific failure records, and independent scenario quality analysis reports are generated respectively.

[0039] When the fingerprint compilation module compiles and generates a global execution rule set, if it identifies that there are mutually exclusive verification rules for the same medical data field in different medical supervision scenarios, it retains all mutually exclusive verification rules in the global execution rule set and generates independent logical fingerprints for each of them. In a single physical I / O scan, the single scan engine executes the mutually exclusive verification rules in parallel on the same medical data field and records all verification results into the atomic verification log. When the asynchronous thread dispatch module performs processing, each asynchronous processing thread reads the logical fingerprint state that strictly matches its own scenario only through its corresponding scenario identifier and reverse mapping dictionary, so as to achieve physical coexistence and logical isolation of the results of mutual exclusion rules.

[0040] In another aspect of the embodiments of this application, an electronic device is provided, including at least one processor and a memory; wherein the memory stores computer execution instructions; at least one processor executes the computer execution instructions stored in the memory, causing at least one processor to perform a single traversal and report distribution method for multi-scenario compliance verification of medical data as described in the foregoing embodiments.

[0041] In another aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, which, when the computer program is run by a processor, controls the device where the storage medium is located to perform a single traversal and report distribution method for multi-scenario compliance verification of medical data as described in the foregoing embodiments.

[0042] The above description is only a preferred embodiment of this application and is not intended to limit this application. Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application.

Claims

1. A method for single-pass traversal and report distribution of medical data for multi-scenario compliance verification, characterized in that, include: Receive concurrent verification requests for multiple medical supervision scenarios targeting the target medical data table, parse each verification request, and obtain the original verification rule set corresponding to each medical supervision scenario; Extract the verification field, logical operator, and parameter threshold of each verification rule in the original verification rule set, and generate a unique corresponding logical fingerprint using a hash algorithm; perform a union operation and deduplication on all the original verification rule sets based on the logical fingerprint, compile to generate a global execution rule set; and establish a reverse mapping dictionary between the logical fingerprint and the medical supervision scenario identifier. Based on the global execution rule set, the underlying database interface is invoked to perform a single physical I / O scan on the target medical data table; a fixed bitmap index bit is assigned to each logical fingerprint in the global execution rule set; for each row of medical data scanned, a zero vector with a length equal to the total number of rules in the global execution rule set is initialized; if the row of medical data fails the rule verification corresponding to a certain logical fingerprint, the corresponding bitmap index bit in its zero vector is set to 1, a bitmap status feature code is generated, and a key-value pair is constructed using the unique primary key of the medical data as the key to generate an atomic verification log decoupled from the medical supervision scenario; The atomic verification log is written to the memory cache, and multiple asynchronous processing threads corresponding to the number of medical monitoring scenarios are woken up. Each asynchronous processing thread sets the bitmap index bits corresponding to all logical fingerprints contained in its own scenario to 1 according to the reverse mapping dictionary, and generates a scenario mask for that scenario. Each asynchronous processing thread performs a bitwise AND operation between the bitmap state feature code and its own scenario mask. If the operation result is non-zero, the bitmap index bits that are 1 in the operation result are reverse parsed into specific failure records, and independent scenario quality analysis reports are generated respectively. When compiling and generating a global execution rule set, if mutually exclusive verification rules for the same medical data field are identified in different medical supervision scenarios, all mutually exclusive verification rules are retained in the global execution rule set, and independent logical fingerprints are generated for each of them. In a single physical I / O scan, the mutually exclusive verification rules are executed in parallel on the same medical data field, and all verification results are recorded in the atomic verification log. Each asynchronous processing thread reads the logical fingerprint state that strictly matches its own scenario only through its corresponding scenario identifier and reverse mapping dictionary, thus achieving physical coexistence and logical isolation of the results of the mutual exclusion rules.

2. The method for single-pass traversal and report distribution of medical data for multi-scenario compliance verification according to claim 1, characterized in that, Before extracting the validation fields, logical operators, and parameter thresholds of each validation rule in the original validation rule set, the abstract syntax tree parser is used to perform lexical and syntactic analysis on the original validation rules written in natural language or custom scripts, automatically converting unstructured business rules into structured machine-readable logical expressions.

3. A single-pass traversal and report distribution system for multi-scenario compliance verification of medical data, characterized in that: include: The request parsing module is used to receive concurrent verification requests for multiple medical supervision scenarios targeting the target medical data table, parse each verification request, and obtain the original verification rule set corresponding to each medical supervision scenario. The fingerprint compilation module is used to extract the verification field, logical operator, and parameter threshold of each verification rule in the original verification rule set, generate a unique corresponding logical fingerprint through a hash algorithm; perform a union operation and deduplication on all the original verification rule sets based on the logical fingerprint, compile to generate a global execution rule set; and establish a reverse mapping dictionary between the logical fingerprint and the medical supervision scenario identifier. A single-scan engine is used to call the underlying database interface to perform a single physical I / O scan of the target medical data table based on the global execution rule set; a fixed bitmap index bit is assigned to each logical fingerprint in the global execution rule set; for each row of medical data scanned, a zero vector with a length equal to the total number of rules in the global execution rule set is initialized; if the row of medical data fails the rule verification corresponding to a certain logical fingerprint, the bitmap index bit in its zero vector is set to 1, a bitmap status feature code is generated, and a key-value pair is constructed using the unique primary key of the medical data as the key to generate an atomic verification log decoupled from the medical supervision scenario; An asynchronous thread distribution module is used to write the atomic verification log into a memory cache and wake up multiple asynchronous processing threads corresponding to the number of medical monitoring scenarios. Each asynchronous processing thread sets the bitmap index bits corresponding to all logical fingerprints contained in its own scenario to 1 according to the reverse mapping dictionary, and generates a scenario mask for that scenario. Each asynchronous processing thread performs a bitwise AND operation between the bitmap state feature code and its own scenario mask. If the operation result is non-zero, the bitmap index bits that are 1 in the operation result are reverse parsed into specific failure records, and independent scenario quality analysis reports are generated respectively. When the fingerprint compilation module compiles and generates a global execution rule set, if it identifies that there are mutually exclusive verification rules for the same medical data field in different medical supervision scenarios, it retains all mutually exclusive verification rules in the global execution rule set and generates independent logical fingerprints for each of them. In a single physical I / O scan, the single scan engine executes the mutually exclusive verification rules in parallel on the same medical data field and records all verification results into the atomic verification log. When the asynchronous thread dispatch module performs processing, each asynchronous processing thread reads the logical fingerprint state that strictly matches its own scenario only through its corresponding scenario identifier and reverse mapping dictionary, so as to achieve physical coexistence and logical isolation of the results of mutual exclusion rules.

4. The single-pass traversal and report distribution system for multi-scenario compliance verification of medical data according to claim 3, characterized in that, Before extracting the verification fields, logical operators, and parameter thresholds of each verification rule in the original verification rule set, the fingerprint compilation module first uses an abstract syntax tree parser to perform lexical and syntactic analysis on the original verification rules written in natural language or custom scripts, automatically converting unstructured business rules into structured machine-readable logical expressions.

5. An electronic device comprising at least one processor and a memory; wherein, The memory stores computer execution instructions; characterized in that, when the at least one processor executes the computer execution instructions stored in the memory, the at least one processor performs the single traversal and report distribution method for multi-scenario compliance verification of medical data as described in claim 1 or 2.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor, it controls the device where the storage medium is located to perform a single traversal and report distribution method for multi-scenario compliance verification of medical data as described in claim 1 or 2.

Images