A medical payment reconciliation system and method based on a four-node closed loop and a storage medium

Abstract

The application provides a medical payment reconciliation system and method based on a four-node closed loop and a storage medium, aiming to solve the problems existing in the current medical payment reconciliation process and improve the efficiency and accuracy of hospital fund management. The core is to deeply integrate the four nodes of payment, delivery, return and refund into the hospital payment platform and hospital information center, and to build a full-link closed-loop management system, including a unified access module, a transaction processing module, a four-node state management module, a two-way state synchronization module, an abnormal monitoring and processing module, a dynamic reconciliation matrix module, a full-link audit log module and a visual management end module. The application realizes four-node full-process closed-loop management, builds a passive double-mode state synchronization mechanism, breaks through the lagging limitation of the traditional reconciliation mode, creates an intelligent reconciliation engine, improves the reconciliation efficiency and accuracy, has perfect distributed transaction management and compliance audit capability, and fully adapts to the compliance requirements of the medical industry.

Description

Technical Field

[0001] This invention relates to the field of medical payment technology, and in particular to a medical payment reconciliation system, method and storage medium based on a four-node closed loop. Background Technology

[0002] In today's booming healthcare industry, hospitals are increasingly diversifying their channels for handling various medical services (including registration, payment, admission and discharge). Self-service terminals, manual counters, and online services are now commonplace. All these channels rely on the hospital's unified payment and reconciliation system for fund settlement and transaction verification. The core objective is to ensure the hospital's financial security. When using the payment and reconciliation platform, strict procedures are followed: payment must be made before service is provided, and service cancellations must be processed before refunds are issued to prevent shortfalls and ensure the smooth operation of core medical services such as registration, payment, and hospitalization.

[0003] However, existing technologies have revealed numerous problems in practical applications. Regarding transaction processes, current technologies lack effective node monitoring and management mechanisms, resulting in severe process disconnects and a lack of node control. Payment, delivery, returns, and refunds are treated as independent stages, without unified integration and collaborative management of these four core nodes. There is a lack of end-to-end node linkage mechanisms and corresponding standardized interface designs, leading to severe data silos. Existing systems cannot simultaneously obtain the real payment, delivery, return, and refund statuses of merchants and business parties through a combination of proactive and reactive calls. They lack real-time monitoring mechanisms for the two key stages of "payment-delivery" and "return-refund," making it difficult to quickly identify abnormal transactions, especially the two critical abnormal orders: successful payment but unsuccessful delivery, and successful return but unsuccessful refund. Furthermore, although automation and intelligence levels are gradually improving, existing systems still heavily rely on manual operations, with insufficient integration of manual and automated system reviews. This leads to errors during the reconciliation process, resulting in high costs and delays in identifying refunds owed to patients, which in turn leads to patient complaints. This not only brings unnecessary negative impacts to the hospital but also increases the hospital's workload in handling complaints, reduces overall operational efficiency, and is more likely to trigger doctor-patient conflicts, damaging the hospital's image.

[0004] While mainstream payment and reconciliation systems in the healthcare industry can theoretically reduce human error, they suffer from fragmented processes, lack of node control, delayed anomaly identification, and insufficient coordination between human and system processing. As a result, they cannot meet the needs for efficient and accurate order inquiry and reconciliation. There is an urgent need to build an intelligent payment and reconciliation system with multi-node closed-loop management. Summary of the Invention

[0005] The technical problem to be solved by the present invention is: in order to overcome the shortcomings of the prior art, the present invention provides a medical payment reconciliation system and method based on a four-node closed loop.

[0006] The technical solution adopted by this invention to solve its technical problem is: a medical payment reconciliation system based on a four-node closed loop, comprising a unified access module, a transaction processing module, a four-node status management module, a two-way status synchronization module, an anomaly monitoring and handling module, a dynamic reconciliation matrix module, a full-link audit log module, and a visual management terminal module, wherein...

[0007] The unified access module communicates with the transaction processing module and integrates the interface protocols of multiple financial merchant payment channels (payment channels). It establishes standardized access specifications and provides standardized interfaces for connecting with various external access entities (i.e., external access channels). These standardized interfaces include, but are not limited to, payment interfaces, delivery notification interfaces, return notification interfaces, and refund interfaces. External access entities include, but are not limited to, hospital HIS systems, hospital self-service terminals, manual window cashier systems, online medical platforms, and third-party payment channels (external payments). The module receives initial business requests from various external access entities, performs compliance verification on the business requests of each cooperating platform by calling the compliance database, and obtains verified business requests. The verified business requests are then sent to the transaction processing module. Compliance verification includes performing message format verification, signature verification, and authorization authentication on all access business requests.

[0008] The transaction processing module communicates with the unified access module, the four-node status management module, the end-to-end audit log module, and the visualization management module. It receives business requests from the unified access module, such as payment, delivery notifications, return notifications, and refunds, and performs legality verification, routing distribution, transaction log generation, and status tracking. For each business request, it generates a globally unique transaction serial number and ultimately initiates payment and refund transaction requests to the payment channel. The transaction serial number is bound to transaction information and stored to form a transaction record with a unique end-to-end transaction index, serving as the data foundation for the four-node status linkage. Simultaneously, it generates audit logs and pushes them to the end-to-end audit log module. It also acquires transaction data from the visualization management module and provides data display to it. The transaction information includes, but is not limited to, business order number, patient identifier, payment channel identifier, business type, transaction amount, and timestamp. Furthermore, based on the TCC distributed transaction protocol, this module performs transaction control on cross-system transaction operations, ensuring eventual consistency of the "payment-delivery" and "return-refund" stages, and avoiding transaction inconsistency issues in distributed scenarios.

[0009] The four-node status management module communicates with the transaction processing module, the two-way status synchronization module, the anomaly monitoring and handling module, and the dynamic reconciliation matrix module. This module has a built-in state machine model for four core nodes: payment, delivery, return, and refund. It constructs a four-state snapshot mechanism covering the entire chain, which uses the transaction serial number generated by the transaction processing module as an index to generate a traceable and verifiable standardized four-state snapshot of the entire process status of each transaction, forming transaction status information. At the same time, it has a built-in status comparison engine, which performs consistency verification on the status data of the four nodes in the real-time transaction flow received from the two-way status synchronization module based on a preset rule base, marks the status deviation, and sends the verification result to the anomaly monitoring and handling module. In addition, it provides the four-node status data to the dynamic reconciliation matrix module during the reconciliation the next day.

[0010] The bidirectional status synchronization module communicates with the four-node status management module, the payment channel, and the hospital's HIS system. It has a built-in dual-mode mechanism that combines passive callback mode and active polling mode. It is used to collect the real-time transaction flow of the payment channel and the hospital's HIS system, send the real-time transaction flow to the four-node status management module to update the four-state snapshot, assist in generating an abnormal order list, and realize the real-time synchronization of the four-node status.

[0011] The anomaly monitoring and handling module communicates with the four-node status management module to receive the verification results from the four-node status management module, query transaction records based on the verification results, and generate a list of suspected delivery anomalies based on the transaction records, so as to realize the real-time identification and closed-loop handling of abnormal orders on the same day.

[0012] The dynamic reconciliation matrix module communicates with the four-node status management module, the visualization management module, the payment channel, and the hospital's HIS system. It is used to collect bills from the payment channel and the hospital's HIS system. It has a built-in multi-source data cross-comparison model. Based on multiple key data points of the bills stored in the reconciliation system, it performs full intelligent reconciliation of the multi-source reconciliation data sources the next day, automatically filters out normal bills, accurately identifies abnormal reconciliation orders by combining time nodes, and generates a reconciliation anomaly list and corresponding reconciliation conclusions based on the bill status, time nodes, and four-node status. The results are displayed through the visualization management module as a basis for hospital financial staff to take action.

[0013] The end-to-end audit log module communicates with the transaction processing module to receive audit logs from the transaction processing module, real-time transaction records, and transaction status information, ensuring that the system meets the hospital's security management requirements.

[0014] The visualization management module communicates with the transaction processing module and the dynamic reconciliation matrix module, respectively, and is used to display the queried transaction information and billing information in a visual way.

[0015] Furthermore, the transaction processing module performs transaction management on cross-system transaction operations based on the TCC distributed transaction protocol.

[0016] Furthermore, the state machine model built into the four-node state management module presets legal state transition paths, allowing only the forward transaction path of "pending payment → payment successful → pending delivery → delivery successful" and the reverse transaction path of "pending return → return successful → pending refund → refund successful" to be executed sequentially, intercepting illegal state jump requests and forcibly following the business rule of "payment before delivery, return before refund"; in the four-state snapshot mechanism, the state change of each node is bound to a unique transaction serial number, operation timestamp, system source identifier, operator signature and channel response code, generating an immutable state snapshot.

[0017] Furthermore, the passive callback mode opens a dedicated encrypted callback interface, which uses the dedicated encrypted callback interface of the unified access module to receive payment status and refund status change notifications actively pushed by the payment channel, as well as delivery status and return status change notifications actively pushed by the hospital's HIS system. After receiving the callback, the corresponding status snapshot in the four-node status management module is updated in real time to realize the collection of transaction status information in the passive callback mode.

[0018] The proactive polling mode initiates order status query requests to the payment channel according to a preset configurable polling cycle to obtain the actual payment status and refund status of each transaction, and initiates business status query requests to the hospital's HIS system to obtain the actual delivery status and return status of each transaction. For timed-out orders with outdated statuses, the polling frequency is automatically increased to ensure the accuracy and real-time nature of the status data. In scenarios where financial merchants have not issued invoices for the same day, a list of suspected delivery anomalies and a list of returns pending refunds are automatically generated.

[0019] The dual-mode mechanism completely resolves the issue of state asynchrony caused by network jitter or interface timeouts, ensuring eventual data consistency. Especially when data is passively unavailable, the system actively queries to correct the state. Through this two-pronged approach, the system can comprehensively and accurately grasp the real-time status of each business process, providing a solid data foundation for subsequent anomaly handling and reconciliation. Therefore, in scenarios where financial merchants have not issued invoices for the day, the system can separately generate a delivery anomaly list and a return pending refund list, overcoming the lag limitations of traditional next-day reconciliation refunds and providing data support for same-day anomaly handling.

[0020] Furthermore, the anomaly monitoring and processing module includes a delivery anomaly processing unit and a return / refund anomaly processing unit, wherein,

[0021] The delivery anomaly handling unit, based on the verification results of the four-node status management module (i.e., the four-state comparison engine), filters out orders that are "paid successfully but delivered unsuccessfully" in real time, and automatically generates a list of suspected delivery anomalies. The list includes core information such as transaction serial number, business order number, payment time, payment amount, payment channel, patient information, anomaly type, and timeout duration. It is displayed in real time through the visualization management module, supporting financial personnel to perform order verification, re-trigger delivery, and single-sided account confirmation operations. During the daily reconciliation window, if the order is confirmed to be a single-sided account with successful payment but failed delivery, the transaction processing module is automatically triggered to perform a refund operation on the original payment method, completing the order loop and avoiding the risk of hospital cash shortage.

[0022] The return and refund exception handling unit, based on the verification results of the four-node status management module (i.e., the four-state comparison engine), filters out orders that are "successfully returned but not successfully refunded" in real time and automatically generates a list of returned items pending refund. This list is displayed in real time through the visual management module, supporting staff to perform return compliance checks and trigger refund retry operations. Within the order query window of the day, if the order is confirmed to meet the refund rules, the transaction processing module is automatically triggered to execute the original payment method refund operation, ensuring the patient's refund rights and compressing the refund response time from the traditional T+1 to T+0.5.

[0023] Furthermore, the key data of the reconciliation data source includes eight items, namely, the payment status snapshot, delivery status snapshot, return status snapshot, refund status snapshot, positive transaction bills on the merchant side, negative transaction bills on the merchant side, positive transaction bills on the business side, and negative transaction bills on the business side stored in the system; the multi-source data cross-comparison model uses the globally unique transaction serial number as an index to automatically filter out normal bills that can be balanced, and, in conjunction with time nodes, accurately identifies abnormal reconciliation orders, and outputs reconciliation conclusions and standardized handling suggestions for each abnormal order.

[0024] A medical payment reconciliation method based on a four-node closed loop, implemented using the aforementioned medical payment reconciliation system based on a four-node closed loop, further includes the following steps:

[0025] S1: Based on the initial business request initiated by the received external access channel, the interface protocol is integrated through the unified access module to obtain the business request;

[0026] S2: Based on the business request, the transaction processing module performs legality verification and generates a transaction record with a globally unique transaction serial number bound to the business request, thus completing the transaction initialization; and initiates a payment or refund request to the payment channel according to the transaction record.

[0027] S3: Based on a preset four-node state machine model, it manages the state transitions of the four nodes—payment, delivery, return, and refund—throughout the entire process and intercepts illegal state transition requests. Each node's state change generates an immutable state snapshot bound to the transaction serial number. The state comparison engine performs millisecond-level consistency checks on the four-node states and marks state deviations in real time.

[0028] S4: It adopts a dual-mode mechanism that combines passive callback and active polling to synchronize the payment status and refund status of the financial merchant side and the delivery status and return status of the hospital's HIS system in real time, and update the status snapshot of the four nodes simultaneously; in the scenario where the financial merchant has not issued a bill on the same day, it automatically generates a list of suspected delivery anomalies and a list of returns pending refund.

[0029] S5: The abnormal order list is displayed in real time through a visual management terminal, which supports manual review by finance personnel; during the daily reconciliation window, the original payment method or refund operation is automatically triggered for confirmed one-sided order and compliant refund order, so as to achieve the same-day closed loop for abnormal orders;

[0030] S6: During the next day's reconciliation window, the intelligent reconciliation engine of the dynamic reconciliation matrix module, based on the core reconciliation data source and time nodes, performs full reconciliation through a multi-source data cross-comparison model, automatically filters out normal bills that can be balanced, accurately identifies reconciliation abnormal orders, generates a reconciliation abnormality list, and outputs reconciliation conclusions and standardized handling suggestions for each abnormal order, thus completing full account reconciliation.

[0031] S7: Throughout the entire transaction process, the full-link audit log module encrypts and records all transaction operations, status changes, anomaly handling, and reconciliation operations, achieving tamper-proof full-process traceability and meeting the financial compliance and Level 3 information security protection requirements of the medical industry.

[0032] Furthermore, the business request mentioned in step S1 is a payment request. When the unified access module receives the payment request, the transaction processing module sends the payment request to the payment channel. After receiving the payment success result information from the payment channel, the module sends the delivery result verification request to the hospital's HIS system within a specified time.

[0033] In response to the successful delivery result issued by the hospital's HIS system, the two-way status synchronization module uploads the current transaction flow status to the four-node status management module.

[0034] Furthermore, the business request mentioned in step S1 is a refund request. When the unified access module receives the refund request, the transaction processing module will eventually send a return result verification request to the hospital's HIS service until it receives the return success result information from the hospital's HIS service and then forwards the refund request to the payment channel.

[0035] In response to the payment channel issuing a successful refund result, the transaction processing module will synchronize the current transaction flow status from the four-node status management module.

[0036] A computer-readable storage medium, characterized in that the computer program-readable storage medium has a computer program / instructions embodied thereon, the computer program / instructions being executable by one or more processors, the computer program / instructions implementing the steps of the above-described four-node closed-loop medical payment reconciliation method when executed by the processors.

[0037] Furthermore, the medical payment reconciliation system based on a four-node closed loop is a purely software-implemented business system deployed on a general-purpose x86 architecture server cluster within the hospital's intranet. It runs on domestic server operating systems (such as Kylin, UnionTech, and DragonLizard), and is built using a Spring Boot microservice architecture, a MySQL relational database, a Redis caching middleware, and a RabbitMQ message queue middleware. Each module is a software logical functional unit, communicating with the message queue via HTTPS protocol; there are no independent dedicated hardware modules. The system interfaces with the hospital's HIS system, self-service terminals, and POS system (including medical insurance) through the hospital's intranet, and establishes a secure connection with external financial payment channels via an encrypted dedicated line, meeting the overall requirements of Level 3 network security protection and medical industry financial compliance.

[0038] The beneficial effects of this invention are:

[0039] (1) Achieve closed-loop management of the entire process of four nodes and solve the core problem of the disconnect between business flow and capital flow from the source: This invention innovatively incorporates the four core nodes of payment, delivery, return and refund into a unified state machine management framework. Through standardized interface design and legal state transition path control, it enforces the rigid rule of "payment before delivery and return before refund" in the medical industry, realizes the deep integration of business process and financial reconciliation process, and completely solves the problems of independent nodes, process fragmentation and data silos in the existing technology. It avoids the capital security risks of long and short payments and one-sided accounts from the source of the process.

[0040] (2) Constructing a dual-mode active and passive status synchronization mechanism to overcome the lag limitation of the traditional reconciliation mode: This invention uses a dual-mode status synchronization mechanism that combines passive callback and active polling. It can obtain the real status of four nodes in real time on the same day without waiting for the financial merchant's T+1 bill. It can accurately identify two types of core abnormal orders: "payment successful but delivery not delivered" and "return successful but refund not issued". It can realize the same-day identification and handling of abnormal orders, and reduce the average refund response time from the traditional T+1 to T+0.5. It can effectively prevent patient refund complaints and doctor-patient conflicts, which can not only protect the hospital's financial security, but also protect the legitimate rights and interests of patients.

[0041] (3) Building an intelligent reconciliation engine to significantly reduce reliance on manual labor and improve reconciliation efficiency and accuracy: The intelligent reconciliation engine of this invention is based on a multi-source cross-comparison model with 8 core data sources and time nodes. It can automatically filter out more than 95% of normal bills that can be adjusted and accurately locate the truly abnormal orders that need to be processed. At the same time, it automatically outputs reconciliation conclusions and standardized handling suggestions, which completely changes the traditional operation mode of manual reconciliation of each item by finance personnel, greatly reduces the workload of manual reconciliation of finance personnel, reduces the error rate of human operation, significantly improves reconciliation efficiency and accounting accuracy, and provides timely and accurate financial data support for hospital financial management and business decision-making.

[0042] (4) Possesses comprehensive distributed transaction management and compliance audit capabilities, fully adapting to the compliance requirements of the medical industry: This invention effectively ensures the eventual consistency of distributed transactions across HIS systems, multiple payment channels, and multiple business terminals through the TCC distributed transaction protocol; at the same time, through the full-link audit log module, it realizes the operation traceability and tamper-proof encrypted storage of the entire transaction process, fully meeting the compliance requirements of the "Financial System for Medical and Health Institutions" and the Level 3 Network Security Protection, providing complete evidence support for hospital financial compliance audit and transaction dispute tracing.

[0043] (5) High adaptability and scalability, fully covering all scenarios of hospital medical payment business: Through a standardized unified access module, this invention can quickly adapt to various business channels such as hospital self-service terminals, manual windows, and online medical platforms, as well as various financial payment channels such as WeChat Pay, Alipay, and bank payment. The interface adaptation cost is low and the scalability is strong. It can fully cover all scenarios of hospital medical payment business such as registration, outpatient payment, inpatient settlement, and day surgery settlement, and meet the payment reconciliation management needs of hospitals of different sizes. Attached Figure Description

[0044] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0045] Figure 1 This is a schematic diagram of the external docking body involved in the present invention.

[0046] Figure 2 This is a transaction flowchart for a multi-node payment reconciliation system.

[0047] Figure 3 This is a flowchart of the payment and delivery process through the access channel.

[0048] Figure 4 This is a flowchart of the return and refund process through the access channel.

[0049] Figure 5 This is a flowchart illustrating the mechanism by which the payment reconciliation system obtains the status of the four nodes.

[0050] Figure 6 This is a flowchart of the payment reconciliation system for the next day.

[0051] Figure 7 This is a diagram illustrating the data flow relationships between the various modules.

[0052] Figure 8 This is the overall flowchart of the payment reconciliation system. Detailed Implementation

[0053] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0054] This invention discloses a medical payment reconciliation system based on a four-node closed loop, aiming to solve the problems existing in the current medical payment reconciliation process and improve the efficiency and accuracy of hospital fund management. Figure 2 As shown, the core is to deeply integrate the four nodes of payment, delivery, return, and refund into the hospital's aggregated payment platform and hospital information center to build a closed-loop control system for the entire chain. Specifically, it includes a unified access module, a transaction processing module, a four-node status management module, a two-way status synchronization module, an anomaly monitoring and handling module, a dynamic reconciliation matrix module, a full-chain audit log module, and a visual management terminal module. The specific functions and interaction logic of each module are as follows.

[0055] (1) Unified access module

[0056] like Figure 7 As shown, the unified access module communicates with the transaction processing module. This module is responsible for integrating the interface protocols of multiple financial merchant payment channels (payment channels), formulating standardized access specifications that conform to medical industry standards, and providing unified and standardized payment interfaces, delivery notification interfaces, return notification interfaces, and refund interfaces. Figure 1As shown, the external entities it interfaces with include the hospital's HIS system (hospital HIS services and HIS windows), hospital self-service terminals (hospital self-service machines), manual window cashier systems, online medical platforms (hospital online medical services), and third-party payment channels (external payments). It performs message format verification, signature verification, and authorization authentication on all access requests to ensure the legality of access and the consistency of data formats, completely resolving the fragmentation problem of interfaces across multiple channels and systems and eliminating data silos. In specific implementation, the system first receives payment requests from hospital self-service machines, HIS windows, or online platforms, generating a unique transaction serial number. After successful payment, the system monitors the delivery feedback from the HIS system in real time; if a refund occurs, the system verifies the return status before initiating the refund. For any out-of-synchronization anomalies, the system displays them in a list on the web interface and supports finance personnel in triggering order replenishment or refund operations with a single click.

[0057] (2) Transaction processing module

[0058] like Figure 7 As shown, this module communicates with the unified access module, the four-node status management module, the end-to-end audit log module, and the visualization management module. It is responsible for receiving payment, delivery notifications, return notifications, and refund requests forwarded by the unified access module, and performing request validity verification, transaction routing and distribution, transaction log generation, real-time status tracking, and transaction result forwarding. For each business request, a globally unique transaction log number is generated. This transaction log number is then bound and stored with the business order number, patient identifier, payment channel identifier, business type, transaction amount, and timestamp, forming a unique transaction index across the entire chain, providing the data foundation for the four-node status linkage. Simultaneously, based on the TCC distributed transaction protocol, this module performs transaction control on cross-system transaction operations, ensuring eventual consistency of the "payment-delivery" and "return-refund" stages, and avoiding transaction inconsistency issues in distributed scenarios.

[0059] (3) Four-node status management module

[0060] like Figure 7As shown, this module communicates with the transaction processing module, the two-way state synchronization module, the anomaly monitoring and handling module, and the dynamic reconciliation matrix module, and is the core control module of this invention. It incorporates a state machine model for four core nodes: payment, delivery, return, and refund. This model generates a traceable and verifiable standardized state snapshot for the entire transaction process, and implements a full-link state control mechanism for state consistency verification and illegal transition interception. The construction method uses the globally unique transaction serial number generated by the transaction processing module as the core index, strongly associating the state data of each node with the transaction serial number, operation timestamp, system source identifier, operator signature, and channel response code, ensuring that each snapshot can accurately locate the corresponding transaction. When the state of the four core nodes (payment, delivery, return, and refund) changes, an independent state snapshot is generated in real time and written to a time-series database for persistent storage, forming a state chain covering the entire transaction lifecycle. Simultaneously, consistency verification rules are embedded. Based on a pre-defined rule base (including node timeout thresholds, state transition legality rules, channel response code mapping tables, and business type adaptation rules), millisecond-level consistency verification is performed on the state data of the four nodes. State deviation types and deviation points are automatically marked, providing precise anchor points for anomaly identification and reconciliation verification. The state machine model pre-defines a unique and legal state transition path, allowing only the forward transaction path of "pending payment → payment successful → pending delivery → delivery successful" and the reverse transaction path of "pending return → return successful → pending refund → refund successful." It directly intercepts all illegal state transition requests, forcibly adhering to the medical payment business rule of "payment before delivery, return before refund" from a process perspective.

[0061] This mechanism functions in the following ways:

[0062] End-to-end status traceability: Generates traceable and verifiable status snapshots, fully retains the status change records of the entire transaction process, and provides evidence support for end-to-end auditing, dispute tracing, and financial verification.

[0063] Ensuring eventual consistency: Real-time verification of the state matching degree of the four nodes resolves the issue of asynchronous payment / delivery / return / refund states in distributed transactions, ensuring the consistency of business flow and fund flow states.

[0064] Accurately identify transaction anomalies: Quickly pinpoint core anomalies such as "successful payment but no delivery" and "successful return but no refund," providing precise data support for closed-loop anomaly handling on the same day.

[0065] Supports intelligent reconciliation closed loop: Provides a status baseline for the dynamic reconciliation matrix module, and achieves accurate identification and handling suggestions for abnormal orders through cross-comparison of multi-source data, thereby improving reconciliation efficiency and accuracy.

[0066] Enforcing mandatory business rules: Solidifying rigid business rules for medical payments from a technical perspective, avoiding financial security risks such as one-sided accounts and overdue or underpaid payments from the source, and protecting hospital funds and patients' rights.

[0067] like Figure 3 As shown, the payment and delivery process through the access channel includes the following steps:

[0068] S301: Hospital self-service machines, hospital online medical services, and HIS windows (hereinafter referred to as hospital access channels) obtain the corresponding services from the hospital's HIS system and display them on their respective interfaces. After the patient confirms the service, the hospital access channel initiates a payment request to the hospital's payment reconciliation system.

[0069] S302: The hospital's in-hospital payment reconciliation system receives a payment request from the hospital's access channel, stores the business data, and then sends the payment request to the financial merchant payment channel service.

[0070] S303: The hospital's in-hospital payment reconciliation system receives payment success result information returned by the financial merchant payment channel service and sends this payment success result information to the hospital's access channel;

[0071] S304: The hospital access channel receives the payment success result information returned by the hospital's internal payment reconciliation system and initiates a delivery request to the hospital's HIS service;

[0072] S305: After receiving a delivery request from the access channel, the hospital's HIS service will complete the delivery within the hospital's HIS system and return the successful delivery result to the hospital's access channel.

[0073] S306: After receiving the delivery success notification, the hospital access channel will display a service success notification on its respective interface, allowing the patient to continue with the next step of medical treatment.

[0074] like Figure 4 As shown, the return and refund process through the access channel includes the following steps:

[0075] S401: Hospital self-service machines, hospital online medical services, and HIS windows (hereinafter referred to as hospital access channels) obtain the corresponding refundable services from the hospital's HIS system and display them on their respective interfaces. After the patient confirms the cancellation of the service, the hospital access channel initiates a refund request to the hospital's HIS system.

[0076] S402: The hospital's HIS system receives a return request from the hospital's access channel. After completing the business return within the hospital's HIS system, it returns the successful return result to the hospital's access channel.

[0077] S403: After receiving the successful return result information from the hospital's HIS system, the hospital access channel initiates a refund request to the hospital's payment reconciliation system;

[0078] S404: The hospital's in-hospital payment reconciliation system receives a refund request from the hospital's access channel, stores the business data, and then sends the refund request to the financial merchant payment channel service.

[0079] S405: The hospital's in-hospital payment reconciliation system receives the refund success result information returned by the financial merchant payment channel service and sends the refund success result information to the hospital's access channel;

[0080] S406: After receiving the successful refund result information, the hospital access channel will display a message on its respective interface notifying the patient that the business return was successful and the refund was successful.

[0081] (4) Two-way state synchronization module

[0082] like Figure 7 As shown, this module communicates with the four-node status management module, the payment channel (external payment), and the internal HIS (internal business), respectively. It adopts a dual-mode mechanism that combines passive callback and active polling to achieve real-time synchronization of the four-node status.

[0083] Passive callback mode: Open a dedicated encrypted callback interface to receive payment status and refund status change notifications actively pushed by the payment channel, as well as delivery status and return status change notifications actively pushed by the hospital's HIS system. After receiving the callback, update the corresponding status snapshot in the four-node status management module in real time.

[0084] Active polling mode: According to the preset configurable polling cycle, the system sends order status query requests to the payment channel to obtain the actual payment status and refund status of each transaction, and sends business status query requests to the hospital's HIS system to obtain the actual delivery status and return status of each transaction; for timed-out orders whose status is not synchronized, the polling frequency is automatically increased to ensure the accuracy and real-time nature of the status data.

[0085] The dual-mode mechanism completely resolves the issue of state asynchrony caused by network jitter or interface timeouts, ensuring eventual data consistency. Especially when data is passively unavailable, the system actively queries to correct the state. Through this two-pronged approach, the system can comprehensively and accurately grasp the real-time status of each business process, providing a solid data foundation for subsequent anomaly handling and reconciliation. Therefore, in scenarios where financial merchants have not issued invoices for the day, the system can separately generate a delivery anomaly list and a return pending refund list, overcoming the lag limitations of traditional next-day reconciliation refunds and providing data support for same-day anomaly handling.

[0086] like Figure 5 As shown, the process of obtaining the status of the four nodes in the payment reconciliation system includes the following steps:

[0087] S501: The hospital access channel or the hospital's HIS system polls the order status in real time, and the platform automatically records the actual payment and refund status of the orders.

[0088] S502: The hospital's payment reconciliation system periodically polls for orders with unknown payment or return statuses and automatically adds them to the inventory upon receipt.

[0089] S503: Delivery and return notifications from hospital access channels or in-hospital HIS systems, and the actual delivery and return status of business orders automatically entered into the platform's inventory system;

[0090] S504: The hospital payment reconciliation system periodically polls for orders with unknown business status in the hospital's HIS service to obtain the actual delivery and return status of the business orders.

[0091] S505: The hospital's payment reconciliation system provides a web interface that displays menus for handling suspected delivery anomalies and return / refund anomalies, and notifies finance personnel to handle them promptly.

[0092] (5) Anomaly monitoring and handling module

[0093] like Figure 7 As shown, this module is connected to the four-node status management module, including a delivery exception handling unit and a return and refund exception handling unit, to realize the real-time identification and closed-loop handling of abnormal orders on the same day.

[0094] Delivery Anomaly Handling Unit: Based on the verification results of the four-state comparison engine, it filters out orders that are "paid successfully but delivered unsuccessfully" in real time, automatically generating a list of suspected delivery anomalies. The list includes core information such as transaction serial number, business order number, payment time, payment amount, payment channel, patient information, anomaly type, and timeout duration. It is displayed in real time through a visual management module, supporting financial personnel to perform order verification, re-trigger delivery, and single-sided account confirmation operations. During the daily reconciliation window, if an order is confirmed to be a single-sided account with successful payment but failed delivery, the transaction processing module is automatically triggered to perform a refund operation on the original payment method, completing the order closure and avoiding the risk of hospital cash shortage.

[0095] Return and Refund Anomaly Handling Unit: Based on the verification results of the four-state comparison engine, it filters out orders that are "successfully returned but not successfully refunded" in real time and automatically generates a list of returned items pending refund. This list is displayed in real time through a visual management module, supporting staff to perform compliance checks on returns and trigger refund retry operations. Within the order query window of the day, if the order is confirmed to meet the refund rules, the transaction processing module is automatically triggered to execute the original payment method refund operation, ensuring the patient's refund rights and compressing the refund response time from the traditional T+1 to T+0.5.

[0096] (6) Dynamic reconciliation matrix module

[0097] Considering that finance personnel may not be able to process all refundable amounts in a timely manner every day, this system introduces an intelligent reconciliation engine for the next day's reconciliation. This engine performs comprehensive reconciliation based on eight key data points stored on the platform: payment status, delivery status, return status, refund status, positive transaction invoices on the merchant side, negative transaction invoices on the merchant side, positive transaction invoices on the business side, and negative transaction invoices on the business side, combined with time points. Through in-depth analysis and comparison of this data, the intelligent reconciliation engine can automatically filter out invoices that can be balanced, accurately identify truly outstanding abnormal invoices, and generate a reconciliation anomaly list. This four-state snapshot mechanism further supports the dynamic verification capabilities of the real-time reconciliation engine, realizing a chain-response logic of "payment success triggers delivery verification, delivery completion triggers pre-return verification, and return confirmation simultaneously initiates refund verification"; all state transitions are constrained by the TCC transaction protocol, ensuring eventual consistency across system operations. This mechanism also provides a status baseline for the generation of abnormal diagnostic reports, supporting a three-level linkage decision-making process of "deviation type - verification path - handling strategy": when deviations such as "payment without delivery" or "return without refund" are identified, the system automatically performs a dual-source comparison of the billing transaction and the platform's payment, delivery, return and refund status, and provides detailed reconciliation conclusions according to preset rules, providing strong assistance to hospital financial staff in handling abnormal bills and greatly improving reconciliation efficiency and accuracy.

[0098] like Figure 6 As shown, the next-day reconciliation process of the payment reconciliation system includes the following steps:

[0099] S601: The hospital's in-hospital payment reconciliation system obtains merchant billing data for financial merchant payment channel services the following day;

[0100] S602: The hospital's internal payment reconciliation system obtains the business billing data of the hospital's HIS services the following day;

[0101] S603: The hospital's payment reconciliation system uses an intelligent reconciliation engine to analyze eight key data results stored on the platform, including payment status, delivery status, return status, refund status, positive transaction bills on the merchant side, negative transaction bills on the merchant side, positive transaction bills on the business side, and negative transaction bills on the business side, to conduct a comprehensive reconciliation.

[0102] S604: The hospital's payment reconciliation system provides a web interface that automatically filters out bills that can be reconciled, identifies truly abnormal bills that need to be processed, displays a menu for handling reconciliation anomalies, and notifies finance personnel to handle them promptly.

[0103] (7) End-to-end audit log module

[0104] This module communicates with the transaction processing module to fully record the entire process of each transaction, including status change records for four nodes, operator information, operation trigger time, operation execution result, request and response messages, anomaly handling records, and reconciliation operation records. It simultaneously ensures the hospital's financial security, prevents shortfalls, and forms a complete technical system of "multi-channel access - multi-node linkage - timely anomaly handling - intelligent reconciliation closed loop." It also includes a built-in audit log module, fully meeting the requirements of the "Financial System for Medical and Health Institutions" and Level 3 Cybersecurity Protection for operational traceability, data security, and compliance auditing. Furthermore, it provides complete evidentiary support for transaction dispute tracing, financial verification, and regulatory auditing.

[0105] (8) Visual management terminal module

[0106] This module communicates with the transaction processing module and the dynamic reconciliation matrix module, providing a web-based visual operation interface with a B / S architecture for hospital finance, operations, and management personnel, supporting three-level hierarchical permission management. Its core functions include: querying, filtering, verifying, and one-click handling of abnormal orders; filtering by multiple dimensions such as time range, payment channel, business type, and anomaly type; querying, exporting, and printing reconciliation reports; full-chain traceability query of audit logs; and visual configuration management of system parameters, polling cycles, and rule bases, achieving full-process visual control of reconciliation operations.

[0107] Based on the above system, the present invention also provides a medical payment reconciliation method based on a four-node closed loop, such as... Figure 7 and Figure 8 As shown, the core includes the following steps:

[0108] S1: Standardized Access

[0109] By integrating the interface protocols of various financial payment channels through a unified access module, it provides standardized four-node interfaces for payment, delivery notification, return notification, and refund. It receives initial business requests initiated by external access channels and obtains the business requests by integrating the interface protocols through the unified access module.

[0110] S2: Transaction Initialization

[0111] Based on the business request, the transaction processing module verifies the validity of the business request, generates a transaction record bound with a globally unique transaction serial number, and completes the transaction initialization; then, it initiates a payment or refund request to the payment channel based on the transaction record.

[0112] S3: Four-Node State Machine Management and Full-Link Snapshot Generation

[0113] Based on a pre-defined four-node state machine model, the system manages the state transitions of the four nodes—payment, delivery, return, and refund—throughout the entire process and intercepts illegal state transition requests. Each node's state change generates an immutable state snapshot bound to the transaction serial number. The state comparison engine performs millisecond-level consistency checks on the four-node states and marks state deviations in real time.

[0114] S4: Active and Passive Dual-Mode State Synchronization

[0115] It adopts a dual-mode mechanism combining passive callback and active polling to synchronize the payment status and refund status of financial merchants in real time, as well as the delivery status and return status of the hospital's HIS system, and update the status snapshots of the four nodes simultaneously; in the scenario where financial merchants have not issued bills on the same day, it automatically generates a list of suspected delivery anomalies and a list of returns pending refunds.

[0116] S5: Real-time identification and closed-loop processing of abnormal orders within the same day

[0117] The abnormal order list is displayed in real time through a visual management interface, which supports manual review by finance personnel. During the daily reconciliation window, the original payment method is automatically triggered for confirmed one-sided order and compliant refund order, so as to achieve same-day closed-loop for abnormal orders.

[0118] S6: Full Intelligent Reconciliation the Next Day

[0119] During the reconciliation window the following day, the intelligent reconciliation engine, based on eight core reconciliation data sources and time nodes, performs full reconciliation through a multi-source data cross-comparison model. It automatically filters out normal bills that can be balanced, accurately identifies reconciliation anomalies, generates a reconciliation anomaly list, and outputs reconciliation conclusions and standardized handling suggestions for each anomaly order, thus completing full account reconciliation.

[0120] S7: End-to-End Audit Recording and Compliance Control

[0121] Throughout the entire transaction process, the full-link audit log module encrypts and stores all transaction operations, status changes, anomaly handling, and reconciliation operations, achieving tamper-proof full-process traceability and meeting the financial compliance and Level 3 information security protection requirements of the medical industry.

[0122] To make the objectives, technical solutions, and advantages of this invention clearer, the following describes the invention in further detail with reference to the specific business scenarios of hospital outpatient payment and refund. The specific embodiments described herein are only used to explain the invention and are not intended to limit the invention.

[0123] The multi-node payment reconciliation system provided in this embodiment is deployed on the hospital's intranet server and is integrated with the hospital's HIS system, WeChat Pay / Alipay payment channels, in-hospital self-service terminals, outpatient manual window cashier system, and the hospital's WeChat official account mobile medical platform to achieve four-node closed-loop reconciliation management of the hospital's outpatient payment business across all scenarios.

[0124] Example 1: Implementation of the Forward Transaction (Outpatient Payment) Process

[0125] Patients select outpatient payment services at the hospital's self-service terminal. The self-service terminal retrieves and displays the patient's prescription information from the HIS system. After confirming the payment amount, the patient initiates a payment request to the unified access module of the hospital's payment reconciliation system by scanning a QR code.

[0126] The unified access module performs SM4 signature verification, message format verification, and authorization authentication on the payment request before forwarding it to the transaction processing module. The transaction processing module verifies the validity of the request, generates a 21-digit globally unique transaction serial number (encoding rule: G + 8-digit date + 12-digit serial number), creates a transaction record, marks the status as "pending payment," and forwards the payment request to the WeChat Pay channel.

[0127] After the WeChat Pay channel completes the payment for the patient, it returns a payment success result to the transaction processing module. The transaction processing module updates the transaction status to "payment successful", writes a payment node status snapshot to the four-node status management module, and returns a payment success result to the self-service terminal.

[0128] After receiving the payment success notification, the self-service terminal sends a delivery request to the hospital's HIS system, requesting that the payment be processed and the medication be dispensed.

[0129] After the hospital's HIS system completes the prescription accounting (delivery), it returns a delivery success result to the self-service terminal and simultaneously pushes the delivery success status to the two-way status synchronization module through the passive callback mode.

[0130] The two-way status synchronization module synchronizes the successful delivery status to the four-node status management module, generating a snapshot of the delivery node status. The status comparison engine performs consistency verification on the payment and delivery node status. After the verification passes, the transaction status is updated to "successful delivery", the positive transaction is completed, and the self-service terminal displays the payment success certificate and medication receipt to the patient.

[0131] Example 2: Implementation of Reverse Transaction (Prescription Refund) Process

[0132] When a patient cancels a prescription and initiates a refund request at the manual counter, the counter's cashier system retrieves and displays the refundable prescription order from the HIS system. After the patient confirms the refund, the cashier system sends a return request to the HIS system.

[0133] The hospital's HIS system processes prescription returns (e.g., patients return medication, patients cancel examinations), and upon completion, returns a successful return result to the window cashier system. At the same time, through a passive callback mode, it pushes the successful return status to the two-way status synchronization module.

[0134] The two-way status synchronization module synchronizes the successful return status to the four-node status management module, generating a snapshot of the return node status; the status comparison engine verifies the legality of the return node status, and after the verification is successful, the window cashier system initiates a refund request to the unified access module of the hospital's payment reconciliation system.

[0135] After verifying the refund request, the unified access module forwards it to the transaction processing module. The transaction processing module retrieves the original transaction record based on the transaction serial number, verifies the legality of the refund, and then forwards the refund request to the WeChat Pay channel. At the same time, the transaction status is updated to "pending refund".

[0136] After WeChat Pay completes the refund to the original payment method, it returns a successful refund result to the transaction processing module. The transaction processing module updates the transaction status to "refund successful" and simultaneously writes a snapshot of the refund node status to the four-node status management module. At the same time, it returns a successful refund result to the window cashier system.

[0137] The window cashier system displays a notification to the patient that the return and refund were successful, and the reverse transaction is completed.

[0138] Example 3: Implementation of the Daily Exception Handling Process

[0139] The bidirectional status synchronization module obtains the four-node status of all transactions in real time through active polling and passive callback. For forward transactions, if a delivery success notification is not received within 10 minutes after successful payment, the status comparison engine marks it as a suspected delivery anomaly and automatically adds it to the suspected delivery anomaly list. For reverse transactions, if a refund success notification is not received within 10 minutes after successful return, it is marked as a return refund anomaly and automatically added to the return pending refund list.

[0140] The daily order query window is from 08:00 to 18:00. The system will push two lists of abnormal orders to the web-based visual management terminal. Finance personnel can log in to view the details of abnormal orders and check them one by one.

[0141] For orders suspected of delivery issues, finance staff can automatically check the prescription delivery status in the HIS system by clicking the processing button on the web interface. If the HIS system confirms that the delivery failed and the patient did not pick up the medication and receive medical services, the system will automatically trigger a refund to the original payment method, completing the order loop and preventing the hospital from experiencing a cash shortage. If the verification confirms that the delivery was successful, the order will be manually marked as a normal order and the status snapshot will be updated.

[0142] For orders in the return pending refund list, finance staff can automatically check the compliance of the return by clicking the processing button on the web interface. If the return is confirmed to be successful and meets the refund rules, the system will automatically trigger a refund retry operation to complete the refund for the patient. If the return is confirmed to be unsuccessful after verification, it will be manually marked as a normal order and the status snapshot will be updated.

[0143] All abnormal order processing operations are synchronously written to the end-to-end audit log module, retaining tamper-proof operation credentials.

[0144] Example 4: Implementation of the next-day intelligent reconciliation process

[0145] The next day's bill is usually retrieved at 10:00 AM. The intelligent reconciliation engine automatically starts a full reconciliation task, obtaining the positive and negative transaction bills from the WeChat Pay channel of the previous day, the positive and negative transaction bills from the HIS system, and simultaneously retrieving the status snapshots of the four nodes of payment, delivery, return, and refund stored in the system, for a total of 8 core reconciliation data sources.

[0146] The intelligent reconciliation engine uses globally unique transaction serial numbers as indexes to perform cross-referencing of multi-source data, automatically filtering out reconcilable invoices where the four nodes are consistent and the merchant's invoice and the business invoice's amount and number of transactions are completely matched. It then provides specific reconciliation conclusions by combining time points.

[0147] For orders that cannot be matched, accurately identify the type of anomaly and generate a reconciliation anomaly list. At the same time, for each abnormal order, automatically output reconciliation conclusions and handling suggestions based on the deviation type, such as "The order was successfully paid, but the delivery failed in the HIS system. It is a one-sided account. The refund has been completed on the same day and the accounts have been balanced" or "The order was successfully returned in the HIS system, but the refund failed in the payment channel. A new refund application needs to be initiated."

[0148] After reconciliation is completed, the system automatically generates the previous day's total reconciliation report, channel-specific reconciliation reports, and abnormal order statistics reports, and pushes them to the web-based visual management terminal, supporting finance personnel to query, export, and print them.

[0149] Based on the list of reconciliation anomalies and the proposed solutions, finance staff completed the processing of the remaining abnormal orders. All processing operations were recorded in audit logs, achieving a closed-loop accounting system for the entire month.

[0150] The technical solution of the present invention has the following characteristics:

[0151] (1) Closed-loop management of the entire process nodes: The complex medical business handling process is abstracted and solidified into four standardized nodes: "payment, delivery, return, and refund". The four nodes are incorporated into a unified management framework, realizing the business rule of "delivery after payment and refund after return", which fundamentally solves the problem of "disconnect between business process and financial reconciliation" in the existing system. The system monitors the four key nodes in all aspects and can grasp the status information of each link in real time.

[0152] (2) Timely identification of anomalies on the same day: By promptly identifying anomalies such as successful payment but unsuccessful delivery, and successful return but unsuccessful refund, and forming a corresponding anomaly list, it is easy for relevant hospital personnel to quickly verify and handle the situation. It is especially suitable for the hospital finance department to quickly respond to refunds on the same day, effectively preventing financial risks and doctor-patient conflicts caused by node anomalies, and ensuring the safety and stability of hospital fund flow.

[0153] (3) Dynamic reconciliation matrix calculation engine improves reconciliation efficiency and accuracy. This engine analyzes reconciliation based on multi-dimensional data, automatically filters out adjustable bills, accurately locates truly problematic bills, and provides detailed reconciliation conclusions. This innovative design greatly reduces the workload of manual reconciliation for financial staff, avoids errors caused by human factors, significantly improves reconciliation efficiency and accuracy, enables hospital financial staff to manage funds more efficiently, and provides timely and accurate financial data support for hospital decision-making.

[0154] Based on the above-described preferred embodiments of the present invention, and through the foregoing description, those skilled in the art can make various changes and modifications without departing from the scope of the present invention. The technical scope of this invention is not limited to the contents of the specification, but must be determined according to the scope of the claims.

Claims

1. A medical payment reconciliation system and method based on a four-node closed loop, characterized in that: It includes a unified access module, a transaction processing module, a four-node status management module, a two-way status synchronization module, an anomaly monitoring and handling module, a dynamic reconciliation matrix module, a full-link audit log module, and a visual management terminal module. The unified access module communicates with the transaction processing module and is used to integrate the interface protocols of multiple financial merchant payment channels. It formulates standardized access specifications, provides a unified standardized interface to connect with various external access entities, receives initial business requests from various external access entities, obtains verified business requests by calling the compliance database, and sends the verified business requests to the transaction processing module. The transaction processing module communicates with the unified access module, the four-node status management module, the end-to-end audit log module, and the visualization management module. It receives business requests from the unified access module, generates a globally unique transaction serial number for each request, and ultimately initiates payment and refund requests to the payment channel. It also binds and stores the transaction serial number with the transaction information, forming a transaction record with a unique end-to-end transaction index. Simultaneously, it generates audit logs and pushes them to the end-to-end audit log module. Finally, it acquires transaction data from the visualization management module and provides data display to it. The four-node status management module communicates with the transaction processing module, the two-way status synchronization module, the anomaly monitoring and handling module, and the dynamic reconciliation matrix module. This module incorporates state machine models for four core nodes: payment, delivery, return, and refund. It constructs a four-state snapshot mechanism covering the entire chain, using the transaction serial number generated by the transaction processing module as an index to generate standardized four-state snapshots for each transaction, forming transaction status information. Simultaneously, it has a built-in status comparison engine that performs consistency checks on the status data of the four nodes in the real-time transaction flow received from the two-way status synchronization module based on a preset rule base, marks status deviations, and sends the verification results to the anomaly monitoring and handling module. Furthermore, it provides the four-node status data to the dynamic reconciliation matrix module during the next day's reconciliation. The two-way status synchronization module communicates with the four-node status management module, the payment channel, and the hospital's HIS system respectively. It has a built-in dual-mode mechanism that combines passive callback mode and active polling mode. It is used to collect the real-time transaction flow of the payment channel and the hospital's HIS system, send the real-time transaction flow to the four-node status management module to update the four-state snapshot, assist in generating a list of abnormal orders at each stage, and realize the real-time synchronization of the four-node status. The anomaly monitoring and processing module communicates with the four-node status management module to receive the verification results from the four-node status management module, query transaction records based on the verification results, and generate a list of suspected delivery anomalies based on the transaction records, so as to realize the real-time identification and closed-loop handling of abnormal orders on the same day. The dynamic reconciliation matrix module communicates with the four-node status management module, the visualization management module, the payment channel, and the hospital's HIS system. It is used to collect bills from the payment channel and the hospital's HIS system. It has a built-in multi-source data cross-comparison model. Based on multiple key data of the bills stored in the reconciliation system, it performs full intelligent reconciliation of the multi-source reconciliation data sources the next day, automatically filters out normal bills, accurately identifies abnormal reconciliation orders with time nodes, and generates a list of abnormal reconciliations and corresponding reconciliation conclusions based on the bill status, time nodes, and four-node status. The results are displayed through the visualization management module as a basis for hospital financial staff to take action. The end-to-end audit log module communicates with the transaction processing module to receive audit logs from the transaction processing module, real-time transaction records, and transaction status information, ensuring that the system meets the hospital's security management requirements. The visualization management module communicates with the transaction processing module and the dynamic reconciliation matrix module, respectively, and is used to display the queried transaction information and billing information in a visual way.

2. The medical payment reconciliation system based on a four-node closed loop as described in claim 1, characterized in that: The transaction processing module performs transaction management on cross-system transaction operations based on the TCC distributed transaction protocol.

3. The medical payment reconciliation system based on a four-node closed loop as described in claim 1, characterized in that: The state machine model built into the four-node state management module presets legal state transition paths, including a forward transaction path of "pending payment → payment successful → pending delivery → delivery successful" and a reverse transaction path of "pending return → return successful → pending refund → refund successful". It intercepts illegal state transition requests and enforces the business rule of "payment before delivery and return before refund". In the four-state snapshot mechanism, the state change of each node is bound to a unique transaction serial number, operation timestamp, system source identifier, operator signature and channel response code to generate an immutable state snapshot.

4. The medical payment reconciliation system based on a four-node closed loop as described in claim 1, characterized in that: The passive callback mode opens a dedicated encrypted callback interface, which uses the dedicated encrypted callback interface of the unified access module to receive payment status and refund status change notifications actively pushed by the payment channel, as well as delivery status and return status change notifications actively pushed by the hospital's HIS system. After receiving the callback, the corresponding status snapshot in the four-node status management module is updated in real time. The proactive polling mode initiates order status query requests to the payment channel according to a preset configurable polling cycle to obtain the actual payment status and refund status of each transaction, and initiates business status query requests to the hospital's HIS system to obtain the actual delivery status and return status of each transaction; for timed-out orders whose status is not synchronized, the polling frequency is automatically increased; in scenarios where financial merchants have not issued bills on the same day, a list of suspected delivery anomalies and a list of returns pending refunds are automatically generated.

5. The medical payment reconciliation system based on a four-node closed loop as described in claim 1, characterized in that: The anomaly monitoring and handling module includes a delivery anomaly handling unit and a return and refund anomaly handling unit, wherein... The delivery anomaly handling unit, based on the verification results of the four-node status management module, filters out orders that are "paid successfully but delivery failed" in real time and automatically generates a list of suspected delivery anomalies. The list is displayed in real time through the visualization management module, supporting financial personnel to perform order verification, re-delivery triggering, and single-sided account confirmation operations. During the daily reconciliation window, if an order is confirmed to be a single-sided account with successful payment but failed delivery, the transaction processing module is automatically triggered to perform a refund operation on the original payment method, completing the order loop. The return and refund exception handling unit, based on the verification results of the four-node status management module, filters out orders that are "successfully returned but not successfully refunded" in real time and automatically generates a list of returns pending refunds. This list is displayed in real time through the visual management module, supporting staff to perform return compliance checks and trigger refund retry operations. Within the order query window of the day, if the order is confirmed to meet the refund rules, the transaction processing module is automatically triggered to execute the original payment method refund operation.

6. The medical payment reconciliation system based on a four-node closed loop as described in claim 1, characterized in that: The key data from the reconciliation data source includes eight items: payment status snapshot, delivery status snapshot, return status snapshot, refund status snapshot, positive transaction bill from the merchant side, negative transaction bill from the merchant side, positive transaction bill from the business side, and negative transaction bill from the business side. The multi-source data cross-comparison model uses a globally unique transaction serial number as an index to automatically filter out normal bills that can be balanced. Combined with time nodes, it accurately identifies abnormal reconciliation orders and outputs reconciliation conclusions and standardized handling suggestions for each abnormal order.

7. A medical payment reconciliation method based on a four-node closed loop, characterized in that: The medical payment reconciliation system based on a four-node closed loop, as described in any one of claims 1-6, further includes the following steps: S1: Based on the initial business request initiated by the received external access channel, the interface protocol is integrated through the unified access module to obtain the business request; S2: Based on the business request, the transaction processing module performs legality verification and generates a transaction record with a globally unique transaction serial number bound to the business request, thus completing the transaction initialization; and initiates a payment or refund request to the payment channel according to the transaction record. S3: Based on a preset four-node state machine model, it manages the state transitions of the four nodes—payment, delivery, return, and refund—throughout the entire process and intercepts illegal state transition requests. Each node's state change generates an immutable state snapshot bound to the transaction serial number. The state comparison engine performs millisecond-level consistency checks on the four-node states and marks state deviations in real time. S4: It adopts a dual-mode mechanism that combines passive callback and active polling to synchronize the payment status and refund status of the financial merchant side and the delivery status and return status of the hospital's HIS system in real time, and update the status snapshot of the four nodes simultaneously; in the scenario where the financial merchant has not issued a bill on the same day, it automatically generates a list of suspected delivery anomalies and a list of returns pending refund. S5: The abnormal order list is displayed in real time through a visual management terminal, which supports manual review by finance personnel; during the daily reconciliation window, the original payment method or refund operation is automatically triggered for confirmed one-sided order and compliant refund order, so as to achieve the same-day closed loop for abnormal orders; S6: During the next day's reconciliation window, the intelligent reconciliation engine of the dynamic reconciliation matrix module, based on the core reconciliation data source and time nodes, performs full reconciliation through a multi-source data cross-comparison model, automatically filters out normal bills that can be balanced, accurately identifies reconciliation abnormal orders, generates a reconciliation abnormality list, and outputs reconciliation conclusions and standardized handling suggestions for each abnormal order, thus completing full account reconciliation. S7: Throughout the entire transaction process, the full-link audit log module encrypts and records all transaction operations, status changes, anomaly handling, and reconciliation operations, achieving tamper-proof full-process traceability and meeting the financial compliance and Level 3 information security protection requirements of the medical industry.

8. The medical payment reconciliation method based on a four-node closed loop as described in claim 7, characterized in that: The business request is a payment request. When the unified access module receives the payment request, the transaction processing module sends the payment request to the payment channel. After receiving the payment success result information from the payment channel, the module sends the delivery result verification request to the hospital's HIS system within a specified time. In response to the successful delivery result issued by the hospital's HIS system, the two-way status synchronization module uploads the current transaction flow status to the four-node status management module.

9. The medical payment reconciliation method based on a four-node closed loop as described in claim 7, characterized in that: The business request is a refund request. When the unified access module receives the refund request, the transaction processing module will eventually send a return result verification request to the hospital's HIS service. After receiving the return success result information from the hospital's HIS service, the module will forward the refund request to the payment channel. In response to the payment channel issuing a successful refund result, the transaction processing module will synchronize the current transaction flow status from the four-node status management module.

10. A computer-readable storage medium, characterized in that, The computer program readable storage medium has a computer program / instructions embodied thereon, which can be executed by one or more processors, and when executed by the processors, the computer program / instructions implement the steps of the medical payment reconciliation method based on a four-node closed loop as described in any one of claims 7 to 9.

Images