A payment network-based product recommendation method and related devices

Abstract

This application discloses a product recommendation method and related equipment based on a payment network, belonging to the field of artificial intelligence technology, and applied to medical insurance claims. At the data level, patient medical data from different systems are first formatted and mapped to form unified medical data. Then, claims rules matching the unified medical data are extracted from a pre-set insurance claims database, and combined with insurance eligibility determination logic, the system automatically generates insurance verification results. Based on the verification results and rules, the system allocates insurance payment amounts, extracts premium allocation ratios, and achieves precise and transparent sharing of funds among the insurance company, medical insurance account, and patient co-payment. Simultaneously, the system obtains medical records from the hospital information system and generates reimbursement vouchers based on the allocation ratios. This application significantly improves the level of claims automation, settlement accuracy, reconciliation efficiency, and overall operational efficiency.

Description

Technical Field

[0001] This application belongs to the field of artificial intelligence technology, specifically relating to a product recommendation method based on a payment network and related equipment. Background Technology

[0002] The healthcare sector plays a crucial role in improving patient experience and optimizing insurance claims efficiency, particularly in the rapid payment and convenient services of commercial medical insurance, which directly impact patients' financial burden and access to care. With the development of digital technology, the interactions between medical institutions, insurance companies, and patients are becoming increasingly complex, necessitating an efficient and convenient payment and claims system to address diverse healthcare scenarios. However, current solutions still have significant shortcomings in technology integration and business process optimization, failing to meet the demands for real-time, convenient, and multi-scenario adaptability.

[0003] Existing solutions rely on traditional manual claims processes, requiring patients to submit cumbersome paper documents or complete reimbursement through multiple platforms, which is time-consuming and error-prone. Furthermore, existing systems often lack a unified interaction protocol, leading to inefficient data transfer between hospitals, payment platforms, and insurance companies, hindering real-time verification and rapid payouts. These issues not only increase patients' time costs but also limit the widespread adoption and application of commercial insurance in healthcare settings.

[0004] First, medical data involves complex interactions between hospital information systems, payment terminals, and insurance platforms. Inconsistent data formats and fields make system integration difficult. For example, hospital records may not directly match insurance company claims rules, leading to data processing delays or errors. Second, this poor data interaction directly impacts the implementation of real-time reimbursement mechanisms. Real-time reimbursement requires the system to instantly verify insurance eligibility and allocate costs upon patient payment, but current technology struggles to respond quickly across multiple scenarios. For instance, when patients use a combination of their medical insurance personal account and commercial insurance for payment at the hospital, the system cannot quickly distinguish the payment source and simultaneously complete the claim, resulting in delays in fund arrival.

[0005] Therefore, how to achieve immediate direct reimbursement and rapid payment from commercial insurance after patients have paid in full in cash, through a unified interactive protocol and real-time reimbursement mechanism, has become a key issue that urgently needs to be addressed in the field of medical payment and insurance claims. Summary of the Invention

[0006] The purpose of this application is to propose a product recommendation method, device, computer equipment, and storage medium based on a payment network, in order to solve the key problem that urgently needs to be solved in the field of medical payment and insurance claims: how to achieve immediate direct payment and rapid crediting of commercial insurance after the patient has paid the full amount in cash, through a unified interaction protocol and real-time verification mechanism.

[0007] To address the aforementioned technical problems, this application provides a product recommendation method based on a payment network, employing the following technical solution: A product recommendation method based on a payment network includes: Patient medical data is collected from multiple medical databases, and data mapping algorithms are used to process the differences in data formats between different systems to obtain unified medical data; For unified medical data, appropriate product rules are obtained from a pre-set product database, and the validity of product qualifications is determined based on unified medical data and product rules to obtain product verification results; Obtain the product verification results and matching payment amount, and allocate fees based on the payment amount according to the product rules to determine the product allocation ratio; Retrieve medical record data from the hospital information system, and generate reimbursement vouchers based on the medical record data and product allocation ratio; The system sends a payment instruction to the payment platform based on the verification voucher. If the payment instruction is confirmed to be correct, the fund transfer is triggered, and a fund arrival instruction is received. The system updates the patient's account status based on the fund arrival instruction and generates and pushes payment detail reports.

[0008] To address the aforementioned technical problems, this application also provides a product recommendation device based on a payment network, employing the following technical solution: A product recommendation device based on a payment network includes: The data acquisition module is used to collect patient medical data from multi-source medical databases and to use data mapping algorithms to process the differences in data formats between different systems to obtain unified medical data. The rule verification module is used to retrieve the appropriate product rules from the preset product database for unified medical data, and to determine the validity of product qualification based on the unified medical data and product rules, so as to obtain the product verification result. The fee allocation module is used to obtain the payment amount that matches the product verification results, and allocate the fee according to the product rules to determine the product allocation ratio. The voucher generation module is used to obtain medical record data from the hospital information system and generate reimbursement vouchers based on the medical record data and product allocation ratio; The payment processing module is used to send payment instructions to the payment platform based on the verification voucher. If the payment instructions are confirmed to be correct, the fund transfer is triggered and a fund arrival instruction is received. The report push module is used to update the patient's account status upon receipt of funds and to generate and push payment detail reports.

[0009] To address the aforementioned technical problems, this application also provides a computer device that employs the following technical solution: A computer device includes a memory and a processor, the memory storing computer-readable instructions, the processor executing the computer-readable instructions to implement the steps of the product recommendation method based on a payment network as described in any of the preceding claims.

[0010] To address the aforementioned technical problems, this application also provides a computer-readable storage medium, employing the technical solution described below: A computer-readable storage medium storing computer-readable instructions that, when executed by a processor, implement the steps of the product recommendation method based on a payment network as described above.

[0011] Compared with the prior art, the embodiments of this application have the following main advantages: This application discloses a product recommendation method and related equipment based on a payment network, belonging to the field of artificial intelligence technology, and applied to medical insurance claims. At the data level, patient medical data from different systems is first formatted and mapped to form unified medical data. Then, product rules matching the unified medical data are extracted from a pre-set product database, and combined with eligibility determination logic, the system automatically generates product verification results. Based on the verification results and rules, the system allocates product payment amounts, extracts payment allocation ratios, and achieves precise and transparent allocation of funds among insurance companies, medical insurance accounts, and patient co-payments. Simultaneously, the system obtains medical records from the hospital information system and generates reimbursement vouchers based on the allocation ratios. By sending a direct payment instruction to the payment platform and triggering fund transfer upon instruction confirmation, and updating the patient's account status through fund arrival instructions, a claim details report is generated and pushed. The entire process of this application supports audit tracking, anomaly alerts, and log retention, and has good scalability to adapt to changes in regional policies, institution types, and payment models, significantly improving the level of claims automation, settlement accuracy, reconciliation efficiency, and overall operational efficiency. Attached Figure Description

[0012] To more clearly illustrate the solutions in this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 An exemplary system architecture diagram is shown, in which this application can be applied; Figure 2A flowchart is shown as an embodiment of a product recommendation method based on a payment network according to this application; Figure 3 It shows Figure 2 A flowchart of one embodiment of step S202; Figure 4 A schematic diagram of the structure of an embodiment of a product recommendation device based on a payment network according to this application is shown; Figure 5 It shows Figure 4 A schematic diagram of the structure of an embodiment of the rule verification module 402; Figure 6 A schematic diagram of the structure of one embodiment of a computer device according to this application is shown. Detailed Implementation

[0014] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0015] 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 separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0016] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0017] like Figure 1 As shown, system architecture 100 may include terminal device 101, network 102, and server 103. Terminal device 101 may be a laptop 1011, tablet 1012, or mobile phone 1013. Network 102 is used as a medium to provide a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables.

[0018] Users can use terminal device 101 to interact with server 103 via network 102 to receive or send messages, etc. Various communication client applications can be installed on terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0019] Terminal device 101 can be various electronic devices with a display screen and support web browsing. In addition to laptops 1011, tablets 1012, or mobile phones 1013, terminal device 101 can also be e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, and desktop computers.

[0020] Server 103 can be a server that provides various services, such as a backend server that provides support for the pages displayed on terminal device 101.

[0021] It should be noted that the product recommendation method based on the payment network provided in this application embodiment is generally executed by a server / terminal device, and correspondingly, the product recommendation device based on the payment network is generally set in the server / terminal device.

[0022] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative; the system can have any number of terminal devices, networks, and servers depending on implementation needs.

[0023] Continue to refer to Figure 2 The diagram illustrates a flowchart of an embodiment of a product recommendation method based on a payment network according to this application. The product recommendation method based on a payment network includes the following steps: S201: Collect patient medical data from multi-source medical databases and use data mapping algorithms to process data format differences between different systems to obtain unified medical data; Specifically, the system establishes data acquisition channels with multiple medical data sources, including Hospital Information System (HIS), Electronic Medical Record System (EMR), Laboratory Information System (LIS), and Pharmaceutical Supply Chain System (PIS). The system first parses the interface protocols of each data source and uses pre-defined data acquisition adapters to obtain raw data such as patient basic information, medical records, prescription information, laboratory reports, and cost details. Due to differences in data standards and field definitions across different systems, this method employs a rule-based template-based data mapping algorithm for format processing. This algorithm establishes a field mapping relationship table to match and transform the semantics of data fields from different systems, and combines this with a JSON Schema template to achieve cross-system data structure unification. During the mapping process, a dynamic data type identification mechanism is used to normalize the format and verify the value range of key fields such as timestamps, amounts, and code sets, ensuring data integrity and consistency. The final output of unified medical data is stored in the form of structured JSON objects for use in the claims rule matching and eligibility verification process.

[0024] S202, for unified medical data, retrieve the appropriate product rules from the preset product database, and determine the validity of the product qualification based on the unified medical data and product rules to obtain the product verification result; Specifically, taking insurance products as an example, the product database is an insurance claims database, the product rules are the rules corresponding to the insurance products, and the insurance verification result is achieved by calling the insurance claims rule engine module. First, based on the patient's identity, enterprise affiliation information, and treatment type contained in the unified medical data, the system extracts the corresponding insurance product rule set from the insurance claims database. This database stores claims rules hierarchically according to insurance type, policy version, regional policies, and enterprise-customized parameters. Then, the rule engine parses the structured definition of each rule, including the scope of compensation, item restrictions, deductible, capped amount, and proportional parameters. The system matches elements such as treatment item codes, medical institution levels, and cost categories in the unified medical data with the rule conditions item by item, using a Boolean logic calculation engine to perform multi-condition judgments. If some items do not meet the compensation conditions, the system automatically identifies and records the reason for the claim rejection. After matching is complete, an insurance verification result file is generated, including item-level compensation validity, rule matching status, and information on the total reimbursable amount range.

[0025] S203, obtain the payment amount that matches the product verification results, and allocate the payment amount according to the product rules to determine the product allocation ratio; Specifically, the product allocation ratio is based on the insurance verification results. First, based on the list of items marked as "valid claims" in the insurance verification results, the corresponding cost details and payment amounts are extracted. The system then calls the claims algorithm module from the insurance claims rules set to automatically calculate the claim amount for each item. This algorithm comprehensively considers parameters such as deductibles, reimbursement ratios, caps, and differentiated corporate policies. After calculation, the system categorizes all cost items, separately calculating the portion covered by commercial insurance, the portion paid by the medical insurance personal account, and the portion paid by the patient. Subsequently, the cost allocation engine performs proportional analysis on different payment sources, using a weighted calculation model to determine the total premium allocation ratio, where the weighting factor can be dynamically adjusted based on risk level, policy type, and historical claims ratio. Finally, a standardized structured cost allocation table is generated, containing item classifications, allocation ratios, corresponding amounts, and funding sources.

[0026] S204: Obtain medical record data from the hospital information system and generate a reimbursement voucher based on the medical record data and product allocation ratio; Specifically, this is accomplished by the data interaction interface module. The system accesses patient medical records in real time through the hospital information system's API interface, including registration information, treatment department, visit number, medication list, billing details, and medical insurance settlement transaction number. The acquired data first undergoes structured parsing and standardization, mapping its fields to corresponding fields in the unified medical data. Then, the system calculates the one-to-one correspondence between the expense items and the determined premium allocation ratio, generating a detailed settlement item containing the commercial insurance payment amount, the medical insurance account payment amount, and the patient's co-payment amount. Next, an electronic reimbursement voucher is constructed based on this detail. The voucher includes the visit number, payment path, allocation ratio, rule number, and timestamp information. To ensure data security and traceability, a digital signature and encryption identifier are attached when the voucher is generated. Finally, the reimbursement voucher is stored in the payment network in JSON format, used to trigger the payment platform's direct payment instruction, achieving automated fund settlement and reconciliation.

[0027] S205: Send a payment instruction to the payment platform based on the verification voucher. If the payment instruction is confirmed to be correct, the fund transfer is triggered and a fund arrival instruction is received. Specifically, this process is executed by the payment network interaction module. The system first reads the signed and verified reimbursement voucher data and performs consistency checks on the voucher number, payment amount, insurance institution account information, and transaction time. Upon successful verification, the system generates a direct claim instruction package conforming to the payment platform's interface specifications. This package includes fields for transaction ID, source account, target account, amount, and transaction purpose. The instruction is encrypted and transmitted to the third-party payment channel, where the payment platform performs security authentication and risk control review. After confirming the instruction's validity, the payment platform returns a direct claim confirmation response. Upon receiving the confirmation result, the system automatically triggers the fund transfer process, completing the transfer of funds from the insurance institution's account to the hospital's or patient's account through the payment clearing channel. Simultaneously, a fund arrival instruction file is generated, containing the fund transfer path, arrival time, transaction serial number, and fund status information, used for account updates and claims report generation.

[0028] S206 updates the patient's account status via fund arrival instructions and generates and pushes payment details reports.

[0029] Specifically, the system primarily handles account settlement and report generation. Upon receiving a fund arrival instruction, the system first parses the transaction status and updates the patient's account balance and payment status identifier in the medical payment network accordingly. If the arrival status is successful, the corresponding insurance payment record is written to the patient's account transaction log, and the settlement status is updated to "Paid." Next, the system calls the report generation engine to generate a detailed compensation report based on the reimbursement voucher, insurance rules, and arrival record data. The report includes structured content such as visit information, item classification, compensation amount, insurance rule number, and transaction serial number. To ensure information security, the generated report undergoes digital signature and encryption processing and is pushed to the patient and insurance institution via the Good Doctor APP or enterprise integration system. If the fund status is abnormal, the system will automatically trigger the anomaly handling module for secondary reconciliation and risk identification, ensuring the accuracy and closed-loop management of compensation records.

[0030] Example 1: Automated reconciliation of the hospital's three-tiered medical process; Scenario: A hospital generates a patient record by completing diagnosis, medication, and examinations in the outpatient and emergency departments. The system retrieves the patient data through the HIS interface and associates each treatment item with a pre-set premium allocation ratio.

[0031] The system displays that drug costs, consultation fees, and examination fees are respectively mapped to three parts: insurance company payments, medical insurance account payments, and patient out-of-pocket payments. The generated itemized settlement details include consultation codes, drug codes, payment serial numbers, and allocation coefficients, ultimately forming an electronic reimbursement voucher data package, facilitating end-of-day reconciliation, inter-hospital reconciliation, and insurance claim review.

[0032] Example 2: Cross-institutional collaborative settlement and audit traceability; Scenario: A patient visits two hospitals in the cooperative network. The first hospital completes the settlement and generates an electronic reimbursement voucher. The second hospital needs to reconcile and verify the previous record during the settlement process.

[0033] The system enables cross-hospital traceability through a unique credential number. The credential data package contains metadata such as the patient number, cost category, payment path, and allocation ratio. The second hospital can quickly compare the original payment flow, allocation results, and settlement amount, improving reconciliation efficiency and reducing error rate.

[0034] Example 3: Anomaly detection and automatic error correction; Situation: On a certain day, the out-of-pocket amount of a certain department was significantly higher than the historical distribution. The system detected the anomaly and triggered an alarm.

[0035] Display: The anomaly detection module will trigger an automatic review process. Administrators are requested to check whether the treatment items and allocation coefficients have been updated and whether there are any data mismatches. If an anomaly is confirmed, the system can automatically roll back or recalculate the allocation ratio to ensure fair and compliant settlement.

[0036] Example 4: Compliance Audit and Replay; Situation: Regulatory authorities require an audit of settlement documents for a specific period.

[0037] Display: All electronic reconciliation vouchers and details include metadata such as version number, timestamp, and rule version. Auditors can replay the voucher generation and allocation process along a timeline to quickly locate problems and provide a chain of evidence.

[0038] Example 5: Transparency of the patient experience; Situation: The patient wants to know the breakdown of their medical expenses.

[0039] Presentation: Through publicly available billing details, patients can see the allocation of payments from the insurance company, medical insurance accounts, and out-of-pocket expenses. Each amount can be traced back to specific treatment items and medication details, enhancing transparency and trust.

[0040] Furthermore, the steps of collecting patient medical data from multi-source medical databases and using data mapping algorithms to process data format differences between different systems to obtain unified medical data specifically include: Patient information is extracted from the hospital information system, electronic medical record system, laboratory and examination system, and drug management system. The patient information includes basic information, diagnosis and treatment information, laboratory reports, and cost lists. A data field mapping relationship table is established based on the data source identifier, and the field names, data types and encoding rules of different systems are standardized and preprocessed. The pre-processed multi-source data is formatted and semantically aligned using a preset data mapping algorithm, and unstructured fields are converted into structured JSON format data. Data in a standardized format is aggregated according to a pre-defined medical information model to generate unified medical data that includes patient identity information, treatment behavior, cost details, and payment path.

[0041] In this embodiment, deep fusion of cross-system data is achieved through multi-source medical data acquisition and intelligent mapping algorithms. The system first establishes multi-channel parallel data interfaces for the Hospital Information System (HIS), Electronic Medical Record System (EMR), Laboratory Information System / PACS (LIS / PACS), and Pharmaceutical Information System (PIS), utilizing APIs or message queues to achieve asynchronous data acquisition, ensuring the real-time nature and completeness of data acquisition. After data extraction, the system generates a field mapping table based on the interface protocols and field specifications of each data source. It performs standardized preprocessing on the semantic tags, data types, encoding rules, and timestamps of each field, and uses regular expression matching and fuzzy comparison algorithms to resolve naming conflicts and encoding differences. Next, a preset data mapping algorithm performs format conversion and semantic alignment. Based on a template-driven mechanism, the algorithm uniformly encapsulates structured and semi-structured data into standardized JSON objects. For unstructured text, such as medical records or test results, the system uses a natural language processing model to extract key fields and convert them into computable field nodes. Finally, based on the pre-set medical information model, the processed multidimensional data is aggregated into a unified medical data object, which contains core elements such as patient identity information, treatment behavior, cost details and payment path.

[0042] Through the above steps, a unified and structured integration of heterogeneous medical data was achieved, improving the standardization and interoperability of data processing.

[0043] Further, please refer to Figure 3 The steps involved in obtaining product verification results, specifically, include: retrieving suitable product rules from a pre-defined product database based on unified medical data, and determining the validity of product eligibility based on the unified medical data and product rules. S301, based on the patient's identity, visit type and cost items in the unified medical data, calls the rule index module in the preset product database to retrieve the product rule set corresponding to the patient type; S302, perform rule parsing on the product rule set and extract product rule information; S303 compares unified medical data with product rule information item by item, performs validity matching and verification based on elements such as treatment item code, medical institution level, and cost item, and generates product verification results.

[0044] In this embodiment, a two-way matching mechanism between the insurance claims rule database and unified medical data is established to automate and achieve high-precision processing of insurance eligibility verification. The system first retrieves information from the insurance claims database using the patient's identity, treatment type, company affiliation, and expense item information within the unified medical data. This module employs a hierarchical index structure, using multi-dimensional indexing based on insurance type, policy version, regional policies, company rules, and effective date to ensure a complete match between the retrieved rule set and the patient's corresponding policy. After retrieving the rule set, the system parses its logical structure, using a rule parsing engine to extract parameters such as coverage scope, deductible conditions, reimbursement ratio, maximum payout, and restrictions on specific treatment items, transforming these into computable rule expressions. Next, the system uses the unified medical data as input and performs item-by-item matching and verification against the parsed rules. The matching process is based on a multi-dimensional logical judgment model, encompassing steps such as consistency verification of treatment item codes, verification of medical institution level matching, comparison of expense item classifications, and verification of special item eligibility. When some items do not meet the insurance compensation conditions, the system will automatically mark and record the reason for the abnormality; for items that meet the conditions, a structured insurance verification result file will be output, which includes the item-level matching status, compensation validity and rule number mapping relationship.

[0045] Through the above steps, the automatic matching of insurance claim rules and the accurate verification of insurance eligibility are achieved, significantly improving the automation level of claim review and the accuracy of data matching.

[0046] Furthermore, the step of retrieving the product rule set corresponding to the patient type by calling the rule index module in the preset product database based on the patient's identity identifier, visit type, and cost item in the unified medical data specifically includes: Parse the patient identification field in the unified medical data to obtain the product type code corresponding to the patient; Based on the product type code, locate the corresponding rule index table in the product database, and call the query interface of the rule index module to obtain the primary rule list; The product rules in the primary rule list are filtered in multiple dimensions, based on the type of medical visit, the level of the medical institution, the category of the fee item, and the regional policy parameters. Based on the rule version number and timestamp information, the currently effective product rule set is automatically selected from multiple candidate rules, and the selected product rule set is cached in the local rule mapping table.

[0047] In this embodiment, the step of retrieving the insurance claim rule set corresponding to the patient's insurance type by calling the rule index module in the preset insurance claim database based on the patient's identity identifier, treatment type, and cost items in the unified medical data specifically includes: parsing the patient identity identifier field in the unified medical data to obtain the patient's corresponding insurance type code, enterprise affiliation information, and insurance status; locating the corresponding rule index table in the insurance claim database based on the insurance type code, and calling the query interface of the rule index module to obtain a primary rule list; performing multi-dimensional filtering on the claim rules in the primary rule list, filtering rules according to treatment type, medical institution level, cost item category, and regional policy parameters; and automatically selecting the currently effective insurance claim rule set from multiple candidate rules based on the rule version number and timestamp information, and caching the filtered insurance claim rule set to the local rule mapping table. In this embodiment, by seamlessly connecting the unified medical data and the claim rule database, the steps of patient identity identifier parsing, insurance type location, rule index retrieval, primary rule filtering, regional and institutional dimension condition filtering, and automatic selection of effective rules driven by version control and timestamps are formed into a closed-loop process. This process de-identifies and minimizes the exposure of sensitive fields before the data stream goes live, and achieves low-latency rule retrieval and fast cache updates through distributed caching and local mapping tables, ensuring stable throughput and consistency even under peak patient volume and complex settlement scenarios. Through modular design, the rule index, primary rule set, filtering conditions, and caching mechanism are decoupled, facilitating rapid adaptation to new regional policies, new insurance products, and institutional level adjustments. It also supports playback and audit trails, improving governance compliance capabilities and operational efficiency.

[0048] Through the above steps, the automatic matching of insurance claim rules and the accurate verification of insurance eligibility are achieved, significantly improving the automation level of claim review and the accuracy of data matching.

[0049] Further, the steps of obtaining the product verification results and matching payment amounts, allocating fees based on the payment amounts according to product rules, and determining the product allocation ratio specifically include: Based on the valid payment items that have passed the product verification results, extract the corresponding cost details and payment amounts from the unified medical data. Based on the payment parameters in the product rules, calculate the amount payable for each payment item and generate an initial payment list; The execution costs of each item in the initial payment list are categorized and processed, and the distribution of payment amounts from each payment source is calculated; Based on the distribution of payment amounts, a weighted calculation model is used to determine the proportion of each payment source in the total cost, thus obtaining the product allocation ratio.

[0050] In this embodiment, after obtaining the insurance verification results and confirming valid reimbursement items, the expense details and payment amounts in the unified medical data are matched item by item to ensure that each expense can be traced back to the specific treatment behavior and settlement unit. Next, based on the reimbursement ratio, deductible, capped amount, and item type parameters in the insurance claim rules, a sub-item calculation model is established to calculate the reimbursement amount for each reimbursement item, generating a detailed initial reimbursement list with corresponding calculation basis, rule version, and timestamp information to ensure traceability. Subsequently, the initial reimbursement list undergoes expense classification processing, dividing the payment sources into three parts: insurance company, patient co-payment, and medical insurance account. The amount distribution for each part is calculated separately, handling situations including deductible segmentation, cross-month settlement mechanisms of the pooled account, and multiple apportionments within the same treatment cycle, ensuring the fairness and consistency of the allocation results. Based on the amount distribution results, a dynamic weighted model is used to recalibrate the proportions originating from different payment entities, considering regional policy differences, institution levels, and changes in different medical insurance plans to achieve adaptive adjustment of the premium allocation ratio. Simultaneously, the initial claims list and final premium allocation results are stored in a local cache table and audit log, supporting post-event queries, playback, and compliance audits. This ensures high availability and traceability during policy updates, case reviews, and cross-institutional information sharing. Through modular design, payment amount calculation, expense classification, weighted averages, and caching mechanisms are decoupled, facilitating rapid implementation of new regional medical insurance policies, new claims structures, and rules for different payment entities. The solution will also incorporate anomaly detection and automatic error correction mechanisms to alert and automatically correct abnormal payments, duplicate settlements, or rule conflicts, improving settlement robustness and user experience.

[0051] Through the above steps, the accurate calculation of compensation amounts and the automation of multi-source payment allocation are achieved, significantly improving the accuracy, transparency and efficiency of settlement.

[0052] Furthermore, based on the distribution of payment amounts, a weighted calculation model is used to determine the proportion of each payment source in the total cost, thus obtaining the product allocation ratio. This process specifically includes: Based on the total amount of fees from each payment source in the payment amount distribution, extract the payment amount from each payment source; Set weighting coefficients for each payment source; The weighted summation of the payment amount from each payment source and its corresponding weighting coefficient is performed to calculate the total weighted payment amount. Divide the weighted amount of each payment source by the total weighted payment amount to obtain the weighted percentage of each payment source in the total cost; The weighted percentage is output as the product allocation ratio.

[0053] In this embodiment, after obtaining the amount distribution results and identifying each payment source, a dynamic weighted allocation framework is established, using insurance company payments, medical insurance personal account payments, and patient out-of-pocket payments as the three core components. First, based on the claim levels, risk-bearing ratios, and enterprise policy types in the insurance claims rules, an adaptive weighting coefficient generation strategy is designed, allowing the weights of different sources to adjust with policy and risk changes under different scenarios. Second, considering regional regulatory requirements, differences in institutional levels, and patient group characteristics (such as disease spectrum, treatment intensity, and frequency of visits), scenario grouping logic is introduced. A consistent weighting strategy is applied to similar scenarios within the same time window to reduce volatility and improve predictability. Then, the actual payment amount for each payment source is normalized to ensure that, with the denominator being the total weighted payment amount, the influence of each source matches its economic risk. To ensure transparency and traceability, the weighting coefficients and calculation process are recorded in local audit logs and a versioned rule base, supporting cross-institutional reconciliation and retrospective analysis. Meanwhile, an anomaly detector is designed so that if the amount distribution of a payment source deviates significantly from historical trends, an alarm will be triggered and the weights will be automatically adjusted to avoid user experience degradation and financial risks caused by abnormal settlements. Through modular design, payment amount extraction, weighted coefficient generation, weighted summation, and standardized percentage output are decoupled, facilitating rapid adaptation and verification for new regions, new insurance products, and new corporate policy types.

[0054] Through the above steps, the automated weighting and proportion output of multi-source payment allocation is realized, improving settlement transparency, predictability, and adaptability to policy changes.

[0055] Furthermore, the steps of obtaining medical record data from the hospital information system and generating reimbursement vouchers based on the medical record data and product allocation ratio specifically include: The patient's current medical record data is obtained by calling the interface module of the hospital information system. The patient's current medical record data includes registration information, treatment items, drug costs, settlement information and payment serial number. The system associates and calculates each cost item in the patient's current medical record with the corresponding product allocation ratio to generate a settlement detail. Based on the settlement details, an electronic reimbursement voucher data package is constructed, which includes the patient's visit number, cost category, payment path, and allocation ratio, and a unique voucher number is generated for the electronic reimbursement voucher data package.

[0056] In this embodiment, based on the acquisition of medical record data, premium allocation ratios, and project-based settlement details, the Hospital Information System (HIS) is further deeply integrated with the claims and settlement rule base to form a closed loop for the generation and verification of electronic reimbursement vouchers across the entire chain. First, the medical records obtained through the HIS interface include elements such as registration, treatment, medication, medical insurance settlement, and payment transaction numbers. These fields need to be uniformly mapped to ensure consistent data formats across different hospital campuses or partner institutions. Then, each medical item is matched against a predefined premium allocation ratio. Based on dimensions such as item type, medication category, and treatment intensity, project-based settlement details with clear destinations are generated, along with the original payment transaction number, allocation coefficient, version number, and timestamp, ensuring traceability and auditability. Next, an electronic reimbursement voucher data package is constructed based on the details, including metadata such as medical record number, expense category, payment path, allocation ratio, amounts for each party, voucher code, generation time, and validity period, ensuring consistency and efficiency during cross-institutional reconciliation. To enhance security, end-to-end encrypted transmission, field-level data masking, and access control policies are implemented to ensure minimal exposure of sensitive information during transmission and storage. Furthermore, a voucher lifecycle management mechanism is designed to support voucher creation, modification, revocation, archiving, and playback, as well as automatic alerts and manual review processes for abnormal vouchers. Through modular and microservice implementation, HIS data acquisition, expense alignment, electronic voucher generation, and reconciliation playback are decoupled, facilitating rapid cross-institutional integration and compliance auditing.

[0057] Through the above steps, seamless integration of medical data and premium allocation is achieved, generating traceable electronic reimbursement vouchers and improving reconciliation efficiency and settlement transparency.

[0058] In the above embodiments, this application discloses a product recommendation method based on a payment network, belonging to the field of artificial intelligence technology, and applied to medical insurance claims. At the data level, patient medical data from different systems is first formatted and mapped to form unified medical data. Then, claims rules matching the unified medical data are extracted from a pre-set insurance claims database, and combined with insurance eligibility determination logic, the system automatically generates insurance verification results. Based on the verification results and rules, the system allocates insurance payment amounts, extracts premium allocation ratios, and achieves precise and transparent allocation of funds among the insurance company, medical insurance account, and patient co-payment. Simultaneously, the system obtains medical records from the hospital information system and generates reimbursement vouchers based on the allocation ratios. By sending a direct payment instruction to the payment platform and triggering fund transfer upon instruction confirmation, and updating the patient's account status through a fund arrival instruction, a claim details report is generated and pushed. The entire chain of this application supports audit tracking, anomaly alerts, and log retention, and has good scalability to adapt to changes in regional policies, institution types, and payment models, significantly improving the level of claims automation, settlement accuracy, reconciliation efficiency, and overall operational efficiency.

[0059] In this embodiment, the product recommendation method based on the payment network operates on an electronic device (e.g., Figure 1 The server shown can receive instructions or acquire data via wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra-wideband) connections, and other currently known or future wireless connection methods.

[0060] It should be emphasized that, in order to further ensure the privacy and security of the aforementioned patient medical data, the aforementioned patient medical data can also be stored in a blockchain node.

[0061] The blockchain referred to in this application is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. Essentially, a blockchain is a decentralized database, a chain of data blocks linked together using cryptographic methods. Each data block contains information about a batch of network transactions, used to verify the validity of the information (anti-counterfeiting) and generate the next block. A blockchain can include an underlying blockchain platform, a platform product service layer, and an application service layer.

[0062] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0063] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0064] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0065] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0066] Further reference Figure 4 As a response to the above Figure 2 The implementation of the method shown in this application provides an embodiment of a product recommendation device based on a payment network. This device embodiment is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0067] like Figure 4 As shown, the product recommendation device 400 based on a payment network described in this embodiment includes: The data acquisition module 401 is used to collect patient medical data from multi-source medical databases and use a data mapping algorithm to process the differences in data formats between different systems to obtain unified medical data. The rule verification module 402 is used to obtain the appropriate product rules from the preset product database for the unified medical data, and to determine the validity of the product qualification based on the unified medical data and the product rules, so as to obtain the product verification result. The fee allocation module 403 is used to obtain the payment amount that matches the product verification results, and allocate fees based on the payment amount according to the product rules to determine the product allocation ratio. The voucher generation module 404 is used to obtain medical record data from the hospital information system and generate reimbursement vouchers based on the medical record data and product allocation ratio. The payment processing module 405 is used to send a payment instruction to the payment platform based on the verification voucher. If the payment instruction is confirmed to be correct, the fund transfer is triggered and a fund arrival instruction is obtained. The report push module 406 is used to update the patient's account status through the fund arrival instruction and generate and push payment detail reports.

[0068] Furthermore, the data acquisition module 401 specifically includes: The patient information unit is used to extract patient information from the hospital information system, electronic medical record system, laboratory and examination system, and drug management system, respectively. The patient information includes basic information, diagnosis and treatment information, laboratory reports, and cost lists. Standardized units are used to establish a data field mapping relationship table based on the data source identifier, and to perform standardized preprocessing on the field names, data types and encoding rules of different systems. Structured units are used to unify the format and align the semantics of preprocessed multi-source data through a preset data mapping algorithm, and to convert unstructured fields into structured JSON format data. The data aggregation unit is used to aggregate standardized data according to a preset medical information model to generate unified medical data that includes patient identity information, treatment behavior, cost details and payment path.

[0069] Further, please refer to Figure 5 The rule validation module 402 specifically includes: Rule Index Form 501 is used to retrieve the product rule set corresponding to the patient type by calling the rule index module in the preset product database based on the patient's identity, visit type and cost item in the unified medical data; Rule parsing unit 502 is used to parse the product rule set and extract product rule information; The rule comparison unit 503 is used to compare the unified medical data with the product rule information item by item, and to perform validity matching and verification based on the elements of diagnosis and treatment item code, medical institution level, and cost item, and generate product verification results.

[0070] Furthermore, the rule index unit 501 specifically includes: The identity recognition subunit is used to parse the patient identity identifier field in the unified medical data and obtain the product type code corresponding to the patient. The interface query subunit is used to locate the corresponding rule index table in the product database based on the product type code, and call the query interface of the rule index module to obtain the primary rule list; The multi-dimensional filtering sub-unit is used to perform multi-dimensional filtering of product rules in the primary rule list, filtering rules according to the type of visit, level of medical institution, category of fee item, and regional policy parameters. The rule selection sub-unit is used to automatically select the currently effective product rule set from multiple candidate rules based on the rule version number and timestamp information, and cache the selected product rule set in the local rule mapping table.

[0071] Furthermore, the cost allocation module 403 specifically includes: The valid payment verification unit is used to extract the corresponding expense details and payment amount from the unified medical data based on the valid payment items that have passed the verification in the product verification results. The payment calculation unit is used to calculate the amount payable for each payment item based on the payment parameters in the product rules and generate an initial payment list. The classification and processing unit is used to classify and process the costs of each item in the initial payment list and calculate the distribution of payment amounts from each payment source. The weighted calculation unit is used to determine the proportion of each payment source in the total cost based on the distribution of payment amounts using a weighted calculation model, thereby obtaining the product allocation ratio.

[0072] Furthermore, the weighted calculation unit specifically includes: The payment classification subunit is used to extract the payment amount for each payment source based on the total amount of fees for each payment source in the payment amount distribution; The weighting coefficient subunit is used to set weighting coefficients for each payment source; The weighted summation subunit is used to perform a weighted summation operation on the payment amount of each payment source and the corresponding weighting coefficient to calculate the weighted total payment amount; The weighted percentage calculation subunit is used to divide the weighted amount of each payment source by the total weighted payment amount to obtain the weighted percentage of each payment source in the total cost. The weighted calculation subunit is used to output the weighted percentage as the product allocation ratio.

[0073] Furthermore, the voucher generation module 404 specifically includes: The medical record unit is used to obtain the patient's current medical record data through the interface call module of the hospital information system. The patient's current medical record data includes registration information, treatment items, drug costs, settlement information and payment serial number. The association calculation unit is used to associate and calculate the cost items in the patient's current medical record data with the corresponding product allocation ratio to generate settlement details. The unique voucher unit is used to construct an electronic reimbursement voucher data package containing the visit number, cost category, payment path and allocation ratio based on the settlement details, and to generate a unique voucher number for the electronic reimbursement voucher data package.

[0074] In the above embodiments, this application discloses a product recommendation device based on a payment network, belonging to the field of artificial intelligence technology, and applied to medical insurance claims. At the data level, patient medical data from different systems is first format-aligned and field-mapped to form unified medical data. Then, claims rules matching the unified medical data are extracted from a pre-set insurance claims database, and combined with insurance eligibility determination logic, the system automatically generates insurance verification results. Based on the verification results and rules, the system allocates insurance payment amounts, extracts premium allocation ratios, and achieves precise and transparent allocation of funds among the insurance company, medical insurance account, and patient co-payment. Simultaneously, the system obtains medical records from the hospital information system and generates reimbursement vouchers based on the allocation ratios. By sending a direct payment instruction to the payment platform and triggering fund transfer upon instruction confirmation, and updating the patient's account status through a fund arrival instruction, a claim details report is generated and pushed. The entire chain of this application supports audit tracking, anomaly alerts, and log retention, and has good scalability to adapt to changes in regional policies, institution types, and payment models, significantly improving the level of claims automation, settlement accuracy, reconciliation efficiency, and overall operational efficiency.

[0075] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 6 , Figure 6 This is a basic structural block diagram of the computer device in this embodiment.

[0076] The computer device 6 includes a memory 61, a processor 62, and a network interface 63 that are interconnected via a system bus. It should be noted that only the computer device 6 with memory 61, processor 62, and network interface 63 is shown in the figure; however, it should be understood that it is not required to implement all the components shown, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0077] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0078] The memory 61 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 61 may be an internal storage unit of the computer device 6, such as the hard disk or memory of the computer device 6. In other embodiments, the memory 61 may also be an external storage device of the computer device 6, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 6. Of course, the memory 61 may also include both the internal storage unit and its external storage device of the computer device 6. In this embodiment, the memory 61 is typically used to store the operating system and various application software installed on the computer device 6, such as computer-readable instructions for product recommendation methods based on payment networks. In addition, the memory 61 can also be used to temporarily store various types of data that have been output or will be output.

[0079] In some embodiments, the processor 62 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. The processor 62 is typically used to control the overall operation of the computer device 6. In this embodiment, the processor 62 is used to execute computer-readable instructions stored in the memory 61 or to process data, for example, to execute computer-readable instructions for the product recommendation method based on the payment network.

[0080] The network interface 63 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 6 and other electronic devices.

[0081] This application also provides an embodiment, namely, a computer device including a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the product recommendation method based on the payment network as described above.

[0082] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the product recommendation method based on the payment network described above.

[0083] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0084] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0085] It should be noted that the software tools or components not belonging to this company that appear in the various embodiments of this application are merely illustrative examples and do not represent actual use.

[0086] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

Claims

1. A product recommendation method based on a payment network, characterized in that, include: Patient medical data is collected from multiple medical databases, and data mapping algorithms are used to process the differences in data formats between different systems to obtain unified medical data; For the unified medical data, appropriate product rules are obtained from a preset product database, and the validity of product qualification is determined based on the unified medical data and the product rules to obtain the product verification result; Obtain the product verification result and the matching payment amount, and allocate the payment amount according to the product rules to determine the product allocation ratio; Obtain medical record data from the hospital information system, and generate a reimbursement voucher based on the medical record data and the product allocation ratio; A payment instruction is sent to the payment platform based on the verification voucher. If the payment instruction is confirmed to be correct, a fund transfer is triggered, and the fund arrival instruction is obtained. The patient's account status is updated via the fund arrival instruction, and a payment details report is generated and pushed.

2. The product recommendation method based on a payment network as described in claim 1, characterized in that, The step of collecting patient medical data from multi-source medical databases and using a data mapping algorithm to process data format differences between different systems to obtain the unified medical data specifically includes: Patient information is extracted from the hospital information system, electronic medical record system, laboratory and examination system, and drug management system. The patient information includes basic information, diagnosis and treatment information, laboratory reports, and expense lists. A data field mapping relationship table is established based on the data source identifier, and the field names, data types and encoding rules of different systems are standardized and preprocessed. The pre-processed multi-source data is formatted and semantically aligned using a preset data mapping algorithm, and unstructured fields are converted into structured JSON format data. Data in a standardized format is aggregated according to a pre-defined medical information model to generate unified medical data that includes patient identity information, treatment behavior, cost details, and payment path.

3. The product recommendation method based on a payment network as described in claim 1, characterized in that, The steps of obtaining suitable product rules from a preset product database for the unified medical data, and determining the validity of product eligibility based on the unified medical data and the product rules to obtain the product verification result specifically include: Based on the patient's identity, treatment type, and cost items in the unified medical data, the rule index module in the preset product database is invoked to retrieve the product rule set corresponding to the patient type. The product rule set is parsed to extract product rule information; The unified medical data is compared item by item with the product rule information, and the validity is verified based on the elements of diagnosis and treatment item code, medical institution level, and cost item to generate the product verification result.

4. The product recommendation method based on a payment network as described in claim 3, characterized in that, The step of retrieving the product rule set corresponding to the patient type by calling the rule index module in the preset product database based on the patient's identity identifier, visit type, and cost item in the unified medical data specifically includes: Parse the patient identification field in the unified medical data to obtain the product type code corresponding to the patient; Based on the product type code, locate the corresponding rule index table in the product database, and call the query interface of the rule index module to obtain the primary rule list; The product rules in the primary rule list are filtered in multiple dimensions, according to the type of medical visit, the level of the medical institution, the category of the fee item, and the regional policy parameters. Based on the rule version number and timestamp information, the currently effective product rule set is automatically selected from multiple candidate rules, and the selected product rule set is cached in the local rule mapping table.

5. The product recommendation method based on a payment network as described in claim 1, characterized in that, The steps of obtaining the payment amount that matches the product verification result and allocating fees based on the payment amount according to the product rules to determine the product allocation ratio specifically include: Based on the valid payment items that have passed verification in the product verification results, extract the corresponding cost details and payment amounts from the unified medical data. Based on the payment parameters in the product rules, calculate the amount payable for each payment item and generate an initial payment list; The execution costs for each item in the initial payment list are categorized and processed, and the payment amount distribution for each payment source is calculated; Based on the payment amount distribution, a weighted calculation model is used to determine the proportion of each payment source in the total cost, thereby obtaining the product allocation ratio.

6. The product recommendation method based on a payment network as described in claim 5, characterized in that, The step of determining the proportion of each payment source in the total cost based on the payment amount distribution using a weighted calculation model to obtain the product allocation ratio specifically includes: Based on the total amount of fees from each payment source in the payment amount distribution, extract the payment amount from each payment source; Set weighting coefficients for each payment source; The weighted summation of the payment amount from each payment source and its corresponding weighting coefficient is performed to calculate the total weighted payment amount. Divide the weighted amount of each payment source by the total weighted payment amount to obtain the weighted percentage of each payment source in the total cost; The weighted percentage is output as the product allocation ratio.

7. The product recommendation method based on a payment network as described in claim 1, characterized in that, The step of obtaining medical record data from the hospital information system and generating a reimbursement voucher based on the medical record data and the product allocation ratio specifically includes: The patient's current medical record data is obtained through the interface call module of the hospital information system. The patient's current medical record data includes registration information, treatment items, drug costs, settlement information and payment serial number. The settlement details are generated by associating each cost item in the patient's current medical record with the corresponding product allocation ratio. Based on the settlement details, an electronic verification voucher data package containing the visit number, cost category, payment path, and allocation ratio is constructed, and a unique voucher number is generated for the electronic verification voucher data package.

8. A product recommendation device based on a payment network, characterized in that, include: The data acquisition module is used to collect patient medical data from multi-source medical databases and to use data mapping algorithms to process the differences in data formats between different systems to obtain unified medical data. The rule verification module is used to obtain suitable product rules from a preset product database for the unified medical data, and to determine the validity of product qualification based on the unified medical data and the product rules, so as to obtain the product verification result. The fee allocation module is used to obtain the product verification result and the matching payment amount, and allocate the fee according to the product rules to the payment amount to determine the product allocation ratio; The voucher generation module is used to obtain medical record data from the hospital information system and generate reimbursement vouchers based on the medical record data and the product allocation ratio; The payment processing module is used to send a payment instruction to the payment platform based on the verification voucher. If the payment instruction is confirmed to be correct, the fund transfer is triggered and the fund arrival instruction is obtained. The report push module is used to update the patient's account status based on the fund arrival instruction, and to generate and push payment details reports.

9. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the product recommendation method based on a payment network as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the product recommendation method based on a payment network as described in any one of claims 1 to 7.

Images