CN112308552B - Method and device for ordering medical insurance medicine - Google Patents
Method and device for ordering medical insurance medicine Download PDFInfo
- Publication number
- CN112308552B CN112308552B CN202010603400.7A CN202010603400A CN112308552B CN 112308552 B CN112308552 B CN 112308552B CN 202010603400 A CN202010603400 A CN 202010603400A CN 112308552 B CN112308552 B CN 112308552B
- Authority
- CN
- China
- Prior art keywords
- medical insurance
- server
- request
- order
- insurance card
- 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.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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—Managing shopping lists, e.g. compiling or processing purchase lists
- G06Q30/0635—Managing shopping lists, e.g. compiling or processing purchase lists replenishment orders; recurring orders
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Computer Networks & Wireless Communication (AREA)
- Medical Treatment And Welfare Office Work (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The embodiment of the application discloses a method and a device for ordering medical insurance medicines. One embodiment of the method comprises the following steps: in response to receiving a settlement request for the medical insurance medicine, determining whether a user account from which the settlement request originates is bound with the 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 of a medical insurance card of a user indicated by a user account, and the pre-settlement result comprises a medical insurance reimbursement amount and a personal payment amount; pushing a bill ordering page comprising medical insurance reimbursement amount and personal payment amount to a user terminal from which the settlement request is sent; and responding to the receiving 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 an order for the medical insurance drug online.
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. Social medical insurance is a social insurance system established by the state and the society for providing basic medical demand guarantee when illness for laborers in a guarantee range according to certain laws and regulations. The basic medical insurance fund consists of an overall fund and a personal account. The existing medical insurance bureau system is characterized in that independent medical insurance systems are independently established by each local medical insurance bureau, the information of the medical insurance systems is not uniform, if the medical insurance systems need to be accessed to enter an e-commerce platform, independent development is required to be carried out on each local market medical insurance system, and interface definition needs to be independently configured and data transcoding is required.
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 the medical insurance medicine, determining whether a user account from which the settlement request originates is bound with the medical insurance card; if so, a pre-settlement request is sent to a first server, and a pre-settlement result returned by the first server is received, 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 of medical insurance medicines aiming at the medical insurance area, and the pre-settlement result comprises medical insurance reimbursement amount and personal payment amount; pushing a bill ordering page comprising medical insurance reimbursement amount and personal payment amount to a user terminal from which the settlement request is sent; and responding to the receiving 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 originated is bound to the medical insurance card, the method further includes: if not, pushing a medical insurance card binding page to the user terminal, and receiving a binding application comprising medical insurance card information returned by the user terminal; sending a binding request comprising 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 number with the medical insurance card information.
In some embodiments, the method further comprises: responding to a refund application sent by a user terminal, and sending a refund request to a first server, wherein the refund request comprises a user account and order information corresponding to a medicine to be refunded; receiving a refund result returned by the first server; if the refund result represents that the refund is successful, the prompt information for representing that the refund is successful is pushed to the user terminal.
In some embodiments, the method further comprises: responding to a query application which is sent by a user terminal and used for querying the balance of the medical insurance card, and sending a balance query request to a first server, wherein the balance query request comprises a user account; receiving the balance of the medical insurance card returned by the first server; pushing the balance of the medical insurance card to the user terminal.
In some embodiments, the method further comprises: in response to receiving an order query request including an order query condition, a target order is selected from the candidate orders for pushing using the order query condition.
In a second aspect, an embodiment of the present application provides a device for ordering medical insurance medicines, including: a determination unit configured to determine, in response to receiving a settlement request for the medical insurance medicine, whether a user account from which the settlement request originates is bound with the medical insurance card; the first receiving unit is configured to send a pre-settlement request to the first server if a user account from which the settlement request is sent is bound with the medical insurance card, and receive 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 the settlement request of medical insurance medicines for 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, to a user terminal from which the settlement request originates, a lower order page including a medical insurance reimbursement amount and a personal payment amount; the second receiving unit 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 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 comprising medical insurance card information returned by the user terminal if the user account from which the settlement request is sent is not bound with the medical insurance card; the fourth receiving unit is configured to send a binding request comprising 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 and 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 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 a user account and order information corresponding to a medicine to be refunded; the fifth receiving unit is configured to receive a refund result returned by the first server; and the second pushing unit is configured to push prompt information for representing successful refund to the user terminal if the refund result represents successful refund.
In a third aspect, an embodiment of the present application provides an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, which when executed by the one or more processors, cause the one or more processors to implement the method as described in any of the implementations of the first aspect.
In a fourth aspect, embodiments of the present application provide a computer readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements a method as described in any of the implementations of the first aspect.
The method and the device for ordering the medical insurance medicine provided by the embodiment of the application determine whether the user account from which the settlement request is sent is bound with the medical insurance card or not by responding to the received settlement request for the medical insurance medicine; if the user account from which the settlement request is derived 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 bill page comprising the medical insurance reimbursement amount and the personal payment amount to a user terminal from which the settlement request is sent; and finally, responding to the receiving of the 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 mode can access the E-commerce platform to the medical insurance systems in various places, and unify the data format and the docking mode, so that a user can order the medical insurance medicines on line.
Drawings
Other features, objects and advantages of the present application will become more apparent upon reading of the detailed description of non-limiting embodiments, 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 of ordering a medical insurance drug in accordance with the present application;
FIG. 3 is a timing diagram of one embodiment of a method of ordering medical insurance drugs in accordance with the present application;
FIG. 4 is a flow chart of yet another embodiment of a method of ordering a medical insurance drug in accordance with the present application;
FIG. 5 is a schematic diagram of one embodiment of an ordering apparatus for medical insurance drugs according to the present application;
fig. 6 is a schematic diagram of a computer system suitable for use in implementing an embodiment of the application.
Detailed Description
The application is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the application and are not limiting of the application. It should be noted that, for convenience of description, only the portions related to the present application are shown in the drawings.
It should be noted that, without conflict, the embodiments of the present application and features of the embodiments may be combined with each other. The application will be described in detail below with reference to the drawings in connection with embodiments.
FIG. 1 illustrates an exemplary system architecture 100 of an embodiment of a method of ordering medical insurance products to which 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, an order server 103, a first server 104, and a second server 105. The network 1021 is the medium used to provide a communication link between the user terminals 1011, 1012 and the order server 103. The network 1022 is used to provide a medium for communication links between the order server 103 and the first server 104. The network 1023 is a medium used to provide a communication link between the order server 103 and the second server 105. The networks 1021, 1022, 1023 may 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 order server 103 via the network 1021 to send or receive messages (e.g., the order server 103 may receive a settlement request for the medical insurance drug sent by the user terminals 1011, 1012, and the order server 103 may also send an order page to the user terminals 1011, 1012). The user terminals 1011, 1012 may have various communication client applications installed thereon, such as shopping applications, medical health applications, instant messaging software, and the like.
The user terminals 1011, 1012 may be hardware or software. When the user terminals 1011, 1012 are hardware, they may be various electronic devices supporting information interaction, including but not limited to smart phones, tablet computers, laptop and desktop computers, and the like. When the user terminals 1011, 1012 are software, they can be installed in the above-listed electronic apparatuses. Which may be implemented as a plurality of software or software modules, or as a single software or software module. The present invention is not particularly limited herein.
The first server 104 may interact with the order server 103 over the network 1022 to send or receive messages (e.g., the order server 103 may send a pre-settlement request to the first server 104, and the order server 103 may also receive the pre-settlement results returned by the first server 104).
The second server 105 may interact with the order server 103 via the network 1023 to send or receive messages (the order server 103 may send a binding request to the second server 105, and the order 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 smartphones, tablets, laptop and desktop computers, and the like. When the first server 104 and the second server 105 are software, they can be installed in the above-listed electronic devices. Which may be implemented as a plurality of software or software modules, or as a single software or software module. The present invention is not particularly limited herein.
The order server 103 may be a server providing various services. For example, a background server that analyzes the settlement request for the medical insurance drug may be used. In response to the ordering server 103 receiving the settlement request for the medical insurance medicine sent by the user terminal 1011, 1012, it may be determined whether the user account from which the settlement request is derived is bound with the medical insurance card; if the user account from which the settlement request originates is bound with the medical insurance card, a pre-settlement request can be sent to the first server 104, and a pre-settlement result returned by the first server 104 is received; then, a lower order page including the medical insurance reimbursement amount and the personal payment amount may be pushed to the user terminal 1011, 1012; finally, in response to receiving the order submission request returned by the user terminal 1011, 1012, an order placement request may be sent to the first server 104, and an order placement result returned by the first server 104 may be received.
Note that, the order server 103 may be hardware, or may be software. When the policy server 103 is hardware, it may be implemented as a distributed server cluster composed of a plurality of servers, or as a single server. When the order 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. The present invention is not particularly limited herein.
It should be noted that, the ordering method of the medical insurance medicine provided by the embodiment of the present application is generally executed by the ordering server 103.
It should be understood that the number of user terminals, networks, order servers, first servers and second servers in fig. 1 are merely illustrative. There may be any number of user terminals, networks, order servers, first servers, and second servers, as desired for implementation.
With continued reference to FIG. 2, a flow 200 of one embodiment of a method of ordering medical insurance drugs in accordance with the present application is shown. The method for ordering the medical insurance medicine comprises the following steps:
in step 201, in response to receiving a settlement request for a medical insurance drug, it is determined whether a user account from which the settlement request originated is bound to a medical insurance card.
In this embodiment, the execution subject of the order method of the medical insurance medicine (for example, the order server shown in fig. 1) may determine whether a settlement request for the medical insurance medicine is received. Medical insurance medicines generally refer to basic medical insurance medicines, and a specific range can be managed by making a basic medical insurance medicine catalogue. After clicking the "settle" icon in the purchase page of the medical insurance drug, the executing body may receive an settlement request for the medical insurance drug. The executing entity may then determine whether the user account from which the settlement request originated 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 executing body may execute step 202.
Step 202, if the user account from which the settlement request originates is bound to the medical insurance card, sending a pre-settlement request to the first server, and receiving a pre-settlement result returned by the first server.
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 body may send a pre-settlement request to the first server. Pre-settlement is generally referred to herein as a pre-estimation of the price of the medical insurance drug purchased by the user. The pre-settlement request may include information of a medical insurance card, where the medical insurance card information may include a medical insurance area to which the medical insurance card of the user indicated by the user account number belongs, and the medical insurance area may be a municipal area. The first server is typically configured to process a settlement request for medical insurance medicines in the medical insurance area. The first server is generally 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 medicine information, which may include medicine identification, medicine price, medicine quantity, medicine manufacturer, and medicine dosage form. After receiving the pre-settlement request, the first server can acquire the medical insurance reimbursement amount corresponding to the medicine identifier. The difference between the price of the drug and the amount of the medical insurance reimbursement may then be determined as the individual payment amount. Pre-settlement results may then be generated that include the medical insurance reimbursement amount and the personal payment amount. The pre-settlement result may also include a medicine price, for example, the pre-settlement result may include a medicine price of 32 yuan for the medical insurance medicine a, a medical insurance reimbursement amount of 10 yuan, and a personal payment amount of 22 yuan.
Then, the executing body may receive a pre-settlement result returned from the first server.
Step 203, pushing an order page including the medical insurance reimbursement amount and the personal payment amount to the user terminal from which the settlement request is derived.
In this embodiment, the executing body may push, to the user terminal from which the settlement request originates, a download page including the medical insurance reimbursement amount and the personal payment amount. After receiving the order page, the user terminal can confirm the medical insurance reimbursement amount and the personal payment amount in the order page, and then can send an order submitting request to the execution body by clicking an order submitting icon in the order page.
And step 204, in response to receiving the 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 this embodiment, if an order submitting request returned by the user terminal is received, the execution body may send an order placing request to the first server. After receiving the order placing request sent by the execution main body, the first server can acquire the balance in the medical insurance card bound by the user account, and then can determine whether the balance in the medical insurance card bound by the user account is larger than the medical insurance reimbursement amount. If the balance is greater than the medical insurance reimbursement amount, an order placing result used for representing successful order placing can be generated. If the balance is smaller than the reimbursement amount of medical insurance, an order placing result used for representing the order placing failure can be generated.
And then, the execution body can receive the ordering result returned by the first server. If the received single-result representation is successful, the execution main body can push a page for representing the successful ordering to the user terminal, and then can send order information for the medical insurance medicine to a warehouse terminal of a designated warehouse, so that warehouse personnel can complete follow-up medicine sorting, delivery and other processes. If the received single result represents that the order is failed, the execution body may push a page for representing that the order is failed to the user terminal.
The method provided by the embodiment of the application can access the E-commerce platform to the medical insurance systems in various places, unify the data format and the docking mode, and enable the user to order the medical insurance medicines on line.
In some optional implementations of this embodiment, the executing entity may determine whether a refund application sent by the user terminal is received. If a refund request sent by the user terminal is received, the execution body may send a refund request to the first server. The refund request may include the user account and order information corresponding to the drug to be refunded. The order information corresponding to the drug to be refunded may include, but is not limited to: drug identification, drug number and time of order for the drug to be refunded. After receiving the refund request, the first server may determine whether the drug to be refunded meets a refund condition. 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 time and a current time of the drug to be refunded, and if the time difference does not exceed 15 days, the refund operation may be performed on the drug to be refunded. As another example, the refund condition may further include that the order time and the refund applying time are the same year, and the first server may determine whether the order time and the refund applying time of the medicine to be refunded are the same year, and if so, may execute the refund operation on the medicine to be refunded. It should be noted that, the refund condition may be modified accordingly according to the service. And after determining that the refund operation can be performed on the drug to be refunded, the first server may perform the refund operation, for example, may refund the funds of the individual payment amount of the user to the funds account of the user in a primary way, and refund the funds of the medical insurance reimbursement amount to the medical insurance card account of the user. If it is determined that the refund operation is successfully executed, the first server may generate a refund result for indicating that the refund is successful. If it is determined that the refund operation fails to be executed, the first server may generate a refund result for characterizing the refund failure. 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". Then, the execution body may receive a refund result returned from 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 body may push, to the user terminal, a prompt message for representing that the refund is successful.
In some optional implementations of this embodiment, the executing body may determine whether a query application sent by the user terminal for querying a balance of the medical insurance card is received. If a query request for querying the balance of the medical insurance card is received, the execution 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 executive body can receive the balance of the medical insurance card returned by the first server. The executing entity may then push the medical insurance card balance to the user terminal.
In some optional implementations of this embodiment, the executing entity may determine whether an order query request is received. The order query request may include order query conditions, such as a medical insurance area, a purchase channel (online, offline), and the like. If the order inquiry request is received, the execution body may select a target order from the candidate orders to push by using the order inquiry condition. The candidate orders may be orders stored in the execution body, or orders within a preset period of time. As an example, if the order query condition is "beijing" in the medical insurance area, the executing entity may select an order corresponding to "beijing" in the medical insurance area from the candidate orders as the target order for pushing. If the order query condition is the start time "5 month 1 number" and the end time "5 month 10 number", the execution subject may select the order with the order placing time in the time period from the start time "5 month 1 number" to the end time "5 month 10 number" from the candidate order as the target order to push.
With continued reference to fig. 3, fig. 3 is a timing diagram of an embodiment of a method of ordering medical insurance drugs according to the present embodiment.
As shown in fig. 3, in step 301, an order server receives a settlement request for a medical insurance drug sent by a user terminal.
Here, the order server may determine whether a settlement request for the medical insurance drug is received. Medical insurance medicines generally refer to basic medical insurance medicines, and a specific range can be managed by making a basic medical insurance medicine catalogue. After clicking the "settlement" icon in the purchase page of the medical insurance medicine on the user terminal, the ordering server may receive a settlement request for the medical insurance medicine.
In step 302, the order server determines whether the user account from which the settlement request originated is bound to the medical insurance card.
Here, the order server may determine whether the user account from which the settlement request originated is bound to the medical insurance card. If it is determined that the user account from which the settlement request originated is bound to the medical insurance card, the order server may execute step 303.
In step 303, if the user account from which the settlement request originates is bound to the medical insurance card, the order 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 originated is bound to the medical insurance card, the order server may send a pre-settlement request to the first server. Pre-settlement is generally referred to herein as a pre-estimation of the price of the medical insurance drug purchased by the user. The pre-settlement request may include information of a medical insurance card, where the medical insurance card information may include a medical insurance area to which the medical insurance card of the user indicated by the user account number belongs, and the medical insurance area may be a municipal area. The first server is typically configured to process a settlement request for medical insurance medicines in the medical insurance area. The first server is generally 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 transmits the pre-settlement result to the order server.
Here, the pre-settlement request may further include medicine information, which may include medicine identification, medicine price, medicine quantity, medicine manufacturer, and medicine dosage form. After receiving the pre-settlement request, the first server can acquire the medical insurance reimbursement amount corresponding to the medicine identifier. The difference between the price of the drug and the amount of the medical insurance reimbursement may then be determined as the individual payment amount. Pre-settlement results may then be generated that include the medical insurance reimbursement amount and the personal payment amount. The first server may transmit the pre-settlement result to the order server. The pre-settlement result may also include a medicine price, for example, the pre-settlement result may include a medicine price of 32 yuan for 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 order server pushes an order page to the user terminal that includes the medical insurance reimbursement amount and the personal payment amount.
Here, the order server may push an order 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 order server.
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 order placing server by clicking an icon of submitting an order in the order placing page.
In step 307, the order server sends an order request to the first server.
Here, if the order placing server receives the order submitting request returned by the user terminal, the order placing server may send the order placing request to the first server. After receiving the order placing request sent by the order placing server, the first server can acquire the balance in the medical insurance card bound by the user account, and then the first server can determine whether the balance in the medical insurance card bound by the user account is larger than the medical insurance reimbursement amount. If the balance is greater than the medical insurance reimbursement amount, the first server may generate an order outcome for characterizing successful order placement. If the balance is less than the medical insurance reimbursement amount, the first server may generate an order result used to characterize the order failure.
In step 308, the order server receives the order result returned by the first server.
Here, the order server may receive the order result returned by the first server. If the received ordering result represents successful ordering, the ordering server can push a page for representing successful ordering to the user terminal, and then the ordering server can send order information for the medical insurance medicine to a warehouse terminal of a designated warehouse, so that warehouse personnel can complete follow-up medicine sorting, delivery and other processes. If the received ordering result represents the ordering failure, 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 the medical insurance systems in various places, unify the data format and the docking mode, and enable the user to order the medical insurance medicines on line.
With further reference to fig. 4, a flow 400 of yet another embodiment of a method of ordering medical insurance drugs is shown. The process 400 of the ordering method of the medical insurance medicine comprises the following steps:
in step 401, in response to receiving a settlement request for a medical insurance drug, it is determined whether a user account from which the settlement request originated is bound to a medical insurance card.
In this embodiment, step 401 may be performed in a similar manner to step 201, and will not be described here.
Step 402, if the user account from which the settlement request originates is not bound to the medical insurance card, 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.
In this embodiment, if it is determined in step 401 that the user account from which the settlement request originates is not bound to the medical insurance card, the execution subject of the method for ordering medical insurance medicines (for example, the ordering server shown in fig. 1) may push the medical insurance card binding page to the user terminal from which the settlement request originates. The user may fill in the card binding page with the card information (e.g., name, gender, age, identification number, phone number, mailbox, home address, card number, province, etc.), and then click on the "ok" icon to send the filled-in information to the executing body.
And then, the execution main body can receive a binding application which is returned by the user terminal and comprises the medical insurance card information.
Step 403, sending a binding request including the received medical insurance card information to the second server, and receiving a binding result returned by the second server.
In this embodiment, the executing body 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 a medical insurance card management system running therein. The second server can manage the medical insurance card by using the medical insurance card saving management system.
As an example, the second server may store the user's medical insurance card information (for example, an identification card number) in advance, and the second server may match the locally stored user's medical insurance card information with the medical insurance card information submitted by the user, and if the matching fails, may generate a binding result for representing that the binding fails. 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, may generate a binding result for representing a binding failure. 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, if 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.
And then, the execution body can receive the binding result returned by the second server.
Here, the character "1" or "T" may be utilized to characterize the binding success. The character "0" or "F" may be used to characterize binding failure.
Step 404, if the binding result represents that the medical insurance card is successfully bound, the user account is bound with the medical insurance card information.
In this embodiment, the executing body 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 executing body can bind the user account with the medical insurance card information. Binding may be understood as setting a correspondence between the user account and the medical insurance card information.
Step 405, sending a pre-settlement request to the first server, and receiving a pre-settlement result returned by the first server.
In this embodiment, the execution body may send a pre-settlement request to the first server. Pre-settlement is generally referred to herein as a pre-estimation of the price of the medical insurance drug purchased by the user. The pre-settlement request may include information of a medical insurance card, where the medical insurance card information may include a medical insurance area to which the medical insurance card of the user indicated by the user account number belongs, and the medical insurance area may be a municipal area. The first server is typically configured to process a settlement request for medical insurance medicines in the medical insurance area. The first server is generally 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 medicine information, which may include medicine identification, medicine price, medicine quantity, medicine manufacturer, and medicine dosage form. After receiving the pre-settlement request, the first server can acquire the medical insurance reimbursement amount corresponding to the medicine identifier. The difference between the price of the drug and the amount of the medical insurance reimbursement may then be determined as the individual payment amount. Pre-settlement results may then be generated that include the medical insurance reimbursement amount and the personal payment amount. The pre-settlement result may also include a medicine price, for example, the pre-settlement result may include a medicine price of 32 yuan for the medical insurance medicine a, a medical insurance reimbursement amount of 10 yuan, and a personal payment amount of 22 yuan.
Then, the executing body may receive a pre-settlement result returned from the first server.
Step 406, pushing an order page including the medical insurance reimbursement amount and the personal payment amount to the user terminal from which the settlement request is originated.
Step 407, in response to receiving the 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 this embodiment, steps 406-407 and steps 203-204 are performed, and are not described herein.
As can be seen from fig. 4, compared with the embodiment corresponding to fig. 2, the process 400 of the method for ordering the medical insurance medicine in this embodiment reflects 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 foregoing figures, the present application provides an embodiment of a device for ordering medical insurance medicines, where the embodiment of the device corresponds to the embodiment of the method shown in fig. 2, and the device may be specifically applied to various electronic devices.
As shown in fig. 5, the ordering device 500 of the medical insurance medicine of the present embodiment includes: a determining 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, in response to receiving a settlement request for a medical insurance medicine, whether a user account from which the settlement request originates is bound to the medical insurance card; the first receiving unit 502 is configured to send a pre-settlement request to the first server if a user account from which the settlement request originates is bound with a medical insurance card, and receive a pre-settlement result returned by the first server, where the pre-settlement request includes medical insurance card information, the medical insurance card information includes a medical insurance area to which a medical insurance card of a user indicated by the user account belongs, and the first server is configured to process the settlement request of the medical insurance medicine for 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, to a user terminal from which the settlement request originates, a lower order page including a medical insurance reimbursement amount and a personal payment amount; the second receiving unit 504 is configured to send an order placing request to the first server in response to receiving an order submission request returned by the user terminal, and to 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 device 500 for medical insurance drugs may refer to step 201, step 202, step 203, and step 204 in the corresponding embodiment of fig. 2.
In some optional implementations of this embodiment, the ordering device 500 of the medical insurance drug 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 with 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 card binding page with the card information (e.g., name, gender, age, identification number, phone number, mailbox, home address, card number, province, etc.), and then click on the "ok" icon to send the filled-in information to the executing body. And then, the third receiving unit can receive a binding application which is returned by the user terminal and comprises the medical insurance card information. 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 a medical insurance card management system running therein. The second server can manage the medical insurance card by using the medical insurance card saving management system. As an example, the second server may store the user's medical insurance card information (for example, an identification card number) in advance, and the second server may match the locally stored user's medical insurance card information with the medical insurance card information submitted by the user, and if the matching fails, may generate a binding result for representing that the binding fails. 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, may generate a binding result for representing a binding failure. 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, if 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. Then, the fourth receiving unit may receive the binding result returned by the second server. Here, the character "1" or "T" may be utilized to characterize the binding success. The character "0" or "F" may be used to characterize binding failure. The binding unit may determine whether the binding result characterizes successful binding of the medical insurance card. If the binding result represents that the medical insurance card is successfully bound, and if the binding result is determined to be 1 or T, the binding unit can bind the user account with the medical insurance card information. Binding may be understood as setting a correspondence between the user account and the medical insurance card information.
In some optional implementations of this embodiment, the ordering device 500 of the medical insurance drug may further include: a first transmitting 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. If a refund request sent by the user terminal is received, the first sending unit may send a refund request to the first server. The refund request may include the user account and order information corresponding to the drug to be refunded. The order information corresponding to the drug to be refunded may include, but is not limited to: drug identification, drug number and time of order for the drug to be refunded. After receiving the refund request, the first server may determine whether the drug to be refunded meets a refund condition. 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 time and a current time of the drug to be refunded, and if the time difference does not exceed 15 days, the refund operation may be performed on the drug to be refunded. As another example, the refund condition may further include that the order time and the refund applying time are the same year, and the first server may determine whether the order time and the refund applying time of the medicine to be refunded are the same year, and if so, may execute the refund operation on the medicine to be refunded. It should be noted that, the refund condition may be modified accordingly according to the service. And after determining that the refund operation can be performed on the drug to be refunded, the first server may perform the refund operation, for example, may refund the funds of the individual payment amount of the user to the funds account of the user in a primary way, and refund the funds of the medical insurance reimbursement amount to the medical insurance card account of the user. If it is determined that the refund operation is successfully executed, the first server may generate a refund result for indicating that the refund is successful. If it is determined that the refund operation fails to be executed, the first server may generate a refund result for characterizing the refund failure. 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". Then, the fifth receiving unit may receive a refund result returned from 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, to the user terminal, a prompt message for representing that the refund is successful.
In some optional implementations of this embodiment, the ordering device 500 of the medical insurance drug may further include: a second transmitting unit (not shown), a sixth receiving unit (not shown), and a third pushing unit (not shown). The second sending unit may determine whether a query application for querying the balance of the medical insurance card sent by the user terminal is received. If a query request for querying the balance of the medical insurance card sent by the user terminal is received, 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. And then, the sixth receiving unit can 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 this embodiment, the ordering device 500 of the medical insurance drug may further include: a pick unit (not shown). The selection unit may determine whether an order query request is received. The order query request may include order query conditions, such as a medical insurance area, a purchase channel (online, offline), and the like. If the order inquiry request is received, the selecting unit may select a target order from the candidate orders for pushing by using the order inquiry condition. The candidate orders may be orders stored in the execution body, or orders within a preset period of time. As an example, if the order query condition is "beijing" in the medical insurance area, the selecting unit may select, from the candidate orders, an order corresponding to "beijing" in the medical insurance area as the target order for pushing. If the order query condition is the start time "5 month 1 number" and the end time "5 month 10 number", the selecting unit may select, from the candidate orders, the order with the order placing time in the time period from the start time "5 month 1 number" to the end time "5 month 10 number" as the target order for pushing.
Referring now to fig. 6, a schematic diagram of an electronic device (e.g., the order server of fig. 1) 600 suitable for use in implementing embodiments of the present disclosure is shown. The server illustrated in fig. 6 is merely an example, and should not be construed as limiting the functionality and scope of use of the embodiments of the present disclosure in any way.
As shown in fig. 6, the electronic device 600 may include a processing means (e.g., a central processing unit, a graphics processor, etc.) 601, which may perform various appropriate actions and processes according to 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 required 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 through a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.
In general, the following devices may be connected to the I/O interface 605: input devices 606 including, for example, a touch screen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, and the like; an output device 607 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 608 including, for example, magnetic 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 shows an electronic device 600 having various means, it is to be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may be implemented or provided instead. Each block shown in fig. 6 may represent one device or a plurality of devices as needed.
In particular, according to embodiments of the present disclosure, the processes described above with reference to 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 shown in the flowcharts. In such an embodiment, the computer program may be downloaded and installed from a network via communication means 609, or from storage means 608, or from ROM 602. The above-described functions defined in the methods of the embodiments of the present disclosure are performed when the computer program is executed by the processing means 601. It should be noted that, the computer readable medium according to 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. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any 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 an embodiment of the present 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. Whereas in embodiments of the present disclosure, the computer-readable signal medium may comprise a data signal propagated in baseband or as part of a carrier wave, with computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. 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, fiber optic cables, RF (radio frequency), and the like, or any suitable combination of the foregoing.
The computer readable medium may be contained in the electronic device; or may exist alone without being incorporated 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 the medical insurance medicine, determining whether a user account from which the settlement request originates is bound with the medical insurance card; if so, a pre-settlement request is sent to a first server, and a pre-settlement result returned by the first server is received, 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 of medical insurance medicines aiming at the medical insurance area, and the pre-settlement result comprises medical insurance reimbursement amount and personal payment amount; pushing a bill ordering page comprising medical insurance reimbursement amount and personal payment amount to a user terminal from which the settlement request is sent; and responding to the receiving 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 of embodiments of the present disclosure may be written in 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 kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).
The flowcharts 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 involved in the embodiments described in the present disclosure may be implemented by means of software, or may be implemented by means of hardware. The described units may also be provided in a processor, for example, described as: a processor includes a determination unit, a first receiving unit, a first pushing unit, and a second receiving unit. The names of these units do not constitute a limitation on the unit itself in some cases, and for example, the first pushing unit may also be described as "a unit that pushes a lower page including a medical insurance reimbursement amount and a personal payment amount to a user terminal from which a settlement request originates".
The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being 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 technical features, but encompasses other technical features formed by any combination of the above technical features or their equivalents without departing from the spirit of the invention. Such as the above-described features, are mutually substituted with (but not limited to) the features having similar functions disclosed in the embodiments of the present disclosure.
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, a pre-settlement request is sent to a first server, and a pre-settlement result returned by the first server is received, 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 of medical insurance medicines aiming at the medical insurance area, the pre-settlement result comprises a medical insurance reimbursement amount and a personal payment amount, a local medical insurance system corresponding to the medical insurance area is operated in the first server, and the first server utilizes the local medical insurance system to process the settlement request;
Pushing a bill making page comprising the medical insurance reimbursement amount and the personal payment amount to a user terminal from which the settlement request is sent;
And responding to the received order submitting request returned by the user terminal, sending an order placing request to the first server, so that the first server generates an order placing result based on the balance in the medical insurance card bound by the user account and the judgment result of the medical insurance reimbursement amount, and receiving the 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 originated 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 comprising medical insurance card information returned by the user terminal;
sending a binding request comprising 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:
Responding to a refund application sent by the user terminal, and sending a refund request to the first server, wherein the refund request comprises the user account and order information corresponding to the medicine 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:
Responding to a query application which is sent by the user terminal and used for querying the balance of the medical insurance card, and sending a balance query request to the first server, wherein the balance query request comprises the user account;
receiving the balance of the medical insurance card returned by the first server;
pushing the medical insurance card balance to the user terminal.
5. The method of claim 1, wherein the method further comprises:
In response to receiving an order query request including an order query condition, a target order is selected from the candidate orders for pushing using the order query condition.
6. A medical insurance drug ordering device, comprising:
A determining 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 if a user account from which the settlement request is sent is bound with a medical insurance card, and receive 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 the settlement request of medical insurance medicines for the medical insurance area, the pre-settlement result comprises a medical insurance reimbursement amount and a personal payment amount, a local medical insurance system corresponding to the medical insurance area is operated in the first server, and the first server processes the settlement request by using the local medical insurance system;
a first pushing unit configured to push, to a user terminal from which the settlement request originates, a lower order page including the medical insurance reimbursement amount and the individual payment amount;
the second receiving unit is configured to respond to receiving an order submitting request returned by the user terminal, send an order placing request to the first server, enable the first server to generate an order placing result based on the balance in the medical insurance card bound by the user account and the judgment result of the medical insurance reimbursement amount, and receive the order placing result returned by the first server.
7. The apparatus of claim 6, wherein 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 comprising medical insurance card information returned by the user terminal if the user account from which the settlement request is sent is not bound with the medical insurance card;
The fourth receiving unit is configured to send a binding request comprising 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 successful binding of the medical insurance card.
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 information corresponding to a medicine to be refunded;
the fifth receiving unit is configured to receive a refund result returned by the first server;
And the second pushing unit is configured to push prompt information for representing successful refund to the user terminal if the refund result represents successful refund.
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, causes the one or more processors to implement the method of any of claims 1-5.
10. A computer readable medium having stored thereon a computer program, wherein the program when executed by a processor implements the method of any of claims 1-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010603400.7A CN112308552B (en) | 2020-06-29 | 2020-06-29 | Method and device for ordering medical insurance medicine |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010603400.7A CN112308552B (en) | 2020-06-29 | 2020-06-29 | Method and device for ordering medical insurance medicine |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112308552A CN112308552A (en) | 2021-02-02 |
| CN112308552B true CN112308552B (en) | 2024-08-16 |
Family
ID=74483454
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010603400.7A Active CN112308552B (en) | 2020-06-29 | 2020-06-29 | Method and device for ordering medical insurance medicine |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112308552B (en) |
Families Citing this family (7)
| 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 |
| CN113989060B (en) * | 2021-12-23 | 2023-02-03 | 浙江口碑网络技术有限公司 | Medical service order processing method and device and electronic equipment |
| CN114897535A (en) * | 2022-06-01 | 2022-08-12 | 北京京东拓先科技有限公司 | Payment method, device and system |
| CN115510338B (en) * | 2022-09-27 | 2024-03-12 | 北京三快在线科技有限公司 | Information recommendation method and device, storage medium and electronic equipment |
| CN115358829B (en) * | 2022-10-19 | 2023-04-07 | 北京京东拓先科技有限公司 | Article transaction data processing method and device, storage medium and electronic equipment |
| CN115797011A (en) * | 2022-11-30 | 2023-03-14 | 泰康保险集团股份有限公司 | Online order processing method, device and equipment |
| CN117350627B (en) * | 2023-10-18 | 2024-04-09 | 杭州正马软件科技有限公司 | E-commerce logistics package interception system and automatic refund method |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
Family Cites Families (4)
| 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 |
| CN107895168A (en) * | 2017-10-13 | 2018-04-10 | 平安科技（深圳）有限公司 | The method of data processing, the device of data processing and computer-readable recording medium |
-
2020
- 2020-06-29 CN CN202010603400.7A patent/CN112308552B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112308552A (en) | 2021-02-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112308552B (en) | Method and device for ordering medical insurance medicine | |
| CN113379523A (en) | Bill generation method, device, medium and electronic equipment | |
| CN111857888B (en) | Transaction processing method and device | |
| CN114997977A (en) | Data processing method and device, electronic equipment and computer readable medium | |
| CN112182400B (en) | Message processing method, message processing device, electronic equipment and storage medium | |
| CN113627835A (en) | Distribution management method and device | |
| CN114626841A (en) | Resource transfer processing method, device, computer device, medium, and program product | |
| CN114169863A (en) | Signing method, signing device, electronic equipment and computer readable medium | |
| CN112241866B (en) | Service processing method and device, computer readable medium and electronic equipment | |
| CN111695985A (en) | System and method for processing voluntary deposit service of accumulation fund | |
| US20230162145A1 (en) | Ex-warehouse control method, device and system | |
| US20220058599A1 (en) | Settlement operation support system and settlement operation support method | |
| CN108346095A (en) | Management-control method, device, equipment and the computer readable storage medium of association system | |
| CN111210349A (en) | Virtual asset transfer hosting method and device, electronic equipment and storage medium | |
| CN112308661B (en) | Order processing method and device | |
| CN112581179B (en) | Electronic coupon generation method and generation device | |
| CN112348612B (en) | Order generation method and device | |
| CN112232943A (en) | Method and device for multi-mode binding of virtual account | |
| CN113850685B (en) | Method, device, server and medium for real-time adjustment | |
| CN112036898B (en) | Payment mode determining method and device, electronic equipment and storage medium | |
| CN115545707A (en) | Transaction result confirmation method, transaction result sending device, electronic equipment and medium | |
| CN113469795A (en) | Order payment substitute method and device | |
| CN112966043A (en) | Data processing method, device, computer system and storage medium | |
| CN111784429B (en) | Information push method and device | |
| CN113822661A (en) | Payment method, device and system |
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. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |