CN112308552A - Ordering method and device for medical insurance medicines - Google Patents
Ordering method and device for medical insurance medicines Download PDFInfo
- Publication number
- CN112308552A CN112308552A CN202010603400.7A CN202010603400A CN112308552A CN 112308552 A CN112308552 A CN 112308552A CN 202010603400 A CN202010603400 A CN 202010603400A CN 112308552 A CN112308552 A CN 112308552A
- Authority
- CN
- China
- Prior art keywords
- medical insurance
- server
- request
- insurance card
- settlement
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
- G06Q20/3415—Cards acting autonomously as pay-media
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
- G06Q30/0635—Processing of requisition or of purchase orders
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
Abstract
The embodiment of the application discloses a method and a device for ordering medical insurance medicines. One embodiment of the method comprises: in response to receiving a settlement request for a medical insurance drug, determining whether a user account from which the settlement request originates is bound with a medical insurance card; if so, sending a pre-settlement request to the first server, and receiving a pre-settlement result returned by the first server, wherein the pre-settlement request comprises medical insurance card information, the medical insurance card information comprises a medical insurance area to which a medical insurance card of the user indicated by the user account belongs, and the pre-settlement result comprises a medical insurance reimbursement amount and an individual payment amount; pushing a placing page comprising the medical insurance reimbursement amount and the personal payment amount to a user terminal from which the settlement request comes; in response to receiving an order submitting request returned by the user terminal, sending an order placing request to the first server, and receiving an order placing result returned by the first server. This embodiment allows the user to place orders for medical insurance drugs on-line.
Description
Technical Field
The embodiment of the application relates to the technical field of computers, in particular to a method and a device for ordering medical insurance medicines.
Background
Medical insurance refers to social medical insurance. The social medical insurance is a social insurance system established by the nation and the society according to certain laws and regulations for providing the workers in the guarantee range with basic medical requirements in illness. The basic medical insurance fund is composed of a pool fund and an individual account. In the existing medical insurance bureau system, independent medical insurance systems are independently set up by each medical insurance bureau, the information of the medical insurance systems is isolated and not unified, if the medical insurance systems need to be accessed to an e-commerce platform, the medical insurance systems in each grade city need to be independently developed, and the interface definitions need to be independently configured and data transcoding is carried out.
Disclosure of Invention
The embodiment of the application provides a method and a device for ordering medical insurance medicines.
In a first aspect, an embodiment of the present application provides a method for ordering a medical insurance drug, including: in response to receiving a settlement request for a medical insurance drug, determining whether a user account from which the settlement request originates is bound with a medical insurance card; if so, sending a pre-settlement request to a first server, and receiving a pre-settlement result returned by the first server, wherein the pre-settlement request comprises medical insurance card information, the medical insurance card information comprises a medical insurance area to which a medical insurance card of a user indicated by a user account belongs, the first server is used for processing a settlement request aiming at medical insurance medicines in the medical insurance area, and the pre-settlement result comprises a medical insurance reimbursement amount and a personal payment amount; pushing a placing page comprising the medical insurance reimbursement amount and the personal payment amount to a user terminal from which the settlement request comes; in response to receiving an order submitting request returned by the user terminal, sending an order placing request to the first server, and receiving an order placing result returned by the first server.
In some embodiments, after determining whether the user account from which the settlement request originates is bound to the medical insurance card, the method further comprises: if not, pushing a medical insurance card binding page to the user terminal, and receiving a binding application including medical insurance card information returned by the user terminal; sending a binding request including the received medical insurance card information to a second server, and receiving a binding result returned by the second server, wherein the second server is used for processing the binding request; and if the binding result represents that the medical insurance card is successfully bound, binding the user account with the medical insurance card information.
In some embodiments, the method further comprises: sending a refund request to a first server in response to receiving a refund application sent by a user terminal, wherein the refund request comprises a user account and order placing information corresponding to a drug to be refunded; receiving a refund result returned by the first server; and if the refund result represents that the refund is successful, pushing prompt information for representing that the refund is successful to the user terminal.
In some embodiments, the method further comprises: sending a balance inquiry request to a first server in response to receiving an inquiry application which is sent by a user terminal and used for inquiring the balance of the medical insurance card, wherein the balance inquiry request comprises a user account; receiving the balance of the medical insurance card returned by the first server; and pushing the balance of the medical insurance card to the user terminal.
In some embodiments, the method further comprises: and selecting a target order from the candidate orders for pushing by using the order query condition in response to receiving the order query request comprising the order query condition.
In a second aspect, an embodiment of the present application provides an ordering device for a medical insurance medicine, including: a determination unit configured to determine, in response to receiving a settlement request for a medical insurance drug, whether a user account from which the settlement request originates is bound with a medical insurance card; the first receiving unit is configured to send a pre-settlement request to a first server and receive a pre-settlement result returned by the first server if a user account from which the settlement request originates is bound with a medical insurance card, wherein the pre-settlement request comprises medical insurance card information, the medical insurance card information comprises a medical insurance area to which the medical insurance card of the user indicated by the user account belongs, the first server is used for processing the settlement request aiming at medical insurance medicines in the medical insurance area, and the pre-settlement result comprises a medical insurance reimbursement amount and a personal payment amount; a first pushing unit configured to push a placing page including a medical insurance reimbursement amount and a personal payment amount to a user terminal from which the settlement request is originated; and the second receiving unit is configured to respond to the order submitting request returned by the user terminal, send the order placing request to the first server and receive the order placing result returned by the first server.
In some embodiments, the apparatus further comprises: the third receiving unit is configured to push a medical insurance card binding page to the user terminal and receive a binding application including medical insurance card information returned by the user terminal if the user account from which the settlement request originates is not bound with the medical insurance card; the fourth receiving unit is configured to send a binding request including the received medical insurance card information to the second server, and receive a binding result returned by the second server, wherein the second server is used for processing the binding request; and the binding unit is configured to bind the user account with the medical insurance card information if the binding result represents that the medical insurance card is successfully bound.
In some embodiments, the apparatus further comprises: the system comprises a first sending unit, a first server and a second sending unit, wherein the first sending unit is configured to send a refund request to the first server in response to receiving a refund application sent by a user terminal, and the refund request comprises a user account and ordering information corresponding to a drug to be refunded; a fifth receiving unit configured to receive a refund result returned by the first server; and the second pushing unit is configured to push prompt information for representing the successful refund to the user terminal if the refund result represents the successful refund.
In a third aspect, an embodiment of the present application provides an electronic device, including: one or more processors; a storage device, on which one or more programs are stored, which, when executed by the one or more processors, cause the one or more processors to implement the method as described in any implementation manner of the first aspect.
In a fourth aspect, the present application provides a computer-readable medium, on which a computer program is stored, where the computer program, when executed by a processor, implements the method as described in any implementation manner of the first aspect.
According to the method and the device for ordering the medical insurance medicine, provided by the embodiment of the application, whether a user account from which a settlement request comes is bound with a medical insurance card is determined by responding to the received settlement request aiming at the medical insurance medicine; if the user account from which the settlement request comes is bound with the medical insurance card, sending a pre-settlement request to a first server, and receiving a pre-settlement result returned by the first server; then, pushing a placing page comprising the medical insurance reimbursement amount and the personal payment amount to a user terminal from which the settlement request comes; and finally, responding to the received order submitting request returned by the user terminal, sending an order placing request to the first server, and receiving an order placing result returned by the first server. The E-commerce platform can be connected to medical insurance systems of various places in the mode, and the data format and the butt joint mode can be unified, so that a user can place orders on medical insurance medicines on line.
Drawings
Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:
FIG. 1 is an exemplary system architecture diagram in which various embodiments of the present application may be applied;
FIG. 2 is a flow chart of one embodiment of a method for ordering a medical insurance product according to the present application;
FIG. 3 is a timing diagram of one embodiment of a method of ordering a medicare product according to the application;
FIG. 4 is a flow chart of yet another embodiment of a method of ordering a medical insurance product according to the present application;
FIG. 5 is a schematic diagram of one embodiment of an ordering device for medicare medications according to the present application;
FIG. 6 is a schematic block diagram of a computer system suitable for use in implementing an electronic device according to embodiments of the present application.
Detailed Description
The present application will be described in further detail with reference to the following drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings.
It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.
Fig. 1 illustrates an exemplary system architecture 100 to which embodiments of the method of ordering of medicare drugs of the present application may be applied.
As shown in fig. 1, the system architecture 100 may include user terminals 1011, 1012, networks 1021, 1022, 1023, a ordering server 103, a first server 104 and a second server 105. The network 1021 is the medium used to provide the communication link between the user terminals 1011, 1012 and the ordering server 103. Network 1022 is the medium used to provide a communication link between order server 103 and first server 104. Network 1023 is the medium used to provide a communication link between order server 103 and second server 105. Networks 1021, 1022, 1023 can include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
The user terminals 1011, 1012 may interact with the ordering server 103 via the network 1021 to send or receive messages (e.g., the ordering server 103 may receive a request for settlement of a medical insurance drug sent by the user terminals 1011, 1012, and the ordering server 103 may also send an ordering page to the user terminals 1011, 1012). Various communication client applications, such as shopping applications, medical health applications, instant messaging software, and the like, may be installed on the user terminals 1011, 1012.
The user terminals 1011, 1012 may be hardware or software. When the user terminals 1011, 1012 are hardware, they may be various electronic devices that support information interaction, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like. When the user terminals 1011, 1012 are software, they may be installed in the electronic devices listed above. It may be implemented as multiple pieces of software or software modules, or as a single piece of software or software module. And is not particularly limited herein.
The second server 105 may interact with the ordering server 103 through the network 1023 to send or receive messages (the ordering server 103 may send a binding request to the second server 105, and the ordering server 103 may also receive a binding result returned by the second server 105).
The first server 104 and the second server 105 may be hardware or software. When the first server 104 and the second server 105 are hardware, they may be various electronic devices supporting information interaction, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like. When the first server 104 and the second server 105 are software, they may be installed in the electronic devices listed above. It may be implemented as multiple pieces of software or software modules, or as a single piece of software or software module. And is not particularly limited herein.
The ordering server 103 may be a server that provides various services. For example, it may be a back-office server that analyzes settlement requests for medical insurance drugs. In response to the receipt server 103 receiving a settlement request for a medical insurance drug sent by the user terminal 1011, 1012, it may be determined whether a user account from which the settlement request originates is bound with a medical insurance card; if the user account from which the settlement request originates is bound with the medical insurance card, a settlement advance request can be sent to the first server 104, and a settlement advance result returned by the first server 104 is received; then, a ordering page comprising the medical insurance reimbursement amount and the personal payment amount can be pushed to the user terminals 1011 and 1012; finally, in response to receiving the order submission request returned by the user terminal 1011, 1012, an order placing request may be sent to the first server 104, and an order placing result returned by the first server 104 may be received.
Note that the order issuing server 103 may be hardware or software. When the ordering server 103 is hardware, it may be implemented as a distributed server cluster composed of a plurality of servers, or may be implemented as a single server. When the ordering server 103 is software, it may be implemented as a plurality of software or software modules (for example, to provide distributed services), or may be implemented as a single software or software module. And is not particularly limited herein.
It should be noted that the order placing method for the medical insurance medicines provided in the embodiment of the present application is generally executed by the order placing server 103.
It should be understood that the number of user terminals, networks, ordering servers, first servers and second servers in fig. 1 are merely illustrative. There may be any number of user terminals, networks, ordering servers, first servers, and second servers, as desired for an implementation.
With continued reference to FIG. 2, a flow 200 of one embodiment of a method for ordering a medicare medication according to the present application is shown. The ordering method of the medical insurance medicine comprises the following steps:
In this embodiment, an executing agent (e.g., the ordering server shown in fig. 1) of the ordering method of the medical insurance drug may determine whether a settlement request for the medical insurance drug is received. The medical insurance drugs generally refer to basic medical insurance drugs, and the specific scope can be managed by establishing 'the catalog of the basic medical insurance drugs'. After the user clicks the "settle" icon in the purchase page of the medicare, the executive body may receive a request for a settlement for the medicare. Then, the executing body can determine whether the user account from which the settlement request originates is bound with the medical insurance card. If it is determined that the user account from which the settlement request originates is bound to the medical insurance card, the executing entity may perform step 202.
In this embodiment, if it is determined in step 201 that the user account from which the settlement request originates is bound to the medical insurance card, the executing entity may send the pre-settlement request to the first server. Herein, pre-settlement generally refers to a pre-estimation of the price of a medical insurance drug purchased by a user. The pre-settlement request may include medical insurance card information, and the medical insurance card information may include a medical insurance area to which a medical insurance card of the user indicated by the user account belongs, where the medical insurance area may be a city-level area. The first server is generally configured to process a request for settlement of medical insurance drugs for the medical insurance area. The first server is usually operated with a local medical insurance system corresponding to the medical insurance area. The first server may process the settlement request using the local medical insurance system.
Here, the pre-settlement request may further include drug information, and the drug information may include drug identification, drug price, drug quantity, drug manufacturer, and drug formulation. And after receiving the pre-settlement request, the first server can acquire the medical insurance reimbursement amount corresponding to the medicine identifier. Thereafter, the difference between the price of the medication and the medical insurance reimbursement amount may be determined as the personal payment amount. A pre-settlement result including the medical insurance reimbursement amount and the personal payment amount may then be generated. The pre-settlement result may further include a medicine price, for example, the pre-settlement result may include a medicine price 32 yuan of the medical insurance medicine A, a medical insurance reimbursement amount of 10 yuan and a personal payment amount of 22 yuan.
Thereafter, the execution subject may receive a pre-settlement result returned by the first server.
In this embodiment, the execution agent may push a placing page including the medical insurance reimbursement amount and the personal payment amount to the user terminal from which the settlement request originates. After receiving the order-placing page, the user terminal can confirm the medical insurance reimbursement amount and the personal payment amount in the order-placing page, and then can send an order submitting request to the execution main body by clicking the order submitting icon in the order-placing page.
In this embodiment, the execution body may send an order placing request to the first server if receiving an order submitting request returned by the user terminal. After receiving the order placing request sent by the execution main body, the first server may obtain the balance in the medical insurance card bound by the user account, and then may determine whether the balance in the medical insurance card bound by the user account is greater than the medical insurance reimbursement amount. If the balance is larger than the medical insurance reimbursement amount, an order placing result used for representing the order placing success can be generated. If the balance is less than the medical insurance reimbursement amount, an order placing result for representing the order placing failure can be generated.
Then, the execution subject may receive a placing result returned by the first server. If the received ordering result represents that ordering is successful, the execution main body can push a page for representing that ordering is successful to the user terminal, and then, order information aiming at the medical insurance medicine can be sent to a warehouse terminal of an appointed warehouse, so that warehouse personnel complete subsequent medicine sorting, delivery and other processes. If the received ordering result represents that the ordering fails, the execution main body can push a page for representing the ordering failure to the user terminal.
The method provided by the embodiment of the application can access the E-commerce platform to various medical insurance systems, and can unify the data format and the docking mode, so that a user can place orders for medical insurance medicines on line.
In some optional implementation manners of this embodiment, the executing entity may determine whether a refund application sent by the user terminal is received. The execution body may send a refund request to the first server if receiving a refund application sent by the user terminal. The refund request may include the user account and ordering information corresponding to the drug to be refunded. The ordering information corresponding to the drug to be refunded may include, but is not limited to: the drug identification of the drug to be refunded, the number of the drugs, and the order placing time. The first server may determine whether the drug to be refunded meets a refund condition after receiving the refund request. As an example, the refund condition may include a purchase time not exceeding 15 days, the first server may determine a time difference between an order placing time of the drug to be refunded and a current time, and if the time difference does not exceed 15 days, a refund operation may be performed on the drug to be refunded. As another example, the refund condition may further include that the order placing time and the refund applying time are in the same year, and the first server may determine whether the order placing time and the refund applying time of the drug to be refunded are in the same year, and if so, may perform a refund operation on the drug to be refunded. It should be noted that the refund condition may be modified according to the service. When determining that the refund operation can be performed on the drug to be refunded, the first server may perform the refund operation, for example, funds of the personal payment amount of the user may be refunded to the fund account of the user, and funds of the medical insurance reimbursement amount may be refunded to the medical insurance card account of the user. If the refund operation is determined to be successfully executed, the first server can generate a refund result for representing that the refund operation is successful. If it is determined that the refund operation fails to be performed, the first server may generate a refund result for indicating that the refund operation fails. For example, a refund failure may be characterized by the character "0" or "F", and a refund success may be characterized by the character "1" or "T". After that, the execution agent may receive a refund result returned by the first server. If it is determined that the refund result represents that the refund is successful, for example, the refund result is "1" or "T", the execution main body may push a prompt message for representing that the refund is successful to the user terminal.
In some optional implementation manners of this embodiment, the executing entity may determine whether a query application for querying a balance of the medical insurance card sent by the user terminal is received. If receiving a query application for querying the balance of the medical insurance card sent by the user terminal, the execution main body may send a balance query request to the first server. The balance inquiry request may include the user account. The first server may query a medical insurance card balance of the medical insurance card corresponding to the user account. And then, the execution main body can receive the balance of the medical insurance card returned by the first server. And then, the executive body can push the balance of the medical insurance card to the user terminal.
In some optional implementations of this embodiment, the execution principal may determine whether an order query request is received. The order inquiry request may include order inquiry conditions, such as medical insurance area, purchase channel (online, offline), and the like. If the order query request is received, the execution subject may select a target order from the candidate orders for pushing by using the order query condition. The candidate order may be an order stored in the execution subject, or an order within a preset time period. For example, if the order query condition is "beijing" in the medical insurance area, the executing entity may select an order corresponding to the "beijing" in the medical insurance area from the candidate orders as a target order for pushing. If the order query condition is the starting time "5 month 1 number" and the ending time "5 month 10 number", the execution subject may select an order with the order-taking time from the starting time "5 month 1 number" to the ending time "5 month 10 number" from the candidate orders as the target order to push.
With continued reference to fig. 3, fig. 3 is a timing diagram of an embodiment of a method for ordering a medicare product according to the present embodiment.
As shown in fig. 3, in step 301, the ordering server receives a settlement request for a medical insurance drug sent by a user terminal.
Here, the ordering server may determine whether a settlement request for the medicare is received. The medical insurance drugs generally refer to basic medical insurance drugs, and the specific scope can be managed by establishing 'the catalog of the basic medical insurance drugs'. After the user clicks the "settle" icon in the purchase page of the medicare on the user terminal, the ordering server may receive a settlement request for the medicare.
In step 302, the ordering server determines whether the user account from which the settlement request originates is bound to the medical insurance card.
Here, the ordering server may determine whether the user account from which the settlement request originates is bound to the medical insurance card. If it is determined that the user account from which the settlement request originates is bound to the medical insurance card, the ordering server may perform step 303.
In step 303, if the user account from which the settlement request originates is bound to the medical insurance card, the ordering server sends a pre-settlement request to the first server.
Here, if it is determined in step 302 that the user account from which the settlement request originates is bound to the medical insurance card, the ordering server may send the pre-settlement request to the first server. Herein, pre-settlement generally refers to a pre-estimation of the price of a medical insurance drug purchased by a user. The pre-settlement request may include medical insurance card information, and the medical insurance card information may include a medical insurance area to which a medical insurance card of the user indicated by the user account belongs, where the medical insurance area may be a city-level area. The first server is generally configured to process a request for settlement of medical insurance drugs for the medical insurance area. The first server is usually operated with a local medical insurance system corresponding to the medical insurance area. The first server may process the settlement request using the local medical insurance system.
In step 304, the first server sends the pre-computed result to the ordering server.
Here, the pre-settlement request may further include drug information, and the drug information may include drug identification, drug price, drug quantity, drug manufacturer, and drug formulation. And after receiving the pre-settlement request, the first server can acquire the medical insurance reimbursement amount corresponding to the medicine identifier. Thereafter, the difference between the price of the medication and the medical insurance reimbursement amount may be determined as the personal payment amount. A pre-settlement result including the medical insurance reimbursement amount and the personal payment amount may then be generated. The first server may send the pre-computed result to the lower order server. The pre-settlement result may further include a medicine price, for example, the pre-settlement result may include a medicine price 32 yuan of the medical insurance medicine A, a medical insurance reimbursement amount of 10 yuan and a personal payment amount of 22 yuan.
In step 305, the ordering server pushes an ordering page including the medical insurance reimbursement amount and the personal payment amount to the user terminal.
Here, the ordering server may push an ordering page including the medical insurance reimbursement amount and the personal payment amount to the user terminal.
In step 306, the user terminal sends an order submission request to the ordering server.
Here, after receiving the order page, the user terminal may confirm the medical insurance reimbursement amount and the personal payment amount in the order page, and then may send an order submission request to the order server by clicking the "submit order" icon in the order page.
In step 307, the ordering server sends an ordering request to the first server.
Here, if the order placing server receives an order submitting request returned by the user terminal, the order placing server may send an order placing request to the first server. After receiving the order placing request sent by the order placing server, the first server may obtain the balance in the medical insurance card bound by the user account, and then, the first server may determine whether the balance in the medical insurance card bound by the user account is greater than the medical insurance reimbursement amount. If the balance is larger than the medical insurance reimbursement amount, the first server can generate an order placing result used for representing the successful order placing. If the balance is less than the medical insurance reimbursement amount, the first server can generate an order placing result used for representing the failure of order placing.
In step 308, the ordering server receives the ordering result returned by the first server.
Here, the ordering server may receive an ordering result returned by the first server. If the received ordering result represents that ordering is successful, the ordering server can push a page for representing that ordering is successful to the user terminal, and then the ordering server can send order information aiming at the medical insurance medicine to a warehouse terminal of a specified warehouse, so that warehouse personnel complete subsequent medicine sorting, delivery and other processes. If the received ordering result represents that the ordering fails, the ordering server can push a page for representing the ordering failure to the user terminal.
The method provided by the embodiment of the application can access the E-commerce platform to various medical insurance systems, and can unify the data format and the docking mode, so that a user can place orders for medical insurance medicines on line.
With further reference to fig. 4, a flow 400 of yet another embodiment of a method of ordering a medical insurance drug is illustrated. The process 400 of the ordering method of the medical insurance medicine comprises the following steps:
in response to receiving a settlement request for a medical insurance drug, step 401 determines whether a user account from which the settlement request originates is bound to a medical insurance card.
In this embodiment, step 401 may be performed in a similar manner to step 201, and is not described herein again.
In this embodiment, if it is determined in step 401 that the user account from which the settlement request is originated is not bound to the medical insurance card, an execution subject (for example, the ordering server shown in fig. 1) of the ordering method of the medical insurance drug may push a medical insurance card binding page to the user terminal from which the settlement request is originated. The user may fill in the medical insurance card information (e.g., name, gender, age, identification number, cell phone number, mailbox, home address, medical insurance card number, medical insurance province, etc.) in the medical insurance card binding page, and then click on the "ok" icon to send the filled-in information to the executive body.
And then, the execution main body can receive a binding application including the medical insurance card information returned by the user terminal.
In this embodiment, the executing agent may send a binding request including the received medical insurance card information to the second server. The second server may be configured to process the binding request. Here, the second server may have an provincial medical insurance card management system running therein. The second server can manage the medical insurance card by using the provincial medical insurance card management system.
For example, the second server may store medical insurance card information (e.g., an identification number) of the user in advance, match the locally stored medical insurance card information of the user with the medical insurance card information submitted by the user, and if the matching fails, generate a binding result for representing the binding failure. The second server may also determine whether the state of the medical insurance card of the user is normal, and if the state of the medical insurance card is abnormal, a binding result for representing the binding failure may be generated. If the second server determines that the locally stored medical insurance card information of the user is not matched with the medical insurance card information submitted by the user, such as the identity card number is not matched, or determines that the state of the medical insurance card is abnormal, a binding result for representing successful binding can be generated.
Thereafter, the execution subject may receive the binding result returned by the second server.
Here, the binding success may be characterized by the character "1" or "T". Binding failure may be characterized by the characters "0" or "F".
And step 404, if the binding result represents that the medical insurance card is successfully bound, binding the user account with the medical insurance card information.
In this embodiment, the executing entity may determine whether the binding result indicates that the medical insurance card is successfully bound. If the binding result represents that the medical insurance card is successfully bound, if the binding result is determined to be '1' or 'T', the executive body can bind the user account and the medical insurance card information. The binding may be understood as setting a corresponding relationship between the user account and the medical insurance card information.
In this embodiment, the execution subject may send a pre-settlement request to the first server. Herein, pre-settlement generally refers to a pre-estimation of the price of a medical insurance drug purchased by a user. The pre-settlement request may include medical insurance card information, and the medical insurance card information may include a medical insurance area to which a medical insurance card of the user indicated by the user account belongs, where the medical insurance area may be a city-level area. The first server is generally configured to process a request for settlement of medical insurance drugs for the medical insurance area. The first server is usually operated with a local medical insurance system corresponding to the medical insurance area. The first server may process the settlement request using the local medical insurance system.
Here, the pre-settlement request may further include drug information, and the drug information may include drug identification, drug price, drug quantity, drug manufacturer, and drug formulation. And after receiving the pre-settlement request, the first server can acquire the medical insurance reimbursement amount corresponding to the medicine identifier. Thereafter, the difference between the price of the medication and the medical insurance reimbursement amount may be determined as the personal payment amount. A pre-settlement result including the medical insurance reimbursement amount and the personal payment amount may then be generated. The pre-settlement result may further include a medicine price, for example, the pre-settlement result may include a medicine price 32 yuan of the medical insurance medicine A, a medical insurance reimbursement amount of 10 yuan and a personal payment amount of 22 yuan.
Thereafter, the execution subject may receive a pre-settlement result returned by the first server.
In the present embodiment, the steps 406-407 and the steps 203-204 are performed, and are not described herein again.
As can be seen from fig. 4, compared with the embodiment corresponding to fig. 2, the process 400 of the order placing method for medical insurance medicines in this embodiment embodies the step of binding the user account with the medical insurance card information if it is determined that the user account is not bound with the medical insurance card. Therefore, the scheme described in the embodiment provides a binding method for binding the user account and the medical insurance card information.
With further reference to fig. 5, as an implementation of the method shown in the above figures, the present application provides an embodiment of an ordering apparatus for medicare medicines, which corresponds to the embodiment of the method shown in fig. 2, and which can be applied to various electronic devices.
As shown in fig. 5, the ordering apparatus 500 of the medical insurance medicine of the present embodiment includes: a determination unit 501, a first receiving unit 502, a first pushing unit 503 and a second receiving unit 504. Wherein the determining unit 501 is configured to determine whether a user account from which a settlement request is originated is bound with a medical insurance card in response to receiving the settlement request for the medical insurance drug; the first receiving unit 502 is configured to send a pre-settlement request to the first server and receive a pre-settlement result returned by the first server if a user account from which the settlement request originates is bound with the medical insurance card, wherein the pre-settlement request includes medical insurance card information including a medical insurance area to which the medical insurance card of the user indicated by the user account belongs, the first server is used for processing the settlement request for medical insurance drugs in the medical insurance area, and the pre-settlement result includes a medical insurance reimbursement amount and a personal payment amount; the first pushing unit 503 is configured to push a placing page including the medical insurance reimbursement amount and the personal payment amount to the user terminal from which the settlement request is originated; the second receiving unit 504 is configured to send an order placing request to the first server in response to receiving an order submitting request returned by the user terminal, and receive an order placing result returned by the first server.
In this embodiment, the specific processes of the determining unit 501, the first receiving unit 502, the first pushing unit 503 and the second receiving unit 504 of the ordering apparatus 500 of the medical insurance medicine can refer to step 201, step 202, step 203 and step 204 in the corresponding embodiment of fig. 2.
In some optional implementations of the present embodiment, the ordering apparatus 500 for medical insurance drugs may further include: a third receiving unit (not shown), a fourth receiving unit (not shown), and a binding unit (not shown). If it is determined that the user account from which the settlement request originates is not bound to the medical insurance card, the third receiving unit may push a medical insurance card binding page to the user terminal from which the settlement request originates. The user may fill in the medical insurance card information (e.g., name, gender, age, identification number, cell phone number, mailbox, home address, medical insurance card number, medical insurance province, etc.) in the medical insurance card binding page, and then click on the "ok" icon to send the filled-in information to the executive body. Then, the third receiving unit may receive a binding application including the medical insurance card information returned by the user terminal. The fourth receiving unit may send a binding request including the received medical insurance card information to the second server. The second server may be configured to process the binding request. Here, the second server may have an provincial medical insurance card management system running therein. The second server can manage the medical insurance card by using the provincial medical insurance card management system. For example, the second server may store medical insurance card information (e.g., an identification number) of the user in advance, match the locally stored medical insurance card information of the user with the medical insurance card information submitted by the user, and if the matching fails, generate a binding result for representing the binding failure. The second server may also determine whether the state of the medical insurance card of the user is normal, and if the state of the medical insurance card is abnormal, a binding result for representing the binding failure may be generated. If the second server determines that the locally stored medical insurance card information of the user is not matched with the medical insurance card information submitted by the user, such as the identity card number is not matched, or determines that the state of the medical insurance card is abnormal, a binding result for representing successful binding can be generated. Thereafter, the fourth receiving unit may receive the binding result returned by the second server. Here, the binding success may be characterized by the character "1" or "T". Binding failure may be characterized by the characters "0" or "F". The binding unit can determine whether the binding result represents that the medical insurance card is successfully bound. If the binding result represents that the medical insurance card is successfully bound, if the binding result is determined to be '1' or 'T', the binding unit can bind the user account and the medical insurance card information. The binding may be understood as setting a corresponding relationship between the user account and the medical insurance card information.
In some optional implementations of the present embodiment, the ordering apparatus 500 for medical insurance drugs may further include: a first sending unit (not shown), a fifth receiving unit (not shown), and a second pushing unit (not shown). The first sending unit may determine whether a refund application sent by the user terminal is received. The first sending unit may send a refund request to the first server if receiving a refund application sent by the user terminal. The refund request may include the user account and ordering information corresponding to the drug to be refunded. The ordering information corresponding to the drug to be refunded may include, but is not limited to: the drug identification of the drug to be refunded, the number of the drugs, and the order placing time. The first server may determine whether the drug to be refunded meets a refund condition after receiving the refund request. As an example, the refund condition may include a purchase time not exceeding 15 days, the first server may determine a time difference between an order placing time of the drug to be refunded and a current time, and if the time difference does not exceed 15 days, a refund operation may be performed on the drug to be refunded. As another example, the refund condition may further include that the order placing time and the refund applying time are in the same year, and the first server may determine whether the order placing time and the refund applying time of the drug to be refunded are in the same year, and if so, may perform a refund operation on the drug to be refunded. It should be noted that the refund condition may be modified according to the service. When determining that the refund operation can be performed on the drug to be refunded, the first server may perform the refund operation, for example, funds of the personal payment amount of the user may be refunded to the fund account of the user, and funds of the medical insurance reimbursement amount may be refunded to the medical insurance card account of the user. If the refund operation is determined to be successfully executed, the first server can generate a refund result for representing that the refund operation is successful. If it is determined that the refund operation fails to be performed, the first server may generate a refund result for indicating that the refund operation fails. For example, a refund failure may be characterized by the character "0" or "F", and a refund success may be characterized by the character "1" or "T". The fifth receiving unit may receive a refund result returned by the first server. If it is determined that the refund result represents that the refund is successful, for example, the refund result is "1" or "T", the second pushing unit may push a prompt message for representing that the refund is successful to the user terminal.
In some optional implementations of the present embodiment, the ordering apparatus 500 for medical insurance drugs may further include: a second sending unit (not shown), a sixth receiving unit (not shown), and a third pushing unit (not shown). The second sending unit may determine whether an inquiry application for inquiring the balance of the medical insurance card sent by the user terminal is received. If receiving a query application for querying the balance of the medical insurance card sent by the user terminal, the second sending unit may send a balance query request to the first server. The balance inquiry request may include the user account. The first server may query a medical insurance card balance of the medical insurance card corresponding to the user account. Then, the sixth receiving unit may receive the balance of the medical insurance card returned by the first server. And then, the third pushing unit can push the balance of the medical insurance card to the user terminal.
In some optional implementations of the present embodiment, the ordering apparatus 500 for medical insurance drugs may further include: a selection unit (not shown). The selecting unit may determine whether an order query request is received. The order inquiry request may include order inquiry conditions, such as medical insurance area, purchase channel (online, offline), and the like. If the order query request is received, the selecting unit may select a target order from the candidate orders for pushing by using the order query condition. The candidate order may be an order stored in the execution subject, or an order within a preset time period. As an example, if the order query condition is "beijing" in the medical insurance area, the selecting unit may select an order corresponding to the "beijing" in the medical insurance area from the candidate orders as the target order for pushing. If the order query condition is the starting time "5 month 1 number" and the ending time "5 month 10 number", the selecting unit may select an order with an order release time within a time period from the starting time "5 month 1 number" to the ending time "5 month 10 number" from the candidate orders as the target order to push.
Referring now to FIG. 6, a schematic diagram of an electronic device (e.g., ordering server in FIG. 1) 600 suitable for use in implementing embodiments of the present disclosure is shown. The server shown in fig. 6 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.
As shown in fig. 6, electronic device 600 may include a processing means (e.g., central processing unit, graphics processor, etc.) 601 that may perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)602 or a program loaded from a storage means 608 into a Random Access Memory (RAM) 603. In the RAM603, various programs and data necessary for the operation of the electronic apparatus 600 are also stored. The processing device 601, the ROM 602, and the RAM603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.
Generally, the following devices may be connected to the I/O interface 605: input devices 606 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 607 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 608 including, for example, tape, hard disk, etc.; and a communication device 609. The communication means 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. While fig. 6 illustrates an electronic device 600 having various means, it is to be understood that not all illustrated means are required to be implemented or provided. More or fewer devices may alternatively be implemented or provided. Each block shown in fig. 6 may represent one device or may represent multiple devices as desired.
In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication means 609, or may be installed from the storage means 608, or may be installed from the ROM 602. The computer program, when executed by the processing device 601, performs the above-described functions defined in the methods of embodiments of the present disclosure. It should be noted that the computer readable medium described in the embodiments of the present disclosure may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In embodiments of the disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In embodiments of the present disclosure, however, a computer readable signal medium may comprise a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, optical cables, RF (radio frequency), etc., or any suitable combination of the foregoing.
The computer readable medium may be embodied in the electronic device; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: in response to receiving a settlement request for a medical insurance drug, determining whether a user account from which the settlement request originates is bound with a medical insurance card; if so, sending a pre-settlement request to a first server, and receiving a pre-settlement result returned by the first server, wherein the pre-settlement request comprises medical insurance card information, the medical insurance card information comprises a medical insurance area to which a medical insurance card of a user indicated by a user account belongs, the first server is used for processing a settlement request aiming at medical insurance medicines in the medical insurance area, and the pre-settlement result comprises a medical insurance reimbursement amount and a personal payment amount; pushing a placing page comprising the medical insurance reimbursement amount and the personal payment amount to a user terminal from which the settlement request comes; in response to receiving an order submitting request returned by the user terminal, sending an order placing request to the first server, and receiving an order placing result returned by the first server.
Computer program code for carrying out operations for embodiments of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + +, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The units described in the embodiments of the present disclosure may be implemented by software or hardware. The described units may also be provided in a processor, and may be described as: a processor includes a determination unit, a first reception unit, a first push unit, and a second reception unit. Where the names of these units do not constitute a limitation on the unit itself in some cases, for example, the first pushing unit may also be described as a "unit that pushes a drop page including a medical insurance reimbursement amount and a personal payment amount to the user terminal from which the settlement request is originated".
The foregoing description is only exemplary of the preferred embodiments of the disclosure and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention in the embodiments of the present disclosure is not limited to the specific combination of the above-mentioned features, but also encompasses other embodiments in which any combination of the above-mentioned features or their equivalents is made without departing from the inventive concept as defined above. For example, the above features and (but not limited to) technical features with similar functions disclosed in the embodiments of the present disclosure are mutually replaced to form the technical solution.
Claims (10)
1. A method of ordering a medical insurance drug, comprising:
in response to receiving a settlement request for a medical insurance drug, determining whether a user account from which the settlement request originates is bound with a medical insurance card;
if so, sending a pre-settlement request to a first server, and receiving a pre-settlement result returned by the first server, wherein the pre-settlement request comprises medical insurance card information, the medical insurance card information comprises a medical insurance area to which a medical insurance card of a user indicated by the user account belongs, the first server is used for processing a settlement request for medical insurance medicines in the medical insurance area, and the pre-settlement result comprises a medical insurance reimbursement amount and a personal payment amount;
pushing a placing page comprising the medical insurance reimbursement amount and the personal payment amount to a user terminal from which the settlement request comes;
and responding to the received order submitting request returned by the user terminal, sending an order placing request to the first server, and receiving an order placing result returned by the first server.
2. The method of claim 1, wherein after the determining whether the user account from which the settlement request originates is bound to a medical insurance card, the method further comprises:
if not, pushing a medical insurance card binding page to the user terminal, and receiving a binding application including medical insurance card information returned by the user terminal;
sending a binding request including the received medical insurance card information to a second server, and receiving a binding result returned by the second server, wherein the second server is used for processing the binding request;
and if the binding result represents that the medical insurance card is successfully bound, binding the user account with the medical insurance card information.
3. The method of claim 1, wherein the method further comprises:
sending a refund request to the first server in response to receiving a refund application sent by the user terminal, wherein the refund request comprises the user account and order placing information corresponding to a drug to be refunded;
receiving a refund result returned by the first server;
and if the refund result represents that the refund is successful, pushing prompt information for representing that the refund is successful to the user terminal.
4. The method of claim 1, wherein the method further comprises:
sending a balance inquiry request to the first server in response to receiving an inquiry application which is sent by the user terminal and used for inquiring the balance of the medical insurance card, wherein the balance inquiry request comprises the user account;
receiving the balance of the medical insurance card returned by the first server;
and pushing the balance of the medical insurance card to the user terminal.
5. The method of claim 1, wherein the method further comprises:
in response to receiving an order query request comprising order query conditions, selecting a target order from candidate orders for pushing by using the order query conditions.
6. An ordering device for medical insurance drugs, comprising:
a determination unit configured to determine whether a user account from which a settlement request is originated is bound with a medical insurance card in response to receiving the settlement request for the medical insurance medicine;
the first receiving unit is configured to send a pre-settlement request to a first server and receive a pre-settlement result returned by the first server if a user account from which the settlement request originates is bound with a medical insurance card, wherein the pre-settlement request comprises medical insurance card information, the medical insurance card information comprises a medical insurance area to which the medical insurance card of the user indicated by the user account belongs, the first server is used for processing the settlement request of medical insurance medicines in the medical insurance area, and the pre-settlement result comprises a medical insurance reimbursement amount and a personal payment amount;
a first pushing unit configured to push a placing page including the medical insurance reimbursement amount and the personal payment amount to a user terminal from which the settlement request is originated;
the second receiving unit is configured to respond to the order submitting request returned by the user terminal, send an order placing request to the first server, and receive an order placing result returned by the first server.
7. The apparatus of claim 6, wherein the apparatus further comprises:
a third receiving unit, configured to, if the user account from which the settlement request originates is not bound with a medical insurance card, push a medical insurance card binding page to the user terminal, and receive a binding application including medical insurance card information returned by the user terminal;
the fourth receiving unit is configured to send a binding request including the received medical insurance card information to a second server and receive a binding result returned by the second server, wherein the second server is used for processing the binding request;
and the binding unit is configured to bind the user account with the medical insurance card information if the binding result represents that the medical insurance card is successfully bound.
8. The apparatus of claim 6, wherein the apparatus further comprises:
the first sending unit is configured to send a refund request to the first server in response to receiving a refund application sent by the user terminal, wherein the refund request comprises the user account and order placing information corresponding to a drug to be refunded;
a fifth receiving unit configured to receive a refund result returned by the first server;
and the second pushing unit is configured to push prompt information for representing that the refund is successful to the user terminal if the refund result represents that the refund is successful.
9. An electronic device, comprising:
one or more processors;
a storage device having one or more programs stored thereon,
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-5.
10. A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010603400.7A CN112308552A (en) | 2020-06-29 | 2020-06-29 | Ordering method and device for medical insurance medicines |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010603400.7A CN112308552A (en) | 2020-06-29 | 2020-06-29 | Ordering method and device for medical insurance medicines |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112308552A true CN112308552A (en) | 2021-02-02 |
Family
ID=74483454
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010603400.7A Pending CN112308552A (en) | 2020-06-29 | 2020-06-29 | Ordering method and device for medical insurance medicines |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112308552A (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112926961A (en) * | 2021-04-09 | 2021-06-08 | 口碑(上海)信息技术有限公司 | Payment method, display method, processing method and device and electronic equipment |
| CN113989060A (en) * | 2021-12-23 | 2022-01-28 | 浙江口碑网络技术有限公司 | Medical service order processing method and device and electronic equipment |
| CN115358829A (en) * | 2022-10-19 | 2022-11-18 | 北京京东拓先科技有限公司 | Article transaction data processing method and device, storage medium and electronic equipment |
| CN115510338A (en) * | 2022-09-27 | 2022-12-23 | 北京三快在线科技有限公司 | Information recommendation method and device, storage medium and electronic equipment |
| CN117350627A (en) * | 2023-10-18 | 2024-01-05 | 杭州正马软件科技有限公司 | E-commerce logistics package interception system and automatic refund method |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102074069A (en) * | 2011-01-13 | 2011-05-25 | 易联众信息技术股份有限公司 | Self-service settlement method for diagnosis and treatment expense of outpatient service |
| CN105488577A (en) * | 2014-10-13 | 2016-04-13 | 潘一琦 | Medical service purchasing method for telemedicine users and system thereof |
| CN107292597A (en) * | 2017-05-26 | 2017-10-24 | 深圳医畅科技发展有限公司 | Medical method, mobile terminal and the storage device paid is realized based on social security card |
| WO2019071965A1 (en) * | 2017-10-13 | 2019-04-18 | 平安科技（深圳）有限公司 | Data processing method, data processing device, and computer readable storage medium |
| CN109785095A (en) * | 2018-12-13 | 2019-05-21 | 平安医疗健康管理股份有限公司 | A kind of settlement method of medical expense, checkout apparatus and terminal device |
| CN110060049A (en) * | 2018-11-30 | 2019-07-26 | 阿里巴巴集团控股有限公司 | Method of payment, device and equipment |
-
2020
- 2020-06-29 CN CN202010603400.7A patent/CN112308552A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102074069A (en) * | 2011-01-13 | 2011-05-25 | 易联众信息技术股份有限公司 | Self-service settlement method for diagnosis and treatment expense of outpatient service |
| CN105488577A (en) * | 2014-10-13 | 2016-04-13 | 潘一琦 | Medical service purchasing method for telemedicine users and system thereof |
| CN107292597A (en) * | 2017-05-26 | 2017-10-24 | 深圳医畅科技发展有限公司 | Medical method, mobile terminal and the storage device paid is realized based on social security card |
| WO2019071965A1 (en) * | 2017-10-13 | 2019-04-18 | 平安科技（深圳）有限公司 | Data processing method, data processing device, and computer readable storage medium |
| CN110060049A (en) * | 2018-11-30 | 2019-07-26 | 阿里巴巴集团控股有限公司 | Method of payment, device and equipment |
| CN109785095A (en) * | 2018-12-13 | 2019-05-21 | 平安医疗健康管理股份有限公司 | A kind of settlement method of medical expense, checkout apparatus and terminal device |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112926961A (en) * | 2021-04-09 | 2021-06-08 | 口碑(上海)信息技术有限公司 | Payment method, display method, processing method and device and electronic equipment |
| CN113989060A (en) * | 2021-12-23 | 2022-01-28 | 浙江口碑网络技术有限公司 | Medical service order processing method and device and electronic equipment |
| CN113989060B (en) * | 2021-12-23 | 2023-02-03 | 浙江口碑网络技术有限公司 | Medical service order processing method and device and electronic equipment |
| CN115510338A (en) * | 2022-09-27 | 2022-12-23 | 北京三快在线科技有限公司 | Information recommendation method and device, storage medium and electronic equipment |
| CN115510338B (en) * | 2022-09-27 | 2024-03-12 | 北京三快在线科技有限公司 | Information recommendation method and device, storage medium and electronic equipment |
| CN115358829A (en) * | 2022-10-19 | 2022-11-18 | 北京京东拓先科技有限公司 | Article transaction data processing method and device, storage medium and electronic equipment |
| CN117350627A (en) * | 2023-10-18 | 2024-01-05 | 杭州正马软件科技有限公司 | E-commerce logistics package interception system and automatic refund method |
| CN117350627B (en) * | 2023-10-18 | 2024-04-09 | 杭州正马软件科技有限公司 | E-commerce logistics package interception system and automatic refund method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112308552A (en) | Ordering method and device for medical insurance medicines | |
| US10198764B2 (en) | System and method for message-based purchasing | |
| WO2012045154A1 (en) | System and method of capturing point-of-sale data and providing real-time advertising content | |
| CN110619555A (en) | Unified management method and device for order information, terminal equipment and medium | |
| US20190147416A1 (en) | System and method for facilitating mobile payments via mobile messaging | |
| CN111857888A (en) | Transaction processing method and device | |
| EP4138011A1 (en) | Ex-warehouse control method, device and system | |
| US10467585B2 (en) | Beverage product acquisition and inventory management system | |
| KR102400828B1 (en) | System for providing owner information of art creations and method thereof | |
| CN112348612B (en) | Order generation method and device | |
| US20160042343A1 (en) | Information processing apparatus, information processing method and information processing program | |
| CN114418482A (en) | Order information processing method and device, electronic equipment and computer readable medium | |
| CN112766969A (en) | Mobile payment method and system, payment device and computer readable storage medium | |
| CN111695985A (en) | System and method for processing voluntary deposit service of accumulation fund | |
| CN113077881A (en) | Internet hospital information processing method and device | |
| KR20220026195A (en) | System and Method for Providing Openmarket Service by Using Terminal | |
| US20220058599A1 (en) | Settlement operation support system and settlement operation support method | |
| CN112581179B (en) | Electronic coupon generation method and generation device | |
| CN113763058A (en) | Method and device for realizing service interaction across systems | |
| US10839450B2 (en) | Communication system and method thereof | |
| CN112308661A (en) | Order processing method and device | |
| CN113822661A (en) | Payment method, device and system | |
| CN114399347A (en) | Information display method and device, electronic equipment and computer readable medium | |
| CN111932374A (en) | Data updating method and device and electronic equipment | |
| KR20230043445A (en) | System for providing owner information of metahuman and method thereof |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20210226 Address after: 100176 room 701, 7 / F, building 1, yard 18, Kechuang 11th Street, Beijing Economic and Technological Development Zone, Daxing District, Beijing Applicant after: Beijing Jingdong tuoxian Technology Co.,Ltd. Address before: Room A402, 4th floor, building 2, No. 18, Kechuang 11th Street, Daxing Economic and Technological Development Zone, Beijing 100176 Applicant before: BEIJING WODONG TIANJUN INFORMATION TECHNOLOGY Co.,Ltd. Applicant before: BEIJING JINGDONG CENTURY TRADING Co.,Ltd. |