Pharmacy intelligent payment recommendation method, device and equipment based on user portrait

Abstract

The invention discloses a drugstore intelligent payment recommendation method, device and equipment based on a user portrait, and relates to the field of data processing. The method comprises the following steps: acquiring a medical insurance card number of a user; according to the medical insurance card number, basic information and historical medicine purchasing records of the user are extracted from a pharmacy database; analyzing the basic information and the historical medicine purchasing records of the user by adopting a clustering algorithm to obtain a medicine purchasing habit of the user, and constructing a user portrait of the user according to the medicine purchasing habit; according to the historical medicine purchasing record, payment preferences of the user are counted, and the payment preferences comprise the use frequency of the user for each payment mode; in a preset payment recommendation model, taking the user portrait and the payment preference as input, and matching a candidate payment scheme library; and based on the current medicine purchase list and the medical insurance account balance, determining a target payment combination from the plurality of candidate payment combinations. By implementing the technical scheme provided by the invention, the user experience is improved.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular, to a pharmacy intelligent payment recommendation method, device, and equipment based on user portraits. Background Art

[0002] With the development of society and the progress of technology, the demand for personalized services in all walks of life is increasing. Especially in the field of healthcare, with the application of big data and intelligent technologies, people have higher expectations for the convenience and personalization of services. As an important part of medical services, pharmacies not only need to provide accurate drug sales services but also payment solutions that meet the needs and habits of users. Different health conditions, drug purchase habits, and payment method preferences of users require pharmacies to provide more intelligent and personalized services to enhance the shopping experience and satisfaction of consumers.

[0003] Currently, existing pharmacy payment systems often adopt a relatively unified payment processing method, ignoring the personalized payment preferences and drug purchase habits of users. This payment method not only reduces the payment convenience of users but also may affect the customer satisfaction of pharmacies. In addition, existing payment systems rarely consider the automatic integration of users' medical insurance information, resulting in users having to manually select and confirm various payment information during payment, increasing the complexity and time cost of transactions. These limitations are particularly prominent when dealing with a large number of customers, easily causing service bottlenecks and a decline in the user experience. Therefore, existing pharmacy payment systems have the problem of low user experience.

[0004] Therefore, there is an urgent need for a pharmacy intelligent payment recommendation method, device, and equipment based on user portraits. Summary of the Invention

[0005] This application provides a pharmacy intelligent payment recommendation method, device, and equipment based on user portraits, improving the user experience.

[0006] In the first aspect of the present application, a pharmacy intelligent payment recommendation method based on user portraits is provided. The method includes: obtaining the user's medical insurance card number; extracting the user's basic information and historical drug purchase records from the pharmacy database according to the medical insurance card number; analyzing the user's basic information and historical drug purchase records using a clustering algorithm to obtain the user's drug purchase habits, and constructing the user's user portrait according to the drug purchase habits; counting the user's payment preferences according to the historical drug purchase records, where the payment preferences include the usage frequencies of the user for various payment methods; in a preset payment recommendation model, using the user portrait and the payment preferences as inputs to match a candidate payment plan library, where the candidate payment plan library includes multiple candidate payment combinations; obtaining the user's current drug purchase list and the balance of the medical insurance account corresponding to the medical insurance card number; and determining a target payment combination from the multiple candidate payment combinations based on the current drug purchase list and the medical insurance account balance.

[0007] By adopting the above technical solution, first, the user's medical insurance card number is obtained, and the user's basic information and historical drug purchase records are extracted from the pharmacy database. Then, a clustering algorithm is used to analyze the user's drug purchase habits, construct a user portrait, and count the usage frequencies of the user for various payment methods according to the historical drug purchase records to obtain the user's payment preferences. Next, the user portrait and the payment preferences are input into a preset payment recommendation model to match the candidate payment plan library and obtain multiple candidate payment combinations. Finally, according to the user's current drug purchase list and the balance of the medical insurance account, the optimal target payment combination is determined from the candidate payment combinations. This method matches the user portrait and the payment preferences with the candidate payment plans, and can intelligently recommend the payment combination that best meets the user's habits and needs, improving the user's payment experience and satisfaction.

[0008] Optionally, the step of analyzing the user's basic information and historical drug purchase records using a clustering algorithm to obtain the user's drug purchase habits and constructing the user's user portrait according to the drug purchase habits specifically includes: extracting features from the user's basic information to obtain a user basic feature vector; where the user's basic information includes age, gender, and home address; extracting features from the user's historical drug purchase records to obtain a user drug purchase feature vector; where the user's historical drug purchase records include the drug purchase time, drug purchase frequency, drug category, and drug quantity; inputting the user basic feature vector and the user drug purchase feature vector into a preset clustering model to obtain the clustering result of the user's drug purchase habits; where the clustering model is trained using the K-means clustering algorithm; and matching a corresponding user portrait template from a preset user portrait template library according to the clustering result of the drug purchase habits, and generating the user's user portrait based on the user portrait template.

[0009] By adopting the above technical solution, feature extraction is performed on the user's basic information and historical pharmacy purchase records to obtain a user basic feature vector and a user pharmacy purchase feature vector. Then, these two feature vectors are input into a preset clustering model for clustering analysis to obtain the clustering result of the user's pharmacy purchase habits. Finally, a user portrait is matched and generated from the user portrait template library according to the clustering result. This method utilizes feature engineering and clustering algorithms in machine learning and can efficiently and accurately depict the user's pharmacy purchase habits and user characteristics. By performing structured feature extraction on the user's basic information and historical pharmacy purchase records, the unstructured original data is transformed into mathematical vectors that can be understood and processed by a computer, laying a foundation for subsequent algorithm analysis. Matching the user portrait template based on the clustering result makes the portrait construction more flexible and personalized, can significantly enhance the pharmacy's insight into user behavior and preferences, and provides a high-quality user understanding basis for intelligent payment recommendations.

[0010] Optionally, the statistics of the user's payment preferences according to the historical pharmacy purchase records specifically include: obtaining the payment method field in the historical pharmacy purchase records, and performing category labeling on each payment method according to the payment method field to obtain a payment method category label, where the payment method category label includes medical insurance payment, bank card payment, mobile payment, and cash payment; counting the number of each payment method category label and calculating the proportion of the number of each payment method category label in the total number of records, and taking the proportion as the usage frequency of the user for each payment method.

[0011] By adopting the above technical solution, this method first extracts the payment method field from the historical pharmacy purchase records and performs category labeling on different payment methods, then counts the number and proportion of each payment method category, and takes the proportion as the usage frequency of the user for this payment method. This payment preference statistics method is simple to operate, easy to implement, and can objectively reflect the user's selection tendency for different payment methods in the actual pharmacy purchase scenario. By mining and labeling the payment method field in the historical pharmacy purchase records, the payment behavior data of users can be comprehensively collected. Taking the proportion of the number of times each payment method is used in the total number of times as the preference measure intuitively depicts the relative preference ranking of the user for different payment methods and is easy to apply in the recommendation algorithm. This payment preference statistics method can help pharmacies comprehensively understand the true payment behavior and preferences of users, discover mainstream and niche payment methods, optimize the payment settlement process, and provide reliable user preference input for intelligent payment recommendations.

[0012] Optionally, after counting the user's payment preferences based on the historical drug purchase records, the method further includes: obtaining the payment methods included in each candidate payment combination in the candidate payment plan library; calculating the weight scores of the payment methods in the candidate payment combination, where the weight score is equal to the usage frequency of the payment method multiplied by a preset weight coefficient; accumulating the weight scores of the payment methods in the candidate payment combination to obtain the combined score of the candidate payment combination; sorting the candidate payment combinations from largest to smallest according to the combined score to obtain a sorting result.

[0013] By adopting the above technical solution, after counting the user's payment preferences, the combined score of the candidate payment combinations is further calculated, and the candidate payment combinations are sorted based on the combined score. The method first obtains the payment methods included in each candidate payment combination in the candidate payment plan library, then calculates the weight scores of each payment method, where the weight score is equal to the usage frequency of the payment method multiplied by a preset weight coefficient. Next, the weight scores of the payment methods in the candidate payment combination are accumulated to obtain the combined score of the candidate payment combination. Finally, all candidate payment combinations are sorted from largest to smallest according to the combined score to obtain a recommended sorting result of the payment combinations. This combined score calculation and sorting method makes full use of the user's historical payment preference data and quantitatively evaluates the matching degree of each candidate payment combination with the user's preferences through a weighted average method. When calculating the weight score, not only the usage frequency of the payment method is considered, but also a weight coefficient is introduced, allowing the pharmacy to flexibly adjust the importance of different payment methods according to business experience and actual situations, improving the controllability and adaptability of the scoring mechanism.

[0014] Optionally, determining the target payment combination from multiple candidate payment combinations based on the current drug purchase list and the balance of the medical insurance account specifically includes: extracting the drug information in the current drug purchase list, where the drug information includes the drug name, drug unit price, and drug quantity of each drug, and calculating the total payable amount; determining whether each drug in the drug purchase list belongs to the medical insurance catalog drugs and labeling the drug category label; calculating the amount allowed for medical insurance reimbursement for each drug according to the drug category label and the medical insurance payment policy, and accumulating to obtain the total amount allowed for medical insurance reimbursement; subtracting the total amount allowed for medical insurance reimbursement from the total payable amount to obtain the out-of-pocket amount; screening the sorting result according to the out-of-pocket amount, eliminating the candidate payment combinations that do not include medical insurance payment to obtain the target sorting result; using the candidate payment combination ranked first in the target sorting result as the target payment combination.

[0015] By adopting the above technical solution, first, the drug information in the user's current drug purchase list is extracted, and then it is determined whether each drug in the purchase list belongs to the medical insurance catalog and category labeling is performed. Then, according to the drug category and the medical insurance payment policy, the reimbursable amount allowed for each drug is calculated, and the total reimbursable amount allowed by the medical insurance is accumulated. Then, the total payable amount is subtracted from the total medical insurance reimbursement amount to obtain the amount that the user actually needs to pay out of their own pocket. According to the out-of-pocket amount, the sorting result of the previously obtained candidate payment combinations is screened, and the combinations that do not include medical insurance payment are excluded to obtain a more refined and matching target sorting result. Finally, the candidate payment combination ranked first in the target sorting result is used as the final target payment combination and recommended to the user for payment. This method for determining the target payment combination comprehensively considers the user's actual payment needs, medical insurance reimbursement policies, and payment priorities. When making payment recommendations, by analyzing the user's current specific drug purchase scenario, calculating the actual out-of-pocket amount to be paid, and screening the candidate payment combinations based on this, it can specifically narrow down the recommendation scope and improve the accuracy and practicality of the recommendation.

[0016] Optionally, in the preset payment recommendation model, before using the user portrait and the payment preference as inputs to match the candidate payment scheme library, the method further includes: obtaining the user portrait features, payment preference features, and payment result labels of historical users to form a training data set; using the user portrait features and the payment preference features as inputs, converting the user portrait features into user portrait feature vectors through an embedding layer, and converting the payment preference features into payment preference feature vectors; splicing the user portrait feature vectors and the payment preference feature vectors, and performing feature transformation and combination through multiple fully connected layers; in the last fully connected layer, scoring each candidate payment combination to obtain the recommendation probability of each candidate payment combination, thereby obtaining the preset payment recommendation model.

[0017] By adopting the above technical solution, first, the user portrait features, payment preference features, and payment result labels of historical users are obtained to form a training data set. Then, the user portrait features and the payment preference features are used as inputs, and they are converted into user portrait feature vectors and payment preference feature vectors through an embedding layer. Next, these two feature vectors are spliced and subjected to feature transformation and combination through multiple fully connected layers. Finally, in the last fully connected layer, each candidate payment combination is scored to obtain their recommendation probabilities, completing the training of the payment recommendation model. This method for constructing the payment recommendation model makes full use of deep learning technology and can automatically learn the complex association and mapping relationship between user features and payment behaviors from a large amount of historical data.

[0018] Optionally, after determining the target payment combination from multiple candidate payment combinations based on the current drug purchase list and the balance of the medical insurance account, the method further includes: obtaining confirmation information of the user for the target payment combination; if the confirmation information indicates that the user accepts the target payment combination, sending the payment amounts corresponding to the respective payment methods in the target payment combination to a payment terminal; if the confirmation information indicates that the user rejects the target payment combination, obtaining the payment combination selected by the user, and sending the payment amounts corresponding to the respective payment methods in the payment combination selected by the user to the payment terminal.

[0019] By adopting the above technical solution, on the basis of payment recommendation, an active confirmation link of the user is further introduced, improving the flexibility of the payment plan and the user perception. The method first obtains the confirmation information of the user for the recommended target payment combination. If the user accepts the recommendation, the specific payment amounts corresponding to the respective payment methods in the target payment combination are sent to the payment terminal to complete the payment process. If the user rejects the recommendation, the system allows the user to independently select a payment combination, and sends the amount information of the payment combination selected by the user to the payment terminal to complete the payment process. This payment confirmation mechanism maximally exerts the role of intelligent payment recommendation on the basis of respecting the user's will. The user can flexibly decide whether to adopt the payment plan recommended by the system according to their actual situation and the acceptance degree of the recommendation result.

[0020] In a second aspect of the present application, a pharmacy intelligent payment recommendation device based on a user portrait is provided. The device includes: an acquisition module and a processing module, wherein: the acquisition module is used to acquire the medical insurance card number of the user; the processing module is used to extract the basic information and historical drug purchase records of the user from a pharmacy database according to the medical insurance card number; the processing module is further used to analyze the basic information and historical drug purchase records of the user by using a clustering algorithm to obtain the drug purchase habits of the user, and construct the user portrait of the user according to the drug purchase habits; the processing module is further used to count the payment preferences of the user according to the historical drug purchase records, and the payment preferences include the usage frequencies of the user for each payment method; the processing module is further used to use the user portrait and the payment preferences as inputs in a preset payment recommendation model to match a candidate payment plan library, and the candidate payment plan library includes multiple candidate payment combinations; the acquisition module is further used to acquire the current drug purchase list of the user and the balance of the medical insurance account corresponding to the medical insurance card number; the processing module is further used to determine a target payment combination from multiple candidate payment combinations based on the current drug purchase list and the balance of the medical insurance account.

[0021] In a third aspect of the present application, an electronic device is provided, including a processor, a memory, a user interface, and a network interface. The memory is used to store instructions. Both the user interface and the network interface are used to communicate with other devices. The processor is used to execute the instructions stored in the memory, so that the electronic device executes the method described in any one of the above.

[0022] In a fourth aspect of the present application, a computer-readable storage medium is provided. The computer-readable storage medium stores instructions, and when the instructions are executed, the method described in any one of the above is executed.

[0023] In summary, one or more technical solutions provided in the present application have at least the following technical effects or advantages: 1. First, obtain the user's medical insurance card number, extract the user's basic information and historical drug purchase records from the pharmacy database, then use a clustering algorithm to analyze the user's drug purchase habits, construct a user portrait, and count the usage frequency of each payment method based on the historical drug purchase records to obtain the user's payment preference. Next, input the user portrait and payment preference into a preset payment recommendation model, match the candidate payment plan library, and obtain multiple candidate payment combinations. Finally, determine the optimal target payment combination from the candidate payment combinations according to the user's current drug purchase list and the balance of the medical insurance account. This method matches the user portrait and payment preference with the candidate payment plan, and can intelligently recommend the payment combination that best meets the user's habits and needs, improving the user's payment experience and satisfaction. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a schematic flowchart of a pharmacy intelligent payment recommendation method based on user portrait disclosed in an embodiment of the present application; Figure 2 is a schematic module diagram of a pharmacy intelligent payment recommendation device based on user portrait disclosed in an embodiment of the present application; Figure 3 is a schematic structural diagram of an electronic device disclosed in an embodiment of the present application.

[0025] Description of the reference numerals: 201, acquisition module; 202, processing module; 300, electronic device; 301, processor; 302, communication bus; 303, user interface; 304, network interface; 305, memory. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0026] In order to enable those skilled in the art to better understand the technical solutions in this specification, the following will clearly and completely describe the technical solutions in the embodiments of this specification with reference to the accompanying drawings in the embodiments of this specification. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments.

[0027] In the description of the embodiments of the present application, words such as "for example" or "for instance" are used to give examples, illustrations or explanations. Any embodiment or design solution described as "for example" or "for instance" in the embodiments of the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0028] In the description of the embodiments of the present application, the term "a plurality of" means two or more. For example, a plurality of systems means two or more systems, and a plurality of screen terminals means two or more screen terminals. In addition, the terms "first" and "second" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include one or more of such features. The terms "include", "comprise", "have" and their variants all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0029] The present application provides a pharmacy intelligent payment recommendation method based on user portraits. Refer to Figure 1 , Figure 1 is a schematic flowchart of a pharmacy intelligent payment recommendation method provided by an embodiment of the present application. This method is applied to a server. The server is a server that executes a pharmacy intelligent payment recommendation program based on user portraits. The server can be a single server, a server cluster composed of multiple servers, or a cloud computing service center. This method includes steps S101 to S107, and the above steps are as follows: Step S101: Obtain the user's medical insurance card number.

[0030] In step S101, the server obtains the user's medical insurance card number. This step can be implemented in multiple ways. One way is to collect the user's medical insurance card number through the pharmacy's cashier system or self-service terminal device. When a user purchases medicine at a pharmacy, the user needs to insert or scan the medical insurance card into the cashier system or self-service terminal device, and the system will automatically read the information on the medical insurance card, including the medical insurance card number. Then, the cashier system or self-service terminal device transmits the read medical insurance card number to the server through the network. Another possible implementation method is to obtain the medical insurance card number through the pharmacy's mobile application. When a user uses the pharmacy's mobile application for the first time, the user needs to register and bind their own medical insurance card. During the binding process, the user needs to manually enter or use the scanning function of the application to enter the medical insurance card number. After the user submits the medical insurance card number, the mobile application uploads the medical insurance card number to the server.

[0031] Regardless of the method used to obtain the medical insurance card number, after the server receives the medical insurance card number, it performs necessary verification and processing. The server can check whether the format and length of the medical insurance card number are correct and whether it conforms to the encoding rules of the medical insurance card number. If the medical insurance card number passes the verification, the server stores it in the database and associates it with other user information, such as user ID, name, age, etc. In this way, the server establishes a mapping relationship between the user's medical insurance card number and the user's personal information, providing a basis for subsequent data analysis and recommendation.

[0032] Step S102: Extract the user's basic information and historical drug purchase records from the pharmacy database according to the medical insurance card number.

[0033] In step S102, the server extracts the basic information and historical drug purchase records of the user from the pharmacy database according to the user's medical insurance card number. The server establishes a connection with the pharmacy database. The pharmacy database usually contains multiple data tables such as user information tables and drug purchase record tables, storing various types of data of the pharmacy. The server establishes a stable connection channel with the pharmacy database through a database connection program, such as JDBC.

[0034] After establishing the connection, the server starts to extract relevant data according to the user's medical insurance card number. The server executes an SQL query statement to find the user record that matches the given medical insurance card number in the user information table. The user information table usually contains the user's basic information, such as user ID, name, gender, date of birth, contact information, etc. The server extracts this basic information from the query result and temporarily stores it in memory or writes it to a temporary file. Then, the server queries the historical drug purchase records of the user in the drug purchase record table according to the user ID. The drug purchase record table usually contains information such as user ID, drug purchase time, drug name, drug quantity, payment amount, payment method, etc. The server also executes an SQL query statement to retrieve all historical drug purchase records related to the current user ID and arranges them in chronological order.

[0035] Step S103: Use a clustering algorithm to analyze the user's basic information and historical drug purchase records to obtain the user's drug purchase habits, and construct a user portrait for the user according to the drug purchase habits.

[0036] In step S103, a clustering algorithm is used to analyze the user's basic information and historical medication purchase records to obtain the user's medication purchase habits, and a user profile is constructed based on the medication purchase habits, specifically including: extracting features from the user's basic information to obtain a user basic feature vector; where the user's basic information includes age, gender, and home address; extracting features from the user's historical medication purchase records to obtain a user medication purchase feature vector; where the user's historical medication purchase records include the medication purchase time, purchase frequency, drug category, and drug quantity; inputting the user basic feature vector and the user medication purchase feature vector into a preset clustering model to obtain a clustering result of the user's medication purchase habits; where the clustering model is trained using the K-means clustering algorithm; and based on the clustering result of the medication purchase habits, matching the corresponding user profile template from a preset user profile template library, and generating a user profile for the user based on the user profile template.

[0037] Specifically, the server uses a clustering algorithm to analyze the user's basic information and historical medication purchase records to obtain the user's medication purchase habits, and constructs a user profile based on the medication purchase habits. The purpose of this step is to automatically discover the user's medication purchase patterns and preferences through machine learning technology, providing a personalized decision-making basis for subsequent intelligent payment recommendations.

[0038] First, the server extracts features from the user's basic information to obtain a user basic feature vector. The user's basic information includes attributes such as age, gender, and home address. The server converts these attributes into numerical or categorical feature variables to form a feature vector with a fixed dimension. For example, representing the gender "male" as 1 and "female" as 0; dividing the age into several intervals, such as representing "18 - 25 years old" as 1, "26 - 35 years old" as 2, and so on; encoding the home address as a set of numerical coordinates according to the geographical location. Through feature extraction, the server standardizes the user's basic information into a structured data representation.

[0039] Next, the server extracts features from the user's historical medication purchase records to obtain a user medication purchase feature vector. The user's historical medication purchase records include information such as the medication purchase time, purchase frequency, drug category, and drug quantity. The server designs a suitable feature engineering scheme according to the business requirements and data characteristics to convert these information into numerical or categorical feature variables. For example, dividing the medication purchase time into three time periods: morning, afternoon, and evening; calculating the purchase frequency as the number of medication purchases per month; encoding the drug category as a high-dimensional sparse vector, where each dimension represents a drug category; normalizing the drug quantity to a real number between 0 and 1. Through feature extraction, the server converts the user's medication purchase records into a structured data representation, forming a complete user feature set with the user basic feature vector.

[0040] Then, the server inputs the user's basic feature vector and the user's medicine purchase feature vector into a preset clustering model to obtain the clustering result of the user's medicine purchase habits. The clustering model is trained using the K-means clustering algorithm and can automatically classify similar users into the same group. The K-means algorithm continuously updates the clustering centers and adjusts the belonging categories of users through iterative optimization, and finally obtains K clustering results. Each clustering represents a typical user's medicine purchase habit. For example, the clustering result may show that one type of user often buys cold medicine and cough syrup at night. It is speculated that they may be office workers who are busy at work and are easily troubled by colds. Another type of user often buys vitamin health products. It is speculated that they may be middle-aged and elderly people with a strong sense of health.

[0041] Finally, based on the clustering result of the medicine purchase habits, the server matches the corresponding user portrait template from the preset user portrait template library and generates a personalized user portrait for the user based on the user portrait template. Various typical user feature templates are predefined in the user portrait template library, such as "office worker", "middle-aged and elderly people", "chronic disease patients", etc. The server matches the clustering result of the current user with the templates in the preset user portrait template library to find the most similar template as the basis for generating the user portrait. Then, the server fills in the actual information of the current user, such as age, gender, frequently purchased medicines, etc., according to the fields and rules in the template, and finally obtains a complete user portrait. For example, for user Wang who is classified as an "office worker", the server generates the following user portrait: "Wang Xiaoming, male, 35 years old, office worker, busy at work, often works overtime, easily catches colds, often buys cold medicine and cough syrup, prefers to buy medicine online at night, buys medicine 2-3 times a month, and pays attention to the brand and efficacy of medicines".

[0042] Step S104: According to the historical medicine purchase records, count the user's payment preferences, where the payment preferences include the usage frequencies of various payment methods by the user.

[0043] In step S104, according to the historical medicine purchase records, count the user's payment preferences, where the payment preferences include the usage frequencies of various payment methods by the user. Specifically, it includes: obtaining the payment method field in the historical medicine purchase records, and classifying and labeling each payment method according to the payment method field to obtain payment method category labels. The payment method category labels include medical insurance payment, bank card payment, mobile payment, and cash payment; count the quantities of each payment method category label, and calculate the proportion of the quantity of each payment method category label in the total number of records, and use the proportion as the usage frequency of each payment method by the user.

[0044] Specifically, the server analyzes the user's historical drug purchase records to calculate the user's payment preferences, mainly including the usage frequency of each payment method. The purpose of this step is to understand the user's payment habits and preferences during the drug purchase process by analyzing the user's past payment behavior, providing a decision-making basis for subsequent intelligent payment recommendations. First, the server starts from the user's historical drug purchase records extracted in step S102 and obtains the payment method field in each purchase record. The payment method field records the actual payment means used by the user in this drug purchase, such as medical insurance card, bank card, mobile payment, cash, etc. Since the database designs and field names of different pharmacies may vary, the server accurately identifies the payment method information of each record through methods such as field mapping or regular expression matching.

[0045] Then, the server classifies each payment method according to the value of the payment method field to obtain payment method category labels. The server has predefined several common payment method categories, such as medical insurance payment, bank card payment, mobile payment, and cash payment, etc., and designed corresponding label values. The server maps the original values of the payment method field to the predefined category labels through a rule engine or machine learning algorithm. For example, field values such as "medical insurance card" and "social security card" are mapped to the medical insurance payment label, field values such as "credit card" and "debit card" are mapped to the bank card payment label, field values such as "Alipay" and "WeChat Pay" are mapped to the mobile payment label, and field values such as "cash" and "paper money" are mapped to the cash payment label. In this way, the server converts the unstructured payment method text into structured category labels for subsequent statistical analysis.

[0046] Next, the server counts the payment method category labels in the user's historical drug purchase records and calculates the quantity and frequency of each label. The server first summarizes the entire historical drug purchase records to obtain the total number of records N. Then, the server traverses each purchase record and counts the number of occurrences of each payment method category label, denoted as n1, n2, n3, n4, representing the number of times of medical insurance payment, bank card payment, mobile payment, and cash payment respectively. Finally, the server calculates the proportion of the quantity of each payment method category label in the total number of records, that is, freq1 = n1 / N, freq2 = n2 / N, freq3 = n3 / N, freq4 = n4 / N, to obtain the usage frequency of each payment method by the user.

[0047] For example, for the historical drug purchase records of user Xiaowang, the server statistically obtains the following results: the total number of records N = 20, among which the medical insurance payment is n1 = 5, the bank card payment is n2 = 8, the mobile payment is n3 = 6, and the cash payment is n4 = 1. The usage frequencies of each payment method for Xiaowang are calculated as follows: the medical insurance payment freq1 = 5 / 20 = 25%, the bank card payment freq2 = 8 / 20 = 40%, the mobile payment freq3 = 6 / 20 = 30%, and the cash payment freq4 = 1 / 20 = 5%. This indicates that when purchasing drugs, the payment method that Xiaowang most frequently uses is the bank card, followed by mobile payment and medical insurance card, and cash payment is less used. The server records this payment preference information as part of Xiaowang's user profile.

[0048] In a possible implementation manner, after step S04, the method further includes: obtaining the payment methods included in each candidate payment combination in the candidate payment plan library; calculating the weight scores of each payment method in the candidate payment combination, where the weight score is equal to the usage frequency of the payment method multiplied by a preset weight coefficient; accumulating the weight scores of each payment method in the candidate payment combination to obtain the combined score of the candidate payment combination; sorting the candidate payment combinations from largest to smallest according to the combined score to obtain a sorting result.

[0049] Specifically, the server obtains the payment methods included in each candidate payment combination from the candidate payment plan library. The candidate payment plan library is a set of commonly used payment combinations pre-configured by the pharmacy, such as "medical insurance payment + cash payment", "bank card payment + medical insurance payment", etc. Each candidate payment combination consists of one or more payment methods, covering various payment scenarios for drug purchase. The server obtains the specific payment method list of each candidate payment combination by parsing the configuration file of the candidate payment plan library or querying the database table.

[0050] Then, the server calculates the weight scores of each payment method in the candidate payment combination according to the user's payment preference. The calculation formula for the weight score is: the usage frequency of the payment method multiplied by a preset weight coefficient. Among them, the usage frequency of the payment method is the result statistically obtained in step S104, reflecting the actual usage situation of the user for this payment method. The preset weight coefficient is a constant set by the pharmacy according to business requirements and experience, and is used to adjust the importance of different payment methods in the recommendation algorithm. For example, the pharmacy believes that medical insurance payment is the most important for users, so the weight coefficient of medical insurance payment is set to 1.5, while the weight coefficients of other payment methods are set to 1.

[0051] Next, the server accumulates the weight scores of each payment method in the candidate payment combinations to obtain the combined score of the candidate payment combination. The combined score reflects the matching degree between the payment combination and the user's payment preference. The higher the score, the more in line with the user's actual needs and habits the payment combination is. For example, for the candidate payment combination "medical insurance payment + bank card payment", user Xiao Wang's usage frequency of medical insurance payment is 25%, and the usage frequency of bank card payment is 40%. Assuming the weight coefficients are 1.5 and 1 respectively, the combined score of this payment combination is: 25%×1.5 + 40%×1 = 77.5%.

[0052] Finally, the server sorts all candidate payment combinations according to the combined scores to obtain the sorting result. The server sorts the candidate payment combinations in descending order according to the combined scores. The payment combination with the highest score is ranked at the top as the optimal recommendation scheme. For example, the server calculates the combined scores of the following three candidate payment combinations: medical insurance payment + bank card payment: 77.5%; bank card payment + cash payment: 45%; medical insurance payment + mobile payment: 70%. After sorting from high to low, the payment schemes recommended to user Xiao Wang are: medical insurance payment + bank card payment, medical insurance payment + mobile payment, bank card payment + cash payment.

[0053] Step S105: In the preset payment recommendation model, use the user profile and payment preference as inputs to match the candidate payment scheme library, which includes multiple candidate payment combinations.

[0054] In step S105, the server uses the preset payment recommendation model, takes the user profile and payment preference as inputs, and matches the most suitable payment combination for the user from the candidate payment scheme library. The purpose of this step is to intelligently recommend payment methods that meet the user's needs and habits based on the user's personal characteristics and historical behaviors, and improve the convenience and satisfaction of payment.

[0055] First, the server loads the preset payment recommendation model. The preset payment recommendation model is a machine learning model pre-trained by the pharmacy based on historical data and business experience for matching user characteristics with payment schemes. The server takes the user profile generated in step S103 and the payment preference statistically analyzed in step S104 as input features and passes them to the preset payment recommendation model. The user profile is a comprehensive description of the user's basic attributes, consumption behaviors, health conditions, etc., reflecting the user's personal characteristics and demand preferences. The payment preference is the statistical usage frequency of various payment methods by the user during historical drug purchases, reflecting the user's payment habits and selection tendencies. The server organizes and encodes these two types of information according to the input format of the model to form a structured feature vector for the preset payment recommendation model to process and analyze.

[0056] Next, the server uses a preset payment recommendation model to match the user feature vector with the candidate payment plan library and calculates the matching score for each candidate payment combination. The candidate payment plan library is a set of commonly used payment combinations pre-configured by the pharmacy, such as "medical insurance payment + out-of-pocket payment", "bank card payment + points deduction", etc., covering various common payment scenarios and user needs. The server also encodes each payment combination in the candidate payment plan library as a feature vector, and through the calculation layer and activation function of the model, obtains the similarity or matching score with the user feature vector. The higher the score, the more in line the payment combination is with the user's preferences and needs.

[0057] For example, for user Xiao Wang, his user profile shows: male, 35 years old, a chronic disease patient, seeking medical advice and purchasing medicine every month, with a medicine expense budget of 2,000 yuan, and commonly using medical insurance cards and credit cards for payment. The server inputs Xiao Wang's feature vector into the preset payment recommendation model and obtains the scores of the following payment combinations in the candidate payment plan library: medical insurance payment + out-of-pocket payment: 0.8; medical insurance payment + credit card installment: 0.7; medical insurance payment + medical insurance account payment: 0.6; credit card payment + points deduction: 0.5.

[0058] It can be seen that the matching scores of "medical insurance payment + out-of-pocket payment" and "medical insurance payment + credit card installment" are the highest, indicating that these two payment combinations most conform to Xiao Wang's actual situation and payment preferences. The server uses these two payment combinations as candidate recommendation results for further screening and ranking in subsequent steps.

[0059] In a possible implementation manner, before step S105, the method further includes: obtaining the user profile features, payment preference features, and payment result labels of historical users to form a training data set; using the user profile features and payment preference features as inputs, converting the user profile features into user profile feature vectors through an embedding layer, and converting the payment preference features into payment preference feature vectors; splicing the user profile feature vectors and payment preference feature vectors, and performing feature transformation and combination through multiple fully connected layers; in the last fully connected layer, scoring each candidate payment combination to obtain the recommendation probability of each candidate payment combination, and obtaining the preset payment recommendation model.

[0060] Specifically, before the server executes step S105, it needs to first construct and train a preset payment recommendation model. First, the server obtains a certain amount of historical user data from the pharmacy database or the log system as the training dataset. Each piece of historical user data includes three parts: user portrait features, payment preference features, and payment result labels. Among them, user portrait features describe aspects such as the user's demographic attributes, health status, and consumption behavior, such as age, gender, home address, disease types, and pharmacy purchase frequency; payment preference features are statistics of the user's historical payment behavior, such as the usage frequency of each payment method and the payment amount distribution; the payment result label is the payment combination used by the user during the actual pharmacy purchase process, such as "medical insurance payment + out-of-pocket payment", "bank card payment + points deduction", etc. The server integrates these three types of data to form a structured training sample.

[0061] Then, the server uses the embedding layer to transform and encode the user portrait features and payment preference features. The embedding layer is a commonly used feature learning technique that can map high-dimensional sparse categorical features into low-dimensional dense real-valued vectors while preserving the semantic relationships between features. The server trains an embedding matrix for each user portrait feature and payment preference feature respectively, and through look-up table and multiplication operations, converts them into fixed-length user portrait feature vectors and payment preference feature vectors. For example, for the user portrait feature "age", the server encodes it as a 1×n one-hot vector, and then multiplies it by the k×n embedding matrix to obtain a 1×k user portrait feature vector, where n is the number of age values and k is the dimension of the embedding vector.

[0062] Next, the server concatenates the user portrait feature vector and the payment preference feature vector to form a user comprehensive feature vector with a length of 2k. Then, the server uses multiple fully connected layers to perform non-linear transformation and high-level feature combination on the user comprehensive feature vector. The fully connected layer is a basic neural network structure that maps the input features to another feature space through matrix multiplication and activation functions to extract more abstract and high-level feature representations. The server designs multiple cascaded fully connected layers according to actual requirements and data scale, and uses activation functions such as ReLU and Sigmoid to continuously enhance the feature expression ability and classification ability.

[0063] Finally, at the last fully-connected layer, the server scores each candidate payment combination in the candidate payment solution library to obtain the recommended probability of each candidate payment combination. The recommended probability reflects the likelihood that the current user will use this payment combination. The higher the probability, the more suitable the payment combination is for the characteristics and preferences of the current user. The server uses the Softmax function to normalize the output of the last fully-connected layer into a probability distribution. Each candidate payment combination corresponds to a probability value, and the sum of all probability values is 1. In this way, the server establishes a mapping relationship between user characteristics and payment combinations, forming the basic structure of the preset payment recommendation model.

[0064] Step S106: Obtain the user's current drug purchase list and the balance of the medical insurance account corresponding to the medical insurance card number.

[0065] In step S106, the server obtains the user's current drug purchase list from the pharmacy management system. When the user completes the selection of drugs in the online store or offline counter of the pharmacy, the pharmacy management system will generate a drug purchase list, recording information such as the name, quantity, unit price, and amount of the drugs purchased by the user. The server reads the latest drug purchase list of this user from the pharmacy management system through the API interface or database query, and obtains the total amount and details of the drug expenses that the user currently needs to pay. For example, user Xiao Wang purchased the following drugs in the pharmacy: enteric-coated aspirin tablets, 3 boxes, 24.5 yuan per box, a total of 73.5 yuan; nifedipine sustained-release tablets, 2 boxes, 67 yuan per box, a total of 134 yuan; vitamin C tablets, 1 bottle, 52 yuan. The server obtains Xiao Wang's drug purchase list from the pharmacy management system and calculates that the total amount of this drug purchase is 259.5 yuan.

[0066] Then, the server obtains the balance information of the user's medical insurance account according to the medical insurance card number provided by the user. The medical insurance account refers to the personal account established by the user in the medical insurance settlement system, which is used to record the payment, use, and balance of the user's medical insurance fund. The server docks with the medical insurance settlement system, passes in the user's medical insurance card number, and queries the balance information of this account. The medical insurance settlement systems in different regions may have different interface specifications and security mechanisms. The server selects a suitable docking method according to the actual situation, such as API call, database connection, encrypted transmission, etc. The server extracts the current available balance of the user's medical insurance account from the return result of the medical insurance settlement system. For example, after querying, the balance of user Xiao Wang's medical insurance account is 1500 yuan.

[0067] It should be noted that since the medical insurance account information belongs to the user's sensitive personal data, the server needs to strictly comply with relevant laws, regulations and security specifications during the acquisition and processing, such as the "Cybersecurity Law", the "Personal Information Protection Law", etc. The server needs to desensitize the medical insurance card number, use encrypted transmission and storage to prevent information leakage and tampering. At the same time, the server also needs to judge the user's authorization and consent situation. Only when the user clearly consents can the medical insurance account information be queried and used. The server can pop up an authorization prompt when the user logs in or purchases medicine, allowing the user to choose whether to allow the acquisition of the medical insurance account balance.

[0068] Step S107: Determine the target payment combination from multiple candidate payment combinations based on the current medicine purchase list and the medical insurance account balance.

[0069] In step S107, determining the target payment combination from multiple candidate payment combinations based on the current medicine purchase list and the medical insurance account balance specifically includes: extracting the medicine information in the current medicine purchase list, where the medicine information includes the medicine name, medicine unit price, and medicine quantity of each medicine, and calculating the total payable amount; judging whether each medicine in the medicine purchase list belongs to the medical insurance catalog medicine and marking the medicine category label; according to the medicine category label and the medical insurance payment policy, calculating the amount allowed to be reimbursed by medical insurance for each medicine, and accumulating to obtain the total amount allowed to be reimbursed by medical insurance; subtracting the total amount allowed to be reimbursed by medical insurance from the total payable amount to obtain the out-of-pocket amount; screening the sorting result according to the out-of-pocket amount, eliminating the candidate payment combinations that do not include medical insurance payment to obtain the target sorting result; taking the candidate payment combination ranked first in the target sorting result as the target payment combination.

[0070] Specifically, the server extracts the detailed information of each medicine from the user's current medicine purchase list obtained in step S106, including the medicine name, medicine unit price, and purchase quantity. The server parses and structures the medicine purchase list, converting the medicine information into a standardized data format for convenient subsequent calculation and processing. For example, for the medicine purchase list of user Xiao Wang, the server extracts the following medicine information: Enteric-coated Aspirin Tablets, 3 boxes, 24.5 yuan per box; Nifedipine Sustained Release Tablets, 2 boxes, 67 yuan per box; Vitamin C Tablets, 1 bottle, 52 yuan. The server calculates the total amount of each medicine according to the medicine unit price and quantity, and then accumulates to obtain the total payable amount for this medicine purchase. For Xiao Wang's medicine purchase list, the total payable amount is 259.5 yuan.

[0071] Then, the server determines whether each drug in the drug purchase list belongs to the drugs covered by the medical insurance catalog and labels them. The medical insurance catalog is a list of drugs that can be paid for with medical insurance funds announced by the national or local medical insurance departments, including Class A drugs and Class B drugs. The server matches with the medical insurance drug catalog database to label each drug with a category label of "Class A", "Class B" or "self-pay". For example, after querying, enteric-coated aspirin tablets and slow-release nifedipine tablets belong to Class A medical insurance drugs, and vitamin C tablets belong to self-pay drugs.

[0072] Next, the server calculates the reimbursable amount for each drug according to the drug category label and the medical insurance payment policy. Different categories of drugs have different reimbursement ratios. Class A drugs are usually fully reimbursed, Class B drugs have a reimbursement ratio between 70-90%, and self-pay drugs are not reimbursed. The server refers to the medical insurance payment policy rules, calculates the reimbursement amount for each drug, and accumulates to get the total amount reimbursed by medical insurance. For example, according to the drug category and quantity purchased by Xiao Wang, the amount reimbursed by medical insurance is: enteric-coated aspirin tablets, 3 boxes, 24.5 yuan per box, a total of 73.5 yuan, fully reimbursed 73.5 yuan; slow-release nifedipine tablets, 2 boxes, 67 yuan per box, a total of 134 yuan, fully reimbursed 134 yuan; vitamin C tablets, 1 bottle, 52 yuan, self-pay not reimbursed; the total amount reimbursed by medical insurance is 207.5 yuan.

[0073] Then, the server subtracts the total amount reimbursed by medical insurance from the total amount payable to get the amount that the user actually needs to pay out of their own pocket. For Xiao Wang's drug purchase list, the out-of-pocket amount is 259.5 yuan - 207.5 yuan = 52 yuan.

[0074] The server filters the sorting results of the candidate payment combinations according to the calculated out-of-pocket amount. The server compares the out-of-pocket amount with the non-medical insurance payment amount of each candidate payment combination, and eliminates those candidate payment combinations that cannot meet the out-of-pocket payment requirements or do not include medical insurance payments, to obtain a more refined and matching target sorting result. For example, for Xiao Wang's out-of-pocket amount of 52 yuan, the server finds that the non-medical insurance payment amount of some candidate payment combinations is less than 52 yuan or some candidate payment combinations do not include medical insurance payments and cannot meet the payment requirements, so they are excluded from the sorting results.

[0075] Finally, the server takes the candidate payment combination ranked first in the target sorting result as the final target payment combination and recommends it to the user for payment. The target payment combination not only meets the user's payment needs but also maximally utilizes the medical insurance reimbursement policy, saving the user's out-of-pocket expenses. It is the optimal payment solution under the current circumstances. For example, for Xiao Wang's drug purchase list, the target payment combination recommended by the server is "Medical insurance payment of 207.5 yuan + Bank card payment of 52 yuan", which fully utilizes the medical insurance reimbursement and pays the remaining out-of-pocket part through bank card payment, being the most cost-effective payment method.

[0076] In a possible implementation manner, after step S107, the method further includes: obtaining the confirmation information of the user for the target payment combination; if the confirmation information indicates that the user accepts the target payment combination, sending the payment amounts corresponding to the respective payment methods in the target payment combination to the payment terminal; if the confirmation information indicates that the user rejects the target payment combination, obtaining the payment combination selected by the user and sending the payment amounts corresponding to the respective payment methods in the payment combination selected by the user to the payment terminal.

[0077] Specifically, the server presents the target payment combination recommended in step S107 to the user and obtains the confirmation information of the user. The server shows the detailed information of the target payment combination, including payment methods, payment amounts, preferential discounts, etc., to the user through front-end interfaces such as mobile apps, WeChat mini-programs, and web pages. At the same time, the server also provides two operation buttons, "Confirm payment" and "Modify payment", for the user to choose. For example, the target payment combination recommended by the server to user Xiao Wang is "Medical insurance payment of 207.5 yuan + Bank card payment of 52 yuan", and the following information is displayed on the payment confirmation page of the app: Total amount payable: 259.5 yuan, Medical insurance payment amount: 207.5 yuan, Bank card payment amount: 52 yuan. The user can carefully view the payment details and click the button to confirm or modify.

[0078] If the user clicks the "Confirm payment" button, indicating acceptance of the target payment combination recommended by the server, the server sends the payment amounts corresponding to the respective payment methods in the target payment combination to the payment terminal for deduction. The payment terminal refers to a payment device or system connected to banks and third-party payment platforms, such as POS machines, payment gateways, etc. The server passes the payment instructions and amount parameters to the payment terminal through API interfaces or message queues to trigger the corresponding payment operations. For example, the server sends Xiao Wang's payment instructions to the payment gateway of the bank, notifying the bank to deduct 207.5 yuan from Xiao Wang's medical insurance account and 52 yuan from the bank card bound by Xiao Wang. After the payment terminal executes the deduction operation, it returns the payment result to the server, and the server then notifies the user that the payment is successful, completing the entire payment process.

[0079] If the user clicks the "Modify Payment" button, it means that the user rejects the target payment combination recommended by the server and hopes to select other payment methods by themselves. Then the server provides a payment method selection interface for the user to recombine the payment methods and amounts. The payment method selection interface lists all the payment methods supported by the pharmacy, such as medical insurance payment, bank card payment, WeChat payment, Alipay payment, etc., and allows the user to enter the payment amount corresponding to each payment method. For example, Xiao Wang selects the following payment combination on the modify payment interface: Medical insurance payment: 200 yuan, WeChat payment: 59.5 yuan.

[0080] The server calculates the total payment amount entered by the user in real time and compares it with the total amount payable to ensure the accuracy of the payment amount. After the user confirms that it is correct, the user clicks the "Pay Now" button, and the server sends the payment amounts corresponding to the payment methods selected by the user to the payment terminal to perform the deduction operation and complete the payment process.

[0081] Referring to Figure 2 , the present application also provides a pharmacy intelligent payment recommendation device based on user portraits. The device is a server, and the server includes an acquisition module 201 and a processing module 202, where: The acquisition module 201 is used to acquire the user's medical insurance card number; The processing module 202 is used to extract the user's basic information and historical pharmacy purchase records from the pharmacy database according to the medical insurance card number; The processing module 202 is also used to analyze the user's basic information and historical pharmacy purchase records by using a clustering algorithm to obtain the user's pharmacy purchase habits, and construct the user's user portrait according to the pharmacy purchase habits; The processing module 202 is also used to count the user's payment preferences according to the historical pharmacy purchase records, and the payment preferences include the user's usage frequency of each payment method; The processing module 202 is also used to use the user portrait and payment preferences as inputs in a preset payment recommendation model to match a candidate payment plan library, and the candidate payment plan library includes multiple candidate payment combinations; The acquisition module 201 is also used to acquire the user's current pharmacy purchase list and the medical insurance account balance corresponding to the medical insurance card number; The processing module 202 is also used to determine a target payment combination from multiple candidate payment combinations based on the current pharmacy purchase list and the medical insurance account balance.

[0082] In a possible implementation, the processing module 202 analyzes the user's basic information and historical drug purchase records using a clustering algorithm to obtain the user's drug purchase habits, and constructs a user profile based on the drug purchase habits, specifically including: the processing module 202 extracts features from the user's basic information to obtain a user basic feature vector; wherein, the user's basic information includes age, gender, and home address; the processing module 202 extracts features from the user's historical drug purchase records to obtain a user drug purchase feature vector; wherein, the user's historical drug purchase records include drug purchase time, drug purchase frequency, drug category, and drug quantity; the processing module 202 inputs the user basic feature vector and the user drug purchase feature vector into a preset clustering model to obtain a clustering result of the user's drug purchase habits; wherein, the clustering model is trained using the K-means clustering algorithm; the processing module 202 matches the corresponding user profile template from a preset user profile template library according to the clustering result of the drug purchase habits, and generates a user profile based on the user profile template.

[0083] In a possible implementation, the processing module 202 statistically analyzes the user's payment preferences based on the historical drug purchase records. The payment preferences include the usage frequency of each payment method by the user, specifically including: the acquisition module 201 acquires the payment method field in the historical drug purchase records, and performs category labeling on each payment method according to the payment method field to obtain a payment method category label. The payment method category label includes medical insurance payment, bank card payment, mobile payment, and cash payment; the processing module 202 counts the number of each payment method category label, and calculates the proportion of the number of each payment method category label in the total number of records, and uses the proportion as the usage frequency of each payment method by the user.

[0084] In a possible implementation, after the processing module 202 statistically analyzes the user's payment preferences based on the historical drug purchase records, the method further includes: the acquisition module 201 acquires the payment methods included in each candidate payment combination in the candidate payment plan library; the processing module 202 calculates the weight score of each payment method in the candidate payment combination. The weight score is equal to the usage frequency of the payment method multiplied by a preset weight coefficient; the processing module 202 accumulates the weight scores of each payment method in the candidate payment combination to obtain a combined score of the candidate payment combination; the processing module 202 sorts the candidate payment combinations from largest to smallest according to the combined score to obtain a sorting result.

[0085] In a possible implementation, the processing module 202 determines a target payment combination from multiple candidate payment combinations based on the current drug purchase list and the balance of the medical insurance account. Specifically, the processing module 202 extracts the drug information in the current drug purchase list. The drug information includes the drug name, drug unit price, and drug quantity of each drug, and calculates the total payable amount. The processing module 202 determines whether each drug in the drug purchase list belongs to the drugs in the medical insurance catalog and labels the drug category label. The processing module 202 calculates the amount that can be reimbursed by medical insurance for each drug according to the drug category label and the medical insurance payment policy, and accumulates to obtain the total amount that can be reimbursed by medical insurance. The processing module 202 subtracts the total amount that can be reimbursed by medical insurance from the total payable amount to obtain the out-of-pocket amount. According to the out-of-pocket amount, the sorting result is screened, and the candidate payment combinations that do not include medical insurance payment are excluded to obtain the target sorting result. The processing module 202 uses the candidate payment combination ranked first in the target sorting result as the target payment combination.

[0086] In a possible implementation, before the processing module 202 uses the user profile and payment preference as inputs in the preset payment recommendation model to match the candidate payment scheme library, the method further includes: the acquisition module 201 acquires the user profile features, payment preference features, and payment result labels of historical users to form a training data set. The processing module 202 uses the user profile features and payment preference features as inputs, converts the user profile features into user profile feature vectors through an embedding layer, and converts the payment preference features into payment preference feature vectors. The processing module 202 splices the user profile feature vector and the payment preference feature vector, and performs feature transformation and combination through multiple fully connected layers. The processing module 202 scores each candidate payment combination in the last fully connected layer to obtain the recommendation probability of each candidate payment combination, and obtains the preset payment recommendation model.

[0087] In a possible implementation, after the processing module 202 determines a target payment combination from multiple candidate payment combinations based on the current drug purchase list and the balance of the medical insurance account, the method further includes: the acquisition module 201 acquires the confirmation information of the user for the target payment combination. If the confirmation information indicates that the user accepts the target payment combination, the processing module 202 sends the payment amounts corresponding to the respective payment methods in the target payment combination to the payment terminal. If the confirmation information indicates that the user rejects the target payment combination, the processing module 202 acquires the payment combination selected by the user, and sends the payment amounts corresponding to the respective payment methods in the payment combination selected by the user to the payment terminal.

[0088] It should be noted that: when the device provided in the above embodiment realizes its functions, only the division of the above function modules is used for illustration. In actual applications, the above functions can be allocated to different function modules according to needs, that is, the internal structure of the device is divided into different function modules to complete all or part of the functions described above. In addition, the device and method embodiments provided in the above embodiment belong to the same concept. For the specific implementation process, please refer to the method embodiment, which will not be elaborated here.

[0089] This application also provides an electronic device. Referring to Figure 3 , Figure 3 FIG. is a schematic structural diagram of an electronic device provided in an embodiment of this application. The electronic device 300 may include: at least one processor 301, at least one network interface 304, a user interface 303, a memory 305, and at least one communication bus 302.

[0090] Among them, the communication bus 302 is used to realize the connection and communication between these components.

[0091] Among them, the user interface 303 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 303 may further include a standard wired interface and a wireless interface.

[0092] Among them, the network interface 304 may optionally include a standard wired interface and a wireless interface (such as a Wi-Fi interface).

[0093] Among them, the processor 301 may include one or more processing cores. The processor 301 connects various parts within the entire server through various interfaces and lines. By running or executing instructions, programs, code sets, or instruction sets stored in the memory 305, and by invoking the data stored in the memory 305, it executes various functions of the server and processes data. Optionally, the processor 301 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 301 may integrate a combination of one or several of a central processing unit (CPU), a graphics processing unit (GPU), and a modem, etc. Among them, the CPU mainly processes the operating system, user interface, application programs, etc.; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 301 and may be implemented separately by a single chip.

[0094] Among them, the memory 305 may include random access memory (RAM) and may also include read-only memory. Optionally, the memory 305 includes a non-transitory computer-readable storage medium. The memory 305 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing the operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-mentioned method embodiments, etc.; the data storage area may store the data involved in the above-mentioned method embodiments. Optionally, the memory 305 may further be at least one storage device located far from the aforementioned processor 301. Referring to Figure 3 , as a computer storage medium, the memory 305 may include an operating system, a network communication module, a user interface module, and an application program for a pharmacy intelligent payment recommendation method based on user portraits.

[0095] In Figure 3In the electronic device 300 shown, the user interface 303 is mainly used to provide an interface for the user to input and obtain the data input by the user; and the processor 301 can be used to call an application program stored in the memory 305 for a pharmacy intelligent payment recommendation method based on user portraits. When executed by one or more processors 301, the electronic device 300 is caused to execute one or more of the methods as described in the above embodiments. It should be noted that for the foregoing method embodiments, for the sake of simple description, they are all expressed as a series of action combinations. However, those skilled in the art should know that the present application is not limited by the described action sequence, because according to the present application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should also know that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the present application.

[0096] The present application also provides a computer-readable storage medium storing instructions. When executed by one or more processors 301, the electronic device 300 is caused to execute one or more of the methods as described in the above embodiments.

[0097] In the above embodiments, the descriptions of the respective embodiments have their own emphases. For the parts not detailed in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0098] In several implementation manners provided by the present application, it should be understood that the disclosed device can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed couplings or direct couplings or communication connections to each other can be through some service interfaces. The indirect couplings or communication connections of the devices or units can be in electrical or other forms.

[0099] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0100] In addition, in each embodiment of the present application, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The above integrated units can be implemented in the form of hardware or in the form of software functional units.

[0101] When the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present application. The aforementioned memory includes various media that can store program codes, such as USB flash drives, mobile hard disks, magnetic disks, or optical discs.

[0102] The above are only exemplary embodiments of the present disclosure, and the scope of the present disclosure cannot be limited thereby. That is, any equivalent changes and modifications made in accordance with the teachings of the present disclosure still fall within the scope covered by the present disclosure. After considering the specification and the disclosure of the practical truth, those skilled in the art will easily think of other implementation manners of the present disclosure.

[0103] The present application aims to cover any variations, uses, or adaptive changes of the present disclosure. These variations, uses, or adaptive changes follow the general principles of the present disclosure and include well-known general knowledge or conventional technical means in the technical field not recorded in the present disclosure. The specification and the embodiments are only regarded as exemplary, and the scope and spirit of the present disclosure are defined by the claims.

Claims

1. A method for recommending intelligent payment for pharmacies based on user portraits, characterized in that: The method comprises: Get the user's medical insurance card number; According to the medical insurance card number, extract the user's basic information and historical drug purchase records from the pharmacy database; A clustering algorithm is used to analyze the basic information and historical drug purchase records of the user to obtain the drug purchase habits of the user, and a user profile of the user is constructed based on the drug purchase habits; According to the historical drug purchase records, the user's payment preferences are counted, and the payment preferences include the frequency of use of each payment method by the user; In a preset payment recommendation model, the user profile and the payment preference are used as inputs to match a candidate payment solution library, wherein the candidate payment solution library includes a plurality of candidate payment combinations; Obtain the user's current drug purchase list and the medical insurance account balance corresponding to the medical insurance card number; Based on the current drug purchase list and the balance of the medical insurance account, a target payment combination is determined from a plurality of candidate payment combinations.

2. The method according to claim 1, characterized in that The clustering algorithm is used to analyze the basic information and historical drug purchase records of the user to obtain the drug purchase habits of the user, and a user profile of the user is constructed based on the drug purchase habits, specifically including: Extracting features from the basic information of the user to obtain a basic feature vector of the user; wherein the basic information of the user includes age, gender and home address; Extracting features from the user's historical drug purchase records to obtain a user drug purchase feature vector; wherein the user's historical drug purchase records include drug purchase time, drug purchase frequency, drug category, and drug quantity; Inputting the user's basic feature vector and the user's drug purchasing feature vector into a preset clustering model to obtain a clustering result of the user's drug purchasing habits; wherein the preset clustering model is trained using a K-means clustering algorithm; According to the clustering result of the drug purchasing habits, a corresponding user portrait template is matched from a preset user portrait template library, and a user portrait of the user is generated based on the user portrait template.

3. The method according to claim 1, characterized in that The counting of the user's payment preference according to the historical drug purchase records specifically includes: Obtain the payment method field in the historical drug purchase record, and classify each payment method according to the payment method field to obtain a payment method category label, wherein the payment method category label includes medical insurance payment, bank card payment, mobile payment, and cash payment; The number of each payment method category label is counted, and the ratio of the number of each payment method category label to the total number of records is calculated, and the ratio is used as the frequency of use of each payment method by the user.

4. The method according to claim 1, characterized in that After calculating the user's payment preference according to the historical drug purchase records, the method further includes: Obtain the payment methods included in each candidate payment combination in the candidate payment solution library; Calculating a weight score of each payment method in the candidate payment combination, where the weight score is equal to the usage frequency of the payment method multiplied by a preset weight coefficient; Accumulating the weighted scores of the various payment methods in the candidate payment combination to obtain a combined score of the candidate payment combination; The candidate payment combinations are sorted from large to small according to the combination scores to obtain a sorting result.

5. The method according to claim 4, characterized in that The determining of a target payment combination from a plurality of candidate payment combinations based on the current drug purchase list and the balance of the medical insurance account specifically includes: Extracting drug information from the current drug purchase list, the drug information including the drug name, drug unit price and drug quantity of each drug, and calculating the total amount payable; Determine whether each drug in the current drug purchase list belongs to the medical insurance catalogue drug, and mark the drug category label; According to the drug category label and medical insurance payment policy, the amount of each drug allowed to be reimbursed by medical insurance is calculated, and the total amount allowed to be reimbursed by medical insurance is accumulated; Subtract the total amount of reimbursement allowed by medical insurance from the total amount payable to get the out-of-pocket amount; According to the self-paid amount, the ranking results are screened, and candidate payment combinations that do not include medical insurance payment are eliminated to obtain a target ranking result; The candidate payment combination ranked first in the target ranking result is used as the target payment combination.

6. The method according to claim 1, characterized in that In the preset payment recommendation model, before taking the user profile and the payment preference as input and matching the candidate payment solution library, the method further includes: Obtain user profile features, payment preference features, and payment result labels of historical users to form a training data set; Taking the user portrait feature and the payment preference feature as input, converting the user portrait feature into a user portrait feature vector through an embedding layer, and converting the payment preference feature into a payment preference feature vector; The user portrait feature vector and the payment preference feature vector are concatenated, and feature transformation and combination are performed through multiple fully connected layers; In the last fully connected layer, each candidate payment combination is scored to obtain the recommendation probability of each candidate payment combination, and the preset payment recommendation model is obtained.

7. The method according to claim 1, characterized in that After determining the target payment combination from the plurality of candidate payment combinations based on the current drug purchase list and the balance of the medical insurance account, the method further includes: Obtaining confirmation information of the user on the target payment combination; If the confirmation information indicates that the user accepts the target payment combination, the payment amount corresponding to each payment method in the target payment combination is sent to the payment terminal; If the confirmation information indicates that the user rejects the target payment combination, the payment combination selected by the user is obtained, and the payment amount corresponding to each payment method in the payment combination selected by the user is sent to the payment terminal.

8. A pharmacy intelligent payment recommendation device based on user portrait, characterized in that: The device comprises an acquisition module (201) and a processing module (202), wherein: The acquisition module (201) is used to acquire the user's medical insurance card number; The processing module (202) is used to extract the basic information and historical drug purchase records of the user from the drugstore database according to the medical insurance card number; The processing module (202) is further used to analyze the basic information and historical drug purchase records of the user using a clustering algorithm to obtain the drug purchase habits of the user, and to construct a user profile of the user based on the drug purchase habits; The processing module (202) is further used to collect statistics on the user's payment preferences based on the historical drug purchase records, wherein the payment preferences include the frequency of use of each payment method by the user; The processing module (202) is further configured to use the user profile and the payment preference as inputs in a preset payment recommendation model to match a candidate payment solution library, wherein the candidate payment solution library includes a plurality of candidate payment combinations; The acquisition module (201) is further used to acquire the user's current medicine purchase list and the medical insurance account balance corresponding to the medical insurance card number; The processing module (202) is further configured to determine a target payment combination from a plurality of candidate payment combinations based on the current drug purchase list and the balance of the medical insurance account.

9. An electronic device, characterized in that: The electronic device (300) comprises a processor (301), a memory (305), a user interface (303) and a network interface (304), wherein the memory (305) is used to store instructions, the user interface (303) and the network interface (304) are used to communicate with other devices, and the processor (301) is used to execute the instructions stored in the memory (305) so that the electronic device (300) executes the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions, and when the instructions are executed, the method according to any one of claims 1 to 7 is executed.

Images