JP7557802B2 - Pharmacy support system and pharmacy support method - Google Patents

Description

The present invention relates to a pharmacy support system and a pharmacy support method, and can be applied to a system that supports, for example, transactions between pharmacies and customers (patients) and tasks related to drug guidance.

Conventionally, an information system for supporting (assisting) the operations of dispensing pharmacies has been disclosed, for example, in the technology described in Patent Document 1.

Patent Document 1 describes a system for supporting pharmacists in providing medication instructions to patients. In order to facilitate the building of a relationship of trust between customers (patients) and pharmacists (pharmacy staff), the system described in Patent Document 1 displays an introduction of the pharmacist and a list of prescribed medications on a mobile device presented to the customer, and stores the information presented to the customer as the customer's medical history.

JP 2018-60526 A

Nowadays, pharmacies are expected to not only dispense prescription drugs, but also provide comprehensive support for customers' health, such as acting as "family pharmacies" and "health support pharmacies." However, there is a problem in that there is a shortage of pharmacists who can carry out these tasks.

For example, a family pharmacy is required to be able to handle customer inquiries 24 hours a day and to visit customers at their homes to deliver prescription drugs, but a conventional pharmacy support system such as that described in Patent Document 1 alone is not able to reduce the workload of family pharmacies (pharmacists) or health support pharmacies, or provide support that is useful for improving the health of customers.

In light of the above problems, there is a need for a pharmacy support system and method that can reduce the workload of pharmacies while promoting the health of customers (patients).

The first invention is characterized by having a pharmacy account on a message processing system corresponding to a pharmacy, an account management means for managing customer accounts on the message processing system corresponding to customers of the pharmacy, a prescription management means for accepting input via the customer account in the message processing system and managing the contents of prescriptions dispensed to the customers, a message processing means for transmitting , for each prescription, a question message asking a question regarding the situation after taking the medicine dispensed according to the prescription and a choice message of answers to the question message from the pharmacy account to the customer account in accordance with a scenario corresponding to the contents of the prescription, and receiving the choice message related to the answer to the question message sent from the customer account to the pharmacy account via the message processing system , a message management means for managing the question message and the choice message related to the answer, and a pharmacy terminal processing means for supplying messages managed by the message management means to a pharmacy terminal located at the pharmacy.

The second present invention is a pharmacy support method comprising an account management means, a prescription management means, a message processing means, a message management means, and a pharmacy terminal processing means, wherein the account management means manages a pharmacy account on a message processing system corresponding to the pharmacy and a customer account on the message processing system corresponding to a customer of the pharmacy, the prescription management means accepts input of and manages the contents of a prescription dispensed to the customer via the customer account in the message processing system , the message processing means transmits, for each prescription, a question message asking a question about the situation after taking a drug dispensed according to the prescription and a choice message of answers to the question message from the pharmacy account to the customer account in accordance with a scenario corresponding to the contents of the prescription, and is capable of receiving the choice message related to the answer to the question message transmitted from the customer account to the pharmacy account via the message processing system, the message management means is capable of managing the question message and the choice message related to the answer, and the pharmacy terminal processing means supplies the message managed by the message management means to a pharmacy terminal arranged at the pharmacy.

The present invention makes it possible to promote the health of customers while reducing the workload of pharmacies.

FIG. 2 is a block diagram showing a connection configuration of each device related to the first embodiment. FIG. 2 is a block diagram showing a functional configuration of a Web application server according to the first embodiment. FIG. 2 is a block diagram showing a functional configuration of a database server according to the first embodiment. 2 is a block diagram showing the functional configuration of a pharmacy terminal according to the first embodiment. FIG. FIG. 2 is a block diagram showing a functional configuration of a customer terminal according to the first embodiment. FIG. 2 is a diagram illustrating an example of a configuration of a pharmacy database according to the first embodiment. FIG. 2 is a diagram illustrating an example of a configuration of a customer database according to the first embodiment. FIG. 2 is a diagram illustrating an example of a configuration of an MS customer management database according to the first embodiment. 3 is a diagram showing an example of the configuration of an MS pharmacy management database according to the first embodiment. FIG. FIG. 2 is a diagram showing an example of the configuration of a prescription reservation database according to the first embodiment. FIG. 2 is a diagram showing an example of the configuration of a prescription database according to the first embodiment. FIG. 2 is a diagram showing an example of the configuration of a prescription drug database according to the first embodiment. FIG. 2 is a diagram showing an example of the configuration of a health consultation conversation database according to the first embodiment. 1 is a flowchart showing an example (scenario) of the operation of the pharmacy support system according to the first embodiment. FIG. 11 is a diagram (part 1) showing an example of a Web screen presented by a portal processing unit according to the first embodiment; FIG. 11 is a diagram (part 2) showing an example of a Web screen presented by a portal processing unit according to the first embodiment; FIG. 11 is a diagram (part 1) showing an example of a scenario of automatic dialogue processing transmitted and received by a health consultation processing unit and a message processing unit according to the first embodiment. FIG. 2 is a diagram (part 2) showing an example of a scenario of automatic dialogue processing transmitted and received by a health consultation processing unit and a message processing unit according to the first embodiment; 1 is an explanatory diagram showing an example of the configuration of a prescription drug information sheet according to the first embodiment. FIG. FIG. 11 is a diagram (part 3) showing an example of a scenario of automatic dialogue processing transmitted and received by a health consultation processing unit and a message processing unit according to the first embodiment. FIG. 4 is a diagram (part 4) showing an example of a scenario of automatic dialogue processing transmitted and received by a health consultation processing unit and a message processing unit according to the first embodiment. FIG. 11 is a block diagram showing a functional configuration of a Web application server according to a second embodiment. FIG. 11 is a block diagram showing a functional configuration of a database server according to a second embodiment. FIG. 11 is a block diagram showing an example of the configuration of message link information held in a Web application server according to the second embodiment;

(A) First Embodiment Hereinafter, a first embodiment of a pharmacy support system and a pharmacy support method according to the present invention will be described in detail with reference to the drawings.

(A-1) Configuration of the First Embodiment FIG. 1 is a block diagram showing the connection configuration of each device related to the first embodiment.

The pharmacy support system 1 is a system that supports the operations of dispensing pharmacies to reduce the workload of pharmacy staff (pharmacists, etc.) and promote the health of the customers (patients) of the pharmacies it supports.

The pharmacy support system 1 shown in FIG. 1 is equipped with devices including a web application server 10 and a database server 20. Note that in FIG. 1, the reference characters in parentheses are used only in the second embodiment described later.

The pharmacy support system 1 is also connected to a pharmacy terminal 30, a customer terminal 40, and a message service system 50 via a network NW. The network NW corresponds to an IP network such as the Internet. Furthermore, the number of devices connected to the pharmacy support system 1 is not limited. The number of pharmacies and customers that use the pharmacy support system 1 is not limited.

As the message service system 50, various message service (chat service) systems such as LINE (registered trademark), Facebook (registered trademark), Skype (registered trademark), etc., can be applied. In the following, an example will be described in which the message service system 50 uses the LINE service of the version at the time of filing.

The web application server 10 is a device that provides web-based applications (application services) to each terminal in the pharmacy support system 1. The database server 20 is arranged as a means for managing various data in the web application server 10. In the pharmacy support system 1 shown in FIG. 1, the web application server 10 and the database server 20 are assumed to be arranged in a data center.

The pharmacy terminal 30 is a terminal installed in a pharmacy that receives services (business support) from the web application server 10. The pharmacy terminal 30 may be, for example, a tablet or a PC. In addition, the pharmacy terminal 30 is connected to a printer 60 that can print itemized statements and the like.

The customer terminal 40 is a terminal carried by the customer. For example, a mobile terminal such as a smartphone or tablet can be used as the customer terminal.

Next, we will explain the internal configuration of each device that makes up the pharmacy support system 1.

Figure 2 is a block diagram showing the internal configuration of the web application server 10.

The internal configuration of the web application server 10 can be functionally shown as in Figure 2. The web application server 10 can be constructed, for example, using a computer (e.g., a PC or a workstation) that has a memory and a processor.

The web application server 10 can be realized, for example, by executing a program (e.g., a program using HTML, PHP, etc.) in an environment of middleware for various web servers (e.g., so-called Apache, Nginx, etc.).

In the first embodiment, the program (the pharmacy support program according to the embodiment) incorporated in the Web application server 10 includes the modules of the portal processing unit 11, prescription reservation processing unit 12, in-store service processing unit 13, health consultation processing unit 14, and message processing unit 15 shown in FIG. 3. Note that the combination of modules included in the pharmacy support program of the first embodiment is not limited to the above example. Details of each module constituting the Web application server 10 will be described later.

Figure 3 is a block diagram showing the internal configuration of the database server 20.

The database server 20 is a device that provides various data required for the processing of the web application server 10.

The database server 20 has a database processing unit 21 and a data recording unit 22.

The internal configuration of the database server 20 can be functionally shown as in FIG. 3. The database server 20 can be constructed, for example, using a computer (e.g., a PC or a workstation) having a memory and a processor.

As shown in FIG. 3, the database server 20 has a database processing unit 21 and a data recording unit 22.

The data recording unit 22 is a data recording means for recording various data used in each process in the database server 20. As shown in FIG. 3, the data recording unit 22 records at least a pharmacy database 221, a customer database 222, an MS customer management database 223, an MS pharmacy management database 224, a prescription reservation database 225, a prescription database 226, a prescription drug database 227, and a health consultation conversation database 228. The detailed configuration of each data recorded in the data recording unit 22 will be described later.

The database processing unit 21 processes data of the databases recorded in the data recording unit 22. The database processing unit 21 can be constructed, for example, using various DBMSs (Database Management Systems). Therefore, each database recorded in the data recording unit 22 must be configured with a data structure that is compatible with the database processing unit 21. The database processing unit 21 processes data of each database recorded in the data recording unit 22 (for example, updating or reading data) in response to a request (command) from the Web application server 10.

Next, we will explain the internal configuration of the pharmacy terminal 30.

Figure 4 is a block diagram showing an example of the internal configuration of the pharmacy terminal 30.

The pharmacy terminal 30 can be constructed using various terminal devices (computers; hardware), such as a PC or a tablet PC. Figure 4 shows an example in which a tablet PC is used as hardware for the pharmacy terminal 30.

As shown in FIG. 4, the pharmacy terminal 30 functionally has a touch panel display 31 and a web browser 43.

The touch panel display 31 is a device (a device that performs the function of a user interface) that outputs information to the pharmacy staff carrying the pharmacy terminal 30 and accepts input from the pharmacy staff (e.g., input using a GUI screen). In the first embodiment, an example is shown in which the pharmacy terminal 30 is constructed using a tablet PC, but the type of device that performs the user interface (means for input from the pharmacy staff and means for output to the pharmacy staff) in the pharmacy terminal 30 is not limited.

Various web browsers can be used as the web browser 43. The web browser 43 of the pharmacy terminal 30 can access the web application server 10 to receive and execute a web application program for the pharmacy. The pharmacy terminal 30 may be configured so that the application program for the pharmacy is installed as a dedicated application rather than a web-based application. Here, it is assumed that the web browser 43 also has installed therein a program (plug-in) that can access and log in to the message service system 50 (message service). It is also assumed that the plug-in of the web browser 43 has the MS account ID and password of the user using the customer terminal 40 set therein.

Next, we will explain the internal configuration of the customer terminal 40.

Figure 5 is an explanatory diagram showing an example of the internal configuration of the customer terminal 40.

The customer terminal 40 can be constructed using various terminal devices (computers; hardware), such as a smartphone, a PC, a tablet PC, etc. FIG. 5 shows an example in which a smartphone is used as the hardware of the customer terminal 40.

As shown in FIG. 5, the customer terminal 40 functionally has a touch panel display 41, a camera 42, a web browser 43, and a message service AP 44.

The touch panel display 41 is a device (a device that performs the function of a user interface) that outputs information to a customer who possesses the customer terminal 40 and accepts input from the customer (for example, input using a GUI screen). In the first embodiment, an example is shown in which the customer terminal 40 is constructed using a smartphone, but the type of device that performs the user interface (means for input from the customer and means for output to the customer) in the customer terminal 40 is not limited.

Various web browsers can be used as the web browser 43. The web browser 43 of the customer terminal 40 can access the web application server 10 to receive and execute a web application program for the customer. Note that the customer terminal 40 may be configured so that the application program for the customer is installed as a dedicated application rather than as a web-based application.

The camera 42 can be activated, for example, in response to a call from another program (such as a web browser 43 or a message service AP 44), and can capture an image (for example, an image of a prescription or a two-dimensional barcode) in response to a customer's operation and output the captured image data.

The message service AP44 is an application program that sends and receives messages with the message service system 50.

Next, we will provide an overview of each module that makes up the web application server 10.

The portal processing unit 11 is a module that provides the customer terminal 40 with portal functions such as pharmacy-related information and search services. In this case, the portal processing unit 11 provides at least a service of searching for pharmacies where a prescription can be filled based on the prescription the customer possesses. The portal processing unit 11 presents the customer with pharmacy candidates based on the customer's operation (e.g., keywords or current location). In this case, the portal processing unit 11 provides not only the pharmacy's name and contact information, but also a link button for accessing the pharmacy's account on the message service system 50 (hereinafter referred to as the "message account" or "MS account").

The prescription reservation processing unit 12 is a module that performs processing to accept reservations for dispensing based on a prescription (hereinafter referred to as "prescription reservations") from a customer (customer terminal 40). The prescription reservation processing unit 12 may provide a web screen (GUI screen) that can accept prescription reservations via a web connection from the customer terminal 40, but here, the prescription reservation processing unit 12 is also capable of processing to accept prescription reservations via a user interface via the message service system 50.

The in-store service processing unit 13 is a module that provides the pharmacy terminal 30 (web browser 43) with web screens (GUI screens) required for operations within the pharmacy, and provides various information and accepts processing requests.

The health consultation processing unit 14 is a module that handles the process of accepting health consultations from customers (customer terminals 40) via the message service system 50 and automatically conducting dialogue with customers (customer terminals 40).

The message processing unit 15 functions as an interface with the message service system 50. The message processing unit 15 performs processing to send and receive messages with the customer's MS account ID using the MS account ID of each pharmacy. The message processing unit 15 may be configured using an API (Application Programming Interface) function for connecting to the message service system 50 and exchanging messages, etc.

Next, an example of the configuration of each database (database) that constitutes the data recording unit 22 will be described. In the following, in order to simplify the explanation, each database (database) that constitutes the data recording unit 22 is illustrated in table format, but in reality, various database data structures can be used.

Figure 6 is an explanatory diagram showing an example of the configuration of the pharmacy database 221.

Pharmacy database 221 is a database for managing data related to each pharmacy.

In the pharmacy database 221 shown in FIG. 6, information including the "pharmacy ID," "pharmacy name," "address," and "telephone number" for identifying and managing the pharmacy is registered for each pharmacy.

Figure 7 is an explanatory diagram showing an example of the configuration of the customer database 222.

The customer database 222 is a database for managing data related to each customer (user).

In the customer database 222 shown in FIG. 7, information including "customer ID," "name," "date of birth," "gender," and "telephone number" is registered for each customer to identify and manage the customer.

Figure 8 is an explanatory diagram showing an example of the configuration of the MS customer management database 223.

The MS customer management database 223 is a database for managing the MS account ID of each customer (user).

In the MS customer management database 223 shown in FIG. 8, information including "customer ID" and "MS account ID" is registered for each customer.

Figure 9 is an explanatory diagram showing an example of the configuration of the MS pharmacy management database 224.

The MS pharmacy management database 224 is a database for managing the MS account ID of each pharmacy.

In the MS pharmacy management database 224 shown in FIG. 9, information on items including "pharmacy ID" and "MS account ID" is registered for each pharmacy.

Figure 10 is an explanatory diagram showing an example of the configuration of the prescription reservation database 225.

The prescription reservation database 225 is a database for managing prescription reservations accepted from customers through processing by the prescription reservation processing unit 12.

In the prescription reservation database 225 shown in FIG. 10, the following information is registered for each prescription reservation: a "prescription reservation ID" for identifying the prescription reservation, a "pharmacy ID" that is the destination of the prescription reservation, the "name" of the customer who made the prescription reservation, the "date of birth" of the customer who made the prescription reservation, the "reservation time" when the prescription reservation was accepted, "generic" indicating whether or not the customer wishes to be prescribed a generic drug (1: generic desired, 0: generic not desired), and "prescription image data" indicating data of an image of the prescription for the prescription reservation (hereinafter referred to as the "prescription image")

The prescription data item may be registered with the prescription image data itself or with link information for accessing the prescription image data file. In the first embodiment, the prescription reservation database 225 is configured to directly manage the prescription image data, but the specific database (table) structure is not limited, and multiple databases (tables) may be used for management.

Figure 11 is an explanatory diagram showing an example of the configuration of the prescription database 226.

The prescription database 226 is a database for managing records when prescriptions are filled based on prescriptions during processing by the in-store service processing unit 13.

In the prescription database 226 shown in FIG. 11, for each prescription, information is registered that includes a "prescription ID" for identifying the prescription, the "pharmacy ID" of the pharmacy that dispensed the prescription, the "customer ID" of the pharmacy that dispensed the prescription, and the "dispensing date" indicating the date that the prescription was dispensed.

Figure 12 is an explanatory diagram showing an example of the configuration of the prescription drug database 227.

The prescription drug database 227 is a database for managing each prescription drug prescribed for each prescription managed in the prescription database 226. For example, if any prescription managed in the prescription database 226 prescribes two prescription drugs, the data for the two prescription drugs corresponding to that prescription (the data for the two records) will be registered separately in the prescription drug database 227.

In the prescription drug database 227 shown in FIG. 12, for each prescription drug, there is stored a "prescription drug ID" to identify the prescription drug, a "prescription ID" to identify the prescription corresponding to that prescription drug, a "drug code", a "drug name", a "daily amount" indicating the prescribed amount of that prescription drug per day, a "dispensed amount" indicating the prescribed amount of that prescription drug (total amount prescribed), a "dosing interval" indicating the interval between taking the prescription drug (in hours), a "dosing interval text" indicating the interval between taking the prescription drug on a text basis (for example, a string of characters such as "after breakfast", "after breakfast, after dinner", etc.), and a "dosing interval text" indicating the day on which the prescription drug should be started. The information registered includes the following items: "Date to start taking the prescription drug", which indicates the date when the prescription drug is started; "Date to end taking the prescription drug", which indicates the midpoint of the entire period during which the prescription drug is taken; "Date to end taking the prescription drug", which indicates whether the timing of the date when the prescription drug is started to be taken will be notified to the customer via the message service system 50; "During taking the prescription drug, whether notification is possible", which indicates whether the timing of the date when the prescription drug is being taken will be notified to the customer via the message system; and "Date to end taking, whether notification is possible", which indicates whether the timing of the date when the prescription drug is stopped to be taken will be notified to the customer via the message service system 50.

Figure 13 is an explanatory diagram showing an example of the configuration of the health consultation conversation database 228.

The health consultation conversation database 228 is a database for managing the contents of messages exchanged between the pharmacy and the customer regarding health consultations conducted by the health consultation processing unit 14 (messages exchanged on the message service system 50). The health consultation conversation database 228 manages messages from the pharmacy to the customer and messages from the customer to the pharmacy separately. The health consultation conversation database 228 records data for each message (for "one message from the pharmacy to the customer" or "one message from the customer to the pharmacy").

In the health consultation conversation database 228 shown in FIG. 13, for each health consultation message, the following information is registered: a "message identification ID" for identifying the message, a "sent date and time" indicating the date and time the message was sent, a "pharmacy ID" for identifying the pharmacy receiving the health consultation, a "customer ID" for identifying the customer requesting the health consultation, a "conversation type" indicating the sender of the message (customer or pharmacy), and a "status" indicating whether the message has been read or unread (read or unread by pharmacy staff).

(A-2) Operation of the First Embodiment Next, an example of the operation of the pharmacy support system 1 of the first embodiment having the above-mentioned configuration (the pharmacy support method according to the embodiment) will be described.

Here, we will explain an example in which the Web application server 10 of the pharmacy support system 1 operates according to the scenario in Figure 14.

First, we will explain the overview of the scenario in Figure 14.

First, the Web application server 10 accepts a prescription reservation for AAA Pharmacy (a pharmacy with a store ID of "1") from a customer (customer terminal 40) named "Yamada Taro" and with an MS account ID of "taro_ms" via the portal function (function of the portal processing unit 11) and the message service system 50 (S101).

Next, the customer visits the pharmacy (AAA Pharmacy), the prescription is dispensed (the prescription drug is delivered based on the prescription) based on the reserved prescription for the customer, and the customer information and the prescription are registered by the function of the in-store service processing unit 13 (S102).

Next, it is assumed that a process is performed on the message service system 50 to associate the MS account ID of the customer with the MS account ID of the AAA pharmacy (e.g., registering the customer as a friend in the LINE service) (S103). This makes it possible to send a message from the MS account ID of the AAA pharmacy to the MS account ID of the customer (e.g., sending a message regarding a health consultation, etc.).

Then, using the function of the health consultation processing unit 14, messages are exchanged between the customer (customer terminal 40) and the customer via the message service system 50 at a timing based on the contents of the prescription (S104), and the exchanged messages (conversation contents) are saved (S105).

Then, the contents of the message exchanged with the customer are presented to the pharmacy staff by the functions of the in-store service processing unit 13 and the health consultation processing unit 14 (S106). In addition, by the functions of the in-store service processing unit 13 and the health consultation processing unit 14, the pharmacy staff can also perform processing to send messages, etc., in response to the health consultation to each customer.

Below, we'll provide specific examples of each step in the above scenario.

[S101: Prescription reservation reception process]
First, a specific example of the prescription reservation acceptance process in step S101 will be described.

First, we will explain the process of accepting a prescription reservation from the customer (customer terminal 40) in the Web application server 10 using the message service system 50 via the portal function (function of the portal processing unit 11).

Here, it is assumed that the customer terminal 40 (web browser 32) accesses a URL corresponding to the portal processing unit 11 of the web application server 10 in response to an operation by the customer. Here, it is assumed that the portal processing unit 11 provides the customer terminal 40 (web browser 32) with a web screen such as that shown in FIG. 15, for example.

The portal web screen shown in FIG. 15 includes a field F101 for accepting keyword input for searching for pharmacies, and a button B101 for accepting a search for pharmacies using the keywords entered in field F101.

Here, the portal processing unit 11 presents a web screen such as that shown in FIG. 15 on the customer terminal 40 (web browser 32), accepts a keyword search for pharmacies, and performs a search based on the keyword (for example, searches the pharmacy database 221 for pharmacies that match the keyword).

Then, the portal processing unit 11 presents a web screen displaying a list of the detected pharmacies on the customer terminal 40 (web browser 32). Here, it is assumed that the portal processing unit 11 presents a web screen such as that shown in FIG. 16.

The web screen shown in FIG. 16 displays a list of pharmacies including AAA Pharmacy (pharmacy with pharmacy ID 1) and BBB Pharmacy (pharmacy with pharmacy ID 2).

In FIG. 16, AAA Pharmacy is displayed in field F201, and BBB Pharmacy is displayed in field F202. In field F201, a button B201 (link) is placed for AAA Pharmacy to accept a prescription reservation via message service system 50. In addition, in field F202, a button B202 (link) is placed for BBB Pharmacy to accept a prescription reservation via message service system 50.

When a customer presses button B201 on the web screen shown in FIG. 16, the web browser 43 of the customer terminal 40 uses the message service plug-in function to log in to the message service system 50 (log in using a pre-set MS account ID and password) and starts the message service AP 33. As a result, the customer terminal 40 (message service AP 33) becomes capable of sending and receiving messages with the MS account ID (AAA_ms) of the AAA pharmacy based on the link information (MS account ID of the AAA pharmacy) set in button B201.

Meanwhile, in the Web application server 10, the message processing unit 15 uses the MS account ID (AAA_ms) of the AAA pharmacy to automatically communicate with the customer's MS account ID (taro_ms) (hereinafter referred to as "automatic dialogue processing"). During the automatic dialogue processing, the message processing unit 15 also cooperates with other modules as necessary to transmit and receive messages. During the automatic dialogue processing, the message processing unit 15 can send messages, present input options to the customer (presenting buttons with inputtable options), accept messages from the customer (including messages entered by selecting one of the presented options), and accept the upload of data from the customer (e.g., prescription image data).

17 and 18 show an example of automatic dialogue processing performed by the message processing unit 15 between the MS account ID (taro_ms) of the AAA pharmacy and the MS account ID (taro_ms) of the customer during prescription reservation reception processing. 17 and 18 show the contents displayed on the screen displayed by the message service AP44 of the customer terminal 40 when messages are transmitted and received between the MS account ID (AAA_ms) of the AAA pharmacy and the MS account ID (taro_ms) of the customer. 17 and 18 show messages sent from the MS account ID (AAA_ms) of the AAA pharmacy surrounded by a speech bubble from the left, and messages sent from the customer's MS account ID (taro_ms) (i.e., messages sent from the message service AP44 of the customer terminal 40) surrounded by a speech bubble from the right. In addition, in Figures 17 and 18, the buttons of options presented by the automatic dialogue process from the MS account ID (AAA_ms) of the AAA pharmacy are illustrated surrounded by dotted lines. This is also the case in Figures 20 and 21, which will be described later.

When the message processing unit 15 receives access to the AAA Pharmacy's MS account ID (AAA_ms) from the customer's MS account ID (taro_ms) via the message service system 50, it first presents a button to select either "health consultation" or "prescription reservation" along with a message indicating that the message has been received at the AAA Pharmacy's MS account ID (AAA_ms), as shown in FIG. 17(a). Here, it is assumed that the customer presses the "prescription reservation" button, and the message "prescription reservation" is sent from the customer terminal 40 (message service AP44).

Then, when the message processing unit 15 receives a "prescription reservation" message from the customer's MS account ID (taro_ms), it requests the prescription reservation processing unit 12 to start processing the prescription reservation from the customer's MS account ID (taro_ms) to the AAA Pharmacy's MS account ID (AAA_ms).

From then on, the prescription reservation processing unit 12 will perform automatic interactive processing of prescription reservations with the customer's MS account ID (taro_ms) via the message processing unit 15.

When the prescription reservation processing unit 12 starts automatic interactive processing of the prescription reservation processing with the customer's MS account ID (taro_ms), it first sends a message requesting the customer to input their name (free input) as shown in FIG. 17(b). Here, it is assumed that the prescription reservation processing unit 12 receives a message "Yamada Taro" from the customer's MS account ID (taro_ms) as a result of the customer's input operation on the customer terminal 40 (message service AP44).

Next, the prescription reservation processing unit 12 sends a message requesting input of the customer's telephone number (free input) as shown in FIG. 17(c), and receives a message "090-1234-5678" from the customer's MS account ID (taro_ms).

The prescription reservation processing unit 12 then performs a process of presenting buttons to select either "Today" or "Within the prescription validity period" along with a message requesting input of a planned visit, as shown in FIG. 17(d). Here, it is assumed that the customer presses the "Today" button and the message "Today" is sent from the customer terminal 40 (message service AP44). Then, in response to the message "Today", as shown in FIG. 17(c), the prescription reservation processing unit 12 sends a message informing the customer of today's business hours of the AAA Pharmacy.

The prescription reservation processing unit 12 then performs a process of presenting a button for selecting either "Yes" or "No" along with a message requesting selection input as to whether or not a generic drug is desired, as shown in FIG. 18(a). Here, it is assumed that the customer presses the "Yes" button and a message "Yes" is sent from the customer terminal 40 (message service AP44). Then, in response to the message "Yes", as shown in FIG. 18(a), the prescription reservation processing unit 12 sends a message to the effect that a generic drug will be prepared.

Next, as shown in FIG. 18(b), the prescription reservation processing unit 12 sends a message requesting the upload of prescription image data obtained by photographing the prescription with a camera, and waits to receive the uploaded prescription image data. Then, the prescription is photographed by the camera 42 through the customer's operation on the customer terminal 40, and the photographed prescription image data is uploaded by the message service AP 44. The process of photographing and uploading an image on the customer terminal 40 can be similar to the process used for various mobile terminals such as various smartphones, so a detailed explanation will be omitted here.

Next, the prescription reservation processing unit 12 sends a message notifying the user that the prescription reservation has been accepted, as shown in FIG. 18(c), and ends the series of automatic interactive processing for the prescription reservation.

As described above, the Web application server 10 accepts prescription reservations from the customer terminal 40 via the message service system 50 through automatic dialogue processing by the message processing unit 15 and the prescription reservation processing unit 12. Note that the order of information and combination of information acquired through the automatic dialogue processing of prescription reservations are not limited to the above example.

When the prescription reservation processing unit 12 acquires the necessary information from the customer (customer terminal 40) through automatic dialogue processing, it assigns a prescription reservation ID to the prescription reservation based on the contents of the message accepted through automatic dialogue processing, and registers the information corresponding to the prescription reservation ID (prescription reservation information) in the prescription reservation database 225. Here, it is assumed that the prescription reservation processing unit 12 assigns "1" as the prescription reservation ID to the accepted prescription reservation. Furthermore, when the prescription reservation processing unit 12 performs automatic dialogue processing using a message with the contents shown in Figures 17 and 18, it registers the information shown in Figure 10 (information for "prescription reservation ID: 1") in the prescription reservation database 225. In this case, the prescription reservation processing unit 12 adds the following information to the prescription reservation database 225, as shown in FIG. 10: "Prescription reservation ID: 1, pharmacy ID: 1, name: Yamada Taro, phone number: 090-1234-5678, reservation time: February 1, 2019, generic: 1, prescription image data: image data X1."

When the in-store service processing unit 13 is accessed by the pharmacy terminal 30 (web browser 32) located at the AAA pharmacy, it can present a screen on the pharmacy terminal 30 (web browser 32) that displays prescription reservation information corresponding to the pharmacy ID (1) of the AAA pharmacy (information extracted from the prescription reservation database 225 for prescription reservations with a pharmacy ID of "1").

This allows staff at AAA pharmacies to check the details of current prescription reservations and prepare the necessary prescription medications.

[S102: Customer information and prescription registration]
Thereafter, the customer visits the AAA pharmacy, and the AAA pharmacy dispenses the prescription drug to the customer based on the prescription.

At that time, using the functions of the in-store service processing unit 13, the staff of the AAA pharmacy registers the customer's information in the customer database 222 and also registers the prescription for the customer in the prescription database 226 (prescription drug database 227). At this time, the in-store service processing unit 13 assigns an available customer ID to the customer, and further assigns an available prescription ID to the prescription. Furthermore, the in-store service processing unit 13 assigns available prescription drug IDs to each prescription drug set in the prescription.

Here, we will assume that the customer (name: Yamada Taro) has been assigned a customer ID of 1, and that the prescription has been assigned a prescription ID of 1. We will also assume that two prescription drugs are set for the prescription (prescription ID: 1), and that the prescription drug IDs for these two prescription drugs have been assigned 1 and 2, respectively.

Here, it is assumed that the content shown in FIG. 7 has been registered in the customer database 222 as customer information for the customer (name: Yamada Taro, customer ID: 1).

Here, it is assumed that the contents shown in Figures 11 and 12 are registered in the prescription database 226 and the prescription drug database 227 as information on the prescription (prescription ID: 1) and related prescription drugs (prescription drug IDs: 1, 2).

The storefront service processing unit 13 may accept input from the pharmacist for all items in the prescription drug database 227, but may automatically input the start date, middle date, and end date based on information on other items. For example, if the daily dose and dispensed amount are known, the period of use (the period from the start date to the end date) can be known (period of use = dispensed amount / daily dose). Therefore, in the storefront service processing unit 13, for example, if the start date of use is the dispensed date or the day after the dispensed date, the end date and middle date of use can be automatically input. In addition, the storefront service processing unit 13 may accept input from the pharmacist only for the start date of use (for example, the pharmacist inputs the start date of use after checking the status of remaining medicine from the customer), and automatically input the middle date and end date of use. In addition, the in-store service processing unit 13 may set the middle day of the dosing period as the middle dosing day if the number of days in the dosing period is an odd number, and may set the "last day of the first half of the dosing period" or the "first day of the second half of the dosing period" as the middle dosing day if the number of days in the dosing period is an even number.

[S103: Associating MS account ID]
Furthermore, when the in-store service processing unit 13 accepts the registration of a prescription, it issues a document (hereinafter referred to as a "prescription drug information sheet") on which information regarding the prescription drug dispensed based on the prescription is printed from the printer 60.

Figure 19 is an explanatory diagram showing an example of the configuration of a prescription drug information sheet.

As shown in FIG. 19, the prescription drug information sheet issued by the in-store service processing unit 13 has a two-dimensional barcode (e.g., a QR code (registered trademark)) printed thereon for executing a process on the message service system 50 to associate the MS account ID of the customer with the MS account ID of the AAA pharmacy (e.g., friend registration using the LINE@ service). The two-dimensional barcode contains a command to associate the MS account ID of the AAA pharmacy with the MS account ID of the customer, and additional information for the command (e.g., personal information such as a customer ID for identifying the customer).

Then, when the customer operates the customer terminal 40 and the camera 42 is activated by the message service AP 44 to read the two-dimensional barcode, the message service AP 44 requests the message service system 50 to associate the MS account ID of the customer with the MS account ID of the AAA pharmacy, and transmits the additional information (information including the customer ID) contained in the two-dimensional barcode to the MS account ID of the AAA pharmacy (AAA_ms). This allows the message processing unit 15 to recognize the correspondence between the customer's MS account ID (associated with the MS account ID of the AAA pharmacy in the message service system 50) and the customer's customer ID, and to register the contents of this in the MS customer management database 223. Here, the message processing unit 15 can set "taro_ms" as the MS account ID of the customer (customer ID: 1) in the MS customer management database 223, as shown in FIG. 8.

By performing the above-described processing, the health consultation processing unit 14 is able to send a message regarding health consultation from the MS account ID of the AAA Pharmacy to the MS account ID (taro_ms) of the customer via the message service system 50.

[S104: Message exchange regarding health consultation (automatic dialogue processing)]
Next, a specific example will be described in which automatic dialogue processing regarding health consultation is performed between the customer (customer ID: 1, name: Yamada Taro) and his/her MS account ID (taro_ms) at a timing based on the contents of the prescription (prescription database 226 and prescription drug database 227) using the functions of the health consultation processing unit 14.

The health consultation processing unit 14 grasps each timing (hereinafter referred to as "health consultation message transmission timing") for sending a message regarding health consultation registered in the prescription drug database 227 for each prescription ID registered in the prescription database 226, and transmits a message etc. corresponding to the health consultation message transmission timing each time the grasped health consultation message transmission timing arrives.

As shown in FIG. 12, the prescription drug database 227 registers the start date, inactive date, and end date of each prescription drug as the timing for sending a health consultation message. However, to simplify the explanation, it is assumed that a common timing (date) is set for the timing for sending a health consultation message (start date, inactive date, and end date) in prescription drug data corresponding to the same prescription ID. For example, in FIG. 12, the start date, inactive date, and end date for the two "prescription drug IDs: 1, 2" corresponding to "prescription ID: 1" are all set to a common date.

The health consultation processing unit 14 also determines whether or not to send a health consultation message at each timing (date when taking the drug starts, date when taking the drug is in progress, and date when taking the drug ends) by referring to "Whether or not to notify when taking the drug starts,""Whether or not to notify when taking the drug ends," and "Whether or not to notify when taking the drug ends" for each prescription drug ID in the prescription drug database 227. In other words, "Whether or not to notify when taking the drug starts,""Whether or not to notify when taking the drug ends," and "Whether or not to notify when taking the drug ends" function as switches that determine whether or not to send a message at each timing (date when taking the drug starts, date when taking the drug is in progress, and date when taking the drug ends).
In order to simplify the explanation, it will be assumed that the same values are set for these switch items ("Whether to notify when starting to take the drug,""Whether to notify while taking the drug," and "Whether to notify when the drug has finished taking the drug") in prescription drug data corresponding to the same prescription ID.

Here, if the contents of the prescription drug database 227 are as shown in FIG. 11 and the contents of the prescription drug database 227 are as shown in FIG. 12, the timing of sending the health consultation message corresponding to "Prescription ID: 1" is "Date of initiation of taking the drug = February 1, 2019, date of initiation of taking the drug = February 8, 2019, date of end of taking the drug = February 14, 2019." Furthermore, by combining the contents of the prescription database 226, the customer database 222, the MS customer management database 223, and the MS pharmacy management database 224, the health consultation processing unit 14 can recognize the MS account ID of the pharmacy and the MS account ID of the customer for each prescription ID.

As described above, the health consultation processing unit 14 can recognize the timing of sending the health consultation message (start date, middle date, and end date of medication) for each prescription ID, the MS account ID of the pharmacy providing the health consultation, and the MS account ID of the customer receiving the health consultation, and can perform processing (automatic dialogue processing) to send and receive health consultation messages.

20 and 21, an example of message transmission and reception performed by the health consultation processing unit 14 at each health consultation message transmission timing (start date, middle date, and end date) based on the prescription with "Prescription ID: 1" will be described. For the prescription with "Prescription ID: 1", the pharmacy that dispensed the prescription is "AAA Pharmacy", and the customer to whom the prescription is given is customer with "Customer ID: 1" (name: Yamada Taro, MS account ID: taro_ms).

First, when the start date for the prescription with "Prescription ID: 1" arrives, the health consultation processing unit 14 sends a message from the pharmacy's MS account ID (AAA_ms) to the customer's MS account ID (taro_ms) to notify that it is time to start taking the prescribed prescription drug, as shown in FIG. 20(a).

Next, when the day of medication for the prescription "Prescription ID: 1" arrives, the health consultation processing unit 14 sends and receives messages to inquire about the medication status of the prescribed prescription drug, as shown in Figures 20(b) to 20(d) and 21(a) to 21(c). The scenario for inquiring about the medication status (hereinafter referred to as the "health consultation scenario") is not limited to the examples in Figures 20 and 21, and various scenarios can be applied.

When the day of medication is reached, the health consultation processing unit 14 first performs a process of presenting the customer with a message requesting them to select a medication status as shown in FIG. 20(b), along with buttons to select either "Can take" or "Can't take." Here, it is assumed that the customer presses the "Can't take" button, and the message "Can't take" is sent from the customer terminal 40 (message service AP44).

The health consultation processing unit 14 then performs a process of presenting the customer with a message requesting free input about any issues the customer is having with taking their medication, as shown in FIG. 20(c). Here, it is assumed that the customer inputs the message "I often forget to take my medicine," and that the message is sent from the customer's MS account ID (taro_ms). Note that if "I can take it" is selected in response to the question in FIG. 20(b), the health consultation processing unit 14 may perform a process of skipping the question in FIG. 20(c). In this way, the health consultation processing unit 14 may change or skip the next question depending on the content input by the customer in the automatic dialogue process.

Next, the health consultation processing unit 14 performs a process of presenting the customer with a message requesting the customer to select whether or not there is a problem with side effects, along with buttons for selecting either "No problem" or "Problem," as shown in FIG. 20(d). Here, it is assumed that the customer presses the "Problem" button, and a message stating "Problem" is sent from the customer terminal 40 (message service AP44).

The health consultation processing unit 14 then performs processing to send a message to the customer requesting free input regarding the side effects as shown in FIG. 21(a). Here, it is assumed that the customer inputs the message "Taking this medicine makes me very sleepy" and that the message is sent from the customer's MS account ID (taro_ms). Note that the health consultation processing unit 14 may perform processing to skip the question in FIG. 21(a) if "No problem" is selected in response to the question in FIG. 20(d).

Next, the health consultation processing unit 14 performs a process of presenting a button to select either "no" or "yes" along with a message requesting the customer to select whether or not they are having trouble with symptoms, as shown in FIG. 21(b). Here, it is assumed that the customer presses the "yes" button, and a message stating "yes" is sent from the customer terminal 40 (message service AP44).

Next, the health consultation processing unit 14 performs a process of sending a message to the customer requesting free input of any symptoms that are bothering the customer, as shown in FIG. 21(c). Here, it is assumed that the customer inputs the message "I have a persistent low-grade fever," and that the message is sent from the customer's MS account ID (taro_ms). Note that if "no" is selected in response to the question in FIG. 21(b), the health consultation processing unit 14 may perform a process of skipping the question in FIG. 21(c).

After that, when the medication end date arrives (or a few days before the medication end date), the health consultation processing unit 14 performs processing to send a message to the customer urging them to receive the medication from the medical institution because the medication period has ended, as shown in FIG. 21 (d).

As described above, the health consultation processing unit 14 performs message sending and receiving (automatic dialogue processing) for each prescription ID according to a predetermined health consultation scenario for each timing of sending a health consultation message (start date, middle date, and end date of medication).

[S105: Record the messages exchanged regarding health consultation]
Every time the health consultation processing unit 14 transmits or receives a message regarding health consultation, it assigns a message identification ID to each message and registers it in the health consultation conversation database 228. When messages such as those shown in Fig. 20 and Fig. 21 are transmitted or received, the contents of the health consultation conversation database 228 will be as shown in Fig. 13.

The health consultation processing unit 14 may receive not only messages sent in response from the customer (customer's MS account ID) in accordance with the health consultation scenario, but also messages sent voluntarily by the customer, and register them in the health consultation conversation database 228.

[S106: Present the message exchanged with the customer to the pharmacy staff]
The in-store service processing unit 13 can extract and display each message from the health consultation conversation database 228 based on keys such as "customer ID,""sent date and time," and "status" (hereinafter, the screen displaying the extracted message is referred to as the "message display screen"). The in-store service processing unit 13 may also accept a request to reply to a message displayed on the message display screen (to the MS account ID of the customer who sent the message). This allows the in-store service processing unit 13 to send a message to each customer (each customer's MS account ID) of the pharmacy (pharmacy ID) via the message processing unit 15.

(A-3) Advantages of the First Embodiment According to the first embodiment, the following advantages can be achieved.

In the pharmacy support system 1 (Web application server 10) of the first embodiment, a message service system 50 is used for communication between the pharmacy (pharmacist) and the customer (patient). As a result, in the pharmacy support system 1 of the first embodiment, compared to conventional communication by telephone or other means, the time at which the customer can be served is not limited, which has the effect of making it easier for the customer to respond to or ask questions about health consultations. In addition, in the pharmacy support system 1 of the first embodiment, the effort required for the pharmacy (pharmacist) to receive health consultations from customers or provide health information can be significantly reduced compared to conventional communication by telephone or other means. Furthermore, in the pharmacy support system 1 of the first embodiment, a record of the conversation between the pharmacy (pharmacist) and the customer can be reliably kept, which reduces the omission of information provided to the customer and promotes the health of the customer.

In addition, in the pharmacy support system 1 (Web application server 10) of the first embodiment, the timing of sending a health consultation message (start date, middle date, and end date of taking the medicine) is set in the prescription drug database 227 (prescription database 226), and automatic dialogue processing (message sending and receiving using the message service system 50 according to the health consultation scenario) is performed in accordance with each health consultation message sending timing. As a result, the pharmacy support system 1 of the first embodiment can accept health consultations from a large number of customers at a suitable timing according to the contents of the prescription without increasing the workload of the pharmacist. As a result, customers who use the pharmacy support system 1 of the first embodiment can receive health consultations at a suitable timing according to the contents of the prescription and improve their health, even if a problem related to the prescription occurs during the medication period.

As described above, the pharmacy support system 1 (Web application server 10) of the first embodiment can promote the health of customers while reducing the workload of pharmacies.

(B) Second Embodiment Hereinafter, a second embodiment of the pharmacy support system and pharmacy support method according to the present invention will be described in detail with reference to the drawings.

(B-1) Configuration and Operation of the Second Embodiment The overall configuration of the pharmacy support system 1A of the second embodiment can also be shown using the above-mentioned Fig. 1. In Fig. 1, the reference characters in parentheses are used only in the second embodiment.

As shown in FIG. 1, the pharmacy support system 1A differs from the first embodiment in that the Web application server 10 and the database server 20 are replaced with a Web application server 10A and a database server 20A.

Figure 22 is a block diagram showing the functional configuration of a web application server 10A according to the second embodiment.

As shown in FIG. 22, the Web application server 10A differs from the first embodiment in that the message processing unit 15 is replaced with a message processing unit 15A. In addition, the message processing unit 15A of the second embodiment holds message link information 151.

Figure 23 is a block diagram showing the functional configuration of the database server 20A according to the second embodiment.

As shown in FIG. 23, the database server 20A of the second embodiment differs from the first embodiment in that the MS pharmacy management database 224 is excluded from the data recording unit 22.

In the first embodiment, a configuration was described in which each pharmacy is assigned an MS account ID on the message service system 50. However, in a typical message service system 50 such as LINE, corporate accounts (e.g., LINE official accounts and LINE@ accounts) are charged, so if each pharmacy obtains a corporate account, each pharmacy will be required to cover these costs. In order to attract a large number of pharmacies to join the pharmacy support system 1, it is desirable to keep operational costs as low as possible.

In the first embodiment, each pharmacy is assigned an individual MS account ID, but it is only the Web application server 10 that actually connects directly to the message service system 50 and sends and receives messages with the customer's MS account ID (customer terminal 40). Therefore, in the pharmacy support system 1A of the second embodiment, each pharmacy obtains a common MS account ID (corporate MS account ID), and messages are sent and received by the Web application server 10A. Below, the MS account ID assigned to the pharmacy support system 1A (Web application server 10A) is represented as "YS_MS".

Specifically, in the second embodiment, the message processing unit 15A of the web application server 10A uses the MS account ID (YS_MS) on the pharmacy support system 1A side to send and receive messages with each customer's MS account ID (customer terminal 40).

In the second embodiment, since the MS customer management database 223 is stored in the database server 20A, the message processing unit 15A performs message transmission processing for messages (hereinafter referred to as "downstream messages") from the pharmacy support system 1A (Web application server 10A) to each customer's MS account ID (customer terminal 40) in the same manner as in the first embodiment.

The message processing unit 15A also holds message link information 151 as information regarding which pharmacy (pharmacy ID) is currently sending and receiving messages for each customer's MS account ID (customer terminal 40).

Figure 24 is an explanatory diagram showing an example of the configuration of message link information 151.

As shown in FIG. 24, the message link information 151 registers a combination of a pharmacy ID and a customer ID (or a customer's MS account ID) (hereinafter, this combination will be simply referred to as a "message link"), a "customer MS account ID" as the MS account ID corresponding to the customer ID of the message link, and a "last message sending/receiving time" as the time when the last message was sent/received via the message link.

For example, when sending a downstream message for a message link that is not registered in the message link information 151, the message processing unit 15A additionally registers information about the message link in the message link information 151. At that time, the message processing unit 15A sets the destination of the downstream message (the customer's MS account ID) to the customer MS account ID of the message link, and further sets the current time to the last message sending/receiving time of the message link.

In addition, when an outbound message or inbound message occurs corresponding to a message link registered in the message link information 151, the message processing unit 15A updates the last message transmission/reception time corresponding to that message link in the message link information 151 to the current time.

Furthermore, when the message processing unit 15A receives an uplink message from the message service system 50, it acquires the MS account ID (the customer's MS account ID) of the sender of the uplink message, and recognizes the message link (the message link that matches the customer's MS account ID) corresponding to the uplink message based on the acquired MS account ID. This allows the message processing unit 15A to identify the message link of the uplink message received from the message service system 50, and at the same time, to identify the pharmacy ID (pharmacy) that is the destination of the uplink message, and record the information of the uplink message in the health consultation conversation database 228.

Furthermore, if there is a message link in the message link information 151 whose last message sending/receiving time is more than a predetermined time T1 ago (a message link for which no message has been sent/received for a period of T1 or more), the message processing unit 15A deletes the information of that message link from the message link information 151. That is, the message processing unit 15A recognizes and retains only message links for which a message has been sent/received within the most recent period T1 as active message links, and recognizes and discards only message links for which no message has been sent/received within the most recent period T1 as inactive message links. For example, a period of about 30 minutes to 1 hour can be applied as the time T1. Since it is generally unlikely that a customer will send/receive messages to multiple pharmacies at the same time, no major problems will arise if a message link for which no message has been sent/received for a certain period is made inactive.

When registering a new message link, if the customer ID of the message link to be registered overlaps with any message link already registered in the message link information 151, the message processing unit 15A may delete the message link information already registered in the message link information 151 and register the new message link information. This allows the message processing unit 15A to correctly receive incoming messages even when a customer is attempting to send and receive messages to multiple pharmacies in succession.

Furthermore, when a customer's MS account ID (customer terminal 40) accesses a pharmacy (pharmacy ID) via the portal function (portal processing unit 11) by specifying the pharmacy, the message processing unit 15A may register a message link corresponding to the customer's MS account ID (customer terminal 40) in the message link information 151. In this case, when the message processing unit 15A receives an access (e.g., an uplink message) from the customer's MS account ID (customer terminal 40) to the MS account ID of the pharmacy support system 1 via the portal, the message processing unit 15A may register a message link of the customer's MS account ID (customer terminal 40) that has been accessed in the message link information 151. For example, on the portal web screen shown in FIG. 16, the link information of the button B201 for accessing the AAA pharmacy (pharmacy ID: 1) includes an instruction to send a message including the pharmacy ID (1) of the AAA pharmacy to the MS account ID (YS_MS) of the pharmacy support system 1A. Then, a portal web screen such as that shown in FIG. 16 is displayed on the customer terminal 40 (web browser 32), and when button B201 for accessing AAA Pharmacy (pharmacy ID: 1) is pressed, the customer terminal 40 (customer terminal 40 and message service AP 43) sends a message including the pharmacy ID (1) of AAA Pharmacy to the MS account ID (YS_MS) of the pharmacy support system 1A in accordance with the link information set in button B201. When the message processing unit 15A receives the message, it can generate new message link information based on the pharmacy ID etc. set in the message and register it in the message link information 151.

In addition, without being limited to the above example, if a process is generated from the customer terminal 40 (customer terminal 40 and message service AP43) to specify a pharmacy ID and send a message to the MS account ID (YS_MS) of the pharmacy support system 1A, new message link information can be generated by the message processing unit 15A and registered in the message link information 151.

(B-2) Advantages of the Second Embodiment According to the second embodiment, the following advantages can be obtained.

As described above, the message processing unit 15A of the Web application server 10A in the second embodiment uses the MS account ID (YS_MS) on the pharmacy support system 1A side to send and receive messages with each customer's MS account ID (customer terminal 40), making it possible to operate the pharmacy support system 1A at lower cost.

(C) Other Embodiments The present invention is not limited to the above-described embodiments, and modified embodiments such as those exemplified below can also be mentioned.

(C-1) In the above embodiment of the pharmacy support system 1, the web application server 10 and the database server 20 are configured using separate computers, but they may be configured using a single computer. Also, the web application server 10 and the database server 20 may be configured using further subdivided computers. In other words, there is no limit to the number of computers that make up the pharmacy support system 1.

(C-2) Although the pharmacy support system 1 in the above embodiment is configured as a web-based system, it may also be configured as a client-server system (a configuration realized by installing a dedicated application on the pharmacy terminal 30 and the customer terminal 40). In other words, a dedicated application that performs the same operation as the program distributed to the pharmacy terminal 30 and the customer terminal 40 as a web application in the above embodiment may be installed on the pharmacy terminal 30 and the customer terminal 40.

1...pharmacy support system, 10...web application server, 11...portal processing unit, 12...prescription reservation processing unit, 13...store service processing unit, 14...health consultation processing unit, 15...message processing unit, 20...database server, 21...database processing unit, 22...data recording unit, 221...pharmacy database, 222...customer database, 223...MS customer management database, 224...MS pharmacy management database, 225...prescription reservation database, 226...prescription database, 227...prescription drug database, 228...health consultation conversation database, 30...pharmacy terminal, 31...touch panel display, 32...web browser, 33...message service AP, 44...message service AP, 40...customer terminal, 41...touch panel display, 42...camera, 43...web browser, 50...message service system, 60...printer.

Claims (3)

an account management means for managing a pharmacy account on a message processing system corresponding to a pharmacy and a customer account on the message processing system corresponding to a customer of the pharmacy;
a prescription management means for receiving and managing the contents of a prescription dispensed to the customer via the customer account of the message processing system ;
a message processing means for transmitting, for each prescription, from the pharmacy account to the customer account in accordance with a scenario corresponding to the content of the prescription, a question message asking a question regarding the state after taking the drug dispensed according to the prescription and a selection message for answering the question message, and for receiving, via the message processing system , the selection message for answering the question message transmitted from the customer account to the pharmacy account;
a message management means for managing the question message and the option messages related to the answers;
and a pharmacy terminal processing means for supplying messages managed by the message management means to a pharmacy terminal disposed in the pharmacy. The message processing means is also capable of accepting any free input message that is not a response to the question message sent from the customer account,
The pharmacy support system according to claim 1 , wherein the message management means manages at least the question message, the option message related to the answer, and the free input message. In the pharmacy support method,
The system includes an account management means, a prescription management means, a message processing means, a message management means, and a pharmacy terminal processing means,
The account management means manages a pharmacy account on a message processing system corresponding to a pharmacy and a customer account on the message processing system corresponding to a customer of the pharmacy;
The prescription management means manages the contents of the prescription dispensed to the customer by receiving input via the customer account of the message processing system ;
The message processing means is capable of transmitting, for each prescription, a question message asking a question regarding the situation after taking the medicine dispensed according to the prescription from the pharmacy account to the customer account in accordance with a scenario corresponding to the content of the prescription, and a choice message of answers to the question message, and receiving the choice message related to the answer to the question message transmitted from the customer account to the pharmacy account via the message processing system ;
the message management means is capable of managing the question message and the option messages related to the answers,
The pharmacy support method, wherein the pharmacy terminal processing means supplies the message managed by the message management means to a pharmacy terminal disposed in the pharmacy.

Images