JP7536838B2 - Distribution management server, distribution management method, and computer program - Google Patents

Description

The present invention relates to a distribution management server used in a distribution management system. In particular, the present invention relates to a distribution management server and a distribution management method that can quickly determine whether a pharmaceutical product can be delivered. Furthermore, the present invention relates to a computer program related to the distribution management server.

Distribution management work : Some pharmaceuticals (prescription drugs) have distribution delivery conditions set for them. The task of managing whether or not these conditions are met is called distribution management work. This type of pharmaceutical distribution management work is extremely important because it is directly related to the health of the nation.
An explanatory diagram of a conventional distribution management operation is shown in Figure 15. As shown in this figure, first, an authorized dealer 10 that receives an order for pharmaceuticals from a hospital or pharmacy and delivers the pharmaceuticals in response to the order sends a delivery notification 12 to a distribution manager 14. The distribution manager 14 then checks whether the conditions for delivery are met and sends a response to the authorized dealer 10 indicating whether delivery is possible or not. The authorized dealer 10 then receives this response, and if the response indicates that delivery is possible, delivers the pharmaceuticals to the hospital or pharmacy.

The following are examples of criteria for determining whether or not a product can be delivered (distribution restrictions):
- Is appropriate information being provided to hospitals and pharmacies?
-Have you attended the designated seminars?
・Is he a specialist?
-Do you have all the necessary documents?
The distribution manager 14 is a person who judges whether or not delivery is possible on behalf of the pharmaceutical company and manages the appropriate distribution of pharmaceuticals. This distribution manager 14 may be a business entity (and its staff) that performs distribution management work. The authorized dealer 10 is a person who delivers pharmaceuticals to hospitals and pharmacies, and may be a so-called pharmaceutical wholesaler. The delivery notification 12 described above may be transmitted, for example, by facsimile (hereinafter referred to as FAX), and the above-mentioned reply may also be transmitted by FAX.
As mentioned above, the distribution management task is to manage whether the distribution conditions have been met, and when the result of the delivery feasibility determination is that the item is deliverable, this is called "unlocking."

The problems with such conventional distribution management operations are shown in Fig. 16. As shown in Fig. 16 (and Fig. 15), the distribution manager 14 receives the delivery notification 12 and the like by FAX. Therefore, the information must be further digitized and entered into a computer, which tends to result in excessive labor costs and workload.
16, the dealer 10 has conventionally confirmed with the distribution manager 14 via FAX whether it is OK to deliver to the hospital/pharmacy 16. Therefore, during busy periods, it may take some time for a reply to be received from the distribution manager 14. As a result, it may be impossible to make urgent deliveries, and it may take some time for the medicines to be delivered to the hospital/pharmacy 16.

FIG. 17 shows a detailed process flow of a conventional distribution management operation.
First, in the white circle 1 in FIG. 17, a hospital/pharmacy 16 places an order for medicines with an authorized dealer 10 .
In the white circle 2, the authorized dealer 10 transmits the delivery notification 12 to the distribution manager 14 by FAX.
At the open circle 3, the distribution manager 14 sends a notification of the delivery possibility (possible) to the authorized dealer 10 by FAX. Upon receiving this notification, the authorized dealer 10 makes the delivery at the open circle 5.
In addition, in the white circle 4, the distribution manager 14 notifies the MRs (Medical Representatives) 18 that the product is ready for delivery.

On the other hand, if the delivery is not possible, the distribution manager 14 sends a notification of the delivery possibility judgment (not possible) to the authorized dealer 10 by FAX in the above-mentioned white circle 3. The authorized dealer 10 who receives this notification cannot make the delivery at that time. In this case, in the black circle 1, the distribution manager 14 sends a request to MR 18 to hear the delivery possibility judgment criteria information .
In black circle 2, the MR 18 who received the request inquires about the delivery possibility judgment criteria information from the hospital/pharmacy 16. Then, in black circle 3, the MR 18 transmits the information obtained from the hospital/pharmacy 16 (delivery possibility judgment criteria information ) to the distribution manager 14.
In the black circle 4, the distribution manager 14 makes a decision based on the new information obtained from the MR 18, and sends a new delivery feasibility decision (delivery impossible → delivery possible) to the authorized dealer 10 by FAX.
The special agent 10 who receives this notification delivers the goods at black circle 5. Conventional distribution management operations are carried out in this manner.

Prior Patent Literature There are many aspects to pharmaceutical distribution management, and various improved distribution methods have been proposed for various purposes. The following inventions are not directly related to the present invention, but represent the general background art in the field.
The following Patent Document 1 discloses an invention related to pharmaceutical distribution management, similar to the present invention. According to the invention described in Patent Document 1, it is possible to prevent counterfeit pharmaceuticals by issuing an authentication code using special ink.

The following Patent Document 2 also discloses a monitoring system for monitoring drug distribution. According to the invention described in Patent Document 2, pharmacies can dispense medicine only when the management system issues a permission code.

Special Publication No. 2015-508519 JP 2015-27477 A

As described above, conventional distribution management operations tend to require huge amounts of labor and work. In addition, there were cases where the decision on whether or not a drug could be delivered was delayed, and delivery to the hospital or pharmacy 16 took a long time.
The present invention has been made in consideration of the above problems, and its object is to provide a system that can reduce the workload in distribution management operations and more quickly determine whether or not a pharmaceutical can be delivered.

In order to solve this problem, the inventors of the present application conducted extensive research and came up with the idea of building a system in which delivery admissibility determination criteria information is registered in a distribution management server and delivery admissibility determination is automatically performed.

(1) In order to solve the above problems, the present invention provides a distribution management server for managing the distribution of pharmaceuticals, comprising: a communication unit for communicating with the outside; a delivery feasibility determination criteria information database for storing delivery feasibility determination criteria information; and a control unit for executing a delivery feasibility determination for a delivery notification sent from the outside based on the delivery feasibility determination criteria information stored in the delivery feasibility determination criteria information database and generating a determination result, wherein the communication unit transmits the determination result generated by the control unit to the outside.

(2) The present invention also relates to a distribution management server as described in (1), characterized in that the communication unit includes a web server that provides a web page for inputting information about the delivery notification, and the delivery notification transmitted from the outside includes a delivery notification with information input on the web page.

(3) The present invention also relates to a distribution management server as described in (1), wherein the communication unit includes a web server that provides a web page that displays the judgment result of the delivery notification, and the communication unit transmits the judgment result generated by the control unit to an external device by displaying the judgment result on the web page.

(4) The present invention also relates to a distribution management server as described in (1), characterized in that the control unit stores delivery feasibility determination criteria information transmitted from an external source in the delivery feasibility determination criteria information database and executes an update process to update the contents of the delivery feasibility determination criteria information database.

(5) The present invention also provides a distribution management server according to (4), which includes a delivery notification database that stores the delivery notification, and the control unit sets a flag to the delivery notification as the result of the judgment, either "OK" meaning that the delivery is possible, or "NO" meaning that the delivery is not possible, and stores the delivery notification with the set "OK" or "NO" flag in the delivery notification database, and the control unit, after executing the update process, performs a delivery possibility judgment again for the "NO" delivery notification that was judged as "NO" among the delivery notifications stored in the delivery notification database based on the delivery possibility judgment criteria information stored in the delivery possibility judgment criteria information database, and generates the judgment result, and the communication unit transmits the judgment result to the outside when the judgment result generated by the control unit is "OK".

(6) The present invention also provides a distribution management method for performing distribution management using the distribution management server described in (1), characterized in that the method includes a step in which the control unit executes a delivery feasibility determination for a delivery notification sent from an external source based on the delivery feasibility determination criteria information stored in the delivery feasibility determination criteria information database, and generates a determination result, and a step in which the communication unit transmits the determination result generated by the control unit to an external source.

(7) The present invention also relates to a distribution management method according to (6), characterized in that it includes an update step in which the control unit stores the delivery feasibility determination criteria information transmitted from the outside in the delivery feasibility determination criteria information database and executes an update process to update the contents of the delivery feasibility determination criteria information database.

(8) The present invention also relates to a distribution management method as described in (7), characterized in that the distribution management server includes a delivery notification database that stores the delivery notifications, and the control unit, after executing the update step, performs a delivery feasibility determination again for the "not possible" delivery notifications stored in the delivery notification database that have been determined to be "not possible" based on the delivery feasibility determination criteria information stored in the delivery feasibility determination criteria information database, and generates a determination result, and the communication unit transmits the determination result generated by the control unit to an external device.

(9) To solve the above problem, the present invention provides a computer program for causing a computer having a communication unit for communicating with the outside, a delivery feasibility determination criteria information database for storing delivery feasibility determination criteria information, and a control unit to operate as the distribution management server described in (1), characterized in that the computer is caused to execute a control procedure in which the control unit executes a delivery feasibility determination for a delivery notification sent from the outside based on the delivery feasibility determination criteria information stored in the delivery feasibility determination criteria information database and generates the determination result, and a procedure in which the communication unit transmits the determination result generated by the control procedure to the outside.

(10) The present invention also provides a computer program as described in (9), characterized in that the computer is caused to execute an update procedure for storing delivery feasibility determination criteria information transmitted from an external source in the delivery feasibility determination criteria information database and updating the contents of the delivery feasibility determination criteria information database.

(11) In order to solve the above problem, the present invention provides a computer program for causing a computer having a communication unit for communicating with the outside, a delivery feasibility determination criteria information database for storing delivery feasibility determination criteria information, a control unit, and a delivery notification database for storing delivery notifications to operate as the distribution management server described in (5), the computer being provided with a control procedure in which the control unit executes a delivery feasibility determination for a delivery notification transmitted from the outside based on the delivery feasibility determination criteria information stored in the delivery feasibility determination criteria information database and generates a determination result; and the control unit sets, as a flag in the delivery notification, a value of either "OK", meaning that the delivery is possible, or "NOT possible", meaning that the delivery is not possible, as the determination result, and sets the "OK" or "NOT possible" flag in the delivery notification after the setting. a step of storing a delivery notification in the delivery notification database when the delivery notification has been set with the above-mentioned criteria; an update step of storing delivery feasibility determination criteria information transmitted from an external source in the delivery feasibility determination criteria information database and updating the contents of the delivery feasibility determination criteria information database; a second control step of, after the control unit executes the update process, re-executing a delivery feasibility determination for a "not possible" delivery notification stored in the delivery notification database that has been determined to be "not possible" based on the delivery feasibility determination criteria information stored in the delivery feasibility determination criteria information database, and generating a determination result; and a step of, if the determination result generated in the second control step is "possible," transmitting the determination result to the outside.

As described above, according to the present invention, the determination of whether or not a drug can be delivered is automatically performed by the distribution management server, so that it is possible to more quickly determine whether or not a drug can be delivered.

FIG. 2 is a configuration diagram of a distribution management server 100 in the present embodiment. FIG. 2 is an explanatory diagram of a distribution management operation in this embodiment. FIG. 4 is an explanatory diagram of access authority in the present embodiment. 13 is a flowchart showing detailed operations of a distribution management task. 13 is a flowchart showing detailed operations of a distribution management task. 13 is a flowchart showing detailed operations of a distribution management task. 13 is a flowchart showing detailed operations of a distribution management task. 13 is a flowchart showing detailed operations of a distribution management task. 13 is a flowchart showing detailed operations of a distribution management task. 11 is a flowchart showing the detailed operations of a distribution management process, in particular, a flow chart showing the response to a "delivery OK" request. 11 is a flowchart showing the detailed operations of a distribution management operation, in particular, a flow chart showing how to handle a case where a delivery is "unavailable." 11 is a flowchart showing the detailed operations of a distribution management task, and in particular, a flowchart showing an unlocking operation. FIG. 13 is an explanatory diagram showing how unlock data (data file output) is output. FIG. 11 is an explanatory diagram illustrating the effect of the present embodiment. FIG. 1 is an explanatory diagram of a conventional pharmaceutical distribution management operation. FIG. 1 is an explanatory diagram showing a problem with the processing operation of a conventional distribution management business. FIG. 1 is an explanatory diagram of a processing operation of a conventional distribution management business.

The following describes the configuration of a distribution management system according to a preferred embodiment of the present invention, the distribution management server that constitutes it, and the processing operations of distribution management tasks using them, with reference to the accompanying drawings.

A. Distribution Management Server The distribution management system 90 according to this embodiment is configured around a distribution management server 100. A configuration diagram of this distribution management server 100 is shown in FIG.
As shown in this figure, the distribution management server 100 comprises a communications section 102, a control section 104, a delivery notification database 106, a delivery feasibility determination criteria information database 108, a variety of information databases 110, and a management master 112.
The communication unit 102 is a communication interface that controls communication with the outside, and may employ various communication standards. The communication unit 102 can communicate with various external devices via a predetermined communication path 120. For example, the communication unit 102 can communicate with a dealer terminal 130, a distribution manager terminal 140, and an MR terminal 150.

The communication unit 102 also includes a WEB server 102b, which provides a WEB page through which various information can be sent to the outside and various information can be input from the outside.
For example, it is also preferable to "send" the delivery note 12 to the distribution management server 100 by inputting information on the delivery note 12 on a WEB page provided by the WEB server 102b.
It is also preferable that the control unit 104 display "Delivery possible" on a web page provided by the web server 102b, thereby "sending" (informing) the delivery possibility result on the delivery notification 12 to an external party (e.g., the authorized dealer 10).

The control unit 104 may be composed of a so-called CPU and a computer program executed by the CPU. The control unit is realized by the CPU executing the computer program. This causes the operation of the distribution management server 100 to be executed. In other words, the distribution management server 100 is a computer, and the control unit 104 corresponds to the CPU and executes the operation of the distribution management server 100. In other words, the computer program is a program that defines the operation of the distribution management server. Furthermore, the computer program may be stored in a specified storage device, and the storage device may be located anywhere. This storage device may be the same storage device as the various databases described below, or may be a storage device separate from them. Furthermore, the computer program referred to here corresponds to a preferred example of a computer program in the claims.

The delivery notification database 106 is a database that stores the delivery notification 12. The delivery feasibility determination criteria information database 108 is a database that stores delivery feasibility determination criteria information. The various information 110 database is a database that stores various information described later. The management master 112 stores various master information, the details of which will be described later.
The delivery notification database 106, the delivery admissibility criteria information database 108, the various information database 110, and the management master 112 may be configured with a predetermined storage device, such as a hard disk or various semiconductor storage devices.
As shown in FIG. 1 , the communication unit 102, the control unit 104, the delivery notification database 106, the delivery feasibility determination criteria information database 108, the various information database 110, and the management master 112 are capable of transmitting and receiving data via a predetermined internal communication path 116.

The communication path 120 connects the distribution management server 100 , the dealer terminal 130 , and the MR terminal 150 .
The authorized dealer terminal 130 is a computer terminal equipped with a communication interface capable of communicating via the communication path 120. The authorized dealer 10 (or a person in charge at the authorized dealer 10) transmits the delivery notification 12 from the authorized dealer terminal 130 to the distribution management server 100.
The distribution management terminal 140 is a computer terminal equipped with a communication interface capable of communicating via the communication path 120. The distribution manager 14 accesses the distribution management server 100 via the distribution manager terminal 140.
The MR terminal 150 is a computer terminal equipped with a communication interface that enables communication via the communication path 120. The MR 18 accesses the distribution management server 100 via the MR terminal 150.

B. Distribution Management Operations An overview of the distribution management operations according to this embodiment is shown in Fig. 2. This figure corresponds to Fig. 17 showing the conventional distribution management operations. Below, the features of the distribution management operations of this embodiment will be explained using Fig. 2 and other figures.
Update of information in the distribution management server 100
First, in the white circle 1 in FIG. 2, the MR 18 inquires of the hospital/pharmacy 16 about the delivery possibility judgment criteria information .
Thereafter, in white circle 2, the MR 18 transmits the information (delivery possibility determination criteria information ) obtained from the hospital/pharmacy 16 to the distribution management server 100. The distribution management server 100 stores the received delivery possibility determination criteria information in the delivery possibility determination criteria information database 108.
In this embodiment, this "transmission" performed by MR 18 is performed by MR 18 inputting delivery possibility judgment criteria information on a website (web screen) provided by the distribution management server 100. This enables the distribution management server 100 to execute delivery possibility judgment based on the delivery possibility judgment criteria information .

There are two routes by which the delivery possibility determination criteria information reaches the distribution management server 100. That is, in Fig. 2, two white circles 2 are shown. The first route (first route) is a route that goes directly from the MR 18 to the distribution management server 100 as described above.
The second location (second route) is a route from MR 18 to the distribution management server 100 via the pharmaceutical company's client DB (database) 160. This second route follows the procedure previously performed by MR 18. In other words, conventionally, MR 18 entered the delivery feasibility determination criteria information that it obtained into the pharmaceutical company's client DB (database) 160, so this second route has the advantage that MR 18 does not need to learn a new operation (the operation of sending information to the distribution management server 100), making it easier to introduce the present system.

Delivery possibility determination criteria information set for pharmaceuticals and various master information are stored in the pharmaceutical company's client DB (database) 160. The delivery possibility determination criteria information includes information provided by the MR 18 and other information.
In this embodiment, this information in the client DB 160 is stored in the distribution management server 100 via the distribution manager 14 .

In the white circle 3, the distribution manager 14 accesses the pharmaceutical company's client DB 160 and reads out therefrom the delivery admissibility determination criteria information and various master information.
Next, in white circle 4, the distribution manager 14 stores the delivery possibility determination criteria information read in white circle 3 and various master information in a database in the distribution management server 100. Specifically, the delivery possibility determination criteria information is stored in the delivery possibility determination criteria information database 108 and the contents are updated. In addition, the master information is stored in the management master 112 and various information database 110 and the contents are updated.
In this way, the role of the distribution manager 14 in this embodiment includes the role of updating various information stored in the distribution management server 100 as appropriate.
Through such processing, the second route described above is formed.

Next, in the open circle 5 in FIG . 2, the hospital/pharmacy 16 places an order for the medicine with the authorized dealer 10 .
In the white circle 6, the authorized dealer 10 transmits the delivery notification 12 to the distribution management server 100. In this embodiment, this "transmission" is performed by inputting the information of the delivery notification 12 on a website provided by the distribution management server 100.
In the white circle 7, the distribution management server 100 notifies (transmits) the result of the delivery possibility (for example, "OK" or "Possible") to the authorized dealer 10 by email. In the same white circle 7, the distribution management server 100 also notifies the MR 18 of the result of the delivery possibility by email. These notifications may be sent by a single broadcast email.
When the authorized dealer 10 receives the email indicating the result of delivery (possible) in the white circle 8, the authorized dealer 10 delivers the drug to the hospital/pharmacy 16.
In the above example, the result of the delivery possibility is sent by email, but it may be communicated by other methods. For example, "Yes"/"No" or the like may be displayed on a screen provided by the WEB server 102b together with the number of the delivery notification 12. Such an operation also corresponds to a type of "sending" of the delivery possibility result.

Delivery possibility judgment 2
Now, in the above white circle 7, even if the result of the delivery is "not possible", the authorized dealer 10 and the MR 18 are notified by email. In that case, the authorized dealer 10 who received the email of the delivery result (not possible) will not deliver the medicine to the hospital/pharmacy 16.
In this case, at black circle 9, the MR 18 again inquires of the hospital/pharmacy 16 for information on the delivery feasibility criteria. This process is basically the same as that at white circle 1, but since the MR 18 has received a notification at white circle 7 that the delivery feasibility result was "not possible," by inquiring accordingly, an efficient inquiry can be made.

Thereafter, in the black circle 10, the MR 18 transmits the information (delivery possibility determination criteria information ) obtained from the hospital/pharmacy 16 to the distribution management server 100. The distribution management server 100 stores the received delivery possibility determination criteria information in the delivery possibility determination criteria information database 108.
The operation of this black circle 10 is similar to the operation of the white circle 2 already explained, and via the first route or the second route, the delivery feasibility determination criteria information can be transmitted (input) to the distribution management server 100, and the distribution management server 100 can execute the delivery feasibility determination, which is a characteristic operation of this system, based on the newly updated delivery feasibility determination criteria information .
Here, as a method for transmitting (inputting) the delivery possibility determination criteria information to the distribution management server 100, the delivery possibility determination criteria information may be configured to be input on a WEB screen provided by the WEB server 102b.

In the black circle 11, the distribution manager 14 accesses the pharmaceutical company's client DB 160 and reads out the delivery availability judgment criteria information and various master information therefrom. This process is the same as the process in the white circle 3.
In black circle 12, the distribution manager 14 stores the delivery feasibility determination criteria information read in white circle 3 and various master information in a database in the distribution management server 100. This process is the same as the process in white circle 4. That is, the delivery feasibility determination criteria information is stored in the delivery feasibility determination criteria information database 108 and the contents are updated. Also, the master information is stored in the management master 112 and various information database 110 and the contents are updated.

Next, in black circle 13, when the contents of the delivery feasibility judgment criteria information database 108 are updated, the distribution management server 100 re-evaluates the contents of the delivery notification 12 that was previously processed as "not possible" and executes a delivery feasibility judgment. The distribution management server 100 stores the received delivery notification 12 in the delivery notification database 106. In particular, the judgment result of "possible" or "not possible" is attached to the delivery notification 12 as a flag, so the delivery notification 12 in the delivery notification database 106 is stored including the judgment result. Therefore, it is easy for the control unit 104 to extract the delivery notification 12 that has been judged as "not possible" from the delivery notification database 106.

The distribution management server 100 can then reassess the delivery notification 12 that was once judged as "not possible" and notify the authorized dealer 10 of the result of the delivery being "possible" by email. Specifically, the control unit 104 can create an email containing the result of the delivery possibility, and the communication unit 102 can send it. This may be implemented by a so-called automatic email system.
Furthermore, in the same black circle 13, the distribution management server 100 similarly notifies the MR 18 of the result of delivery (yes or no) by email. This email may also be sent automatically by the control unit creating the email and the communication unit 102 sending it.
These notifications may be sent by a single mass email. Although an example of email has been described here, other communication methods may be used, for example, sending (notifying) the information over the Web.
The authorized dealer 10 that has received the email indicating the result of delivery (yes) in the black circle 14 delivers the drug to the hospital/pharmacy 16 .

C. Access Rights Here, the access rights of the distribution management server 100 in this embodiment will be described.
FIG. 3 is a diagram for explaining access rights to each database in the distribution management server 100. In FIG.
For ease of understanding, an example will be described in which a drug (1) from pharmaceutical company A and a drug (2) from pharmaceutical company B are handled. As described in Fig. 1 and other figures, the distribution management server 100 has various databases, and these databases manage internal data separately for each drug handled. In other words, it is essentially the same as if there were various databases for each drug .

In the example of Figure 3, an example is described in which a drug (1) from pharmaceutical company A and a drug (2) from pharmaceutical company B are handled, so Figure 3 is diagrammatically drawn as if there are two types of various databases.
That is, for the drug (1) of pharmaceutical company A, a delivery notification database 106a, a delivery feasibility determination criteria information and various information database 114a, and a management master 112a are provided. Here, the delivery feasibility determination criteria information and various information database 114a is a combined expression of the delivery feasibility determination criteria information database 108 and the various information database 110 shown in FIG. 1, and includes both of these databases.
Similarly, for pharmaceutical company B's drug (2), a delivery notification database 106b, a delivery admissibility determination criteria information and various information database 114b, and a management master 112b are provided.

The delivery notification databases 106 a and 106 b may contain information on the delivery destination hospitals and pharmacies 16 entered by the authorized dealer 10 in addition to the data on the delivery notification 12 .
The delivery possibility determination criteria information and various information databases 114a, 114b store delivery possibility determination criteria information such as contract information and activity information of MR 18.
The management master data 112a and 112b may include information on the authorized dealers 10, medical representatives 18, hospitals and pharmacies 16, and pharmaceutical company personnel.

In the situation shown in FIG. 3, the access rights are defined as follows:
The distribution manager 14 manages and operates the distribution management server 100 and can therefore access all databases.
The authorized dealer 10 can access all databases that are approved by pharmaceutical companies and relate to drugs that the authorized dealer handles. In the example of Figure 3, the authorized dealer 10 handles drugs (1) and (2), and can therefore access all databases for both.

Each pharmaceutical company can only access the database related to its own pharmaceuticals. Pharmaceutical company A's head office staff 180a can access all databases related to their own pharmaceuticals (1). However, Pharmaceutical company A's MR 18a cannot access the management master 112a, and can only access the delivery notification database 108a and the delivery availability criteria information and various information database 114a.
Similarly, the head office staff member 180b of pharmaceutical company B can access all the databases related to the company's drug (2). However, pharmaceutical company B's MR 18b cannot access the management master 112b, and can only access the delivery notification database 108b and the delivery admissibility criteria information and various information database 114b.

D. Detailed Operation Hereinafter, the detailed operation of the distribution management system 90 according to this embodiment will be described with reference to a flowchart.

(1) Preparation process 1
FIG. 4 shows a flowchart of the preparation process for the distribution management system 90.
In particular, FIG. 4 shows the processes corresponding to the white circle 3 and the black circle 11 in FIG.
Step S4-1 represents the facility master in the client DB 160. This data is the in-house facility master and is updated as necessary. This data is imported into the distribution management server 100 by the distribution manager 14 via file sharing, as described later.
Step S4-2 represents the "List of MR information email addresses in charge" in the client DB 160. This data is updated as necessary. This data is sent by email to the distribution manager 14 (distribution manager terminal 140).
In step S4-3, the mail sent in step S4-2 is received by the distribution manager 14 (distribution manager terminal 140). Then, the "responsible MR mail information" sent by the mail is registered in the database of the distribution management server 100.

Step S4-4 represents the "list of MRs in charge of superiors linked to each other" in the client DB 160. This data is updated as necessary. This data is sent by email to the distribution manager 14 (distribution manager terminal 140).
In step S4-5, the mail sent in step S4-4 is received by the distribution manager 14 (distribution manager terminal 140). Then, the "superior-MR linking information" sent by the mail is registered in the database of the distribution management server 100.
Steps S4-1, S4-2, and S4-4 are called master information, and are mainly stored in the information master 112.

Step S4-6 represents the "contract information " in the client DB 160. This data is a type of delivery possibility determination criteria information, and is stored by the distribution manager 14 mainly in the delivery possibility determination criteria information database 108 in the distribution management server 100 by file sharing as described later.
In the explanation of Fig. 4, methods such as sending emails and sharing files have been explained, but depending on the client's request, it is also preferable to automatically link data using a Web API, etc. In this case, the processes of the white circle 3 and the black circle 11 in Fig. 2 are automatically processed, but it is also preferable to link the processes of the white circle 4 and the black circle 12 by the same linkage.
4 and its description are merely examples, and various other information and documents may be used. Furthermore, various other information and documents other than those shown in FIG. 4 may be used as the delivery possibility determination criteria information in FIG.

The process continued from the flowchart of FIG. 4 is shown in the flowchart of FIG.
In step S5-1 in Fig. 5, the database in the distribution management server 100 is updated using the various data described in Fig. 4. This update is executed by the distribution manager 14 via the distribution manager terminal 140.
The facility master (S4-1) and contract information (S4-6) described above are used to update the database in the distribution management server 100 by file sharing, but other methods of data updating may be used. The MR in charge email information (S4-3) and superior-MR linking information (S4-5) may be updated by the distribution manager 14. Also, for example, as described above, automatic linking may be performed using a Web API or the like.

D5-1 is a distribution management DB (facility information), which is a database in the distribution management server 100 and particularly relates to facility information. Specifically, this mainly corresponds to the management master 112. In step S5-1, the distribution management DB (facility information) of D5-1 is updated.
Step S5-2 is a temporary storage process for reserved applications and cooperation confirmations. This is a process for temporarily storing applications and the like whose processing has been put on hold. Applications and the like may be temporarily stored in various information databases 110. This temporary storage is executed by the distribution manager 14 operating the database in the distribution management server 100 using the distribution manager terminal 140.
In step S5-3, a process is executed to reflect the reserved application forms and cooperation confirmation forms in the database of the distribution management server 100. This process is executed by the distribution manager 14 using the distribution manager terminal 140 to operate the database in the distribution management server 100. As in step S5-1, the distribution management DB (facility information) of D5-1 is the target for update.

In step S5-4, it is confirmed whether or not the contract information is described in the document (data) processed in step S5-3. This process is also performed by the distribution manager 14 using the distribution manager terminal 140 to check the database in the distribution management server 100. If the contract information is described, the process proceeds to step S5-5, and if the contract information is not described, the process proceeds to step S5-6.
In step S5-5, the reserved application form/cooperation confirmation is registered. This process is executed by the distribution manager 14 using the distribution manager terminal 140 to operate the database in the distribution management server 100.
In step S5-6, the reserved applications and cooperation confirmations are temporarily stored. This process is the same as that in step S5-2.
In this way, when contract information (delivery availability determination criteria information) is imported (into the distribution management server 100) and a comparison is made before and after the import, if contract information that was "not available" becomes "available," there is a possibility that it will become possible to register the white circle 2 or the black circle 10 in Figure 2. In the next section, the processing of the white circle 2 and the black circle 10 will be explained based on a flowchart.

(2) Preparation process 2
Next, the processes corresponding to the white circle 2 and the black circle 10 in FIG. 2, and also the white circle 3 and the black circle 11 will be described with reference to the flow chart of FIG.
(2)-1 Various information on criteria for determining whether or not a product can be delivered
The facility responsible physician application form D7-1 in Fig. 7 is obtained by MR 18, who then inputs it into the client DB 160. The input state is shown in D7-2. Also, the state in which the information has been sent by email to the distribution manager 14 (to the distribution manager terminal 140) is shown in D7-3.
Similarly, the sub-doctor application form D7-4 is obtained by MR 18, who then inputs it into the client DB 160. The input state is shown in D7-5. Also, the state in which the form has been sent by email to the distribution manager 14 (distribution manager terminal 140) is shown in D7-6.
Furthermore, the cooperation confirmation letter (for doctor) shown in D7-7 is provided from the hospital/pharmacy 16 to the MR 18. The state in which it has been provided to the MR 18 is shown in D7-8. The MR 18 inputs this D7-8 into the client DB. The input state is shown in D7-9. Furthermore, the state in which an email has been sent to the distribution manager 14 (to the distribution manager terminal 140) is shown in D7-10.

Furthermore, the cooperation confirmation letter (for the pharmacy) shown in D7-11 is provided from the hospital/pharmacy 16 to the MR 18. The state in which it has been provided to the MR 18 is shown in D7-12. The MR 18 inputs this D7-12 into the client DB. The input state is shown in D7-13. Furthermore, the state in which it has been sent by email to the distribution manager 14 is shown in D7-14.
The example shown in Fig. 7 shows an operation example in which MR 18 inputs the obtained information into the client DB 160. As described above, this operation corresponds to the operation of the white circle 2 and the black circle 10 in Fig. 2, and further corresponds to the operation of the white circle 3 and the black circle 11 leading to the distribution manager 14.

It is also preferable that MR 18 inputs directly to the distribution management server 100, rather than to the client DB 160. In this case, MR 18 can directly input information such as that shown in FIG. 7 to the distribution management server 100 by accessing the distribution management server 100 using the MR terminal 150 and inputting the necessary data on the screen.

Specifically, it is preferable that the distribution management server 100 provides a website for data input to the MR 18. In other words, the WEB server 102b of the communication unit 102 provides such a website screen, and the MR 18
By inputting predetermined data on the screen 8, the predetermined data can be directly stored in various databases of the distribution management server 100. The WEB 102b sends the input data to the control unit 104, and the control unit 104 stores the data in databases such as the delivery possibility determination criteria information database 108 and various information databases 110 according to the type. In this manner, the delivery possibility determination criteria information database 108 and the like are updated.
The data stored in the delivery possibility determination criteria information database 108 is delivery possibility determination criteria information. The various delivery possibility determination criteria information shown in FIG. 7 and its explanation (mainly the explanation of (2)-1 Preparation process part 2) is only an example, and various other information may be used as the delivery possibility determination criteria information.

(2)-2 Updating the Database The process following the flowchart of Fig. 7 is shown in the flowchart of Fig. 8. In step S8-1 of Fig. 8, the database in the distribution management server 100 is updated using the various data explained in Fig. 7. This update may be performed by the distribution manager 14 via the distribution manager terminal 140.
The above-mentioned various application forms (D7-3, D7-6) and confirmations (D7-10, D7-14) are compared with the distribution management DB (facility information) D8-1 for update processing. This process is performed by the distribution manager 14 using the distribution manager terminal 140 to operate the database of the distribution management server 100. The distribution management DB (facility information) D8-1 is a database similar to the distribution management DB (facility information) D5-1 in FIG. 5.
In step S8-2, it is confirmed whether or not the contract information is described in the data updated in step S8-1. This process is also performed by the distribution manager 14 using the distribution manager terminal 140 to check the database in the distribution management server 100. If the contract information is described, the process proceeds to step S8-4, and if the contract information is not described, the process proceeds to step S8-3.

In step S8-3, the reserved applications and cooperation confirmations are temporarily stored. This process is similar to that in steps S5-2 and S5-6.
When performing the distribution management work according to this embodiment, (user) registration is linked to contract information, so if there is no contract information, MR 18 cannot directly register (in the distribution management server 100). It is necessary to conclude a contract with the facility before acquiring facility information. In other words, (direct) registration in the distribution management server 100 is put on hold until such a contract is concluded.

In step S8-4, after the processing in step S8-5 is completed, the contents of various applications and confirmations are confirmed. This processing is executed by the distribution manager 14 accessing the distribution management server 100 via the distribution manager terminal 140 and confirming the contents of a predetermined database.
In step S8-5, the reserved applications and cooperation confirmations are registered. This process is executed by the distribution manager 14 using the distribution manager terminal 140 to operate the database in the distribution management server 100. This process is the same as S5-5 in FIG. 5.

After the contents of the description are confirmed in step S8-4, they are entered into the database in step S8-6.
D8-2 in FIG. 8 is a distribution management DB (database) relating to applications and cooperation confirmations.

(2)-3 Lock Release Conditions In the distribution management of this embodiment, a state in which the delivery possibility determination is "not possible" and delivery is not permitted is called a locked state, or simply "locked."
The condition for releasing this locked state is that all of the following information is present:
Contract information
・Contract physician data (responsible physician)
・Contract physician data (participating physicians)
・Facility application form ・Physician application form (responsible physician, sub-physician)
・ Cooperation confirmation letter (for pharmacy department)
・Confirmation of cooperation (for doctors)
The information given here is merely an example, and other information may be used.
The conditions differ for each formulation. In actual operation, the above information will be customized for each formulation.

(3) Processing of the Delivery Note 12 Next, the processing when the dealer 10 delivers medicines to the hospital/pharmacy 16 will be described with reference to a flowchart. Such a flowchart is shown in FIG.
D9-1 represents the delivery note 12. The dealer 10 "sends" the delivery note 12 to the distribution management server 100 by inputting the file of the delivery note 12, D9-1, into the distribution management server 100.

As explained in Fig. 1, the communication section 102 of the distribution management server 100 is equipped with a web server 102b and can provide a web site to the outside. The person in charge at the authorized dealer 10 can access the distribution management server 100 from the authorized dealer terminal 130 and can input the data of the delivery notification D9-1 on the input screen provided by the web server 102b. This input operation corresponds to the white circle 6 in Fig. 2.
Next, the control unit 104 creates a delivery note 12 (a computer file) based on the input data, and stores it in a delivery note database 106 .

In this embodiment, the delivery notification 12 is a computer file that includes the date of issue, the name of the authorized dealer 10, the medicine to be delivered (the name and quantity) , and the name of the delivery destination hospital/pharmacy 16. This delivery notification 12 is provided with a judgment result flag, which can indicate the judgment result. For example,
"OK": The result indicates that the product can be delivered.
"Failed": The result of the judgment is that the product cannot be delivered.
At the time of issuing (creating) the delivery notification 12, the determination result flag may be set to "no value."
In this embodiment, this is called a "judgment result 'flag'", but it can be anything that gives an attribute (pass, fail, (no value), etc.) to the computer file (delivery notice 12), and it can be included in the header part of the computer file, etc.

9, the distribution management server 100 sends a receipt for the delivery notification D9-1 back to the party who input the delivery notification D9-1. This receipt may be sent by e-mail, for example, but other communication methods may also be used.
In step S9-2, a search for the prescriber is performed. When the authorized dealer 10 registers (inputs) the information on the delivery notification 12 in the distribution management server 100, the distribution management server searches for the prescriber of the drug, and if the facility information of the prescriber is not available (if it has not been registered yet), the distribution management server 100 is configured to provisionally register the facility information. After the provisional registration, an inquiry email is automatically sent to the responsible department. As a result of this distribution, additional information linked to the facility information is updated in the facility master database (DB) (white circle 3, black circle 11 in FIG. 2).

The operation of step S9-2 is executed by the control unit 104 of the distribution management server 100. The control unit 104 manages the data of the delivery notification D9-1 input to the distribution management server 100, and can estimate the prescription origin from the data and perform a search based on the estimation result. Such an operation of the control unit 104 is realized by the control unit 104 executing a computer program stored in a predetermined storage medium. When searching for the prescription origin, the database of the distribution management DB (unlocked) D9-2 is searched.
In step S9-3, it is confirmed whether or not there is facility master information of the prescription originator. If there is no facility master information, the process proceeds to step S9-6. If there is facility master information, the process proceeds to step S9-7.

In step S9-6, a provisional registration is made in the master information in accordance with the response from the pharmaceutical company. This makes it possible to access the distribution management server 100. This provisional registration is made in the distribution management DB (facility information) D9-3. This provisional registration is realized by the distribution manager 14 using the distribution manager terminal 140 to make a provisional registration in the database in the distribution management server 100.

In step S9-7, the delivery notification 12 is registered. This process is executed by the distribution management server 100. In particular, it is executed by the control unit 104. The control unit 104 stores the delivery notification 12 received by the communication unit 102 in the distribution management DB (unlocked) D9-4. This database corresponds to the delivery notification database 106 in FIG. 1.

In step S9-8, it is confirmed whether the unlocking conditions are met. If the confirmation result shows that the unlocking conditions are met, processing proceeds to step S9-9, and if not, processing proceeds to step S9-10. This confirmation process is also executed by the distribution management server 100. In particular, it is executed by the control unit 104. The control unit 104 executes the confirmation work by referring to the contents of the distribution management DB (facility information) D9-5, and also reflects the result in the contents of the distribution management DB (facility information). The distribution management DB (facility information) D9-5 is the same as the distribution management DB (facility information) D9-3 explained so far. This database corresponds to the delivery feasibility determination criteria information database 108 in FIG. 1.

In step S9-9, since the result of the check was "pass", the determination flag of the delivery notification 12 is set to "pass". This process is executed by the control unit 104.
Furthermore, the control unit 104 transmits the delivery notification 12 indicating that the delivery is "OK" to the dealer 10 (the dealer terminal 130) and the MR 18 (the MR terminal 150). This transmission is executed by the control unit 104 via the communication unit 102.
In this embodiment, for example, a method may be adopted in which the delivery notification 12 with the "OK" flag is displayed on a web screen, so that each party can confirm it on the screen. The display of the web screen may be made simpler. For example, the number of the delivery notification 12 and "OK" or "OK" may simply be displayed, and then "send" may be performed.
The "send" may also be to send the delivery notification 12 with the "OK" flag set to the dealer 10 and the MR 18 by email. This method is also an example of the "send" of the delivery notification 12 that is "OK". This operation corresponds to the white circle 7 in FIG. 2.
Then, the process proceeds to step S9-11 to take a specific action to determine whether the delivery is "OK." This action to determine whether the delivery is "OK" is specifically shown in the flow chart of FIG.

In step S9-10, since the result of the confirmation is "not possible," a notification of "not possible" for delivery is sent to the dealer 10 (the dealer terminal 130) and the MR 18 (the MR terminal 150). This transmission is executed by the control unit 104 via the communication unit 102.
In this embodiment, a method may be adopted in which the delivery notification 12 with the "Not available" flag is displayed on a web screen, so that each counterparty can confirm the information on the screen. Alternatively, the number of the delivery notification 12 and "Delivery not available" or simply "Not available" may be displayed on the web screen, so that each counterparty can confirm the information on the screen.
In addition, the delivery notification 12 with the "Not possible" judgment result flag set may be sent by email to the authorized dealer 10 and the MR 18. This method also corresponds to an example of "sending" the delivery notification 12 of the non-deliverable item. This operation corresponds to the white circle 7 in FIG. 2.
Furthermore, the process proceeds to step S9-12 to take a specific action to deal with the "unavailable" delivery. This action to deal with the "unavailable" delivery is specifically shown in the flowchart of FIG.

(4) Handling of "Ready" Delivery FIG. 10 is a flowchart showing the operation of handling of "ready" delivery.
In step S10-1, the process for responding to a "delivery OK" is started.
In step S10-2, the distribution management server 100 displays a distribution management screen on the WEB. This is realized by the control unit 104 operating the WEB server 102b in the communication unit 102 to display desired content.
The screen shows the contents of the delivery notification 12 with the judgment result flag set to "OK". This allows the dealer 10 and the MR 18 to know that the delivery notification 12 has been confirmed and the delivery has become "OK". This display can be viewed on the dealer terminal 130, the MR terminal 150, etc.

In step S10-3, the drug is delivered from the authorized dealer 10 to the hospital/pharmacy 16. This is done by the authorized dealer 10 in the same manner as in the past.
In step S10-4, the "OK" delivery note 12 is automatically sent by e-mail. In this embodiment, the "OK" delivery note 12 refers to a delivery note 12 whose judgment result flag is "OK".
This is executed by the control unit 104 of the distribution management server 100. This automatic mail is sent to the MR terminal 150 of the MR 18. This automatic mail is also sent to the personal address of the person in charge at the client (pharmaceutical company). This automatic mail is also sent to the authorized dealer terminal 130 of the authorized dealer 10.
The automated mail is named D10-1 for MR 18 (at MR terminal 150), D10-2 for the personal address of the client (pharmaceutical company) in charge, and D10-3 for distributor 10 (at distributor terminal 130), but all have the same content.
In step S10-5, the "OK" delivery note 12 indicated by D10-4, which is the same as the one sent in step S10-4, is stored separately. This process is executed by the control unit 104 storing the "OK" delivery note 12 whose judgment result flag is set to "OK" in the delivery note database 106.

(5) Handling of "Delivery Impossible" FIG. 11 is a flowchart showing the operation of handling a "delivery impossible" situation.
In step S11-1, processing for handling the "unavailable" delivery is started.
In step S11-2, the distribution management server 100 displays a distribution management screen on the WEB. This is realized by the control unit 104 operating the WEB server 102b in the communication unit 102 to display desired content.
On this screen, the contents of the delivery notice 12 whose judgment result flag is "rejected" are displayed. This allows the authorized dealer 10 and MR 18 to know that the delivery notice 12 has been rejected and is now "rejected." This display can be viewed on the authorized dealer terminal 130, MR terminal 150, etc. A delivery notice 12 whose judgment result flag is "rejected" is called a "rejected" delivery notice 12.
The above screen displays the delivery notification 12 with the judgment result flag set to "Not Possible." For example, it is preferable to display the name of the drug related to the delivery notification 12 and the name of the hospital/pharmacy 16 to which the delivery is to be made. Furthermore, it is preferable to display the reason for the "Not Possible" status, that is, the information that should have been satisfied in order to release the lock but was not satisfied (missing). In this way, by displaying the reason for the "Not Possible" status (missing information), the MR 18 can quickly deal with the reason.
For example, if the required contract information is not available, the MR 18 can take the contract information to the hospital/pharmacy 16 to inquire and exchange the contract information . Also, as a result of the inquiry, it may be found that the contract information has been exchanged but not registered in the database (delivery feasibility determination criteria information database 108) in the distribution management server 100. In that case, the MR 18 can register the contract information in the delivery feasibility determination criteria information database 108 in the distribution management server 100.
In this way, by displaying on the screen the information that is the cause of the "unacceptable" result, the MR 18 can quickly take various measures.

In step S11-4, the "Not Accepted" delivery notice 12 is automatically sent by e-mail. This is executed by the control unit 104 of the distribution management server 100. This automatic e-mail is sent to the MR terminal 150 of the MR 18. This automatic e-mail is also sent to the personal address of the person in charge at the client (pharmaceutical company). This automatic e-mail is also sent to the authorized dealer terminal 130 of the authorized dealer 10.
The automated mail is named D11-1 for MR 18 (at his MR terminal 150), D11-2 for the personal address of the client (pharmaceutical company) in charge, and D11-3 for the authorized dealer 10 (at his authorized dealer terminal 130), but all have the same content.
By sending such an automatic email, MR 18 can start the function of black circle 9 or black circle 10 in FIG. 2, and in some cases, can change the "not acceptable" delivery notice 12 to "acceptable" after re-examination.
In step S11-5, a "rejected" delivery note D11-4 similar to the one sent in step S11-4 is temporarily stored as a reserved item. This process is performed by the control unit 104 storing the "rejected" delivery note 12 in the delivery note database 106.

The significance of reserved handling and temporary storage Basically , all "unacceptable" delivery notes 12 in the reserved handling note database 106 can be considered to be temporarily stored, and basically, there is no need to prepare a separate special place for temporary storage. The control unit 104 can search the delivery note database 106 under various conditions, and if it extracts only delivery notes 12 with the judgment result flag set to "unacceptable," it is easy to take out the temporarily stored delivery notes 12.
However, when the amount of data becomes huge, or when it is necessary to properly organize old data by date and time, it is preferable to prepare a temporary storage location and store the data there temporarily.

(6) Unlocking Next, the operation when a delivery notification 12 that has been judged as "not possible" is judged as "possible" by updating the delivery feasibility judgment criteria information will be explained with reference to the flowcharts in Figures 6 to 12.
First, when the database is updated in step S5-1 of the flow chart of Fig. 5, which has already been described, the delivery possibility determination may be affected accordingly. Arrow B in Fig. 5 connects to Fig. 6.

Therefore, the explanation will be given starting from the flow chart shown in FIG.
In step S6-1 of Fig. 6, the contract information is confirmed and the responsible physician is confirmed. These processes may be executed by the distribution manager 14. Here, the contract information is confirmed to confirm that the contract has been concluded. In the case of expiration, it is confirmed that the renewal procedure has already started. Furthermore, the responsible physician is confirmed to confirm that the responsible physician is the responsible physician listed in the contract information .

In step S6-2, the conclusion of the contract and the existence of a responsible doctor are confirmed. In particular, when contract information is imported and compared before and after the import, the distribution management server 100 checks whether the delivery has been changed from "not available" to "available". Specifically, the control unit 104 makes this determination. If there is no change, nothing is done in step S6-3. On the other hand, if there is a change from "not available" to "available", in step S6-4 it is confirmed whether the change from "not available" to "available". These processes may be performed by the control unit 104. In step S6-5, the delivery notices 12 for the unavailable/withheld items are confirmed. This is performed using the distribution management DB (database) D6-1. This confirmation process may be performed by the control unit 104.

Next, in step S6-7, it is determined whether the "rejected" delivery notes 12 that have been determined to be "rejected" are temporarily stored as reserved items. This determination may also be made by the control unit 104. In order to make this determination, the reserved items of the "rejected" delivery notes 12 are checked using the reserved items temporary storage process (see step S6-6). This operation can be performed by searching for data whose result flag is "rejected" as determined by the control unit 104, as described above.
If the result of this determination is that the reserved portion is not temporarily stored, the process proceeds to step S6-8 and nothing is done, whereas if the result of this determination is that the reserved portion is temporarily stored, the process proceeds to step S6-9.

In step S6-9, the so-called lock is released. This means that the delivery note changes from "not acceptable" to "acceptable." This process may be performed by the control unit 104 rewriting the judgment result flag of the delivery note 12 from "not acceptable" to "acceptable" if there is a delivery note 12 temporarily stored in the delivery note database 106.

After the process of Fig. 6, the process proceeds to the flowchart of Fig. 12. The flowchart of Fig. 12 shows the details of the process of changing the lock release from "unavailable" to "available".
First, in step S12-1, the process of changing "not possible" to "possible" is started.
In step S12-2, the control unit 104 extracts the “not acceptable” delivery notes 12 from the delivery note database 106.
In step S12-3, the control unit 104 rewrites the judgment result flag of the "Not Possible" delivery note 12 from "Not Possible" to "Possible". This results in unlocking. Since the delivery note 12 is stored in the distribution management DB (unlocked) shown in D12-1, the "Not Possible" delivery note 12 is extracted from there and rewritten to the "Possible" delivery note 12. This distribution management DB (unlocked) shown in D12-1 corresponds to the delivery note database 106 in FIG. 1.

In step S12-4, the control unit 104 registers the delivery note 12 with the rewritten judgment result flag in the distribution management DB (unlocked) indicated by D12-2. This means that the delivery note 12 is stored in the distribution management DB (unlocked) indicated by D12-2.
In step S12-5, after the above registration, the control unit 104 displays the contents of the delivery note 12 that has newly become the "OK" delivery note 12 on the distribution management screen on the distribution manager terminal 140. This is to notify the distribution manager that the lock has been released.
In step S12-6, the newly unlocked "OK" delivery notice 12 is extracted as a computer file from the distribution management DB (unlocked).

In step S12-7, the control unit 104 sends the "OK" delivery notification 12 retrieved in step S12-6 above to the MR 18, etc., by automatic mail. The "OK" delivery notification 12 retrieved in step S12-6 is attached to this automatic mail. The control unit 104 sends the automatic mail created in this way to the MR 18, etc., via the communication unit 102.
As shown in Fig. 12, the "OK" delivery notice 12 is sent to the dealer 10 by automatic e-mail. The control unit 104 creates the automatic e-mail and sends it to the communication unit 102. The communication unit 102 automatically transmits the e-mail to the destination of the automatic e-mail. In Fig. 12, the sent automatic e-mail is indicated by D12-6.
The "OK" delivery notification 12 may be sent to the MR 18 (the MR terminal 150) by automatic mail in the same manner. This transmission is also executed by the control unit 104 and the communication unit 102, as in the case of the transmission to the authorized dealer 10. In FIG. 12, the transmitted automatic mail is indicated by D12-5.
The "OK" delivery notification 12 may also be sent by automatic e-mail to the personal address of the person in charge at the pharmaceutical company's headquarters. This transmission is also executed by the control unit 104 and the communication unit 102, just like the transmission to the authorized dealer 10. In FIG. 12, the sent automatic e-mail is indicated by D12-4.
In step S12-8, the control unit 104 stores the “OK” delivery note 12 in the delivery note database 106.

In this way, even if a delivery notification 12 was once judged as "not acceptable," it can be changed to "acceptable" by updating the delivery eligibility criteria information, allowing for the delivery of pharmaceuticals with improved convenience.

(7) Data File Output The distribution management server 100 of this embodiment executes a prescribed data file output at a predetermined frequency as a result of daily distribution management operations. The predetermined frequency may be once a day, once a week, once a month, or any cycle may be determined freely. Furthermore, operations that are not executed may be set to a frequency of "0", and when this frequency is set to "0", it may be determined that "data file output is executed at the frequency and output specifications specified by the pharmaceutical company".
This data file is preferably a list of approved delivery notes 12, but may contain other types of data. For example, it may contain the delivery note 12 number, issue date, approval date, name of authorized dealer 10, name and quantity of pharmaceutical product, destination hospital/pharmacy 16, etc. Since approved delivery notes 12 are extracted, it is preferable that the approval date is a required item, but other items may be provided as needed. The state of this data file output is shown in Figure 13.
As shown in this figure, the distribution management server 100 (its control unit 104) extracts delivery notes 12 that have been permitted ("OK") from the distribution management database represented by D13-2, and creates a data file with the values as, for example, a table. The created data file is the unlocking data represented by D13-2. This file is sent to the client DB by automatic email, file sharing, etc. For convenience, this data will be referred to as D13-1, but it is the unlocking data. The distribution management database represented by D13-3 is a database that includes the delivery note database 106 in FIG. 1.

(8) Overall Effects of the Present Embodiment The configuration and operation of the present embodiment have been described above, and a diagram outlining the overall effects thereof is shown in FIG. 14. As shown in this diagram, the authorized dealer 10 accesses the distribution management server of the distribution management system 90 and transmits (inputs) the delivery notification 12 to the distribution management server 100. The control unit 104 of the distribution management server 100 then makes a judgment while referring to the internal delivery feasibility judgment criteria information database 108 and the like. The judgment result is then transmitted to the authorized dealer (displayed on the screen). The authorized dealer 10 can quickly deliver the pharmaceuticals to the hospitals and pharmacies 16.
Therefore, the distribution management system 90 automatically determines whether delivery is possible or not, which reduces labor costs and labor. In addition, the hospital/pharmacy 16 can quickly know the result of delivery possibility without going through the distribution manager 14, which contributes to quick delivery.

(9) Effects of Re-determination, a Characteristic Technical Item of the Present Embodiment Here, the characteristic effects of the "re-determination" of the present embodiment and operational ideas and the like will be described.
(9a) Re-evaluation of the delivery note 12 In the conventional system, when the delivery note 12 is judged as "not acceptable," the judgment result is notified (displayed on the screen) not only to the authorized dealer 10 but also to the MR 18, so that the MR 18 can immediately carry out interviews to prepare the judgment criteria. As a result, the response process to meet the judgment criteria can be carried out quickly, and as a result, it is easy to take measures to change the delivery note 12 that was judged as "not acceptable" to "acceptable."

Therefore, as described above, the "Not Possible" delivery notice 12 is stored as is, and then, when the delivery possibility judgment criteria information is updated, the distribution management server 100 automatically performs a re-judgment each time (each time it is updated). As a result, if there is something that changes from "Not Possible" to "Possible," it can be quickly changed to "Possible," and the delivery notice 12 can be processed quickly.

(9b) Time restrictions (operational measures)
In the above embodiment, there is no particular time or duration restriction for reassessment, but there are some medicines for which the significance of reassessment decreases after a certain amount of time has passed. Therefore, it is preferable to set an expiration date for the items on the delivery notification 12. It is also preferable to configure the control unit 104 to extract delivery notifications 12 marked "not acceptable" and whose expiration date has not yet passed, when extracting the delivery notifications 12 from the delivery notification database 106.
As described above, the delivery notification 12 is a computer file, and as described above, its contents include the date of issue, etc., but it is easy to set an expiration date in addition to these. The expiration date may be set in any way. It may be set freely, such as three days or one year. It may be set when the authorized dealer 10 creates the delivery notification 12, or it may be set automatically based on the type of drug. Also, the expiration date may be set later by another person based on the type and characteristics of the drug.

E. Modification (1) In the above embodiment, there are two routes: one in which the MR 18 directly inputs the delivery feasibility determination criteria information to the delivery feasibility determination criteria information database 108 in the distribution management server 100, and the other in which the information is input to the client DB 160. The configuration may be such that the MR 18 can choose either route based on his/her preference.
However, at the beginning of the operation of the distribution management system 90 centered on the distribution management server 100, it is highly likely that MR 18 is not yet accustomed to inputting information to the distribution management server 100. For that reason, at the beginning of the operation, it is preferable to continue the operation of inputting the delivery possibility determination criteria information to the client DB 160 as before. After that, once the access authority is in order and MR 18 has learned how to input information to the distribution management server 100, it is also preferable to configure MR 18 to switch (route) to inputting information to the distribution management server 100.

(2) In the above embodiment, as explained in (1), MR 18 can input delivery availability judgment criteria information to various databases in the distribution management server 100. When adopting this route, it is also preferable to connect the contents of the various databases in the distribution management server 100 and the client DB 160 using technology such as file sharing or file synchronization.
With this configuration, the delivery availability judgment criteria information input by MR 18 to the distribution management server 100 can be automatically reflected in the client DB, which is convenient for pharmaceutical companies (the "clients" of the client DB) as they can easily obtain the latest data. Also, for MR 18, data can be input to two types of databases with a single input, which is convenient as it reduces the input work.

F. Summary (Overall embodiment)
Although the embodiment of the present invention has been described in detail above, the above-mentioned embodiment merely shows a specific example of implementing the present invention. The technical scope of the present invention is not limited to the above-mentioned embodiment. The present invention can be modified in various ways without departing from the spirit of the invention, and these modifications are also included in the technical scope of the present invention.

10 Authorized dealer 12 Delivery notification 14 Distribution manager 16 Hospital/pharmacy 18, 18a, 18b MR
90 Distribution management system 100 Distribution management server 102 Communication unit 102b WEB server 104 Control unit 106, 106a, 106b Delivery notification database 108 Delivery feasibility determination criteria information database 110 Various information databases 112, 112a, 112b Management master 114a, 114b Delivery feasibility determination criteria information and various information databases 116 Internal communication path 120 Communication path 130 Special dealer terminal 140 Distribution manager terminal 150 MR terminal 180a, 180b Head office staff

Claims (11)

A distribution management server for managing distribution of pharmaceuticals,
A communication unit for communicating with the outside;
a delivery possibility determination criteria information database for storing delivery possibility determination criteria information;
a control unit that executes a delivery possibility determination for a delivery notification transmitted from an external source based on the delivery possibility determination criteria information stored in the delivery possibility determination criteria information database, and generates a determination result;
Equipped with
The communication unit transmits the determination result generated by the control unit to an external device.
A distribution management server comprising: 2. The distribution management server according to claim 1,
The communication unit includes a WEB server that provides a WEB page for inputting information on the delivery notification,
A distribution management server, wherein the delivery notification transmitted from the outside includes a delivery notification with information entered on the WEB page. 2. The distribution management server according to claim 1,
The communication unit includes a web server that provides a web page that displays the judgment result of the delivery notification,
The distribution management server is characterized in that the communication unit transmits the judgment result generated by the control unit to an external device by displaying the judgment result on the web page. 2. The distribution management server according to claim 1,
The control unit is a distribution management server characterized in that it stores delivery eligibility determination criteria information transmitted from an external source in the delivery eligibility determination criteria information database and executes an update process to update the contents of the delivery eligibility determination criteria information database. 5. The distribution management server according to claim 4,
a delivery note database for storing the delivery note;
Equipped with
The control unit sets, as a flag in the delivery notification, a value of either "OK" meaning that the delivery is possible or "NO" meaning that the delivery is not possible, as the result of the determination, and stores the delivery notification with the set "OK" or "NO" flag in the delivery notification database.
After executing the update process, the control unit executes a delivery feasibility determination again for the "not possible" delivery notes stored in the delivery note database based on the delivery feasibility determination criteria information stored in the delivery feasibility determination criteria information database, and generates a determination result.
When the determination result generated by the control unit is “OK”, the communication unit transmits the determination result to an external device.
A distribution management server comprising: A distribution management method for performing distribution management using the distribution management server according to claim 1,
the control unit executes a delivery possibility determination for the delivery notification transmitted from the outside based on the delivery possibility determination criterion information stored in the delivery possibility determination criterion information database, and generates a determination result;
The communication unit transmits the determination result generated by the control unit to an outside;
A distribution management method comprising:
The distribution management method according to claim 6,
an update step in which the control unit stores the delivery possibility determination criterion information transmitted from the outside in the delivery possibility determination criterion information database and executes an update process to update the contents of the delivery possibility determination criterion information database;
A distribution management method comprising: The distribution management method according to claim 7,
The distribution management server includes a delivery note database that stores the delivery note,
a step in which, after the control unit executes the update step, it executes a delivery feasibility determination again for the "unacceptable" delivery notes stored in the delivery note database based on the delivery feasibility determination criteria information stored in the delivery feasibility determination criteria information database, and generates a determination result;
a step of the communication unit transmitting the determination result generated by the control unit to an outside;
A distribution management method comprising: A computer program for causing a computer including a communication unit for communicating with the outside, a delivery possibility determination criteria information database for storing delivery possibility determination criteria information, and a control unit to operate as the distribution management server according to claim 1, the computer comprising:
a control procedure in which the control unit executes a delivery possibility determination for a delivery notification transmitted from an external source based on the delivery possibility determination criterion information stored in the delivery possibility determination criterion information database, and generates a determination result;
a step of the communication unit transmitting the determination result generated in the control step to an outside;
A computer program characterized by: 10. The computer program of claim 9, further comprising:
an update procedure for storing delivery possibility determination criterion information transmitted from an external source in the delivery possibility determination criterion information database and updating the contents of the delivery possibility determination criterion information database;
A computer program characterized by: A computer program for causing a computer including a communication unit for communicating with the outside, a delivery possibility determination criteria information database for storing delivery possibility determination criteria information, a control unit, and a delivery notification database for storing delivery notifications to operate as the distribution management server according to claim 5, the computer comprising:
a control procedure in which the control unit executes a delivery possibility determination for a delivery notification transmitted from an external source based on the delivery possibility determination criterion information stored in the delivery possibility determination criterion information database, and generates a determination result;
the control unit sets a flag to the delivery notification as a result of the determination, either "OK" meaning that the item can be delivered or "NO" meaning that the item cannot be delivered, and stores the delivery notification with the "OK" or "NO" flag set in the delivery notification database;
an update procedure for storing delivery possibility determination criterion information transmitted from an external source in the delivery possibility determination criterion information database and updating the contents of the delivery possibility determination criterion information database;
a second control procedure in which the control unit, after executing the update process, executes a delivery feasibility determination again for the "not possible" delivery notes stored in the delivery note database, which have been determined to be "not possible" based on the delivery feasibility determination criteria information stored in the delivery feasibility determination criteria information database, and generates a determination result;
a step of transmitting the determination result generated in the second control step to an external device when the determination result is “OK” by the communication unit;
A computer program comprising:

Images