Pharmacy support system and pharmacy support method

Abstract

To provide a pharmacy support system that reduces operation burden on a pharmacy and furthermore achieves health promotion of a client.SOLUTION: The present invention relates to a pharmacy support system. The pharmacy support system is configured to: manage a content of a prescription prescribed to a client; transmit a message in accordance with a scenario complying with a content of the prescription from a pharmacy account to a client account via a message service at a timing in compliance with the content of the prescription for each prescription; receive a response content transmitted from the client account to the pharmacy account via the message service; hold a plurality of pieces of scenario data defining a content of the message to be transmitted; hold the scenario data corresponding to the prescription from the scenario data; and transmit the message according to the holding scenario data.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] 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. [Background technology]

[0002] BACKGROUND ART Conventionally, as an information system for supporting (assisting) the operations of dispensing pharmacies, there is a technology described in Patent Document 1, for example.

[0003] In Patent Document 1, a message service system is used for communication between pharmacists and patients, thereby reducing the effort required for pharmacists to receive health consultations from customers and provide health information. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2020-149110 Summary of the Invention [Problem to be solved by the invention]

[0005] However, the work at a pharmacy does not end with simply treating patients, but also encompasses a wide range of tasks such as preparing various reports and processing accounts based on interactions with patients.

[0006] However, while the technology described in Patent Document 1 enables efficient communication between pharmacists and patients, patient-related tasks at pharmacies are not completed by itself, and include a wide range of tasks such as creating various reports and processing accounts based on interactions with patients.

[0007] Therefore, there is a demand for a pharmacy support system and a pharmacy support method that enable various patient-related tasks to be performed more efficiently in pharmacies. [Means for solving the problem]

[0008] a message processing means for transmitting a message from the pharmacy account to the customer account via the message service in accordance with a scenario corresponding to the content of the prescription at a timing corresponding to the content of the prescription, and receiving a response content transmitted from the customer account to the pharmacy account via the message service; a response management means for managing the response content received by the message processing means; a pharmacy terminal processing means for supplying a message processed by the message processing means to a pharmacy terminal disposed at the pharmacy; and a scenario data storage means for storing a plurality of scenario data defining the content of the message to be transmitted by the message processing means, wherein the message processing means stores the scenario data corresponding to the prescription from the scenario data stored in the scenario data storage means, and transmits a message in accordance with the stored scenario data. and a report generating / outputting means for generating one or more medication information reports describing part or all of the content transmitted and received by the message processing means and performing a batch output process for outputting the generated reports in a batch, wherein the scenario data includes one or more problem question scenarios for sending a problem question message to the customer account asking whether there are any problems with taking the medicine listed on the prescription and receiving a response to the problem question message, and the report generating / outputting means describes the response to the one or more problem question messages in the report, and excludes from the batch output process any reports for which the response to the one or more problem question messages indicates a problem. It is characterized by:

[0009] The second aspect of the present invention is a pharmacy support method performed by a pharmacy support system, the pharmacy support system including an account management means, a prescription management means, a message processing means, a response management means, a pharmacy terminal processing means, , Shi Scenario data retention method and report generation and output meansthe account management means manages a pharmacy account used in a message service corresponding to a pharmacy and a customer account used in the message service corresponding to a customer of the pharmacy; the prescription management means manages the contents of prescriptions dispensed to the customers; the message processing means, for each prescription, sends a message from the pharmacy account to the customer account via the message service in accordance with a scenario in accordance with the contents of the prescription at a timing in accordance with the contents of the prescription, and receives a response content sent from the customer account to the pharmacy account via the message service; the response management means manages the response content received by the message processing means; the pharmacy terminal processing means supplies a message processed by the message processing means to a pharmacy terminal arranged in the pharmacy; the scenario data holding means holds a plurality of scenario data defining the contents of the message to be sent by the message processing means; the message processing means holds the scenario data corresponding to the prescription from the scenario data held by the scenario data holding means and sends a message in accordance with the held scenario data. The report generation and output means generates one or more medication information reports describing part or all of the content transmitted and received by the message processing means, and performs a batch output process to output the generated reports in a batch. The scenario data includes one or more problem question scenarios that send a problem question message to the customer account asking whether there are any problems with taking the medication listed on the prescription, and receive a response to the problem question message. The report generation and output means describes the response to the one or more problem question messages in the report, and excludes reports for which the response to the one or more problem question messages indicates a problem from the batch output process. It is characterized by: [Effects of the Invention]

[0010] According to the present invention, it is possible to promote the health of customers while reducing the workload of pharmacies. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 2 is a block diagram showing a connection configuration of each device related to the first embodiment. [Figure 2] FIG. 2 is a block diagram showing the functional configuration of a Web application server according to the first embodiment. [Figure 3] FIG. 2 is a block diagram showing the functional configuration of a database server according to the first embodiment. [Figure 4] FIG. 2 is a block diagram showing the functional configuration of a pharmacy terminal according to the first embodiment. [Figure 5] FIG. 2 is a block diagram showing the functional configuration of a customer terminal according to the first embodiment. [Figure 6] FIG. 2 is a block diagram showing the functional configuration of a receipt computer according to the first embodiment. [Figure 7] FIG. 2 is a conceptual diagram showing an outline of the structure of dialogue scenario data according to the first embodiment. [Figure 8] FIG. 2 is a diagram showing an example of the configuration of a pharmacy database according to the first embodiment. [Figure 9] FIG. 2 is a diagram illustrating an example of the configuration of a customer database according to the first embodiment. [Figure 10] FIG. 2 is a diagram illustrating an example of the configuration of an MS customer management database according to the first embodiment. [Figure 11] FIG. 2 is a diagram showing an example of the configuration of an MS pharmacy management database according to the first embodiment. [Figure 12] FIG. 2 is a diagram showing an example of the configuration of a medicine database according to the first embodiment. [Figure 13] FIG. 2 is a diagram showing an example of the configuration of a prescription reservation database according to the first embodiment. [Figure 14] FIG. 2 is a diagram showing an example of the configuration of a prescription database according to the first embodiment. [Figure 15] FIG. 2 is a diagram showing an example of the configuration of a prescription drug database according to the first embodiment. [Figure 16] FIG. 3 is a diagram showing an example of the configuration of a date-based template database according to the first embodiment. [Figure 17] FIG. 3 is a diagram showing an example of the configuration of a date-based option database according to the first embodiment. [Figure 18] FIG. 2 is a diagram showing an example of the configuration of a medicine-specific template database according to the first embodiment. [Figure 19] FIG. 2 is a diagram showing an example of the configuration of a medicine option database according to the first embodiment. [Figure 20] FIG. 2 is a diagram illustrating an example of the configuration of a delivery management database according to the first embodiment. [Figure 21] FIG. 2 is a diagram illustrating an example of the configuration of a response management database according to the first embodiment. [Figure 22] 3 is a flowchart showing an example (scenario) of the operation of the pharmacy support system according to the first embodiment. [Figure 23] FIG. 2 is a diagram showing an example (part 1) of dialogue processing according to the first embodiment. [Figure 24] FIG. 10 is a diagram showing a configuration example (part 1) of a report editing screen according to the first embodiment. [Figure 25] FIG. 10 is a diagram showing an example (part 2) of the dialogue processing according to the first embodiment. [Figure 26] FIG. 10 is a diagram showing a second example of the configuration of a report editing screen according to the first embodiment. [Figure 27] FIG. 10 is a diagram showing a configuration example (part 3) of a report editing screen according to the first embodiment. [Figure 28] FIG. 10 is a diagram showing a configuration example (part 3) of a template editing screen according to the first embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] (A) First embodiment A first embodiment of a pharmacy support system and a pharmacy support method according to the present invention will be described in detail below with reference to the drawings.

[0013] (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.

[0014] The pharmacy support system 1 is a system that supports the operations of dispensing pharmacies, thereby reducing the workload on pharmacy staff (pharmacists, etc.) and promoting the health of customers (patients) of the pharmacies it supports.

[0015] Pharmacy support system 1 shown in Fig. 1 includes devices including a Web application server 10 and a database server 20. Note that in Fig. 1, the reference numerals in parentheses are used only in the second embodiment described later.

[0016] Furthermore, the pharmacy support system 1 is 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.

[0017] Various message service (chat service) systems such as LINE (registered trademark), Facebook (registered trademark), and Skype (registered trademark) can be applied as the message service system 50. In the following, an example will be described in which the message service system 50 uses the LINE service, a version of which is current at the time of filing.

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

[0019] Pharmacy terminal 30 is a terminal installed in a pharmacy that receives services (business support) from web application server 10. For example, a tablet, PC, or other terminal may be used as pharmacy terminal 30. Also, pharmacy terminal 30 is connected to printer 60 that can print statements and the like.

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

[0021] Next, the internal configuration of each device that constitutes the pharmacy support system 1 will be described.

[0022] FIG. 2 is a block diagram showing the internal configuration of the Web application server 10. As shown in FIG.

[0023] The internal functional configuration of the Web application server 10 can be shown as in Figure 2. The Web application server 10 can be constructed using, for example, a computer (such as a PC or workstation) having a memory and a processor.

[0024] In this embodiment, the Web application server 10 includes a portal processing unit 11, a prescription reservation processing unit 12, an in-store service processing unit 13, a dialogue processing unit 14, a message processing unit 15, and a report processing unit 16.

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

[0026] In the first embodiment, the program (pharmacy support program according to the embodiment) incorporated into the Web application server 10 includes modules of a portal processing unit 11, a prescription reservation processing unit 12, an in-store service processing unit 13, a dialogue processing unit 14, a message processing unit 15, and a report processing unit 16 shown in FIG. 3. 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.

[0027] FIG. 3 is a block diagram showing the internal configuration of the database server 20. As shown in FIG.

[0028] The database server 20 is a device that provides various data required for the processing of the Web application server 10 .

[0029] The database server 20 can be constructed using, for example, a computer (for example, a PC or a workstation) having a memory and a processor.

[0030] As shown in FIG. 3, the database server 20 includes a database processing unit 21 and a data recording unit 22.

[0031] The data recording unit 22 is a data recording means for recording various data used in each process within the database server 20. As shown in Fig. 3, the data recording unit 22 is assumed to record at least a pharmacy database 2201, a customer database 2202, an MS customer management database 2203, an MS pharmacy management database 2204, a prescription reservation database 2205, a prescription database 2206, a prescription drug database 2207, a drug database 2208, a date-specific template database 2209, a drug-specific template database 2210, a delivery management database 2211, and a response management database 2212. The detailed configuration of each piece of data recorded in the data recording unit 22 will be described later.

[0032] The database processing unit 21 processes data in the databases recorded in the data recording unit 22. The database processing unit 21 can be constructed using, for example, various DBMSs (Database Management Systems). Therefore, each database recorded in the data recording unit 22 must be configured with a data structure compatible with the database processing unit 21. The database processing unit 21 processes data in 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.

[0033] Next, the internal configuration of pharmacy terminal 30 will be described.

[0034] FIG. 4 is a block diagram showing an example of the internal configuration of pharmacy terminal 30. As shown in FIG.

[0035] Pharmacy terminal 30 can be constructed using various terminal devices (computers; hardware), such as a PC, a tablet PC, etc. Fig. 4 shows an example in which a tablet PC is used as hardware for pharmacy terminal 30.

[0036] As shown in FIG. 4, pharmacy terminal 30 functionally includes touch panel display 31 and web browser 43.

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

[0038] 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. Note that the pharmacy application program may be installed as a dedicated application rather than a web-based program on the pharmacy terminal 30. 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 contains the MS account ID and password of the user using the customer terminal 40.

[0039] Next, the internal configuration of the customer terminal 40 will be described.

[0040] FIG. 5 is an explanatory diagram showing an example of the internal configuration of the customer terminal 40. As shown in FIG.

[0041] 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.

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

[0043] 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 has 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.

[0044] 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 program.

[0045] 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.

[0046] The message service AP 44 is an application program that transmits and receives messages to and from the message service system 50 .

[0047] Next, the internal configuration of the receipt computer 70 will be described.

[0048] FIG. 6 is an explanatory diagram showing an example of the internal configuration of the receipt computer 70.

[0049] The receipt computer 70 can be constructed using various terminal devices (computers; hardware), such as a PC, etc. Fig. 6 shows an example in which a PC is used as the receipt computer 70 hardware.

[0050] As shown in FIG. 6, the receipt computer 70 functionally includes the touch panel display 41, a touch panel display 71, and a receipt processing program 72.

[0051] The touch panel display 71 is a device (a device that functions as a user interface) that outputs information to a customer who has the receipt computer 70 and accepts input from the customer (for example, input using a GUI screen). There are no limitations on the type of device that serves as the user interface (a means for input from and output to the customer) in the receipt computer 70.

[0052] A prescription at a dispensing pharmacy is a detailed statement of prescriptions that is billed to a health insurance association for medical fees for dispensing medicine to a patient (insured medical treatment). The prescription processing program 72 is software that creates a detailed statement of prescriptions based on prescription information, etc. The prescription processing program 72 may be a commercially available package software, and the specific configuration is not limited.

[0053] When data relating to a prescription (hereinafter referred to as "prescription data") output from the receipt processing program 72 is supplied from the receipt processing program 72, the upload processing unit 73 supplies the prescription data to the Web application server 10 (prescription reservation processing unit 12). Based on the supplied prescription data, the prescription reservation processing unit 12 registers detailed information of each prescription in the data recording unit 22 (prescription database 2206).

[0054] Typically, a prescription computer package software supports a function (hereinafter referred to as a "prescription data output function") that outputs input prescription information as text data (for example, data in CSV format, etc.) to a predetermined folder. In this embodiment, the upload processing unit 73 uses the prescription data output function of the prescription processing program 72 to acquire prescription data and upload it to the Web application server 10 (prescription reservation processing unit 12).

[0055] Next, an overview of each module that constitutes the Web application server 10 will be described.

[0056] The portal processing unit 11 is a module that provides the customer terminal 40 with portal functions such as information about pharmacies and search services. Here, the portal processing unit 11 is assumed to provide at least a service for searching for pharmacies where a prescription can be filled based on the prescription the customer has. 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").

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

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

[0059] 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 to and from the MS account ID of the customer 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.

[0060] The dialogue processing unit 14 performs processing (hereinafter referred to as "dialogue processing") to dialogue with the customer (customer terminal 40) via the message service system 50. For example, the dialogue processing unit 14 may perform dialogue processing with the customer (customer terminal 40) based on the contents (history) of prescription drugs dispensed (prescribed) to the customer based on a prescription.

[0061] Furthermore, for example, the dialogue processor 14 may send and receive any messages to and from the customer (customer terminal 40) in response to the pharmacist's operation (control from the pharmacy terminal 30).

[0062] The dialogue processing unit 14 performs dialogue processing with the customer (customer terminal 40) in accordance with data (hereinafter referred to as "dialogue scenario data") that defines a set dialogue scenario (scenario for dialogue with the customer).

[0063] FIG. 7 is a diagram showing an outline of the structure of the dialogue scenario data.

[0064] The dialogue scenario data in this embodiment includes data (hereinafter referred to as "message data") that defines the mainstream messages to be sent to the customer in the dialogue scenario, and data (hereinafter referred to as "input request data") that defines the process of requesting and accepting input from the customer corresponding to the mainstream messages (message data) (e.g., selecting an option or replying to a message).

[0065] The dialogue scenario data shown in Fig. 7 is composed of seven pieces of message data MD001 to MD007 and six pieces of input request data OD001 to OD006. In Fig. 7, the connection relationships (logical connection (link) relationships) between the data symbols are shown by lines between the symbols of the data.

[0066] The dialogue scenario data describes the order (transmission order) of each message data and the message data to which each input request data is linked.

[0067] In the dialogue scenario data, the method for defining the order of each message data is not limited. For example, the dialogue scenario data may have a column for setting a sequence number for each message data, or may have a list structure in which each message data is linked in an order according to the sequence. In FIG. 7, the message data is linked (for example, by various linking methods such as pointers or arrays) in the order of message data MD001 to MD007. For example, in FIG. 7, message data MD002 is linked next to message data MD001, message data MD003 is linked next to message data MD002, ..., message data MD006 is linked next to message data MD007. Therefore, the dialogue scenario data shown in FIG. 7 indicates that message transmission processing is performed in the order of message data MD001 to MD007.

[0068] Furthermore, one or more pieces of input request data are linked to the dialogue scenario data.

[0069] Here, each message data is set with a "message body" that describes the message to be sent to the customer and data indicating the timing of sending the message body.

[0070] Each input request data item includes data for a "display option" that describes the display of the option (for example, the display of options such as "yes" or "no"); a "behavior" that describes the behavior when the option is selected (when an option of the display option is selected) (for example, "proceed to the next process without doing anything" or "process to reply with a specified message"); and a "reply text" that describes the text to be sent back when the option is selected. In this embodiment, it is assumed that only either "yes" or "no" can be input as the display option. Note that the display format and number of types of the display options are not limited, but in this embodiment, the following description will be given assuming that there are only two options, "yes" and "no."

[0071] Here, the behavior item constituting the input request data can be set to either a value indicating that if the option is selected, nothing will be done and the process will proceed to the next step (here, this will be written as "do nothing," but this can also be in the form of a flag), or a value indicating that if the option is selected, the text set in the "reply text" item will be returned (here, this will be written as "reply text," but this can also be in the form of a flag). Note that if the behavior in the input request data is "do nothing," the reply text item may be left blank (for example, "NULL").

[0072] For example, message data MD001 does not have any linked input request data, so it indicates that at the set timing, the text set in the message body (Thank you for your continued patronage...) will be sent to the customer's account, and processing will proceed to the next message data MD002.

[0073] Since two input request data OD001 and OD002 are linked to the message data MD002, the text set in the message body (Thank you for using our service. Please let us know your medication status.) is sent at the set timing, and the display options set in the first input request data OD001 (no) or the display options set in the second input request data OD002 (yes) are presented to the customer, and selection input (for example, selection input on the LINE application) of one of the options (either "yes" or "no") is accepted, and the "behavior" processing corresponding to the selected option is executed, after which processing of the next message data MD003 is moved on to.

[0074] For example, the first input request data OD001 has a display option "No," an action "Do nothing," and a reply text "Blank," which indicates that if the option "No" is selected, nothing will be done and the system will move on to processing the next message data MD004. Also, the first input request data OD001 has a display option "Yes," an action "Reply with text," and a reply text "What symptoms have you been experiencing, and since when?", which indicates that if the option "Yes" is selected, the system will send the reply text "What symptoms have you been experiencing, and since when?" to the customer, and will also accept a text input (reply) from the customer, and will store the input (reply) text as an answer from the customer, before moving on to processing the next message data MD004.

[0075] In this embodiment, it is assumed that two pieces of input request data can be linked to one piece of message data. In other words, in this embodiment, the dialogue scenario data will be described as existing with only two types of message data: message data with no linked input request data (message data that is simply sent unilaterally without requesting an answer; hereinafter referred to as "no-question message data"), and message data with two pieces of input request data linked to it (message data with two options set; hereinafter referred to as "question message data").

[0076] As shown in FIG. 7, each message data contains not only the text of the message to be sent (hereinafter referred to as the "sent text"), but also data for determining the date on which the sent text (message) will be delivered (hereinafter referred to as the "delivery timing determination information").

[0077] The delivery timing determination information includes information (hereinafter referred to as "delivery date attribute") for specifying a day within the prescribed drug taking period (e.g., the first day, last day, middle day, etc. of the taking period). Here, the delivery date attribute is described as being set to one of "first day" indicating the first day of the taking period, "last day" indicating the last day of the taking period, and "middle day" indicating a day between the first day and the last day. For example, if only one middle day is set within the taking period, the dialogue processing unit 14 may set the middle day to the day that is exactly halfway between the first day and the last day (e.g., if the taking period is 15 days, the middle day may be set to the 8th day). Also, for example, if multiple middle days are set within the taking period, the dialogue processing unit 14 may set the respective middle days to be equally spaced between the first day and the last day.

[0078] 7, in the dialogue scenario data, in addition to the delivery date attribute, the order of the intermediate dates set in the message data (hereinafter referred to as "intermediate date order") is set for each message data. For example, for dialogue scenario data in which only one intermediate date is set, only 1 may be set as the intermediate date order, and for dialogue scenario data in which two intermediate dates are set, 1 or 2 may be set as the intermediate date order.

[0079] In the dialogue scenario data, the first date is set as the delivery date attribute for one or more message data from the beginning, the last date is set as the delivery date attribute for one or more message data from the end, and an intermediate date is set as the delivery date attribute for the other message data (message data between the first and last dates).

[0080] In this embodiment, it is assumed that in the dialogue scenario data, only non-question message data is set on the first and last days, and question message data is set only on intermediate days. Note that it is desirable to limit the number of question message data sent to a customer on the same day to a predetermined number or less (to avoid imposing a burden on the customer). Therefore, in this embodiment, it is assumed that the number of question message data set on one intermediate day in the dialogue scenario data is limited to three or less.

[0081] For example, in the dialogue scenario data shown in Fig. 7, the delivery date attribute of the first message data MD001 is set to the first day, the last message data MD007 is set to the last day, and the delivery date attributes of the message data MD002 to MD006 in between are set to mid-days. In the dialogue scenario data shown in Fig. 7, there is only one mid-day, so the mid-day order of the message data MD002 to MD006 is set to 1.

[0082] For example, if two mid-days are set in the dialogue scenario data shown in Figure 7, message data with a delivery date attribute of "mid-day" and a mid-day order of 2 may be set between message data MD006 and MD007.

[0083] As described above, in the dialogue scenario data, by fixing the structure of the message data with a question (for example, by limiting the number of links in the input request data to two), the scenario is configured as a simple waterflow structure rather than a tree structure (a structure with multiple branches), making registration (for example, registration by a store pharmacist) easy and providing dialogue content that is easy for customers to understand.Since the format of questions asked to customers (patients) about medicines can be largely standardized, using a fixed format as described above rather than a complex tree structure makes it possible to facilitate registration and create a format that is easy for customers (patients) to respond to.

[0084] In this embodiment, the data recording unit 22 records the above dialogue scenario data as dialogue scenario templates in a date-specific template database 2209 and a drug-specific template database 2210. Hereinafter, the dialogue scenario data will also be simply referred to as a "template."

[0085] In this embodiment, the date-specific template database 2209 stores templates (dialogue scenario data) corresponding to the medication period based on the target prescription (hereinafter referred to as the "target period"). For example, the date-specific template database 2209 may store templates corresponding to patterns such as when the medication period based on the prescription is 5 days or less, between 6 and 45 days, between 46 and 90 days, etc. The date-specific template database 2209 may also store templates corresponding to prescriptions for which no medication period is set (for example, prescriptions for which only emergency medication or topical medication is prescribed) (for example, a template for which the medication period is 0 days).

[0086] Furthermore, in this embodiment, it is assumed that templates (dialogue scenario data) corresponding to drugs (prescription drugs) are recorded in the drug-specific template database 2210. In this embodiment, it is assumed that templates are registered in the drug-specific template database 2210 only for some of the drugs registered in the drug database 2208. Specifically, in this embodiment, it is assumed that templates including messages and questions appropriate for only drugs that meet predetermined conditions (hereinafter referred to as "template-registered drugs") are registered in the drug database 2208. In this example embodiment, it is assumed that templates are registered in the drug-specific template database 2210 as template-registered drugs only for so-called high-risk drugs (drugs that have a relatively high risk of side effects, etc. when taken). In other words, in this embodiment, it is assumed that dialogue scenario data is registered in the drug database 2208 only for template-registered drugs.

[0087] Here, the dialogue processing unit 14 may determine the content of the actual dialogue with the customer (the content of the message to be sent and received) by combining templates according to the prescription (for example, the dosing period of the longest dosing period among the drugs included in the prescription) and the drugs included in the prescription. In the following description, the dialogue processing unit 14 is described as preferentially delivering (over templates in the date-specific template database 2209) questions from templates for the drug when the prescription includes a drug for which a template is registered (a drug for which a template is registered in the drug-specific template database 2210). In other words, in this embodiment, the dialogue processing unit 14 may select and apply either a drug-specific template or a date-specific template for each intermediate day.

[0088] The internal configurations of the date-specific template database 2209 and the medicine-specific template database 2210 will be described in detail later.

[0089] Next, an overview of the report processing unit 16 will be described.

[0090] The report processing unit 16 creates a report on medication (medication based on the contents of medication dispensed based on a prescription) that reflects the contents of the dialogue processing performed by the dialogue processing unit 14.

[0091] The content of the report created by the report processing unit 16 is not limited, but in this embodiment, a report that conforms to the format of a so-called "tracing report" (medication information document) may be created and output (for example, as printable data).

[0092] A tracing report (medication information document) is a report that a pharmacist uses to communicate information that they believe should be provided to a doctor, such as information about side effects and adherence (patients actively participating in decisions about treatment plans and receiving treatment in accordance with those decisions) that they have heard from patients at a pharmacy (insurance pharmacy).

[0093] In other words, the dialogue scenario data processed by the dialogue processing unit 14 is assumed to be the content for obtaining information related to this tracing report (for example, information on side effects and adherence) from the customer (patient).

[0094] Next, we will explain configuration examples of each database (database) that makes up the data recording unit 22. In the following, for ease of explanation, each database (database) that makes up the data recording unit 22 is illustrated in table format, but in reality, various database data structures can be used.

[0095] FIG. 8 is an explanatory diagram showing an example of the configuration of the pharmacy database 2201.

[0096] The pharmacy database 2201 is a database for managing data relating to each pharmacy.

[0097] In the pharmacy database 2201 shown in FIG. 8, information items including "pharmacy ID," "pharmacy name," "address," and "telephone number" for identifying and managing the pharmacy are registered for each pharmacy.

[0098] FIG. 9 is an explanatory diagram showing an example of the configuration of the customer database 2202.

[0099] The customer database 2202 is a database for managing data relating to each customer (user).

[0100] In the customer database 2202 shown in FIG. 9, information items including "customer ID," "name," "date of birth," "gender," and "telephone number" for identifying and managing each customer are registered.

[0101] FIG. 10 is an explanatory diagram showing an example of the configuration of the MS customer management database 2203. As shown in FIG.

[0102] The MS customer management database 2203 is a database for managing the MS account ID of each customer (user).

[0103] In the MS customer management database 2203 shown in FIG. 10, information items including "customer ID" and "MS account ID" are registered for each customer.

[0104] FIG. 11 is an explanatory diagram showing an example of the configuration of the MS pharmacy management database 2204.

[0105] The MS pharmacy management database 2204 is a database for managing the MS account ID of each pharmacy.

[0106] In the MS pharmacy management database 2204 shown in FIG. 11, information items including a "pharmacy ID" and an "MS account ID" are registered for each pharmacy.

[0107] FIG. 12 is an explanatory diagram showing an example of the configuration of the medicine database 2208.

[0108] The medicine database 2208 is a database for managing medicines (pharmaceuticals) dispensed according to prescriptions.

[0109] In the drug database 2208 shown in Figure 12, information on items including a "drug ID" for identifying the drug, a "drug name," and a "drug code" for managing the drug's code number (e.g., a drug code number listed in the drug price list, etc.) is registered for each drug.

[0110] FIG. 13 is an explanatory diagram showing an example of the configuration of the prescription reservation database 2205.

[0111] The prescription reservation database 2205 is a database for managing prescription reservations accepted from customers through the processing of the prescription reservation processing unit 12.

[0112] In the prescription reservation database 2205 shown in Figure 13, the following information is registered for each prescription reservation: a "prescription reservation ID" for identifying the prescription reservation, a "pharmacy ID" to which the prescription reservation is addressed, 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").

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

[0114] FIG. 14 is an explanatory diagram showing an example of the configuration of the prescription database 2206.

[0115] The prescription database 2206 is a database for managing records when prescriptions are dispensed based on prescriptions in the processing of the storefront service processing unit 13.

[0116] In the prescription database 2206 shown in Figure 14, for each prescription, information is registered including a "prescription ID" to identify the prescription, the "pharmacy ID" of the pharmacy that dispensed the prescription, the "customer ID" of the pharmacy that dispensed the prescription, and information on items including "dispensing date" indicating the date when the prescription was dispensed, "medication start date," "medication end date," "name of medical institution," "prescribing physician," and "pharmacist in charge."

[0117] FIG. 15 is an explanatory diagram showing an example of the configuration of the prescription drug database 2207.

[0118] The prescription drug database 2207 is a database for managing each prescription drug prescribed in each prescription managed in the prescription database 2206. For example, if any prescription managed in the prescription database 2206 prescribes two prescription drugs, the prescription drug database 2207 will register data for the two prescription drugs (data for two records) corresponding to the prescription separately.

[0119] In the prescription drug database 2207 shown in FIG. 15, for each prescription drug, the following information is stored: a "prescription drug ID" for identifying the prescription drug, a "prescription ID" for identifying the prescription corresponding to the prescription drug, a "drug code", a "drug name", a "daily amount" indicating the daily prescribed amount of the prescription drug, a "dispensed amount" indicating the prescribed amount of the prescription drug (total prescribed amount), a "dosing interval" indicating the interval between doses of the prescription drug (unit: hours), a "dosing interval text" indicating the interval between doses of the prescription drug on a text basis (for example, a string of characters such as "after breakfast", "after breakfast, after dinner", etc.), and a "date" indicating the day on which the prescription drug should be started. The information registered includes the following items: "Date to start taking" indicating the date when the prescription drug will be taken; "Date to be taken during" indicating the midpoint of the entire period when the prescription drug will be taken; "Date to end taking" indicating the last day when the prescription drug will be taken; "Whether to notify when taking the prescription drug will start" indicating whether the message service system 50 will notify the customer of the timing of the date when the prescription drug will be taken; "Whether to notify while taking the prescription drug" indicating whether the message system will notify the customer of the timing of the date when the prescription drug will be taken; and "Whether to notify when taking the prescription drug will end" indicating whether the message service system 50 will notify the customer of the timing of the date when the prescription drug will be taken.

[0120] 16 and 17 show examples of the configuration of the date-specific template database 2209. FIG.

[0121] FIG. 16 is a diagram showing an example of the configuration of a database (hereinafter referred to as a “date-based template database”) that manages message data that constitutes the dialogue scenario data (templates) of the date-based template database 2209.

[0122] In Fig. 16, one line constitutes one message data. In Fig. 16, each message data has data set for items including "Template ID", "Root ID", "Parent ID", "Body text", "Delivery date attribute", "Delivery format", "Intermediate date order", "Lower limit of target period", and "Upper limit of target period".

[0123] In FIG. 16, "Template ID" indicates an identifier that identifies the message data. Also in FIG. 16, "Root ID" indicates the identifier (template ID) of the message data that is the root (head) of the dialogue scenario data to which the message data belongs. Furthermore, in FIG. 16, "Parent ID" indicates the identifier (template ID) of the message data linked immediately before the message data (the parent message data in the dialogue scenario data). Furthermore, in FIG. 16, "Body Text" indicates the text of the message to be sent to the customer.

[0124] Also, in FIG. 16, the "Delivery Format" item indicates whether the message data is "Message Data with Question" or "Message Data without Question." Here, when the delivery format is set to 1, it indicates that it is message data without question, and when the delivery format is set to 2, it indicates that it is message data with question. Furthermore, in FIG. 16, the "Lower Limit of Target Period" and the "Upper Limit of Target Period" respectively represent the lower and upper limits of the target period (target period of medication based on prescription) of the dialogue scenario data to which the message data belongs. For example, if the target period is 6 to 45 days, the lower limit of target period is set to 6 and the upper limit of target period is set to 45, as shown in FIG. 16.

[0125] FIG. 17 shows an example of the configuration of a database (hereinafter referred to as a “date-based option database”) that manages input request data that constitutes the dialogue scenario data (templates) of the date-based template database 2209.

[0126] In Fig. 17, one line constitutes one piece of input request data. In Fig. 17, each piece of input request data is set with data items including "Option ID", "Link ID", "Refractory Period Option", "Behavior", and "Reply Text".

[0127] 17, "Choice ID" indicates an identifier for identifying the relevant input request data. Also, in FIG. 17, "Link ID" indicates an identifier (template ID) of message data that is a link destination of the relevant input request data.

[0128] As shown in Figure 16, in the date-based template database, a list structure is established in which message data are connected in series by root ID and parent ID. Note that there are no limitations on the means for creating a list structure for multiple message data in the date-based template database, and various data structures such as an array structure may also be applied.

[0129] Note that the message data with template IDs TD001 to TD007 shown in Fig. 16 show the example of the dialogue scenario data structure (dialogue scenario data made up of message data MD001 to MD007) shown in Fig. 7. Also, the input request data with option IDs OD001 to OD006 shown in Fig. 17 show the example of the dialogue scenario data structure (example of the input request data OD001 to OD006) shown in Fig. 7.

[0130] 18 and 19 show examples of the configuration of the medicine-specific template database 2210. FIG.

[0131] Fig. 18 is a diagram showing an example of the configuration of a database (hereinafter referred to as the "drug-specific template database") that manages message data that constitutes the dialogue scenario data (templates) of the drug-specific template database 2210. Fig. 19 is a diagram showing an example of the configuration of a database (hereinafter referred to as the "drug-specific option database") that manages input request data that constitutes the dialogue scenario data (templates) of the drug-specific template database 2210.

[0132] The structure of the drug-specific template database is basically the same as the date-specific template database shown in FIG. 16, but differs in that the target period (target period lower limit, target period upper limit) is replaced with a "drug code" that identifies the drug. Note that in the drug-specific template database, the drug code may be replaced with another identifier (for example, a drug ID, etc.). The structure of the drug-specific option database is basically the same as the date-specific option database shown in FIG. 17.

[0133] FIG. 20 is a diagram showing an example of the configuration of the distribution management database 2211. As shown in FIG.

[0134] The delivery management database 2211 is a database for managing message delivery (dialogue processing) by the dialogue processor 14 based on message data (management of message delivery reservations, history, etc.).

[0135] In the delivery management database 2211 shown in FIG. 20, one line contains data for managing the delivery of one piece of message data (hereinafter referred to as "delivery management data").

[0136] In the delivery management database 2211, each delivery management data is composed of items including a "delivery ID" as an identifier to identify the delivery management data, a "prescription ID" indicating the corresponding prescription, a "template ID" indicating the corresponding message data, a "delivery date" indicating the date on which the corresponding message data will be processed, a delivery destination indicating the delivery destination (such as the LINE ID of the customer to whom the delivery is made), a "delivery format" indicating the delivery format (whether or not a question is asked), and a "status" indicating the status such as delivered or not delivered.

[0137] In the "status" shown in FIG. 20, "1" is set if the delivery has been completed, and "0" is set if the delivery has not yet been completed.

[0138] The dialogue processing unit 14 selects dialogue scenario data to be applied for each prescription (prescription ID) and sets the delivery management data in the delivery management database 2211 so as to perform dialogue processing in accordance with the selected dialogue scenario data. Then, for each delivery management data registered in the delivery management database 2211, the dialogue processing unit 14 performs processing to send message data (text body) corresponding to the template ID and an input request (for example, a request to select an option or a request to input text) based on the linked input request data to the delivery destination ID at the set delivery timing (the date set as the delivery date).

[0139] In this embodiment, the template ID system is changed between the date-specific template database 2209 and the medicine-specific template database 2210, so that the linked database (either the date-specific template database 2209 or the medicine-specific template database 2210) can be identified in the delivery management database 2211 and the response management database 2212; however, the method for identifying the linked database is not limited to the above method. For example, in this embodiment, the template ID in the date-specific template database 2209 is expressed as starting with "TD" and the option IDs are expressed as starting with "OD." Also, for example, in this embodiment, the template ID in the medicine-specific template database 2210 is expressed as starting with "TM" and the option IDs are expressed as starting with "OM."

[0140] FIG. 21 is a diagram showing an example of the configuration of the response management database 2212. As shown in FIG.

[0141] The answer management database 2212 is a database that manages the content of input (answer to the question-containing message data) when there is input (e.g., selection of an option or text input) from a customer (customer terminal 40) after the dialogue processing unit 14 sends an input request (e.g., a request to select an option or a request to enter text) based on input request data linked to the question-containing message data.

[0142] In the answer management database 2212 shown in FIG. 21, one line of data is used to manage an answer to one piece of message data with a question (hereinafter referred to as "answer management data").

[0143] In the answer management database 2212, each answer management data is composed of items including an "answer ID" as an identifier to identify the answer management data, a "delivery ID" indicating the corresponding delivery management data, a "template ID" indicating the corresponding message data, an "option ID" indicating the input request data corresponding to the option selected for the message data with a question, and an "answer text" indicating the text (text entered by the customer) if there is a reply text in the input request data corresponding to the selected option (an answer to the text reply behavior).

[0144] In other words, for each message data with a question, the dialogue processing unit 14 records, as answer management data, an option ID indicating the option (input request data) selected for the question and an "answer text" indicating the text entered by the customer in response to the question in the message data with a question.

[0145] (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-described configuration (the pharmacy support method according to the embodiment) will be described.

[0146] Here, an example will be described in which the Web application server 10 of the pharmacy support system 1 operates in accordance with the scenario of FIG.

[0147] First, an overview of the scenario in FIG. 14 will be described.

[0148] 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" whose MS account ID is "taro_ms" via the portal function (function of the portal processing unit 11) and the message service system 50 (S101).

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

[0150] Next, it is assumed that a process is performed on the message service system 50 to associate the customer's MS account ID with the AAA pharmacy's MS account ID (e.g., registering as a friend in the LINE service) (S103). This makes it possible to send a message from the AAA pharmacy's MS account ID to the customer's MS account ID (e.g., message transmission associated with interactive processing). Note that the same processes as those in Patent Document 1 can be applied to the processes in steps S101 to S103, and therefore detailed explanations will be omitted here.

[0151] Furthermore, at the pharmacy (AAA pharmacy), when dispensing, the prescription details are entered into the receipt computer 70 (receipt processing program 72), and data that can output a dispensing fee statement or a dispensing fee statement is held. Then, in the receipt computer 70, the prescription data is held by the upload processing unit 73, and uploaded to the Web application server 10 (prescription reservation processing unit 12), and the prescription details are registered in the prescription database 2206 and the prescription drug database 2207 (S104).

[0152] The prescription reservation processing unit 12 recognizes the source of the prescription data, thereby recognizing which pharmacy the prescription came from, and can further determine customer (patient) information (e.g., name, date of birth, etc.) based on the contents of the prescription data, thereby recognizing which customer ID the prescription belongs to. The prescription reservation processing unit 12 then registers the prescription information recognized by uploading it in the prescription database 2206 and the prescription drug database 2207. In this embodiment, by registering the prescription contents on the Web application server 10 (prescription reservation processing unit 12) side based on the contents entered in the prescription computer 70 (prescription processing program 72), as described above, it is no longer necessary for the pharmacy to enter the prescription contents twice. In addition, in the Web application server 10 (prescription reservation processing unit 12), the method of inputting the prescription contents into the prescription database 2206 and the prescription drug database 2207 is not limited to the above method, and various methods (for example, a method in which the prescription contents are directly input by a pharmacist at a pharmacy, or a method in which the contents are input based on recorded data such as a barcode attached to the prescription) can be applied.

[0153] Thereafter, the dialogue processing unit 14 selects dialogue scenario data to be applied according to the new prescription registered in step S103, and sets distribution management data in the distribution management database 2211 so as to perform dialogue processing in accordance with the selected dialogue scenario data (S105).

[0154] Then, for each distribution management data registered in the distribution management database 2211, the dialogue processing unit 14 performs a process of sending message data (text body) corresponding to the template ID and an input request (for example, a request to select an option or a request to enter text) based on the linked input request data to the ID of the distribution destination at the set distribution timing (the date set as the distribution date), and registers the content entered by the customer in the response management database 2212 (S106).

[0155] Thereafter, in response to an operation by the staff member (pharmacist) of the pharmacy, the report processing unit 16 generates and outputs a tracing report corresponding to the prescription (the prescription registered in step S104) (S107).

[0156] Below we provide specific examples of each step in the above scenario.

[0157] First, the operations in steps S101 to S103 may be similar to those described in Patent Document 1, and therefore detailed description thereof will be omitted.

[0158] Here, we will assume that, through the processing of steps S101 to S103, a customer with customer ID: 1 shown in Figures 9 and 10 is registered in the customer database 2202 and MS customer management database 2203 at AAA pharmacy (pharmacy with pharmacy ID: 1), respectively, and that a prescription reservation with prescription reservation ID: 1 shown in Figure 13 is registered in the prescription reservation database 2205.

[0159] Next, a specific example of the process in step S104 will be described.

[0160] [S104: Upload and register prescription data] Here, it is assumed that a prescription is dispensed at the AAA pharmacy in accordance with the prescription reservation of "prescription reservation ID: 1," and the prescription details associated with the dispensing are entered into the receipt computer 70 of the AAA pharmacy. Then, in the receipt computer 70, prescription data for the prescription is generated by the receipt processing program 72, and is uploaded to the Web application server 10 (prescription reservation processing unit 12) by the upload processing unit 73. Then, the prescription reservation processing unit 12 registers the contents of the prescription in the prescription database 2206 and the prescription drug database 2207 based on the prescription data.

[0161] Here, it is assumed that data of prescription ID: 1 is newly registered in the prescription database 2206 (prescription drug database 2207). Also, it is assumed that data of prescription order IDs: 1 and 2 are registered in the prescription drug database 2207 as prescription orders corresponding to the prescription ID: 1.

[0162] [S105: Message delivery reservation processing based on dialogue scenario data] Here, the dialogue processing unit 14 acquires the contents of the prescription (prescription with prescription ID: 1) from the prescription database 2206, and selects dialogue scenario data to be used for a dialogue with the customer (patient) of the prescription based on the prescription contents (for example, the medication period, the contents of the prescribed drugs, etc.). Here, it is assumed that the dialogue processing unit 14 has selected dialogue scenario data corresponding to the medication period (the period between the medication start date and medication end date) from the date-specific template database 2209 shown in FIG. 16. Here, it is assumed that the dialogue processing unit 14 has selected dialogue scenario data with a root ID (first message data) of TD001 (i.e., dialogue scenario data with a structure as shown in FIG. 7) as the dialogue scenario data corresponding to the medication period. It is assumed here that the prescription with prescription ID: 1 did not contain any drugs registered in a template.

[0163] Then, the dialogue processing unit 14 registers each message data of the selected dialogue scenario data in the delivery management database 2211. As a result, it is assumed that the delivery data with delivery IDs 1 to 7 in FIG. 20 are registered in the delivery management database 2211.

[0164] [S106: Message sending / receiving and response recording processing according to delivery reservation processing] In this example, the dialogue processing unit 14 performs delivery processing on the delivery data (delivery data with delivery IDs 1 to 7) as shown in FIG. 20. The dialogue processing unit 14 identifies the delivery data for each delivery destination and performs delivery processing for each delivery destination in order of the delivery data with the smallest delivery ID. If there is delivery data with delivery format 2, the dialogue processing unit 14 waits for an answer to be input to the question before proceeding to processing the next delivery data. Furthermore, for delivery data for a single delivery destination that has the same delivery date, the dialogue processing unit 14 performs delivery processing without any gaps other than between answer inputs. For example, in the example of FIG. 20, the delivery dates of the delivery data with delivery IDs 2 to 6 are set to the same day, so these delivery data may be processed continuously except between answer inputs. Furthermore, the dialogue processing unit 14 may set the start time of delivery processing to a predetermined time within a day (for example, 1:00 p.m., a time period when customers are likely to respond). For example, the dialogue processing unit 14 may perform the distribution processing for distribution data with distribution ID 2 at a predetermined time (e.g., 13:00) rather than at midnight on August 8, 2021.

[0165] When processing distribution data in distribution format 2, the dialogue processing unit 14 records the answer from the customer in the answer management database 2212 as answer data.

[0166] In FIG. 20, the distribution data with distribution IDs 3 to 5 have distribution format 2, and the answer data corresponding to each distribution data is data with answer IDs 1 to 3 in FIG.

[0167] FIG. 25 is a diagram showing an example of the results (interactive processing with customer terminal 40) of distribution according to distribution data corresponding to the prescription with prescription ID: 1 (distribution data with distribution IDs 1 to 7 in FIG. 20).

[0168] FIG. 25 shows an example of the display screen of the message service AP 43 (the screen displayed on the touch panel display 41) displayed on the customer terminal 40. Also, in FIG. 25, a message sent from the pharmacy (Web application server 10) is displayed in a speech bubble on the left side, and the input content (including the selection content) from the customer side is displayed on the right side. Furthermore, in FIG. 25, the options based on the input request data (the options of "yes" or "no") are shown surrounded by dotted lines, and the options selected by the customer ("yes" or "no") are shown in a speech bubble on the right side. In the example of FIG. 25, "no" is selected for all options, so no reply text is entered.

[0169] When the dialogue processing shown in FIG. 25 is performed, the contents of the answer management database 2212 will be as shown in FIG. 21 (answer data with answer IDs 1 to 3).

[0170] [S107: Tracing report creation process] Here, it is assumed that pharmacist A of AAA pharmacy operates the pharmacy terminal 30, selects the prescription with prescription ID: 1 in the prescription database 2206, and performs an operation to output a tracing report for that prescription.

[0171] In this case, the report processing unit 16 first obtains the contents of the prescription with prescription ID: 1 from the prescription database 2206, and then obtains information on the customer (patient) of the prescription from the customer database 2202 or the like.

[0172] Furthermore, the report processing unit 16 extracts distribution data with prescription ID: 1 and distribution format 2 from the distribution management database 2211, and extracts response data corresponding to the collected distribution data from the response management database 2212. Furthermore, the report processing unit 16 acquires information (e.g., insurance pharmacy name, pharmacy address, telephone number, etc.) of the pharmacy (insurance pharmacy) that will create the tracing report from the pharmacy database 2201, based on information about the user (user corresponding to the pharmacy) logged in at the pharmacy terminal 30.

[0173] In this way, the report processing unit 16 can extract the answer data with answer IDs 1 to 3 in FIG.

[0174] Through the above processing, the report processing unit 16 collects the information necessary to create a tracing report, displays the tracing report with the collected information entered, and displays an operation screen (hereinafter referred to as the "report editing screen") on the pharmacy terminal 30 (Web browser 32) that allows editing of each piece of information in the displayed tracing report.

[0175] FIG. 24 is a diagram showing an example of the configuration of the report editing screen.

[0176] In the report editing screen shown in Figure 24, the information in the header section (e.g., medical institution name, prescription date, patient name, date of birth, dispensing date, gender, etc.) can be automatically entered based on information from the prescription database 2206, customer database 2202, pharmacy database 2201, etc.

[0177] In FIG. 24, information that can be entered based on information in the prescription database 2206, the customer database 2202, the pharmacy database 2201, etc. is automatically entered.

[0178] In addition, based on the acquired answer data (answer data with answer IDs 1 to 3), the report processing unit 16 generates text data regarding the questions and answers asked in the dialogue with the customer (patient) and automatically inputs the data into the report editing screen (the "Provided information / Proposal content" item).

[0179] In FIG. 24, text based on the response data is automatically input (pasted) into the field F101 (item "Provided Information / Proposal Content").

[0180] When displaying the report editing screen, the report processing unit 16 automatically inputs information for items that can be automatically input based on the information collected as described above. After performing the automatic input process on the report editing screen, the report processing unit 16 can accept free editing of all items. In response to the pharmacist's operation, the report processing unit 16 can output the tracing report displayed on the report editing screen in various ways (for example, printing, outputting as PDF, etc.).

[0181] This allows the pharmacist to obtain the tracing report with the simple operations described above, and all that remains is for the pharmacist to do is submit the tracing report to the medical institution, and the processing related to the tracing report will be completed.

[0182] [Example of prescription drugs containing template-registered drugs] Next, an example will be described in which both a date-specific template and a drug-specific template are applied to the interactive processing for one prescription.

[0183] 14, 15, 18, and 19, the prescription with prescription ID: 2 includes a drug for which a template is registered (drug C). As shown in Figures 18 and 19, a drug-specific template for drug C with TM001 as the root ID (template ID) is registered in the drug-specific template database 2210.

[0184] Therefore, when performing message delivery reservation processing based on dialogue scenario data for the prescription with prescription ID: 2 (the processing of step S105 above), the dialogue processing unit 14 will apply a date-specific template (a template with TD001 as the root ID) and a drug-specific template (a template with TD001 as the root ID).

[0185] As described above, in this embodiment, when a prescription contains a drug corresponding to a registered template, the dialogue processing unit 14 preferentially delivers questions for the template for that drug. For example, as shown in the delivery management database 2211 in FIG. 20 , the dialogue processing unit 14 may apply message data from a date-specific template (a template with TD001 as the root ID) to the first and last days, and extract and apply message data from a drug-specific template (a template with TM001 as the root ID) to intermediate days. In this case, the dialogue processing unit 14 may replace message data for each intermediate day (each intermediate day order) in the date-specific template with message data for the corresponding intermediate day (each intermediate day order) in the drug-specific template, and schedule delivery (reflect the message data in the delivery management database 2211). For example, the dialogue processing unit 14 may replace message data with an intermediate date order of N in the date-specific template with message data with an intermediate date order of N in the drug-specific template (message data with an intermediate date order that matches the date-specific template), and schedule delivery. Specifically, for example, the dialogue processing unit 14 may make a delivery reservation by replacing the message data of intermediate date order: 1 in the date-specific template (message data of TD002 to TD006) with the message data of intermediate date order: 1 in the medicine-specific template (TM002 to TM006), as shown in Fig. 20. Furthermore, if a prescription includes multiple medicines registered in a template, the dialogue processing unit 14 may select one of the medicines registered in the template for each intermediate date (for example, by selecting randomly or by any other method) and reflect this in the delivery reservation.

[0186] As described above, in this embodiment, the dialogue processing unit 14 selects either a date-specific template or a medicine-specific template for each intermediate date to schedule delivery.

[0187] In this case, the distribution data corresponding to prescription ID: 2 is the distribution data with distribution IDs 8 to 14 shown in FIG.

[0188] 25 is a diagram showing an example of the results (interactive processing with customer terminal 40) of distribution according to distribution data corresponding to prescription ID: 2 (distribution data with distribution IDs 8 to 14 in FIG. 20). FIG. 25 is written in the same format as FIG. 23.

[0189] Figure 26 is a diagram showing an example of a report editing screen displayed on the pharmacy terminal 30 (touch panel display 31) when the report processing unit 16 attempts to output a tracing report for a prescription with prescription ID: 2.

[0190] 21, field F101 shown in FIG. 26 is automatically populated with text data according to the contents of answer management database 2212 (answer data of answer IDs: 4 to 6). For example, answer data of answer ID: 4 has template ID: TM003, option ID: OM002, and answer text: "I've had blurred vision since the first day." Therefore, field F101 shown in FIG. 26 is automatically populated with text "Q. Have you had blurred vision? A. Yes, I've had blurred vision since the first day" based on the contents of medication-specific template database 2210 (the contents of FIGS. 19 and 20). Similarly, field F101 shown in FIG. 26 is automatically populated with text "Q. Have you felt drowsy? A. Yes, I've felt very drowsy since the first day" based on answer data of answer ID: 5, and with text "Q. Have you felt shortness of breath? A. Yes, I've had shortness of breath since the first day" based on answer data of answer ID: 6.

[0191] FIG. 26 shows the state (initial state) in which the report processing unit 16 has performed automatic input, but as described above, the report editing screen can accept further editing by the pharmacist.

[0192] FIG. 27 is a diagram showing an example of a state in which the report editing screen has been further edited from the initial state.

[0193] On the report editing screen, the pharmacist added the following string to field F101 as information about the patient's side effects (information for the doctor): "There is a possibility of side effects occurring. The patient was advised to receive the information early and consult a doctor."

[0194] Also, on the report editing screen in Fig. 27, an additional check mark has been placed in the checkbox CB101 relating to side effects. On the report editing screen, for example, as shown in Fig. 27, it is possible for a pharmacist to freely edit the automatically entered initial state.

[0195] As shown in Figures 26 and 27, the report editing screen may be configured to accept operations (on / off operations for check boxes) for items in check box format (for example, check boxes for "Medication status," "Information provision regarding remaining medication adjustment," "Side effects," etc. in the tracing report shown in Figure 27).

[0196] (A-3) Effects of the First Embodiment According to the first embodiment, the following effects can be achieved.

[0197] In the pharmacy support system 1 of the first embodiment, dialogue processing can be performed based on a date-specific template (date-specific template database 2209) according to the medication period determined by the contents of the prescription. As a result, in the pharmacy support system 1 of the embodiment, dialogue processing based on dialogue scenario data according to the length of the medication period can be performed automatically without the need for operation by a pharmacist.

[0198] Furthermore, the pharmacy support system 1 of the first embodiment performs interactive processing in which the content of the date-specific template is changed in consideration of the drug-specific template (drug-specific template database 2210) corresponding to the prescribed drug. As a result, the pharmacy support system 1 of the first embodiment can ask the customer (patient) a question (message data with a question) according to the nature of the template-registered drug when the prescribed drug includes the drug. This allows patients to realize risk reduction, such as preventing health damage associated with side effects from the drugs they take.

[0199] Furthermore, in the pharmacy support system 1 of the first embodiment, the contents of the tracing report are automatically input based on the contents of the interactive processing. As a result, the pharmacy support system 1 of the embodiment can reduce the work of inputting the tracing report by the pharmacist.

[0200] (B) Other embodiments The present invention is not limited to the above-described embodiments, and may include modified embodiments such as those exemplified below.

[0201] (B-1) In the pharmacy support system 1 of the above embodiment, the Web application server 10 and the database server 20 are configured using separate computers, but they may also 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, the number of computers that make up the pharmacy support system 1 is not limited.

[0202] (B-2) Although the pharmacy support system 1 in the above embodiment is configured as a web-based system, it may also have a client-server configuration (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 operations 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.

[0203] (B-3) In the above embodiment, an example was described in which the report processing unit 16 outputs a tracing report for each prescription selected in response to an operation by the pharmacist. However, tracing reports for multiple prescriptions may be output in bulk (for example, by printing from the printer 60 or generating and outputting a PDF file) to simplify (improve efficiency of) the pharmacist's operation to output tracing reports. In this case, the report processing unit 16 may automatically output tracing reports (outputting only the content that can be automatically input without editing by the pharmacist) in bulk for prescriptions that meet predetermined conditions (hereinafter referred to as "prescriptions eligible for automatic output"). For example, in the interactive processing, a prescription for which the "no" option is selected as the display option for all questioned message data (hereinafter referred to as a "no-problem prescription") may be determined to be an automatic output prescription, while a prescription for which the "yes" option is selected as the display option for some or all questioned message data (hereinafter referred to as a "problem-problem prescription") may not be determined to be an automatic output prescription.

[0204] For example, the report processing unit 16 can extract problem-free prescriptions by referring to the data in the delivery management database 2211 and the response management database 2212 for each prescription (prescription ID). For example, when referring to the response data related to prescription ID: 1 in the response management database 2212 shown in FIG. 21, the display option "none" is selected for all questioned message data. Therefore, the report processing unit 16 can determine that prescription ID: 1 is a "problem-free prescription." On the other hand, when referring to the response data related to prescription ID: 2 in the response management database 2212 shown in FIG. 21, message data with a question in which the display option "yes" is selected is included. Therefore, the report processing unit 16 can determine that prescription ID: 2 is not a "problem-free prescription" (it is a "problematic prescription").

[0205] (B-4) In the above embodiment, the dialogue processing unit 14 has been described as determining the content of the dialogue processing to be performed with the customer (patient) using templates (dialogue scenario data) registered in the date-specific template database 2209 and the medicine-specific template database 2210. However, the dialogue processing unit 14 may also be configured to support a function for editing the templates registered in the date-specific template database 2209 and the medicine-specific template database 2210. For example, the dialogue processing unit 14 may present an operation screen for editing templates (hereinafter referred to as a "template editing screen") to the pharmacy terminal 30, and accept editing of the template (e.g., registering a new template, changing an existing template, etc.) in response to an operation by a pharmacist or the like.

[0206] FIG. 28 is a diagram showing an example of the configuration of the template editing screen.

[0207] The template editing screen includes a no-question message data input object OB101 for accepting input of no-question message data, and a question-containing message data input object OB102 for accepting input of question-containing message data (including accompanying input request data).

[0208] A field F201 for accepting input of the text body is arranged in the no-question message data input object OB101. One object OB101 can accept input of one no-question message data.

[0209] On the other hand, the question message data input object OB102 has arranged therein a field F201 for receiving input of the text body, and two sub-objects SOB1 and SOB2 for receiving input of input request data.

[0210] Sub-objects SOB1 and SOB2 each have a field F301 for accepting input of display options, a field F302 for accepting input of behavior, and a field F303 for accepting input of reply text. Field F301 may be configured to accept input of "Yes" or "No" in a selectable format. Field F302 may be configured to accept input of "Do nothing" or "Reply with text" in a selectable format. Therefore, the question-message data input object OB102 can accept input of one question-message data and two associated input request data.

[0211] The template editing screen displays multiple objects (question / question message data input objects) arranged vertically, and allows editing of each object. On the template editing screen, multiple objects displayed side by side are combined to represent a single template (dialogue scenario data). On the template editing screen, the object at the top indicates the message data that serves as the root ID, and objects for each message data are arranged from the top downwards.

[0212] As a result, the template editing screen visually displays a template (dialogue scenario data) made up of message data and input request data.

[0213] 28, each object (question / question message data input object) is provided with a button B101 for accepting insertion of a new no-question message data input object immediately before it, a button B102 for accepting insertion of a new question message data input object immediately before it, and a button B103 for accepting deletion of that object. Furthermore, the template editing screen shown in Fig. 28 has a button B201 at the bottom for accepting addition of a new no-question message data input object, and a button B202 at the bottom for accepting addition of a new question message data input object.

[0214] On the template editing screen shown in FIG. 28, these buttons allow addition or deletion of message data (message with question / message without question) at any position in the template.

[0215] (B-5) In the pharmacy support system 1 of the first embodiment, similar to the configuration described as the second embodiment in Patent Document 1, the message processing unit 15 of the Web application server 10 may be configured to send and receive messages with each customer's MS account ID (customer terminal 40) using the MS account ID on the pharmacy support system 1 side (in the example of Patent Document 1, the representative ID called "YS_MS"). [Explanation of symbols]

[0216] 1...Pharmacy support system, 10...Web application server, 11...Portal processing unit, 12...Prescription reservation processing unit, 13...Store service processing unit, 14...Dialogue processing unit, 15...Message processing unit, 16...Report processing unit, 20...Database server, 21...Database processing unit, 22...Data recording unit, 30...Pharmacy terminal, 31...Touch panel display, 32...Web browser, 40...Customer terminal, 41...Touch panel display, 42...Camera, 43...Web browser, 50...Message service system, 60...Printer, 70...Receipt computer data, 71...touch panel display, 72...prescription processing program, 73...upload processing unit, 2201...pharmacy database, 2202...customer database, 2203...MS customer management database, 2204...MS pharmacy management database, 2205...prescription reservation database, 2206...prescription database, 2207...prescription drug database, 2208...drug database, 2209...date-specific template database, 2210...drug-specific template database, 2211...distribution management database, 2212...response management database.

Claims

1. an account management means for managing a pharmacy account used in a message service corresponding to a pharmacy and a customer account used in the message service corresponding to a customer of the pharmacy; a prescription management means for managing the contents of prescriptions dispensed to said customers; a message processing means for transmitting a message from the pharmacy account to the customer account via the message service according to a scenario corresponding to the content of the prescription for each prescription at a timing corresponding to the content of the prescription, and receiving a response content transmitted from the customer account to the pharmacy account via the message service; a response management means for managing the contents of responses received by the message processing means; a pharmacy terminal processing means for supplying the message processed by the message processing means to a pharmacy terminal disposed in the pharmacy; a scenario data storage means for storing a plurality of scenario data defining the contents of the messages to be transmitted by the message processing means, the message processing means stores the scenario data corresponding to the prescription from the scenario data stored in the scenario data storage means, and transmits a message in accordance with the stored scenario data; The method further comprises a report generation / output means for generating one or more medication information reports that describe part or all of the content transmitted and received by the message processing means, and performing a batch output process for outputting the generated reports in a batch, The scenario data includes one or more problem question scenarios for sending a problem question message to the customer account to inquire about the presence or absence of problems regarding the administration of the medicine described in the prescription, and receiving a response to the problem question message; The report generation and output means writes answers to one or more of the question messages regarding the presence or absence of a problem in the report, and excludes the report in which the answer to one or more of the question messages regarding the presence or absence of a problem is "problem" from the batch output process. A pharmacy support system characterized by:

2. In the pharmacy support method performed by the pharmacy support system, the pharmacy support system comprises an account management means, a prescription management means, a message processing means, a response management means, a pharmacy terminal processing means, a scenario data storage means, and a report generation and output means; the account management means manages a pharmacy account used in a message service corresponding to a pharmacy and a customer account used in the message service corresponding to a customer of the pharmacy; The prescription management means manages the contents of prescriptions dispensed to the customers, the message processing means transmits, for each prescription, a message from the pharmacy account to the customer account via the message service in accordance with a scenario corresponding to the content of the prescription at a timing corresponding to the content of the prescription, and receives a response content transmitted from the customer account to the pharmacy account via the message service; the response management means manages the content of the response received by the message processing means, The pharmacy terminal processing means supplies the message processed by the message processing means to a pharmacy terminal located in the pharmacy; the scenario data storage means stores a plurality of scenario data defining the contents of messages to be transmitted by the message processing means; the message processing means stores the scenario data corresponding to the prescription from the scenario data stored in the scenario data storage means, and transmits a message in accordance with the stored scenario data; the report generation and output means generates one or more medication information reports describing part or all of the content transmitted and received by the message processing means, and performs a batch output process of outputting the generated reports in a batch; The scenario data includes one or more problem question scenarios for sending a problem question message to the customer account to inquire about the presence or absence of problems regarding the administration of the medicine described in the prescription, and receiving a response to the problem question message; The report generation and output means writes answers to one or more of the question messages regarding the presence or absence of a problem in the report, and excludes the report in which the answer to one or more of the question messages regarding the presence or absence of a problem is "problem" from the batch output process. A pharmacy support method characterized by:

Images