A medical insurance business communication management system based on face recognition

Abstract

This application discloses a medical insurance business communication management system based on facial recognition. This invention constructs a complete medical insurance business communication management system through the collaborative cooperation of multiple modules. This invention improves identity authentication security by employing a two-factor authentication mechanism combining facial recognition and social security card chip. It solves the distributed transaction consistency problem by using a preprocessing mechanism and a unified coordination mechanism. This invention uses a parallel sending of pre-operation requests to simultaneously initiate resource locking requests to the insured's local medical insurance system, medical institution system, and bank payment system. The pre-operation mechanism achieves advance resource locking, avoiding resource conflicts caused by inconsistent processing times between systems.

Description

Technical Field

[0001] This application relates to the field of communication management technology, and in particular to a medical insurance business communication management system based on face recognition. Background Technology

[0002] With the continuous improvement of my country's medical security system and the deepening of informatization, social security informatization management has become an important means to improve the efficiency of public services and protect people's rights and interests. In the field of social security informatization management, the medical insurance business management system, as a core component, undertakes key functions such as enrollment registration, expense settlement, and fund supervision. Especially within the medical insurance business management system, cross-regional medical insurance settlement involves the collaborative work of multiple independent systems, including the medical insurance system of the insured's place of residence, the medical insurance system of the place of treatment, the HIS system of the medical institution, and the bank payment system, making it one of the most complex and technically challenging application scenarios. To improve the security and convenience of cross-regional settlement, a medical insurance business communication management system based on facial recognition technology has emerged. This system uses biometric recognition technology to verify the identity of insured persons and coordinates data interaction and transaction processing between multiple business systems through a unified communication management mechanism, providing reliable technical support for cross-regional medical insurance settlement.

[0003] However, existing cross-regional medical insurance settlement services suffer from significant technical deficiencies in communication management and transaction processing. Currently, the medical insurance systems at the insured's location, the medical institution's HIS system, and the bank's payment system communicate independently, lacking a unified transaction coordination mechanism. This architecture means that in the cross-regional settlement process, if any link fails due to network failure, system anomaly, or business rule verification failure, the consistency of data status across all participating systems cannot be guaranteed. For example, the insured's local medical insurance system may have completed the deduction from the individual's account, but the medical institution may not have received settlement confirmation due to network interruption, resulting in data inconsistency where the insured's account has been deducted but the hospital has not recorded the transaction. These problems not only require significant manpower for post-event reconciliation and error handling, generating thousands of inconsistent records daily with reconciliation cycles of 3-7 days, but also seriously damage the legitimate rights and interests of insured individuals and the security of the medical insurance fund, affecting the effective supervision, management, and auditing of medical insurance services. Summary of the Invention

[0004] The main objective of this application is to provide a medical insurance business communication management system based on facial recognition to solve the problems mentioned in the background.

[0005] To achieve the above objectives, this application provides the following technical solution:

[0006] A medical insurance business communication management system based on facial recognition includes an identity authentication module, a transaction coordination module, a status management module, an anomaly recovery module, and an audit and supervision module.

[0007] The identity authentication module collects facial images of insured persons and performs liveness detection, extracts facial feature vectors and compares them with the medical insurance database, combines social security card chip information to perform two-factor authentication, and generates authentication tokens and globally unique business transaction numbers.

[0008] The transaction coordination module receives the business serial number and authentication token, sends preprocessing requests in parallel to the medical insurance system, medical institution system and bank payment system of the insured's place of insurance, obtains the pre-operation vouchers returned by each system, and sends confirmation instructions or cancellation instructions to each system according to the response results.

[0009] The status management module records the current status and status change history of a business using the business serial number as the primary key, scans non-final state business records, and queries the actual execution status of each participating system.

[0010] The anomaly recovery module receives anomaly notifications from the status management module, queries the actual business status from each participating system, and performs compensation operations based on the query results. The compensation request carries the original business transaction number.

[0011] The audit and supervision module collects operation logs from each module, pulls transaction flow data from each participating system, compares it with local records to generate reconciliation reports, monitors business operation indicators, and provides an audit query interface.

[0012] Preferably, the identity authentication module includes a biometric verification unit and a business initialization unit;

[0013] The biometric verification unit acquires facial images of insured persons through image acquisition devices and performs liveness detection. It extracts facial feature vectors and calculates the similarity between them and the facial feature vectors pre-stored in the medical insurance database. When the similarity reaches a preset threshold, the verification is deemed successful. At the same time, it reads the identity information in the social security card chip for cross-verification, queries the insured person's insurance status record and medical insurance benefit eligibility record, and generates an authentication token containing the insured person's unique identifier, verification timestamp, and validity period.

[0014] The business initialization unit receives the authentication token from the biometric verification unit, extracts the insured person's unique identifier and verification timestamp from the authentication token, generates a globally unique business serial number by combining the timestamp with a random number, obtains medical information and expense details, and encapsulates the insured person's unique identifier, medical information, expense details, authentication token, and business initiation time into a business context object. The business context object is stored in the transaction log table of the local database with the business serial number as the primary key.

[0015] Preferably, the transaction coordination module includes a pre-operation execution unit and a transaction commit unit;

[0016] The pre-operation execution unit receives the business transaction number and business context object transmitted by the identity authentication module, parses the business context object to obtain the expense details and authentication token, constructs a pre-deduction request data packet and sends it to the medical insurance system of the insured location to obtain the pre-deduction voucher, constructs a pre-billing request data packet and sends it to the medical institution system to obtain the pre-billing voucher, constructs a pre-payment request data packet and sends it to the bank payment system to obtain the pre-payment voucher, collects the response status of each participating system within a preset time threshold, determines whether all pre-operations are successful, and encapsulates the determination result and pre-operation voucher into a pre-operation result data packet;

[0017] The transaction commit unit receives the pre-operation result data packet transmitted by the pre-operation execution unit and extracts the judgment result. When the judgment result is that all pre-operations are successful, it sends a confirmation deduction instruction with pre-deduction voucher to the medical insurance system of the insured location, a confirmation accounting instruction with pre-accounting voucher to the medical institution system, and a confirmation payment instruction with pre-payment voucher to the bank payment system. When the judgment result is that some pre-operations have failed, it sends a cancellation instruction with corresponding voucher to the system that has completed the pre-operation. Based on the final response results of each participating system, it updates the business status and constructs a status change notification data packet to be transmitted to the status management module.

[0018] Preferably, the pre-operation execution unit includes a request construction unit and a response collection unit;

[0019] The request construction unit receives the business transaction number and business context object transmitted by the identity authentication module, parses the expense details and authentication token from the business context object, constructs a pre-deduction request data packet containing the business transaction number and authentication token based on the personal account payment amount, constructs a pre-billing request data packet based on the total medical expenses and the medical insurance fund payment amount, constructs a pre-payment request data packet based on the medical insurance fund payment amount, and sends the three types of request data packets to the medical insurance system, medical institution system and bank payment system in the insured's place of insurance through the network communication interface, records the system identifier and sending timestamp of each participating system and encapsulates them into a request sending record data packet;

[0020] The response collection unit receives the request sending record data packet transmitted by the request construction unit, extracts the system identifier and sending timestamp of each participating system, adds the sending timestamp to a preset time threshold to calculate the response timeout point, creates a response status record table in the local database, monitors network communication connections, receives pre-deduction vouchers containing frozen transaction numbers returned by the medical insurance system of the insured's place of insurance, receives pre-billing vouchers containing pre-billing transaction numbers returned by the medical institution system, and receives pre-payment vouchers containing frozen order numbers returned by the bank payment system. It writes the pre-operation vouchers into the response status record table, counts the number of successful responses and determines whether all pre-operations were successful, and encapsulates the determination result and pre-operation vouchers into a pre-operation result data packet.

[0021] Preferably, the transaction commit unit includes an instruction distribution unit and a result aggregation unit;

[0022] The instruction distribution unit receives the pre-operation result data packet and extracts the judgment result. When the judgment result is that all pre-operations are successful, it extracts the pre-deduction voucher, pre-accounting voucher, and pre-payment voucher. It combines the business transaction number with the transaction number in each voucher to construct a confirmation instruction data packet and sends it to the medical insurance system, medical institution system, and bank payment system of the insured's place of insurance, respectively. When the judgment result is that there is a failure in the pre-operation, it constructs a cancellation instruction data packet and sends it to the system that has completed the pre-operation. It records the system identifier and instruction sending timestamp and encapsulates it into an instruction sending record data packet.

[0023] The results aggregation unit receives the instruction sending record data packet and extracts the system identifier, instruction sending timestamp, and judgment result. It adds the instruction sending timestamp to a preset time threshold to calculate the response timeout point, creates an execution result record table in the local database, monitors network communication connections and receives response status codes returned by each participating system, counts the number of successful responses, updates the business status to success, failure, or exception based on the judgment result and response status code, encapsulates the business serial number, business status, and response status code into a status change notification data packet, and sends it to the status management module.

[0024] Preferably, the status management module includes a status recording unit and a status scanning unit;

[0025] The status recording unit receives status change notification data packets and extracts the business serial number, business status, and execution results of each participating system. It creates a business status record table in the local database with the business serial number as the primary key, writes the business status and execution results into the business status record table, and writes the original status into the status change history table when a new status change notification data packet is received. It updates the business status record table with the new business status and transmits the business serial number and current status to the status scanning unit.

[0026] The status scanning unit receives the business transaction number and the current status, sets a preset scanning period, queries the business status record table and filters non-final state business records in each scanning period, extracts the business transaction number and constructs a status query request data packet, sends the status query request data packet to the medical insurance system, medical institution system and bank payment system in the insured's place of insurance, collects the actual execution status returned by each participating system, and constructs an exception notification data packet when the actual execution status is inconsistent with the recorded status and sends it to the exception recovery module.

[0027] Preferably, the state recording unit includes a state writing unit and a history archiving unit;

[0028] The status writing unit receives the status change notification data packet and extracts the business serial number, business status and execution result. It queries whether the business serial number already exists in the business status record table. If the business serial number does not exist, it creates a new record and writes the business status and execution result. If the business serial number already exists, it reads the original status and constructs a historical record data packet and transmits it to the historical archiving unit. After waiting for the archiving completion notification, it updates the new business status to the business status record table.

[0029] The historical archiving unit receives historical data packets and extracts the business transaction number, original status, and status change time. It creates a status change history table in the local database, generates a historical record identifier as the primary key, writes the business transaction number, original status, and status change time into the status change history table, and returns an archiving completion notification to the status writing unit. The status writing unit updates the new business status into the business status record table and then passes the business transaction number and current status to the status scanning unit.

[0030] Preferably, the state scanning unit includes a periodic scanning unit and a state comparison unit;

[0031] The periodic scanning unit receives the business serial number and the current status, sets a preset scanning period, queries the business status record table in each scanning period and filters non-final business records with statuses of confirmation, cancellation, or abnormal, extracts the business serial number and encapsulates it into a status query request data packet, sends the status query request data packet to the medical insurance system, medical institution system, and bank payment system of the insured's place of insurance, records the system identifier and query request sending timestamp and encapsulates it into a query request record data packet.

[0032] The status comparison unit receives the query request record data packet and extracts the business serial number, system identifier, and query request sending timestamp. It adds the query request sending timestamp to a preset time threshold to calculate the response timeout point, creates an actual status record table in the local database, listens for network communication connections and receives the actual execution status returned by each participating system, queries the business status record table according to the business serial number and reads the record execution status, compares the actual execution status with the record execution status, and when they are inconsistent, encapsulates the business serial number and inconsistency type into an exception notification data packet and sends it to the exception recovery module.

[0033] Preferably, the anomaly recovery module includes a status verification unit and a compensation execution unit;

[0034] The status verification unit receives the anomaly notification data packet and extracts the business transaction number and inconsistency type. After locating the participating system with the anomaly, it encapsulates a detailed status query request, collects the health parameters of each system, calculates the real-time reliable weight, and determines the true status of the business as successful, failed, or partially successful based on a weighted statistical mechanism. The verification result and system parameters are then encapsulated into a status verification result data packet and transmitted.

[0035] After receiving the status verification result data packet, the compensation execution unit constructs a lightweight digital twin image, simulates multiple candidate compensation strategies in parallel and collects execution indicators, generates the optimal strategy through a reinforcement learning model, and generates retry, rollback or differential compensation instructions in combination with transaction dependency differences. The instruction hash is written into the consortium chain to trigger cross-system consensus. After reaching the fault tolerance threshold, a certificate is generated. If the main strategy fails, the backup strategy is automatically triggered.

[0036] Preferably, the audit supervision module includes a log collection unit and an account reconciliation monitoring unit;

[0037] Operation log data is collected from the transaction coordination module, status management module, and exception recovery module, and then classified and organized according to the business transaction number before being written into the operation log record table. A preset collection period is set, and within each collection period, transaction flow data is pulled from the medical insurance system, medical institution system, and bank payment system of the insured's place of insurance, and then classified and organized according to the business transaction number before being written into the external transaction flow record table. The business transaction number, operation log record table, and external transaction flow record table are encapsulated into a log collection data package and transmitted to the reconciliation monitoring unit.

[0038] The system receives log collection data packets and extracts the business transaction number. Based on the business transaction number, it reads local records from the operation log record table and transaction data from the external transaction record table. It compares the local records with the transaction data. When the transaction amount or transaction status is inconsistent, it identifies the difference type, counts the number of differences, and writes them to the reconciliation report table. It sets a preset monitoring period, counts business operation indicators in each monitoring period, and writes them to the business operation indicator record table. It provides an audit query interface for external systems to call.

[0039] Compared with the prior art, the beneficial effects of the present invention are:

[0040] 1. This invention constructs a complete medical insurance business communication management system through the collaborative cooperation of multiple modules. It enhances identity authentication security by employing a two-factor authentication mechanism combining facial recognition and social security card chip; solves the distributed transaction consistency problem by using a preprocessing mechanism and a unified coordination mechanism; improves the timeliness of anomaly detection by employing an active scanning and status tracing mechanism; reduces operation and maintenance costs by employing an automated compensation mechanism; and improves the accuracy of business data by employing an automated reconciliation and real-time monitoring mechanism.

[0041] 2. The pre-operation execution unit adopts a parallel pre-operation request sending method to simultaneously initiate resource locking requests to the medical insurance system, medical institution system, and bank payment system in the insured's place of insurance. Through the pre-operation mechanism, resources are locked in advance, avoiding resource conflicts caused by inconsistent processing timing between systems. Within a preset time threshold, the response status of each participating system is collected uniformly, and it is determined whether all pre-operations are successful, providing complete data support for subsequent unified decision-making.

[0042] 3. The transaction commit unit adopts a unified confirmation or cancellation mechanism based on the results of the pre-operations. When all pre-operations are successful, a confirmation instruction is sent to each participating system to make the pre-operations effective. When a pre-operation fails, a cancellation instruction is sent to the system that has completed the pre-operation to roll back. This ensures that all participating systems either all execute successfully or all roll back, thus achieving the atomicity guarantee of distributed transactions. Attached Figure Description

[0043] Figure 1 This is the system flowchart for this application. Detailed Implementation

[0044] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0045] The terms "first," "second," and "third" in this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. All directional indications (such as up, down, left, right, front, back, etc.) in the embodiments of this application are only used to explain the relative positional relationships and movements between components in a specific orientation (as shown in the figures). If the specific orientation changes, the directional indications also change accordingly. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0046] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0047] Example 1: Please refer to Figure 1 A medical insurance business communication management system based on facial recognition includes an identity authentication module, a transaction coordination module, a status management module, an anomaly recovery module, and an audit and supervision module.

[0048] The identity authentication module collects facial images of insured persons and performs liveness detection, extracts facial feature vectors and compares them with the medical insurance database, combines social security card chip information to perform two-factor authentication, and generates authentication tokens and globally unique business transaction numbers.

[0049] The transaction coordination module receives the business serial number and authentication token, sends preprocessing requests in parallel to the medical insurance system, medical institution system and bank payment system of the insured's place of insurance, obtains the pre-operation vouchers returned by each system, and sends confirmation instructions or cancellation instructions to each system according to the response results.

[0050] The status management module records the current status and status change history of a business using the business serial number as the primary key, scans non-final state business records, and queries the actual execution status of each participating system.

[0051] The anomaly recovery module receives anomaly notifications from the status management module, queries the actual business status from each participating system, and performs compensation operations based on the query results. The compensation request carries the original business transaction number.

[0052] The audit and supervision module collects operation logs from each module, pulls transaction flow data from each participating system, compares it with local records to generate reconciliation reports, monitors business operation indicators, and provides an audit query interface.

[0053] In this embodiment: the identity authentication module effectively prevents fraudulent activities using forged photos, videos, and other means by collecting facial images of insured individuals and performing liveness detection. It extracts facial feature vectors and compares them with feature data stored in the medical insurance database, combining this with two-factor authentication using social security card chip information. This achieves dual verification of biometrics and physical media, significantly improving the security and accuracy of identity authentication. The generated authentication token and globally unique business serial number provide reliable identity credentials and traceability for subsequent business processes, solving the risks of identity theft and information leakage inherent in traditional identity authentication methods and ensuring the safe use of medical insurance funds.

[0054] After receiving the business transaction number and authentication token, the transaction coordination module sends preprocessing requests in parallel to the medical insurance system, medical institution system, and bank payment system in the insured's location. The preprocessing mechanism enables the early locking of resources, avoiding data inconsistency caused by inconsistent processing times between systems. After obtaining the pre-operation vouchers returned by each system, the module sends confirmation or cancellation instructions in a unified manner based on the response results of all systems, ensuring transaction consistency between multiple systems. This solves the problems of low efficiency and difficulty in coordinating distributed transactions in traditional serial processing methods, significantly shortens business processing time, and improves user experience and system processing capabilities.

[0055] The status management module records the current status and status change history of a business using the business serial number as the primary key, establishing a complete business status traceability chain. This provides data support for troubleshooting anomalies and optimizing business processes. By periodically scanning non-final state business records and querying the actual execution status of each participating system, it achieves proactive monitoring of business execution status and timely detection of anomalies. This avoids long-term inconsistencies in business status caused by network fluctuations or system failures, solves the problem that traditional passive waiting response methods cannot detect anomalies in a timely manner, and improves the reliability of the system and the integrity of business processing.

[0056] After receiving the exception notification from the status management module, the exception recovery module queries the actual business status of each participating system. By statistically analyzing the execution status returned by each system, it uses the majority rule to determine the actual execution status of the business. Based on the query results, it performs retry operations on systems that fail to execute or rollback operations on systems that succeed. The compensation request carries the original business serial number, which implements an idempotent design, avoiding data errors caused by duplicate compensation. It solves the problems of low efficiency and error-proneness of traditional manual intervention methods, realizes automated recovery of exceptions, significantly reduces operation and maintenance costs, and improves the system's self-healing capability and business continuity.

[0057] The audit and supervision module collects operation logs from each module, establishing a complete operation audit trail. This provides a reliable basis for business compliance checks and accountability. It periodically pulls transaction flow data from participating systems and compares it with local records to generate reconciliation reports, achieving automated verification of business data. This promptly identifies data inconsistencies, monitors business operation indicators, and provides an audit query interface. This provides a convenient data acquisition method for real-time monitoring of system operation status and external auditing, solving the problems of low efficiency and difficulty in timely detection of data inconsistencies in traditional manual reconciliation methods. This improves the accuracy of business data and the transparency of system operation.

[0058] This invention constructs a complete medical insurance business communication management system through the coordinated operation of multiple modules. It enhances identity authentication security by employing a two-factor authentication mechanism combining facial recognition and social security card chip; solves the distributed transaction consistency problem by using a preprocessing mechanism and a unified coordination mechanism; improves the timeliness of anomaly detection by employing proactive scanning and status tracing mechanisms; reduces operation and maintenance costs by employing an automated compensation mechanism; and improves the accuracy of business data by employing automated reconciliation and real-time monitoring mechanisms.

[0059] Example 2: Please refer to Figure 1 The identity authentication module includes a biometric verification unit and a business initialization unit;

[0060] The biometric verification unit acquires facial images of insured persons through image acquisition devices and performs liveness detection. It extracts facial feature vectors and calculates the similarity between them and the facial feature vectors pre-stored in the medical insurance database. When the similarity reaches a preset threshold, the verification is deemed successful. At the same time, it reads the identity information in the social security card chip for cross-verification, queries the insured person's insurance status record and medical insurance benefit eligibility record, and generates an authentication token containing the insured person's unique identifier, verification timestamp, and validity period.

[0061] The business initialization unit receives the authentication token from the biometric verification unit, extracts the insured person's unique identifier and verification timestamp from the authentication token, generates a globally unique business serial number by combining the timestamp with a random number, obtains medical information and expense details, and encapsulates the insured person's unique identifier, medical information, expense details, authentication token, and business initiation time into a business context object. The business context object is stored in the transaction log table of the local database with the business serial number as the primary key.

[0062] In this embodiment, the biometric verification unit acquires the insured person's facial image through an image acquisition device and performs liveness detection, effectively preventing fraudulent activities such as identity theft using photos or videos. It extracts facial feature vectors and calculates their similarity with pre-stored facial feature vectors in the medical insurance database. When the similarity reaches a preset threshold, the verification is considered successful, achieving accurate identity recognition based on biometrics. Simultaneously, it reads the identity information from the social security card chip for cross-verification, combining biometric recognition with physical medium verification to form a two-factor authentication mechanism, significantly improving the security and reliability of identity authentication.

[0063] The business initialization unit receives the authentication token from the biometric verification unit, extracts the insured person's unique identifier and verification timestamp from the authentication token, and generates a globally unique business transaction number by combining the timestamp with a random number. This ensures that each transaction has a unique identifier, providing a reliable basis for full-process traceability and anomaly localization. After obtaining medical information and expense details, the insured person's unique identifier, medical information, expense details, authentication token, and transaction initiation time are encapsulated into a business context object, achieving centralized management and unified transmission of business-related information.

[0064] The identity authentication module, through the collaborative operation of the biometric verification unit and the business initialization unit, realizes a complete process from identity verification to business initialization. The biometric verification unit employs a two-factor authentication mechanism combining facial recognition and social security card chip, addressing the security shortcomings of traditional single-factor authentication methods. Through liveness detection and feature vector similarity calculation, it effectively prevents identity theft and fraud. By querying enrollment status and medical insurance eligibility, it ensures that insured individuals have the legal right to enjoy medical insurance benefits, and the generated authentication token provides a time-sensitive identity credential for subsequent business processes. The business initialization unit uses a combination of timestamps and random numbers to generate a globally unique business serial number, providing a reliable identifier for full-process traceability of the business. It encapsulates business-related information into a business context object and persists it, providing complete data support for the execution of subsequent business processes. Compared to traditional identity authentication methods, this module significantly improves the security of identity verification, the traceability of authentication results, the integrity of business information, and the standardization of business processes, providing reliable assurance for the secure processing and efficient management of medical insurance business.

[0065] Example 3: Please refer to Figure 1 The transaction coordination module includes a pre-operation execution unit and a transaction commit unit;

[0066] The pre-operation execution unit receives the business transaction number and business context object transmitted by the identity authentication module, parses the business context object to obtain the expense details and authentication token, constructs a pre-deduction request data packet and sends it to the medical insurance system of the insured location to obtain the pre-deduction voucher, constructs a pre-billing request data packet and sends it to the medical institution system to obtain the pre-billing voucher, constructs a pre-payment request data packet and sends it to the bank payment system to obtain the pre-payment voucher, collects the response status of each participating system within a preset time threshold, determines whether all pre-operations are successful, and encapsulates the determination result and pre-operation voucher into a pre-operation result data packet;

[0067] The transaction commit unit receives the pre-operation result data packet transmitted by the pre-operation execution unit and extracts the judgment result. When the judgment result is that all pre-operations are successful, it sends a confirmation deduction instruction with pre-deduction voucher to the medical insurance system of the insured location, a confirmation accounting instruction with pre-accounting voucher to the medical institution system, and a confirmation payment instruction with pre-payment voucher to the bank payment system. When the judgment result is that some pre-operations have failed, it sends a cancellation instruction with corresponding voucher to the system that has completed the pre-operation. Based on the final response results of each participating system, it updates the business status and constructs a status change notification data packet to be transmitted to the status management module.

[0068] In this embodiment: The pre-operation execution unit receives the business transaction number and business context object from the identity authentication module, parses the expense details and authentication token from the business context object, constructs a pre-deduction request data packet, a pre-billing request data packet, and a pre-payment request data packet, and sends them to the medical insurance system, medical institution system, and bank payment system, respectively. This pre-operation mechanism achieves advance locking of resources, avoiding resource conflicts caused by inconsistent processing times between systems. Within a preset time threshold, the response status of each participating system is collected to determine whether all pre-operations were successful, achieving unified collection and judgment of response results from multiple systems.

[0069] The transaction commit unit receives the pre-operation result data packet from the pre-operation execution unit and extracts the judgment result. When the judgment result indicates that all pre-operations were successful, it sends a confirmation instruction carrying the corresponding credentials to each participating system. When the judgment result indicates that some pre-operations failed, it sends a cancellation instruction carrying the corresponding credentials to the systems that have completed the pre-operations. This achieves unified decision-making and coordination based on the pre-operation results, ensuring transaction consistency among multiple systems. By carrying pre-operation credentials, each participating system can accurately identify the pre-operation records that need to be confirmed or cancelled, avoiding misoperations and duplicate operations.

[0070] The transaction coordination module achieves unified coordination and consistency assurance for distributed transactions through the collaborative work of the pre-operation execution unit and the transaction commit unit. The pre-operation execution unit sends pre-operation requests in parallel, simultaneously initiating resource locking requests to the medical insurance system, medical institution system, and bank payment system. This pre-operation mechanism secures resources in advance, avoiding resource conflicts caused by inconsistent processing times between systems. Within a preset time threshold, it collects the response status of each participating system and determines whether all pre-operations were successful, providing complete data support for subsequent unified decision-making. The transaction commit unit uses a unified confirmation or cancellation mechanism based on the pre-operation results. When all pre-operations are successful, it sends confirmation instructions to each participating system to make the pre-operations effective. When a pre-operation fails, it sends cancellation instructions to systems that have completed the pre-operation for rollback, ensuring that all participating systems either all succeed or all rollbacks, achieving atomicity assurance for distributed transactions. Compared to traditional serial processing methods and distributed transaction processing methods lacking a unified coordination mechanism, this module effectively solves problems such as resource conflicts, low processing efficiency, and data inconsistency through pre-operation mechanisms and unified coordination mechanisms. It significantly shortens business processing time, improves the system's processing capacity and the consistency of business data, and provides a strong guarantee for the efficient processing and reliable operation of medical insurance business.

[0071] Example 4: Please refer to Figure 1 The pre-operation execution unit includes a request construction unit and a response collection unit;

[0072] The request construction unit receives the business transaction number and business context object transmitted by the identity authentication module, parses the expense details and authentication token from the business context object, constructs a pre-deduction request data packet containing the business transaction number and authentication token based on the personal account payment amount, constructs a pre-billing request data packet based on the total medical expenses and the medical insurance fund payment amount, constructs a pre-payment request data packet based on the medical insurance fund payment amount, and sends the three types of request data packets to the medical insurance system, medical institution system and bank payment system in the insured's place of insurance through the network communication interface, records the system identifier and sending timestamp of each participating system and encapsulates them into a request sending record data packet;

[0073] The response collection unit receives the request sending record data packet transmitted by the request construction unit, extracts the system identifier and sending timestamp of each participating system, adds the sending timestamp to a preset time threshold to calculate the response timeout point, creates a response status record table in the local database, monitors network communication connections, receives pre-deduction vouchers containing frozen transaction numbers returned by the medical insurance system of the insured's location, receives pre-billing vouchers containing pre-billing transaction numbers returned by the medical institution system, and receives pre-payment vouchers containing frozen order numbers returned by the bank payment system. It writes the pre-operation vouchers into the response status record table, counts the number of successful responses and determines whether all pre-operations were successful, and encapsulates the determination result and pre-operation vouchers into a pre-operation result data packet.

[0074] In this embodiment: The request construction unit receives the business transaction number and business context object transmitted by the identity authentication module, parses the expense details and authentication token from the business context object, and constructs pre-deduction request data packets, pre-billing request data packets, and pre-payment request data packets according to different expense compositions such as personal account payment amount, total medical expenses, and medical insurance fund payment amount. This achieves differentiated request construction for different participating systems, ensuring that each system can perform pre-operation processing according to its own business rules. The three types of request data packets are sent to the medical insurance system, medical institution system, and bank payment system in the insured's place of insurance through the network communication interface, realizing parallel request sending of multiple systems.

[0075] The response collection unit receives the request sending record data packets transmitted by the request construction unit, extracts the system identifier and sending timestamp of each participating system, adds the sending timestamp to a preset time threshold to calculate the response timeout point, and establishes a response timeout judgment mechanism based on sending time, avoiding the problem of long waiting times for overall business processing due to the response delay of a certain system. A response status record table is created in the local database and network communication connections are monitored. Pre-operation credentials returned by each participating system are received and written into the response status record table, realizing centralized storage and unified management of the response results of each system.

[0076] The pre-operation execution unit, through the coordinated efforts of the request construction unit and the response collection unit, achieves a complete process of sending pre-operation requests to multiple participating systems in parallel and uniformly collecting response results. The request construction unit constructs differentiated request data packets for the insured's local medical insurance system, medical institution system, and bank payment system based on different cost structures. These packets are simultaneously sent to each participating system in parallel, recording the system identifier and sending timestamp of each participating system to provide accurate data for subsequent response processing. The response collection unit calculates the response timeout point based on the sending timestamp and establishes a response timeout judgment mechanism. It centrally receives pre-operation vouchers returned by each participating system by monitoring network communication connections and writes them into a response status record table. It counts the number of successful responses and determines whether all pre-operations were successful. The judgment result and pre-operation vouchers are encapsulated into a pre-operation result data packet, providing complete data support for subsequent unified decision-making. Compared to traditional serial request sending and distributed response processing, this unit significantly shortens the pre-operation processing time through parallel request sending and centralized response collection mechanisms. By recording sending timestamps and establishing a response timeout judgment mechanism, it avoids long waiting times for overall business processing due to response delays in individual systems. By uniformly collecting and judging response results, it provides a reliable data foundation for the consistency coordination of distributed transactions, thereby improving the efficiency and reliability of pre-operation execution.

[0077] Example 5: Please refer to Figure 1 The transaction commit unit includes an instruction distribution unit and a result aggregation unit;

[0078] The instruction distribution unit receives the pre-operation result data packet and extracts the judgment result. When the judgment result is that all pre-operations are successful, it extracts the pre-deduction voucher, pre-accounting voucher, and pre-payment voucher. It combines the business transaction number with the transaction number in each voucher to construct a confirmation instruction data packet and sends it to the medical insurance system, medical institution system, and bank payment system of the insured's place of insurance, respectively. When the judgment result is that there is a failure in the pre-operation, it constructs a cancellation instruction data packet and sends it to the system that has completed the pre-operation. It records the system identifier and instruction sending timestamp and encapsulates it into an instruction sending record data packet.

[0079] The results aggregation unit receives the instruction sending record data packet and extracts the system identifier, instruction sending timestamp, and judgment result. It adds the instruction sending timestamp to a preset time threshold to calculate the response timeout point, creates an execution result record table in the local database, monitors network communication connections and receives response status codes returned by each participating system, counts the number of successful responses, updates the business status to success, failure, or exception based on the judgment result and response status code, encapsulates the business serial number, business status, and response status code into a status change notification data packet, and sends it to the status management module.

[0080] In this embodiment: The instruction distribution unit receives the pre-operation result data packet and extracts the judgment result. When the judgment result indicates that all pre-operations were successful, it extracts the pre-deduction voucher, pre-posting voucher, and pre-payment voucher. It combines the business transaction number with the transaction number in each voucher to construct a confirmation instruction data packet and sends it to the medical insurance system of the insured's location, the medical institution system, and the bank payment system, respectively. This achieves unified confirmation decision based on the pre-operation result, ensuring that all participating systems execute the confirmation operation synchronously. When the judgment result indicates that a pre-operation failed, it constructs a cancellation instruction data packet and sends it to the systems that have completed the pre-operation. This achieves unified rollback decision based on the pre-operation result, avoiding data inconsistency caused by some systems succeeding while others fail.

[0081] The results aggregation unit receives instruction transmission record data packets and extracts the system identifier, instruction transmission timestamp, and judgment result. It adds the instruction transmission timestamp to a preset time threshold to calculate the response timeout point, establishing a response timeout judgment mechanism based on instruction transmission time. This avoids the problem of prolonged uncertainty in business status due to response delays from a single system. An execution result record table is created in the local database, and network communication connections are monitored to receive response status codes returned by each participating system. The number of successful responses is counted, achieving centralized collection and unified management of execution results from all systems.

[0082] The transaction submission unit, through the coordinated operation of the instruction distribution unit and the result aggregation unit, achieves unified decision-making based on pre-operation results and centralized aggregation of execution results. The instruction distribution unit employs a unified confirmation or cancellation decision mechanism based on the pre-operation results. When all pre-operations are successful, it combines the business transaction number with the transaction numbers in each voucher to construct a confirmation instruction data packet and sends it to all participating systems. When any pre-operation fails, it constructs a cancellation instruction data packet and sends it to the systems that have completed the pre-operation, ensuring that all participating systems either all perform confirmation operations or all perform cancellation operations. Recording system identifiers and instruction sending timestamps provides accurate information for subsequent response processing. The result aggregation unit calculates the response timeout point based on the instruction sending timestamp and establishes a response timeout judgment mechanism. It centrally receives response status codes returned by each participating system by monitoring network communication connections and writes them into the execution result record table. It counts the number of successful responses and accurately determines the business status based on the judgment results and response status codes. It then sends status change notification data packets to the status management module, establishing a cross-module status transmission mechanism. Compared to traditional methods that lack a unified decision-making mechanism and have decentralized result processing, this unit achieves atomicity assurance for distributed transactions through a unified confirmation or cancellation decision-making mechanism, ensures accurate updates of business status through centralized aggregation and unified judgment of execution results, and avoids the business status being uncertain for a long time due to response delays from individual systems by recording instruction sending timestamps and establishing a response timeout judgment mechanism, thereby improving the reliability of transaction commits and the accuracy of business status management.

[0083] Example 6: Please refer to Figure 1 The status management module includes a status recording unit and a status scanning unit;

[0084] The status recording unit receives status change notification data packets and extracts the business serial number, business status, and execution results of each participating system. It creates a business status record table in the local database with the business serial number as the primary key, writes the business status and execution results into the business status record table, and writes the original status into the status change history table when a new status change notification data packet is received. It updates the business status record table with the new business status and transmits the business serial number and current status to the status scanning unit.

[0085] The status scanning unit receives the business transaction number and the current status, sets a preset scanning period, queries the business status record table and filters non-final state business records in each scanning period, extracts the business transaction number and constructs a status query request data packet, sends the status query request data packet to the medical insurance system, medical institution system and bank payment system in the insured's place of insurance, collects the actual execution status returned by each participating system, and constructs an exception notification data packet when the actual execution status is inconsistent with the recorded status and sends it to the exception recovery module.

[0086] In this embodiment: The status recording unit receives status change notification data packets and extracts the business transaction number, business status, and execution results of each participating system. It creates a business status record table in the local database using the business transaction number as the primary key, and writes the business status and execution results into the business status record table. This establishes a business status management mechanism with the business transaction number as the unique identifier, achieving centralized storage and unified management of business status. When a new status change notification data packet is received, the existing status is written to the status change history table, and the new business status is updated to the business status record table, establishing a complete business status change history traceability chain. This provides reliable data support for troubleshooting anomalies and optimizing business processes.

[0087] The status scanning unit receives the business transaction number and current status, sets a preset scanning cycle, queries the business status record table within each scanning cycle, filters non-final state business records, extracts the business transaction number, constructs a status query request data packet, and sends the status query request data packet to the medical insurance system, medical institution system, and bank payment system in the insured's location. This establishes a proactive scanning and periodic query mechanism for non-final state businesses, enabling continuous monitoring and timely detection of business execution status. It also collects the actual execution status returned by each participating system. When the actual execution status differs from the recorded status, it constructs an exception notification data packet and sends it to the exception recovery module, establishing an automatic detection and exception notification mechanism for status inconsistencies.

[0088] The status management module, through the coordinated operation of the status recording unit and the status scanning unit, achieves centralized management and continuous monitoring of business status. The status recording unit receives status change notification data packets and creates a business status record table using the business transaction number as the primary key. This table centrally stores the business status and the execution results of each participating system. When a new status change notification data packet is received, the existing status is written to the status change history table, and the business status record table is updated, establishing a complete business status change history traceability chain. The business transaction number and current status are then passed to the status scanning unit, establishing a data transfer mechanism between status recording and status scanning. The status scanning unit is set to a preset scanning cycle to periodically query the business status record table and filter non-final state business records. It sends status query request data packets to each participating system and collects the actual execution status. When the actual execution status is inconsistent with the recorded status, an exception notification data packet is constructed and sent to the exception recovery module, establishing a proactive scanning mechanism for non-final state business and an automatic detection mechanism for status inconsistencies. Compared to traditional passive waiting for responses and decentralized status management, this module achieves accurate management and complete traceability of business status by centrally recording business status and fully saving the history of status changes. It enables timely detection of anomalies by periodically scanning non-final state business records and proactively querying the actual execution status. By constructing anomaly notification data packets and sending them to the anomaly recovery module, it establishes a linkage mechanism between status management and anomaly recovery, thereby improving the standardization of business status management and the reliability of the system.

[0089] Example 7: Please refer to Figure 1 The state recording unit includes a state writing unit and a history archiving unit;

[0090] The status writing unit receives the status change notification data packet and extracts the business serial number, business status and execution result. It queries whether the business serial number already exists in the business status record table. If the business serial number does not exist, it creates a new record and writes the business status and execution result. If the business serial number already exists, it reads the original status and constructs a historical record data packet and transmits it to the historical archiving unit. After waiting for the archiving completion notification, it updates the new business status to the business status record table.

[0091] The historical archiving unit receives historical data packets and extracts the business transaction number, original status, and status change time. It creates a status change history table in the local database, generates a historical record identifier as the primary key, writes the business transaction number, original status, and status change time into the status change history table, and returns an archiving completion notification to the status writing unit. The status writing unit updates the new business status into the business status record table and then passes the business transaction number and current status to the status scanning unit.

[0092] In this embodiment: the status writing unit receives the status change notification data packet and extracts the business serial number, business status, and execution result. It then queries whether the business serial number already exists in the business status record table. If the business serial number does not exist, a new record is created and the business status and execution result are written, thus achieving the initialization and recording of the new business status. If the business serial number already exists, the original status is read, and a historical record data packet is constructed and transmitted to the historical archiving unit, thus achieving the preservation of the original status before the status change and the triggering of historical archiving. After waiting for the archiving completion notification, the new business status is updated to the business status record table, ensuring that the original status has been archived before the status update, avoiding the loss of the status change history.

[0093] The historical archiving unit receives historical data packets and extracts the business transaction number, original status, and status change time. It creates a status change history table in the local database, generates a historical record identifier as the primary key, and writes the business transaction number, original status, and status change time into the status change history table. This establishes a complete business status change history mechanism, enabling the associated storage of the original status, change time, and business transaction number for each status change. An archiving completion notification is returned to the status writing unit, triggering the unit to update the new business status to the business status record table. The unit then transmits the business transaction number and current status to the status scanning unit, establishing a synchronization and coordination mechanism between historical archiving and status updates.

[0094] The status recording unit, through the collaborative work of the status writing unit and the historical archiving unit, achieves accurate recording of business status and complete preservation of status change history. The status writing unit receives status change notification data packets and queries whether the business serial number already exists in the business status record table. If the business serial number does not exist, a new record is created to initialize the status of the new business. If the business serial number already exists, the original status is read, and a historical record data packet is constructed and transmitted to the historical archiving unit to trigger the historical archiving process. After waiting for the archiving completion notification, the new business status is updated to the business status record table to ensure that the original status has been archived. The historical archiving unit receives historical record data packets and generates a historical record identifier as the primary key in the status change history table. It associates and stores the business serial number, the original status, and the status change time to establish a complete status change history. It returns an archiving completion notification to the status writing unit, triggering status updates and status transmission, establishing a synchronous coordination mechanism between historical archiving and status updates. Compared to the traditional update method that directly overwrites the original state, this unit uses different processing logic by judging whether the business serial number already exists. It ensures the complete preservation of the state change history by constructing a historical record data package and waiting for the archiving completion notification. By generating historical record identifiers and associating them with the business serial number, the original state, and the state change time, it achieves complete traceability of the state change process, thereby improving the integrity and traceability of business state management.

[0095] Example 8: Please refer to Figure 1 The state scanning unit includes a periodic scanning unit and a state comparison unit;

[0096] The periodic scanning unit receives the business serial number and the current status, sets a preset scanning period, queries the business status record table in each scanning period and filters non-final business records with statuses of confirmation, cancellation, or abnormal, extracts the business serial number and encapsulates it into a status query request data packet, sends the status query request data packet to the medical insurance system, medical institution system, and bank payment system of the insured's place of insurance, records the system identifier and query request sending timestamp and encapsulates it into a query request record data packet.

[0097] The status comparison unit receives the query request record data packet and extracts the business serial number, system identifier, and query request sending timestamp. It adds the query request sending timestamp to a preset time threshold to calculate the response timeout point, creates an actual status record table in the local database, listens for network communication connections and receives the actual execution status returned by each participating system, queries the business status record table according to the business serial number and reads the record execution status, compares the actual execution status with the record execution status, and when they are inconsistent, encapsulates the business serial number and inconsistency type into an exception notification data packet and sends it to the exception recovery module.

[0098] In this embodiment: The periodic scanning unit receives the business transaction number and current status, sets a preset scanning period, and queries the business status record table within each scanning period to filter non-final business records with statuses of "confirming," "cancelling," or "abnormal." This establishes a periodic scanning and automatic filtering mechanism for non-final businesses, enabling continuous monitoring and timely detection of incomplete businesses. The business transaction number is extracted and encapsulated into a status query request data packet, which is then sent to the medical insurance system, medical institution system, and bank payment system in the insured's location. This proactively queries the participating systems for the actual execution status of the business, avoiding the long-term inconsistency caused by passively waiting for responses.

[0099] The status comparison unit receives query request record data packets and extracts the business transaction number, system identifier, and query request sending timestamp. It adds the query request sending timestamp to a preset time threshold to calculate the response timeout point, establishing a response timeout judgment mechanism based on the query request sending time. This avoids the problem of status comparison failing to complete for a long time due to a system's response delay. An actual status record table is created in the local database, and network communication connections are monitored. The unit receives the actual execution status returned by each participating system, queries the business status record table based on the business transaction number, reads the recorded execution status, and compares the actual execution status with the recorded execution status, achieving accurate comparison between the actual execution status of each participating system and the local recorded status.

[0100] The status scanning unit, through the coordinated operation of the periodic scanning unit and the status comparison unit, achieves continuous monitoring of non-final state services and automatic detection of status inconsistencies. The periodic scanning unit sets a preset scanning cycle to periodically query the service status record table and filter non-final state service records with statuses of "confirming," "cancelling," or "abnormal." It extracts the service serial number and actively queries the actual execution status of the service by sending status query request data packets to each participating system. It records the system identifier and the query request sending timestamp, providing accurate information for subsequent response processing. The status comparison unit calculates the response timeout point based on the query request sending timestamp, establishing a response timeout judgment mechanism. It receives the actual execution status returned by each participating system by monitoring network communication connections and writes it into the actual status record table. It queries the service status record table based on the service serial number and reads the recorded execution status, comparing the actual execution status with the recorded execution status. When inconsistencies are found, it encapsulates the service serial number and inconsistency type into an anomaly notification data packet and sends it to the anomaly recovery module, establishing an automatic detection and anomaly notification mechanism for status inconsistencies. Compared to traditional state management methods that passively wait for responses and lack proactive comparison mechanisms, this unit achieves continuous monitoring of business execution status by periodically scanning non-final state business records and proactively querying actual execution status. It also enables timely detection of state inconsistencies by accurately comparing the actual execution status with the recorded execution status. Furthermore, it establishes a linkage mechanism between state management and anomaly recovery by constructing anomaly notification data packets and sending them to the anomaly recovery module, thereby improving the timeliness of anomaly detection and the reliability of the system.

[0101] Example 9: Please refer to Figure 1 The anomaly recovery module includes a status verification unit and a compensation execution unit;

[0102] The status verification unit receives the anomaly notification data packet and extracts the business transaction number and inconsistency type. After locating the participating system with the anomaly, it encapsulates a detailed status query request, collects the health parameters of each system, calculates the real-time reliable weight, and determines the true status of the business as successful, failed, or partially successful based on a weighted statistical mechanism. The verification result and system parameters are then encapsulated into a status verification result data packet and transmitted.

[0103] After receiving the status verification result data packet, the compensation execution unit constructs a lightweight digital twin image, simulates multiple candidate compensation strategies in parallel and collects execution indicators, generates the optimal strategy through a reinforcement learning model, and generates retry, rollback or differential compensation instructions in combination with transaction dependency differences. The instruction hash is written into the consortium chain to trigger cross-system consensus. After reaching the fault tolerance threshold, a certificate is generated. If the main strategy fails, the backup strategy is automatically triggered.

[0104] In this embodiment: After receiving the abnormal notification data packet, the status verification unit extracts the business serial number and inconsistency type, locates the participating system with abnormal status and encapsulates a detailed status query request, collects the health parameters of each system to calculate the real-time reliable weight, and determines the true status of the business as successful, failed, or partially successful based on the weighted statistical mechanism. The verification results and system parameters are encapsulated and transmitted, breaking through the binary logic limitation of the traditional majority judgment, realizing the refined identification of the true status of the business, and providing accurate status basis for subsequent differentiated compensation.

[0105] After receiving the status verification result data packet, the compensation execution unit constructs a lightweight digital twin image, simulates multiple candidate compensation strategies in parallel, and collects the execution success rate, resource consumption value, and cascading failure risk index. Through reinforcement learning model, it generates an optimal strategy group containing the main execution strategy and backup strategies. Combined with transaction dependency differences, it generates retry, rollback, or differential compensation instructions, writes the instruction hash to the consortium blockchain to trigger cross-system consensus, verifies it from all parties, writes back the signature, and generates an immutable compensation certificate after reaching the Byzantine fault-tolerant consensus threshold. When the main strategy fails, the backup strategy is automatically triggered, effectively solving the problems of rigid strategies, uncontrollable risks, and difficulty in auditing execution results in the traditional compensation process.

[0106] The anomaly recovery module, through the coordinated operation of the status verification unit and the compensation execution unit, achieves accurate identification of anomalies and intelligent decision-making on compensation strategies. Compared to the traditional passive approach of relying on manual intervention and fixed strategies for anomaly recovery, this module, by introducing dynamic weight determination and a digital twin pre-simulation mechanism, realizes a shift from passive response to proactive prevention, and from extensive decision-making to precise control. This significantly improves the system's self-healing capabilities and business continuity assurance level in a distributed environment, effectively reduces error handling costs and manual reconciliation burdens in cross-regional medical insurance settlement, and provides reliable technical support for the secure supervision of medical insurance funds.

[0107] Example 10: Please refer to Figure 1 The audit and supervision module includes a log collection unit and an account reconciliation monitoring unit;

[0108] Operation log data is collected from the transaction coordination module, status management module, and exception recovery module, and then classified and organized according to the business transaction number before being written into the operation log record table. A preset collection period is set, and within each collection period, transaction flow data is pulled from the medical insurance system, medical institution system, and bank payment system of the insured's place of insurance, and then classified and organized according to the business transaction number before being written into the external transaction flow record table. The business transaction number, operation log record table, and external transaction flow record table are encapsulated into a log collection data package and transmitted to the reconciliation monitoring unit.

[0109] The system receives log collection data packets and extracts the business transaction number. Based on the business transaction number, it reads local records from the operation log record table and transaction data from the external transaction record table. It compares the local records with the transaction data. When the transaction amount or transaction status is inconsistent, it identifies the difference type, counts the number of differences, and writes them to the reconciliation report table. It sets a preset monitoring period, counts business operation indicators in each monitoring period, and writes them to the business operation indicator record table. It provides an audit query interface for external systems to call.

[0110] In this embodiment, the log collection unit collects operation log data from the transaction coordination module, status management module, and exception recovery module, categorizes and organizes it according to business transaction numbers, and writes it into the operation log record table. This establishes a complete operation audit trail, providing a reliable basis for business compliance checks and accountability. A preset collection cycle is set. Within each collection cycle, transaction flow data is retrieved from the medical insurance system, medical institution system, and bank payment system of the insured's location, categorized and organized according to business transaction numbers, and written into the external transaction flow record table. This achieves centralized collection and unified management of local operation logs and external transaction flow data, providing a complete data foundation for subsequent reconciliation and comparison.

[0111] The reconciliation monitoring unit receives log collection data packets and extracts the business transaction number. Based on the business transaction number, it reads local records from the operation log table and transaction data from the external transaction record table. It compares the local records with the transaction data, identifying the type of discrepancy and counting the number of discrepancies when they occur in the transaction amount or status. This information is then written to the reconciliation report table, achieving automated verification of business data and timely detection of data inconsistencies. A preset monitoring period is set, and business operation indicators are statistically analyzed and written to the business operation indicator record table within each monitoring period. This establishes a regular monitoring and indicator statistical mechanism for business operation status, providing a quantitative basis for real-time monitoring of system operation status.

[0112] The audit supervision module, through the collaborative efforts of the log collection unit and the reconciliation monitoring unit, achieves complete collection of audit data and automated verification of business data. The log collection unit collects operation log data from various modules, categorizes and organizes it according to business transaction numbers, and writes it into the operation log record table, establishing a complete operation audit trajectory. It also sets a preset collection cycle to periodically pull transaction data from participating systems, categorizes it according to business transaction numbers, and writes it into an external transaction record table. The business transaction numbers, operation log record table, and external transaction record table are encapsulated into a log collection data package, providing a complete data foundation for subsequent reconciliation comparisons. The reconciliation monitoring unit reads local records from the operation log record table based on the business transaction number and reads transaction data from the external transaction record table for comparison. When transaction amounts or transaction statuses are inconsistent, the difference type is identified, the number of differences is counted, and the data is written into the reconciliation report table, enabling timely detection of data inconsistencies. It also sets a preset monitoring cycle to periodically collect business operation indicators and write them into the business operation indicator record table, establishing a periodic monitoring mechanism for business operation status. Furthermore, it provides an audit query interface for external systems to call, establishing an open mechanism for audit data. Compared to traditional manual reconciliation and auditing methods lacking systematic monitoring, this module achieves complete collection of audit data through automated log collection and regular transaction data retrieval. It also enables accurate verification of business data and timely detection of data inconsistencies through automated reconciliation and comparison, and achieves transparent monitoring of system operation status through regular statistical analysis of business operation indicators, thereby improving the accuracy of business data and the transparency of system operation.

[0113] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units. The above are merely embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made based on the description and drawings of this application, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

[0114] The specific embodiments of the invention have been described in detail above, but they are only examples, and this application is not limited to the specific embodiments described above. For those skilled in the art, any equivalent modifications or substitutions to the invention are also within the scope of this application. Therefore, all equivalent changes, modifications, and improvements made without departing from the spirit and principles of this application should be covered within the scope of this application.

Claims

1. A medical insurance business communication management system based on face recognition, characterized in that: It includes an identity authentication module, a transaction coordination module, a status management module, an exception recovery module, and an audit and supervision module; The identity authentication module collects facial images of insured persons and performs liveness detection, extracts facial feature vectors and compares them with the medical insurance database, combines social security card chip information to perform two-factor authentication, and generates authentication tokens and globally unique business transaction numbers. The transaction coordination module receives the business serial number and authentication token, sends preprocessing requests in parallel to the medical insurance system, medical institution system and bank payment system of the insured's place of insurance, obtains the pre-operation vouchers returned by each system, and sends confirmation instructions or cancellation instructions to each system according to the response results. The status management module records the current status and status change history of a business using the business serial number as the primary key, scans non-final state business records, and queries the actual execution status of each participating system. The anomaly recovery module receives anomaly notifications from the status management module, queries the actual business status from each participating system, and performs compensation operations based on the query results. The compensation request carries the original business transaction number. The audit and supervision module collects operation logs from each module, pulls transaction flow data from each participating system, compares it with local records to generate reconciliation reports, monitors business operation indicators, and provides an audit query interface.

2. The medical insurance business communication management system based on face recognition according to claim 1, characterized in that, The identity authentication module includes a biometric verification unit and a business initialization unit; The biometric verification unit acquires facial images of insured persons through image acquisition devices and performs liveness detection. It extracts facial feature vectors and calculates the similarity between them and the facial feature vectors pre-stored in the medical insurance database. When the similarity reaches a preset threshold, the verification is deemed successful. At the same time, it reads the identity information in the social security card chip for cross-verification, queries the insured person's insurance status record and medical insurance benefit eligibility record, and generates an authentication token containing the insured person's unique identifier, verification timestamp, and validity period. The business initialization unit receives the authentication token from the biometric verification unit, extracts the insured person's unique identifier and verification timestamp from the authentication token, generates a globally unique business serial number by combining the timestamp with a random number, obtains medical information and expense details, and encapsulates the insured person's unique identifier, medical information, expense details, authentication token, and business initiation time into a business context object. The business context object is stored in the transaction log table of the local database with the business serial number as the primary key.

3. The medical insurance business communication management system based on face recognition according to claim 2, characterized in that, The transaction coordination module includes a pre-operation execution unit and a transaction commit unit; The pre-operation execution unit receives the business transaction number and business context object transmitted by the identity authentication module, parses the business context object to obtain the expense details and authentication token, constructs a pre-deduction request data packet and sends it to the medical insurance system of the insured location to obtain the pre-deduction voucher, constructs a pre-billing request data packet and sends it to the medical institution system to obtain the pre-billing voucher, constructs a pre-payment request data packet and sends it to the bank payment system to obtain the pre-payment voucher, collects the response status of each participating system within a preset time threshold, determines whether all pre-operations are successful, and encapsulates the determination result and pre-operation voucher into a pre-operation result data packet; The transaction commit unit receives the pre-operation result data packet transmitted by the pre-operation execution unit and extracts the judgment result. When the judgment result is that all pre-operations are successful, it sends a confirmation deduction instruction with pre-deduction voucher to the medical insurance system of the insured location, a confirmation accounting instruction with pre-accounting voucher to the medical institution system, and a confirmation payment instruction with pre-payment voucher to the bank payment system. When the judgment result is that some pre-operations have failed, it sends a cancellation instruction with corresponding voucher to the system that has completed the pre-operation. Based on the final response results of each participating system, it updates the business status and constructs a status change notification data packet to be transmitted to the status management module.

4. The medical insurance business communication management system based on face recognition according to claim 3, characterized in that, The pre-operation execution unit includes a request construction unit and a response collection unit; The request construction unit receives the business transaction number and business context object transmitted by the identity authentication module, parses the expense details and authentication token from the business context object, constructs a pre-deduction request data packet containing the business transaction number and authentication token based on the personal account payment amount, constructs a pre-billing request data packet based on the total medical expenses and the medical insurance fund payment amount, constructs a pre-payment request data packet based on the medical insurance fund payment amount, and sends the three types of request data packets to the medical insurance system, medical institution system and bank payment system in the insured's place of insurance through the network communication interface, records the system identifier and sending timestamp of each participating system and encapsulates them into a request sending record data packet; The response collection unit receives the request sending record data packet transmitted by the request construction unit, extracts the system identifier and sending timestamp of each participating system, adds the sending timestamp to a preset time threshold to calculate the response timeout point, creates a response status record table in the local database, monitors network communication connections, receives pre-deduction vouchers containing frozen transaction numbers returned by the medical insurance system of the insured's place of insurance, receives pre-billing vouchers containing pre-billing transaction numbers returned by the medical institution system, and receives pre-payment vouchers containing frozen order numbers returned by the bank payment system. It writes the pre-operation vouchers into the response status record table, counts the number of successful responses and determines whether all pre-operations were successful, and encapsulates the determination result and pre-operation vouchers into a pre-operation result data packet.

5. The medical insurance business communication management system based on face recognition according to claim 4, characterized in that, The transaction commit unit includes an instruction distribution unit and a result aggregation unit; The instruction distribution unit receives the pre-operation result data packet and extracts the judgment result. When the judgment result is that all pre-operations are successful, it extracts the pre-deduction voucher, pre-accounting voucher, and pre-payment voucher. It combines the business transaction number with the transaction number in each voucher to construct a confirmation instruction data packet and sends it to the medical insurance system, medical institution system, and bank payment system of the insured's place of insurance, respectively. When the judgment result is that there is a failure in the pre-operation, it constructs a cancellation instruction data packet and sends it to the system that has completed the pre-operation. It records the system identifier and instruction sending timestamp and encapsulates it into an instruction sending record data packet. The results aggregation unit receives the instruction sending record data packet and extracts the system identifier, instruction sending timestamp, and judgment result. It adds the instruction sending timestamp to a preset time threshold to calculate the response timeout point, creates an execution result record table in the local database, monitors network communication connections and receives response status codes returned by each participating system, counts the number of successful responses, updates the business status to success, failure, or exception based on the judgment result and response status code, encapsulates the business serial number, business status, and response status code into a status change notification data packet, and sends it to the status management module.

6. The medical insurance business communication management system based on face recognition according to claim 5, characterized in that, The status management module includes a status recording unit and a status scanning unit; The status recording unit receives status change notification data packets and extracts the business serial number, business status, and execution results of each participating system. It creates a business status record table in the local database with the business serial number as the primary key, writes the business status and execution results into the business status record table, and writes the original status into the status change history table when a new status change notification data packet is received. It updates the business status record table with the new business status and transmits the business serial number and current status to the status scanning unit. The status scanning unit receives the business transaction number and the current status, sets a preset scanning period, queries the business status record table and filters non-final state business records in each scanning period, extracts the business transaction number and constructs a status query request data packet, sends the status query request data packet to the medical insurance system, medical institution system and bank payment system in the insured's place of insurance, collects the actual execution status returned by each participating system, and constructs an exception notification data packet when the actual execution status is inconsistent with the recorded status and sends it to the exception recovery module.

7. A medical insurance business communication management system based on face recognition according to claim 6, characterized in that, The status recording unit includes a status writing unit and a history archiving unit; The status writing unit receives the status change notification data packet and extracts the business serial number, business status and execution result. It queries whether the business serial number already exists in the business status record table. If the business serial number does not exist, it creates a new record and writes the business status and execution result. If the business serial number already exists, it reads the original status and constructs a historical record data packet and transmits it to the historical archiving unit. After waiting for the archiving completion notification, it updates the new business status to the business status record table. The historical archiving unit receives historical data packets and extracts the business transaction number, original status, and status change time. It creates a status change history table in the local database, generates a historical record identifier as the primary key, writes the business transaction number, original status, and status change time into the status change history table, and returns an archiving completion notification to the status writing unit. The status writing unit updates the new business status into the business status record table and then passes the business transaction number and current status to the status scanning unit.

8. A medical insurance business communication management system based on face recognition according to claim 7, characterized in that, The state scanning unit includes a periodic scanning unit and a state comparison unit; The periodic scanning unit receives the business serial number and the current status, sets a preset scanning period, queries the business status record table in each scanning period and filters non-final business records with statuses of confirmation, cancellation, or abnormal, extracts the business serial number and encapsulates it into a status query request data packet, sends the status query request data packet to the medical insurance system, medical institution system, and bank payment system of the insured's place of insurance, records the system identifier and query request sending timestamp and encapsulates it into a query request record data packet. The status comparison unit receives the query request record data packet and extracts the business serial number, system identifier, and query request sending timestamp. It adds the query request sending timestamp to a preset time threshold to calculate the response timeout point, creates an actual status record table in the local database, listens for network communication connections and receives the actual execution status returned by each participating system, queries the business status record table according to the business serial number and reads the record execution status, compares the actual execution status with the record execution status, and when they are inconsistent, encapsulates the business serial number and inconsistency type into an exception notification data packet and sends it to the exception recovery module.

9. A medical insurance business communication management system based on face recognition according to claim 8, characterized in that, The anomaly recovery module includes a status verification unit and a compensation execution unit; The status verification unit receives the anomaly notification data packet and extracts the business transaction number and inconsistency type. After locating the participating system with the anomaly, it encapsulates a detailed status query request, collects the health parameters of each system, calculates the real-time reliable weight, and determines the true status of the business as successful, failed, or partially successful based on a weighted statistical mechanism. The verification result and system parameters are then encapsulated into a status verification result data packet and transmitted. After receiving the status verification result data packet, the compensation execution unit constructs a lightweight digital twin image, simulates multiple candidate compensation strategies in parallel and collects execution indicators, generates the optimal strategy through a reinforcement learning model, and generates retry, rollback or differential compensation instructions in combination with transaction dependency differences. The instruction hash is written into the consortium chain to trigger cross-system consensus. After reaching the fault tolerance threshold, a certificate is generated. If the main strategy fails, the backup strategy is automatically triggered.

10. A medical insurance business communication management system based on face recognition according to claim 9, characterized in that, The audit and supervision module includes a log collection unit and an account reconciliation monitoring unit; Operation log data is collected from the transaction coordination module, status management module, and exception recovery module, and then classified and organized according to the business transaction number before being written into the operation log record table. A preset collection period is set, and within each collection period, transaction flow data is pulled from the medical insurance system, medical institution system, and bank payment system of the insured's place of insurance, and then classified and organized according to the business transaction number before being written into the external transaction flow record table. The business transaction number, operation log record table, and external transaction flow record table are encapsulated into a log collection data package and transmitted to the reconciliation monitoring unit. The system receives log collection data packets and extracts the business transaction number. Based on the business transaction number, it reads local records from the operation log record table and transaction data from the external transaction record table. It compares the local records with the transaction data. When the transaction amount or transaction status is inconsistent, it identifies the difference type, counts the number of differences, and writes them to the reconciliation report table. It sets a preset monitoring period, counts business operation indicators in each monitoring period, and writes them to the business operation indicator record table. It provides an audit query interface for external systems to call.

Images