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

Description

Applicable to Article 30, Paragraph 2 of the Patent Act Published on October 14, 2020 on the website (https://www.yppp.info/, https://yppp.jp, https://www.kenko-salon.com/yppp, https://www.kenko-salon.com/) Published on October 14, 2020 on the website (https://yppp.jp, https://yppp.jp/client/login/login (address for accessing the provision system)) Published on November 14, 2020 on the website (https://pnb.jiho.jp/ (Pharmacy News Break))

This invention relates to a pharmacy support system and a pharmacy support method, and can be applied, for example, to a system that supports operations related to transactions and medication guidance between a pharmacy and a customer (patient).

Conventionally, information systems for supporting (assisting) the operations of dispensing pharmacies exist, such as the technology described in Patent Document 1.

Patent Document 1 describes how a messaging service system is used for communication between pharmacists and patients, thereby reducing the effort required for pharmacists to receive health consultations and provide health information from customers.

Japanese Patent Publication No. 2020-149110

By the way, the work at a pharmacy doesn't end with just dealing with patients; it encompasses a wide range of tasks, including creating various reports based on interactions with patients and handling accounting.

However, while the technology described in Patent Document 1 enables efficient communication between pharmacists and patients, patient-related tasks in a pharmacy are not limited to this; they encompass a wide range of activities, including the creation of various reports based on interactions with patients and accounting procedures.

Therefore, there is a need for pharmacy support systems and methods that can perform various patient-related tasks more efficiently in pharmacies.

The first pharmacy support system of the present invention includes: a pharmacy account used in a messaging service corresponding to a pharmacy; an account management means for managing customer accounts used in the messaging service corresponding to customers of the pharmacy; a prescription management means for managing the contents of prescriptions dispensed to customers; a message processing means for sending a message from the pharmacy account to the customer account via the messaging service according to a scenario corresponding to the contents of the prescription, at a timing corresponding to the contents of the prescription, and receiving the response content sent from the customer account to the pharmacy account via the messaging service; a response management means for managing the response content 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 located in the pharmacy; and a scenario data holding means for holding a plurality of scenario data defining the contents of the messages to be sent by the message processing means. The message processing means further comprises a report generation and output means which holds scenario data corresponding to the prescription from the scenario data held by the scenario data holding means, sends a message according to the held scenario data, generates one or more medication information reports describing some or all of the contents sent and received by the message processing means, and performs a batch output processing to output the generated reports in a batch, wherein the scenario data includes one or more problem presence/absence question scenarios which send a problem presence/absence question message to the customer account asking whether there are any problems regarding the taking of the medication described in the prescription and receive a response to the problem presence/absence question message, and the report generation and output means describes one or more responses to the problem presence/absence question messages in the report, and excludes reports in which one or more responses to the problem presence/absence question messages indicate a problem from the batch output processing .

The second aspect of the present invention relates to a pharmacy support method performed by a pharmacy support system, wherein the pharmacy support system comprises account management means, prescription management means, message processing means, response management means, pharmacy terminal processing means , scenario data holding means, and report generation output means , wherein the account management means manages pharmacy accounts used in a message service corresponding to a pharmacy and customer accounts used in the message service corresponding to the pharmacy's customers, 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 according to a scenario corresponding to the contents of the prescription at a timing corresponding to the contents of the prescription, and receives the contents of responses sent from the customer account to the pharmacy account via the message service, the response management means manages the contents of responses received by the message processing means, and the pharmacy terminal processing means supplies the messages processed by the message processing means to a pharmacy terminal located in the pharmacy. The scenario data holding means holds a plurality of scenario data defining the content of messages 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 according to the held scenario data , the report generation output means generates one or more medication information reports describing some or all of the content sent and received by the message processing means, and performs batch output processing to output the generated reports in a batch, the scenario data includes one or more problem presence/absence question scenarios that send a problem presence/absence question message to the customer account asking whether there are any problems regarding the taking of the medication described in the prescription, and receive a response to the problem presence/absence question message, the report generation output means describes one or more responses to the problem presence/absence question messages in the report, and excludes reports in which one or more responses to the problem presence/absence question messages indicate a problem from the batch output processing .

According to this invention, it is possible to improve the health of customers while reducing the workload of pharmacies.

This is a block diagram showing the connection configuration of each device related to the first embodiment. This is a block diagram showing the functional configuration of the Web application server according to the first embodiment. This is a block diagram showing the functional configuration of the database server according to the first embodiment. This is a block diagram showing the functional configuration of a pharmacy terminal according to the first embodiment. This is a block diagram showing the functional configuration of a customer terminal according to the first embodiment. This is a block diagram showing the functional configuration of the medical billing computer according to the first embodiment. This is an illustrative diagram showing the general structure of the dialogue scenario data according to the first embodiment. This figure shows an example of the configuration of a pharmacy database according to the first embodiment. This figure shows an example of the configuration of a customer database according to the first embodiment. This figure shows an example configuration of the MS customer management database according to the first embodiment. This figure shows an example of the configuration of the MS pharmacy management database according to the first embodiment. This figure shows an example of the configuration of a drug database according to the first embodiment. This figure shows an example of the configuration of a prescription reservation database according to the first embodiment. This figure shows an example of the configuration of a prescription database according to the first embodiment. This figure shows an example of the configuration of a prescription drug database according to the first embodiment. This figure shows an example of the configuration of a date-based template database according to the first embodiment. This figure shows an example of the configuration of a date-based selection database according to the first embodiment. This figure shows an example of the configuration of a drug-specific template database according to the first embodiment. This figure shows an example of the configuration of a drug-specific selection database according to the first embodiment. This figure shows an example configuration of the distribution management database according to the first embodiment. This figure shows an example of the configuration of the response management database according to the first embodiment. This is a flowchart illustrating an example (scenario) of the operation of the pharmacy support system according to the first embodiment. This figure shows an example (part 1) of dialogue processing according to the first embodiment. This figure shows an example configuration (part 1) of the report editing screen according to the first embodiment. This figure shows an example (part 2) of the dialogue processing according to the first embodiment. This figure shows an example configuration (part 2) of the report editing screen according to the first embodiment. This figure shows an example configuration (part 3) of the report editing screen according to the first embodiment. This figure shows an example configuration (part 3) of the template editing screen according to the first embodiment.

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

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

Pharmacy Support System 1 is a system designed to support the operations of dispensing pharmacies, thereby reducing the workload on pharmacy staff (pharmacists, etc.) and promoting the health of the customers (patients) of the supported pharmacies.

The pharmacy support system 1 shown in Figure 1 includes a web application server 10 and a database server 20. Note that the symbols in parentheses in Figure 1 are used only in the second embodiment described later.

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

The message service system 50 can be any of the various messaging services (chat services) available, such as LINE®, Facebook®, or Skype®. Below, we will describe an example where the message service system 50 uses the version of LINE available at the time of filing.

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

The pharmacy terminal 30 is a terminal installed in a pharmacy that receives services (business support) from the Web application server 10. For example, a tablet or PC can be used as the pharmacy terminal 30. Furthermore, a printer 60 capable of printing detailed statements and other documents is assumed to be connected to the pharmacy terminal 30.

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

Next, we will explain the internal configuration of each device that makes up Pharmacy Support System 1.

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

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

In this embodiment, the Web application server 10 includes a portal processing unit 11, a prescription reservation processing unit 12, a storefront service processing unit 13, a dialogue processing unit 14, a message processing unit 15, and a report processing unit 16.

The web application server 10 can be implemented, for example, by executing a program (for example, a program using HTML or PHP) on an environment with middleware for various web servers (for example, so-called Apache or Nginx).

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

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

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

The database server 20 can be constructed using, for example, a computer with memory and a processor (e.g., a PC or workstation).

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

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

The database processing unit 21 performs data processing on the databases recorded in the data recording unit 22. The database processing unit 21 can be constructed using, for example, various DBMS (Database Management Systems). Therefore, each database recorded in the data recording unit 22 must be configured with a data structure corresponding to that of the database processing unit 21. The database processing unit 21 performs data processing (for example, data updating or reading) on each database recorded in the data recording unit 22 in response to requests (commands) from the web application server 10.

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

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

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

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

The touch panel display 31 is a device (a device that performs user interface functions) that outputs information to pharmacy staff holding the pharmacy terminal 30 and accepts input from pharmacy staff (for example, input using a GUI screen). While the first embodiment shows an example of constructing the pharmacy terminal 30 using a tablet PC, the type of device that performs the user interface (means for input from pharmacy staff and means for output to pharmacy staff) in the pharmacy terminal 30 is not limited.

Various web browsers can be applied 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 web application programs for pharmacies. Alternatively, the pharmacy terminal 30 may be configured to install the pharmacy application programs as dedicated applications rather than being web-based. Here, it is assumed that the web browser 43 also has a program (plugin) installed that allows access to and login to the message service system 50 (message service). Furthermore, it is assumed that the MS account ID and password of the user using the customer terminal 40 are set in this plugin of the web browser 43.

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

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

The customer terminal 40 can be constructed using various terminal devices (computers; hardware) such as smartphones, PCs, and tablet PCs. Figure 5 shows an example where a smartphone is used as the hardware for the customer terminal 40.

As shown in Figure 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.

The touch panel display 41 is a device (a device that performs user interface functions) that outputs information to the customer holding the customer terminal 40 and accepts input from the customer (for example, input using a GUI screen). While the first embodiment shows an example of constructing the customer terminal 40 using a smartphone, the type of device that performs the user interface (means for input from the customer and means for output to the customer) in the customer terminal 40 is not limited.

Various web browsers can be applied as the web browser 43. The web browser 43 on the customer terminal 40 can access the web application server 10 to receive and execute customer-specific web application programs. Alternatively, the customer terminal 40 may be configured to install customer-specific application programs as dedicated applications rather than web-based applications.

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 perform image capture (for example, capturing a prescription or a QR code) in response to customer operations, and output the captured image data.

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

Next, we will explain the internal configuration of the medical billing computer 70.

Figure 6 is an explanatory diagram showing an example of the internal configuration of the medical billing computer 70.

The medical billing computer 70 can be constructed using various terminal devices (computers; hardware), such as a PC. Figure 6 shows an example where a PC is used as the hardware for the medical billing computer 70.

As shown in Figure 6, the claims processing computer 70 functionally comprises a touch panel display 41, a touch panel display 71, and a claims processing program 72.

The touch panel display 71 is a device (a device that performs user interface functions) that outputs information to customers who possess the medical billing computer 70 and accepts input from customers (for example, input using a GUI screen). The type of device that performs the user interface (means of input from customers and means of output to customers) in the medical billing computer 70 is not limited.

In a dispensing pharmacy, a "receipt" refers to a detailed dispensing statement submitted to the health insurance association for medical fees related to dispensing medication to a patient (insurance-covered medical treatment). The receipt processing program 72 is software that creates the detailed dispensing statement based on prescription information, etc. The receipt processing program 72 may be a commercially available package software, and its specific configuration is not limited.

The upload processing unit 73 receives prescription data (hereinafter referred to as "prescription data") output from the claims processing program 72 and supplies that 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 for each prescription in the data recording unit 22 (prescription database 2206).

Typically, prescription processing software packages include a function to output the entered prescription information as text data (e.g., data in CSV format) to a designated folder (hereinafter referred to as the "prescription data output function"). In this embodiment, the upload processing unit 73 uses the prescription data output function of the claims processing program 72 to acquire prescription data and upload it to the Web application server 10 (prescription reservation processing unit 12).

Next, we will describe the overview of each module that makes up the Web application server 10.

The portal processing unit 11 is a module that provides portal functions, such as information and search services related to pharmacies, to the customer terminal 40. Here, the portal processing unit 11 provides at least a service to search for pharmacies where the customer can obtain prescriptions based on their existing prescriptions. The portal processing unit 11 presents the customer with a list of pharmacy candidates based on their actions (e.g., keywords or current location). In doing so, the portal processing unit 11 provides not only the pharmacy's name and contact information, but also a link button to access the pharmacy's account on the message service system 50 (hereinafter referred to as the "message account" or "MS account").

The prescription reservation processing unit 12 is a module that processes prescription-based dispensing reservations (hereinafter referred to as "prescription reservations") from customers (customer terminals 40). While the prescription reservation processing unit 12 may provide a web screen (GUI screen) that accepts prescription reservations via a web connection from the customer terminal 40, here it is assumed that the prescription reservation processing unit 12 can also process prescription reservations through a user interface via the message service system 50.

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

The message processing unit 15 is responsible for the interface function with the message service system 50. The message processing unit 15 performs message sending and receiving with the customer's MS account ID using each pharmacy's MS account ID. The message processing unit 15 may also be configured using an API (Application Programming Interface) function for message exchange and other functions connected to the message service system 50.

The dialogue processing unit 14 performs dialogue processing (hereinafter referred to as "dialogue processing") 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 the prescription drugs dispensed (prescribed) to the customer based on the prescription.

Furthermore, for example, the dialogue processing unit 14 may be configured to send and receive arbitrary messages with the customer (customer terminal 40) in response to the pharmacist's actions (control from the pharmacy terminal 30).

The dialogue processing unit 14 performs dialogue processing with the customer (customer terminal 40) according to data defining the configured dialogue scenario (a scenario for dialogue with the customer) (hereinafter referred to as "dialogue scenario data").

Figure 7 shows an overview of the structure of the dialogue scenario data.

The dialogue scenario data in this embodiment includes data defining the mainstream message to be sent to the customer in the dialogue scenario (hereinafter referred to as "message data"), and data defining the process of requesting and receiving input from the customer corresponding to the mainstream message (message data) (for example, selection of options or response to the message) (hereinafter referred to as "input request data").

The dialogue scenario data shown in Figure 7 consists of seven message data (MD001-MD007) and six input request data (OD001-OD006). In Figure 7, the connection relationships (logical links) between each data are illustrated by lines between the symbols of each data.

The dialogue scenario data should include the order (transmission order) of each message data and the message data to which each input request data is linked.

The method for defining the order of each message data in the dialogue scenario data is not limited. For example, the dialogue scenario data may include a column for assigning a sequence number to each message data, or it may be structured as a list in which each message data is linked in the order indicated. In Figure 7, the message data MD001 to MD007 are linked (for example, by various linking methods such as pointers or arrays). For example, in Figure 7, message data MD002 is linked after message data MD001, message data MD003 is linked after message data MD002, and so on, until message data MD007 is linked after message data MD006. Therefore, the dialogue scenario data shown in Figure 7 indicates that the message transmission process is performed in the order of message data MD001 to MD007.

Furthermore, dialogue scenario data contains links to one or more input request data.

Here, each message data entry is assumed to contain a "message body" that describes the message to be sent to the customer, and data indicating the timing of the message body's transmission.

Each input request data set includes data for the following fields: "Notation Option," which describes the notation of the option (e.g., "Yes," "No," etc.); "Behavior," which describes the action taken when that option is selected (e.g., "Proceed to the next process without doing anything" or "Reply a predetermined message"); and "Reply Text," which describes the text to be sent when that option is selected. In this embodiment, only "Yes" or "No" can be entered as the notation option. While the format and number of notations for the notation options are not limited, in this embodiment, the following explanation assumes only "Yes" and "No."

Here, the behavior field in the input request data can be set to either a value indicating that if the option is selected, the system will proceed to the next process without taking any action (referred to here as "Do nothing," but this can also be expressed as a flag), or a value indicating that if the option is selected, the text set in the "Reply Text" field will be sent back (referred to here as "Reply Text," but this can also be expressed as a flag). Note that if the behavior in the input request data is "Do nothing," the "Reply Text" field may be left blank (for example, "NULL").

For example, since message data MD001 does not have any linked input request data, 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 the process will proceed to the next message data MD002.

Furthermore, since message data MD002 is linked to two input request data OD001 and OD002, it indicates that at the set timing, the text set in the message body (Thank you for your continued patronage. Please tell us about your medication status.) will be sent, and at the same time, the customer will be presented with either the notation option set in the first input request data OD001 (none) or the notation option set in the second input request data OD002 (yes), and the selection input (either "yes" or "no") will be accepted (for example, via selection input on the LINE application). After executing the "behavior" according to the selected option, the process will proceed to the next message data MD003.

For example, the first input request data OD001 has the notation option "None," the behavior "Do nothing," and the reply text "Blank." Therefore, if the option "None" is selected, the system proceeds to the next message data MD004 without taking any action. Also, the first input request data OD001 has the notation option "Yes," the behavior "Reply with text," and the reply text "What symptoms are you experiencing, and since when?". Therefore, if the option "Yes" is selected, the system sends the reply text "What symptoms are you experiencing, and since when?" to the customer, receives text input (reply) from the customer, retains the input (reply) text as the customer's response, and then proceeds to the next message data MD004.

In this embodiment, it is assumed that two input request data can be linked to one message data. In other words, in this embodiment, the dialogue scenario data consists of only two types: message data that is not linked to input request data (message data that is sent unilaterally without requesting a response; hereinafter referred to as "message data without questions") and message data to which two input request data are linked (message data with two options set; hereinafter referred to as "message data with questions").

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

The information used to determine the delivery timing includes information (hereinafter referred to as "delivery date attribute") for specifying the days within the medication period prescribed by the user (e.g., the first day, last day, and intermediate days of the medication period). Here, the delivery date attribute is assumed to be set to either "first day" (indicating the first day of the medication period), "last day" (indicating the last day of the medication period), or "intermediate day" (indicating the day between the first and last days). For example, if only one intermediate day is set within the medication period, the dialogue processing unit 14 may set the intermediate day to be exactly halfway between the first and last days (for example, if the medication period is 15 days, it may be set to the 8th day, which is the halfway point). Alternatively, if multiple intermediate days are set within the medication period, the dialogue processing unit 14 may set them so that each intermediate day is equally spaced between the first and last days.

As shown in Figure 7, in the dialogue scenario data, each message data is assigned a delivery date attribute, as well as the order of the intermediate dates set for that message data (hereinafter referred to as the "intermediate date order"). For example, a dialogue scenario data with only one intermediate date may be assigned only the intermediate date order 1, while a dialogue scenario data with two intermediate dates may be assigned either 1 or 2 as the intermediate date order.

In the dialogue scenario data, the first or more message data at the beginning will have the first day set as the delivery date attribute, the last or more message data at the end will have the last day set as the delivery date attribute, and the remaining message data (message data between the first and last days) will have an intermediate day set as the delivery date attribute.

In this embodiment, the dialogue scenario data is described as having only message data without questions set on the first and last days, and message data with questions set only on intermediate days. It is desirable to limit the number of message data with questions sent to the customer on the same day to a predetermined number (as this would be burdensome for the customer). Therefore, in this embodiment, the number of message data with questions set on a single intermediate day in the dialogue scenario data is limited to three or fewer.

For example, in the dialogue scenario data shown in Figure 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 final day, and the delivery date attributes of the message data MD002 to MD006 are set to intermediate days. In the dialogue scenario data shown in Figure 7, there is only one intermediate day, so the intermediate day order of message data MD002 to MD006 is set to 1.

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

As described above, in the dialogue scenario data, by fixing the structure of the question-containing message data (for example, limiting the number of links in the input request data to two), the scenario structure is simplified into a waterflow type rather than a tree structure (a structure with multiple branches). This facilitates registration (for example, registration by a pharmacist at a store) while ensuring the dialogue content is easy for the customer to understand. Since the format of questions asked to the customer (patient) regarding medication can generally be standardized, adopting a fixed format as described above, rather than a complex tree structure, makes registration easier and the format more user-friendly for the customer (patient).

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

In this embodiment, the date-based template database 2209 records templates (dialogue scenario data) corresponding to the duration of medication use based on the prescription (hereinafter referred to as the "target period"). For example, the date-based template database 2209 may store templates corresponding to patterns such as when the duration of medication use based on the prescription is 5 days or less, between 6 and 45 days, between 46 and 90 days, etc. Furthermore, the date-based template database 2209 may also store templates corresponding to prescriptions without a set duration of use (for example, prescriptions containing only as-needed medication or topical medications) (for example, a template with a duration of use of 0 days).

Furthermore, in this embodiment, the drug-specific template database 2210 records templates (dialogue scenario data) corresponding to drugs (prescription drugs). In this embodiment, the drug-specific template database 2210 is described as containing templates only for some of the drugs registered in the drug database 2208. Specifically, in this embodiment, the drug database 2208 contains templates that include messages and questions suitable for drugs that meet predetermined conditions (hereinafter referred to as "template-registered drugs"). In this example, templates are registered in the drug-specific template database 2210 only for so-called high-risk drugs (drugs with a relatively high risk of side effects, etc., when taken). In other words, in this embodiment, the drug database 2208 contains dialogue scenario data only for template-registered drugs.

Here, the dialogue processing unit 14 may determine the actual content of the conversation with the customer (the content of the messages sent and received) by combining the duration of medication prescribed (for example, the duration of medication with the longest duration among the medications included in the prescription) and templates corresponding to the medications included in the prescription. The dialogue processing unit 14 will be described as prioritizing the delivery of questions from the template of the medication (message data with questions set for the intermediate day) when the prescription includes a medication for which a template is registered (a medication for which a template is registered in the medication-specific template database 2210). In other words, in this embodiment, the dialogue processing unit 14 may select and apply either a medication-specific template or a date-specific template for each intermediate day.

Details of the internal structure of the date-based template database 2209 and the drug-based template database 2210 will be described later.

Next, we will explain the overview of the report processing unit 16.

The report processing unit 16 creates a report on medication (medication based on the prescription and dispensing content) that reflects the content of the dialogue processing performed by the dialogue processing unit 14.

The content of the report generated by the report processing unit 16 is not limited, but in this embodiment, it may be configured to generate and output a report in the format of a so-called "tracing report" (medication information sheet) (for example, output as printable data).

A tracing report (medication information sheet) is a report that a pharmacist at a pharmacy (community pharmacy) has gathered from a patient to convey information that the pharmacist believes should be provided to the physician, such as information on side effects and adherence (the patient's active participation in treatment decision-making and following those decisions).

In other words, the dialogue scenario data processed by the dialogue processing unit 14 consists of information related to this tracing report (for example, information on side effects and adherence) that is gathered from the customer (patient).

Next, we will describe examples of the configurations of each database that constitutes the data recording unit 22. For simplicity, the databases constituting the data recording unit 22 are shown in table format below; however, various database data structures can actually be used.

Figure 8 is an explanatory diagram showing an example of the structure of the pharmacy database 2201.

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

In the pharmacy database 2201 shown in Figure 8, information including "pharmacy ID," "pharmacy name," "address," and "telephone number" is registered for each pharmacy to identify and manage the pharmacy.

Figure 9 is an explanatory diagram showing an example configuration of the customer database 2202.

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

In the customer database 2202 shown in Figure 9, information including "Customer ID," "Name," "Date of Birth," "Gender," and "Telephone Number" is registered for each customer to identify and manage them.

Figure 10 is an explanatory diagram showing an example configuration of the MS Customer Management Database 2203.

The MS Customer Management Database 2203 is a database for managing the MS Account ID of each customer (user).

In the MS Customer Management Database 2203 shown in Figure 10, information including "Customer ID" and "MS Account ID" is registered for each customer.

Figure 11 is an explanatory diagram showing an example of the configuration of the MS pharmacy management database 2204.

The MS Pharmacy Management Database 2204 is a database for managing the MS account IDs of each pharmacy.

In the MS pharmacy management database 2204 shown in Figure 11, information including the "Pharmacy ID" and "MS Account ID" is registered for each pharmacy.

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

Drug Database 2208 is a database for managing medications (pharmaceuticals) dispensed according to prescriptions.

In the drug database 2208 shown in Figure 12, information is registered for each drug, including items such as a "drug ID" for identifying the drug, a "drug name," and a "drug code" for managing the drug's code number (e.g., the drug price standard listed drug code number).

Figure 13 is an explanatory diagram showing an example of the configuration of the prescription reservation database 2205.

The prescription reservation database 2205 is a database for managing prescription reservations received from customers through the processing of the prescription reservation processing unit 12.

In the prescription reservation database 2205 shown in Figure 13, each prescription reservation registers the following information: a "prescription reservation ID" to identify the reservation, a "pharmacy ID" to which the reservation is addressed, the "name" of the customer who made the reservation, the "date of birth" of the customer who made the reservation, the "reservation time" when the reservation was received, "generic" (1: generics desired, 0: generics not desired) indicating whether the customer wishes to be prescribed generic drugs for the reservation, and "prescription image data" showing the image of the prescription for that reservation (hereinafter referred to as "prescription image").

The prescription data fields may include either the prescription image data itself or link information to access the prescription image data file. Furthermore, while the first embodiment directly manages prescription image data in the prescription reservation database 2205, the specific database (table) structure is not limited, and management may be carried out using multiple databases (tables).

Figure 14 is an explanatory diagram showing an example of the configuration of the prescription database 2206.

The prescription database 2206 is a database for managing records of prescriptions issued based on prescriptions processed by the over-the-counter service processing unit 13.

In the prescription database 2206 shown in Figure 14, each prescription is registered with information including a "prescription ID" to identify the prescription, a "pharmacy ID" of the pharmacy that dispensed the medication based on that prescription, a "customer ID" of the recipient of the medication, and information such as the "dispensing date," "medication start date," "medication end date," "medication institution name," "prescribing physician," and "attending pharmacist."

Figure 15 is an explanatory diagram showing an example of the structure of the prescription drug database 2207.

The prescription drug database 2207 is a database for managing each prescription drug prescribed under each prescription managed in the prescription drug database 2206. For example, if any prescription managed in the prescription drug database 2206 prescribes two drugs, the prescription drug database 2207 will register the data for those two drugs (two separate records) separately.

In the prescription drug database 2207 shown in Figure 15, each prescription drug has the following fields: "Prescription Drug ID" to identify the prescription drug, "Prescription ID" to identify the prescription corresponding to the prescription drug, "Drug Code", "Drug Name", "Daily Dose" indicating the daily prescribed amount of the prescription drug, "Dispensing Amount" indicating the prescribed amount (total prescribed amount) of the prescription drug, "Dosage Interval" indicating the interval between doses of the prescription drug (in hours), "Dosage Interval Text" indicating the dosage interval of the prescription drug in text format (e.g., strings such as "After breakfast", "After breakfast, after dinner"), and the day on which the prescription drug should be started. The system registers information including the following items: "Start Date of Medication," "Mid-Term Medication Days" (indicating the midpoint of the entire period of medication use), "End Date of Medication" (indicating the final day of medication use), "Notification at Start of Medication" (indicating whether or not the customer will be notified via the message service system 50 at the start date of medication use), "Notification during Medication" (indicating whether or not the customer will be notified via the message service system 50 at the mid-term medication use), and "Notification at End of Medication" (indicating whether or not the customer will be notified via the message service system 50 at the final day of medication use).

Figures 16 and 17 show an example configuration of the date-based template database 2209.

Figure 16 shows an example of the configuration of the database (hereinafter referred to as the "date-specific template database") that manages the message data constituting the dialogue scenario data (templates) of the date-specific template database 2209.

In Figure 16, one line represents one message data entry. In Figure 16, each message data entry includes the following fields: "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."

In Figure 16, the "Template ID" indicates the identifier that identifies the message data. Furthermore, in Figure 16, the "Root ID" indicates the identifier (Template ID) of the root (first) message data in the dialogue scenario data to which the message data belongs. Additionally, in Figure 16, the "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). Finally, in Figure 16, the "Body Text" indicates the text of the message sent to the customer.

Furthermore, in Figure 16, the "Delivery Format" column indicates whether the message data is a "message data with a question" or a "message data without a question." Here, if the delivery format is set to 1, it indicates a message data without a question, and if the delivery format is set to 2, it indicates a message data with a question. Additionally, in Figure 16, the "Lower Limit of Target Period" and "Upper Limit of Target Period" represent the lower and upper limits of the target period (the period of medication prescribed by the doctor) for the dialogue scenario data to which the message data belongs. For example, if the target period is 6 to 45 days, as shown in Figure 16, the lower limit of the target period is set to 6 and the upper limit of the target period is set to 45.

Figure 17 shows an example of the configuration of the database (hereinafter referred to as the "date-specific choice database") that manages the input request data that constitutes the dialogue scenario data (templates) of the date-specific template database 2209.

In Figure 17, each line represents one input request data. In Figure 17, each input request data includes data for items such as "Option ID," "Link ID," "Responsive Option," "Behavior," and "Reply Text."

In Figure 17, "Option ID" indicates an identifier that identifies the input request data. Also in Figure 17, "Link Destination ID" indicates the identifier (template ID) of the message data to which the input request data is linked.

As shown in Figure 16, in the date-based template database, a list structure is established where message data is sequentially linked by root ID and parent ID. Note that the means of creating a list structure for multiple message data in the date-based template database are not limited; various data structures such as array structures may be applied.

Furthermore, the message data with template IDs TD001 to TD007 shown in Figure 16 represents an example of the dialogue scenario data configuration shown in Figure 7 (dialogue scenario data composed of message data MD001 to MD007). Similarly, the input request data with option IDs OD001 to OD006 shown in Figure 17 represents an example of the dialogue scenario data configuration shown in Figure 7 (an example of the input request data OD001 to OD006).

Figures 18 and 19 show an example of the configuration of the drug-specific template database 2210.

Figure 18 shows an example of the configuration of the database that manages the message data constituting the dialogue scenario data (templates) of the drug-specific template database 2210 (hereinafter referred to as the "drug-specific template database"). Figure 19 shows an example of the configuration of the database that manages the input request data constituting the dialogue scenario data (templates) of the drug-specific template database 2210 (hereinafter referred to as the "drug-specific choice database").

The structure of the drug-specific template database is basically the same as the date-based template database shown in Figure 16, but differs in that the target period (lower limit and upper limit of the target period) is replaced with the "drug code," which is the drug identifier. Note that in the drug-specific template database, the drug code may be replaced with another identifier (e.g., drug ID). Furthermore, the structure of the drug-specific choice database is basically the same as the date-based choice database shown in Figure 17.

Figure 20 shows an example configuration of the distribution management database 2211.

The distribution management database 2211 is a database used to manage the message distribution (dialogue processing) performed by the dialogue processing unit 14 based on message data (managing message distribution reservations, history, etc.).

In the distribution management database 2211 shown in Figure 20, each line represents data that manages the distribution of one message data (hereinafter referred to as "distribution management data").

In the distribution management database 2211, each distribution management data entry consists of items including: a "distribution ID" as an identifier to identify the distribution management data; a "prescription ID" indicating the corresponding prescription; a "template ID" indicating the corresponding message data; a "distribution date" indicating the date on which the corresponding message data is processed; a "distribution destination" indicating the recipient (e.g., the LINE ID of the recipient customer); a "distribution format" indicating the distribution format (whether or not there is a question); and a "status" indicating the status, such as whether it has been delivered or not.

In Figure 20, the "Status" column will show "1" if the message has been delivered and "0" if it has not been delivered.

The dialogue processing unit 14 selects the appropriate dialogue scenario data for each prescription (prescription ID) and sets the distribution management data in the distribution management database 2211 to perform dialogue processing according to the selected dialogue scenario data. Then, for each distribution management data registered in the distribution management database 2211, the dialogue processing unit 14 sends the message data (text body) corresponding to the template ID and the input request based on the linked input request data (for example, a request to select options or a request for text input) to the recipient ID at the set distribution timing (the date set as the distribution date).

In this embodiment, the template ID system is changed between the date-based template database 2209 and the drug-based template database 2210 to identify the linked database (either the date-based template database 2209 or the drug-based template database 2212) in the distribution 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-based template database 2209 starts with "TD" and the option ID starts with "OD". Also, for example, in this embodiment, the template ID in the drug-based template database 2210 starts with "TM" and the option ID starts with "OM".

Figure 21 shows an example of the configuration of the response management database 2212.

The response management database 2212 is a database that manages the content of input (responses to the question message data) received from the customer (customer terminal 40) after the dialogue processing unit 14 has sent an input request (e.g., a request to select an option or a request for text input) based on input request data linked to the question message data.

In the response management database 2212 shown in Figure 21, each row manages the response to a single question-containing message data (hereinafter referred to as "response management data").

In the response management database 2212, each response management data item consists of fields including: "Response ID" as an identifier to identify the response management data; "Distribution ID" indicating the corresponding distribution management data; "Template ID" indicating the corresponding message data; "Option ID" indicating the input request data corresponding to the selected option for the question-containing message data; and "Response Text" indicating the text (text entered by the customer) if there was a reply text (a response to the behavior of text replies) in the input request data corresponding to the selected option.

In other words, the dialogue processing unit 14 records, for each question-containing message data, the option ID indicating the selected option (input request data) in response to the question, and the "response text" indicating the text entered by the customer in response to the question in the question-containing message data, as response management data.

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

This section describes an example of how the Web application server 10 of the pharmacy support system 1 operates according to the scenario shown in Figure 14.

First, let's explain the outline of the scenario in Figure 14.

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

Next, the customer visits the pharmacy (AAA Pharmacy), and the prescription is dispensed to the customer based on the reserved prescription (delivery of the prescribed medication based on the prescription). The customer information is then registered by the functions of the in-store service processing unit 13 (S102).

Next, it is assumed that the message service system 50 performs a process to associate the customer's MS account ID with the AAA Pharmacy's MS account ID (for example, adding them as friends on the LINE service) (S103). This enables the sending of messages from the AAA Pharmacy's MS account ID to the customer's MS account ID (for example, sending and receiving messages during dialogue processing). Note that the processing in steps S101 to S103 can be the same as that described in Patent Document 1, so a detailed explanation is omitted here.

Furthermore, at the pharmacy (AAA Pharmacy), when dispensing medication, the contents of the prescription are entered into the claims computer 70 (claim processing program 72), and data capable of outputting a dispensing fee statement or dispensing fee statement is stored. Then, the claims computer 70, via the upload processing unit 73, stores the prescription data, uploads it to the Web application server 10 (prescription reservation processing unit 12), and the contents of the prescription are registered in the prescription database 2206 and the prescription drug database 2207 (S104).

The prescription reservation processing unit 12 recognizes the source of the prescription data, thereby recognizing which pharmacy the prescription originated from. Furthermore, based on the content of the prescription data, it can grasp customer (patient) information (e.g., name, date of birth, etc.), allowing it to recognize which customer ID the prescription belongs to. The prescription reservation processing unit 12 then registers the prescription information recognized by the upload into the prescription database 2206 and the prescription drug database 2207. In this embodiment, as described above, by registering the prescription content on the Web application server 10 (prescription reservation processing unit 12) side based on the content entered into the claims computer 70 (claims processing program 72), the need for pharmacies to enter the prescription content twice is eliminated. Furthermore, the method for inputting prescription details into the prescription database 2206 and prescription drug database 2207 in the Web application server 10 (prescription reservation processing unit 12) is not limited to the method described above. Various methods can be applied (for example, a method in which pharmacists at pharmacies directly input the prescription details, or a method in which the details are input based on recorded data such as barcodes attached to the prescription).

Subsequently, the dialogue processing unit 14 selects dialogue scenario data to be applied according to the prescription newly registered in step S103, and sets the distribution management data in the distribution management database 2211 so that dialogue processing is performed according to the selected dialogue scenario data (S105).

The dialogue processing unit 14 then performs the following processing for each distribution management data registered in the distribution management database 2211: at the set distribution timing (the date set as the distribution date), it sends message data (text body) corresponding to the template ID and input requests based on linked input request data (for example, a request to select options or a request for text input) to the recipient ID. The content entered by the customer is then registered in the response management database 2212 (S106).

Subsequently, in response to the operation of the pharmacy staff (pharmacist), the report processing unit 16 generates and outputs a tracing report corresponding to the prescription (the prescription registered in step S104) (S107).

The following sections provide specific examples for each step of the scenario described above.

First, regarding the operations in steps S101 to S103, since the same processing as described in Patent Document 1 may be applied, a detailed explanation will be omitted.

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

Next, a specific example of the process in step S104 described above will be explained.

[S104: Uploading and registering prescription data]
Here, we assume that, according to the prescription reservation for "Prescription Reservation ID: 1", dispensing is performed at AAA Pharmacy, and the contents of the prescription associated with that dispensing are entered into AAA Pharmacy's claims computer 70. Then, the claims computer 70 generates prescription data for that prescription using the claims processing program 72, and the upload processing unit 73 uploads it to the Web application server 10 (prescription reservation processing unit 12). 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.

This explanation assumes that data with prescription ID: 1 has been newly registered in prescription database 2206 (prescription drug database 2207). Furthermore, it is assumed that, at this time, data with prescription agreement IDs: 1 and 2 have been registered in prescription drug database 2207 as corresponding prescription agreements for prescription ID: 1.

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

The dialogue processing unit 14 then registers each message data of the selected dialogue scenario data in the distribution management database 2211. As a result, the distribution management database 2211 contains distribution data with distribution IDs 1 to 7 as shown in Figure 20.

[S106: Message sending and receiving and response recording processing according to the delivery reservation process]
Here, the dialogue processing unit 14 will perform distribution processing on the distribution data (distribution data with distribution IDs 1 to 7) as shown in Figure 20. The dialogue processing unit 14 will grasp the distribution data for each distribution destination and perform distribution processing for each distribution destination in order from the distribution data with the smallest distribution ID. In addition, if there is distribution data with distribution format 2, the dialogue processing unit 14 will wait for the input of the answer to the question before moving on to processing the next distribution data. Furthermore, for distribution data set to the same day at a single distribution destination, the dialogue processing unit 14 will perform distribution processing without any intervals except during the time between answer inputs. For example, in the example in Figure 20, the distribution dates for distribution data with distribution IDs 2 to 6 are set to the same day, so the processing of this distribution data may be done continuously except during the time between answer inputs. Furthermore, the dialogue processing unit 14 may set the time to start distribution processing within a day to a predetermined time (for example, 1 p.m., a time when customers are likely to answer). For example, the dialogue processing unit 14 may perform the distribution processing for distribution data with distribution ID 2 at a predetermined time (for example, 13:00) rather than at 0:00 on August 8, 2021.

Furthermore, when processing data with distribution format 2, the dialogue processing unit 14 records the customer's response as response data in the response management database 2212.

In Figure 20, the distribution data with distribution IDs 3 to 5 is set to distribution format 2, and the corresponding response data in Figure 21 is assumed to be the data with response IDs 1 to 3.

Figure 25 shows an example of the results of distribution (interaction processing with customer terminal 40) according to the distribution data corresponding to prescription ID: 1 (distribution data with distribution IDs 1 to 7 in Figure 20).

Figure 25 shows an example of the display screen of the message service AP 43 (the screen displayed on the touch panel display 41) shown on the customer terminal 40. In Figure 25, messages sent from the pharmacy side (Web application server 10 side) are displayed in a speech bubble from the left, while customer input (including selections) is displayed on the right. Furthermore, in Figure 25, the options based on the input request data ("Yes" or "No") are enclosed in a dotted line, and the content of the selected option ("Yes" or "No") is shown in a speech bubble from the right. In the example in Figure 25, "No" is selected for all options, so no reply text has been entered.

When the dialogue process shown in Figure 25 is performed, the contents of the response management database 2212 will be as shown in Figure 21 (response data with response IDs 1 to 3).

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

In this case, the report processing unit 16 first retrieves the contents of prescription ID: 1 from the prescription database 2206, and then retrieves customer (patient) information for that prescription from the customer database 2202, etc.

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 corresponding response data from the response management database 2212. The report processing unit 16 also obtains information about the pharmacy (insurance pharmacy) for which the tracing report is to be created (e.g., insurance pharmacy name, pharmacy address, telephone number, etc.) from the pharmacy database 2201, based on the user information (user corresponding to the pharmacy) logged in on the pharmacy terminal 30.

As a result, the report processing unit 16 can extract the response data with response IDs 1 to 3 in Figure 21.

Through the above processing, the report processing unit 16 collects the information necessary for creating the tracing report, displays the tracing report with the collected information entered, and displays an editable 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.

Figure 24 shows an example of the report editing screen configuration.

In the report editing screen shown in Figure 24, the header section (for example, 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.

In Figure 24, information that can be entered based on data from the prescription database 2206, customer database 2202, pharmacy database 2201, etc., is automatically entered.

Furthermore, the report processing unit 16 generates text data about the questions and answers in the dialogue process with the customer (patient) based on the acquired response data (response data with response IDs 1 to 3), and automatically inputs it into the report editing screen (the "Provided Information/Proposed Content" section).

In Figure 24, the text based on the response data is automatically entered (pasted) into field F101 (the "Information Provided/Proposed Content" item).

When displaying the report editing screen, the report processing unit 16 automatically inputs items that can be automatically entered based on the information collected as described above. After the automatic input process is complete, the report processing unit 16 allows all items to be freely edited on the report editing screen. Depending on the pharmacist's actions, the report processing unit 16 can output the tracing report displayed on the report editing screen in various ways (e.g., printing or outputting as a PDF).

This allows pharmacists to obtain tracing reports with the simple operations described above. All they need to do is submit these tracing reports to the medical institution, and the process related to the tracing reports will be complete.

[Example of a case where a prescription drug includes a drug that is registered in the template]
Next, we will describe an example where both date-based templates and drug-based templates are applied to the dialogue processing for a single prescription.

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

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

As described above, in this embodiment, if the prescription includes a drug that is registered in the template, the dialogue processing unit 14 will prioritize delivering questions from the template for that drug. For example, as shown in the distribution management database 2211 in Figure 20, the dialogue processing unit 14 may apply message data from the date-specific template (template with TD001 as the root ID) for the first and last days, and extract and apply data from the drug-specific template (template with TM001 as the root ID) for the intermediate days. In this case, the dialogue processing unit 14 may replace the message data for each intermediate day (each intermediate day in sequence) in the date-specific template with the message data for the corresponding intermediate day (each intermediate day in sequence) in the drug-specific template and make a distribution reservation (reflected in the distribution management database 2211). For example, the dialogue processing unit 14 may replace the message data with intermediate day sequence N in the date-specific template with message data with intermediate day sequence N in the drug-specific template (message data whose intermediate day sequence matches that of the date-specific template) and make a distribution reservation. Specifically, for example, as shown in Figure 20, the dialogue processing unit 14 may replace the message data for intermediate day order: 1 in the date-specific template (message data for TD002 to TD006) with the message data for intermediate day order: 1 in the drug-specific template (message data for TM002 to TM006) and then perform the delivery reservation. Furthermore, if a prescription contains multiple drug-registered drugs, the dialogue processing unit 14 may select one of the drug-registered drugs for each intermediate day (for example, by random selection or any other method) and reflect this in the delivery reservation.

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

In this case, the distribution data corresponding to prescription ID: 2 will be the distribution data with distribution IDs 8 to 14, as shown in Figure 20.

Figure 25 shows an example of the results of distribution (interaction processing with customer terminal 40) according to the distribution data corresponding to prescription ID: 2 (distribution data with distribution IDs 8 to 14 in Figure 20). Figure 25 is written in the same format as Figure 23.

Figure 26 shows an example of the 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 prescription ID: 2.

In Figure 26, field F101 is automatically populated with text data corresponding to the content of the response management database 2212 (response data for response IDs 4-6) shown in Figure 21. For example, the response data for response ID 4 has template ID TM003, option ID OM002, and response text: "I have blurred vision from the first day." Therefore, in field F101 shown in Figure 26, the text "Q. Do you have blurred vision? A. Yes. I have blurred vision from the first day" is automatically populated based on the content of the drug-specific template database 2210 (contents of Figures 19 and 20). Similarly, in field F101 shown in Figure 26, the text "Q. Do you feel sleepy? A. Yes. I have felt very sleepy from the first day" is automatically populated based on the response data for response ID 5, and the text "Q. Do you experience shortness of breath? A. Yes. I have experienced shortness of breath from the first day" is automatically populated based on the response data for response ID 6.

Figure 26 shows the state after the report processing unit 16 has performed automatic input (initial state). However, as described above, the report editing screen allows for further editing by the pharmacist.

Figure 27 shows an example of a report editing screen that has undergone further editing from its initial state.

On the report editing screen, the pharmacist added the following text to field F101 as information regarding the patient's side effects (information for the physician): "There is a possibility of side effects occurring; the patient was instructed to seek medical attention early and consult with a physician."

Furthermore, in the report editing screen shown in Figure 27, a checkbox CB101 related to side effects has been added. The report editing screen allows pharmacists to freely edit the automatically filled-in initial state, as shown in Figure 27.

As shown in Figures 26 and 27, the report editing screen may be configured to allow operation (on/off operation) of checkbox-type items (for example, the checkboxes for "Medication Status," "Information Provision Regarding Remaining Medication Adjustment," and "Side Effects" in the tracing report shown in Figure 27).

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

In the first embodiment of the pharmacy support system 1, dialogue processing can be performed based on date-specific templates (date-specific template database 2209) according to the medication period determined by the prescription content. This allows the pharmacy support system 1 of the embodiment to automatically perform dialogue processing based on dialogue scenario data corresponding to the length of the medication period, without requiring any operation from the pharmacist.

Furthermore, in the pharmacy support system 1 of the first embodiment, dialogue processing is performed by modifying the content of the date-specific template, taking into account drug-specific templates (drug-specific template database 2210) corresponding to the prescribed drug. As a result, in the pharmacy support system 1 of the first embodiment, when the prescribed drug includes a drug registered in the template, questions (question message data) can be asked of the customer (patient) according to the properties of the drug registered in the template. This allows patients to reduce risks, such as preventing health damage caused by side effects from the medications they take.

Furthermore, in the pharmacy support system 1 of the first embodiment, the contents of the tracing report are automatically entered based on the content of the dialogue processing. This reduces the workload for pharmacists in entering tracing reports.

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

(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. Furthermore, the web application server 10 and the database server 20 may be configured using even more subdivided computers. In other words, the number of computers constituting the pharmacy support system 1 is not limited.

(B-2) Although the pharmacy support system 1 in the above embodiment is configured as a web-based system, it may also be configured as a client-server system (a configuration implemented by installing a dedicated application on the pharmacy terminal 30 and the customer terminal 40). That is, 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.

(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 the pharmacist's operation. However, the pharmacist's operation to output tracing reports may be simplified (made more efficient) by outputting tracing reports for multiple prescriptions at once (for example, by printing from the printer 60 or generating a PDF file). In this case, the report processing unit 16 may automatically output tracing reports for prescriptions that meet predetermined conditions (hereinafter referred to as "automatically output eligible prescriptions") (outputting only content that can be automatically entered without editing by the pharmacist). For example, in the dialogue processing, prescriptions in which the "none" option is selected for all question message data (hereinafter referred to as "problem-free prescriptions") may be designated as automatically output eligible prescriptions, while prescriptions in which the "yes" option is selected for some or all question message data (hereinafter referred to as "problem prescriptions") may not be designated as automatically output eligible prescriptions.

For example, the report processing unit 16 can extract prescriptions without problems by referring to the data in the distribution management database 2211 and the response management database 2212 for each prescription (prescription ID). For instance, in the response management database 2212 shown in Figure 21, referring to the response data related to prescription ID: 1 reveals that the "none" option is selected for all message data with questions. Therefore, the report processing unit 16 can determine that prescription ID: 1 is a "prescription without problems." On the other hand, in the response management database 2212 shown in Figure 21, referring to the response data related to prescription ID: 2 reveals that message data with questions includes those where the "yes" option is selected. Therefore, the report processing unit 16 can determine that prescription ID: 2 is not a "prescription without problems" (it is a "prescription with problems").

(B-4) In the above embodiment, the process by which the dialogue processing unit 14 determines the content of the dialogue process to be performed with the customer (patient) using templates (dialogue scenario data) registered in the date-based template database 2209 and the drug-based template database 2210 was described. The dialogue processing unit 14 may also be configured to support editing functions for templates registered in the date-based template database 2209 and the drug-based template database 2210. For example, the dialogue processing unit 14 may present an operation screen for editing templates (hereinafter referred to as the "template editing screen") to the pharmacy terminal 30 and accept template editing (e.g., registration of a new template, modification of an existing template, etc.) in response to operations by a pharmacist or other user.

Figure 28 shows an example of the template editing screen configuration.

The template editing screen includes an input object OB101 for accepting message data without questions, and an input object OB102 for accepting message data with questions (including accompanying input request data).

The no-question message data input object OB101 contains a field F201 for receiving text input. One object OB101 can accept input for one no-question message.

On the other hand, the message data input object OB102, which contains a question, has a field F201 for receiving text input and two sub-objects SOB1 and SOB2 for receiving input request data.

The sub-objects SOB1 and SOB2 each contain a field F301 for receiving input for notation options, a field F302 for receiving input for behavior, and a field F303 for receiving input for reply text. Field F301 may be configured to accept input as a selection of "Yes" or "No." Field F302 may be configured to accept input as a selection of "Do nothing" or "Reply with text." Therefore, the question message data input object OB102 can accept input for one question message data and two associated input request data.

The template editing screen displays multiple objects (objects with questions/message data input objects with questions) side-by-side, and allows editing of each object. The template editing screen represents a single template (dialogue scenario data) composed of these multiple objects. In the template editing screen, the object at the top represents the message data with the root ID, and the objects for each message data are arranged downwards from the top.

As a result, the template editing screen visually displays the template (dialogue scenario data) composed of message data and input request data.

Furthermore, in the template editing screen shown in Figure 28, each object (a message data input object with a question/a message data input object with a question) has buttons B101 to accept the insertion of a new message data input object without a question, B102 to accept the insertion of a new message data input object with a question, and B103 to accept the deletion of the object. Additionally, in the template editing screen shown in Figure 28, buttons B201 to accept the addition of a new message data input object without a question and B202 to accept the addition of a new message data input object with a question are located at the bottom.

In the template editing screen shown in Figure 28, these buttons allow you to add or delete message data (messages with/without questions) at any point in the template.

(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 of the pharmacy support system 1 (in the example of Patent Document 1, a representative ID called "YS_MS").

1...Pharmacy support system, 10...Web application server, 11...Portal processing unit, 12...Prescription reservation processing unit, 13...In-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...Claim 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-based template database, 2210...Drug-based template database, 2211...Distribution management database, 2212...Response management database.

Claims (2)

An account management means for managing a pharmacy account used in a messaging service for pharmacies, and customer accounts used in the messaging service for customers of the pharmacy,
A prescription management means for managing the contents of prescriptions dispensed to the aforementioned customer,
For each of the aforementioned prescriptions, a message processing means sends a message from the pharmacy account to the customer account via the messaging service according to a scenario corresponding to the content of the prescription, at a timing corresponding to the content of the prescription, and receives the response content sent from the customer account to the pharmacy account via the messaging service.
The message processing means manages the content of the response received,
A pharmacy terminal processing means that supplies the message processed by the message processing means to a pharmacy terminal located in the pharmacy,
The system includes a scenario data holding means that holds multiple scenario data defining the content of messages transmitted 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 according to the held scenario data.
The system further includes a report generation and output means that generates one or more medication information reports describing some or all of the content transmitted and received by the message processing means, and performs a batch output processing to output the generated reports in a batch.
The scenario data includes one or more scenarios in which a question message is sent to the customer account asking whether there are any problems with taking the medication described in the prescription, and a response to the question message is received.
The report generation output means includes in the report the answers to one or more of the problem presence/absence question messages, and excludes reports in which one or more of the answers to the problem presence/absence question messages indicate a problem from the batch output processing.
A pharmacy support system characterized by the following features. In the pharmacy support methods implemented by the pharmacy support system,
The pharmacy support system comprises account management means, prescription management means, message processing means, response management means, pharmacy terminal processing means , scenario data storage means , and report generation output means .
The account management means manages pharmacy accounts used in the messaging service corresponding to the pharmacy and customer accounts used in the messaging service corresponding to the pharmacy's customers.
The prescription management means manages the contents of the prescriptions dispensed to the customer,
The message processing means, for each prescription, sends 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, at a timing corresponding to the content of the prescription, and receives the response content sent 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 the pharmacy terminal located in the pharmacy.
The scenario data holding means holds a plurality of scenario data that define the content 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 according to the held scenario data .
The report generation output means generates one or more medication information reports that describe part or all of the content sent and received by the message processing means, and performs a batch output process to output the generated reports all at once.
The scenario data includes one or more scenarios in which a question message is sent to the customer account asking whether there are any problems with taking the medication described in the prescription, and a response to the question message is received.
The report generation output means includes in the report the answers to one or more of the problem presence/absence question messages, and excludes reports in which one or more of the answers to the problem presence/absence question messages indicate a problem from the batch output processing.
A pharmacy support method characterized by the following features.