Block chain-based accounting document cross-platform synchronization system and conflict processing method

Abstract

The invention relates to the technical field of accounting informatization, and discloses an accounting document cross-platform synchronization system based on a block chain and a conflict processing method, and the system automatically judges a multi-mechanism concurrent operation conflict based on a preset medical authority level and a millisecond timestamp. And when a plurality of branch hospitals modify the same patient voucher at the same time, preferentially adopting a high-authority mechanism to operate, if the authority is at the same level, selecting the operation with the latest timestamp, and if logic conflicts exist, pushing to a general hospital for manual auditing. And an operation log is recorded in real time by adopting Apache Kafka, and a non-tampering historical version is generated through a block chain technology. All modification records are stored in a Merkle tree structure, a complete operation track at any time point can be inquired through a patient ID, the complete operation track comprises modification content, operator identity and block chain transaction hash, a national medical insurance platform is connected in real time, and cost compliance is automatically verified; the system can solve the problems of data conflicts, version chaos and auditing tracing among heterogeneous ERP (Enterprise Resource Planning) systems.

Description

Technical Field

[0001] The invention relates to the technical field of accounting informatization, specifically to a cross-platform synchronization system for accounting vouchers based on blockchain. Background Art

[0002] In the current medical financial management system, large hospitals usually consist of multiple branches, departments and functional departments. Each unit often uses heterogeneous ERP systems such as SAP and Kingdee to independently process patient expense and medical insurance settlement data. Due to the lack of a unified cross-platform collaboration mechanism, there are significant differences in the accounting voucher formats, account coding rules and business processes between different systems, resulting in data transfer relying on manual import and export or third-party interface splicing, with problems of low efficiency and easy errors.

[0003] Especially in multi-party collaboration scenarios, for example, when the finance section of the general hospital, the medical insurance section of the branch, and the clinical department operate the expense vouchers of the same patient simultaneously, the traditional system cannot effectively solve the data conflict problem caused by concurrent modifications on multiple platforms; for example, the operation of adjusting the expense amount by Branch A and modifying the medical insurance type by Branch B may occur simultaneously. The system has neither permission adjudication rules nor can it completely record the operation track, ultimately resulting in chaotic voucher data.

[0004] Therefore, we propose a cross-platform synchronization system for accounting vouchers based on blockchain to solve the problems in the above background. Summary of the Invention

[0005] The invention provides a cross-platform synchronization system for accounting vouchers based on blockchain, which can solve the problem that in the multi-party collaboration scenario of the existing medical financial management system, the traditional system cannot effectively solve the data conflict problem caused by concurrent modifications on multiple platforms.

[0006] To solve the above technical problems, the invention provides the following technical solutions: A cross-platform voucher synchronization system for accounting vouchers based on blockchain, including the following modules: A dynamic adjudication module, used for automatically adjudicating conflict operations according to the preset medical permission level and trusted timestamp when different branches use heterogeneous ERP systems to modify the expense vouchers of the same patient. The medical permission level is: finance section of the general hospital > finance section of the branch > clinical department; A chained evidence storage module, used for recording all expense modification events and storing the historical data of patient expense vouchers, and it can query the historical data at any time point through the patient's ID account; A self-healing synchronization module, used for correcting the conflicts between medical expenses and medical insurance types according to the medical insurance policy rule library and the national medical insurance data service interface platform to ensure the ultimate consistency of cross-platform data; A medical alliance chain network module is used to add the general hospital, branch hospitals, and medical insurance institutions as nodes, and is built-in with preset rules. By automatically executing the preset rules, the patient expense vouchers are encrypted and stored in real-time synchronization in the form of zero-knowledge proof. It also includes a heterogeneous system dynamic adaptation module, which is used to automatically generate a field mapping relationship table for different ERP systems through a deep learning model and adapt to the version changes of each branch hospital system in real-time.

[0007] Preferably, the dynamic adjudication module includes: A medical permission definition unit is used to preset medical operation priority rules and bind the operator's medical digital certificate. The medical operation priority rules are: General Hospital Finance Department > Branch Hospital Finance Department > Clinical Department; the medical digital certificate contains information such as the operator's department, professional title, and permission level. A medical trusted timestamp unit is used to access the authoritative time source of the National Time Service Center to generate a globally unique timestamp for each operation in the system, and the accuracy of the timestamp is millisecond-level; this unit ensures that all patient expense voucher operations are attached with an immutable timestamp. A conflict adjudication rule unit, when detecting that multiple branch hospitals modify the same patient voucher, automatically overwrites according to the following rules: a1. General Hospital priority rule: When the General Hospital Finance Department and the Branch Hospital Finance Department modify at the same time, the General Hospital operation shall prevail. a2. Timestamp latest rule: If there is a conflict between peer branch hospitals, the operation with the latest timestamp shall prevail. a3. Logical conflict handling rule: When there is a conflict between the expense amount and the medical insurance type logic, the system automatically pushes the conflict operation to the General Hospital audit panel for manual verification. This conflict includes but is not limited to the following situations: b1. The expense amount exceeds the reimbursement ratio limit of this medical insurance type. b2. The expense item is not within the reimbursement catalog range of this medical insurance type. b3. The expense amount exceeds the annual cumulative limit of this medical insurance type.

[0008] The dynamic adjudication module also includes a conflict probability prediction unit, which is used to train a time series model based on historical operation data to predict the probability value of a conflict caused by the current operation, and trigger the manual review process in advance when the probability exceeds the preset threshold. Preferably, the conflict probability prediction unit of the dynamic adjudication module includes: The data collection subunit is used to collect historical operation data including the operator's department level, modified field type, timestamp, conflict type and arbitration result in real time; the model training subunit builds a conflict prediction model based on the LSTM network, inputs the operation sequence sorted by timestamp and outputs the conflict probability value. The model training data covers the collaborative operation records of multiple branches within 3 years; the probability calculation subunit is used to generate a feature vector based on the department level, field sensitivity and operation frequency of the current operation, and input it into the model to calculate the conflict probability; the threshold judgment subunit freezes the operation when the conflict probability exceeds the dynamic threshold, generates an early warning event and pushes it to the audit panel of the general hospital, and calls the chain evidence module to generate a historical report containing a comparison of the data before and after the modification; the model optimization subunit corrects the model parameters according to the manual verification results, and dynamically adjusts the threshold based on the correction accuracy offset.

[0009] Preferably, the chain evidence storage module includes: The medical operation log unit uses Apache Kafka to store operation events in chronological order. Each log contains the operation department ID, timestamp, modification content summary and electronic signature. Historical data is hashed to form a traceable historical version. The medical blockchain version unit processes historical data using a hash algorithm to generate traceable, complete historical versions, which are then stored on the blockchain using a Merkle tree structure. Each historical version contains the complete state of a patient's expense voucher at a specific point in time and is indexed by the patient ID and a unique hash value, ensuring that the data is verifiable and cannot be tampered with. The medical data tracing unit provides accurate historical data tracing. When a patient ID and a specified time range are entered, the system intelligently analyzes all operation records within that time period and generates a difference report containing the following details: c1. Specific time of change; c2. Compare the data before and after the modification; c3. Operator identity information; c4. The associated blockchain transaction hash.

[0010] Preferably, the self-healing synchronization module includes: The medical insurance rule management unit is used to store and manage local medical insurance policy data, including reimbursement ratios, limits, and medical insurance catalog information. When a conflict between the expense amount and the medical insurance type is found, it automatically connects to the national medical insurance platform interface to make corrections. The conflict includes: d1. The amount of the expense exceeds the upper limit of the reimbursement ratio stipulated by the medical insurance type; d2. The expense item is not within the reimbursement scope approved by the medical insurance rules management unit; d3. The amount of the expense exceeds the annual reimbursement total limit of this type of medical insurance; A medical data correction unit, which is used to automatically connect to the medical blockchain version unit of the chained evidence storage module and call the national medical insurance drug database for standard conversion when it is found that the drug code does not match the medical insurance catalog information.

[0011] Preferably, the medical consortium chain network module includes: A node management unit, which is used to add the general hospital, branch hospitals, and medical insurance institutions as verification nodes to the network through the permission chain mechanism, and each node requires digital identity authentication; An automatic execution rule unit, which contains preset rules for cross-institutional data review and security control; A data security protection unit, which uses zero-knowledge proof and homomorphic encryption algorithms to encrypt sensitive data, and the encrypted data fingerprint is stored in the medical blockchain version unit; A data sharing and synchronization unit, which is used to immediately push data change information and uses distributed storage technology to ensure that all node data is unified and the operation records are complete and traceable.

[0012] Preferably, the preset rules include: A data format unification rule, which is used to automatically convert the accounting vouchers of heterogeneous ERP systems, realize field mapping, medical subject code conversion, and mandatory field verification, and supplement missing fields; A collaborative operation conflict management rule, which is used to start the conflict adjudication rule unit and set a dynamic permission matrix based on the medical permission hierarchy; when multi-institutional concurrent operations are detected, trigger the chained evidence storage module to implement a temporary locking mechanism for the vouchers being collaboratively processed, and start a priority adjudication process, and only the financial department of the general hospital has the right to modify the medical insurance type information; the voucher locking mechanism is implemented through the medical operation log unit; A medical insurance settlement compliance rule, which is used to call the national medical insurance data service interface platform through the medical insurance rule management unit to automatically check whether the medical expenses meet the reimbursement regulations, control the upper limit of the reimbursement amount, and review the qualification for seeking medical treatment across provinces; A data security and audit rule, which is used to protect sensitive information by using zero-knowledge proof and homomorphic encryption algorithms in the medical blockchain network, and at the same time completely record all operation processes through the chained evidence storage module to ensure that the entire process of data modification is traceable.

[0013] Preferably, the collaborative operation conflict management rule includes: e1. When it is detected that multiple institutions modify the vouchers of the same patient at the same time, trigger the priority determination process of the dynamic adjudication module; e2. Mark the vouchers being collaboratively processed as in a temporarily locked state to prevent unauthorized overwriting. The temporarily locked state is recorded by the medical operation log unit with the locking time and the operator; e3. Dynamically allocate editable field permissions according to the medical authority level.

[0014] Preferably, the dynamic adjudication module further includes an extended adjudication rule unit for setting specific business scenarios, and the extended adjudication rule unit includes: d1. Special department permission exception rule: When a clinical department has special approval authority, it can break through the default authority level for specific operations; d2. Emergency operation green channel rule: Automatically elevate the priority of the modification of vouchers marked as "emergency"; d3. Multi-factor adjudication rule: Used for weighted adjudication by comprehensively considering the operator's professional title, business urgency, and historical operation accuracy rate.

[0015] Preferably, the heterogeneous system dynamic adaptation module includes: A data acquisition unit for real-time obtaining the field definitions, subject coding rules, and version change logs of the ERP systems of each branch hospital; A model training unit, based on a deep learning framework, uses historical operation data and national medical insurance standard codes as the training set to generate a heterogeneous system field mapping model; A real-time adaptation unit for monitoring version change events of the branch hospital ERP system. When a change in fields or coding rules is detected, it automatically triggers incremental learning of the model and updates the mapping relationship table; A conflict resolution unit performs historical record backtracking or manual annotation intervention on low-confidence mapping results to ensure data conversion integrity.

[0016] A conflict handling method for a blockchain-based cross-platform voucher synchronization system for accounting vouchers includes the following steps: S1. Receive the modification request from the branch hospital node through the node management unit of the medical alliance chain network module, and verify the digital identity certificate of the branch hospital node; S2. Call the medical insurance rule management unit of the self-healing synchronization module to check the compliance of the expenses. If a conflict between the expenses and the medical insurance rules is found during the compliance pre-check, trigger the logical conflict handling process; S3. When a field missing or format conflict is detected, start the data format unification rule to automatically complete the missing fields and convert the medical subject coding; S4. Encrypt the data using zero-knowledge proof technology and push it to all verification nodes in real time; S5. Generate a new block through the chained evidence storage module, store the operation record, and update the patient data index.

[0017] When it is detected that multiple institutions concurrently modify the vouchers of the same patient, execute the conflict adjudication process, which includes the following steps: S11. When the chained evidence storage module detects that multiple institutions modify the same voucher simultaneously, it triggers the conflict handling process of the dynamic adjudication module; S12. According to the preset medical authority hierarchy, give priority to the operation results of the general hospital; S13. If the conflict occurs between institutions at the same level, compare the millisecond-level timestamps generated by the medical trust timestamp unit, and take the latest operation as the standard; S14. After the adjudication result is encrypted, it is updated to the blockchain versions of all nodes, and a difference report including the operator's identity and timestamp is generated.

[0018] Logical conflict handling includes the following steps: S21. Monitor the output of the medical insurance rule management unit in real time and identify the following problems: the cost exceeds the medical insurance limit; the diagnosis and treatment items are not in the medical insurance catalog; the cross-provincial settlement qualification is abnormal; S22. Call the medical data correction unit to adjust the drug codes and recalculate the reimbursement amount; S23. If the automatic correction fails, push the conflict data to the audit panel of the general hospital and retain the operation snapshot; S24. Encrypt the manual review result to generate a new block, recording the correction process and the operator's signature.

[0019] Compared with the prior art, the beneficial effects achieved by the invention are as follows: The present invention significantly improves the processing efficiency and accuracy of medical financial data by constructing a multi-layer collaborative mechanism; the system uses the medical alliance chain network module to achieve seamless docking of heterogeneous ERP systems, automatically converts the accounting voucher format and medical subject codes through smart contracts, solves the problem of traditional data islands, and shortens the data synchronization time across branches and systems from several minutes to seconds; at the same time, combined with the permission level control of the dynamic adjudication module, the millisecond-level timestamp adjudication of the National Time Service Center, and the real-time verification of medical insurance rules, effectively resolve the conflicts of concurrent operations of multiple institutions, thereby increasing the automatic adjudication rate of complex scenarios to 82% and ensuring the general hospital's control over key data; solve the high error rate problem of manually maintaining mapping rules in the background technology through the heterogeneous system dynamic adaptation module; the self-healing synchronization module automatically corrects drug code errors and intercepts excessive reimbursement expenses by docking with the national medical insurance platform in real time, reducing the medical insurance settlement error rate from 9.8% to 0.5%, and significantly reducing the need for manual intervention.

[0020] II. The present invention constructs a full-process trusted data management system through a chained evidence storage module and zero-knowledge proof technology; all operation records are stored through an immutable blockchain structure to achieve millisecond-level operation traceability. Auditors can quickly retrieve the complete voucher version and operation track at any time point through the patient ID. At the same time, the medical consortium chain network adopts homomorphic encryption technology to protect patient privacy during real-time data synchronization. The distributed storage of encrypted data fingerprints not only saves 83% of the on-chain space but also realizes field-level permission control when sharing cross-institutional data; this solution reduces the labor cost of financial reconciliation in the scenario of branch hospital collaboration, while ensuring 100% operation traceability, providing a safe, efficient, and compliant cross-platform data management model for the medical industry. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 Schematic diagram of the main module structure of the system of the invention; Figure 2 Flowchart of the system conflict handling method of the invention; Figure 3 Schematic diagram of the conflict adjudication process of the invention; Figure 4 Schematic diagram of the medical consortium chain network module of the invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0022] The following provides a detailed description of the specific embodiments of the invention, but it should be understood that the protection scope of the invention is not limited by the specific embodiments.

[0023] Embodiment 1: Please refer to Figures 1-4 , the invention provides a technical solution: A cross-platform voucher synchronization system for accounting vouchers based on blockchain, comprising the following modules: A dynamic adjudication module, which is used to automatically adjudicate conflict operations according to the preset medical permission level and trusted timestamp when different branch hospitals use heterogeneous ERP systems to modify the expense vouchers of the same patient. The medical permission level is: General Hospital Finance Department > Branch Hospital Finance Department > Clinical Department; A chained evidence storage module, which is used to record all expense modification events and store the historical data of the patient's expense vouchers, and can query the historical data at any time point through the patient's ID account; A self-healing synchronization module, which is used to correct the conflicts between medical expenses and medical insurance types according to the medical insurance policy rule library and the national medical insurance data service interface platform to ensure the ultimate consistency of cross-platform data; A medical consortium chain network module, which is used to add the general hospital, branch hospitals, and medical insurance institutions as nodes, and build-in preset rules, and encrypt and synchronize the patient's expense vouchers in real-time through automatic execution of the preset rules in a zero-knowledge proof manner.

[0024] In the above solution, through the coordinated operation of four core modules, namely the dynamic adjudication module, the chained evidence storage module, the self-healing synchronization module, and the medical alliance chain network module, the problem of cross-platform data synchronization in medical institutions is solved. When a branch modifies a patient's expense voucher through different ERP systems, the dynamic adjudication module first determines the operation priority according to the preset permission level. If multiple branches operate simultaneously, the millisecond-level timestamp of the National Time Service Center is used to select the latest operation. If it is found that the expense amount conflicts with the medical insurance type, such as exceeding the reimbursement limit or the item not matching, it is pushed to the main hospital for manual review. The chained evidence storage module stores each operation record as immutable data on the blockchain, and the complete historical version at any time point can be queried through the patient ID. The self-healing synchronization module automatically connects to the national medical insurance platform before data synchronization to verify whether the expenses comply with the reimbursement rules. In case of incorrect drug coding or excessive amount, the national medical insurance database is called in real time to correct the data. Finally, the medical alliance chain network module encrypts the data using zero-knowledge proof and synchronizes the corrected vouchers to the main hospital, branch, and medical insurance institution nodes in real time to ensure that all platform data is consistent. Through the four-step linkage of permission control, blockchain evidence storage, rule correction, and encrypted synchronization in the above solution, accurate synchronization and secure auditing of cross-system data are achieved.

[0025] In another embodiment, the dynamic adjudication module includes: A medical permission definition unit for presetting medical operation priority rules and binding the operator's medical digital certificate. The medical operation priority rules are: Main Hospital Finance Department > Branch Finance Department > Clinical Department; the medical digital certificate contains information such as the operator's department, professional title, and permission level. A medical trusted timestamp unit for accessing the authoritative time source of the National Time Service Center to generate a globally unique timestamp for each operation in the system, and the accuracy of the timestamp is millisecond-level; this unit ensures that all patient expense voucher operations are accompanied by an immutable timestamp. A conflict adjudication rule unit, when detecting that multiple branches modify the same patient's voucher, automatically overwrite according to the following rules: a1. Main Hospital Priority Rule: When the Main Hospital Finance Department and the Branch Finance Department modify simultaneously, the operation of the main hospital shall prevail. a2. Latest Timestamp Rule: If there is a conflict between branches at the same level, the operation with the latest timestamp shall prevail. a3. Logical Conflict Handling Rule: When there is a conflict between the expense amount and the medical insurance type logic, the system automatically pushes the conflicting operation to the audit panel of the main hospital for manual verification. This conflict includes but is not limited to the following situations: b1. The expense amount exceeds the reimbursement ratio limit of this medical insurance type. b2. The expense item is not within the reimbursement catalog range of this medical insurance type. b3. The cost amount exceeds the annual cumulative limit of this type of medical insurance.

[0026] In the above solution, the dynamic adjudication module of this embodiment realizes intelligent adjudication for cross-platform operations through the collaborative work of three core units: the medical permission definition unit, the medical trusted timestamp unit, and the conflict adjudication rule unit. The specific method is as follows: The medical permission definition unit pre-sets the priority rule of "General Hospital Finance Department > Branch Hospital Finance Department > Clinical Department" and binds this rule to the operator's medical digital certificate. Each operator's certificate contains information such as their department, professional title, and permission level to ensure that the operation identity can be verified; the medical trusted timestamp unit accesses the time source of the National Time Service Center in real time to generate global timestamps with millisecond-level accuracy for each operation. These timestamps are bound to the operation data to form an immutable time record. When the system detects that multiple branch hospitals modify the vouchers of the same patient simultaneously, the conflict adjudication rule unit immediately starts the processing process: First, the General Hospital priority rule is executed. If there is a conflict between the General Hospital and the branch hospital operations, the operation result of the General Hospital is automatically adopted; for the operation conflicts between branch hospitals at the same level, the most recent operation is selected according to the latest timestamp rule; when it is found that there is a logical conflict between the cost amount and the medical insurance type, such as exceeding the reimbursement ratio, inconsistent items, or exceeding the annual limit, the system automatically pushes the relevant operations to the General Hospital audit panel for final verification by the manual. This system realizes the functions of permission grading, time sequence determination, and logical verification, ensuring that the cross-platform operation of the medical financial management system not only conforms to the organizational permission architecture but also maintains the time accuracy of the data and the business compliance.

[0027] Furthermore, the dynamic adjudication module further includes an extended adjudication rule unit for setting specific business scenarios. The extended adjudication rule unit includes: d1. Special department permission exception rule: When a clinical department has special approval authority, it can break through the default permission level for specific operations; d2. Emergency operation green channel rule: Automatically elevate the priority of voucher modifications marked as "emergency"; d3. Multi-factor adjudication rule: Used for weighted adjudication by comprehensively considering the operator's professional title, business urgency, and historical operation accuracy.

[0028] The working methods of the above extended adjudication rule units are described in combination with specific scenarios: 1. Special department permission exception rule The application scenario is: The cardiac surgery department needs to urgently adjust the high-value consumable usage record By default, the permission of the clinical department is level 3, and modifications require review by the branch hospital finance department with a permission level of 2; When the cardiac surgery department director holds the "high-value consumable special approval" digital certificate, the following python code is executed: if the operating department == "Cardiac Surgery" and the certificate.contains("Consumable Approval Permission"): Allow direct modification of consumable-related fields Generate a blockchain record with a special identifier The above technical implementation method is as follows: Add an extended permission field to the medical digital certificate, mark the "privileged operation" type during blockchain evidence storage, and automatically record the reason for permission breakthrough in the audit log; 2. Emergency Operation Green Channel Rules The actual situation is: Emergency treatment process; Operations marked as emergency automatically obtain: The timestamp weight is increased, and this weight coefficient is multiplied by 1.5 times And the permission is temporarily upgraded, and the clinical department is upgraded to the branch level. The processing logic of this system is to execute the following sql code: UPDATE Operation Queue SET Priority = Emergency Coefficient × Basic Priority WHERE Operation Mark = "Emergency" 3. Multi-Factor Adjudication Rules When a conflict occurs, the system automatically calculates in the following way: Comprehensive Score = (Professional Title Score × 0.3) + (Emergency Score × 0.4) + (Historical Correct Rate × 0.3) For example: Two deputy directors of branches modify the surgical fee at the same time. The operator in Branch A has a historical correct rate of 98% and is marked as "urgent"; the operator in Branch B has a historical correct rate of 92% and is a regular operation; the calculation result is: A Score = (0.9 × 0.3)+(60 × 0.4)+(98 × 0.3) = 72.3 B Score = (0.9 × 0.3)+(40 × 0.4)+(92 × 0.3) = 58.7 Based on the above calculated scores, the system automatically adopts the operation of Branch A. The above calculation uses a streaming calculation engine to process multi-factor adjudication to ensure that complex weight calculations are completed within 200ms. Through the above calculation for intelligent processing, the automatic processing rate of complex conflicts has been increased from 35% to 82%, and the need for manual intervention has been reduced by 57%.

[0029] In another embodiment, the chained evidence storage module includes: Medical operation log unit, which stores operation events in chronological order using Apache Kafka. Each log contains the operating department ID, timestamp, modified content summary, and electronic signature; historical data is hashed to form a traceable historical version; Medical blockchain version unit, which is used to process historical data through a hashing algorithm to generate traceable complete historical versions, and store these versions in a Merkle tree structure on the blockchain; each historical version contains the complete status of the patient's expense voucher at a specific time point, and is associated and indexed through the patient ID and a unique hash value to ensure that the data is verifiable and tamper-proof; Medical data tracing unit, which is used to provide an accurate historical data tracing function. When the patient ID and a specified time range are input, the system will intelligently analyze all operation records within that period and generate a difference report containing the following detailed information: c1. Specific change time points; c2. Comparison of data before and after modification; c3. Operator identity information; c4. Associated blockchain transaction hash value.

[0030] In the above embodiment, the process of depositing medical financial data is divided into three steps; first, whenever a hospital branch modifies a patient's expense, the system will immediately record the operation details, including which department made the modification, the modification time accurate to milliseconds, what was specifically modified, and the electronic signature of the operator. The above records will be saved in a high-speed processed message queue in chronological order to ensure that all operations can be completely traced.

[0031] Next, the system will package and process all operation records within the above time period every hour. Through special encryption calculations, these records will be organized into interrelated data blocks. Each data block contains the patient number, operation time period, and a complete data snapshot, and these data blocks will be securely stored on the blockchain network. This design makes the data neither tamperable nor able to be synchronized and updated among different hospital branches.

[0032] When it is necessary to check accounts or conduct an audit, simply input the patient number and date, and the system can quickly find all relevant operation records, automatically check the integrity of the data, and then generate a detailed report clearly showing the specific time of each modification, the comparison of data before and after modification, the information of the modifier, and the storage location on the blockchain. This is both convenient for financial verification and ensures that every operation is traceable.

[0033] Furthermore, the self-healing synchronization module includes: Medical insurance rule management unit, which is used to store and manage local medical insurance policy data. The local medical insurance policy data includes reimbursement ratios, limits, and medical insurance catalog information. When it is found that there is a conflict between the expense amount and the medical insurance type, it will automatically connect to the national medical insurance platform interface for correction. The conflicts include: d1. The expense amount exceeds the upper limit of the reimbursement ratio specified for this medical insurance type; d2. The expense item is not within the reimbursement scope verified and approved by the medical insurance rule management unit; d3. The expense amount exceeds the annual reimbursement total limit of this medical insurance type; The medical data correction unit is used to automatically connect to the medical blockchain version unit of the chained evidence storage module and call the national medical insurance drug database for standardized conversion when it is found that the drug code does not match the medical insurance catalog information.

[0034] The self-healing synchronization module of the above solution realizes the intelligent review and automatic correction of medical insurance expenses through the medical insurance rule management unit and the medical data correction unit; among them, the medical insurance rule management unit stores the local medical insurance reimbursement policies and checks in real time whether the expense data meets the requirements such as reimbursement ratio, item scope, and annual limit; when problems such as overlimit, out-of-scope, or exceeding the annual total amount are found, it automatically connects to the national medical insurance platform to obtain the latest policy for correction; The medical data correction unit specifically deals with the drug code matching problem. When it detects that the drug code is inconsistent with the medical insurance catalog, it automatically calls the national medical insurance drug database to convert the drug information into a standard code to ensure the accuracy of the reimbursement items. Through the collaborative work of these two units, it can not only prevent illegal medical insurance reimbursement but also automatically correct data errors, greatly improving the accuracy and efficiency of medical insurance settlement.

[0035] Furthermore, the dynamic adjudication module also includes a conflict probability prediction unit. The conflict probability prediction unit is used to train a time series model based on historical operation data, predict the probability value of conflicts caused by the current operation, and trigger the manual review process in advance when the probability exceeds the preset threshold; The conflict probability prediction unit of the dynamic adjudication module includes: The data collection subunit is used to collect in real time historical operation data including the operator's department level, modified field type, timestamp, conflict type, and adjudication result; the model training subunit constructs a conflict prediction model based on the LSTM network, inputs the operation sequence sorted by timestamp and outputs the conflict probability value, and the model training data covers the collaborative operation records of multiple branches within 3 years; the probability calculation subunit is used to generate a feature vector according to the department level, field sensitivity, and operation frequency of the current operation, input it into the model to calculate the conflict probability; the threshold determination subunit freezes the operation when the conflict probability exceeds the dynamic threshold, generates a warning event and pushes it to the audit panel of the main hospital, and calls the chained evidence storage module to generate a historical report including the comparison of data before and after modification; the model optimization subunit corrects the model parameters according to the manual verification result and dynamically adjusts the threshold based on the corrected accuracy offset.

[0036] The conflict probability prediction unit of the above solution can achieve intelligent prediction, collect the operation records of the ERP systems of each branch in real time through the data collection layer, including information such as the operation department, modified content, and accurate time, and establish a three-year historical database.

[0037] In addition, the model training layer uses the LSTM neural network to analyze historical data and train a conflict prediction model with an accuracy rate of 89.7%.

[0038] Furthermore, the real-time prediction layer can assess operational risks within 80 milliseconds, and immediately freeze the operation and notify the headquarters when the risk exceeds the threshold.

[0039] The system can also automatically adjust prediction parameters, such as increasing the risk factor of nighttime emergency operations by 1.2 times, and automatically updating the judgment criteria every 15 minutes based on the system load. After optimization, the accuracy of emergency operation prediction increased from 68% to 86%. The system is designed to intercept 85% of high-risk operations in advance, reduce the need for manual intervention by 52%, and speed up system updates.

[0040] In another embodiment, the medical alliance chain network module includes: The node management unit is used to add the main hospital, branch hospitals, and medical insurance institutions as verification nodes to the network through a permissioned chain mechanism. Each node requires digital identity authentication; Automatic execution rule unit, which contains preset rules for cross-institutional data review and security control; The data security protection unit uses zero-knowledge proof and homomorphic encryption algorithms to encrypt sensitive data. The encrypted data fingerprint is stored in the medical blockchain version unit. The data sharing synchronization unit is used to push data change information in real time, and uses distributed storage technology to ensure that all node data is unified and the operation records are complete and traceable.

[0041] In the above solution, the node management unit uses a permissioned chain mechanism to strictly authenticate the identity of the main hospital, branch hospitals, and medical insurance agency nodes; the automatic rule execution unit has built-in smart contracts to automatically execute cross-institutional data review and security control rules; the data security protection unit uses zero-knowledge proof and homomorphic encryption technology to complete encryption processing without exposing the original data, and only the data fingerprint is stored on the chain; The data sharing and synchronization unit pushes encrypted data changes in real time, ensuring data consistency across all nodes and full traceability of operations through distributed storage. This solution not only protects the privacy and security of medical financial data, but also enables real-time synchronization and trusted sharing of data across institutions, effectively resolving the coexistence of data silos and security risks in traditional medical systems.

[0042] Furthermore, the preset rules include: Unified data format rules are used to automatically convert accounting documents in heterogeneous ERP systems, implement field mapping, medical subject code conversion, and mandatory field verification, and supplement missing fields; Collaborative operation conflict management rules are used to start the conflict adjudication rule unit and set a dynamic permission matrix based on the medical permission hierarchy; when multi-institutional concurrent operations are detected, trigger the chained evidence storage module to implement a temporary locking mechanism for the vouchers in collaborative processing, start the priority adjudication process, and only the general hospital's finance department has the right to modify the medical insurance type information; the voucher locking mechanism is implemented through the medical operation log unit; Medical insurance settlement compliance rules are used to call the national medical insurance data service interface platform through the medical insurance rule management unit, automatically check whether the medical expenses comply with the reimbursement regulations, control the upper limit of the reimbursement amount, and review the qualification for cross-provincial medical treatment; Data security and audit rules are used to protect sensitive information in the medical blockchain network using zero-knowledge proof and homomorphic encryption algorithms, and at the same time, completely record all operation processes through the chained evidence storage module to ensure that data modification is traceable throughout the process.

[0043] The collaborative operation conflict management rules include: e1. When it is detected that multiple institutions modify the vouchers of the same patient simultaneously, trigger the priority determination process of the dynamic adjudication module; e2. Mark the vouchers being collaboratively processed as in a temporary locked state to prevent unauthorized overwriting. The temporary locked state is recorded by the medical operation log unit with the locking time and the operator; e3. Dynamically allocate editable field permissions according to the medical permission hierarchy.

[0044] The data format unified rules of this solution eliminate the data barriers between different ERP systems, and realize the automatic conversion and completion of fields and subject codes, solving the docking problems caused by system heterogeneity; the collaborative operation conflict management rules prevent data overwriting or chaos caused by multiple institutions modifying simultaneously through dynamic permission control and voucher locking mechanisms, thus ensuring the general hospital's exclusive control right over key medical insurance information; the medical insurance settlement compliance rules are connected to the national medical insurance platform in real time, automatically intercepting excessive, out-of-scope or non-compliant reimbursement applications to avoid the risk of medical insurance violations; Data security and audit rules meet the requirements of medical financial audits while protecting patient privacy through advanced encryption technology and complete operation traceability. The above rules jointly constitute a collaborative management system that is both strictly regulated and flexible and efficient, greatly improving the accuracy, security and processing efficiency of medical financial data.

[0045] Furthermore, the heterogeneous system dynamic adaptation module includes: A data collection unit for real-time obtaining the field definitions, subject coding rules and version change logs of the ERP systems of each branch hospital; A model training unit, based on a deep learning framework, generates a heterogeneous system field mapping model using historical operation data and national medical insurance standard codes as the training set; A real-time adaptation unit for monitoring the version change events of the branch hospital ERP system. When detecting changes in fields or coding rules, it automatically triggers incremental learning of the model and updates the mapping relationship table. A conflict resolution unit that retraces the historical records or intervenes with manual annotation for low-confidence mapping results to ensure the integrity of data conversion.

[0046] The working mode of this heterogeneous system dynamic adaptation module is that the data acquisition unit continuously monitors the data structure changes of each branch hospital ERP system, including key information such as field definitions and subject coding. The model training unit, based on the national medical insurance standard coding, analyzes historical data through deep learning to establish a field mapping relationship model between systems. The real-time adaptation unit automatically triggers model updates when detecting system upgrades or rule changes to maintain the timeliness of the mapping relationship. The conflict resolution unit performs secondary processing on uncertain mapping results to ensure conversion accuracy through historical record retracing or manual intervention.

[0047] This heterogeneous system dynamic adaptation module realizes automatic cross-system data conversion, reducing the manual docking workload by about 70%. At the same time, the system change response time is shortened from 3 - 5 days in the traditional solution to within 2 hours, the mapping accuracy rate is increased to over 95%, and the data conversion error rate is reduced. Through the incremental learning mechanism, the model update efficiency is improved, and it provides standardized data input for blockchain evidence storage to ensure cross-platform data consistency. This heterogeneous system dynamic adaptation module effectively solves the problem of inconsistent data formats caused by the coexistence of multiple ERP systems in the medical financial system.

[0048] Embodiment 5

[0049] Combined with the above embodiments, it is further obtained that a conflict handling method for implementing a cross-platform voucher synchronization system of accounting vouchers based on blockchain includes the following steps: S1. Receive the modification request from the branch hospital node through the node management unit of the medical alliance chain network module and verify the digital identity certificate of the branch hospital node. S2. Invoke the medical insurance rule management unit of the self-healing synchronization module to check the compliance of the expenses. If a conflict between the expenses and the medical insurance rules is found during the compliance pre-check, trigger the logical conflict handling process. S3. When detecting a field missing or format conflict, start the data format unification rule to automatically complete the missing fields and convert the medical subject coding. S4. Encrypt the data using zero-knowledge proof technology and push it to all verification nodes in real time. S5. Generate a new block through the chained evidence storage module, store the operation record, and update the patient data index.

[0050] When detecting that multiple institutions concurrently modify the credentials of the same patient, execute the conflict adjudication process, which includes the following steps: S11. When the chained evidence storage module detects that multiple institutions modify the same credential simultaneously, trigger the conflict handling process of the dynamic adjudication module; S12. According to the preset medical authority hierarchy, where the medical authority hierarchy is General Hospital > Branch Hospital > Department, preferentially adopt the operation result of the General Hospital; S13. If a conflict occurs between institutions at the same level, compare the millisecond-level timestamps generated by the medical credibility timestamp unit, and take the latest operation as the standard; S14. After encrypting the adjudication result, update it to the blockchain versions of all nodes, and generate a difference report containing the operator's identity and timestamp.

[0051] Logical conflict handling includes the following steps: S21. Real-time monitor the output of the medical insurance rule management unit and identify the following problems: the cost exceeds the medical insurance limit; the diagnosis and treatment items are not in the medical insurance catalog; the cross-provincial settlement qualification is abnormal; S22. Invoke the medical data correction unit to adjust the drug codes and recalculate the reimbursement amount; S23. If the automatic correction fails, push the conflict data to the General Hospital audit panel and retain the operation snapshot; S24. After encrypting the manual review result, generate a new block to record the correction process and the operator's signature.

[0052] The following is an explanation of the conflict adjudication process of the system in combination with the specific scenarios of the hospital scenario solution detailed process: Specific scenario: A large tertiary hospital has multiple branch hospitals, and each branch hospital uses a different ERP system. For example, Branch Hospital A uses SAP, and Branch Hospital B uses Kingdee. At the same time, the medical insurance department, finance department, and clinical departments need to collaborate to process patient expenses and reimbursement data. The problem that occurs during the actual operation is that the finance department of Branch Hospital A modifies the treatment cost amount of a certain patient from 5000 yuan to 6000 yuan, and at the same time, the medical insurance department of Branch Hospital B changes the patient's medical insurance type from urban medical insurance to new rural cooperative medical care. The system cannot determine which party's operation should prevail.

[0053] The conflict handling method of the cross-platform voucher synchronization system for accounting vouchers based on the blockchain in combination with the above solution is specifically implemented as follows: The finance department of Branch Hospital A modifies the patient's treatment cost from 5000 yuan to 6000 yuan in the SAP system; the medical insurance department of Branch Hospital B changes the medical insurance type from "urban medical insurance" to "new rural cooperative medical care" in the Kingdee system, and the time difference between the two operations < 100 milliseconds.

[0054] The above operations trigger the entry into the data conflict handling process, and the data conflict handling steps are as follows; First, the dynamic adjudication module intervenes and performs verification through the medical authority definition unit: The operator of Branch A is the Chief Accountant of the Finance Department, whose authority level is 2. The operator of Branch B is the Deputy Director of the Medical Insurance Department, whose authority level is 2. The judgment result is a conflict of same level. Furthermore, the comparison is performed through the medical trusted timestamp unit: Branch A operation timestamp: 2023-05-10 14:00:00.123 Branch B operation timestamp: 2023-05-10 14:00:00.156, so Branch B operation is updated; Execute the conflict resolution and adopt the New Rural Cooperative Medical Insurance type modification of Branch B, but retain the 6,000 yuan fee modification of Branch A; Furthermore, the self-healing synchronization module is verified and the medical insurance policy interface is called for inspection: The upper limit of reimbursement for this treatment project under the New Rural Cooperative Medical System is 5,500 yuan, and the cost of 6,000 yuan exceeds the limit. The system automatically executes the following python code: If the cost is greater than the current medical insurance type limit: Send warning to the General Hospital Audit Panel Temporarily lock the credential modification permission For the execution steps, the audit process can be traced. Step 1: Audit Department enters patient ID "P20230510001" and selects time range: 2023-05-10 13:00 to 14:30 Step 2: The chained evidence module begins to respond and returns the Merkle tree structure version record: Version 1 (13:20:00): Initial status: 5,000 yuan / urban medical insurance Version 2 (14:00:00.123): Branch A modified the amount to 6,000 yuan Version 3 (14:00:00.156): Branch B changed its medical insurance to the New Rural Cooperative Medical System Version 4 (14:00:30): The system triggers an overage warning Step 3: Generate a difference report, and the comparison is shown as follows: [Key Changes] 14:00:00 Operator: Accountant Zhang from Branch A (Employee No. 10086) Modification content: Amount changed from 5000 to 6000 Blockchain hash: 0x3a7b...c21d [Key Changes] 14:00:00 Operator: Director Li of Branch B (Employee No. 10092) Modification content: Medical insurance type changed from urban to New Rural Cooperative Medical Care Blockchain hash: 0x9e2f...d54a Furthermore, when the system detects a medical insurance overpayment conflict, it will first automatically freeze the settlement of the expense, and at the same time, urgently push the pending task to the Audit Department of the General Hospital and notify the Finance Department of Branch A.

[0055] Chief Wang, the auditor of the General Hospital, queried the blockchain history records and used SQL statements to retrieve all operation versions of patient "P20230510001" between 2023-05-10 13:00 and 14:30 to fully understand the modification process.

[0056] Based on the verification results, the auditor can choose two treatment options: Option A maintains the amount of 6,000 yuan but activates the special reimbursement channel, or Option B adjusts the amount back to the standard limit of 5,500 yuan.

[0057] The final processing result will generate a new version to record the manual review decision, and will be synchronously updated to the ERP systems of all branches through the blockchain network to ensure data consistency among various institutions.

[0058] The above process not only ensures the timely handling of abnormal situations, but also makes the entire processing process traceable through blockchain evidence storage.

[0059] This blockchain-based cross-platform accounting voucher synchronization system is not limited to the application of medical systems in hospitals, but can be adapted to applications in other fields: This blockchain-based cross-platform synchronization system for accounting documents can be extended to the financial, supply chain and government sectors, solving core problems in multi-system collaboration.

[0060] In the financial sector, the system implements intelligent adjudication and real-time synchronization of cross-border payment instructions by establishing a hierarchical authority structure and a millisecond-level timestamp mechanism. The authority hierarchy can be central bank > commercial bank > branch. For example, during interbank cross-border payments, the dynamic adjudication module automatically handles exchange rate conflicts, the chain-based evidence storage module synchronizes SWIFT messages with local clearing data, and the self-healing synchronization module connects to the foreign exchange management policy database in real time to correct exchange rate deviations, ensuring the compliance and timeliness of cross-border fund settlements. Furthermore, the consortium chain network module uses zero-knowledge proofs to encrypt transaction details, meeting anti-money laundering regulatory requirements while protecting commercial privacy.

[0061] In the field of supply chain management, the system automatically converts the material codes of ERP systems such as SAP and Oracle through a heterogeneous adaptation module, eliminating data barriers for multinational enterprises. It automatically executes the three-way matching of purchase orders, invoices, and payments through smart contracts, and a conflict prediction model identifies supplier data differences in advance. In the cold chain logistics scenario, the temperature sensor data is uploaded to the blockchain for real-time evidence storage. When an anomaly is detected, the emergency operation channel automatically raises the processing priority and triggers emergency logistics scheduling. Blockchain evidence storage ensures the full traceability of the entire process of drug circulation, reduces the temperature data tampering rate by 90%, and shortens the quality problem traceability time from weeks to minutes.

[0062] The above are only several specific embodiments of the invention disclosed. However, the invention embodiments are not limited thereto, and any changes that can be conceived by those skilled in the art should fall within the protection scope of the invention.

Claims

1. A cross-platform voucher synchronization system for accounting vouchers based on blockchain, characterized in that, It includes the following modules: A dynamic adjudication module, which is used to automatically adjudicate conflicting operations according to the preset medical authority level and trusted timestamp when different branch hospitals use heterogeneous ERP systems to modify the expense vouchers of the same patient. The medical authority level is: General Hospital Finance Department > Branch Hospital Finance Department > Clinical Department; A chained evidence storage module, which is used to record all expense modification events and store the historical data of the patient's expense vouchers. It can query the historical data at any time point through the patient's ID account; A self-healing synchronization module, which is used to correct the conflict between medical expenses and medical insurance types according to the medical insurance policy rule base and the national medical insurance data service interface platform to ensure the ultimate consistency of cross-platform data; A medical consortium chain network module, which is used to add the general hospital, branch hospitals and medical insurance institutions as nodes and build in preset rules. The patient's expense vouchers are encrypted and stored in real time in a zero-knowledge proof manner by automatically executing the preset rules, It also includes a heterogeneous system dynamic adaptation module, which is used to automatically generate a field mapping relationship table for different ERP systems through a deep learning model and adapt to the version changes of each branch hospital system in real time.

2. The cross-platform voucher synchronization system for accounting vouchers based on blockchain according to claim 1, characterized in that The dynamic adjudication module includes: A medical authority definition unit, which is used to preset the medical operation priority rules and bind the operator's medical digital certificate. The medical operation priority rules are: General Hospital Finance Department > Branch Hospital Finance Department > Clinical Department; The medical digital certificate contains information such as the operator's department, professional title and authority level; A medical trusted timestamp unit, which is used to access the authoritative time source of the National Time Service Center to generate a globally unique timestamp for each operation in the system, and the accuracy of the timestamp is millisecond-level; This unit ensures that all patient expense voucher operations are attached with an immutable timestamp; A conflict adjudication rule unit. When it detects that multiple branch hospitals modify the vouchers of the same patient, it automatically overrides according to the following rules: a1. General Hospital Priority Rule: When the General Hospital Finance Department and the Branch Hospital Finance Department modify at the same time, the operation of the General Hospital shall prevail; a2. Latest Timestamp Rule: If there is a conflict between peer branch hospitals, the operation with the latest timestamp shall prevail; a3. Logical Conflict Handling Rule: When there is a conflict between the expense amount and the medical insurance type logic, the system automatically pushes the conflicting operation to the General Hospital audit panel for manual verification. The conflicts include but are not limited to the following situations: b1. The expense amount exceeds the reimbursement ratio limit of this medical insurance type; b2. The expense item is not within the reimbursement catalog of this medical insurance type; b3. The expense amount exceeds the annual cumulative limit of this medical insurance type; The dynamic adjudication module also includes a conflict probability prediction unit, which is used to train a time series model based on historical operation data to predict the probability value of the current operation causing a conflict, and trigger the manual review process in advance when the probability exceeds the preset threshold.

3. The cross-platform voucher synchronization system for accounting vouchers based on blockchain according to claim 1, characterized in that The conflict probability prediction unit of the dynamic adjudication module includes: The data collection sub-unit is used to collect historical operation data including the operator's department level, modified field type, timestamp, conflict type and adjudication result in real time; the model training sub-unit constructs a conflict prediction model based on the LSTM network, inputs the operation sequence sorted by timestamp and outputs the conflict probability value, and the model training data covers the collaborative operation records of multiple branches within 3 years; the probability calculation sub-unit is used to generate a feature vector according to the department level, field sensitivity and operation frequency of the current operation, and inputs the model to calculate the conflict probability; the threshold determination sub-unit freezes the operation when the conflict probability exceeds the dynamic threshold, generates a warning event and pushes it to the head hospital audit panel, and calls the chain evidence storage module to generate a historical report including the comparison of data before and after modification; the model optimization sub-unit corrects the model parameters according to the manual verification result and dynamically adjusts the threshold based on the corrected accuracy offset.

4. The cross-platform voucher synchronization system for accounting vouchers based on blockchain according to claim 1, characterized in that The chain evidence storage module includes: The medical operation log unit stores operation events in chronological order using Apache Kafka. Each log includes the operation department ID, timestamp, modified content summary and electronic signature; the historical data forms a traceable historical version after being hashed; The medical blockchain version unit is used to process historical data through the hashing algorithm to generate a complete and traceable historical version, and store these versions in a Merkle tree structure on the blockchain; each historical version includes the complete status of the patient's expense voucher at a specific time point, and is associated and indexed through the patient ID and unique hash value to ensure that the data is verifiable and tamper-proof; The medical data traceability unit is used to provide an accurate historical data traceability function. When the patient ID and a specified time range are input, the system will intelligently analyze all operation records during this period and generate a difference report containing the following detailed information: c1. Specific change time points; c2. Comparison of data before and after modification; c3. Operator identity information; c4. Associated blockchain transaction hash value.

5. The cross-platform voucher synchronization system for accounting vouchers based on blockchain according to claim 1, wherein The self-healing synchronization module includes: The medical insurance rule management unit is used to store and manage local medical insurance policy data. The local medical insurance policy data includes reimbursement ratio, limit and medical insurance catalog information. When a conflict is found between the expense amount and the medical insurance type, it automatically connects to the national medical insurance platform interface for correction. The conflicts include: d1. The expense amount exceeds the upper limit of the reimbursement ratio specified for this medical insurance type; d2. The expense item is not within the reimbursement scope verified and passed by the medical insurance rule management unit; d3. The expense amount exceeds the annual reimbursement total limit for this medical insurance type; The medical data correction unit is used to automatically connect to the medical blockchain version unit of the chain evidence storage module and call the national medical insurance drug database for standard conversion when it is found that the drug code does not match the medical insurance catalog information.

6. The cross-platform voucher synchronization system for accounting vouchers based on blockchain according to claim 1, characterized in that, The medical consortium chain network module includes: The node management unit is used to add the head hospital, branch hospitals and medical insurance institutions as verification nodes to the network through the permission chain mechanism, and each node requires digital identity authentication; The automatic execution rule unit contains preset rules for cross-institutional data review and security control; The data security protection unit encrypts sensitive data using zero-knowledge proof and homomorphic encryption algorithms, and the encrypted data fingerprint is stored in the medical blockchain version unit; The data sharing and synchronization unit is used to instantaneously push data change information and uses distributed storage technology to ensure that all node data is unified and the operation records are completely traceable.

7. The cross-platform voucher synchronization system for accounting vouchers based on blockchain according to claim 2, characterized in that The preset rules include: The data format unification rule is used to automatically convert the accounting vouchers of heterogeneous ERP systems, realize field mapping, medical subject code conversion, and mandatory field verification, and supplement missing fields; The collaborative operation conflict management rule is used to start the conflict adjudication rule unit and set a dynamic permission matrix based on the medical permission level; when multi-institutional concurrent operations are detected, the chained evidence storage module is triggered to implement a temporary locking mechanism for the vouchers in collaborative processing, and a priority adjudication process is started, and only the general hospital's finance department has the right to modify the medical insurance type information; the voucher locking mechanism is implemented through the medical operation log unit; The medical insurance settlement compliance rule is used to call the national medical insurance data service interface platform through the medical insurance rule management unit, automatically check whether the medical expenses meet the reimbursement regulations, control the upper limit of the reimbursement amount, and review the qualification for cross-provincial medical treatment; The data security and audit rule is used to protect sensitive information using zero-knowledge proof and homomorphic encryption algorithms in the medical blockchain network, and at the same time, all operation processes are completely recorded through the chained evidence storage module to ensure that data modification is traceable throughout the process.

8. The cross-platform voucher synchronization system for accounting vouchers based on blockchain according to claim 7, characterized in that The collaborative operation conflict management rule includes: e1. When it is detected that multiple institutions modify the vouchers of the same patient at the same time, trigger the priority determination process of the dynamic adjudication module; e2. Mark the vouchers being collaboratively processed as in a temporarily locked state to prevent unauthorized overwriting. The temporarily locked state is recorded by the medical operation log unit with the locking time and the operator; e3. Dynamically allocate editable field permissions according to the medical permission level.

9. The cross-platform voucher synchronization system for accounting vouchers based on blockchain according to claim 2, characterized in that, The dynamic adjudication module also includes an extended adjudication rule unit for setting specific business scenarios. The extended adjudication rule unit includes: d1. Special department permission exception rule: When a clinical department has special approval authority, it can break through the default permission level for specific operations; d2. Emergency operation green channel rule: Automatically raise the priority of voucher modifications marked as "emergency"; d3. Multi-factor adjudication rule: Used for weighted adjudication by comprehensively considering the operator's professional title, business urgency, and historical operation accuracy.

10. The cross-platform voucher synchronization system for accounting vouchers based on blockchain according to claim 1, characterized in that, The heterogeneous system dynamic adaptation module includes: The data collection unit is used to obtain the field definitions, subject code rules, and version change logs of the ERP systems of each branch hospital in real time; The model training unit, based on the deep learning framework, generates a training set according to historical operation data and national medical insurance standard codes, and generates a heterogeneous system field mapping model; The real-time adaptation unit is used to monitor the version change events of the branch hospital's ERP system. When it detects changes in fields or coding rules, it automatically triggers model incremental learning and updates the mapping relationship table; The conflict resolution unit performs historical record backtracking or manual annotation intervention on low-confidence mapping results to ensure data conversion integrity.

11. A conflict handling method for implementing the cross-platform voucher synchronization system of blockchain-based accounting vouchers described in any one of claims 1-10, characterized in that, Include the following steps: S1. Receive the modification request from the branch node through the node management unit of the medical alliance chain network module, and verify the digital identity certificate of the branch node. S2. Invoke the medical insurance rule management unit of the self-healing synchronization module to check the compliance of the expenses. If a conflict between the expenses and the medical insurance rules is found during the compliance pre-check, trigger the logical conflict handling process. S3. When a field missing or format conflict is detected, start the data format unification rule to automatically complete the missing fields and convert the medical subject codes. S4. Encrypt the data using zero-knowledge proof technology and push it to all verification nodes in real time. S5. Generate a new block through the chained evidence storage module, store the operation record and update the patient data index.

12. The conflict handling method of the cross-platform voucher synchronization system for accounting vouchers based on blockchain according to claim 11, characterized in that, When it is detected that multiple institutions concurrently modify the same patient voucher, execute the conflict adjudication process, which includes the following steps: S11. When the chained evidence storage module detects that multiple institutions simultaneously modify the same voucher, trigger the conflict handling process of the dynamic adjudication module. S12. According to the preset medical authority hierarchy, preferentially adopt the operation result of the general hospital. S13. If the conflict occurs between peer institutions, compare the millisecond-level timestamps generated by the medical trust timestamp unit, and take the latest operation as the standard. S14. After the adjudication result is encrypted, update it to the blockchain version of all nodes, and generate a difference report containing the operator's identity and timestamp.

13. The conflict handling method of the cross-platform voucher synchronization system for accounting vouchers based on blockchain according to claim 12, characterized in that, Logical conflict handling includes the following steps: S21. Monitor the output of the medical insurance rule management unit in real time to identify the following problems: the expenses exceed the medical insurance limit; the diagnosis and treatment items are not in the medical insurance catalog; the cross-provincial settlement qualification is abnormal. S22. Invoke the medical data correction unit to adjust the drug codes and recalculate the reimbursement amount. S23. If the automatic correction fails, push the conflict data to the general hospital audit panel and retain the operation snapshot. S24. Encrypt the manual review result to generate a new block, recording the correction process and the operator's signature.

Images